Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Well I do, and moreover I personally have written ~30 thousand lines of code for NetBSD which has been used in other OS projects (the other BSDs, and OpenSolaris at least - see Bluetooth code) in varying amounts, and I am certainly not the only one to have had code re-used. The NetBSD libc is being used for Android now, I believe.

Also, many companies [netbsd.org] do use it, though they don't always advertise that fact.

Seriously, after 25 years in the business I've never seen or heard about anyone using NetBSD in production ever.

The licence is liberal, and companies are not obligated to mention their usage.

Add Minix to the list - they've adapted NetBSD userland, and are an excellent alternative to NetBSD for embedded apps. Only issue - they are currently x86 only, but once they add ARM support and proliferate it across the leading implementations, if not all, they'll be good to go.

Well it's a regular UNIX-like distribution so anyone can use it on their desktop or server if they want, and some do. It's also used in some embedded systems, Apple's networking equipment uses it for example.

Seriously, after 25 years in the business I've never seen or heard about anyone using NetBSD in production ever.

Either you are in the wrong business or you aren't looking very hard. NetBSD runs on almost anything, and is widely used in embedded systems. It is likely that some little black gizmo in your own home or office is quietly humming away with NetBSD inside.

+ FreeBSD is used in certain hardware appliances, and some ISPs use it for shared hosting etc.

+ OpenBSD seems to be the security nerd's choice when they're setting up a really, really secure router. Or so they say.

+ NetBSD? Ummmm. I guess you can install it on some 1990s RISC hardware and brag to slashdot about it? (Except you have to go back to your x86 to run a browser.)

Seriously, after 25 years in the business I've never seen or heard about anyone using NetBSD in production ever. Is this a real legit OS, or is Netcraft just being lazy?

The most important area is probably providing the base for the Darwin kernel. It's good for other commercial products too as the BSD license doesn't require the source to be redistributed and thus you can better protect your intellectual property. But on the other hand, for many BSD setups, Linux would do the job just as fine. It's nice to have variety though.

I'll give you an example Danger, who made the HipTop (T-Mobile's version was the sidekick) one of the earliest innovators for smart / feature phones was based on NetBSD server software. So there you go

This is exactly the reason I was using it for such a long time. I've used it along with Linux and OpenBSD, while these days, I use the latter for my home server. FreeBSD was my first honest attempt at building a home server.

It works without issue. I've used a BSD on and off since the days of Jolitz's 386BSD which came with a compressed image with a number of utilities on a 1.44MB floppy disk. Before this, if a person wanted source code to look at, they would have to pay a good mint to BSDI or a company like that... and of course, if you wanted SVR4 source... good luck with that.

I recall frequent kernel panics while booting that were related to the Intel Ethernet chipset on a SuperMicro H8SGL-F board (not exactly the least common hardware) in a released version (I think it was 8.2 or 8.3), which was probably this [freebsd.org]. Rather annoying.

There have been other problems, too (off the top of my head), like

the mediocre PAE support,

and the in my eyes rather ungracefully handled transition to Xorg 7.2 in the 6.x releases, which for me didn't work at all like the documentation [freebsd.org] said, although this was not a problem of the base system, but the ports collection.

Then there's stuff like some guys arbitrarily deciding to reimplement the system installer and on top of that, to remove the old one in the time window between 9.0 RC 3 and 9.0-RELEASE, see (along with some elitist Linux bashing going on:) here [gmane.org] and here [gmane.org]

or the transition to Clang at a time when it wasn't even ready for the non-x86 architectures!

So sometimes I ask myself whether this OS is really ready for prime time

But enough of the rant. I've been sticking to it since 2000 and for most of the time it just runs and does its job. It's got some nice coherent documentation too.

Back around 1990, we had a 486 system running "US Army BSD". (Whatever that really was.) Apparently our University paid AT&T enough money that this was free to use, at least on-campus.

There are (were) a million-billion variants of Unix. For a while, everyone and their mom was writing [a bad] one or doing [usually a mediocre and never-updated] BSD port. The original RISC machine (IBM RT PC, with the ROMP architecture) had a BSD4.3 port called AOS and later got a 4.4-lite port. A friend had a SAGE machine which ran a Unix called IDRIX. Etc etc.

FreeBSD is a great example of open source working. Not only has it been successful, but it has spawned a lot of other open source projects such as GhostBSD, PC-BSD, DesktopBSD, DragonFly, pfsense, freenas, nanobsd, and my own MidnightBSD.

