Confessions of a Recovering NetBSD Zealot

debilo writes, "ONLamp.com is featuring a lengthy interview with Charles M. Hannum, to Slashdotters probably best known for his wake-up call aptly titled The Future of NetBSD that generated a rather vocal discussion. In the interview, Charles speaks about his role in and the beginning of The NetBSD Project, shares his thoughts on software licenses, discusses the popularity of Linux and its development model, and further addresses the problems that NetBSD is facing. Some notable quotes include: 'If I were doing it again, I might very well switch to the LGPL. I'll just note that it didn't exist at the time.' And: 'There was a lot of FUD around this issue — some of it from Linus, actually — and it did cause us some problems.'"

Comments

Why doesn't he pull a Matt or Theo?

[Anonymous Coward]

In the past, when notable members of the BSD community have encountered difficulties with the status quo, they have taken the initiative to go out on their own. This has proven to be a successful path twice over: first with Theo de Raadt forking OpenBSD from NetBSD, and then Matt Dillon forking DragonFly BSD from FreeBSD.

Will we ever see Charles back up his rantings with a similar fork? The community won't take him seriously until he does at least attempt to rectify the problems he sees by creating his own fork of NetBSD.

Re:Why doesn't he pull a Matt or Theo?

[Hal_Porter]

Maybe he could join Theo's project. Seems crazy to let ego get in the way of the important work of developing software.

Re:Why doesn't he pull a Matt or Theo?

[CTwelve]

I suspect he may be wary of forking off another operating system, which is after all, a large move with consequences to the user community. Definately not something I would undertake lightly...

Re:Why doesn't he pull a Matt or Theo?

[Anonymous Coward]

But if the problems he describe are as serious as he claims them to be, he should have no problem getting current NetBSD developers to migrate over. He may even be able to attract new developers.

Yes, it does take a lot of effort. But in the end, it sometimes pays off greatly. It was precisely that sort of a fork that created the X.org project, which as we know today has become the premiere X11 implementation. XFree86, once a powerhouse, is basically ignored by all (except NetBSD). Many of the disgruntled XFree86 developers moved to X.org, and with its new organizational structure development really took off.

Perhaps it is time for the same to happen with NetBSD. Like XFree86, it is a relatively ancient project, and sometimes ancient projects do need to morph into new projects with a new organizational structure. And for the record, I'm posting this using Seamonkey on NetBSD.

Re:Why doesn't he pull a Matt or Theo?

[unPlugged-2.0]

I think that forking is one of the most disruptive ways to let your point be known.

It hurts the overall project and also has the potential to lose developers and dilute the name even more and start a project just to make a point.

I think that if OSS developers learned to work well and resolve differences without a fork that would make the projects much more competitive.

NetBSD is one of the oldest BSD's and has really suffered a lot from well publicised forks (Theo) and other corporate involvement.

I think it is better for Charles to rant and take his opinions up on a public forum as opposed to forking what is really an exceptional OS.

Re:Why doesn't he pull a Matt or Theo?

[Anonymous Coward]

Division is bad because developers are divided and conquered by MS. Se what happens in the KDE vs GNOME vs good-old-wms. Everybody's fudding each other, wasting time, competing for eye-candy, etc.

So there must be one free OS and people combine their skills to improve it. Why linux?
At least linux was bade and is governed by a real person/hacker and not a board of old directorys.

Sure, nowadays linus doesn't see patches and there are some lame submaintainers who are totally off-putting. And BSD seems more acceptive. But that's because BSD must appear so, in order to survive. If BSD was the one, I bet the board of directors would be the ones to put off the simple contributors.

OpenBSD is neat tho...

Re:Why doesn't he pull a Matt or Theo?

[m.dillon]

Forking a project is not a walk in the park, it takes a huge multi-year commitment in time and effort and it does not necessarily follow that the solution to a disagreement, even a huge disagreement, is to fork a project. It just so happens that I had all the pieces necessary to fork DragonFly (particularly the time available to do so and the ability to self-fund the effort). Theo I believe had similar time availability and the ability to obtain funding (stressful as it probably is at times) to support the effort. Probably one of the biggest reasons why FreeBSD has fragmented leadership now is a lack of time on the part of its leaders verses other life events.

Forking a project is NOT necessarily detrimental. In fact, I would consider it more an evolutionary inevitability. The plain fact of the matter is that most Open Source projects are a confluence of like minded individuals which is at best ephermal in nature. People age, people's interests change, people's life situations change, new people coming in have a different take on things... to assume that a project can keep the same face forever and that such evolutionary changes as a fork in the road is detrimental can only lead to one result: stagnation.

I wouldn't hold Linux up as a poster child, either. Linux is one of the most commercialized projects in existance compared to the BSDs. Just because the core is free doesn't mean the product is. Every time I turn around yet another GPL'd project is being commercialized by its developers, or using tag-ons to the license that require the author to sign over his copyright to the project. The GPL license no more protects against proprietization and commercialization then the BSD license. Nor does it protect against fragmentation... Linux is far more fragmented then all the BSDs put together, and that has seriously hurt its ability to compete against Microsoft. It's nice to day dream, I guess, but the reality is very different.

-Matt (Dillon)

Re:Why doesn't he pull a Matt or Theo?

[Anonymous Coward]

Hi Matt,

Your claim (here: http://slashdot.org/comments.pl?sid=145721&cid=122 08270) that you are
getting close to Linux's SMP parallelism is very interesting to me. If it is true (for interesting values of
"close", and presuming that UP performance is not compromised), I will accept that yours is a revolutionary
(or at least very significant) model for SMP scaling.

I would be really interested to see what sort of data you use to arrive at this conclusion.

At one end, Linux (the kernel.org kernel) runs on SGI Altixes with 1024 cores and 512 memory nodes. I've heard
SGI make noises about their hardware cache coherency supporting 16K CPUs, and they're realistically aiming for
4096 in Linux. But it is also true that these systems won't perform well under *all* workloads...

Now obviously your kernel would run on systems with a maximum of about 64 cores (IIRC, thats about the biggest
x86+/-64 system made). But I'd be surprised if you had access to one of these or could even boot on one. I'm
betting that you must be testing on Opterons, which run pretty well up to 8 cores.

On such systems, I have seen FreeBSD (even 6.x, don't know about 7.x) scale utterly dysmally, often performing
worse than when using a UP kernel on a single core (search FreeBSD archives for mysql benchmarks). While Linux
scales much better on the same workload. So I think its odd that you can be "close" (as in, not quite there yet)
to FreeBSD and also close to Linux. If you are anywhere near FreeBSD, I think you are a long way behind Linux.

Anyway, I'd love to be corrected by some numbers.

Re:Why doesn't he pull a Matt or Theo?

[Anonymous Coward]

Seems crazy to let ego get in the way of the important work of developing software.

You must be new here...

Thanks

[ITO]

Thank you.

It's a new day, new things .. lot's learned.

good luck.

Re:All "in the family."

[westlake]

Wow! Do geeks eat their young, or what?

Hang around here long enough and you'll stsrt to think the answer is "Yes!"

Re:All "in the family."

[mccalli]

How old are you, kid...?

No, that wasn't a serious go at you but it was an attempt at world-weary commentary. I was around when Linux was launched. I was using Minix on an Atari ST before that happened. I was using Linux as a primary desktop in 1994. And once upon a time I had code in the standard Linux driver set (a Compaq SCSI controller, I believe long since factored out. At least, I hope so).

So. The answer is....yes. Geeks eat their young. I remember at the time knowing very vaguely about BSD, but 'knowing' equally that I should steer well clear of it due to ongoing and the future potential for lawsuits. As it turned out, this was utter junk - FUD so to speak. In fact, looking back at things with the artificial benefit of perfect hindsight I would have gone the BSD route rather than the Linux one. I still read amusing little pro-Linux rants that are actually just pro-open source Unix userland, not pro-Linux as they believe themselves to be. Don't get me wrong, there are definite differentiators between BSD, Linux, running GNU tools on Solaris, OS X etc. but that's not the point I'm interested in here. For this discussion, I'm interested in seeing many of Unix per-se's benefits being described as Linux benefits when they are nothing of the sort. Personally I feel a good deal of progress could have been made just following the BSD route instead of going the Linux kernel route. LGPL does seem to encompass the majority of the BSD way, so I find I have agree with the statements made in this article.

Cheers,
Ian

Cause and Effect of BSD "Safety"

[twitter]

A lot of people (and I don't want to be divisive, but honestly they were mostly Linux proponents, including Linus himself) spread FUD for years about BSD systems being "unsafe"--even after the UCB/USL lawsuit was settled. The fact is that there was no danger in using NetBSD in a product, and a number of companies did so.

You have to wonder if that would have been the case if there was not a much bigger boogie man for Ma Bell, M$ and other greed heads to worry about. If it were not for the success of the GPL, would BSD be left alone today? I think not.

Re:Cause and Effect of BSD "Safety"

[s_p_oneil]

Are you kidding? BSD was the bigger boogie man, which is why those companies kept beating it even after it had been effectively "put down" due to fear of law suits. Linux was definitely seen as the lesser of two evils by the powers that existed at the time, and with good reason. The license makes BSD much more of a threat to them than Linux will ever be.

Just look at what Apple did with OS X. Any company could do that, getting a huge head start by building on top of the rock solid BSD core (with no fear of being sued, as you would with the GPL). That is a very scary thought indeed for MS.

What free OS designers need to do is realize that Apple did something very right with OS X, and follow suit. Unix with X-Windows on top of it is not suitable for the average user. X-Windows needs to be replaced with something more light-weight (i.e. single-user with direct access to the multimedia hardware). X-Windows will always be around for the power users who want it, but the average joe just wants his games/videos/music to run smoothly without any hassles, and he wants to be able to be stupid when it comes to using the Internet without having to worry about viruses, spam, and all that.

Re:Cause and Effect of BSD "Safety"

[Lord Kano]

and he wants to be able to be stupid when it comes to using the Internet without having to worry about viruses, spam, and all that.

And this will never happen. Even if "Trusted Computing" wins the day, Sony's rootkit fiasco proves that companies that are big enough to get their binaries signed are willing to fuck you over.

LK

Re:Cause and Effect of BSD "Safety"

[bcrowell]

X-Windows needs to be replaced with something more light-weight
I was with you until this point. X is very lightweight; it runs on some truly ancient systems. Quartz is much heavier.

X-Windows will always be around for the power users who want it, but the average joe just wants his games/videos/music to run smoothly without any hassles,
None of this has anything to do with X versus Quartz. Some of it has to do with proprietary video cards and proprietary codecs. Some of it has to do with the fact that companies producing proprietary games don't see enough profit to be made by porting to any system besides Windows, because Windows can get them to so much of their market.

Re:Cause and Effect of BSD "Safety"

[s_p_oneil]

Of course that will never happen, but you can make it safer for them to be blissfully ignorant. I was thinking more along the lines of not giving the average user root access to the core OS files (while still making sure he has direct exclusive access to the hardware). Make him have to do something relatively difficult (like change and recompile the kernel) to get root access if he really needs it. You could also make it an OS installation option for developers.

For the average user and PC, it's ok to make him install and run everything in his user folder. That means the worst that can happen is that he'll have to wipe his user folder and start over. Certain high-risk applications, like browsers and IM clients, can be quarantined so that getting a virus from one means you only have to reinstall that application.

Re:Cause and Effect of BSD "Safety"

[dbIII]

X-Windows needs to be replaced with something more light-weight (i.e. single-user with direct access to the multimedia hardware)

The rest of the world is waking up to the idea that single user non-network aware systems are limiting. Hacks like VNC and Gotomypc get you somewhere (I use both) but are really still hacks to get around the limitation. As for needing something more "lightweight" - you can run X windows on a Nintendo DS - that's right, on a system with 4MB of total memory and no memory management unit in the CPU. What Apple have done is certainly not lightweight in comparison to X and was never intended to be.

Re:Cause and Effect of BSD "Safety"

[s_p_oneil]

Ok, poor choice of words. However, X without a window/desktop manager is pretty useless to an average user. Although many window managers are also light-weight, Gnome and KDE do not seem to be, and most users trying Linux or BSD for the first time end up trying one of those. I personally prefer some of the lighter window managers, but they don't seem to be accessible to the average user who just wants things to "work" effortlessly.

Also, I didn't say anything about availability of games. That won't come until a decent percentage of people are using these OS's. And I don't believe that will happen until various problems in X, and its window/desktop managers, are fixed. Actually, applications need to be fixed, too. Consistency and ease-of-use are key, and that includes the applications running on it, not just X. Performance is important too, and performance under Gnome/KDE has always seemed sluggish to me.

Re:Cause and Effect of BSD "Safety"

[bcrowell]

Although many window managers are also light-weight, Gnome and KDE do not seem to be, and most users trying Linux or BSD for the first time end up trying one of those. I personally prefer some of the lighter window managers, but they don't seem to be accessible to the average user who just wants things to "work" effortlessly.
Sure, I agree with you there. I use fluxbox myself, for exactly those reasons. However, I think Gnome is starting to have more acceptable performance on today's CPUs. Also, many Windows users are used to bad performance anyway, so they don't notice a difference if they try Gnome. OTOH, it would be nice if Gnome could be more snappy, in order to give Windows users a positive reason to switch to Linux.

Re:Cause and Effect of BSD "Safety"

[ewl1217]

For the average user and PC, it's ok to make him install and run everything in his user folder.

Just imagine the looks of confusion on people's faces when a program they installed isn't avaliable to other users. It may be more secure, but if you have multiple users, then you're in for a lot of unnecessary trouble.

Re:Cause and Effect of BSD "Safety"

[s_p_oneil]

I don't think it would be confusing to most users at all. When my wife uses my computer, she gets confused by all the crap I've installed on it. If she installed her own apps and I installed my own, we would both be happy with it. She's gotten my PC infected with the Cool Web Search virus twice, and at the time it couldn't be removed without "format C:", so I would definitely like to quarantine what she does on my computer. ;-)

For things like games and multimedia files, disk space could be a real problem. Perhaps each user could have a "share" folder to put things in that other users could access. I didn't say I had the whole concept worked out. I just think it would be nice. ;-)

Re:Cause and Effect of BSD "Safety"

[alc6379]

Just imagine the looks of confusion on people's faces when a program they installed isn't avaliable to other users.

Then make an option available that's already around in many Windows XP program installations.

Install application for:

[ ] All Users
[ ] Just Me

...Then run each user's instance in their own sandbox. You wouldn't need seperate copies of the application for each user, but each sandbox would be denied access to all resources except the ones absolutely needed.

We need a NetBSD

[PhotoGuy]

My view of NetBSD:

A *Freely Licensed* (copy the crap out of it *if* you want, contribute *if* you want, not like GPL), rock solid, incredibly portable, fully functional kernel/OS that will install off of a fraction of a CD.

There's nothing like it, and I think it has an important place in the computing world. Please don't ruin it with (L)GPL's and other crap, it has its place!

You can make an NetBSD installation appear almost indistinguishable from a Linux installation (when you add the optional GPL packages), which is pretty cool. But if you need a lean, mean, *free* core, it will offer what Linux will not.

Re:We need a NetBSD

[smash]

A *Freely Licensed* (copy the crap out of it *if* you want, contribute *if* you want, not like GPL), rock solid, incredibly portable, fully functional kernel/OS that will install off of a fraction of a CD. There's nothing like it,

There's FreeBSD. You can install the base system off an ~120mb install image last I checked. Granted, it's not *quite* as portable, however I would argue that this is not such a major problem these days, with x86 hardware being so cheap and giving good performance. It's "portable enough".

I'm the first to admit that I don't *like* the x86 architecture from an idealistic viewpoint, but it does the job and most of the other architectures are either becoming or actually irrelevant...

Re:We need a NetBSD

[mnmn]

Free, sure. But I dont know about lean and mean.

The whole point of NetBSD is portability. If it weren't for portability, NetBSD might as well not exist. But the problem is Linux has taken over as the portability leader and has a huge margin.

Every 32-bit cpu out there has a corresponding Linux BSP or distro. At least ones with enough ram or external bus interface. To compete, NetBSD will have to do without MMUs in some cases, and allow the kernel to be configured to be really small. Linux can scale and has enough configuration options to be able to produce a 200kb kernel and boot in under 1MB on an ARM7TDMI.

Given its license and code cleanliness (and maturity) I'd prefer NetBSD if it was portable enough. Its not.

Re:We need a NetBSD

[dbIII]

To compete, NetBSD will have to do without MMUs in some cases

uClinux and the derived DSLinux (among others) run on CPUs without a memory management unit. NetBSD probably does as well.

Re:We need a NetBSD

[sudog]

Base install for NetBSD is about 23MB, or 47MB with development tools, 55MB with manpages, and 112MB for all the above plus X.

I can get it installed on older hardware in less than 5 minutes, including the boot time for the floppies. I can get it installed on modern Opteron-based badass hardware in about half that. That's pretty cool.

And you're being very short-sighted about other architectures.

Re:We need a NetBSD

[betterunixthanunix]

NetBSD ran with no problems, out of the box, on my P5, even with X11. I have yet to find a Linux distro that competes. Only reason I use Fedora on my laptop is that it is a laptop.

Re:We need a NetBSD

[jmcneill]

NetBSD does not support CPUs without a memory management unit.

Re:We need a NetBSD

[macshit]

uClinux and the derived DSLinux (among others) run on CPUs without a memory management unit.

Note that uClinux was long ago merged into the mainstream linux 2.6 sources (in version 2.5.46 iirc). These days, the "uClinux patch" for 2.6 kernels mainly contains a few odds and ends for specific chips that haven't been merged yet.

So for many MMU-less chips, you can just grab "linux" and it will work, though if you want a 2.4-derived kernel, I guess uClinux is still necessary (2.6 can be slower and more bloated in some cases on small CPUs -- a lot of the optimization work on 2.6 seems to have focused on high-end systems).

Re:We need a NetBSD

[ElleyKitten]

A *Freely Licensed* (copy the crap out of it *if* you want, contribute *if* you want, not like GPL)

The GPL doesn't prevent or require you to copy or contribute. The GPL requires you to distribute the code with any modifications you make. If you're going to bitch about the GPL, at least bitch about things that are actually true about it.

Re:We need a NetBSD

[smash]

And you're being very short-sighted about other architectures.

Yes and no.

I'm aware of the embedded space, but personally I think that within a few years it will all be x86 anyway (much as it's a "crappy" architecture). Also, given that the costs of storage, RAM, etc are dropping extremely quickly, I don't think that worrying about 20mb vs 200-600mb is worth wasting the development time on any more.

