r/NetBSD

NetBSD/FreeBSD will not merge, November 1993 announcement
🔥 Hot ▲ 115 r/NetBSD+3 crossposts

NetBSD/FreeBSD will not merge, November 1993 announcement

Both NetBSD and FreeBSD grew out of the community that had developed around the UPK (Unofficial Patch Kit) to 386BSD ("Jolix"). One cause of the split was impatience among the NetBSD founders at the 386BSD release schedule, and the clunkiness of maintaining a list of patches (see Theo de Raadt's comments). They preferred to start their own repository and release their own improved OS, based on version 0.1 of 386BSD plus patches, as NetBSD 0.8 in April 1993. The bulk of the UPK community were more willing to give the Jolitzes a chance to release an interim "0.5" version of 386BSD which would incorporate their patches, but eventually gave up on waiting (unfortunately relations with the Jolitzes had badly soured) and released FreeBSD 1.0 in November 1993. There were some other differences - the NetBSD group were interested in making their code portable to other platforms, the FreeBSD group cared more about performance on 386 (see brief history by Marshall Kirk McKusick). But there was an obvious question of whether they would be better to combine efforts again.

Obviously, negotiations to bring the two projects back together ended unsuccessfully. Last year I posted for help finding the "no FreeBSD/NetBSD merger" announcement, which produced some interesting recollections but no documentary evidence of merger negotiations having taken place. However, after a bit more digging around I've finally found the following in comp.os.386bsd.announce dated Nov 14, 1993: https://groups.google.com/g/comp.os.386bsd.announce/c/0fDtri4DFo4

The Unix Heritage Society have an archived copy: https://web.archive.org/web/20050210210259/https:/minnie.tuhs.org/cgi-bin/newsread?23856

Incidentally that's less than a fortnight after the the big FreeBSD 1.0 release announcement in the same group, so bear in mind this was still very early days, the projects had not diverged nearly so far apart as they are now, and so at a technical level a merger might still have been feasible - though personality clashes and different goals made that a much less practical possibility! It's interesting there were such existential discussions about the future of FreeBSD taking place even during that busy period around the initial release. https://groups.google.com/g/comp.os.386bsd.announce/c/5OphJ9DEU_U

Status on discussed merge between NetBSD and FreeBSD

This statement is being released in hope of putting to rest some of
the general questions and rumors currently floating around in respect
to the long discussed merger between the FreeBSD and NetBSD groups.

Merge
-----

Due to various problems, and in the face of fundamental differences of
opinion regarding future goals and design strategies, all merger talks
between the groups have been suspended and the proposed merger
postponed indefinately.

The FreeBSD and NetBSD groups will not be merging at any point in the
near future, and each group will be pursuing its own schedules and
delivery dates for future release.


What this means to you
----------------------

Despite various accusations and counter-accusations recently levied in
some of the comp.os.386bsd.* newsgroups, both operating systems have
reached the point where they are both very useful (and relatively
stable) development platforms for the Intel architecture, and no one
would be wrong in chosing either of the two offerings.

The currently outstanding technical differences between the two
systems will also, it is quite likely, continue to shrink with time
and both systems will probably seek their own unique areas of
differentiation outside the realm of adding features to the basic
kernel. Neither system plans to stand still over the next 6 months,
and each has a reasonably large enough user base to ensure that new
ideas, corrections and general clean-up work will continue [in both
camps] for some time to come.


Wouldn't a merge have been better?
----------------------------------

There is no question that work duplication and other technical issues
would have been avoided or made simpler under a merge, but for various
reasons it has nonetheless remained outside the realm of practicality;
please remember that what looks very simple from an outsider's point
of view is often anything but. In any case, work will still continue
apace in both camps, and history has generally shown that a little
"competition" has never hurt anyone when it comes to providing
motivation for improvement and forward movement. We tried to
negotiate a merge, it didn't work, so we have to cut our losses and
move forward. End of story.


Is the matter truly closed?
---------------------------

Yes. Please don't bombard us with email saying "Please merge!" or
"Why can't you merge? Why?!?" - believe me, we've gotten every
possible variation on the theme you might imagine, and we've done our
best to explain in more emails than we can count, so kindly do us a
favor and don't send us even more. We need to get on with our work on
FreeBSD, and such things only sap our time and hinder our progress.
To answer the next question: Conversations on this matter to date
have been, of necessity, constrained to private email due to the fact
that the situation has always been somewhat volatile, and public statements
concerning the inner workings of the merge negotiations while they were
in progress would have made them even more difficult.


We also hope that this statement will help put an end to some of the
unfortunate (and wholly unnecessary) public bickering between the
two groups. We're two groups, providing BSD technology to the world
at large for free and at considerably cost to ourselves in terms of
time and energy, so the last thing we need is the ball-and chain of
internecine warfare attached to our feet - it only aggravates all
of us and delays the progress of your favorite operating system!

Please help by cooperating with all of us in trying to put this
somewhat difficult time behind us, and continuing to provide the
extremely helpful feedback and assistance that has made both groups
possible (and certainly 386BSD itself, with which we also desire only
the best relations). Those who can provide common technology in a
group-neutral fashion are the most helpful of all, and we encourage
all of you to do what you can to see that both groups go forward.

This is all about free software, after all, and should not be about
ideological divisions or matters of personal ego.

Thank you!

(The FreeBSD team)

--
(Jordan K. Hubbard)  

It seems the negotiation emails have remained private. The announcement is somewhat vague on how meaningful the merger talks were, whether any serious progress was made, or what the main sticking points were beyond "fundamental differences of opinion regarding future goals and design strategies". I don't know whether any participants have fleshed out any more details in subsequent talks, interviews or writing, but would be very interested in to hear if they did. I'm not aware of any subsequent attempts at a merger but it would be remiss not to mention the 2003 "FretBSD" April's fool joke by Dan Langille and Michael W. Lucas.

u/BigSneakyDuck — 1 day ago
▲ 7 r/NetBSD

BCM4315 rev 0x01 detected but no bwi/bwn module in NetBSD 10.0 i386

I'm running NetBSD 10.0 i386 on an old laptop with a Broadcom BCM4315 Wi-Fi chip (rev 0x01).

What works:

pcictl pci0 list shows the device (01:00.0)

Wired internet works (alc0)

USB tethering works (urndis0)

I tried:

  1. modload bwi - modload: No such file

  2. modload bwn - modload: No such file

  3. find /stand -name "*.kmod" - no bwi or bwn modules found

  4. pkgin search bwi - nothing found

  5. pkgin search bwn - nothing found

From man bwi I understand that firmware is required, but the module itself doesn't exist on my system.

Does NetBSD 10.0 i386 include bwi/bwn modules by default? Where are they?

Is BCM4315 rev 0x01 supported at all in NetBSD?

How can I get or build the bwi module?

pcictl pci0 list | grep Broadcom:

01:00.0 Network controller: Broadcom BCM4315 [14e4:4315] (rev 0x01)

dmesg | grep Broadcom:

[1.052715] Broadcom BCM4315 2.4GHz (miscellaneous network, revision 0x01) at pci1 dev 0 function 0 not configured

uname -a:

NetBSD 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386

reddit.com
u/_szlachcic_ — 9 hours ago
▲ 22 r/NetBSD

Solving the driver problem

NetBSD is a fantastic operating system.

It is in fact the only normal operating system left. Linux has gone Rust+AI and I don't think it will take long for FreeBSD to follow its lead.

DragonFly BSD is almost dead, OpenBSD is way too paranoid, Haiku and ReactOS will take millenia to reach the point of usability and MidnightBSD just sucks.

But, asides from the weird mouse issues introduced in 10.0 and fixed in 11.0, NetBSD's Achilles' heel is the driver support.

NetBSD does have /some/ drivers, at least for my graphics card, but they are barely any better than VESA. I don't play many games but both Minecraft and Minetest have their framerates halved compared to what I get on Linux and OpenBSD and I think that's an optimistic measurement since I've heard many people not having any drivers whatsoever.

And I think we should resolve this issue. I have this feeling that soon many people might abandon Linux due to the things ongoing there, and NetBSD has the potential to be a viable replacement.

The solution to the driver problem might be just using someone else's drivers. It feels bad but that's actually what other folks do. FreeBSD literally uses Linux drivers. I still remember kld_list="/boot/modules/i915kms.ko" and it works just fine.

In NetBSD we could use OpenBSD drivers as OpenBSD is the closest operating system to NetBSD (OpenBSD was actually forked from NetBSD a long time ago).

When you look at an average OpenBSD firmware package, all it contains are binary blobs. If we could get them supported in NetBSD the driver problem would be for the most part solved.

Would studying the OpenBSD source code and replicating the blob loading code into NetBSD be some license violation?

That's been my thoughts.

reddit.com
u/gargamel1497 — 4 days ago
▲ 5 r/NetBSD

usability on the dell latitude 3190?

ive just ordered a refurbished dell latitude 3190 from amazon for about $89, and im wondering, how well with netbsd run? pardon me for not looking more into the laptop before buying..

the cpu runs at 2.4 ghz, with 4 gigs of ddr4 ram

its harddrive is 64 gigs of emmc, which is fine as i dont see why i'd need so much storage

i have researched the gpu and the wifi card - and both seem like they will work normally (gpu is gemini lake - i915drm[kms](4), and wifi is intel dual-band 8265 - iwm(4))

its emmc is a worrying point for me - as i havent really been able to figure out the exact specs for it, and how well netbsd supports emmc "exactly"

what do you guys think? will it run fine? anything i should watch out for? any man pages for me to research further?

reddit.com
u/cxxhld — 4 days ago
▲ 8 r/NetBSD

Help needed: How to get pkgsrc to use builtin/native libraries?

  1. Hello,
  2. I am once again asking for help on this subreddit. Sorry to bother you all, but I really can't figure this one out!
  3. I am attempting to build CDE on NetBSD/vax 11.0 . CDE seems to require fontconfig, and it obviously requires Motif. Motif in turn requires Xft2, which itself requires fontconfig. Building fontconfig is impossible due to the Python dependency.
  4. I would be able to build Motif if I could convince pkgsrc to use the libXft included with the base system. For some reason, pkgsrc refuses. I have checked the version numbers; `2.3.8nb1` is required, and `make show-var VARNAME=BUILTIN_PKG.libXft` returns `2.3.9`. This should work, right? `2.3.9` is greater than `2.3.8nb1`!
  5. I've tried all sorts of things to get it to work, mostly editing `mk.conf` over and over again. Here is my current version:
  6. DEPENDS_TARGET=bin-install
  7. UPDATE_TARGET=bin-install
  8. X11_TYPE= native
  9. PREFER_NATIVE= yes
  10. USE_BUILTIN.fontconfig= yes
  11. USE_BUILTIN.freetype2= yes
  12. USE_BUILTIN.libXft= yes
  13. PREFER_PKGSRC= no
  14. IS_BUILTIN.libXft= yes
  15. BUILTIN_PKG.libXft= libXft-2.3.9
  16. USE_BUILTIN.libXft= yes
  17. Thank you again for your help!
reddit.com
u/Entire-Benefit-7183 — 3 days ago
▲ 3 r/NetBSD

Wi-Fi/Bluetooth adapter

Hello, folks! I’m thinking about replacing my current rtl8851be, which is very new and isn’t supported by any of BSD’s system by a bit older ax210 or ax200 one. But as I know, they both aren’t supported in NetBSD’s 10th release. Is 11th release‘s situation any different?

reddit.com
u/goldmurder — 1 day ago
▲ 4 r/NetBSD+2 crossposts

Schema ports data necessary for init systems

Undoubtedly, regardless of who ch init system is being used, each ports system includes service software that has to be managed by the init/service system in terms of lifecycle. Do any the ports trees have a schema system to allow users to easily grep the services’ init settings? For instance, can we programmatically find out that we need something like ‘ssh_enable=“YES”’ added to rc.conf?

reddit.com
u/demetrioussharpe — 5 days ago