There are a lot of people who have donated a lot of time to FreeBSD. This wouldn't have happened without all the committers and folks offering patches to the project. FreeBSD and all the other projects I mentioned wouldn't be here without the. Thanks!

I think ftp.exe from NT 3.51 or even 4.0 was BSD based and that was about all. For something as mature and tested as a simple FTP client why bother re-inventing the wheel? It was legally licensed as well.

It was "BSD" derived, not FreeBSD. BSD is often the birth place of many reference implementations of new standards, due to the truly open nature of the license. Develop a "standard" under the GPL and it won't become standard at all, as no commercial OS will be able to use a starting reference implementation as a base.

If you'd bother to think a second before posting, what the OP meant was that you won't see the code of a GPL project being used as a general implementation reference standard. It wasn't a slam against the GPL, simply pointing out that the BSD license allows anyone to read and use the ideas in the code without much in the way of limitation or requirements. For example, a Microsoft engineer could read over the code for the BSD TCP/IP stack and then implement one for Windows using those ideas as a reference.

"For example, a Microsoft engineer could read over the code for the BSD TCP/IP stack and then implement one for Windows using those ideas as a reference. That would never happen with GPL'd code because the license is more restrictive (again, not necessarily a bad thing)."

You are wrong. Anyone that wants to is free to read any GPL code they want and then implement those ideas themselves, using that code as reference. The GPL very explicitly limits itself to copyright law here (which does not prohibit anyone

You are wrong. Anyone that wants to is free to read any GPL code they want and then implement those ideas themselves, using that code as reference. The GPL very explicitly limits itself to copyright law here (which does not prohibit anyone from reading, adapting and applying ideas using a document as a reference.) That is not restricted in any way.

That's not true. Copyright extends to the expression of an idea. Studying code to apply the ideas, that is the expression is covered by copyright. That's why

I think you misunderstand 'expression of an idea'.'Studying code to apply the ideas' is not 'the expression covered by copyright'.Ideas are not covered by copyright. Functionality is not covered by copyright. Only the creative, original expression is covered. Using the black box approach is a way to avoid the argument about what is functional, what is expressive, what is copied, what is original, etc. Trial lawyers love to argue, but clients want corporate lawyers to help them avoid the trial.

I understand that in theory one can study code and avoid expression. In practice though it is complex and people far too easily end up copying expression without realizing it. Expression is a bit broader than line for line copying. See The Wind Done Gone case.

Everyone's getting this mixed up. The BSD stuff went in as a cut and paste with later modifications and there was nothing wrong with that so long as the attributions were kept. So "copied outright" was OK for that licence.

More to the point, the MS engineer could cut and paste the code into his project and modify to suit. In fact, if i'm not mistaken, the original version of the Linux TCP/IP stack was heavily based on the BSD stack if I am not mistaken, but am unable to find confirmation with a quick google search and my memory from back in the early 90s of such things is hazy.

We're currently in an era where lawyers have fought to extend copyright law into some sort of generic Intellectual Property law, and then make that ambiguous enough that their company could win two cases back to back on exactly opposite claims. The GPL can easily be abused in this way, as can all the alternatives. Blaming the GPL, or any other license, is a mistake, when the real problem is widespread legal abuse by powerful corporations.

Point: missed. With BSD code, a closed source vendor can lift the code verbatim and use it as a starting point in their code. This is a FEATURE (not a bug) as it enables us to have well tested code in all our apps, be they open source or closed.

Like I said above. That's fine. That's a standard code base. I would agree BSD allows for a standard codebase. But that's a different claim then saying the GPL apps don't allow for standards. That's a different claim.

____

Now addressing that much weaker claim, I also don't happen to agree with you that the BSD license does this. Because there is no sharing the proprietary vendors end up creating non standard extensions of the BSD codebase rendering the free one more or less worthless. The history of X

There is a little bit of truth hiding behind your words but your statement is still very misleading.

GPL is much more 'truly open' precisely because no 'proprietary' implementation of a standard with a GPL reference implementation will be able to simply lift the code (legally.) *Proprietary* being the keyword here - you said commercial, and that is simply false. You can make a commercial implementation of a standard with a GPL reference implementation, and furthermore you can simply copy that reference implementation to do it!

Proprietary != commercial. Slackware, RedHat, Ubuntu, etc. are all commercial. GPL is perfectly fine with commercial. It's only proprietary that it objects to (and for good reason!)

I will second that. And beyond just the fact that FreeBSD is a great OS and has spawned a number of derivative systems is the fact that it participates in the *BSD ecosystem in which useful ideas and developments are shared among the many BSD based distributions. (FreeBSD, NetBSD, OpenBSD.....n) That makes for a lot of innovation and experimentation that benefits much of Unixland, and beyond.

Let's explode that myth. Here's what actually happened.
Linux distributions such as Slackware back then supported booting from a floppy into the OS so that one could run the rest of the userland from a hard drive. That meant one could preserve Microsoft Windows booting yet run Linux at the same time with no risk. I cannot stress how important a feature that was back then to someone like me, back when PCs were very expensive and had to be shared among family members.
The FreeBSD developers took a different tack. Their OS was for grown-ups, for servers. They openly mocked on their mailing lists the feature of being able to boot into the OS from a floppy drive. (Note this is different from being able to INSTALL from floppy, everyone back then could do that.)
The FreeBSD developers CHOSE to not be popular.

I disagree, as far as real adoption goes. Yes, booting Linux from a floppy using a MSDOS filesystem did enable a lot of people to get exposed, but the race was lost before those people made a difference. Had BSD development not stalled for two years, many of the early commercial and big site adoptions would have gone to BSD instead. Many started with BSD and then jumped to Linux because that is where the momentum was. Red Hat's IPO sealed the deal.

BTW, I introduced Pat Volkerding to the Church of the SubGenius, and pioneered a lot of the early work with Linux at Fermilab. I know a little about these things.

Red Hat's IPO was in 1999. The Linux:: BSD ratio was already massive by then.

I don't agree with you about 1994. I don't think it was losing time. I think the BSD community was hostile to people like me (Windows Power Users and Unix users -- non admins) who became the people who pushed Linux into corporate America during the 1990s and early 2000s.

It wasn't just something specific like floppy boot, it was the entire attitude that Linux was for "Peecees" or "Windoze" users, while *BSD was for the Sun Workstation Master Race (who couldn't actually personally afford a sun workstation). Just as an example, *BSD thought "real workstations use SCSI (period)". While Linux had all sorts of workarounds for your buggy IDE chipset and support for your proprietary Soundblaster CD-ROM drive.