But that's my personal opinion...

Re:We need a NetBSD

[alexdw]

I'm the first to admit that I don't *like* the x86 architecture from an idealistic viewpoint, but it does the job and most of the other architectures are either becoming or actually irrelevant...

I somehow doubt you are the first... I've often wondered what the engineers at Intel were smoking back in the seventies. Low level/assembler programming on any of the 8051/8080/8086/etc (the popular "old school" Intel processors) reveals a LOT of architectural gotchas. Memory addressing on 80x86 processors is, well, "interesting".

It is also quite interesting to note that starting with the Pentium (or was it 80486?) Intel basically threw out the oddball CISC architecture and ran the whole thing as a RISC processor with the x86 arch emulated in microcode.

I really wish one of the nicer RISC processors had really taken off, but unfortunately the 8086 model achieved critical mass (thanks M$!). You're right, though... low cost, and wide availability have been a good thing overall, even if we end up stuck with a hairy architecture. Haven't looked "under the hood" at the 64-bitters yet (too busy hacking 8051 code!), but I hope the situation has improved.

Re:We need a NetBSD

[Anonymous Coward]

I run OpenBSD on my laptop, because hey... it's OpenBSD! ;-)

Re:We need a NetBSD

[smash]

Pretty sure it was the pentium that started using the Risc core... and yeah, from my limited x86 assembly coding experience (a few half-assed games using inline assembly for quick VGA graphics back in the early-mid 90s) it's definately "strange" :)

I was so hoping for the ppc/alpha to take off myself, but alas... "worse is better" strikes again...

It's getting to the point now though that for 99.99% of the coders out there, they couldn't give a crap what a cpu is like to program from an assembly point of view, as most of them wouldn't go any lower level than C these days anyway - most of them won't even go that low...

Re:We need a NetBSD

[alexdw]

Yeah, these days, as long as the compiler supports the processor/architecture, it really doesn't matter. Even better, if you're using a truly high-level language, it all becomes irrelevant. Perl doesn't care about your architecture.

Right now, I'm working on a multiprocessor embedded project, with a DSP, an 8051 clone, and a PC/104 (x86) system for display/data logging. I used to think that the x86 architecture was bad, but after getting stuck with a couple of Harvard architecture systems, I'm loving the x86. I still miss the 6510/6502 processor; now there was a processor with character! :-)

Re:We need a NetBSD

[ElMiguel]

Given its license and code cleanliness (and maturity) I'd prefer NetBSD if it was portable enough.

From the interview:

Charles M. Hannum: [...] NetBSD today does a very poor job of setting and meeting standards. I created the mythos of NetBSD having "clean" code, and even I don't buy it any more.

FWIW I haven't read any NetBSD code so I don't have any personal opinion on it.

Re:We need a NetBSD

[TheRaven64]

I've read small amounts of kernel code from Net-, Free-, and OpenBSD, as well as Linux and this is my opinion of the four: When I read Linux code, I always end up thinking 'WTF?' FreeBSD code is a bit better, I can usually work out what it's doing (and why) quite quickly. OpenBSD code is impressive; it's almost as clear as reading English. Everything is well documented, etc. NetBSD isn't quite up to the OpenBSD standard on the microscopic scale, but it is a bit nicer at the macroscopic scale; lots of clear layers of abstraction.

As for Charles Hannum, he's pretty much a troll. Talking to a few of the NetBSD core developers, he's upset that he was marginalised five or so years ago, and has been tolling the project since then. It's also worth noting that he was one of the people primarily responsible for throwing Theo De Raadt (another of the NetBSD co-founders) out, leading him to found OpenBSD (interestingly, Theo named both NetBSD and OpenBSD). Last survey I saw showed OpenBSD having about twice the market share of NetBSD. It's a shame they kicked Theo, and not Charles, out back then.

Re:We need a NetBSD

[TCM]

Every 32-bit cpu out there has a corresponding Linux BSP or distro.

That's exactly the problem for me. Linux' "portability" consists of special cases for each architecture.

NetBSD is one source tree that you can compile on every supported arch or even cross-compile on i386[1], e.g. if your sun2 is too slow to build its own kernel let alone a complete system in reasonable time.

I can take a PCI WLAN card and put it into a Sparc with PCI slots and it runs the same driver from the same source as on i386. That's portability and it reflects in code quality. Heck, you can even cross-compile a complete NetBSD system on almost any POSIXish system. build.sh and the whole supporting infrastructure is just ingenious and a breeze to use.

Is there one single Linux distribution supporting more than 15 or 20 archs that would give me the same look and feel everywhere? I think not. It's all just special cases and hacks.

[1] i386 is the name of the architecture including the latest Athlons and Core 2 CPUs.

Re:We need a NetBSD

[Anonymous Coward]

He probably refers to the viral aspect of the GPL. You know, e.g. libraries. Your quote more reflects the LGPL.

Re:We need a NetBSD

[Anonymous Coward]

I'm aware of the embedded space, but personally I think that within a few years it will all be x86 anyway

Uh, no frigging way. ARM is just too huge there, from industrial machine controllers to telco gear to mobile phones. The mountains of code for it (accumulated expertise, investment) will keep in the embedded game for a long long time, possibly for keeps. Of the others, Freescale (nee Motorola) is pushing PowerPC more than ever, even good ole Hitachi SuperH has a presence.

Embedded apps are by nature more purpose-specific than desktop apps, there isn't such a huge need for the vast cross-compatibility of the x86 world. (Although code reuse is good, of course.) And it doesn't really matter if the VM for your PDA's cross-platform Java apps is made for a x86 or an ARM processor...

Re:We need a NetBSD

[Anonymous Coward]

I've often wondered what the engineers at Intel were smoking back in the seventies.

Yep, me too... However, the 16-bit early PC processors derive from the 8-bit 8008 which derived from the 4-bit 4004... And those days the 4004 designer team had to first sell the project (it was for a pocket calculator) to Intel's board by pointing out that making and offering a microprocessor will increase the sales of memory chips -- Intel's main breadwinner!

So, many central features in the x86 lineage originate from a hastily executed side project (the 4004) at Intel, which may go some way to explain the weirdnesses.

It is also quite interesting to note that starting with the Pentium (or was it 80486?) Intel basically threw out the oddball CISC architecture and ran the whole thing as a RISC processor with the x86 arch emulated in microcode.

Close, but not quite. It was the Pentium Pro (later Pentium II, III, and kinda also Pentium M) that begun the RISCy business, and x86 wasn't so much "emulated " as "decoded" into smaller ops.

Re:We need a NetBSD

[mnmn]

Of the 3 BSDs, I use OpenBSD the most. The FreeBSD market is the same as Linux and I just use Redhat due to support, commercial apps etc. OpenBSD is used mostly in firewalls and simpler servers that you'd like to install and forget for the next 5 years. 0 maintenance and damn secure. OpenBSD also is a standard with many technologies like the various VPN SSH and crypto technologies, and its openospf and openbgpd gives me a better feeling than quagga.

I suspect NetBSD is dead, and its core developers should work to port OpenBSD around. Maybe they can combine the functionality of FreeBSD and OpenBSD, port it everywhere and just call it 'BSD'.

I for one, only want a BSD that will run on an ARM7TDMI in 1MB flash and 1MB ram including a minimalist library and busybox. And I dont want to resort to porting minix.

Re:We need a NetBSD

[mdhoover]

The whole point of NetBSD is portability. If it weren't for portability, NetBSD might as well not exist. But the problem is Linux has taken over as the portability leader and has a huge margin.

Yes and no. Most people who make this comment should add the caveat "for 2.2.x/2.4.x series kernels with glibc 2.2.x/2.3.x w linuxthreads".

If your hardware is new and relatively common, linux kernel will most likely have a current working port.
Move off the path well travelled and you are in for a lot of strife.

My favorite 2 examples to bring up, mainly due to the massive number of units still in existence are

1. mac-m68k - last worked kernel 2.2 series, broken 2.4 and 2.6 (ADB broken, serial console broken)
2. sparc32 sun4m - currently SMP support broken in 2.6 kernels for supersparc, hypersparc just broken.

At least sun4m looks like it will get fixed, dont hold your breath for the m68k macs.

Dont get me wrong, I am a linux zealot, but linux' rate of change pretty much ensures that older architectures will drop out of the tree due to lack of maintenance, be it in kernel or glibc.
NetBSD still runs, and you can be pretty assured will continue to run, on most hardware you point it at (including your old vaxen ;-) sure beats VMS ).

Re:We need a NetBSD

[magetoo]

The whole point of NetBSD is portability. If it weren't for portability, NetBSD might as well not exist. But the problem is Linux has taken over as the portability leader and has a huge margin.

Any NetBSD advocate worth his salt will tell you there's a big difference between being easy to port, and actually having been ported. And the next point in the argument is that Linux runs on many architectures simply because there's lots of people working on porting Linux to many architectures; it's a brute-force approach, if you will; whereas NetBSD's architecture makes it easier to do the actual porting.

I can't really offer any insight myself, I've never gotten involved with anything that would require me to port an OS, or even look at the kernel code. I do run NetBSD though, and used to run Linux.

Re:We need a NetBSD

[mnmn]

NetBSD is big. Linux has more libraries at its disposal, more different set of tools (busybox being the smallest full set) and way more configurable parts of the kernel and the c libraries. You can choose the smallest scheduler or the most stable one, memory models, XIP, flash devices etc. More configurable. Thats what makes it more portable.

Re:We need a NetBSD

[magetoo]

