Slashdot Mirror
Matt Dillon On FreeBSD 5.0 VM System And More
JigSaw writes: "OSNews features a very interesting interview regarding FreeBSD 5 with the guy responsible for the very good (technically) FreeBSD VM among other things. Matt Dillon talks about everything: FreeBSD 5, Linux, .NET and much more. Additionally, OSNews also includes two mini interviews with the NetBSD and OpenBSD head developers."
This guy makes several good arguments for *BSD, mainly, the difference between *BSD and Linux for the desktop. Many people think that *BSD is only the shell, but GNOME and KDE can be compiled on it just as easily as on Linux, no compatability code needed. Also, his point about .NET is a good one, that Microsoft is just using it as buzzword VaporWare to name whatever the new latest and greatest product that will "change the world".
Consider one of Dillon's points: "A great deal of what people label as 'Linux' isn't actually Linux."
As a long-time FreeBSD user, I am fascinated when Linux users go to bat citing so many popular open source applications as Linux applications. Very few of the thousands of applications out there need to run in Linux "emulation" mode on FreeBSD. Almost all applications build and run similarly on FreeBSD as Linux.
I read print magazines such as Linux Journal and visit many Linux web sites, knowing that the content is very much applicable to my OS of choice.
I think Linux is going through a somewhat painful transition as it moves away from a Wild-West/Darwinist development methodology into something a bit more thoughtful. I will admit to wanting to take a clue-bat to some of the people arguing against Rik's VM work who simply do not understand the difference between optimizing a few nanoseconds out of a routine that is rarely called verses spending a few extra cpu cycles to choose the best pages to recycle in order to avoid disk I/O that would cost tens of millions of cpu cycles later on. It is an attitude I had when I was maybe 16 years old... that every clock cycle matters no matter how its spent. Bull!
This has got to be the BEST description of the Linux development to date that I've heard! (And it's got me rolling on the floor with laughter!)
Seriously, when are people (in Linux, Windows, C, C++, Java, etc. camps) going to learn that design is paramount? We don't design things because we are old farts who have no clue about "how to make a system fast", we design them to get the best tradeoff between performance, stability, structure, and maintainability. Anyone who says "I don't care about those things" is talking out of his ass and will not truely become a good programmer until (s)he can admit that code should be well designed.
Javascript + Nintendo DSi = DSiCade
M. Dillon writes:
Open-source operates behind the scenes far more then it operates in the public eye, and it's hard to sell support to hackers who actually have *fun* trying to figure out a problem. In some respects Linux and the BSDs are poor commercialization candidates because they are *too* good... that they simply do not require the level of support that something like Windows-NT or Oracle might require in a back-office setting.
This sounds like sane reasoning but conraditory to quite a few "service and support" business models (e.g Red Hat). It will be interesting to see who's right. Perhaps proprietary solutions build as userspace applications running on top of Free platforms would be a better? Would that be frowned on by anyone? Not me.
Also, is anyone able to describe the degree to which the new VMs of both Linux and FreeBSD are similar? What are the concepts behind them that distinguish them from other and earlier VMs?
I could spout technical details all day, but it wouldn't mean anything. Instead, let me try to take it from a different perspective.
When a transmission for a car is designed, one of the greatest criteria is that the transmission shift smoothly instead vs. quickly. Would you drive a car that would shift extermely fast but cause the car to lurch every time it did? Probably not. The car must work smoothly at all times so that the driver can maintain control and keep the car in good condition. What might happen if the driver were to rev out the engine during one of these super-fast shifts? That's right, he might drop the trans (very expensive).
By the same token, both Windows and Linux (don't start on me) have very "fast" VMs that will perform extremely well under very particular circumstances. When they are removed from those circumstances, they begin to perform extremely poor.
As an example, a few years ago I was using a Pentium 120 w/ 16MB of RAM. Under Window 95 I was starting to run into performance problems (read: chugging) every time I tried to really use the system. This chugging was caused by the fact that Windows would end up thrashing the VM because there wasn't enough actual memory. So, I loaded up Linux using KDE (1.x). It chugged WORSE! When I finally tried FreeBSD with KDE (same setup), I found that the whole system ran smoothly. If I tried to run too much, the program in question at the moment would take longer to execute but would make it up without impacting any of the other programs. Did FreeBSD actually run slower? Perhaps in certain circumstances that were advantagous to Linux, but overall system performace was much more useful and enjoyable.
Javascript + Nintendo DSi = DSiCade
This would indeed be a nice thing to have, and was, in fact, the subject of two years of work at my previous employer.
We were developing a filesystem named, variously, Charon, CXFS, and SSFS (Charon and CXFS turned out to be other people's trademarks).
It was a 64-bit journaled filesystem that used extensible hashing for directory layout, and provided named streams, ACLs and per-object quotas (i.e., per-volume, per-directory and per-file block and inode quotas). It used a distributed journaling system to synchronize data among several peers, and could perform partial filesystem replication (i.e., client local fs device size is smaller than server local fs device size, but client fs appears to be as large as the server's fs).
It included a system for mapping the local OS authentication and security identifiers to those from the other OSes participating in a replication group (such as unix UIDs/GIDs to NT SIDs, to kerberos tickets, etc.). All filesystem entities has 128-bit UUIDs to aid in this mapping.
We had begun port to FreeBSD and Windows 2000.
We were about 4 months short of having an alpha relase on Linux 2.4 before the company went bust. In short, it was over-engineered, and too ambitious. We should have started smaller; for instance, Linux 2.4 only, with nfs-style 'security'. Or FreeBSD-only.
After the sudden, complete, and total demise of the company we worked for, all of us on the team had to put our energy into paying bills and finding a job. So not much has happened since The End.
I can provide design info and even code if someone wants to help.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I think he's saying two different things.
To give context, he's discussing full transparent process migration, so a process can move *completely* to new hardware, transparently. If this were the case, you could build a 'true' cluster where tasks could move around to different hardware at will.
He's saying that current 'clustering' solutions are NOTHING like this. They are all application specific. Veritas, Sun, whoever is offering you clustering technology is simply offering you their own version of something you can probably think up at home.
He's saying, in point 2, that to have real QOS you need to have redundant hardware, but the unwritten context is that it's not really 'redundant' if processes can't switch to it seamlessly. Otherwise it's just 'other' hardware.
The Linux VM can easily bring my system to a complete halt under high memory usage (by no means extreme). That is not to say FreeBSD's VM that great -- I've never tried it, but it has a good reputation. I mean to say that Linux's VM is disgraceful.
These linux-isms are popping up everywhere now, and just plain causing crossplatform (or at least differing unix platforms) problems.
For those who haven't figured it out yet, let me clue you in on a couple of facts:
1) The linux kernel is specific to Linux. If you make linux specific kernel calls then your program will only run under Linux. If you're writing a kernel module, then go for it. Otherwise forget it. It will only make you look stupid.
2) A Standard C Library (libc) is standard for every Unix and Unix-like operating system. For 99 systems out of 100, this libc will NOT come from GNU. If you write a program that makes use of glibc extensions, your program will not be portable. It will only make you look stupid.
A Government Is a Body of People, Usually Notably Ungoverned
In regards to the desktop... well, I'm not sure exactly what you are asking. Both Linux and FreeBSD are in the same boat there... the only way to drive desktop acceptance is to ship machines pre-installed with the OS (whatever OS) and preconfigured with a desktop so when you turn the thing on, you are ready to rock. The only way to do that is for the PC vendors to pre-install Linux (or FreeBSD, or whatever).
I think this is bunk. As he pointed out earlier open source software is a poor candidate for commericial support. I think it is a poor candidate for pre-installation too. No self respecting sysadmin would want Dell to preload Linux or FreeBSD for their companies desktops (or servers). It is a far easier to support systems that are configured in the same manner and style and each sysadmin has their own preferences which become company policy. If we are talking about pre-installed systems for the home market than ok - it would be a selling point. But I think the market for such a system would be so low as to make it not worth the cost to a large company like Dell.
None of the open source operating systems are ready for the average home users desktop. The desktop environments need to be stable and established. The system update procedures as simple as Windows Update (apt is very close but not enough). There are too many rough edges right now for the average user. Compare the rate of change in the Windows desktop to that of KDE or Gnome. KDE and Gnome have to change because we demand and expect the same ease of use that the Windows desktop environment provides but in the same vain they won't be useful for the average user until they stabilize.
Can you imagine dumbed down debian with a graphical installer and a graphical web-based update like windows update? Instead of seeing all the package details we would only see the meta packages that hold all the updates for a particular component like KDE or X11 or the base system. A simple click and the download and upgrade begins... I'm sure some of us would be horrified by the idea of dumbing it all down so much but I think it will be neccessary - and I wouldn't mind running such a system as my stable desktop while running something a bit hairier on my development system.
Merged From Current. Most new features (esp big ones) go into the "current" version of BSD. Most users use the "stable" version because current isn't exactly stable... If current is a long time off from going throught a code freeze and becoming stable, then some of the new features that don't depend on new other parts get Merged From Current into the stable version that most people use.
The older SMP kernel had a "giant" lock on basically all of the OS. In theory more then one CPU could be int he kernel, in practice one would have a lock on Giant, and the rest would block waiting to get the lock (or would be running free in user code). The stable SMP code has a few other locks, and you can do a little in the kernel without hitting Giant. The SMP code in "current" pretty much (or totally) does away with the Giant lock.
Lotsa little locks is more like how Solaris works. I'm not sure if Linux has lots of little locks, or a hand full of mid-level ones (lots of little ones works better if they are all in the right place, a few mid-level ones works much better then the one giant lock, or lots of little ones in the wrong places).
And yes, it would have been nice to explain all the terms at the start of the article (even SMP which isn't BSD specific). I'll live though.
2) A Standard C Library (libc) is standard for every Unix and Unix-like operating system. For 99 systems out of 100, this libc will NOT come from GNU. If you write a program that makes use of glibc extensions, your program will not be portable. It will only make you look stupid.
This isn't most definately not true. The C library on Unices implements a set of standards, but which standards are implemented is up to the implementators. There are quite a few conflicting functions in between ANSI, SUS, SVID, BSD, ISO, and POSIX though most of them have to do with simple things such as errno values, but there are more serious cases such as the setjmp(3) conflict between BSD and POSIX.
Now, even without the conflicts, not every Unix has a complete implementation of these standards, especially given how frequently they've been coming out in recent years. POSIX 1003.1* for instance contains a good amount of optional functionality (SUSv2 made a lot of it mandatory however) including extremely useful features such as read-write locks for threads.
Now, that's not to say that I don't wish every Unix was at least was SUSv2 conformant, but OS specific code is a fact of life in cross-platform Unix development unless you are working on just Linux and *BSD. Calling someone stupid because they check to see if sigaction(2) exists because they want SA_RESTART to simplify their code just doesn't fly.
I look forward to the day when autoconf doesn't need to exist.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
No, you're not. I'm a Linux user, and this trend irritates the living hell out of me. I don't grok the need for 47 tiny libraries to write a mail client*, especially when nine times out of ten half of the required libs were written by the same guy for the same project, but distributed separately (never to be used by another project).
* For the truly anal retentive, that was a bit of hyperbole. But not much.
Translation: I can't defend any of this, since all I know was a bit of technical talk I didn't understand on a mailing list I lurk on.
So instead of anything substantive, I'll give you my useless anecdotes about my preferred system's performance being more "enjoyable."
And of course, any circumstance where anything outperforms my preferred system, I'll dismiss it out of hand.
I used to miss comp.sys.amiga.advocacy, but slashdot's BSD section is an excellent substitute.
Not just little tools.
Matt also wrote Dice C, which was a rocking good compiler, though admitedly not quite up to par with SAS's tool suite.
Once the Amiga market died, Matt gave Dice away to the community under the BSD license. You can still find it on Aminet today.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Just like all the Linux distros should?