And while the Net/Open/Free factions were flaming each other on the maillists, there was this persistant attitude that Linux was vastly inferior thing, even after the "the battle was over", and Linux had clearly won. When the history is really written, the story of *BSD has little do with AT&T and is more about how arrogance and personal politics alienated a entire genration of users.

Honestly it was worse than that. Linux also had the "I wish I could buy a Sun workstation but can't afford one" crowd. BSDs were focused on Unix admin types they didn't want Unix user types with light admin knowledge.

Actually, the efforts in PC-BSD seem to suggest otherwise. From everything I've read, they've done their level best to ensure simple things - such as gui utilities working in the same way that CLI utilities work. That would have taken a lot of work. Once they get that entire OS pnp installable, that will be good enough to challenge the likes of Ubuntu, Mint, Fedora and other Linux distros. PC-BSD also offers a much wider choice of DEs

The BSD people keep telling themselves that but no. The BSDs never made an attempt to appeal to Windows Power users and Unix users who didn't do administration. They focused on providing a classic Unix admin experience. They were harder to install, harder to configure, less tolerant of various hardware.... BSD failed because it never made an attempt to appeal to the group of end users that became the Linux desktop users of the 1990s and the Linux admins of the 2000s.

Well no. The difference is that I could get a stack of floppies and simple install instructions and actually install Slackware and get it running within one day. Whereas with BSD, asking for install help was pretty much guaranteed to leave you with the mark of the idiot for the remainder of time.

I'm not trolling here, but as a Linux user I never took interest in BSD, I hardly know what it is. The impression I have is that it is solid but somewhat backwards compared to Linux. It's just strange to me that there are two similar OSes coming out the same year and they are still both here. So what are the differences besides the licensing scheme ?

As a regular user you don't see any difference. The same software works on both.

The main differences are in the kernel, and in the way the systems are developed. In Linux land the kernel and most other operating system components are developed in separate projects, and the distributions are responsible for packaging them so that they work together as one cohesive operating system. In FreeBSD everything is developed by essentially the same team as one big project. That's why we often don't speak about BSD di

That's a good description. I would add that each develops with a different open source philosophy; Linux under GPL, the BSD's under the BSD license.Proprietary software companies use CopyRight to preserve power for themselves.The GPL answer to it is CopyLeft, (I'll share with you, but only if you agree to share with everyone else).The BSD answer is CopyFree (I'll share with you. Period. I have faith that some good will come out of it).Perhaps both approaches in parallel are needed to prevent CopyRight holde