You're probably right that it's easier to mix-and-match using Linux than NetBSD; fundamentally different goals and all that.

But you'll have to explain exactly how "more configurable" implies "more portable", because I don't see the connection. If anything, it seems to imply that Linux-based solutions would be more fragmented (if you want to use Linux on platform X, you need to use library Y and the Z tools, etc).

That looks like less portability to me -- the kernel is portable, but the userland is not, and you have to pick the right tools for your specific platform. (OTOH, that would make it more scalable; use less memory-hungry tools or more fully featured ones, whichever is the best fit.)

Or have I misread you completely? Feel free to tell me exactly how I'm wrong.

Re:We need a NetBSD

[squiggleslash]

P6, the core used in the Pentium Pro and later the Pentium II was the first to use the hybrid RISC/CISC approach. FYI.

Re:We need a NetBSD

[mnmn]

Portability to me means you can port it. It means someone gives me a set of hardware and I tell them yes I can port this to that.

In short, give me a 32-bit cpu with gcc support and I'll port 'Linux' to it. I agree that Linux will be more different from its RS6000 versions than NetBSD would be between its smallest and largest implementations. But I happen to have more in my toolbox. Just having more in the toolbox makes it tougher yet more possible to port.

Dont get me wrong, I've used NetBSD at many places and I understand and love the 'cleanliness' of BSD, the way things work as they should and the way its more rigidly standardized while one Linux can be unfairly different from another. But maybe its that flexibility that lets Linux get ported more and used in as many places from the same core sources (at least the kernel).

To answer your question, thats what I mean by 'portability'. Give me a BSD that will utilize the multiple cores of a PS3, run on a DOS file like UMSDOS on a win95 computer and will still run in 512kb ram and 512kb flash, and I'll tell you its more portable. Since NetBSD doesnt support as many devices one would expect it would be more flexible, as in run on non-MMU systems, allow XIP, scale to more processors, take less ram, compile using various compilers directly and allow kernel core structures to be swapped easily and readily like schedulers semapore structures security mechanisms etc. Under this definition, possibly unique to me, Linux is the most portable OS.

Lets face it...

[interval1066]

"We locked 10 BSD programmers in an IT room for one week with one distribution of BSD. When we came back, we found all the programmers dead with their hands around each others throats, and 12 new flavors of BSD."

So true...

Re:Lets face it...

[johansalk]

Haha. 12 flavors for 10 programmers!

Re:Lets face it...

[RAMMS EIN]

While funny, it's actually more true of Linux distros. Practically every Linux enthusiast and their cat have made their own Linux distro, whereas there are only a few flavors of BSD being actively developed. Also, each of the BSD flavors I have heard about has a pretty well-defined focus which differs from that of the other flavors, whereas with Linux distros there are scores that have the same goals and target niche.

Re:Lets face it...

[Galactic Dominator]

Pot: Kettle, you are sooooo black.

Re:Lets face it...

[interval1066]

You are of course correct. The thing about BSD however, is it claims to be homogenous. That is; its similar to Japan. Everyone in Japan speaks one language: Japanese. BSD propoents claim the same thing, more or less. If its not clear look at the history of the 'ps' command on the BSD code line.

Re:Lets face it...

[Nevyn]

While funny, it's actually more true of Linux distros.

I'd rather have the combined differences of the top 20 Linux distributions than between Linux and any of the BSDs. In the same vein the difference between any two linux distributions are almost always: 1) versions of the same upstream package. 2) preference of one upstream package over another (Ie. exim vs. postfix). The differences between any two of the BSDs are "same package name, different code/maintainers/development".

Re:All "in the family."

[smash]

I still read amusing little pro-Linux rants that are actually just pro-open source Unix userland, not pro-Linux as they believe themselves to be. Don't get me wrong, there are definite differentiators between BSD, Linux, running GNU tools on Solaris, OS X etc. but that's not the point I'm interested in here. For this discussion, I'm interested in seeing many of Unix per-se's benefits being described as Linux benefits when they are nothing of the sort.

Why, oh why can more people not see this...

Linux is a kernel (as opposed to the BSDs which include a set of integrated userland tools - not just package a bunch of independently developed GNU tools), that really, these days is nothing particularly special, other than being "free". I mean sure, certain aspects of it may be cutting edge, but for the most part they're not "must have" features that will make or break it's usage in a particular application.

