NetBSD 2.0 RC4 Tagged and Released

← Back to Stories (view on slashdot.org)

NetBSD 2.0 RC4 Tagged and Released

Posted by CmdrTaco on Sunday October 10, 2004 @02:38AM from the for-the-bsdies-in-the-audience dept.

agent dero writes "According to recent news at NetBSD.org, NetBSD 2.0 Release Candidate #4 has been tagged and released to the release engineering server Check out the announcement for more info on changes since RC 3. Also note worthy, the final release has been pushed back a few weeks to allow for testing of RC4"

74 comments

Min score:

Reason:

Sort:

Question by GypC · 2004-10-10 02:59 · Score: 1

I don't want to dig through the mailing lists, and I can't find anything on the website so...
What are the new changes in NetBSD 2.0 that warrant the major vesion number change?
1. Re:Question by Anonymous Coward · 2004-10-10 03:45 · Score: 2, Informative
  
  Significant changes from NetBSD 1.6 to 2.0
  http://www.netbsd.org/Changes/changes-2.0.htm l
2. Re:Question by noselasd · 2004-10-10 04:04 · Score: 5, Informative
  
  2.0 major new features.
  + they've decided to change the versioning scheme ;)
3. Re:Question by Anonymous Coward · 2004-10-10 04:44 · Score: 2, Informative
  
  They decided long ago to call the first version with decent SMP support (on i386) version 2.0. So here it is :-) (almost...).
Microreleases by Anonymous Coward · 2004-10-10 04:59 · Score: -1, Flamebait

Sigh... What's the point of announcing every tiny microrelease on Slashdot? X.Y RC4 is not news. 2.0 final is.
1. Re:Microreleases by Anonymous Coward · 2004-10-10 05:03 · Score: 5, Insightful
  
  The release candidates require lots of testers to work the final bugs out. Slashdot has people that can do that, if they will. While it may be pedantic/boring/whatever to have each release candidate posted, if it catches one bug, then it's been worth it.
2. Re:Microreleases by Anonymous Coward · 2004-10-10 06:24 · Score: -1, Flamebait
  
  A bugsquashing call every once in a while is fair enough, but this article isn't branded as such. I also believe it's NetBSD's responsibility to attract testers, not Slashdot's. (At least not for each and every microrelease.)
3. Re:Microreleases by Dahan · 2004-10-10 07:34 · Score: 3, Informative
  
  I tend to agree, but Slashdot posted a series of articles about Linux kernel 2.5.n and FreeBSD 5.3-BETAn, so I guess beta OS releases are deemed newsworthy here.
For a moment I read the headline as.. by Anonymous Coward · 2004-10-10 07:32 · Score: 1, Funny

"NetBSD 2.0 RC4 Bagged and Tagged"

It's a joke.. laugh. :)
1. Re:For a moment I read the headline as.. by Anonymous Coward · 2004-10-10 08:38 · Score: 0
  
  Freudian slip. B is D... I mean BSD.
Verified Exec by Per+Wigren · 2004-10-10 07:34 · Score: 5, Interesting

From the Changelog:

2.1.6. Verified Exec As the name suggests, Verified Exec verifies a cryptographic hash before allowing execution of binaries and scripts. This can be used to prevent a system from running binaries or scripts which have been illegally modified or installed. In addition, Verified Exec can also be used to limit the use of script interpreters to authorized scripts only and disallow interactive use.

I've been looking for something like this for Linux some time ago. Anyone here know if it exists?

--
My other account has a 3-digit UID.
1. Re:Verified Exec by noselasd · 2004-10-10 08:22 · Score: 2, Informative
  
  >I've been looking for something like this for Linux some time ago. Anyone here know if it exists?
  here
what happened to all the trolls by Anonymous Coward · 2004-10-10 08:40 · Score: -1, Offtopic

I haven't been reading /. for a month or so, and when I come back to my beloved BSD section, all trolls are gone. Died off without food? WTF? Someone explain.
1. Re:what happened to all the trolls by Anonymous Coward · 2004-10-10 13:48 · Score: -1, Offtopic
  
  That's due to the lastest changes in slashdot.
  Even very few downmods give you an IP ban.
  And the IP ban lasts for 2 months or so.
  
  This can be handy sometimes - if you have modpoints and there is a slashdotter you don't like, just moderate some of his lesser posts up via underated. This will result in enough downmods to get him banned. I think you can pull this off with just one moderation account.
2. Re:what happened to all the trolls by Anonymous Coward · 2004-10-11 22:30 · Score: -1, Troll
  
  *BSD Obituary
  
  *BSD, 27, of Berkeley, CA died Monday, Sept. 6, 2004. Born July 3, 1976, it was the creation of a cluster of pot-smoking hippies who went to Illinois and came home with a reel of tape. Rather than smoke the tape, they uploaded it and hacked on it a little.
  
  *BSD was known for its C shell and early TCP/IP implementation. After being banished from UC Berkeley, it was ported to the x86 platform, where it fell into the hands of heavier pot-smokers who liked to argue. Soon, the project had splintered into 12 different Balkanized projects. Until its death, there was almost constant fighting in and amongst these groups, sometimes degenerating into out-and-out fistfights.
  
  *BSD is survived by its superior, Linux, as well as several commercial unix implementations. It may be missed by some who knew it, although most of them are said to be mere OS dilettante dabblers.
  
  A funeral will be held at 2 p.m. Thursday, Sept. 9, at the Berkeley Chapel on the UC campus, with interment to follow via the burning of the original *BSD tapes and scattering of the ashes over the San Francisco Bay. The Rev. Lou "Buddy" Stubbs will officiate.
  
  The family will receive friends from 7 to 8 p.m. Wednesday, Sept. 8, at the funeral home.
