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".
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.
Is the BSD VM really that much better than the Linux VM anymore? It seems that Linux's VM is looking forward to machines with lots and lots of processors (NUMA). BSD seems to still be working out basic SMP. There was a patch for the Linux 2.4 kernel to make it behave like the BSD VM. What sets the BSD VM appart?
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 fact that good admins wipe out anything pre-installed and go for their Network installed image isn't surprising.
But, thats not different on OpenSource than it is for commercial OSs. First thing we do is wipe the Sparc and load from our own trusted (if they can be described as such) disks.
Rod Taylor
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.
I don't mean this as flamebait at all, but I'd like to point out that the reverse is absolutely true as well. Having used both systems quite a bit, I'd say there are as many or more features in the BSD libc that are oh-so-good and oh-so-tempting to use, and many BSD authors do in fact use them, making their programs unportable (making themselves look stupid? =). Now then, it's pretty easy to pull a part of the BSD libc and include it in your program for portability so this is less of an issue than pulling part of glibc and potentially tainting your licenses. Still, it's a concern for any Unix-like system.
Cryptic Allusion - New Mac and Dreamcast Games!
The one on the GPL (Non)Business Model
If the GPL is/has a "non-business model", then why have the major computer manufacturers that have embraced Free Software pretty much all chosen Linux over any form of BSD? (IBM, HP/Compaq, Dell)
The answer is really simple: When companies like IBM & HP make contributions to the Linux source code base, they don't want someone (like Microsoft, for example) to come along and take the code and make it proprietary and closed-source. The BSD license allows this, the GPL doesn't.
These companies seem to either want to keep the code completely closed (AIX, HP-UX, Lotus Notes, etc.) or completely open so that it must stay open.
The business model behind Linux and other GPL-based software is simple: build a turnkey solution that meets the customer's needs/wants and they will pay top dollar for it. There is a company here in Washington State that runs all their systems on Linux: mail, web, desktop, and a custom billing/scheduling system based on MySQL (I believe). They have hired one good Linux hacker (not me, he's a friend of mine) to custom build their solution.
If he had done all this with BSD-licensed software, other companies could come along and steal his code, modify it, close it and sell it as their own. Since it's under the GPL, they can use it if they like, but they must keep it open and give him credit.
IBM is doing the same thing with their work. You can use their modifications to Linux if you like, but you must keep them open and you probably have to give credit to IBM somewhere along the way (I may be mistaken about this, please correct me if I'm wrong). This protects them from competitors stealing their code, not only because it's illegal due to the license, but also because I'm sure HP wouldn't want to use code where they had to give credit to IBM. Individuals and small companies wouldn't mind that, though.
I've seen linux boot on a 16 CPU unisys box with my own eyes.
It still needs work, but not because of the locking. The scheduler is highly optimized for usual small server/desktop loads: only two-three processes runnable at any time.
On a machine with 16 CPUs, you need 16 processes runnable just to keep the CPUs busy, and the current scheduler is pretty damn slow there.