VFS, the filesystem, the whole TCP/IP layer, the POSIX API, all of that cames from FreeBSD code and that's quite a lot of code.
Yes, mac os x uses openstep's kernel. But then, openstep kernel used freebsd code aswell....
I remember a presentation from apple showing percentages of how much code comes from each variant. BSD code was most of it, with the IOKIT being second and MACH-derived code being the last - less than 10%. Shame that I didn't bookmark it...
This of course, comes with a performance penalty. In Linux, everything is a kernel thread. This gives it a big performance advantage, making it appropriate for servers operating under controlled conditions, as the tests indicate. However, OS X's design choice makes for more secure communication between user-space threads and the kernel, which gives an advantage in the workstation-space, since you can keep a user process from running amok in the kernel.
Except that people who implements M:N-style threading like mac os x believe that it can be fast (reasonabily fast)
Not having achieved it (still) is a "achilles heel" indeed. Apple has to work on that and make their threading implementation performant
There's a very good post from Ingo Molnar explaining why linux chose 1:1 and not M:N, and he points out a possible "users-space threads" issues:
"Plus there are other issues like security - it's perfectly reasonable in the 1:1 model for a certain set of server threads to drop all privileges to do the more dangerous stuff. (while there is no such thing as absolute security and separation in a threaded app, dropping privileges can avoid certain classes of exploits)"
Also, expect desktop apps to start using threads heavily (in the future) to use multi-core CPUs
Which is good, because it really doesn't take too much for fix drivers to work on x86-64.
I don't think it's so easy as it sounds. It's easy - if you designed your driver with 64 bits in mind. If not, you'll to rework them a bit
And you know, it's not easy to rework thousand of drivers written in the last 10 years in just a few months. Many manufacturers, even the "big" ones like HP, have already given lists of devices that are not going to be supported in 64-bit platforms ever. Epson, I think, doesn't even has any information or drivers in their web pages. And don't even ask about those cheap chinese devices. Many, many devices are not going to be able to be run on a 64 bit platform ever. Linux will be able to compete with windows in this matter for first time thanks to the open source...the swtich to 64 bits is going to be painful in the windows side no matter what AMD and Microsoft say.
Just check the Microsoft and AMD guides about porting your drivers to 64 bits. IOCTLS are a problem (they are a problem in linux too, 64 bit drivers must provide 32-bit compatible IOCTLS). Problems WRT to DMA too.
Also, notice that in the lovely windows world, in their x86 transition to 64 bits, Microsoft keep the basic data types unchanged for compatiblity. Only pointers are 64-bit wide. Longs, ints...all of those will continue being 32-bit wide; in linux longs are 64 bit-wide not 32. If your memory saves a memory address in a long type somewhere in your code, you'll have to change it too. Plus, modifying all the INF files, etc....I'm not an expert on this but it's not as easy as you said, specially if you didn't build your driver with 64 bit in mind (most of the industry, since everybody got suprised by the AMD-64 platform and it took a while for Intel to decide what it was going to do)
5) Database filesystems - by defile
The buzz around filesystems research nowadays is making the UNIX filesystem more database-ish. The buzz around database research nowadays is making the relational database more OOP-ish.
This research to me sounds like the original designers growing tired of the limitations of their "creations" now that they're commodities and going back to the drawing board to "do things right this time". I predict the reinvented versions will never catch on because they'll be too complex and inaccessible.
Of course, this second system syndrome isn't just limited to systems. It happens to bands, directors, probably in every creative art.
I think what we've got in the modern filesystem and RDBMS is about as good as it gets and we should move on. What do you think?
Pike:"
This is not the first time databases and file systems have collided, merged, argued, and split up, and it won't be the last. The specifics of whether you have a file system or a database is a rather dull semantic dispute, a contest to see who's got the best technology, rigged in a way that neither side wins. Well, as with most technologies, the solution depends on the problem; there is no single right answer.
What's really interesting is how you think about accessing your data. File systems and databases provide different ways of organizing data to help find structure and meaning in what you've stored, but they're not the only approaches possible. Moreover, the structure they provide is really for one purpose: to simplify accessing it. Once you realize it's the access, not the structure, that matters, the whole debate changes character.
One of the big insights in the last few years, through work by the internet search engines but also tools like Udi Manber's glimpse, is that data with no meaningful structure can still be very powerful if the tools to help you search the data are good. In fact, structure can be bad if the structure you have doesn't fit the problem you're trying to solve today, regardless of how well it fit the problem you were solving yesterday. So I don't much care any more how my data is stored; what matters is how to retrieve the relevant pieces when I need them.
Grep was the definitive Unix tool early on; now we have tools that could be characterized as `grep my machine' and `grep the Internet'. GMail, Google's mail product, takes that idea and applies it to mail: don't bother organizing your mail messages; just put them away for searching later. It's quite liberating if you can let go your old file-and-folder-oriented mentality. Expect more liberation as searching replaces structure as the way to handle data.
And the reason why this was left behind and unix-like (well, multics-like) filesystems were used was because that was "too complex"
Who knows. Me, personally, I find the database idea just too complex. Files and folders fit much better in my head. But who knows, with the vast amount of files that we need to manage these days, perhaps the database idea will be much better...time will say.
Notice that linux kernel developers haven't neccesarily opposed to reiser 4 ideas, but how they have been implemented. Hell, Linus even likes the "files-as-directories" thing, a idea which makes many UNIX zealots vomit...
The problem with reiser 4 being merged (as I've seen it in the flam^Wdiscussions) is that they seem to implement things that should be implemented at VFS level, not in the reiser 4 code like they're doing now. It's that what is stopping reiser 4 from being merged, not the "ideas" themselves. Some people don't like reiser 4 ideas, but as long as they're not forced to use them and the features are well implemented they won't oppose to it.
The way to handle this is via embedding versioning/option information in the structures. This is not rocket science.
Methods like the "Windows Driver Model" thing, which would give us back that compatibility HAVE been proposed, implemented and then, rejected. Google for "overengineering".
Again, the kernel HAS a stable ABI - the syscall interface. Lots of projects change their internals while conserving their "public" interface stable. This is what the linux kernel does, and the fact that modules are "different" doesn't make it a bad idea.
These discussions along with final reason for pushing udev were concentrated on devfs weaknesses rather than udev superiority.
udev pushes all the device naming policy to userspace. Moving policy stuff to userspace is something that linux developers (and hackers of other OSes too) love because it's a much better design. That was the main reason for udev.
In fact, it was almost identical to what people are now saying about udev. Makes me less eager to switch. Linux seems to have so many of these false starts that you hear nothing but praise of and then afterwards people say they were broken all along.
Well, devfs was better than nothing, and udev is better than devfs.
I'm shocked that you seem to opose to getting things improved.
A large number of organizations (as well as Debian Stable and Redhat) still use 2.4.
Debian didn't care about switching to 2.6 because that would have delayed sarge even more...we all know debian. Redhat Advanced Server 4.0 uses 2.6 not 2.4, suse's versions for servers too, so what is your point?
As far as I know, except debian there's no major distro using 2.4 as default kernel.
Right now 2.6 is a lame-duck kernel
Wrong. Ubuntu, redhat, fedora, mandriva, suse, gentoo, knoopix, all of them use 2.6. I don't know where you got that impression, looking at current distros it's pretty clear 2.6 is the preffered kernel version for most of people.
Linux packaging technology beats the ass of windows any time. I can click double click on.debs and get them openened by a installer just like.msi
The problem is in how they're delivered and the lack of 1) a common packaging format and 2) lack of a common "package namespace" (ie: xorg can be called xorg in fedora and xserver-xorg in debian, that makes dependencies fail and can be only fixed by using a common packaging framework where developers and not distros makers package things)
But Linux continues being much better than windows in some areas. For example, you've to download the.exe programs from docens of differents web pages. This becomes SCARY when you've to update things. For the vast majority of software you've to check for new versions visiting their web page and reading the text to check visually if there's a new version. Compare it to the magic of apt-get and emerge....I wonder when Microsoft will catch up with the early 90's and will develop a new.msi format where developers can suministrate a URL for a XML file which tells Windows what are the latest file versions of a given program...there're hints that makes me believe that they'll use RSS for this in Windows Vista, but I don't expect that much from microsoft...
not that many people is going to notice it - devfs wasn't really used in most of mainstream distros except 2 or 3. In some cases like Mandrake, they used it and then switched back.
And it's not a surprise, linux's devfs implementation was broken from start, and the idea behind devfs isn't a relly good one. Fortunately, udev is much better...
Linux DOES has a stable ABI, this is, the syscall interface. It hasn't been changed in years...I know people who is running binaries compiled for linux 1.0 in 2.6 kernels. If your app breaks or works bad when changing the kernel version (ej: openoffice when the semantics of yield() where changed in 2.5) is probably because your app was broken in first place. Now, regression and bugs can happen too, but those aren't on purpose
"Ars: You mention mistakes made by Microsoft. What do you feel are mistakes that Mozilla has made in the past?"
One: There was a fundamental mistake made by Netscape management, twice, which cost us a release at the most inopportune time. I think we can attribute a great deal of our market share loss to this mistake that was pretty much based completely on lies from one executive, who has since left the company (and left very rich) and who was an impediment to everything that we did. He was an awful person, and it is completely on him that we missed a release. We had a "Netscape 5" that was within weeks of being ready to go, and this person said that we needed to ship something based on Gecko within 6 months instead. Every single engineer in the company told management "No, it will be two years at least before we ship something based on Gecko." Management agreed with the engineers in order to get 5.0 out.a
Three months later they came back and said "We've changed our mind, this other executive has convinced us, except now instead of six months, you need to do it in three months." Well, you can't put 50 pounds of [crap] in a ten pound bag, it took two years. And we didn't get out a 5.0, and that cost of us everything, it was the biggest mistake ever, and I put it all on the feet of this one individual, whom I will not name.
The biggest offender in this case is MSN Messenger. That messenger thing ALWAYS use IE as browser, no matter what system defaults you have. Ej: If someone sends you a link and you click it, it will be IE who opens it even if you configured your system to use Firefox.
And this will prompt the user: "Do you want to make IE your default browser?"
When I install firefox in someone's machine, the first thing I do is setting it as the default browser, then running IE to get that window prompt to me, and press "no" while checking the "don't ask this again". So, even if Messenger uses IE, at least it won't change your system's settings. I also delete the IE icon from the desktop and start menu and quick bar, BTW.
Slashdot Mirror
Are you joking?
VFS, the filesystem, the whole TCP/IP layer, the POSIX API, all of that cames from FreeBSD code and that's quite a lot of code.
Yes, mac os x uses openstep's kernel. But then, openstep kernel used freebsd code aswell....
I remember a presentation from apple showing percentages of how much code comes from each variant. BSD code was most of it, with the IOKIT being second and MACH-derived code being the last - less than 10%. Shame that I didn't bookmark it...
This of course, comes with a performance penalty. In Linux, everything is a kernel thread. This gives it a big performance advantage, making it appropriate for servers operating under controlled conditions, as the tests indicate. However, OS X's design choice makes for more secure communication between user-space threads and the kernel, which gives an advantage in the workstation-space, since you can keep a user process from running amok in the kernel.
Except that people who implements M:N-style threading like mac os x believe that it can be fast (reasonabily fast)
Not having achieved it (still) is a "achilles heel" indeed. Apple has to work on that and make their threading implementation performant
There's a very good post from Ingo Molnar explaining why linux chose 1:1 and not M:N, and he points out a possible "users-space threads" issues:
"Plus there are other issues like security - it's perfectly reasonable in the 1:1 model for a certain set of server threads to drop all privileges to do the more dangerous stuff. (while there is no such thing as absolute security and separation in a threaded app, dropping privileges can avoid certain classes of exploits)"
Also, expect desktop apps to start using threads heavily (in the future) to use multi-core CPUs
Apple has priorities. Just like linux sucks on desktops and rocks on servers, Mac OS X sucks on servers and rocks on desktop
We got all the chicks and they couldn't reproduce
I don't know why people cares about google's ads. I just don't look at them, I don't about the rest of the people.
/etc/hosts
And for the rest of web pages using adsense you can use this little trick:
echo "0.0.0.1 pagead2.googlesyndication.com" >>
Which is good, because it really doesn't take too much for fix drivers to work on x86-64.
I don't think it's so easy as it sounds. It's easy - if you designed your driver with 64 bits in mind. If not, you'll to rework them a bit
And you know, it's not easy to rework thousand of drivers written in the last 10 years in just a few months. Many manufacturers, even the "big" ones like HP, have already given lists of devices that are not going to be supported in 64-bit platforms ever. Epson, I think, doesn't even has any information or drivers in their web pages. And don't even ask about those cheap chinese devices. Many, many devices are not going to be able to be run on a 64 bit platform ever. Linux will be able to compete with windows in this matter for first time thanks to the open source...the swtich to 64 bits is going to be painful in the windows side no matter what AMD and Microsoft say.
Just check the Microsoft and AMD guides about porting your drivers to 64 bits. IOCTLS are a problem (they are a problem in linux too, 64 bit drivers must provide 32-bit compatible IOCTLS). Problems WRT to DMA too.
Also, notice that in the lovely windows world, in their x86 transition to 64 bits, Microsoft keep the basic data types unchanged for compatiblity. Only pointers are 64-bit wide. Longs, ints...all of those will continue being 32-bit wide; in linux longs are 64 bit-wide not 32. If your memory saves a memory address in a long type somewhere in your code, you'll have to change it too. Plus, modifying all the INF files, etc....I'm not an expert on this but it's not as easy as you said, specially if you didn't build your driver with 64 bit in mind (most of the industry, since everybody got suprised by the AMD-64 platform and it took a while for Intel to decide what it was going to do)
From Rob Pike's slashdot interview:
5) Database filesystems - by defile The buzz around filesystems research nowadays is making the UNIX filesystem more database-ish. The buzz around database research nowadays is making the relational database more OOP-ish.
This research to me sounds like the original designers growing tired of the limitations of their "creations" now that they're commodities and going back to the drawing board to "do things right this time". I predict the reinvented versions will never catch on because they'll be too complex and inaccessible.
Of course, this second system syndrome isn't just limited to systems. It happens to bands, directors, probably in every creative art.
I think what we've got in the modern filesystem and RDBMS is about as good as it gets and we should move on. What do you think?
Pike: " This is not the first time databases and file systems have collided, merged, argued, and split up, and it won't be the last. The specifics of whether you have a file system or a database is a rather dull semantic dispute, a contest to see who's got the best technology, rigged in a way that neither side wins. Well, as with most technologies, the solution depends on the problem; there is no single right answer.
What's really interesting is how you think about accessing your data. File systems and databases provide different ways of organizing data to help find structure and meaning in what you've stored, but they're not the only approaches possible. Moreover, the structure they provide is really for one purpose: to simplify accessing it. Once you realize it's the access, not the structure, that matters, the whole debate changes character.
One of the big insights in the last few years, through work by the internet search engines but also tools like Udi Manber's glimpse, is that data with no meaningful structure can still be very powerful if the tools to help you search the data are good. In fact, structure can be bad if the structure you have doesn't fit the problem you're trying to solve today, regardless of how well it fit the problem you were solving yesterday. So I don't much care any more how my data is stored; what matters is how to retrieve the relevant pieces when I need them.
Grep was the definitive Unix tool early on; now we have tools that could be characterized as `grep my machine' and `grep the Internet'. GMail, Google's mail product, takes that idea and applies it to mail: don't bother organizing your mail messages; just put them away for searching later. It's quite liberating if you can let go your old file-and-folder-oriented mentality. Expect more liberation as searching replaces structure as the way to handle data.
And the reason why this was left behind and unix-like (well, multics-like) filesystems were used was because that was "too complex"
Who knows. Me, personally, I find the database idea just too complex. Files and folders fit much better in my head. But who knows, with the vast amount of files that we need to manage these days, perhaps the database idea will be much better...time will say.
Notice that linux kernel developers haven't neccesarily opposed to reiser 4 ideas, but how they have been implemented. Hell, Linus even likes the "files-as-directories" thing, a idea which makes many UNIX zealots vomit...
The problem with reiser 4 being merged (as I've seen it in the flam^Wdiscussions) is that they seem to implement things that should be implemented at VFS level, not in the reiser 4 code like they're doing now. It's that what is stopping reiser 4 from being merged, not the "ideas" themselves. Some people don't like reiser 4 ideas, but as long as they're not forced to use them and the features are well implemented they won't oppose to it.
The way to handle this is via embedding versioning/option information in the structures. This is not rocket science.
Methods like the "Windows Driver Model" thing, which would give us back that compatibility HAVE been proposed, implemented and then, rejected. Google for "overengineering".
Again, the kernel HAS a stable ABI - the syscall interface. Lots of projects change their internals while conserving their "public" interface stable. This is what the linux kernel does, and the fact that modules are "different" doesn't make it a bad idea.
To database customers, we still recommend kernel 2.4.
Redhat and suse recommend 2.6. I'll take their advice instead...
These discussions along with final reason for pushing udev were concentrated on devfs weaknesses rather than udev superiority.
udev pushes all the device naming policy to userspace. Moving policy stuff to userspace is something that linux developers (and hackers of other OSes too) love because it's a much better design. That was the main reason for udev.
All your information is belong to use - including your thougts
-- Google
In fact, it was almost identical to what people are now saying about udev. Makes me less eager to switch. Linux seems to have so many of these false starts that you hear nothing but praise of and then afterwards people say they were broken all along.
Well, devfs was better than nothing, and udev is better than devfs.
I'm shocked that you seem to opose to getting things improved.
A large number of organizations (as well as Debian Stable and Redhat) still use 2.4.
Debian didn't care about switching to 2.6 because that would have delayed sarge even more...we all know debian. Redhat Advanced Server 4.0 uses 2.6 not 2.4, suse's versions for servers too, so what is your point?
As far as I know, except debian there's no major distro using 2.4 as default kernel.
Right now 2.6 is a lame-duck kernel
Wrong. Ubuntu, redhat, fedora, mandriva, suse, gentoo, knoopix, all of them use 2.6. I don't know where you got that impression, looking at current distros it's pretty clear 2.6 is the preffered kernel version for most of people.
Linux packaging technology beats the ass of windows any time. I can click double click on .debs and get them openened by a installer just like .msi
.exe programs from docens of differents web pages. This becomes SCARY when you've to update things. For the vast majority of software you've to check for new versions visiting their web page and reading the text to check visually if there's a new version. Compare it to the magic of apt-get and emerge....I wonder when Microsoft will catch up with the early 90's and will develop a new .msi format where developers can suministrate a URL for a XML file which tells Windows what are the latest file versions of a given program...there're hints that makes me believe that they'll use RSS for this in Windows Vista, but I don't expect that much from microsoft...
The problem is in how they're delivered and the lack of 1) a common packaging format and 2) lack of a common "package namespace" (ie: xorg can be called xorg in fedora and xserver-xorg in debian, that makes dependencies fail and can be only fixed by using a common packaging framework where developers and not distros makers package things)
But Linux continues being much better than windows in some areas. For example, you've to download the
When 2.6.12 came along it broke my IDE-SCSI setup
Well, maybe those bugs have been fixed in 2.6.13, which is why new kernel versions are released in first place
Because you did care about reporting them, yeah?
You must be new here.
I mean, here in slashdot we have high-quality trolls, we love to be troll-ized by them.
But your start has been quite poor, really. Continue training...
not that many people is going to notice it - devfs wasn't really used in most of mainstream distros except 2 or 3. In some cases like Mandrake, they used it and then switched back.
And it's not a surprise, linux's devfs implementation was broken from start, and the idea behind devfs isn't a relly good one. Fortunately, udev is much better...
Linux DOES has a stable ABI, this is, the syscall interface. It hasn't been changed in years...I know people who is running binaries compiled for linux 1.0 in 2.6 kernels. If your app breaks or works bad when changing the kernel version (ej: openoffice when the semantics of yield() where changed in 2.5) is probably because your app was broken in first place. Now, regression and bugs can happen too, but those aren't on purpose
s /linux-2.6.git;a=blob;h=f39c9d714db3d6bf2f6440d2f6 cf9353057eeae5;hb=02b3e4e2d71b6058ec11cc01c72ac651 eb3ded2b;f=Documentation/stable_api_nonsense.txt
Maybe you mean the internal kernel API - which affects to modules, NVIDIA & friends etc. That API is unstable on purpose, as explained here: http://kernel.org/git/?p=linux/kernel/git/torvald
Or maybe you mean "compatibility" WRT gtk & friends, if GTK breaks compatibily thats their broblem
My spinning wheel is much faster and I don't do a announcement about it.
IE7 is only available to official betatesters, Beta 2 will be a public beta but beta 1 isn't
Why all this fud about "if it comes installed, everyone will use it"? Why is that everyone uses winzip and winamp, then?
Netscape didn't lost the browser war because of not being installed by default. It helped, but that was not the main reason: Ars Technica sits down with Scott Collins from Mozilla.org:
"Ars: You mention mistakes made by Microsoft. What do you feel are mistakes that Mozilla has made in the past?"
One: There was a fundamental mistake made by Netscape management, twice, which cost us a release at the most inopportune time. I think we can attribute a great deal of our market share loss to this mistake that was pretty much based completely on lies from one executive, who has since left the company (and left very rich) and who was an impediment to everything that we did. He was an awful person, and it is completely on him that we missed a release. We had a "Netscape 5" that was within weeks of being ready to go, and this person said that we needed to ship something based on Gecko within 6 months instead. Every single engineer in the company told management "No, it will be two years at least before we ship something based on Gecko." Management agreed with the engineers in order to get 5.0 out.a
Three months later they came back and said "We've changed our mind, this other executive has convinced us, except now instead of six months, you need to do it in three months." Well, you can't put 50 pounds of [crap] in a ten pound bag, it took two years. And we didn't get out a 5.0, and that cost of us everything, it was the biggest mistake ever, and I put it all on the feet of this one individual, whom I will not name.
The biggest offender in this case is MSN Messenger. That messenger thing ALWAYS use IE as browser, no matter what system defaults you have. Ej: If someone sends you a link and you click it, it will be IE who opens it even if you configured your system to use Firefox.
And this will prompt the user: "Do you want to make IE your default browser?"
When I install firefox in someone's machine, the first thing I do is setting it as the default browser, then running IE to get that window prompt to me, and press "no" while checking the "don't ask this again". So, even if Messenger uses IE, at least it won't change your system's settings. I also delete the IE icon from the desktop and start menu and quick bar, BTW.
Windows 98 still works.
Windows 98 is unsupported, with know unfixed security flaws which aren't fixed just because MS isn't forced to do it- windows 98 is SEVEN years old.
Yeah, 50's cars can take you everywhere just like a 2000's car, right?