Heh... by Anonymous Coward · 2004-10-10 08:46 · Score: 0

It comes a day when a troll has to start facing the truth.

:-D
Re:what happened to the troll by Anonymous Coward · 2004-10-10 09:05 · Score: 1, Informative

"all the trolls"... uh, did you count them? It's probably 1 AC...
Anyway, the poor kid is very, very ill. I really don't know what I can do to help him to recover.
uh... yeah. why not. by ulib · 2004-10-10 09:16 · Score: 3, Insightful

Since this is the *BSD section, it makes perfect sense to make the readers aware that a new micro/macro/mini/maxi/nano/mega/pico/giga-release is out.
you wish by Anonymous Coward · 2004-10-10 09:43 · Score: -1, Offtopic

>It's a joke.. laugh. :)
You're a troll.. piss off. :)
Total bullsh*t. (nice try...) by Anonymous Coward · 2004-10-10 19:24 · Score: 0

Total bullsh*t.
...and here's our troll, desperately trying to be modded up ;-)
Only a total retard could have fallen for it, however.
Networking question by ulib · 2004-10-10 19:46 · Score: 1

I've never experienced putting NetBSD (or OpenBSD) machines in a FreeBSD ethernet. I guess everything should run smoothly after some configuring. But are there any potential issues I'd have to watch for (file system compatibility, etc)?
DragonflyBSD 1.0? by Anonymous Coward · 2004-10-10 19:50 · Score: -1, Offtopic

Desparately off topic, but it seems that DragonflyBSD has released 1.0 or will release it tommorrow according to their homepage http://www.dragonflybsd.org/main/
Re:Networking question (doesn't matter!) by ulib · 2004-10-10 19:57 · Score: 1

Uh... don't consider the question I asked 10 minutes ago.
I quickly decided I feel like experimenting it directly :-P
for experiment's sake by Anonymous Coward · 2004-10-10 21:07 · Score: -1, Troll

Most people have DSL or Cable with dynamic IP. Anyways, what are you doing reading this section, silly? BSD is no longer with us, haven't you heard?
I heard this by Anonymous Coward · 2004-10-10 21:57 · Score: -1, Flamebait

uh... I heard this.

Sorry to break this up to you kid, this stuff is for grown-ups. Go back to play with linux. :)
Sounds nice but... by Anonymous Coward · 2004-10-11 11:46 · Score: 2, Funny

Will it finally run on my toaster?
1. Re:Sounds nice but... by hubertf · 2004-10-13 00:22 · Score: 1
  
  Of course it runs NetBSD!
  
  - Hubert
So? by Anonymous Coward · 2004-10-11 12:49 · Score: -1, Flamebait

Who cares about NetBSD? Is there a single platform on which NetBSD runs and Linux doesn't? Welcome to the world of irrelevance my dear masochists.
1. Re:So? by setagllib · 2004-10-11 23:13 · Score: 5, Insightful
  
  Simple. NetBSD has infinitely higher quality and cleanliness. While it is reputed that Linux is now "more portable", not all of the ports are in the main source tree, not all are actively maintained and support all the features (let alone a userland, which NetBSD has for every arch). NetBSD's ports are, with few exceptions where things are just impractical on a device (e.g. Playstation 2 wouldn't really go far), all equally functional and stable, and all are in the main source tree, without needing to apply hacks and do unheardof installation procedures.
  
  NetBSD's stability and cleanliness even put it ahead of FreeBSD, and leave Linux in the dust. Performance that stems from this same cleanliness and the developers' understanding of hardware and good software is pretty hardcore, especially in 2.0. SMP is supported but I haven't heard much about it.
  
  Seriously, try it, you'd be amazed. NetBSD is not just for portability, that happens to be its edge against other BSDs (with OpenBSD close behind, for obvious historical reasons). It is the leader of cleanliness and code perfectionism, and hardware support is right up there (especially the way it handles USB devices is much better than FreeBSD and on par with Linux, albeit with less devices).
  
  I got trolled, I have lost, I'm having a nice day, but at least I got that out there.
  
  Fear this: http://netbsd.org/gallery/in-Action/ - and those were much older releases.
  
  --
  Sam ty sig.
2. Re:So? by Anonymous Coward · 2004-10-12 04:55 · Score: 1, Informative
  
  As far as I know, Debian GNU/Linux is the only Linux distribution which supports comparable number of platforms with NetBSD. Note that if you mix multiple linux distributions, you cannot have uniform operation among the platforms.
  And it seems next Debian release (sarge) lacks amd64, sh3 and vax. NetBSD have all of those.