Hmmm.. last used for any length of time: FreeBSD 2.2.2 with FVWM95 (serial mouse!), back in '00 or thereabouts. (At the time, FreeBSD was reliable; Linux was not. Corel Linux--remember that, anyone? Urg. Red Hat? flaky, at the time. Mandrake Linux: slightly less flaky.)

But the culture hasn't changed much, from a recent scout-round. I'd say your impression is correct. Here are some random thoughts:-

*BSDers will say *BSD is more like "real Un*x", but as far as I can tell the OS has been riddled with schisms since the '70s. The "real Un*x" is a nostalgic fantasy (or an artefact of Stockholm syndrome, take your pick).

*BSDers will say *BSD is reliable. That hasn't been a problem for Linux for a decade. (Except for Intel's video drivers...grrr.)

Differences...apart from being behind the times hardware-wise (which you can do with Centos 4, if you want), the main difference is: only one "distro". (Although there are a few derivatives of FreeBSD and NetBSD, only their creators use them, pretty much.) BDSM submissives enjoy OpenBSD; no-one'd dare fork it.

The FreeBSD man pages were better. Way better, as I recall. That's in part because they tried to avoid all that dubious GNU stuff. Can't say they were wrong about info(1), but I can say they were wrong about make(1).

Filesystems. Linux and *BSD have *FAT*, NTFS, and ZFS in common. That's about it. FreeBSD has had ZFS for a couple of years longer than Linux.

Culture. For a long time the *BSDs' attitude was "compile it from source, and fix the dependencies yourself". Like combining the bad parts of old-time Slackware and Gentoo. Might be better now; I've only tried Live CDs.

Startup: I like the rc.conf startup configuration approach. (Way better than System Five initscripts. "Fragile" hardly begins to describe that approach.) I used Arch Linux for a long time because it had the closest approximation to rc.conf, but it also had drivers for USB and stuff. You know, the hardware I had attached to my PC. Not much, back in the day; but I wanted to use it. Arch was a pretty good compromise.

Now, Arch Linux has moved away from an rc.conf-ish approach to using systemd. I've been getting progressively more annoyed with all the Sieved Poots appearing in linux, so I recently tried PC-BSD, which is supposed to be an end-user friendly porcelain on top of FreeBSD. Unfortunately, it's dire. Bug after glitch after missing object. On both my PCs, the typography is eyewatering. Worse than Windows 3.11.

You're better off with FreeBSD. I might be going back there soon. Probably, though, it won't have support for my USB wifi stick. If you never see me comment again, you'll know what's happened.

They are similar but not the same. Most Linux distributions uses the GNU user land, where FreeBSD develops its own. Programs like ls will still fulfill the same task, but the options will be different and some features might be missing. You can still install the GNU user land on top of FreeBSD if you want it.

ZFS appears to have a performance advantage under BSD. Or am I out of date again? In any case, I use BSD as a cheap NAS for precisely this reason. It can saturate gigabit ethernet on a cheap slow system.

The reason I switched for FreeBSD around 2001 is that in-kernel sound mixing Just Worked. Two apps could write to/dev/dsp and get working sound. I'm now writing this while watching a DVD on the FreeBSD box connected to my projector and 5.1 surround sound system and I didn't need to do any configuration.

The other big difference is ZFS, which makes a huge difference to how you manage storage. Creating a new volume is as easy (and fast) as creating a new directory. You get compression, deduplication, constant-time snapshots, and a load of other things via a very easy administration interface.

If you're doing development work or running servers, jails give you a way of deploying a complete system that's got almost the same isolation as a VM but with much lower overhead. With ZFS, you can create one stock install and then clone it into a new jail in a few seconds.

The base system is maintained as a whole and the developers take the principle of least astonishment (POLA) seriously. User-visible changes are minimised and new configuration utilities are expected to follow the pattern of existing ones.

For firewalling, there are a number of choices, but the most sensible is probably the fork of OpenBSD's pf, modified to have better SMP scalability.

For security, there's the MAC framework, which is roughly equivalent to SELinux, that the sandboxing on OS X and iOS are based on, and also Capscium, which provides a capability model that is better suited to application compartmentalisation. An increasing number of the system daemons use Capsicum for privilege separation.

