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."
As a note (not a flamebait) about how FreeBSD compares with Linux regarding the VM implementations, remember that Linux has actually 2 VM managers (you can choose which one you want in the kernel build configuration), both of exterme poor quality. That seems to be a common problem in linux, where people write sensible code just to learn how to do it, and it becomes the standard in the kernel. Now compare that with any of the BSD's and you'll see why linux is actually very hyped, and why the BSD's are technically so strong.
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.
It was interesting to read that Matt Dillon is supporting Rik van Riel's work on the VM in Linux. There has been a lot of controversy ove the Linux VM, with a number saying that the latest one - based on Rik's work - had made a poor comprimise: more smooth operation for lower overall performance, making it better suited to interactive applications than server applications.
Not being a kernel-list follower, I don't know much about the details, but I'm sure there are other Slashdot readers who are much more familiar with them. I would have thought that lower expected latencies from the VM would improve most server-based tasks as well, at the possible cost of reducing the maximum amount of work the machine could do - but then, it seems counterproductive to talk about performance in such a heavily-loaded environment when the best solution would be typically to add more hardware (RAM, CPUs or split across multiple machines.) Do I have this all wrong?
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 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
That sort of assumes you try to sell the support to the hackers. I expect you end up selling more support contracts to the "normal" folks. For example back before Ret Hat bought Cygnus they sold more gcc support contracts to embedded developers then to people wanting to run gcc on a Unix system to produce Unix executables.
(This is not to say embedded folks aren't hackers, but many more of them are hardware hackers, and software dabblers, and many many many of them a worker grunts and not hackers at all, which was surprising when I was in the field, but never the less true at the time)
So I think service and support business models have a market, that market just isn't me (and is less likely to be folks who read Slashdot, and more likely to be folks who stop reading about computers when they have free time...)
I agree with you about not ever needing to compile, but I think his real point was not any of BSD's strong points (features included, packages/ports, etc) but rather that Linux is way out in left field as far as "across the board" unix compatibility.
I know what you're thinking
I'm sure this will be modded to lowest plane of
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.
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.
Just like all the Linux distros should?
Intresting, it seems like getting the scheduler right would be a lot simpler then getting all the little locks in the right place to both protect resources, and to not build up too much contention.
I'm not saying you are wrong, indeed you know far more about how Linux is built then I do, it just seems like a bottleneck that should be pretty easy to fix!
Could be, software schedules frequently are. Or it could be baised off where they are now, or how fast they got there compaired to how long Linux took. Who knows.
Personally I think the new slower 5.0 schedule is more realistic, and I'm glad for it, even if it means I get checkpoints (and background fsck) much later then I had hoped.