3. Re:So? by Anonymous Coward · 2004-10-12 12:56 · Score: -1, Troll
  
  Linux kernel code is much cleaner than BSDs', because it's peer-reviewed by a huge number of programmers.
4. Re:So? by setagllib · 2004-10-12 19:00 · Score: 1
  
  Nonsense. If that were true then trees would be the cleanest and most pure things around because they are passed by every day by dozens of gardeners. Didn't make sense, did it?
  
  Seriously, your comment is stupid. BSDs have lots of developers, and moreso, the elitist attitude displayed by many is exactly what makes the code bases pure and clean.
  
  I said it before and I'll say it again: Linux development is a hack orgy. They care about what they can say about things ("more interactivity to rule the desktop, cleaner this and that, runs on X and Y") and less what code issues could result. Con Kolivas himself pointed out that Linux 2.6's interactivity hacks were to cover up sloppy coding of drivers and kernel procedures that should have been low-latency by design, not because you interrupt them when it's convenient. The Linux code base has been gradually mangled together to suit the needs and wants (often just to brag) of developers and their sponsors/employers. Can something grown in this fashion, with lousy maintenance afterwards (read the mailing lists regarding devfs' problems, Mr. "more programmers must make it cleaner" clueless troll), possibly be cleaner than systems which are actually engineered to be clean and sensible, not just tacking on new hacks just because they'll sound good in changelogs?
  
  Your parents must be so proud.
  
  --
  Sam ty sig.
5. Re:So? by Anonymous Coward · 2004-10-12 20:03 · Score: -1, Troll
  
  I think someone has a little case of Linux envy.
  
  FreeBSD's new scheduler was actually lifted from Linux. Unfortunately they can't get it right though.
6. Re:So? by ulib · 2004-10-12 20:05 · Score: 2, Insightful
  
  I agree with your post, but I really think this FUD-spreading troll wouldn't deserve such a long answer.
  As far as I know, *BSDs are committed to technical excellence, and have an academic spirit that's light-years away from all the proprietary-hating political crap that infests (and sometimes, sadly, characterizes) the linux commmunity.
  Spreading FUD is a disgusting political act, and it has gone on for so long, and steadily, on this board. Clearly this "troll" has an agenda... But I don't think it's worth taking it personally: *BSD's play in a completely different class. :-)
7. Re:So? by Anonymous Coward · 2004-10-12 20:31 · Score: 0
  
  Why would anybody envy something that's out there, fully accessible to users/developers? Everybody can grab a copy - and anybody (litterally: *anybody* :-D ) is allowed to develop it.
  A BSD user/developer would be stupid to "envy", when he/she can just jump the fence.
  The truth is, people using/developing BSD have their own goddamn reasons. If you don't agree, just go on with linux - just don't pretend we *envy* you. Please... :-)
  (Oh, and about the scheduler "lifting": plain bullsh*t. As always).
8. Re:So? by Anonymous Coward · 2004-10-12 20:42 · Score: -1, Offtopic
  
  Looks like someone is in denial.
9. Re:So? by Anonymous Coward · 2004-10-12 20:54 · Score: 0
  
  A hopeless retard wrote:
  "Linux kernel code is much cleaner than BSDs', because it's peer-reviewed by a huge number of programmers."
  Fact: Linux kernel 2.4.24 is compressed to a 28.4MB .tbz archive, FreeBSD 4.9 kernel is compressed to a 10.3MB .tbz archive. About the same ratio is present with Linux 2.6.1 vs FreeBSD 5.2.
  Conclusion: more than half of the linux kernel is actually junk.
10. Re:So? by Anonymous Coward · 2004-10-12 20:57 · Score: 0
  
  Get a life, pathetic troll.
11. Re:So? by Anonymous Coward · 2004-10-12 21:06 · Score: 0
  
  the indentation of the messages doesn't go any further? that sucks...
12. Re:So? by ulib · 2004-10-12 21:29 · Score: 1
  
  Our troll writes:
  >Linux kernel code is much cleaner than BSDs',
  In your dreams.
  >because it's peer-reviewed by a huge number of programmers.
  This is very true. The fact that 1) there's a huge number of linux programmers and 2) they're peers.
  That pretty much sums it up about their skills. I couldn't have said it better myself. :-)
13. Re:So? by Anonymous Coward · 2004-10-12 22:06 · Score: 0
  
  Haaa ha ha!
  
  "That pretty much sums it up about their skills."
  
  You're saying this like you could do better. Probably the "lowliest" linux kernel programmer would shit all over your intellectww
14. Re:So? by Anonymous Coward · 2004-10-12 23:00 · Score: -1, Troll
  
  Linux source code is bigger, but it's also better. We have more Computer Science Ph.D.s working on Linux than FreeBSD has anyone working on it at all. FreeBSD team is mostly a bunch of hacks with no understanding of proper design principles or clue as to which algorithms should be used for which tasks. No wonder Linux is better.
