Slashdot Mirror

Where does Linux fail where BSD succeeds?

For some people it's the licensing (BSD vs GPL). For others it is the coherence of the system (how many places hide an IP address in Red Hat?). For others, it is a question of style (BSD vs AT&T type Unix). For some, its functionality (I always liked the way the BSD _______ command worked). From some, it's the simple Joy of BSD, or the McKusick - take your pick. For some, it could be the approach taken to a particular problem taken by one of the BSDs, such as the continuous OpenBSD code audits. For some it might be a particular platform maintained as part of the main distribution. For some, it may be the continuing BSD innovations. For some it might be the counter-culture aspect BSD in the Linux world. Plenty more reasons that people could have, including: Linux - 5 letters, BSD - 3 letters. Do the math.

You could say that the only truly popular Unix desktop is Apple's Macintosh running OS X.
Mac OS X: What is BSD?

What's The Greatest Software Ever Written?

OpenBSD FreeBSD NetBSD PC BSD

FreeBSD Mall BSD Magazine

To each his own.

Secondly, a lot of code in Linux is created to follow POSIX standards. There is code in SCO Unix and Linux which looks very similar, but the source for the material is the IEEE Posix standard, not SCO Unix source code.

• Thinking in C++ by Bruce Eckel http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
• Computer Networks by Andrew Tanenbaum http://www.prenhall.com/tanenbaum/details2.html
• Structured Computer Organization by Andrew Tanenbaum http://www.pearsonhighered.com/educator/academic/product/0,,0131485210,00%2Ben-USS_01DBC.html
• Producing Open Source Software by Karl Fogel http://producingoss.com/
• Design and Implementation of the FreeBSD Operating System by Marshall Kirk McKusick and George V. Neville-Neil http://www.mckusick.com/books.html
• Code Quality by Diomidis Spinellis http://www.spinellis.gr/codequality/

The very best course I have found is a ~32 hour DVD course on the FreeBSD kernel internals and: Advanced FreeBSD Kernel Code Walkthrough Videos I've never found anything more thorough.

The very best course I have found is a ~32 hour DVD course on the FreeBSD kernel internals and: Advanced FreeBSD Kernel Code Walkthrough Videos I've never found anything more thorough.

It's not even that. It is a platypus in a daemons clothing. The real daemon, Beastie, is not on that list.

Its not like softupdates are a superior solution to the same problem or anything.

This is a troll. "Background FSCK" isn't BSD's answer to journaling. Soft updates is Dr. McKusick's implementation to maintain filesystem integrity in the event of a system failure. BSD doesn't need journaling, it has soft udpates. You need to read:

http://www.usenix.org/publications/library/proceed ings/usenix2000/general/seltzer.html

http://www.mckusick.com/softdep/

Just hope they don't install it in any fighter jets.

Penguins may have wings, but they CAN'T FLY.

But, of course, the hotter it gets, the more appropriate BSD becomes.

McKusick trademarked the red-demon who represents BSD. No, it is only copyrighted: http://www.mckusick.com/beastie/mainpage/copyright .html

His name's not Chuck.

I'm a huge advocate of McKusick's Kernel Internals course. It's essential for anyone serious about understanding the core components of the OS. The videos are like a grand, but you can find it free in a lot of libraries, or you might be lucky to catch a copy on half.com.

FreeBSD, being rather generic in focus, is a tougher one to design for. Maybe the guy who owns the beastie copyright will transfer it to FreeBSD (or grant unlimited license, etc.) and beastie will become official.

He's a cool guy actually. He's written books, papers and BSD code and most recently on a book on FreeBSD, so who knows. I don't know if FreeBSD would want exclusive rights to Beastie though. Since Beastie has such a general BSD history, FreeBSD would probably still want an image for their own identity.

I doubt if BSD architectMarshall Kirk McKusick has ever kissed a girl!

Anyway, the article's 100% correct. Linux sucks. BSD R00LZ. It's that simple.

NetBSD is hampered by poor scalability and its limited rudimentary SMP.

SMP, yes at the moment. But Uni proc scalability? I don't think so. This looks interesting too.

NetBSD also lacks a production ready journaling file system.

With Soft Updates, it doesn't need it.

Chuck is not and has never been the name of the daemon.

If you wish to argue this fact, please take it up with Mr. McKusick.

About 1 year after Usenix produced the Portland conference T-shirts, they paid Phil for the artwork. Thus, Usenix currently holds title to the copyright.

The BSD daemon showed up again on the shirt shown in the second picture for the Usenix multimedia conference held in 1991 in Nashville Tennessee.