That's probably most of the user-facing things. You'll notice that GPU drivers (except for the nVidia blobs) tend to lag Linux somewhat. For Intel it's not so bad, for AMD it's quite a way behind (catching up, but not there yet).

There's a few things where it's ahead and a few where it is not. ZFS is the biggest thing it leads with IMHO, since the linux implementation (which I'm using on the computer I'm typing this on) has a lot of catching up to do.Another thing which really astonished me is it's performance on 32 bit hardware. To learn how to use freebsd I put it on a disused server full of IDE disks and it performed far better than the linux that had been on there previously. On more recent systems it behaves as well as linux

I remember downloading 386BSD via ftpmail one floppy image at a time. And writing those images to soooo many floppies and again when some of them were corrupted. It took days to download and install 386BSD for the first time but eventually I got it up and running on an 386DX machine. The sense of awe and wonder I had when it finally booted was indescribable. Those were the days.

I'm still waiting to see the BSD userland / toolchain environment spliced together with the Linux kernel. My headache with BSD was always hardware driver support. Linux, the kernel, has won that race, and rather then duplicate efforts I would like to see the best parts of *BSD merged on top of a Linux kernel. Instead of just GNU/Linux (SysV Style Linux), you could have an alternative BSD/Linux (BSD Style Linux) distribution. If you include Mac OS X, BSD style unix far an away out numbers SysV style machines

I think BSD/Linux is a brilliant idea. I started off with SOLARIS and various flavors of BSD and have gradually moved over to GNU/Linux for hardware compatibility. Linux has finally reached BSDs rock solid stability, but I still miss the rc scripts, logical parameters, and well written man files of the BSD userland. Have you tried Starch Linux?

I've attempted to use FreeBSD over the last 10 years and every single time I attempt to, I run into the exact same issue with hard drives. Simply the fact that my chipsets are never supported, IDE and Sata. I've been in the chatrooms on IRC, I've been on the forums and no one was ever able to answer me. So FreeBSD might be 20 years old but they still don't have hard drive support.

Happy Birthday FreeBSD! I've been around since the 1.x series, and I'm still using it on a day-to-day basis, both @home and @work (there, with thousands of FreeBSD servers).

Having said that, I'm not really happy about the status of Xen on FreeBSD. Sure, Xen/DomU is working, no complaints about it. But we're waiting for Xen/Dom0 support for quite some time now, basically to host various VMs on FreeBSD/ZFS clusters. Sadly, Xen/Dom0 support is nowhere to be seen.

With UEFI-PCs being locked down to Microsoft's bootloader soon, FreeBSD will very likely move to one of the Microsoft-signed Linux bootloaders... and that will basically be shim/grub2 or something like that.

A predictable problem I would have expected the *BSDs to avoid. Pre-compiled packages have never been ideal. We used to rely on them simply because our systems were so slow that compiling took so long. With a modern computer you should be able to compile an entire system in about 20 minutes so why on earth would you want to invite problems by using someone elses binaries?

Because your build environment may be subtly different than mine., or the build environment on which the software was first generated and tested. And this can seriously break the software.

The presence, or absence, of optional compilation components makes a large change in software features. A very small change in one system library, or compiler environment, added to allow one component to build, may break other live components in ways the original author of either component never envisioned. And if I patch

Recovering from the security incident is not just a matter of reformatting the machines. You don't just turn things back on and hope. All of the code that is being used to build the packages is being audited (this is now basically done). The FreeBSD cluster is now running auditdistd, so that auditing logs of all of the build machines are preserved even in the case of a compromise. The goal is to ensure that a compromise like this can't happen again, not to rush out packages and then have to do the whole

It did. Android's libc uses a lot of FreeBSD code. They've recently been talking to us about syncing some of their changes and treating us as they do other upstream projects that they pull code from, rather than maintaining a complete fork. They picked the Linux kernel for a very simple reason: Android was created by a small team, and they had experience with the Linux kernel.

I think so. I think that the GPL provide a way for corporations to cooperate and avoid the tragedy of the commons. Under the GPL you as a company get to use this valuable codebase for your project but in exchange you have to help a bunch of companies you neither know about nor care about. That worked much better than a situation where people were free to take without having to share.

No. The GPL does not say you have to give back to the community, it means that you have to pass the source to anyone that you give the binary to. When Google extended Linux to run on their cluster infrastructure, most of those changes remained private. Given that 90% of all software development is in-house and not for public release, this only means that 10% of developers would be compelled to release code by the GPL. The remaining 90% are not affected, but often avoid GPL'd code because of possible fut