15. Re:So? by setagllib · 2004-10-12 23:07 · Score: 2, Insightful
  
  "Lifting" isn't too far off - the ULE scheduler was based at least in part on the O(1) scheduler, but without the problems (there were exceptional cases where the O(1) scheduler in Linux performed erratically, but ULE had much cleaner behavior). It had its own problems later, we know, but it doesn't really matter now.
  
  What's your point though? Who cares if a BSD takes something from Linux? The number of things that Linux has taken from the BSDs is mind boggling. Early code bases didn't have network support until they ripped the BSD network stack ("lifted" definitely). They didn't do that right either - the new open BSDs continue to have infinitely better networking capabilities ("NetBSD 2.0 beats land speed record" twice, and there was that post regarding FreeBSD 5.x routing hundreds/thousands of times as much data over the network as Linux).
  
  The only reason Linux rose to such glamor at all is media hype, certainly not technical merit. There was some geek romance in the notion of a kernel written for users who hate windows, more than for those who love UNIX. The BSDs couldn't care less about fighting off Windows, that's why their features are carefully planned and engineered (even at the cost of convenience for users), not just hacked on to make a cool headline and support pro-Linux evangelists.
  
  Finally, I do not envy Linux. I have run it frequently with varying successes, and there was a time I used it exclusively with quite a bit of success. That's not the point - the point is I didn't know any better. At that stage I was happy mashing together tarballs and compilations into a sorta-working system, with no idea that there were systems out there that were Whole Operating Systems that fit together and did everything with attention to integration and cleanliness. Imagine my surprise.
  
  Don't get me wrong, Linux has a lot of things that are persuasive towards its adoption. Just the options of file systems and curious drivers is enough for many users. But managability, reliability and good documentation? Go elsewhere. It's the equivalent of a group of casual engineers building a house while also putting in pieces (often entire rooms) that kids in their back yard built with Lego and mud, then having some entirely different party figure out how to live in the house and document it - often months out of date. Sometimes the lego and mud will be replaced by an engineer, maybe even well documented, but this will never apply to the whole thing.
  
  --
  Sam ty sig.
16. Re:So? by setagllib · 2004-10-12 23:14 · Score: 1
  
  I won't bother replying at length to this one. It can only be a troll.
  
  Fact: All of the BSDs were working decades before Linux was bootable, written [b]only[/b] by the best and brightest comp sci and soft. eng students (and above), and the UNIX before that by companies and some university contribution. Linux was, with all due respect to Linus Torvalds, a hack to have a non-BSD UNIX-like that worked on i386.
  
  If you'll note, FreeBSD was much more scalable than Linux up until 2.6 arrived, and since no other open source system had this level of scalability (let alone performance and stability) it could only be from-scratch. Where were your PhD.s then? Coding for FreeBSD, obviously. They had the "proper design principles" and "algorithms" going very strongly, while Linux was applying dirty hacks to support new things (you should have seen the early USB support), having never bothered measuring scalability.
  
  --
  Sam ty sig.
17. Re:So? by Anonymous Coward · 2004-10-13 01:23 · Score: -1, Flamebait
  
  "Lifting" isn't too far off - the ULE scheduler was based at least in part on the O(1) scheduler, but without the problems (there were exceptional cases where the O(1) scheduler in Linux performed erratically, but ULE had much cleaner behavior). It had its own problems later, we know, but it doesn't really matter now.
  
  Well yeah it doesn't matter because nobody in FreeBSD knows what's wrong with SCHED_ULE or how to fix it.
  
  What's your point though? Who cares if a BSD takes something from Linux? The number of things that Linux has taken from the BSDs is mind boggling. Early code bases didn't have network support until they ripped the BSD network stack ("lifted" definitely).
  
  Yeah I think they did use some of the BSD network stack early on. They don't now though.
  
  They didn't do that right either - the new open BSDs continue to have infinitely better networking capabilities
  
  I don't think that word means what you think it means.
  
  ("NetBSD 2.0 beats land speed record" twice, and there was that post regarding FreeBSD 5.x routing hundreds/thousands of times as much data over the network as Linux).
  
  No. FreeBSD said they could do 1Mpps while Linux could only do 100Kpps. Linux can actually do a lot more than that (I think I'd seen around 800kpps). I think FreeBSD may have better routing performance here though. Well, FreeBSD 5, anyway, which isn't yet released.
  
  NetBSD did set some records lately, yes. I don't know whether Linux can't match it here or not. It should be able to. FreeBSD definitely wouldn't because it doesn't have SACK (well maybe 5 has SACK).
  
  Linux can push more packets per second though an interface than either though.
  
  The only reason Linux rose to such glamor at all is media hype, certainly not technical merit.
  
  So whatever comes out of your mouth becomes the truth?
  
  There was some geek romance in the notion of a kernel written for users who hate windows, more than for those who love UNIX. The BSDs couldn't care less about fighting off Windows, that's why
  
  For someone who knows as much as you think you do and didn't know Linux was written by someone who couldn't afford UNIX is surprising.
  
  I hate windows because it is an overpriced POS system which I have had the misfortune to have used, but that isn't why I use Linux. It is why I don't use windows. I use Linux because it is a good unix system.
  
  their features are carefully planned and engineered (even at the cost of convenience for users), not just hacked on to make a cool headline and support pro-Linux evangelists.
  
  Sorry, that makes me laugh... Let's say SGI has a multi million dollar 512 CPU system at NASA that has hit some scalability problems in the pagefault path of multithreaded due to contention on a shared lock. I think the last thought on their minds are making some cool headlines.
  
  How about IBM? They are continually putting big money into Linux. I'm sure this is because of its "hype". It obviously has absolutely nothing to do with technical merit at all.
  
  Interesting trivia #74: IBM actually had a lot more BSD hackers than Linux hackers on staff when its Linux program was started. They just thought they'd go with the crappy system with a "commercially unfriendly" license just because it is cool, right?
18. Re:So? by Anonymous Coward · 2004-10-13 11:45 · Score: -1, Troll
  
  Interesting trivia #74: IBM actually had a lot more BSD hackers than Linux hackers on staff when its Linux program was started. They just thought they'd go with the crappy system with a "commercially unfriendly" license just because it is cool, right?
  
  Linux - 1, BSD - 0
19. Re:So? by Anonymous Coward · 2004-10-13 20:40 · Score: 0
  
  Oh, really? Name any CS PhDs who made significant contributions to FreeBSD code base!
20. Re:So? by DashEvil · 2004-10-13 20:51 · Score: 1
  
  Case in Point:
  
  Microsoft has many many more Computer Science Ph.D.s working on Windows than Linux does.
  
  Hmmmmm..... :)
  
  --
  -If God wanted people to be better than me, he would have made them that way.