As much as I think RMS is a idealist nutjob, I can see his point regarding the whole "GNU/Linux" thing here (even though simply tacking "GNU" on the front isn't fair to other developers, without which the system would be useless for certain purposes, such as xfree.org).

So what is the next Toster OS?

[Watson Ladd]

A lot of people depended on NetBSD for embeded software development. What is going to replace it? It's kind of sad to see a standard die like this.

Re:So what is the next Toster OS?

[hubertf]

sorry to bust your bubble, but have you heared anyone actually working on NetBSD say it's dying? It's thriving more than ever, and just a few people that can't get things their way propose its death. If those few people could get over their desire to get into "politics", this whole discussion would not exist.

NetBSD does live, it will live,
but it also needs people to do the work, not just talk.
Join in!

  - Hubert

Re:So what is the next Toster OS?

[Anonymous Coward]

I think that number might be quite a bit smaller than you think.

Re:So what is the next Toster OS?

[Anonymous Coward]

>NetBSD does live, it will live,
>but it also needs people to do the work, not just talk.
>Join in!

Not until the cheque from Wasabi clears.

Re:All "in the family."

[dbIII]

As much as I think RMS is a idealist nutjob, I can see his point regarding the whole "GNU/Linux" thing here

Yes - it gets him descibed as "the co-creator of linux" in computer magazines that should be better edited.

Effect of GPL "Political correctness"

[Nicolay77]

http://chris.pirillo.com/2006/09/06/vistas-ui-is-b etter-than-this/

The Kororaa Project http://kororaa.org/ had a live cd that had the Nvidia drivers included that had all this in it. It was amazing. They were forced to remove the distro though because of the GPL license.

Re:Effect of GPL "Political correctness"

[eraserewind]

Yeah, and pirated MacOSX is better than that, but they had to remove it beause of the license. If you don't like the license use something else.

Re:Effect of GPL "Political correctness"

[Brandybuck]

You don't get it. The GPL was telling Kororaa what to do with THIRD PARTY software! The NVidia driver was an *optional* *runtime* module. Kororaa is an example of GPL hyperlegalism run amok. The GPL isn't about freedom, it's about suing.

Re:Effect of GPL "Political correctness"

[vadim_t]

From wikipedia:

In May 2006 an unnamed kernel developer sent an email to Christopher Smart, the projects leader, suggesting that packaging the proprietary NVIDIA and ATI drivers was a violation of the GPL as they take GPL code from the kernel and build it into a non-GPL kernel module, qualifying as a derived work. The issue is a grey area and is yet to be resolved. Smart says that he has ceased development of the Xgl Live CD. In August 2006, Smart removed the CD image from his website

Problem here is, it's not really third party software if it takes part of the kernel sources and adds code with incompatible licensing into it. So let's see, take some Windows kernel source, add a third party driver to it, then release as say, BSD. You think the result would be very different?

Re:Effect of GPL "Political correctness"

[AJWM]

Nope, the GPL wasn't telling Kororaa what to do with 3rd party software. It was telling Kororaa what they COULDN'T do with GPL'd software. One thing they couldn't do was combine it with non-GPL'd software and distribute the result. The FSF even gives an example of how to get around this -- distribute the non-free modules on a separate disc.

(The only exception to the above is aggregations of software that are independant of each other. The original Kororaa CD was clearly dependent upon the non-Free software, so that exception doesn't apply.)

Re:Effect of GPL "Political correctness"

[Brandybuck]

You're still missing the point. The purpose of the GPL is to threaten people with lawsuits. Nobody from FreeBSD would give a shit if the NVidia driver were bundled on a CD with the kernel. But do it with a GPL kernel like Linux and suddenly people act like you're drowning kittens. Hence the distros that get shut down. Hence the lawsuit over a *free* chess program. Hence the FSF's legal enforcement division acting like Mini-Me to BSA's Doctor Evil.

Freedom is about letting people do what they will, not suing them into a narrow ethic.

Re:Effect of GPL "Political correctness"

[eraserewind]

I do get it. The kernel + module is a program, and a proprietary one. You are not allowed to distribute GPL programs that you don't own unless it's all GPL (pretty much).

If the module was a seperate executable there would be no issue. It's not however, it's a part of the kernel, and so must be GPL if you want to distribute it with the GPL kernel. You can "run" it however you like by yourself, just don't break the kernel author's copyright by distributing it outside of the terms of their chosen license.

You can distribute the module, or you can distribute the kernel, but you can't do both together in a distro because it doesn't count as "mere aggregation".

Re:Effect of GPL "Political correctness"

[vadim_t]

You're still missing the point. We know perfectly fine the restrictions the GPL imposes. We choose the GPL because we *like* those restrictions, as they impose a level playing field. IBM can't just make a closed fork of Linux, give a bunch of cash to Linus and other big developers, and leave the remains of the team wondering what the heck to do now. That's a good thing.

Yes, of course it means some opportunities will be missed that might have been available otherwise. But I think the loss of Korokaa isn't such a big price to pay. After all, look where's Linux now, and where's BSD.

Re:Effect of GPL "Political correctness"

[Nicolay77]

I use something else (duh!), but I still have the right to know this and tell everybody about it.

The point is not the repeated to death "if you don't like the license... blah, blah", but WHY I don't like the license, and why lots of people should at least know this point of view even if they disagree.

Re:Effect of GPL "Political correctness"

[AJWM]

Freedom is about letting people do what they will

Yes, and we have laws against illegal confinement, slavery, and the like to discourage people from preventing others doing what they will. The GPL is like that.

The GPL doesn't prevent anyone from getting hold of Nvidia's drivers if they want them. It does prevent NVidia from benefitting from somebody else distributing NV's proprietary drivers with free code. In other words, the intent is to discourage NVidia, but the only legal method is to discourage NVidia's unwitting accomplices.

As for lawsuits, what do you supposed FreeBSD would do about a distribution that stripped out the BSD copyright notices and disclaimers?

Re:All "in the family."

[Cal Paterson]

Oh how I wish people would call it Unix. It's a better way to be inclusive of GNU, the Linux Kernel, BSD, Xorg and every other group without having to specifically name each one.

Let's be honest, they're all big contributing factors, so why not imply them all?

What is really needed

[earthforce_1]

I am probably going to get flamed to a crisp for this, but what the heck, I have karma to burn...

If Linus continues to dig in and refuses to accept GPLV3 with its anti-DRM provisions, what is is for the linux developers who truly want to move to a GPL V3 model to contribute the fruits of their labour to a GPLV3 fork of the kernel. (Freenix anybody?) Note that they wouldn't have to stop contributing to Linux, they can dual licence as GPL V2/V3 for as long as they wish.

Actually the linux kernel could be forked from the existing code base licenced as GPLV2 with ongoing contributions to the new kernel licenced as GPLV3. Users would be bound by the terms of both licences, which would default to the more restrictive GPLV3 unless they took the time to strip out all of the newly contributed GPLV3 code. Support for DRMed media and hardware would done through clean room design, and hosted from servers in DMCA free countries. Does DVD Jon have some friends and a bit of spare bandwidth?

I really love linux, use it in my home servers and would use it on my desktop if I wasn't doing contract windows development as well. But I disagree with Linus's stand on DRM and the proposed GPLV3. RMS is an arrogant pain in the butt, but in this he is dead right. I like where GPLV3 is going, but we need to build a full featured OS around it.

Re:What is really needed

[mindtriggerz]

"Does DVD Jon have some friends and a bit of spare bandwidth?"
A bit offtopic, but DVD Jon is now living in America.

Re:What is really needed

[Gothmolly]

And you'll end up with 2 versions, 1 that people will sell and be able to use, and another that will smack of the 1.x kernel days, when USB support didn't exist, and X kind of worked if you enabled accelerated video (but often locked up the machine). Your 'freenix' may become a sort of minix replacement, but the rest of us will use Linux.

Re:What is really needed

[r00t]

DVD Jon is now living in America??? What, in prison?

Re:What is really needed

[mindtriggerz]

Nope, San Fransico. See http://nanocrew.net/2006/06/07/moved-to-san-franci sco/

Re:What is really needed

[Brandybuck]

Remember, it was Norway and Norwegian police that hauled his butt of to jail. If I were him I would have moved to the US too.

Re:What is really needed

[Anonymous Coward]

Actually the linux kernel could be forked from the existing code base licenced as GPLV2 with ongoing contributions to the new kernel licenced as GPLV3.

No it can't. GPLv2 makes explicit statements about linking object modules at the binary level (which is what happens when both the kernel is linked during compile and when modules are loaded at runtime) such that all code must be GPLv2-compatible.

A *user* could take a GPLv2-only kernel, add GPLv3-only patches (or modprobe GPLv3-only modules) and use the resulting image. (This BTW is how nVidia gets away with their driver: users have to do it themselves.) However, they would not ever be able to distribute that binary image to anyone else under any license at all. This kills mixing GPLv2 and GPLv3 since distros can't do it.

Now, in practice it won't matter if the kernel is GPLv3: glibc will most definitely move to a LGPL license that adopts the new terms (DRM and patent retaliation) of GPLv3. Since user programs require glibc, and since glibc will eventually require even Tivo-style locked machines to be able to replace /lib/libc.so and /lib/ld.so, the DRM trap will be circumventable at that level. (Unless Tivo plans to make their own version of glibc, or moves to *BSD, or decides to run their entire application as a statically-linked image that calls the Linux system calls directly.) But as others pointed out, if you really want a GPLv3 kernel, take a BSD kernel and redistribute it under GPLv3 and base a new distro off that and you're good to go. Debian could do it overnight on the FreeBSD port.

Re:What is really needed

[Millenniumman]

But as others pointed out, if you really want a GPLv3 kernel, take a BSD kernel and redistribute it under GPLv3 and base a new distro off that and you're good to go. Debian could do it overnight on the FreeBSD port.

Then you wouldn't need the GPLv3 at all. Without any hardware support, DRM isn't an issue.

Re:What is really needed

[bfields]

If Linus continues to dig in and refuses to accept GPLV3 with its anti-DRM provisions

Good grief:

1. GPLv3 isn't even finished yet. This is a little premature.
2. Linus states his opinions very clearly and forcefully. That *doesn't* mean he isn't willing to change his mind. He's done it before. BUT:
3. Even if Linus did "accept GPLV3", he doesn't own the copyright in most of the kernel himself at this point--for each piece of the code he doesn't own copyright in, somebody would have to either track down the copyright-holder (or their heirs, if necessary...) and get their permission, or rewrite their code. The kernel is really big; the chances of this happening are extremely small.

Re:What is really needed

[dbIII]

If Linus continues to dig in and refuses to accept GPLV3 with its anti-DRM provisions

Point one - it is still a draft so he would be stupid and unprofessional to accept it while it is still changing. Point two - some of the DRM clauses still need work to avoid collatoral damage to people that are helping both linux and gnu but don't want random script kiddies flashing the firmware on their embedded systems from the net becuase authentication would be illegal under a silly clause. Point three - the idea to get rid of "evil" uses of the linux kernel by Tivio and Nvidia is not seen as remotely evil by people actually in the linux (ie. kernel) development community. Linux is not a gnu project despite the name change and trying to manipulate it from outside is a good way to piss people off - as you would see from the response of Linus to somebody that demanded he use an earlier draft of GPLV3 which is what I assume you are talking about. Recall that it was a demand and not a suggestion - don't take it from me it is all still on the net. Prove me wrong if you can.

Finish writing the licence, get the bugs out of it, then flame Linus if you like. I'm not really sure a change in the licence is the way to do something that is probably better achieved by writing to your US senator (if you are worked up about this issue I have to assume you are in the USA) - remember that linux is used globally and that DRM is still mostly a US issue.

Re:What is really needed

[SEE]

Actually the linux kernel could be forked from the existing code base licenced as GPLV2 with ongoing contributions to the new kernel licenced as GPLV3.

Actually, no.

The Linux kernel is specifically licensed under GPL v2 only. Due to the deliberate design of the copyleft in the version 2 GPL, it would be illegal to distribute that code in a kernel where portions of the kernel could not be redistributed under the terms of the GPL v2. The inability of GPL v2 code to be put under a more restrictive license without permission of the copyright holder is a deliberate, designed-in feature, and no FSF backdoor exists.

That means, all the "GPL v3" code in your "forked" kernel would either have to include specific permission to be used under the GPL v2, or none of it could be the current GPL v2 Linux kernel code. In the first case, then, anybody could grab any of the code from your "fork" and distribute it under the v2 only, defeating the whole point of forking a project to add v3 DRM restrictions. In the second, you wouldn't be forking Linux, you'd just be writing a new kernel.

You want a GPL v3 GNU kernel? You can start with HURD, or with one of the nonproprietary BSDs (4.4 Lite, Free, Net, Open), or a few more obscure things. But you can't start with Linux if Linus says no, because the FSF set up the GPL v2 that way.

Re:What is really needed

[Danathar]

True, that could happen. But they (the owners of the fork) could'nt call it "Linux" as Linus has that tradmarked.

Re:What is really needed

[Anonymous Coward]

Strange... isn't that exactly what the BSD folks said about Linux back then?

Re:All "in the family."

[tius]

Hmmmm, what sort of blind insults should lay way at you with???? Well, lets skip that, but really, grow up. NetBSD has a very import role in supporting non-homogenios arrays of systems. I would note that for me, that has been the central strenght amonstg many other that have kept me on the netbsd trail. Twat.

GPLv3 OS

[r00t]

You can't convert Linux. GPLv2 and GPLv3 both prohibit extra restrictions.

You could create a GPLv3 fork of NetBSD though. That might revive NetBSD. You might just take the kernel though, letting distributions form around it. Debian already supports Hurd and FreeBSD kernels; they could do a NetBSD one as well.

Of course you'd need to find a name other than "NetBSD".

Ideas: NetOS, NotBSD, Netix, Netrix, Netux, Nettle, WebBSD...

Re:GPLv3 OS

[kv9]

Debian already supports Hurd and FreeBSD kernels; they could do a NetBSD one as well.

http://www.debian.org/ports/netbsd/

Re:GPLv3 OS

[Monsuco]

Doesn't NetBSD still use the old "advertising clause?" In that case it is not compatable. Why not use FreeBSD instead? Well, the biggest issue with this is people "know" what linux is. People don't know BSD as well. We can't just call it "Linux" as that name is trademarked. Loosing the word linux is actually a huge loss for the GNU project. It might be easier to just relicense everything else besides the kernel under GPL 3. How important is the license of the kernel if the rest of the OS is GPL 3. RMS may be a bit overzelous when it comes to FOSS, but he is certainly right on DRM. It cannot be tolerated.

Re:GPLv3 OS

[Breakfast Pants]

It is worth noting that it has been speculated that the only reason for the introduction of the absurd GPLv3 is that Linux won't be able to convert to it, but Hurd will since the FSF demands copyrights to everything. It is Hurd's only chance in hell, and, if true, it is a dirty move.

Re:GPLv3 OS

[obirt]

You could create a GPLv3 fork of NetBSD though. That might revive NetBSD. You might just take the kernel though, letting distributions form around it. Debian already supports Hurd and FreeBSD kernels; they could do a NetBSD one as well.

They already started. There's a debian userland with NetBSD kernel and NetBSD userland with a debian kernel in the works. It hasn't been updated in a while but the project tree is still there: Debian NetBSD.

Linus == Linux

[fm6]

As we've seen over the years, one of the great successes of Linux was that it had a strong leader, who set goals and directions, and was able to get people to do what he wanted -- or find someone else to do it. This latter part is also a key element; there was no sense that anyone else "owned" a piece of Linux (although de facto "ownership" has happened in some parts); if you didn't produce, Linus would use someone else's code. If you wanted people to use your stuff, you had to keep moving.

Which is something to respond next time you hear some GNU dweeb insist that Linux be called GNU/Linux. So GNU contributed a lot of code. So did a lot of other people. LT's leadership is what made it happen. All the more absurd because the GNU OS has been "almost done" for decades.

Re:Linus == Linux

[LordLucless]

Linus' leadership had nothing to do with making the GNU tools "happen". They happened all by themselves, and had happened before Linux was developed. What Linux did is actually give them a platform to be used on; before Linux they were really just open-source versions of stuff that other OSes often already had. Without Linux, the GNU tools were superfluous. Without the GNU tools, Linux was just a barebones kernel; you need tools to actually do anything useful with it.

That said, I think the constant attempt to change an already-entrenched name is futile. I can understand why someone would get irritated when people in ignorance assign all the hardwork they did to someone else.

Re:All "in the family."

[Millenniumman]

What you pointed out is exactly why "GNU/Linux" is ridiculous. The GNU utilities are very important, but many others are equally important to desktop linux. Are we going to call it Ubuntu Debian/GNOME/xorg/Mozilla/Trolltech/OO.o/apache/.. ./GNU/Linux? PHBs would fall asleep before IT had even finished naming it. Linux is a good name and easily imparts what kind of OS a distribution is. Beyond that, the name of a distribution indicates all of the parts other than Linux. You can't really have Debian Linux without GNU, etc. You can have it on a different kernel.

Re:All "in the family."

[setagllib]

Unix is a trademark - you can't name things Unix (not even UNIX as it should be) willy-nilly. We just need a new term, and Linux seems to have become a blanket term for "libre Unix workalike or derivative" which is offensive to those who dislike Linux but, really, doesn't make even a tiny difference to the masses of clueless users who wouldn't even be able to tell the systems apart, as long as they're not Windows or OSX which everyone knows.

In fact, the end users wouldn't even care what base system it's on, with things like KDE and GNOME appearing and being nothing like real Unix, just happening to run on compatible systems. And a lot of the "Linux software" is being ported to even run on Windows, which is about as compatible with Linux and glibc as day and 1. Even MPlayer, originally called "The Media Player for Linux", now runs on practically everything (and crawls on everything else).

Re: Successful?

[Anonymous Coward]

No it's famous because nothing else can touch it when it comes to security and firewalls. It's also famous because the asshole[sic] Theo is a non-compromising sonabitch who doesn't take shit from hardware vendors or accept crap code or bad licenses into the CVS tree. And for that, I'm very very grateful.

Re:All "in the family."

[CeramicNuts]

perhaps it should be called the 'obnoxius' GNU advertising clause?

Soon you'll be a user of DragonFly BSD.

[Anonymous Coward]

DragonFly BSD is very well known in the BSD community. You'll probably hear far more about it soon, since it is completely clear today that we'll soon be dealing with multicore and multiprocessor systems in basically all PCs. DragonFly BSD is a redesign and reimplementation of the FreeBSD kernel and userland libraries from the bottom up, with the main goal being for it to scale very well on multicore and multiprocessor systems.

So while FreeBSD, NetBSD and OpenBSD will still be working on getting their kernel sufficiently threaded for many years to come, DragonFly BSD will have had that task completed for a while. And it will likely become apparent that it is the only one of the BSDs that will scale on the massively multicore and multiprocessor consumer-grade hardware of the near future. Reportedly, it has become better than Irix at many tasks, and is even beginning to rival Solaris. With Irix still trumping Linux in most cases, this goes to show how far ahead DragonFly BSD already is. Keep in mind that DragonFly BSD is still under very heavy development.

And no, OpenBSD is not famous because of Theo's attitude or reputation. OpenBSD is famous because it is one of the most secure operating systems out there for commodity hardware. OpenBSD is famouse because of the efforts of its developers to remove insecure and faulty code from not only the kernel and system utilities, but also from third-party software like Apache.

Re:Soon you'll be a user of DragonFly BSD.

[Lost Found]

DragonFly BSD is a redesign and reimplementation of the FreeBSD kernel and userland libraries from the bottom up, with the main goal being for it to scale very well on multicore and multiprocessor systems.

Redesign and reimplementation seems to imply starting from scratch. This doesn't seem to be the case for DragonflyBSD.

So while FreeBSD, NetBSD and OpenBSD will still be working on getting their kernel sufficiently threaded for many years to come, DragonFly BSD will have had that task completed for a while.

DragonflyBSD has the development resources necessary to redesign and reimplement the FreeBSD kernel, *and* get their kernel "threaded" faster than the other BSD projects already working hard on that task?

Pardon me, but I don't think your description makes much sense, and it doesn't sound like you know anything about operating system scalability. In a monolithic kernel design like Linux, FreeBSD, NetBSD, OpenBSD or DragonflyBSD, "threads" are largely a user-space concept. Sure, you have kernel threads to run specialized tasks, but the bulk of the performance critical code runs "on top of" or "on behalf of" user tasks. This differs from a microkernel implementation where the kernel is really broken down into multiple threads that pass messages (even then, however, certain kernel functions like memory management and process scheduling must be centralized.)

In reality, the real effort of creating better scalability centers on implementation of finer-grained locking and faster data structures, so that the locks aren't as contended as they once were.

Reportedly, it has become better than Irix at many tasks, and is even beginning to rival Solaris. With Irix still trumping Linux in most cases, this goes to show how far ahead DragonFly BSD already is.

DragonflyBSD is interesting, but I don't think you should be making claims like this without providing verifiable data. Do you have any references?

Re:Soon you'll be a user of DragonFly BSD.

[10Ghz]

And it will likely become apparent that it is the only one of the BSDs that will scale on the massively multicore and multiprocessor consumer-grade hardware of the near future. Reportedly, it has become better than Irix at many tasks, and is even beginning to rival Solaris. With Irix still trumping Linux in most cases, this goes to show how far ahead DragonFly BSD already is.

Linux was up & running on 128-way SGI Origin Supercomputers back in 2001. Today, the kernel that you get from kernel.org works with 512-way systems. So what are these "consumer-grade" system you talk about? Quad-core machines? Linux works on those just fine. Hell, since Linux works OOB with 512 CPU's, I don't think that there will be any issues with "consumer-grade" multicore-systems. And, FWIW, just few months ago Linux added support for Sparc T1, Sun's multicore & multithreaded CPU.

So what are these advantages Dragonfly has over Linux? You claim that it scales better with cores and CPU's. I dispute that claim. Please show some raw data to back up your claim. How many CPU's has Dragonfly been tested with? If you want to see the number of CPU's Linux can work with, take a look at the fastest supercomputers in the world. Those systems have thousands of CPU's, and they usually run Linux. Are you saying that Dragonfly is even better? Prove it.

Re:Soon you'll be a user of DragonFly BSD.

[Anonymous Coward]

Redesign and reimplementation seems to imply starting from scratch. This doesn't seem to be the case for DragonflyBSD.

There's no such implication. They have written a vast amount of new code. But they're doing it incrementally, subsystem by subsystem, within the confines of what was the FreeBSD 4.8 kernel and userland. What they have now is vastly different than what FreeBSD has now, even though both were derived from the same sources.

DragonflyBSD has the development resources necessary to redesign and reimplement the FreeBSD kernel, *and* get their kernel "threaded" faster than the other BSD projects already working hard on that task?

DragonFly BSD has Matt Dillon. If you don't know about his software development achievements for the Amiga and FreeBSD, go do some research and find out about them. Along with Jordan Hubbard, Matt Dillon was the premiere FreeBSD developer. He developed most of the FreeBSD VM subsystem, for instance. He has the capabilities of five to ten average developers. And that is why DragonFly BSD has been so successful in so little time.

DragonflyBSD is interesting, but I don't think you should be making claims like this without providing verifiable data. Do you have any references?

I do, but unfortunately I do not think I can publish the exact details at this moment. I work at a fairly large web hosting company, and traditionally we have relied on a small number of mid-level Sun and SGI systems. We recently found that a dual single-core processor Opteron system running DragonFly BSD was only slightly less capable than our 8-way SGI system. We have an in-house Irix expert, who has been using it since the time of the Indigo, so we doubt that configuration problems were at play. The same Opteron machine running Linux and FreeBSD was unable to match even half of the level of performance of the SGI machine, even after heavy tuning by multiple technicians. It's not a quality scientific study by any means, but we are seeing results that would indicate that DragonFly BSD can play with the big boys, and is getting very close to beating them silly, even though it is still under heavy development.

Re:Soon you'll be a user of DragonFly BSD.

[toadlife]

"Quad-core machines? Linux works on those just fine."

Now if Linux could only keep time on those systems without stupid kernel tweaks, or grub boot loader switches, it might be worth a shit.

Re:Soon you'll be a user of DragonFly BSD.

[Anonymous Coward]

It does that just fine. Next.

Re:Soon you'll be a user of DragonFly BSD.

[magetoo]

DragonFly BSD has Matt Dillon. [...] He has the capabilities of five to ten average developers. And that is why DragonFly BSD has been so successful in so little time.

This sounds like obvious fanboyism, of course. But having lurked on the DFBSD mailing lists for a while, I can tell that it doesn't seem to be that far off. It's pretty amazing seeing someone someone reporting a faily obscure kernel bug in one post, and then Dillon posting a patch fixing it in the very next one. And from my perspective, apparently major rewrites of kernel subsystems sometimes have seemed to move impossibly fast.

Of course, I'm not in a position to accurately judge everything that goes on, since I really don't know enough about the internals of the kernel, so take it with a grain of salt, etc.

I'm sure that being in the position of being able to hack on his hobby project full time doesn't hurt either, of course.

One thing is for sure: from a NetBSD user's perspective, DragonFly is looking better and better all the time. Now if it would only run on Xen too...

Re:Soon you'll be a user of DragonFly BSD.

[Eivind Eklund]

Pardon me, but I don't think your description makes much sense, and it doesn't sound like you know anything about operating system scalability. In a monolithic kernel design like Linux, FreeBSD, NetBSD, OpenBSD or DragonflyBSD, "threads" are largely a user-space concept. Sure, you have kernel threads to run specialized tasks, but the bulk of the performance critical code runs "on top of" or "on behalf of" user tasks. This differs from a microkernel implementation where the kernel is really broken down into multiple threads that pass messages (even then, however, certain kernel functions like memory management and process scheduling must be centralized.)

DragonflyBSD is a message passing/microkernel refactor of FreeBSD, using kernel threads for "everything".

And DragonflyBSD could definately get better SMP support faster than FreeBSD, and I would expect NetBSD and OpenBSD. Dragonfly had (and to a degree has) the luxury of not having that many users and developers, and being able to mess up things and fix them again. FreeBSD has much less of that privilege, and as a such development speed is slower. (There's also much more communication overhead in FreeBSD, and "competing" internal projects.)

Eivind.

Re:Soon you'll be a user of DragonFly BSD.

[Eivind Eklund]

Matt is a very, very good programmer. (I've worked with him on FreeBSD, and have thought of dropping by Dragonfly.)

Eivind.

Re:All "in the family."

[smash]

Oh don't get me wrong, I don't call it "GNU/Linux" and I agree it's ridiculous really.

However, calling the operating system "Linux" is not really being truthful either.

There's a lack of a term for describing what it really is ("Linux kernel + free stuff" doesn't have much of a ring to it :D), unless you use a distribution name, i.e., Redhat or Debian, etc.

Oh my...

[Lost Found]

Good lord, the meme about X-Windows needing to be replaced is really obnoxious. I honestly thought that when Compiz, XGL and AIGLX startd to appear, fools parroting this tired meme would finally be put to rest.

X-Windows is in many ways archaic, but under the lead of the X.Org project there has been an astounding increase in the rate of development. The project has finally been modularized and the groundwork is in place for direct access to acceleration features. Honestly, the biggest thing holding back X-Windows from even faster modernization right now is the manufacturers of graphics hardware (NVIDIA and ATI) that are ridiculous enough to not even release programming specifications for their chips. Their "support" of the free operating systems is limited to shitty binary drivers, and so when the X-Windows and kernel communities want to introduce new APIs, they are largely at the whims of the moron companies that haven't gotten around to pulling their heads out of their asses yet.

If you believe that UNIX with X-Windows on top of it is not suitable for the average user, you should provide some facts to back up that opinion. Because as every day passes, I've seen all the arguments get displaced by proof of concept and running code.

Finally, what Apple did with OS X indicates just what is wrong with the BSD license. The coders and users that believe in the BSD license have been shown time and time again that the so-called benefits of the license are actually damaging to their projects. Charles Hannum from NetBSD recognized this recently when he talked about NetBSD's stagnation, and aptly characterized part of the problem as the BSD license that allowed companies to fork BSD and hire away all the important developers to work on their proprietary forks. Charles now says that he would have used the LGPL license if he were to do it again, which is exactly what the Wine project did after Transgaming and others ran off with their code and developers.

So this issue of licensing that you describe as making BSD the biggest threat to the proprietary interests is wrong. The BSD license's shortcomings in this area mean that BSD will continue to go nowhere fast. The reason that the BSD lawsuits were more scary was because the free BSDs actually had lineage leading back to the old proprietary (owned) code. The reason the SCO lawsuit is not scary, and rather actually hilarious, is because Linux was (a) developed in a vacuum and (b) is defended by the GPL.

The GPL is very important here, because it creates a safe haven for companies like IBM, SGI, Oracle, Red Hat, Novell, HP, Nortel and others to all cooperate on *one* core. When all of this engineering talent and financial power gets pooled into one project, that one project goes a long ways. And tossing its technical superiority totally aside, you're left with the actual *largest* threat to the proprietary interests - an entire cultural, economic, political and technical shift in thinking from proprietary development to Copyleft.

The BSD project and license followers have been operating with their heads in the sand for a very long time now. Even when the FOUNDER of one of the most significant free BSD efforts came out and said "We fucked up, and here's why," there were still a thousand BSD fans that chose to ignore the majority of the issues he raised, instead babbling on topics like "Theo is finally vindicated!". Given history, I don't expect this to change. There will always be BSD users with their heads buried in the sand, but their numbers are shrinking as they fail to see the train tracks being built directly in their path.

Re:Oh my...

[Millenniumman]

Apple has contributed a lot to open source software. BSD has won in the arrangement. Maybe .00000001% of Mac users would otherwise be running FreeBSD if OS X had not come around.

The choice between BSD and GPL reflects what a developer wants. If they want others to help with their software and want rights to all derivatives of their software, they choose GPL. If they just want to share what they make, they choose BSD.

I don't think that GPL software will make it to the majority of users' desktops. It is just too hard to make profit from Desktop Linux. Unlike a server, support for a Desktop OS can't be worth enough to make enough money to develop the software, or it won't ever sell.

Now, I'm well aware that interested developers will make good software without monetary incentive. But they will make it for themselves. OSS relies on developers interested in it. Paid software relies on consumers paying money to buy the OS. Competition means that it has to improve from a user's perspective. Since Microsoft has no competition, it isn't very good in many respects.

The best thing for software is not Free Software. It would be a "monopoly" on open standards, and many competing standardized OSes.

Re:Oh my...

[dfghjk]

"...they are largely at the whims of the moron companies that haven't gotten around to pulling their heads out of their asses yet."

Curious that you blame that hardware companies and not X. Why should hardware companies feel obligated to support GPLed software?

"If you believe that UNIX with X-Windows on top of it is not suitable for the average user, you should provide some facts to back up that opinion. Because as every day passes, I've seen all the arguments get displaced by proof of concept and running code."

Documentation of that opinion appears regularly and it take far more than "proof of concept" to make a platform "suitable for the average user".

"Finally, what Apple did with OS X indicates just what is wrong with the BSD license."

Acutally it proves what's right with it. Apple used BSD code precisely in the manner that BSD people would like.

"...which is exactly what the Wine project did after Transgaming and others ran off with their code and developers."

They didn't run off with the code. The WINE project still had the code afterward. As for the developers, perhaps the WINE project wasn't appealing enough to hold on to its team.

"The BSD license's shortcomings in this area mean that BSD will continue to go nowhere fast."

There are multiple BSD projects and they are going how they want them to be.

"When all of this engineering talent and financial power gets pooled into one project, that one project goes a long ways."

Sure, but that's not atributable to the GPL.

"...tossing its technical superiority totally aside..."

you don't know much about linux, do you?

"The BSD project and license followers have been operating with their heads in the sand for a very long time now."

No they haven't.

"...there were still a thousand BSD fans that chose to ignore the majority of the issues he raised..."

or not agree with them.

"Given history, I don't expect this to change."

Neither do I. It doesn't need to.

"There will always be BSD users with their heads buried in the sand..."

sure, just like there will always be Linux users in a similar mindset.

Re:Oh my...

[s_p_oneil]

Oh, please. It's a lot less obnoxious than your preaching of the GPL and griping about ATI and nVidia not releasing specs or source code for their drivers. They shouldn't have to release them any more than other companies should be allowed to steal GPL'ed code. (From what I've read, I believe even Linus agrees with that.) Linux wouldn't be a even fraction as popular as it is today if ATI and nVidia hadn't graced it with their "shitty binary drivers", and it's still not very popular among average users.

I've used MS Windows, Linux, and BSD, and I'm not a fan of any of them. I haven't spent much time with OS/X because I've never cared to buy a Mac. If they'll let it run on any of the machines I already have, I may give it a try. I didn't say that BSD's licensing made it a threat to proprietary interests in general. I don't think a general threat to proprietary interests is a good thing, and neither do those companies you mentioned like IBM, SGI, Oracle, Red Hat, Novell, HP, Nortel, and others. Is Oracle open-source? What about DB2? I've used both of those, and their binaries are generally a lot shittier than nVidia's or ATI's. For some companies, BSD serves their proprietary interests extremely well. For other companies, it is a danger. It gives smaller companies a head-start and helps them compete against more well-established companies, which I do think is a good thing.

Oh, and I'm certain that Linux and X Windows are improving, and that's great, but they've been improving for several years, and they're still not ready for average users. Correction, I think Linux and BSD have been ready for years, but X Windows has been holding them back. You want facts to back that up? How about the low adoption rate by average users? How about the number of average users I've talked to that gave Linux a try, only to give up and go back to MS? These people didn't know or care about what's going on under the covers of the OS, they only saw the windowing system that was presented to them, and they got frustrated with it very quickly.

I've recently tried the current releases of Fedora and FreeBSD, and I was still frustrated by X on both systems. Are you going to tell me I need to download and compile more recent source code, or use a different distro, and still claim that it's ready for "average" users today? Also, XGL and Compiz do not look like a step forward to me. If they're anything like Vista's new 3D interface, they look like a step backward. Keeping the graphics card in 3D mode all the time, the laptops that can run it at a decent rate will have their batteries drained so fast that users will think something is broken (and laptop sales are growing faster than desktop sales). It will be a pain for desktop systems too, as electricity is not getting any cheaper, and most 3D cards have annoyingly loud fans kick in for 3D mode.

X Windows doesn't need extra flash, it needs to fix its consistency and ease-of-use issues. From what I know about X Windows and applications, I think it may be easier to start from scratch. If you make it easy enough for my wife to use without bitching at me about it, I will happily concede defeat. Until then, my gripe about X Windows is very real and legitimate.

Re:Oh my...

[Lost Found]

Apple has contributed a lot to open source software. BSD has won in the arrangement.

What exactly has BSD won? Just recently, Apple decided to close up XNU. Granted, I'm now hearing that they have changed their mind again, but doesn't that seem like any possible benefit to BSD is totally at the whims of Apple?

The choice between BSD and GPL reflects what a developer wants. If they want others to help with their software and want rights to all derivatives of their software, they choose GPL. If they just want to share what they make, they choose BSD.

You imply that BSD has a monopoly on sharing. Ironically, the difference between the BSD license and the GPL license is all about sharing, and in exactly the opposite way that supporters of the BSD license love to imply.

The GPL gets torn down by such folks as if it is some kind of false freedom. In truth, the GPL license lets you use the GPL licensed works in any damn way you please; in fact, you don't even have to accept the GPL license to use GPL'ed software!

The difference between the BSD and GPL license, then, is what happens when you want to copy the software. GPL looks out for the actual _users_ of the software by ensuring that the software will always remain free. The BSD license, on the other had, allows proprietary forks that _hurt_ the users. Mr. Hannum even pointed this out when he talked about NetBSD developers getting hired away to work on a proprietary NetBSD fork! He sees this as a big problem, so do I, and so does Stallman, which is why the GPL is designed to prohibit individuals and corporations from taking the freedom away.

I don't think that GPL software will make it to the majority of users' desktops. It is just too hard to make profit from Desktop Linux. Unlike a server, support for a Desktop OS can't be worth enough to make enough money to develop the software, or it won't ever sell.

Good thing the free software properties of the GPL and copyleft that defend the GNU/Linux desktop mean that most of the components are the same exact components as running on all those servers, where paid support is plentiful!

Your big error is in starting with the assumption that there Must Be a business of selling desktop operating systems. Personally I think it is plainly obvious that free software will displace that entire business. That is not the goal of free software, but it will happen anyway.

Desktop users don't buy operating systems -- they buy computers.

Re:Oh my...

[Lost Found]

Oh, please. It's a lot less obnoxious than your preaching of the GPL and griping about ATI and nVidia not releasing specs or source code for their drivers. They shouldn't have to release them any more than other companies should be allowed to steal GPL'ed code. (From what I've read, I believe even Linus agrees with that.) Linux wouldn't be a even fraction as popular as it is today if ATI and nVidia hadn't graced it with their "shitty binary drivers", and it's still not very popular among average users.

I'm griping about specs, not source code. There was a time that when you bought something, it came with full schematics. Nowadays the business world seems to want to lock that all away from the end user in the interest of chasing the almighty Dollar. A thriving rate of technical development (and indeed, even competition!) depends on open standards and open specs. When proprietary interests get mixed in beyond the point of healthy balance, the users are the ones who lose.

For some companies, BSD serves their proprietary interests extremely well. For other companies, it is a danger. It gives smaller companies a head-start and helps them compete against more well-established companies, which I do think is a good thing.

Are you saying this because Apple was able to use BSD in the development of a desktop operating system?

What BSD zealots seem to misunderstand is that the GPL doesn't prevent anyone from making money off that code, or using it to build other systems. It merely enforces a collaboration and an equal playing field.

If you think BSD has a monopoly on giving companies a leg up in developing new products, what do you think Novell is doing?

[stuff about X Windows and "3D mode"]

Doing things in 2d is dying off. Microsoft sees this, Apple sees this, X.Org sees this. The fact of the matter is that the cost of including 3d support is going down, and since the 2d stuff can be done with the 3d stuff, the 2d stuff is getting pushed off the chip. Sooner or later we'll have hardware where there is no 2d support at all.

Modern processors don't have a big "On/Off" switch for whole areas of functionality; rather, they can actually swing in and out of various states of activation depending on load. This means that your story about "3D mode", loud fans and power consumption is false. Desktops with minor 3d effects just don't place the kind of load on those chips that 3d games do.

Re:Oh my...

[Lost Found]

Curious that you blame that hardware companies and not X. Why should hardware companies feel obligated to support GPLed software?

They shouldn't have to; rather, they should just go back to releasing specifications to their customers like they used to. I think there are plenty of people in the BSD community that would agree with me on this, especially Theo.

Documentation of that opinion appears regularly and it take far more than "proof of concept" to make a platform "suitable for the average user".

You've made an attempt to totally dodge my question.

Acutally it proves what's right with it. Apple used BSD code precisely in the manner that BSD people would like.

That does nothing to address my point, which is that forks of this nature are bad. Whether or not the BSD developers themselves intended to allow that is a different issue.

They didn't run off with the code. The WINE project still had the code afterward. As for the developers, perhaps the WINE project wasn't appealing enough to hold on to its team.

Nice try twisting my words. Curious - did you even read what Mr. Hannum had to say about this problem of proprietary forks? I think the more relevant example isn't WINE but NetBSD. Wasabi Systems forked NetBSD and hired away good NetBSD people to work on their fork. Mr. Hannum, a NetBSD founder, said that did damage to NetBSD.

There are multiple BSD projects and they are going how they want them to be.

Apparently not, or we wouldn't have one of the three most prominent projects firing eight core developers after one of the founders decides to go public with his frustrations and analysis of why they have failed!

Sure, but that's not atributable to the GPL.

It absolutely is attributable to the GPL. The GPL creates a level playing field where no one party's contributions can be used unfairly against them. Why do you think that Linux, and GPL code in general, has such a huge level of corporate support, while BSD has virtually none?

you don't know much about linux, do you?

This is exactly what I mean about BSD zealots buring their heads in the sand. Wake up, it's 2006! Linux is faster, more portable and has more features than any BSD. Linux runs on everything from cell phones to supercomputers. Pretending that this is not true is asinine.

If portability, functionality and performance aren't big components of technical superiority, what do you suppose is?

Re:Oh my...

[TheRaven64]

What exactly has BSD won?

Grep the FreeBSD commit logs for @apple, and you'll see. Apple have given a lot of code back to FreeBSD. So have Yahoo, who employ (as I recall) six developers to work full time on FreeBSD. Unlike IBM and Linux, they don't feel the need to issue press releases about it. Actually, in Apple's case, it's in their best interests to keep it fairly quiet; they wouldn't want the average customer to think that they could use FreeBSD for free rather than OS X.

Just recently, Apple decided to close up XNU.

And this is when I stopped reading your post. Please check your facts. Apple delayed releasing the x86 version for a while, but they are still committed to keeping XNU as open as it has ever been.

Re:Oh my...

[Anonymous Coward]

What exactly has BSD won? Just recently, Apple decided to close up XNU. Granted, I'm now hearing that they have changed their mind again, but doesn't that seem like any possible benefit to BSD is totally at the whims of Apple?
No, you're just at the whims of bad journalism. Apple never "decided to close up XNU"; they just took longer than expected to publish the x86 version after Intel-based Macs were released, because they had to audit the code and split off a few parts which could not be open sourced (drivers depending on third-party proprietary code, and the kernel support for tying the closed-source OS X GUI to Apple's hardware) into a small collection of closed-source extensions, distributed separately. Once this was done, the sources for XNU on x86 were released.

