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."
There are also a few comments from Theo de Raadt, the OpenBSD Founder himself. Be sure to check them out at the very bottom of the page!
If you celebrate Xmas, befriend me (538
I didn't know that there's such a following by Hollywood actors of alternative Operating Systems.
Maybe the last big movie he was in should have been called "There's Something About BSD".
Consultancy: If you're not part of the solution, there's money to be made in prolonging the problem
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.
Just because one actor follows "alternative Operating Systems", you conclude that there is such a following?
Way to generalize! Have a cookie.
I used to bulls-eye womp-rats in my pants
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.
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
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.
KSE = Kernel-Scheduled Entities
"The FreeBSD kernel-scheduled entity (KSE) project is striving to implement new kernel facilities that allow the implementation of SMP-scalable high-performance userland threading, as well as a new userland POSIX threads library (libpthread). KSEs are heavily based on a technology referred to as scheduler activations, and differ only to the degree necessary to support features that the original research does not address. The new libpthread uses as much of libc_r as is reasonably possible."
[...] an I/O descriptor representing a TCP connection could be migrated entirely off the original machine
Now that'd be a tasty bean.
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?
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 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
His statements are not a contradiction. He is saying that QOS is more then just redundant hardware, but that redundant hardware is an important part of QOS. I think that in the first statment Matt also means that using redudant hardware is the wrong way to fix poor (crashing) software.
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.
1) And if you didn't hear me mention so-called 'clustering' solutions currently available from unnamed vendors, it's because they can't actually deliver these things -- not true Q.O.S. That's my opinion, anyway. Using a cluster to hide the fact that the underlying systems crash regularly is an extremely dangerous way to manage a computing environment.
Bullshit. No amount of bug fixes will eliminate crashes. I've seen smoke pouring from servers due to short circuts on the motherboard. I've seen array controlers give up the ghost, network cards bid this cruel world goodbye and absent minded tech power cycle the wrong box. I've worked for 3 (!) companies that have had entire datacenters lose power due to human error (Microsoft, Voicestream and Group Health).
Crashes happen and you have to have redundancy to deal with this. If you want to see a truly stable system, don't look at any Un*x. Un*x clustering solutions are bolted on and it shows. You want to look at a real high availability system like a Tandem system.
On a Tandem system you can lose a processor without dropping a single connection. You can lose a server and recover. It's built fault tolerant from the ground up.
If you're serious about high availability, this is the only way to go. Unix clustering is mostly shit - you really don't want it running a system that absolutely, positively can't go down.
Sure NT clustering is worse -- I did a study at Voicestream and found that our NT clusters had more downtime on average than our standalone NT systems, but Un*x clustering is nothing to write home about either. Saying that Un*x is more stable than NT is like saying that it's better to drink urine than eat shit. Sure it's true, but it's missing the big picture. VMS clusters are more stable than any Un*x solution and Tandem systems won't go down even if you start smashing processors with a mallet. That's what real stability means.
--Shoeboy
Well he's right from one point of view. .Net as an overall strategy is somewhat Vapor. That actually is the marketing goal, to label whatever new and cool comes along as .Net.
.Net, blah blah.
.Net development environment, which is not Vaporware. I just saw an announcement that it RTM's in November and will ship in February.
And you see this with the recent renaming of a lot of old server products as
But he's clearly in denial if he doesn't understand the importance of the
I sometimes wonder if it wasn't Microsoft's goal to confuse their competition so that they didn't know how to respond. It seems to be working, everybody is focusing on Passport and Hailstorm which were clearly not the signifigant pieces.
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.
MFCd? Giants? At least they explained what KSE and SMPng are, but it would have been nice to have that at the beginning of the article.
Even though his pet peeve might not be my pet peeve, it still peeves me off. There are many kinds of linuxisms, even though I mentioned only one.
Li*nux*ism:
Pronunciation: 'lee-nuks-izm'
Function: noun
Date: 1998
: a theory holding that the community can know nothing but its own operating system and that its operating system is the only existent operating system. Compare with English "solipsism".
p.s. You have a Linuxism in your post. Can you find it?
A Government Is a Body of People, Usually Notably Ungoverned
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
Actually I think the main problem with Rik's VM is Rik. He's always got some arrogant comment or critisizing Linus publically about something. The fact is, his code was stuck in a loop (literally) and no one knew how to fix the damn thing. People kept submitting all sorts of little patches but they were just tipping all over each other (Alan claims to have been much more conservative about what he allowed into his Kernal which is performing well). I think when Linus saw that Andrea's total rewrite showed good performance he jumped at the opportunity if for no other reason to just get Rik off his back. And so far the results have been pretty good. Linus still does not approve of the classzone design, the code is supposedly really messy, and there are little annoying incongruencies. Alltogether this meaning the stuggle is not over on this front
Have you looked at Mosix?
It provides pre-emptive process migration across machines in a cluster. Its a single-system-image clustering solution for Linux.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Interesting how really smart people never seem to quit being smart.
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.
When Ballmer visited The Netherlands a couple of months ago, he said after being asked which Microsoft-software product was the biggest and most important one: "Visual Studio.net. It's bigger in codebase than all windows versions together. It's also the most important product for us for the coming future.". Hard to believe the codebase size comment though, but it underscribes nevertheless the realness of VS.net. Microsoft understands very clearly that the one thing needed for a succesful .NET is a large, succesful group of developers. The only way to attrackt developers is to provide the best dev-environment on the planet, and looking at Beta2 of VS.net, I think they'll succeed.
Never underestimate the relief of true separation of Religion and State.
.NET is a development platform and it's far from "Vapor". It's similar in concept to the Java platform in many ways but different in many others. For windows developers it's a whole new way of writing, well, just about everything. Web Services is just a part of it.
How about this:
"Are you going to try and make a John Travolta like comeback....When will we start to see your face show up in our summer blockbusters?"
(+1 Funny) only if I laugh out loud.
Although clustering is no substitute for real software engineering, you can't get real reliability without redundant hardware, because hardware fails. I don't see any contradiction here; I think the points are unrelated.
Ben "You have your mind on computers, it seems."
Yes, I've looked at it and used it quite a bit.
Mosix is the kind of thing we are talking about.. EXCEPT...
.
Mosix only migrates the user context of a task to another machine. The process is still effecitvely tied to the node it started on; if that node crashes, bye-bye process.
What is meant in the article, though, is complete migration... having a process able to move to whichever hardware it wants to.
Or.. to put it differnelty, mosix allows greater performance to a point, by adding machines... but doesn't provide redundancy. If the node a task started on crashes, the task is toast.
You can't instruct it, say, to move all tasks to another machine so you can perform maintenance.