21. Re:So? by Anonymous Coward · 2004-10-13 21:08 · Score: 0
  
  Are you nuts? Windows has many many more Computer Science Ph.D.s working on it than FreeBSD does, but not Linux.
22. Re:So? by Anonymous Coward · 2004-10-14 07:58 · Score: 0
  
  Have you actually read the Linux kernel code?
  Obviously not.
23. Re:So? by Anonymous Coward · 2004-10-14 08:07 · Score: 0
  
  How about IBM? They are continually putting big money into Linux. I'm sure this is because of its "hype". It obviously has absolutely nothing to do with technical merit at all.
  Uh, yes it does have to do with hype and nothing else. IBM is in the business of making money, not technical excellence. They will sell what they think that their customers want to buy. Period. That decision has only a glance in the direction of technical merit.
  Now, granted, after being forced into that decision by their customers, their engineering department will work on improving the technical merit of the OS.
  For extra bonus points, can you name any point where the best OS was the most popular one? If so, you probably don't know about all of the OSes that have been available. Choosing an OS is a trade-off, and IBM last time I checked was a commercial enterprise and so their primary concern is viability in the market place, not ``technical merit''.
24. Re:So? by Anonymous Coward · 2004-10-14 14:38 · Score: 0
  
  That was the only part of my argument that you could selectively rebut? And it took you three rambling paragraphs?
  
  Sorry come back when you learn to formulate proper arguments and reply to my entire post.
25. Re:So? by Anonymous Coward · 2004-10-14 14:41 · Score: 0
  
  Have you?
  
  Obviously not.
26. Re:So? by Anonymous Coward · 2004-10-14 15:13 · Score: 0
  
  OK, if you've read both... What is one part of the Linux core kernel code that is "dirty" which is cleanly implemented on a BSD (where the two have equivalent features implemented)?
  
  I'd really love to see what you say because I'm genuinely curious to see why people say BSDs are cleaner. You seem like you've looked at the code to make an informed judgement.
  
  Just filenames for each would be fine. Most recent releases too, please.
  
  Thanks.
FreeBSD NetBSD by Anonymous Coward · 2004-10-11 14:59 · Score: 0

I feel like FreeBSD and NetBSD are going to release their milestones in the same time. NetBSD 2.0 and FreeBSD 5.3 will (hopefully) be the first 5.x Production Release for the FreeBSD operating system. Nice work !
Bagged and tagged will be linux IP stack. :-D by ulib · 2004-10-11 22:07 · Score: 2, Funny

NetBSD again sets Internet2 Land Speed World Record (30 Sep)
Heh... the harsh truth of software development (and many other sci/tech fields as well): quality and quantity often don't walk hand in hand. :-)
What To Do?!?!?! by devphaeton · 2004-10-12 04:02 · Score: 2, Insightful

Gosh, with all these delicious BSD releases about to happen, (nbsd 2.0, fbsd 5.3, dbsd 1.0) it makes it hard for a guy to decide which one to play with.

I need some more harddrives so i'll have a place to install them!

--

do() || do_not(); // try();
1. Re:What To Do?!?!?! by Homology · 2004-10-12 06:57 · Score: 2, Insightful
  
  Gosh, with all these delicious BSD releases about to happen, (nbsd 2.0, fbsd 5.3, dbsd 1.0) it makes it hard for a guy to decide which one to play with.
  I need some more harddrives so i'll have a place to install them!
  OpenBSD 3.6 is, as usual, to be released 1th of November. Better make an extra primary partition available for install :-)
Insightful? by Anonymous Coward · 2004-10-12 18:54 · Score: 0