I've followed you second link, and I still don't see any "disagreement" with BSD. The second hand rumour (and that's all it is, a second hand rumour) of your link involves DEC, not BSD.

You asserted that Phil inspired the modern BSD daemon (Beastie). This is absolutely incorrect. For the link happy, here's the pictoral history of Beasty.

Part I, Overview

Three introductory chapters provide the context for the complete operating system and for the rest of the book.

History and Goals, sketches the historical development of the system, emphasizing the system's research orientation.

Design Overview of FreeBSD, describes the services offered by the system, and outlines the internal organization of the kernel. It also discusses the design decisions that were made as the system was developed.

Kernel Services, explains how system calls are done, and describes in detail several of the basic services of the kernel.

Part II, Processes

Process Management, lays the foundation for later chapters by describing the structure of a process, the algorithms used for scheduling the execution of the threads that make up a process, and the synchronization mechanisms used by the system to ensure consistent access to kernel-resident data structures.

Memory Management, the virtual-memory-management system is discussed in detail.

Part III, I/O System

I/O System Overview, explains the system interface to I/O and describes the structure of the facilities that support this interface.

Following this introduction are four chapters that give the details of the main parts of the I/O system.

Devices, gives a description of the I/O architecture of the PC, describes how the I/O subsystem is managed, and how the kernel initially maps out and later manages the arrival and departure of connected devices.

Local Filesystems, details the data structures and algorithms that implement filesystems as seen by application programs as well as how local filesystems are interfaced with the device interface described earlier.

The Network Filesystem, explains the network filesystem from both the server and client perspectives.

Terminal Handling, discusses support for character terminals, and provides a description of the pseudo-terminal device driver.

Part IV, Interprocess Communication

Interprocess Communication, describes the mechanism for providing communication between related or unrelated processes.

Network Communication and Network Protocols, are closely related, as the facilities explained in the former are implemented by specific protocols, such as the TCP/IP protocol suite, explained in the latter.

Part V, System Operation

Startup and Shutdown, discusses system startup and shutdown and explains system initialization at the process level, from kernel initialization to user login.

This book reminds me of Marc Rockhind's "Advanced Unix Programming", but is less technical in nature.

The chapter on BSD make was interesting, a topic not usually covered because most people use GNU Make these days.

And the section on kqueue(2) was interesting, although very superficial.

Everything else would be largely familiar to anyone who's familiar with the Unix programming idiom.

As someone who cut his teeth on "The Design and Implementation of the 4.3BSD Operating System", I'm eagerly anticipating McKusick's book on FreeBSD 5.2, to be released in August. http://www.mckusick.com/FreeBSDbook.html

Actually, the mascot of rec.motorcycles is Chuck Rogers'"geeky", himself likely derived from/inspired by McKusick's BSD daemon.

You'd think that a group that named themselves after the BSD Daemon would be more Free Software friendly.

One of the main points of the article is that the (earlier) Linux versions lack any kind of CVS logs. The situation has been remedied when Linus started using BitKeeper, but there are years of development that cannot be tracked using a single source revision control system. This makes things quite complicated as the developers must dig through mailing lists and other means of communication to find out who really wrote what. "[...] they will have to dig themselves out of the swamp [...]", as said by McKusick.

(Oh yes, and just so you know, Marshall Kirk McKusick isn't just some law-monkey, he is one of the leading BSD developers and has, among a lot of other stuff, written stuff such as the SoftUpdates FreeVSD filesystem extension which allows for running fsck as a background process during normal system operation.)

One of the main points of the article is that the (earlier) Linux versions lack any kind of CVS logs. The situation has been remedied when Linus started using BitKeeper, but there are years of development that cannot be tracked using a single source revision control system. This makes things quite complicated as the developers must dig through mailing lists and other means of communication to find out who really wrote what. "[...] they will have to dig themselves out of the swamp [...]", as said by McKusick.

(Oh yes, and just so you know, Marshall Kirk McKusick isn't just some law-monkey, he is one of the leading BSD developers and has, among a lot of other stuff, written stuff such as the SoftUpdates FreeVSD filesystem extension which allows for running fsck as a background process during normal system operation.)

who would run it on a public network?

I'm the kind of person who has run Minix, ya know. Because it's there. I used to have an Altos box that ran Microsoft Xenix (the System III port, from before SCO) Ancient Unixes are cool. I have an AIX box with Power 1 processor (back when POWER was a bunch of chips.) I have old Sparc boxes. I don't have a PDP-11 yet, tho. I ordered the CSRG Archives CD set direct from Kirk McKusick, though, for if and when I do.

And yes, I use NetBSD on anything that has a public face on the Net.

you can also use UFS

Um, except that it's the UFS in FreeBSD 3.x. Which is about 3 years behind during some very ACTIVE programming years.

So apple is missing:

• Dirhash
• Softupdates
• Snapshots
• background fsck (KILLER when you hard stop a box with 500GB disk.

Software patents, though stupid, are a last ditch effort of the old order trying desperately to cling to the unchallenged market dominance it once had. Too little, too late.

And let's not forget, friends of Open Source, that not all of these commericial entities are bad. IBM, with its monstrous patent portfolio has done wonders for Linux, donating powerful technologies such as RCU and NUMA.

Open Source has fought and won bigger battles than this. It has emerged from obscurity against all odds, amazing even those who have been central to its development. Whole operating systems, relational database manangement systems, web and application servers, office suites, desktop managers, clustering technologies, programming languages, advanced firewall and routing technologies, cross platform widget libraries, XML parsers, TCP/IP implementations, accounting and ERP systems --- the list goes on --- have risen from humble beginnings, from good people who have had the good nature, intelligence, and courage to create them. They have overcome the ridicule of trade journals and imbecilic IT pundits, emerged victorous from opressive corporate lawsuites (AT&T, SCO), and have not only made a name for themselves in the mainstream, but in many cases have also shown themselves to be vastly superior to their commercial counterparts.

Kirk McKusick, in his History of Unix at Berkeley recalled when the members of the CSRG first talked about actually trying to free BSD UNIX from AT&T and make it available to the public. Kirk and Mike Karrels, who thought this idea was pipe dreams at best, told Sam Leffler or Steve Bostic (I can't remember which) that they would address the kernel only after free versions of all system programs and utilities had been rewritten. They figured this was a nice way of saying it's never going to happen. Well Sam/Steve went to work getting the word out. At first, there were a few simple utilities that came in, like cat and ls, and more. But after some months, larger things started to roll it, and more and more utilities were falling into place, until one day someone (I believe it was James Clark) announced that he had completely rewritten nroff to the tune of 75,000 lines of code. At that point, Kirk looked at Mike and said something like "Oh Shit, they're really serious about this." A couple years later, BSD UNIX --- the good UNIX --- was free to the world, but only after a fierce and in some cases very personal assault from AT&T.

Despite the best efforts of ridiculous software patents and corrupt politicians brought to you by Microsoft, the hardest part of the battle has been won. This is at best just the Battle of the Bulge in the world war of Gates and Co. It may be painful and difficult, but the heroes of open source have already prevailed. They have shown themselves impervious to the FUD. They have shown themselves powerful enough to develop every kind of software, and capable enough to make it better than many commercial equivalents.

It is because of what they have created, along with us the open source community who have put it to use in our products, businesses,

Could it be...... SATAN?

However, these angry troll/devil hybrids in sneakers trampling over what appears to be a lot of desktop computer hardware however, is evidently what is found in need of an update.

I can list a few likely reasons for changing this, off the top of my head:

One thing is that devils is a somewhat religious device, not found in all religions.

Then there is the aesthetics of this. The logo is just kinda ugly. These guys are not all that different in appearance from some football hooligans... and after all, there is a strong element of marketing here, whether we like it or not. Would you want to buy an operating systems from these guys?

Political correctness or accusations of same, marketing and aestetics aside, I would say it is just as much that the design of the monitors is becoming dated, since many of us now have relatively skinny LCDs, not fat CRT-based ones. If nothing else, the logo is becoming tecnically dated.

All these could, individually, be considered warrants for change.

And then the damn head marketing weenie (whom we hired from *SCO* of all places... think big red horns on her head, and that was long before this current fiasco...

(snicker)

Well, you told me to think big red horns on her head.

Dunno if it's relevant, or useful, but if it is (our could be), there's a claim that Caldera was willing to "release 32/V under an open source license." The Unix Heritage Society is also cited as being partly responsible for that.

Anyone know how to follow up on/verify the claim?

You can also try the computer devil. He initially looks like a torturer, but after a while you'll understand that he's just teaching you how to understand the computer and intelligently automate repetitive tasks.

The real story is a very interesting one, and anyone interested should do one of two things: Either read the condensed version as one of the chapters of the book Open Sources or go buy a copy of the videotape of Kirk telling the story himself (surely the best $49 I've ever spent on videotape).

JFS, other journalled file systems, and Softupdates have the same goal -- keeping file metadata structures consistent on the disk. JFS does not attempt to maintain file data integrity in the event of a crash -- that is the job of a DBMS. Go and read the web page on JFS from IBM that is linked to in the original posting.

Granted, journalled FS's and softupdates go about things in different ways. Softupdates trades off potentially increased disk space usage and higher disk and CPU activity after a crash (performing the background, reduced set of checks in fsck) against a smaller relative performance penalty vs. a non-journalled FS in normal usage as compared to a journalled file system.

My own $0.02 is that this is a nice scratch-the-itch, check-the-box-for-PHB's addition, but for most normal usage softupdates is a better choice. See the papers by Ganger and Patt and McKusick for more details. (Links copied from the OpenBSD FAQ pages.)

--Paul

and thank the good lord for that!!

4. linux has a journaling filesystem, freebsd doesn't

Snapshotting is what you really want for something like this. NetApp has had this functionality available in their Filer appliances for a number of years - you can cd into a 'magic' .snapshot directory where hourly, daily, weekly, and monthly snapshots are kept.

FreeBSD 5.0-CURRENT includes preliminary snapshot support for ffs.

The Linux options aren't quite as good. The most promising new filesystem that could provide this functionality is tux2, where data is structured in a way that would make implementing this functionality fairly easy. There was a post explaining how it would work in the mail archives, but they seem to have disappeared.

There is commercial option: MVD Snap. Their fileserver is Linux based, and the code for their snapfs filesystem was once available during beta testing.

If you want to have access to the Ancient BSD source codes, have a look at CSRG Archive CD-ROMs.

I wonder if there are archives of mailing-lists also, since you can't use code without comments :-)

Why should we explain it when this and this do it so much better? Are you trolling, or can you educate yourself?

Could they be a little more specific ? How was it analyized ?

I doubt that number was. For some real benchmarks you can look at Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems from the 2000 Usenix Procedings. In addition to having useful info in and of itself it has references to other information. You can also try McKusic's home pages he may have newer info that, and does have some info about the experimental checkpointing.

I don't know about dirperf though. Never seen a paper on it.

Softupdates can guartantee consistency in case of crashes, thus providing save yet asynchronous-like performance (i.e. optimal performance).

Details are explained on the website of the author, Kirk McKusick. Also you can find a link there which leads to an interesting (technical) comparison of logging (aka journalling) versus softupdates.

I wish someone would port softupdates to linux (ext2fs). Or better yet, make BSD's FFS+softupdates a native Linux filesystem. It would surely outperform the other currently available filesystems. At least on my computer, when I benchmark FreeBSD+FFS+softupdates against Linux+ext2fs/reiserfs (on the same hardware, disk, disklocation) FFS+softupdates consistently wins hands down. I don't think this is because of FreeBSD's kernel, but rather because of softupdates (and FFS with it's large blocksize combined with smaller fragments to avoid too much slack).

The only advantage the new FSes hold is probably their journaling capability, leading to faster fscks, faster bootups and less risk of data loss. Did we really need a new set of filesystems for that? ( BSD Soft Updates show that the whole speed and reliability advantage can be had with old filesystems as well!) Where's the advantage? Where's the progress? The benchmarks only leave me disappointed.

McKusick, the creator of the logo, has asked that he be referred to as the daemon, and if anything else, "Chuck."

Ahem. He has asked that it be called "Beastie". Where do you people get "Chuck" from? It's an awful name for him.

As for why not to use memory filesystems, it's because most implementations have the memory filesystem as a device not unlike a harddrive, and then place a filesystem on top of that. So you've got the overhead of a filesystem on top of the overhead of the memory disk.

As a rule, they aren't worth the hassle. Like most filesystem discussions, there _are_ cases where a technique shows its strengths. Memory filesystems have more weaknesses than strengths.

If you go to mckusick.com, you can buy a 4 CD set containing all the original BSD src. However, you will need to have an ancient Unix source license, according to the web page. There's a link on how to get one listed on the web page.

Have Softupdates enabled? It'll create an increase in performance that's definetly noticable.

But, you need to remember, that with filesystems it's very hard to compare them. One filesystem may be better at large appends to a few number of files, while another can handle many small files with ease.

Talk about a complete lack of research-- these guys just made up something that sounded good. According to Kirk McKusick, current copyright holder of the BSD Daemon, the term 'daemon' comes directly from the mythological creatures of the same name responsible for taking care of mundane tasks.

For more detail, see Webster's dictionary, in this case we are looking at variant 2, "an attendant power or spirit". Whether daemons are evil as in "demon" variant 1 depends on whether they are working or not. Some days sendmail definately qualifies as the latter.