Again, there was never a decision to make the kernel closed-source, just a lack of communication while the sources were being prepared for release, which sensationalist journalism turned into "XNU goes closed source OMGZ".

As for what Apple has provided, apart from making the entire core OS (Darwin) open-source, they released a lot of their own original work, such as IOKit, launchd, ZeroConf, CoreFoundation, etc.

Re:Oh my...

[stsp]

Grep the FreeBSD commit logs for @apple, and you'll see. Apple have given a lot of code back to FreeBSD.

Interestingly, grepping the FreeBSD source tree itself for '@apple' shows a lot of hits in GPL licensed parts of the tree, such as binutils, gcc and gdb.
Now let's look at the BSD-licensed core parts:

[stsp@ted /usr/src]$ grep -r '@apple' sys sbin bin usr.bin usr.sbin lib
sys/net/bpf.h: * <dieter@apple.com>. The header that's presented is an Ethernet-like
[stsp@ted /usr/src]$

Now, I'm too lazy to run cvs log and do the grep there. But I sure hope that I would get more than one hit...

Re:Oh my...

[s_p_oneil]

Modern processors don't have a big "On/Off" switch for whole areas of functionality; rather, they can actually swing in and out of various states of activation depending on load. This means that your story about "3D mode", loud fans and power consumption is false. Desktops with minor 3d effects just don't place the kind of load on those chips that 3d games do.