There is a lot I enjoy & admire about NetBSD, and a lot more that I am not the judge of. But I have to flag the parent article as a frothing evangelist on one point of fact:

In my experience, NetBSD ported software packages usually do NOT work on any platform but the one where they were developed. Of course software like cal or bc that runs from the command line & doesn't access any hardware work fine. But my experience of playing around with the Mac68k port of NetBSD 1.6x was that precious few of the downloadable packages were at all useful.

Nobody has even yet figured out how the Mac86k floppy drive[s], nor sound work. Want X? It is supported, on a select few machines--but only at 1-bit pixel depth! I was lucky just to have found a [the?] supported ethernet card and harddrive.

I am sure other non-x86 platforms are pretty much in the same boat. NetBSD, like uClinux, is a great portability project for giving engineers a common environment on which to develop exotic single-purpose gadgetry. And it gives students a well-thought-out kernel to learn from [much more comprehensible than Linux, so I've heard].

But as far as giving the rest of us an installable, useful, fully-ported environment where we can run our preferred day-to-day programs on minority hardware... that just isn't where NetBSD or uClinux are at.
1. Re:Insightful? by setagllib · 2004-10-12 19:06 · Score: 1
  
  I can't speak for every port out there (having only tried i386 myself, due to my own hardware limits), but I'd have thought that page at the end with the in-action shots of NetBSD on unbelievable hardware would have served as enough evidence. Of course you can't have every bit of software work everywhere - X on graphics calculator? - but enough does to get something interesting done. Look, there's one shot there of a guy running NetBSD on his StrongArm-based MP3 jukebox, capable of using the audio adapter and optical drives and input. What more do you want?
  
  One thing that surprised me was that NetBSD doesn't have an XBox port. This could be because of the usual "why would any serious developer want that? It's a Linux geek thing", but then again the whole low-cost-okay-power side leaves room for questioning.
  
  --
  Sam ty sig.
Trollsh*t. by Anonymous Coward · 2004-10-13 22:14 · Score: 0

Windows development resources (and their qualifications, like CompSci Ph.D. etc.) are *orders of magnitude* bigger than whatever Linux has.
Whoever denies it (and it's just you, dear troll) is just a pathetic clueless lamer.
One suggestion: learn to code. I know it's very, very arduous to some kind of people, but in the end it could turn out to be fun. Then maybe you'll start to appreciate projects like FreeBSD.
Oh.. but in the meantime, you can go f*ck yourself, of course. :-)
1. Re:Trollsh*t. by Anonymous Coward · 2004-10-14 03:00 · Score: 0
  
  Yes you're very funny. But seriously now, how many people on the Windows NT kernel team?
Here you are by setagllib · 2004-10-14 18:01 · Score: 1

I didn't have to look far. Driver for Broadcom 440x network cards (like the one in the laptop I'm talking from)

Linux 2.6.9-rc4-mm1: drivers/net/b44.c
NetBSD 2.0: src/sys/dev/pci/if_bce.c

Come on. The Linux one can even pass as bloated:

44K /home/nbsd/src/sys/dev/pci/if_bce.c
48K /usr/src/linux/drivers/net/b44.c

A colossal 4kb larger. And a lot of the code within is dirty, but you asked for file names only, right? The Linux one even uses spinlocks where they are completely unnecessary. It has many more functions than the NetBSD one, implying a heavily complicated driver handling concept, or possibly just a sloppy design. Real coders know how many primitive objects to split a design into, and it's clear who's the real coder:

dirk root # exuberant-ctags -x /home/nbsd/src/sys/dev/pci/if_bce.c | grep func | wc -l
22
dirk root # exuberant-ctags -x /usr/src/linux/drivers/net/b44.c | grep func | wc -l
69

Granted the NetBSD source (like the other non-DragonFly BSDs) is mostly in K&R C, which many consider 'dirty' (even if technically more interoperable, which pays dividends in NetBSD's ability to be compiled on virtually any system). That's splitting hairs though. It still manages to be smaller and tighter than the Linux code in spite of the 'redundant' argument naming of K&R.

Anything else you wanted? You seem owned to me. Go back to not knowing about code.

--
Sam ty sig.
1. Re:Here you are by setagllib · 2004-10-14 21:00 · Score: 1
  
  Actually, while I'm here, may as well remind all Linux cleanliness evangelists: DEVFS
  
  Core devs agree it's a crap sandwich and needs to be pulled out if not too many users base their lives on it. It clutters every driver with a device node, it is flaky and undermaintained, and flawed by design. Read the mailing lists.
  
  FreeBSD 5.x has a devfs that is not overbearing, that is clean (including /dev itself, which is as clean as 'pure udev') and stable, entirely in kernel-land (unlike udev), and doesn't need any configuration anywhere to work, and on top of that has no adverse side effects. It is not functionally equivalent to devfs (which had the whole long name tree, to cover up for silly naming ideas early in Linux' life), nor udev, but as is UNIX philosophy, it is clean, solid, and does exactly what it was designed to do.
  
  I can say the same things about ACPI integration (events just Work, no need to configure or write shell scripts just to automate power management), and NFS (Linux needs a local portmap daemon in userspace to mount NFS, else the mount process idles for particularly long times! How the hell is that clean behavior?).
  
  What about reeBSD's pcm(4) vs ALSA?
  Provides much the same functionality for most users, but it provides it more maturely, with kernel-level mixing (since many chipsets don't do hardware, and ALSA does not compensate), OSS compatibility as a feature - not as an extra layer - and a clean /dev/dsp* and /dev/mixer* naming structure that only gets cleaner with devfs, but still conforms to OSS standards. Multiple sound card support, very high quality sound itself, transparent and fast kernel-level channel mixing, and support for most of the same cards without the bugs... yes. That's why FreeBSD's sound is great. ALSA has more functionality in the end, which few people actually need anyway. It requires extra modules (at least for 2.4) and libraries (which are nothing resembling tight), had memory leak bugs up until about 1.0.4, requires yet more libraries to be compatible with OSS, and requires its own toolchain to control it (alsactl, alsamixer...), else your volumes are muted by default. Clever (cough).
  
  Clean code not enough for many, clean design is where BSDs rule the scene. You cannot possibly refute that.
  
  --
  Sam ty sig.
2. Re:Here you are by Anonymous Coward · 2004-10-15 01:28 · Score: 0
  
  Yeah the filenames of the dirty code so I could look and verify myself. Did you think I would ask you to paste hundreds of lines from each here?
  
  Oh, nice "core" kernel code, buddy. Real nice. Go back to now knowing about kernels.
3. Re:Here you are by setagllib · 2004-10-15 10:32 · Score: 1
  
  Oh, right, missed that 'core' in your post. It was lost in the waves of arrogance and ignorance.
  
  Well what's your point? Code is code. Core or fringe doesn't matter, it all still compiles into one binary. One very dirty binary. How often routines get called doesn't justify not cleaning an infrequent algorithm.
  
  I think your point was that you knew (or thought) that core code would be the focus of maximal effort, and so I wouldn't have a point there. But I said just code. And I showed you kernel code - not necessarily core, who really cares? - that justified my claims.
  
  Go back to not knowing about arguments.
  (This is getting boring)
  
  --
  Sam ty sig.
4. Re:Here you are by Anonymous Coward · 2004-10-15 17:27 · Score: 0
  
  No code is not code. If you want me to find you some terribly broken, not working, or dirty FreeBSD drivers it isn't terribly difficult.
  
  Go back to not knowing about kernels.
5. Re:Here you are by Anonymous Coward · 2004-10-15 23:10 · Score: 0
  
  Come on. The Linux one can even pass as bloated:
  
  44K /home/nbsd/src/sys/dev/pci/if_bce.c
  48K /usr/src/linux/drivers/net/b44.c
  
  Are you insane? That doesn't mean anything. Comments, layout etc will all "bloat" source files. Maybe if you compared object sizes with the same compiler. Maybe. But Linux's supports hotplug and suspend. Does NetBSDs?
  
  The Linux one even uses spinlocks where they are completely unnecessary.
  
  Linux implements fine grained locking.
  
  It has many more functions than the NetBSD one, implying a heavily complicated driver handling concept, or possibly just a sloppy design. Real coders know how many primitive objects to split a design into, and it's clear who's the real coder:
  
  dirk root # exuberant-ctags -x /home/nbsd/src/sys/dev/pci/if_bce.c | grep func | wc -l
  22
  dirk root # exuberant-ctags -x /usr/src/linux/drivers/net/b44.c | grep func | wc -l
  69
  
  Nice work from the armchair coder. You have got to be a pointy haired boss, right?
  
  Let's have a look at the lengths of some some of the functions in the NetBSD driver. 227 lines, 129, 73, 169.
  
  227 lines is 9 1/2 (standard unix) pages long. I sure don't write my functions that long.
  
  By contrast, the longest function in Linux is 145 lines (which is still quite long) and is the init function. The rest of the functions are under 3 pages.
  
  I'll take the Linux version, thanks. Anything else you care to throw at me? I don't think I'm "owned" at all.
  
  Go back to being an armchair coder and honorary PHB.
6. Re:Here you are by Anonymous Coward · 2004-10-16 06:05 · Score: 0
  
  Linux implements fine grained locking.
  
  Yup.. thats why NetBSD didn't have SMP in a release OS until 2.0. They started with "biglock" in -current, and made it more finely-grained over time, until they felt it was ready for release.
  
  As opposed to Linux, that had the biglock starting in 2.2 (2.0?) and didn't go truely finely grained until 2.6. Proves the point, exactly, that NetBSD prefers to "do it right the first time" instead of releasing poorly implemented hacks and then spend time redesigning things over and over.
  
  And, from a coding and performance point of view, breaking things into too many modules, FYI, can be a performance hit from pushing registers onto the stack all the time. I've been coding for 20 years, and quite a bit of it OS level. If you've never written a proceedure over 200 lines.. well, I won't go there. Suffice it to say that OS performance is more important sometimes over modularity. A lot of the reason I like NetBSD is that a lot of the older architectures are *actively* supported (and in-tree), and a lot of times performance issues can be far more blatant on a slower box than on that shiney P4/3.5ghz box. Making the code perform well on slower boxes also provides performance gain on faster boxes.
7. Re:Here you are by Anonymous Coward · 2004-10-16 13:57 · Score: 0
  
  Yup.. thats why NetBSD didn't have SMP in a release OS until 2.0. They started with "biglock" in -current, and made it more finely-grained over time, until they felt it was ready for release.
  
  NetBSD isn't fine grained.
  
  As opposed to Linux, that had the biglock starting in 2.2 (2.0?) and didn't go truely finely grained until 2.6. Proves the point, exactly, that NetBSD prefers to "do it right the first time" instead of releasing poorly implemented hacks and then spend time redesigning things over and over.
  
  There was nothing wrong with how Linux did it. 2.0 and 2.2 were "right the first time" because nobody was using Linux on > 4 way. 2.4 was "right the first time" because nobody was using Linux on > 16 way. Linux 2.6 was right the first time because nobody is using Linux on > 512 way. Well, SGI will go 2048-way when they increase their cache coherency domain on the Altix to 512 nodes, and get dual core Itaniums. Well from a scalability standpoint it will be 4096 CPU contexts because they'll also be multithreaded.
  
  And, from a coding and performance point of view, breaking things into too many modules, FYI, can be a performance hit from pushing registers onto the stack all the time. I've been coding for 20 years, and quite a bit of it OS level.
  
  Sorry old timer, I use the inline keyword or even let gcc inline static functions that are only called once for me.
  
  If you've never written a proceedure over 200 lines.. well, I won't go there. Suffice it to say that OS performance is more important sometimes over modularity.
  
  If you think a driver should be micro optimised by squashing functions together then I'm glad you're not writing my OS.
  
  A lot of the reason I like NetBSD is that a lot of the older architectures are *actively* supported (and in-tree), and a lot of times performance issues can be far more blatant on a slower box than on that shiney P4/3.5ghz box. Making the code perform well on slower boxes also provides performance gain on faster boxes.
  
  Except that NetBSD is slower in basic operations than Linux, like network packet tx/rx overhead, syscall overhead, context switching, fork, page fault, page allocation, etc.
8. Re:Here you are by setagllib · 2004-10-16 21:13 · Score: 1
  
  Except that NetBSD is slower in basic operations than Linux, like network packet tx/rx overhead, syscall overhead, context switching, fork, page fault, page allocation, etc.
  
  Really? Show us. No, I'm not saying you're wrong (I saw an *old* bench showing that Scheduler Activations had pretty slow context switching compared to Linux, and a note saying it would be worked on), but I just haven't heard of this, let alone seen conclusive and objective figures to back it up.
  
  On a related note, I don't think anyone is arguing that Linux has a very fine grained and high performing core, it's everything around it. In much the same way, FreeBSD 5.x now has a very tight core, but the locking design and the number of things still Giant-Locked make the system run fiendishly slow anyway. You only notice these things in practice, and I have in fact noticed similar behavior with Linux (compiling two things at the same time - no, not using -j - can be a real exercise in patience)
  
  On a related note, http://news.gw.com/netbsd.ports.i386/%3C2004072610 2903.GA21256@antioche.lip6.fr%3E
  Linux gets slower using SMP on HTT (2.6.6, as I recall, the first mainline kernel to gain hyperthreading - please correct me), NetBSD gets faster. I think that, considering this, NetBSD'S SMP/SMT support is quite alright, and would be even better when hyperthreading scheduling policies are developed. Unless anyone shows figures that disprove this, of course... (invitation)
  
  --
  Sam ty sig.
9. Re:Here you are by Anonymous Coward · 2004-10-16 23:14 · Score: 0
  
  Our devote Troll utters this *gross* BS:
  Except that NetBSD is slower in basic operations than Linux, like network packet tx/rx overhead, ...
  NetBSD again sets Internet2 Land Speed World Record (30 Sep)
  :-)
  ... and in the web page of the lab (and in a comment to a /. story of this spring, thru the words of the researcher himself), they say *why* NetBSD was chosen over Linux. I'll sum it up in 2 words:
  better-code.
  Trolly, go home! :-D
10. Re:Here you are by Anonymous Coward · 2004-10-17 00:09 · Score: 0
  
  Err, TCP implementation is not the same as how many packets per second your network stack can push.
  
  Especially for long distance high bandwidth links, the high level TCP features play a more important role.
  
  Also, they didn't say whether or not they tested Linux. There is no reason why it shouldn't be able to do as well (much TCP algorithm research and tuning is done outside the various OS development camps, and they all end up sucking up basically the same set of RFCs sooner or later).
  
  So no, if you want to disprove me, find out how many cycles it takes a packet to propogate from userspace to the wire and vice versa (or blast a stream over crossover Gbe and measure CPU utilisation).
11. Re:Here you are by Anonymous Coward · 2004-10-18 09:32 · Score: 0
  
  Also, they didn't say whether or not they tested Linux.
  Yes, they *did* test Linux and it performed quite poorly.
  They said it themselves, in a comment to the /. story I linked.