Where graphics cards are concerned, you're dead wrong about that. They do have a big on/off switch for 3D mode. And in 3D mode, they pull out all the stops and try to run as fast as they can. As a graphics/game developer, I know a good bit about it. I've read of a number of indie games that had to add enforced sleeps into their code because they didn't tax the CPU enough, causing the latest video cards (i.e. GeForce 7800 Ultra) to run too fast in 3D mode, causing the cards to overheat and lock up. The fans have gotten quieter since the GeForce FX days (which were horrible), but they can still be quite loud and annoying.

Re:Oh my...

[Millenniumman]

No one can take your "freedom" with the BSD license. Code released as BSD is freely available forever. People can use the code in proprietary works, but I fail to see how that hurts the users any more than Bill Gates not giving them a truck full of money hurts them.

Desktop users don't buy OSes, but if their computer is running Linux and "won't work with their monitor", they will return it and tell other people not to buy a penguin computer.

It takes a lot of work to develop an OS. A hardware manufacturers is not going to do that, and then give it away to all of the other hardware manufacturers. OSS software groups won't make it user friendly enough. You're right, that OSS already has the server components, but that doesn't directly impact the user experience.

I have no problem with the GPL. If a developer wants access to all derivative works of his software, the GPL is great. But if the developer just wants to share it with everyone, BSD is better.

Re:Oh my...

[dfghjk]

"They shouldn't have to; rather, they should just go back to releasing specifications to their customers like they used to."

That would be supporting GPLed software now, wouldn't it? These companies don't release specs because they don't want to document their designs for their competitors. It's universal in that particular business.

"You've made an attempt to totally dodge my question."

No I didn't. I just pointed out that what you request is offered all the time and a quick search will show that. I have no interest in taking up that argument myself but others are and you suggest they don't exist.

"That does nothing to address my point, which is that forks of this nature are bad."

Except that it is your opinion and it is not shared by some notable others (specifically the BSD team). You are holding them up as an example of why it's bad when they fundamentally disagree with you. The BSD teams are doing exactly what they want and their work is getting used in the manner that pleases them. You say it's bad but they are perfectly happy with it. OS X is an example of goodness in their mind, just not in yours.

"Nice try twisting my words."

Your words are twisted to begin with. When open source code is used in a new project, whether is taken in part or forked in its entirety, it is being used in the spirit of which it is offered. As a developer of GPLed or BSDed software, you are specifically offering your work for free and encouraging others to use it and that includes forking. If someone doesn't want their code to be forked, they shouldn't release it under an open source license. Forking is an inherent part of the process and sometimes natural selection hurts some developers.

My comments stand on their own merit. People like you suggest that code is taken and that somehow harms it, but code that is reused is still available under its original license. That's true for BSD and for GPL and that's why the GPL's claim that it alone ensures code freedom is a lie. All open source licenses, including BSD, ensure freedom for the code they license. I chose to address your comment because your language ("run off with the code") is specifically the kind of statement that perpetuates that myth. As far as developers being taken, they wouldn't be if their current work is of sufficient interest to them. That's also part of the process.

"...Mr. Hannum, a NetBSD founder, said that did damage to NetBSD."

Yes, forking damages projects from time to time. Some of those damaged projects are GPLed ones and the GPL itself does nothing to discourage forking or the taking of developers for new projects.

"The GPL creates a level playing field where no one party's contributions can be used unfairly against them."

That's just nonsense. BSD code isn't used unfairly against the BSD community. BSD *wants* its code to be used and they don't care if the usage is commercial or not. Just because one contributor now has regrets doesn't mean that the entire BSD community has had a change of heart.

"Why do you think that Linux, and GPL code in general, has such a huge level of corporate support, while BSD has virtually none?"

Momentum. Had Linux not existed then BSD may well have that kind of support, and if BSD hadn't been engaged in lawsuits at one time Linux may well not exist today. I'm pretty sure that Linus wouldn't attribute the success of Linux to the GPL as you do. Linux is not a GPL zealot.

"This is exactly what I mean about BSD zealots buring their heads in the sand. Wake up, it's 2006! Linux is faster, more portable and has more features than any BSD. Linux runs on everything from cell phones to supercomputers. Pretending that this is not true is asinine."

You said Linux was technically superior and I took issue with that. First off I'm not a BSD zealot; you just assume so because I disagree with you. I do not run BSD because I have no need but I do run Linux when it suits my work. Second, I am an embedded systems

Re:Oh my...

[Lost Found]

OK, perhaps so. I'm not a game developer, I've just assumed that the 3D guys would have adopted basic power management techniques by now. If they have not, it's not going to be very long before they do, because of the exact reasons you cite.

Re:Oh my...

[Lost Found]

There is more to every story than you might think. If Apple is now pretending that their "delayed" release of x86 XNU was due to miscommunication or preparation, that's called "public relations" not "truth".

Re:Oh my...

[s_p_oneil]

Trust me, I'll be very happy when they do that, but they're not there yet. And even if they do it relatively soon, it will be a few years before "almost everyone" has one.

Re:Oh my...

[Alomex]

How can you tell a Unix guru apart from a wannabe? The unix guru positively knows that X sucks, but gives in to it in the name for backward compatibility, the wannabe thinks X is good, 'cuz it belongs to Unix.

Re:All "in the family."

[Millenniumman]

THAT needs to be emailed to the FSF.

The answer is simple...

[Lost Found]

...but you may not like it. The replacement is and will continue to be Linux, which is already more portable than NetBSD, has far greater mindshare, performance, scalability and functionality.

Re:The answer is simple...

[LizardKing]

Linux more portable than NetBSD? If you look at the number of lines of machine dependent code per-architecuture, then Linux is far less portable than NetBSD. Which is what you'd expect from an operating system designed specifically for the 80386. NetBSD on the other hand is a successor of the first Unix codebase, which was rewritten in C with portability as a key goal. Also, in Linux device drivers are usually tied to one architecture. On NetBSD, a PCI driver for a network card will work on any architecture with a PCI bus. So in fact, more of the code in Linux is machine dependent than it first appears!

Having worked on an embedded system (Arcom), I found it easier to ignore the piss poor Linux kit that came with the machines and use NetBSD instead. The result was a smaller operating system and more space for my application code.

Re:The answer is simple...

[LWATCDR]

That is one thing that always bothered me. Why didn't NetBSD thrive in the embedded market.
Seems like it would have been a very good match.

Re:The answer is simple...

[Anonymous Coward]

Linux more portable than NetBSD? If you look at the number of lines of machine dependent code per-architecuture, then Linux is far less portable than NetBSD.

Ahh, that's actually bullshit. The Linux machine specific code for a given architecture is often
smaller than an equivalently supported port on NetBSD. Take a look at Alpha (which is a obviously
a static target, and reasonably supported on both) and NetBSD's machine specific code is significantly
bigger than Linux's. (Even though Linux has significantly better support for SMP on that platform).

Which is what you'd expect from an operating system designed specifically for the 80386.

What Linux are you talking about? Linux 1.0 was designed specifically for the 386. Linux 2.6 was
designed to be portable enough that new architectures just turn up generally without need for any
core code changes.

NetBSD on the other hand is a successor of the first Unix codebase, which was rewritten in C

Umm, you know Linux was written in C to start with, right? So according to your logic, NetBSD is
not portable because it is an operating system designed for the pdp-11.

with portability as a key goal. Also, in Linux device drivers are usually tied to one architecture.

That's bullcrap too. There is a fine generic bus interface and memory management routines for drivers
to be pretty portable. People from various camps do reasonably significant testing on powerpc, ia64,
sparc64, arm and many others. These use the same drivers as i386 for their disk controllers, network
cards.

On NetBSD, a PCI driver for a network card will work on any architecture with a PCI bus. So in fact, more of the code in Linux is machine dependent than it first appears!

No it isn't.

Having worked on an embedded system (Arcom), I found it easier to ignore the piss poor Linux kit that came with the machines and use NetBSD instead. The result was a smaller operating system and more space for my application code.

But you obviously don't know what you're talking about.

Re:All "in the family."

[smash]

Oh how I wish people would call it Unix.

Definately disagree here.

Linux (or more specifically, "GNU" or "the gnu toolchain") is nothing like 'real' unix when you get further than a cursory observation. The GNU tools are usually different in some subtle way for no *really* good reason (it seems) other than to follow GNU's own "standards".

Examples that spring to mind for example: netstat, ifconfig, info, etc...

If you've used a few flavours of Unix (myself, Solaris, SCO (yes, it sucks), AIX, FreeBSD) the differences (even subtle ones like the display formatting of various commands) in Linux really stand out.

All this comes as I think about going to BSD

[cptnapalm]

Recently, I have been reading a hefty amount of Unix history and the philosophy which developed once pipes were introduced. Looking at my own history of Linux usage, I have seen that I look upon my computer as an appliance when I spend too much time in a GUI with the do-it-all monolithic apps, but when I use it in the Unix way, it is less a tool than an environment in which I can do things and learn new things. Having read the quote to many times about people using Linux because they hate Microsoft, while others use BSD because they love Unix, I began to incline toward giving one of the BSDs a go. Then this whole mess came out.

I'm finding myself still interested, but more likely to give one of the newer forks a go, like Dragonfly BSD, PC-BSD or Desktop BSD. I incline toward the latter simply because they have a DVD image for download whereas the others do not. With their desktop focus though, I'm wondering if the experience will be more or less the same as I have now.

I really do like Ubuntu, both as a distro and especially as a community. But within the Linux world, it seems that it is Microsoft is the one to beat by creating ever larger Windows like apps rather than doing things in a more Unix-like way simply because of a love of the *nix environment; more into creating a non-evil and free Windows than carrying the Unix tradition forward, innovating of course, but by expanding upon the methodology rather than imitating the abandoned platform. So I am wondering if things will be any different.

As I am realizing that this has nothing to do with the interview, which I actually did read, I'll just stop typing now.

Re:All this comes as I think about going to BSD

[Anonymous Coward]

DFBSD is only for developers right now. And I'd stay away from PC-BSD/DesktopBSD for exactly the reasons you list. If you really want to get deep into Unix, go with Net or Open. They're both lean and mean and will force you to think in different ways than your typical GUI-noob-friendly OS. You can't go wrong with either of them. FreeBSD is okay too, but I don't like it as much because it tries hard to be everything to everyone and has much more focus on GUI stuff.

Re:All this comes as I think about going to BSD

[Nimrangul]

DesktopBSD and PC-BSD are not forks of FreeBSD, they are add-ons to FreeBSD releases, they are prepackaged versions of FreeBSD, similar to your Linux, "distros," mix KDE with random home-brewed tools and pour into release version 5, 6, or whatever of FreeBSD, serve. DragonFly BSD, while interesting, is not really the system one should be looking into for regular day-to-day use, major design alterations are still underway in the system and as Dillon has said, it's not going to really be ready for a while. NetBSD as you've recently noticed has some issues, it's had stability problems on it's vaunted umpteen jillion platforms for going on the better half of a decade and at best users and developers have been ignoring much of it, the developers focus on making things cross-compile rather than making sure they natively compile and actually run.

If you want to try a BSD, FreeBSD is the most Linux distribution-like of the BSDs, while OpenBSD is the most BSD-like of the BSDs, it's a matter of if you like the old Unix stuff or the newer Linux stuff. Generally speaking FreeBSD is the less GNU-style free, as in that whole freedom schtick, of the two, with better performance and more bells and whistles, while OpenBSD is the more secure, stable, conservative of the two. OpenBSD has better overall documentation, while FreeBSD has several really nice books, like the DAIOTFOS and the Handbook.

Re:All this comes as I think about going to BSD

[cptnapalm]

Thank you for sharing your views on which BSDs to look into. I had not found enough information to properly judge, it seems. I think I'll take a look into both FreeBSD and OpenBSD and perhaps try to keep tabs on Dragonfly.

If ever I fall off the deep end, I can start up a PDP-11 emulator and use the ancient Unix from http://www.tuhs.org/

Re:All this comes as I think about going to BSD

[interval1066]

> DesktopBSD and PC-BSD are not forks of FreeBSD, they are add-ons > to FreeBSD releases...
Right. More properly, they are forks off of the FreeBSD branch of BSD 4.2 Light. We would do well to recognize where all this comes from. I'm frequently amazed by the number of noobs who have no idea about the BSD kernel.

Re:All this comes as I think about going to BSD

[Nimrangul]

What in the fuck are you talking about? They are not forks, I just said they are not forks, you agreed with me, and then contradicted yourself by saying they are forks of FreeBSD.

FreeBSD is not a branch of, "BSD 4.2 Light," FreeBSD is a fork of Jolix with such a long and divergent development that it looks nothing like that old 386BSD code. Once, long ago, both NetBSD and FreeBSD had a resyncing when they had to take their modifications to 386BSD and move it over to the 4.4BSD-lite codebase, but that doesn't make anything here a branch of another. FreeBSD is it's own operating system which works very little like 4.4BSD, just compare what's in the Design and Implementation of the 4.4BSD Operating System to what's in the Design and Implementation of the FreeBSD Operating System - there's a reason they have different names.

There is no singular BSD kernel, each kernel and userland develop with one another in their own repositories - I think you may be one of those, "noobs," that has, "no idea about the BSD kernel."

X11 is heavyweight?

[steveha]

X-Windows needs to be replaced with something more light-weight (i.e. single-user with direct access to the multimedia hardware).

Really? Can you please point me to some numbers that demonstrate this point?

X11 was invented in the bad old days, running on UNIX systems less powerful than today's PDAs. As I understand it, it's actually quite lightweight. Certainly the network transparency features don't cost much, because when you run the X server and the X client software on the same computer, they communicate by using domain sockets (which are very lightweight). Both Microsoft Windows and Apple OS X have abstraction layers that isolate the graphics hardware; do you have some numbers showing that X11 has significantly more overhead than those abstraction layers?

The latest versions coming out of X.org now have support for features similar to what OS X does: applications are rendered into offscreen buffers, and the buffers are composited together (with transparency effects, or other special effects if you desire). So, X11 is no barrier to cool eye-candy either.

The worst thing about X11 used to be way it was managed (under Xfree86). Now that the project has moved to X.org and has been revamped, progress has sped up a lot.

steveha

Re:X11 is heavyweight?

[TheRaven64]

Certainly the network transparency features don't cost much, because when you run the X server and the X client software on the same computer, they communicate by using domain sockets (which are very lightweight).

Not that lightweight. Fortunately, in the '80s, MIT released the shared memory extension which took away most of that overhead and has been standard in X servers for over a decade. The problem with X11's network transparency is that it is at the wrong layer. X11 puts network transparency between the view and the frame buffer, when it should be between the view and the controller. Sun realised this with NeWS, but did a typical Sun and said 'Hey, we've got this great technology! How can we market it in such a way that it never goes anywhere?'

Architecturally, there are quite a few things wrong with X11. The easiest solution is the one that Apple took; throw it away and replace it with something new. That isn't really a good idea for *NIX, however, since there is a lot of legacy software that uses X11. Fortunately, Keith Packard seems well aware of the shortcomings of X11 and has a set of incremental improvements that address them.

Re:All "in the family."

[Pausanias]

Linux has an huge base of open source device drivers taylored to run under it. This is what sets it aside from other kernels. No matter how spiffy the *BSD/minix/Solaris/Hurd or other open source kernels are, they will never catch up with linux as far as popularity, because of this simple issue. You can't use an OS if it doesn't support your devices.

If you ever watch the kernel compiling, most of the time is spent compiling device driver. And the legacy support is immense. Heck, you can shave a few minutes off the compile time just by disabling ISDN.

*BSD is Dying

[Anonymous Coward]

It is now official. Netcraft confirms: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying

Re:BSDying

[Anonymous Coward]

Hmm, well, both NetBSD and OpenBSD suck when compared to any current Linux distribution.

Funny, I know two of the Worlds largest banks use OpenBSD for firewalls in various places. Namely because it does not suck. The US DoD donated $2,000,000 US dollars to OpenBSD for a reason you know? I once posted an email to the sparc@ mailing list around Christmas time, when lots of people were already on holiday and I got various, "sorry I'm out of the office till..." messages. One of those messages was from some IT person working at the Pentagon. So someone in computing with the Pentagon, thinks that OpenBSD is worth watching.

You are an idiot. OpenBSD and NetBSD are great. Linux is great for many things too, but given the choice, I'll take OpenBSD firewalls over any other firewall. Especially on sparc64 hardware.

No matter how large the army of assholes is which you are a member of, nothing can tarnish OpenBSD's legendary status in security.

BSD and the newbie

[twoblink]

I'm pretty much sick and tired of Linux being thrown around as newbie word.. "Yeah, I just installed linux!! I installed redhat!! I clicked next next next 80 times. It's just like windows! I'm a linux sys admin now, someone hire me!!"

When someone tells me "I've been running BSD for 10 year" I at least have some confidence in what they know.. When they tell me that about linux, I don't.

BSD rocks. I think in 2 more generations, most large companies will want to switch to BSD for embedded, simply because the licensing is better.

As for GPLv3, it should die a horrible death. A forked GPLv3 kernel has got to be the stupidest suggestion I've ever heard in my life.

Re:BSD and the newbie

[Anonymous Coward]

BSD rocks. I think in 2 more generations, most large companies will want to switch to BSD for embedded, simply because the licensing is better.

However, according to fuckwits like you, "BSD" is miles ahead of Linux in every department. So
what are "most large companies" waiting for? That the last 9 bugs in the FreeBSD source tree be
fixed?

Cause and Effect of 'X' "Safety"

[Anonymous Coward]

IMHO I don't think the problem with X is so much "lightweight" as it's built on certain assumptions (engineered systems usually are) that limit it's flexability, especially viewed with an eye towards were computers in general, and graphical systems in particular are headed.

Effect of GPL "Ideology"

[Anonymous Coward]

Well regardless of whom one points the finger at. GPL based distros are going to be handicapped (needlessly some feel). While BSD based distros will not. Simple as that.

Re:Effect of GPL "Ideology"

[AJWM]

GPL based distros are going to be handicapped [...]. While BSD based distros will not.

The NVidia drivers aren't available at all for most of the BSDs. Just FreeBSD. And then only on 32-bit x86. (NVidia supports Linux on x86_32, x86_64 and IA_64.) So, who's handicapped, now?

Re:All "in the family."

[smash]

All of my hardware is supported by FreeBSD. USB support worked in the BSDs before it did in linux. The driver "problem" is largely a non-issue. FreeBSD can actually use Windows NDIS drivers for NICs as well...

Re:All "in the family."

[AJWM]

I wish people would call it Unix. It's a better way to be inclusive of GNU,

But, but...GNU's not Unix.

BSD Trouble

[labradore]

Ok, so what I am getting is that in the BSD development process, a bunch of people live at the top level of the org chart and have access to change the source repository. They agree on what they'll do and then theoretically they all make the changes and updates and eventually someone goes, "Hey, lets bugfix this latest commit and release it as (un)stable."

In the linux dev. process, Linus is at the top of the org chart. He accepts or rejects patches that come to him. He trusts other people to maintain certain subsystems and architectures, but ultimately, he decides what goes in and what doesn't (even if he hasn't really looked at it much).

Difference #2: Linux is GPL'd. You can't profit from changes without sharing them. BSD is BSD'd. You can profit from your changes and keep them hidden.

So the sturcture of the Linux license enforces sharing and the structure of the development process enforces a set of standards (each upstream guy's own standards) on the quality (or lack thereof) of the code. The BSD license and the BSD development structure both require social contracts and continuous communication and agreement among the developers to keep things together and quality consistently high.

So in the BSD world there are forks because developers encounter both technical and personal disagreements. In the Linux world, the devs don't really have to get along as much, because the structure of the project is more forceful than the BSD cooperation regime.

All of the problems that this NetBSD guy have described seem to be mitigated more-or-less automatically in the Linux structure and with the GPL. Linux development is not perfect. Nor is the GPL. However, it sure looks like they're better approaches. Linux certainly isn't less successsful than any of the BSDs.

Re:All "in the family."

[Anonymous Coward]

And all your hardware isn't very much hardware. So you prove nothing.

Re:BSDying

[Anonymous Coward]

Funny, I know two of the Worlds largest banks use OpenBSD for firewalls in various places. Namely because it does not suck. The US DoD donated $2,000,000 US dollars to OpenBSD for a reason you know? I once posted an email to the sparc@ mailing list around Christmas time, when lots of people were already on holiday and I got various, "sorry I'm out of the office till..." messages. One of those messages was from some IT person working at the Pentagon. So someone in computing with the Pentagon, thinks that OpenBSD is worth watching.

Pentagon shmentagon, the NSA contributes code to Linux and has employees paid to work on the Linux kernel.

Apart from management; what's the problems?

[RLiegh]

I have an old 1.3ghz machine here I'm typing from. Since the original brouhaha I've been switching back and forth between the three BSD systems. I have invested some time in downloading gnome 2.14 over dialup and it works alright. Both FreeBSD and OpenBSD are using older versions of gnome (I think open is still on 2.10; don't quote me on that, however!).

I'm rambling because I'm tired, sorry. My point is that the software in pkgsrc seems to be recent, and fairly stable (though that port of ajunta is crap, currently), NetBSD is running great as a desktop system for me and it seems to detect my (admittedly ancient) hardware ok, so...where's the gotcha? Does fall down on server tasks (if so - how so? compared to what? according to who?) or what, exactly?

I understand that there's concern because apparently most of the developers work for Wasabi and development appears to proceed (or stagnate) dependent on Wasabi's whims; but apart from the undisputed mis-management, are there any other signs of decay I'm just simply missing?

Re:Apart from management; what's the problems?

[22_9_3_11_25]

if you think a 1.3ghz is ancient hardware you are really out of touch with reality.

Re:Apart from management; what's the problems?

[RLiegh]

It dates from 2001. In the computing world, five years is generally considered extremely out of date -if not ancient.

Re:Apart from management; what's the problems?

[iggymanz]

geez, I better turn off the ten year old machines running our company, then.

Re:Apart from management; what's the problems?

[magetoo]

[...]
so...where's the gotcha?
[...]

I understand that there's concern because apparently most of the developers work for Wasabi and development appears to proceed (or stagnate) dependent on Wasabi's whims; but apart from the undisputed mis-management, are there any other signs of decay I'm just simply missing?

Doesn't seem to be any gotchas, really.

And as for the allegations of mismanagement, what I have seem on the mailing lists so far is exactly one former bigshot shouting "coup d'etat!" (for some reason timed to coincide with his commit privileges being revoked), and tons of people saying "if what you say is true, it's serious". It does seem that the project could do with an infusion of transparency, though.

Until more than only one person says the city is burning, I'll rather believe it's the fallout from some petty power stuggle that he appears to have lost. The later part of the discussion, with all the insults and the he said/she said level of discussion doesn't inspire confidence in mycroft either.

That is not to say that his original post did not have any valid points. I think the project lacks a sense of direction, and it's really hard to see what exactly makes NetBSD a better choice than any of the other BSDs for a new user today.

But still, NetBSD continues to run just fine on my machine. There's serious development going on too, with Elad Efrat's new security model/authentication work for example, and just today I read a post from one guy offering to add support for pluggable schedulers. This does not look like decay and stagnation to me.

Note: I am just a user, and this is all from what I have been able to read on the public mailing lists. I'm sure there are factual errors here, but but my general impression if far, far from the "NetBSD is dying!" scenario that it seems some people here are taking for granted.

Re:Apart from management; what's the problems?

[DaPoulpe]

Not negating their existence in general, but on the desktop side of things (original post) people running 10 years old computers (e.g. 386 and 486) must be a tiny tiny part of the overall computer park IMO.

Re:Apart from management; what's the problems?

[iggymanz]

my company provides "terminals" to banks, you'd be amazed what the "desktop" in a bank could be. OS/2, DOS, windows 3.1....

Re:All "in the family."

[TeknoHog]

Linux is a kernel (as opposed to the BSDs which include a set of integrated userland tools - not just package a bunch of independently developed GNU tools)

I don't really buy this, even if I hear it all the time. Linux is not developed in a vacuum, and neither is GNU userland software. For all practical purposes, Linux is the GNU kernel.

Then again, if you want to argue on the merits of integrating kernel with userspace, look how well Microsoft is doing it ;)

*BSD is Alive

[Anonymous Coward]

It is official; Netcraft now confirms: *BSD is growing

One more crippling bombshell hit the already beleaguered Windows community when IDC confirmed that *BSD market share has risen yet again, now up to more than 30 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has gained more market share , this news serves to reinforce what we've known all along. *BSD is sending other OSes into complete disarray, as fittingly exemplified by topping the charts in the recent Sys Admin comprehensive networking test.

You don't need to be a Daemon to predict *BSD's future. The hand writing is on the wall: *BSD faces a long and prosperous future. In fact there won't be any future at all for Windows Server because *BSD is growing. Things are looking very good for *BSD. As many of us are already aware, *BSD continues to gain market share. Red ink flows from Redmond like a river of blood.

FreeBSD is the most loved of them all, having gained 93% more core developers. The sudden and pleasant release of the long developed 5.0 only serves to underscore the point more clearly. There can no longer be any doubt: FreeBSD is growing.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 70000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 70000/5 = 14000 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 7000 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (70000+14000+7000)*4 = 364000 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the release of OSX, cool new technologies and so on, FreeBSD is expanding into more desktops than ever. FreeBSD has become more than the sum of its parts.

All major surveys show that *BSD has steadily gained in market share. *BSD is very powerful and its long term survival prospects are very bright. If Windows is to survive at all it will be among OS dilettante dabblers. *BSD continues to improve. The progress achieved is nothing short of a miracle. For all practical purposes, *BSD is alive and kicking.

Fact: *BSD will kick your ass

Re:All "in the family."

[OrangeTide]

But I kind of like GNU getopt where you can stick command-line switches anywhere you want instead of having to put them all before the arguments. example:

% ls *zip
(oops, I think I want to see some file sizes)
% ls *zip -l .. on gnu this would be fine. on real UNIX it usually fails.

Re:BSDying

[Anonymous Coward]

Pentagon shmentagon, the NSA contributes code to Linux and has employees paid to work on the Linux kernel.

And that means OpenBSD sucks, how?

Announcing...

[wild_berry]

The SlashEditors rejected my front-page submission for a review of my new GNU/Linux distribution -- the third new distribution I've made this week -- featuring some Linux Kernel and some GNU stuff on top. Wilberux 4.62.81.three was teh b0mb, but 4.62.81.fork had to come out because the project lead (me) was an ass and I had to wrest control back from that evil cabalist.

BTW, 2001's million Linux distributions want their flamebait back.

Re:BSDying

[Anonymous Coward]

Pentagon shmentagon, the NSA contributes code to Linux and has employees paid to work on the Linux kernel.

So the government which has been spying illegally on its own citizens and lying to them, is inserting code into the Linux kernel. And you feel good about that?

Bzzzt! Wrong!

[Anonymous Coward]

The Linux kernel is licensed under version 2 of the GPL, and only version 2 of the GPL. It has been that way for a LONG time, and many hundreds of people have contributed code to it under that license.

It isn't possible for Linus to change the license to GPLv3 without getting the permission of all of those contributors (or the copyright holders of each contribution at least). That would be a gargantuan task.

Code that Linus owns sole copyright to, he can release under any license he wants. Code whose copyright is owned by individuals and corporations, could only be re-licensed by (or with the permission of) those other parties.

Re:All "in the family."

[theonetruekeebler]

In licensing the UNIX brand a vendor warrants and represents that every certified product:

• Conforms to the specification.
• Meets The Open Group's test and certification requirements.
• Will continue to conform to the specification.
• Will be rectified within an agreed time should it be found to be non-conformant.

That's from The Open Group, who own the trademark. So if you want to call it Unix, your product must meet their standards of what Unix actually is. Presumably you have to pay to get it certified. Only companies like IBM, Sun, HP and Fujitsu are on the certified list, so I'm guessing it's not cheap to obtain or maintain.

Linux flavors are mostly conformant only standards specified by their own vendor. Considering that Windows XP only complies to its vendor's specification, this isn't necessarily a marketing black eye.

The biggest problem with getting certified as a "real" Unix is that every new release must be recertified. This gets expensive and time-consuming, making fast release cycles all but impossible. Red Hat could certify RHEL, which they've given a long release cycle. It might be worth it, though, if they could say "We meet the same Unix standards as IBM, HP and Sun, have over half the total Unix market, and do it at a fraction of their boutique OS prices."

in your .profile: POSIXLY_CORRECT=yes

[Ayanami Rei]

*shrug*
A lot of these commands are horrible anyway (have you read the manpage to ifconfig on Solaris, jesus)

I've sort of resigned myself to never expecting the command line to be portable among OSs (unless it's a specific application)

OS choice by fanboyism?

[Anonymous Coward]

Having read the quote to many times about people using Linux because they hate Microsoft, while others use BSD because they love Unix, I began to incline toward giving one of the BSDs a go. Then this whole mess came out.

Choosing an OS by cliches and slogans is a horrible way to become a fanboy of any OS.

How about try them and see which meets your needs more closely.
Keeping a spare 10GB partition or two to try whatever OS you're considering is the easiest way to make an informed decision of whatever you feel like experimenting with. I've been a unix user since about '82 - including the BSD derived SunOS and NextSteps in the late 80s. But in practice I've found Linux moving faster and making more right decisions than any of the unixes.
(For example, Linux approached theoretically optimal SW Raid performance sooner than Solaris: http://archives.postgresql.org/pgsql-performance/2 006-09/msg00205.php) and is portable to far more platforms (Cell chips; many cell phones; etc) than BSDs are toaday.

But your needs may be different than mine - I'd strongly recommend just trying them for a few hours instead of reading so much propaganda.

I recently used Openbsd

[Anonymous Coward]

and the only thing I was impressed by was the small install size, and the programs available by default.
However, it was the userland tools that failed to impress me. I might be used to gnu tools, but there were things that were missing from the BSD tools that left me a little annoyed. I know many sysadmins might find them stupid, but hell, I use them.
using top or vmstat to display available ram doesnt cut it. I like using free -m as a quick reference. it shows what I need when I need it.

Also, bsd's ls command was limited compared to gnu ls. I ended up installing all the gnu utils to the base system and aliasing many that I used that had all the features I need. Might call these bloated, but damn, they were more robust. Size might be an issue, but sometimes if the "bloat" is simply more features that enhance the use of a program to where it's useful, then the trade off is worthwhile. as long as it isnt taken to an extreme.

I know these are *tiny* things, but it's the tiny issues that make all the difference.

Personally I'd like to see a bsd fork that is gnu compatible and makes use of gnu utils.
Just because it worked well in the 1980's doesnt mean it stands today.

Re:I recently used Openbsd

[raddan]

How many BSD machines are you installing per day that you can't just install GNU fileutils and move on? I'm surprised that you didn't mention that the default shell was ksh and not bash. That seems to be the biggest stumble for most Linux converts. Spend more time with your OpenBSD install. There are other (more significant, IMHO) features that make BSD worth it, like wireless drivers. Such a PITA in Linux. The ports tree is pretty nice, too.

Re:BSDying

[Anonymous Coward]

Uhh, no they're not (inserting code). Moron.

You are *totally* wrong

[Lost Found]

Your post is full of 100% false FUD! Linux supports more architectures than NetBSD, and additionally, Linux drivers most certainly are *NOT* tied to one architecture. That is simply not true at all, and I say that as someone who has worked on the kernel before.

Re:You are *totally* wrong

[LizardKing]

No, my post is not full of FUD, as I experienced the lack of Linux driver portability when trying to get a network driver working on a PowerPC embedded board. The driver made assumptions about the endianness of the host system as it was written for x86 - a typical portability fuck up. Great care has been taken with support for different bus architectures in NetBSD, which makes drivers much more readily portable than with Linux where there is a huge amount of duplication in driver code that should be abstracted away.

As for Linux supporting more architectures than NetBSD, that's not quite the case. Many Linux porting efforts stagnate as major kernel subsystems and their APIs are overhauled with little attempt at backwards compatability. As a result many ports (and drivers) fail to build as the authors quit trying to play catchup. The NetBSD codebase is cross compiled to all the supported architectures that make up a release on a nightly basis, so it becomes apparent much more readily when breakage has occurred than with the Linux kernel.

Re:You are *totally* wrong

[Anonymous Coward]

No, my post is not full of FUD, as I experienced the lack of Linux driver portability when trying to get a network driver working on a PowerPC embedded board. The driver made assumptions about the endianness of the host system as it was written for x86 - a typical portability fuck up.

"I experienced"; Ahh, anecdotes, the last retreat of the BSD zealot.

OK Linux gets more testing and development on x86 than most other platforms, Linux has bugs.
NetBSD is no different in either regard.

Great care has been taken with support for different bus architectures in NetBSD, which makes drivers much more readily


You make it sound like this is not the case in Linux, when actually it is. Linux supports different busses
implemented in different ways on different architectures.

portable than with Linux where there is a huge amount of duplication in driver code that should be abstracted away.

No there is not a huge amount of duplication in driver code that should be abstracted away. FUD.

As for Linux supporting more architectures than NetBSD, that's not quite the case. Many Linux porting efforts stagnate as major kernel subsystems and their APIs are overhauled with little attempt at backwards compatability. As a result many ports (and drivers) fail to build as the authors quit trying to play catchup. The NetBSD codebase is cross compiled to all the supported architectures that make up a release on a nightly basis, so it becomes apparent much more readily when breakage has occurred than with the Linux kernel.

FUD. Linux these days is regularly cross compiled on a dozen or more architectures. You obviously
have no idea how Linux kernel development works, because "porting efforts" do not stagnate as a result
of changes when they merged in the tree.

Finally: yes, Linux supports more architectures built from its single source tree than does NetBSD's kernel, period.
If you try to argue with that then you are a liar.

Re:You are *totally* wrong

[Lost Found]

Still wrong, as the Anonymous Coward is also pointing out.

If you ran into an endianness assumption, that is a bug, plain and simple. Among Linux's excellent portability layer is a set of macros to swap byte order how and when necessary (cpu_to_le32, cpu_to_be32, etc). If you find *any* architecture specific code that is not in either "include/asm-*/" or "arch/*", it is a bug and should be reported. And for the record, PCI drivers don't live under "arch/*".

All of these things are things you would know if you actually LOOKED at the code you so readily criticize. Linux is free and freely available. Get a copy from kernel.org and see for yourself.

Re:You are *totally* wrong

[LizardKing]

All of these things are things you would know if you actually LOOKED at the code you so readily criticize. Linux is free and freely available. Get a copy from kernel.org and see for yourself.

What the fuck do you think I was doing when I came across the shitty driver in question? Well if you want to believe that Linux is a decent solution for embedded systems then go ahead and use it. Personally I'll stick with NetBSD where I get an entire, well integrated operating system, not some hastily thrown together mess based on an old RedHat distribution.

Re:You are *totally* wrong

[Anonymous Coward]

Translation: you've got nothing, except for anecodes and assertions.

Re:BSDying

[Anonymous Coward]

Uhh, no they're not (inserting code). Moron.

A very popular Linux distro (Ubuntu), went almost a full release cycle without any developer or user noticing that the root password was stored IN THE PLAIN on disk, as part of a log file of the installer.

And I am expected to think that the US Govt can't insert code into Linux? You idiots are likely to not notice malicious code and then you lot are also happy to use vendor supplied binaries with God knows what is in there.

Fuckwit.

Re:BSDying

[Anonymous Coward]

Ubuntu != Linux.

Anus licker.

Re:BSDying

[Anonymous Coward]

Ubuntu != Linux.

Yeah and people on either side have nothing to do with the other. Polar opposites! One would not reflect parts of the other, in any way!

Re:BSDying

[Anonymous Coward]

Are you quite OK there, or do you have some kind of mental retardation you need help with?

Re:BSDying

[Anonymous Coward]

Are you quite OK there, or do you have some kind of mental retardation you need help with?

You mother must be so proud.

Re:All "in the family."

[Burz]

I agree the "Linux" misnomer is quite awful. As platforms go, its really more of a mass hallucination.

OTOH for basic functionality, the LSB seems as meaningful as "BSD". In a couple of months, we will also have the LSB Desktop spec (to include APIs like Gtk+ and Qt allowing developers to target desktop users, but without the KDE/Gnome desktop layer itself).