. But face it, NTFS, HFS and BeFS will never be the native filesystems on a Linux-machine. They are all proprietary, for one thing. The support for them exists first and foremost to help people to migrate files. The reason there exists a superugly hack for HFS is that any binary will break without its resourcefork. If I'm not all wrong, neither BeFS nor NTFS stores any vital information (just configuration-data, extended attributes etc.) in their streams, so if they get lost, at least your computer will survive. I might be off here, though.
>>>>>>>>>>>>
1) BFS is quite openly documented in a book written by the guy who designed it. It's called Practical File System Design. A copy of the FS is used in AtheOS.
2) The extended attributes in BeOS store a lot of vital stuff. (Size, data, permissions, resources) Taking them out will usually hose the system.
Of course, that is only true as long as Linux is limited to servers. When Linux hits the mainstream desktop market, project like Debian which don't use the latest kernels will become increasingly irrelevant. Ever wonder why Windows2K has DirectX 7 support? Because it is meant to be both a desktop and server OS, and keeping two releases is just too much trouble. While there will still be server people using the previous version, the majority of people will simply go with the leading distro makers (eg. Redhat) and install the latest kernel.
Well, the Linux world is pretty slow lately so what else is there for Linuxdot to do? They COULD have posted the latest BeOS 3D benchmarks, but they aren't Linux benchmarks are they? At least we would have had a good discussion.
I htink a good test is to see which apps run on which OSs. For example:
Win98, Win95, and Win2000 are the same OS because they (almost always) run each other's programs. However, NT4 is missing DirectX, so it is not the same OS.
None of the BSDs are the same OS, since they aren't 100% binary compatible.
All of the Linux distros are the same OS.
Linux/KDE and Linux/GNOME are two different OSs. (Loading redundant libraries is only a notch above WINE or lxrun from a performance point of view, especially since lxrun runs near-native and RAM gets clobbered in the KDE/GNOME case)
One thing I was thinking is that journaling data or disk cache could be written to a battery backed up RAM-disk. That way, if the power fails, all the data would still be on the RAM disk, and the disk could be properly updated. The RAM disk would be as fast as regular RAM (well, depending on where it is located) so writes would be nice and fast. RAM is cheap, batteries are cheap, so whats holding it up?
The next generation, be-all, end-all filesystem for Linux is...SLOWER? than Ext2? Are you kidding me? I don't really understand what problem he is trying to solve. Current journaling filesystems are a good deal FASTER than ext2. The one I have most experiance with is BeOS. On Bonnie (one of the only disk tests available on BeOS) BFS beats ext2 by nearly 20% with about 40% less processor usage (If you want to see the actual results, I'll post 'em if you want) on the read tests, and by a smaller margin on the write tests. It has problems on the read-back tests, but that is due to BeOS's VM issues. As for ReiserFS, I've used that too and that is also faster than Ext2. So if journaling FSs are faster than the current ones, why bother making one that is slower?
The problem is that the ascension of power is NEVER that easy. Not even Linux is immune from egoists, and if Linus goes away, there is going to be a major transition period while things readjust. As Linux becomes more popular, the "Grand Linux pooba" position will become more coveted. Take, for example, the US government (to strech a metaphor) The main reason why the US government is so phenominally stable is because everything is down on paper. There is none of this "I'd guess Alan Cox..." business. They have it mapped out very far. If this guy dies, this guy gets it. If he dies, this guy gets it. There is no ambiguity, and thus there is little chance of a power struggle. The point is that FreeBSD has plan of what to do if the leadership changes, and how to handle changes of leadership. A constitution if you will. Linux has no such plan, and is susceptible to the problems that come from not having a plan.
"I sent email to [LINUS] a couple of years ago, offering to help, buy stock, port something, whatever. Never heard anything back. So fuck [him]... (mother joke deleted)... and the horses [he] rides in on. Fuck [him] [] with a wire brush!"
Listen to yourself rant. Your just bitching because they rejected you. At that time period, Be was extremely supportive of developers. Ask anybody who has worked with them. Just because they didn't get to you doesn't mean that they are somehow evil. And www.beunited.org is a user group, and they are quite a friendly bunch over there.
Or, to coin a phrase ala the Japaneese,
"ultra-turbo-super-snarky-double-happy-conservat ive"
To get an idea of good sueprlatives, look no further than our good friends in the Japaneese media industry.
Its true though. Is it potshotting to point out flaws in something else? When MS says "Windows is a much more robust enterprise computing solution than Linux" they are taking potshots. When someone points out an actual flaw in a plan or design (like when Mindcraft pointed out that the TCP/IP stack needed some work for high-end hardware) then it is totally valid and in fact useful. In the case of mindcraft, the kernel developers took a look at the problems and fixed it.
1) I think that is because Windows doesn't use the HLT instructions, which not only prevent instructions from executing during idle loops, but cools the CPU down in the process.
4) You can never have enough speed. Not even on a laptop.
Umm, all the tests conducted ARE real apps. Thankfully, we seem to have evolved past the Winstone era. Unreal Tournament is a real FPS measure, Cinema4D and Povray test actual rendering times, and Bapco Sysmark is a script of around a dozen common Windows applications (Photoshop, Office, Netscape, etc.) So all these results ARE valid, and the loop thing really wouldn't change anything. (The score reported by Bapco on the Photoshop segment is going to be damn close to actual photoshop performance, because it IS actual photoshop perfromance.) The performance is still pretty good though, just not as groundbreaking as Transmeta would have you believe.
It really shouldn't use up that much CPU power. According to the benchmarks, MacOS X is memory hungry, but just as fast as other UNIXes in terms of graphics (dismal I know.) The main thing is that most of the GUI is still bitmapped, its just that the engine has the capability to add all this stuff to it. Plus, if any bright person ever accelerates PDF in hardware, then graphics designers would be in hog heaven.
Umm, sorry to point this out, but Mach is anything BUT tight. As if FreeBSD on TOP of Mach. The core of OSX is actuall quite bulky. And whoever thought of the stupid "system-server" idea should be shot. On BeOS if the net_server crashes (which happens about once a day, and don't worry, its being replaced) I can just kill it and restart. Under OSX, even though networking is in usermode, a crash of the networking will crash the entire system. In fact, I can crash just about every server except the app server (even the input server if you have a script kill it and bring it back) without locking the system. The NeXT approach totally loses the advantages of having a microkernel design.
Because of things like page flipping?
>>>>>>>
A 20fps difference because of page flipping? I highly doubt it. At most, you're sucking up around 200MB of bandwidth because of the blitting. That's a drop in the bucket for the GF2. Not to mention the fact that even at low res, the Linux drivers are STILL slower. No, the evidence suggests that something other than the blitting is holding back the GF2.
Because most Linux users routinely have tens of processes running in the background while using their systems?
>>>>>
If those idiots conducted benchmarking with tens of processes running in the background, than it is their own damn fault. Not to mention the fact that any half intelligent user tweeks their machine, cutting out unneeded processes. Of course, half of the people using RH6 are running SendMail in the background (which is loaded by default on those systems.)
Because, as good as the NVIDIA drivers are, they are still new (labeled as Beta, even)?
>>>>>>>
They are still beta, but they are based on rock solid code. What about cross-platform access don't you understand? Any bugs are in the driver/OS glue layer, and I seriously doubt that any major performance bugs could be hiding in there.
Because a good Linux driver should perform some minimal input checking to enforce security (I don't know if NVIDIA does this--more of a DRI-ish
thing)?
>>>>>>>
If security involves a 20-30% performance hit, than I say "welcome crackers!" On a game machine, security at that level is absolutely and totally useless and should be turned of. For a home machine, the only security should be in the network server. There is no need on a desktop to protect the user from local processes.
I think I responded to the wrong person. I agree with you, that the G4 has a worse price/performance than the PIII. I was talking to the guy who said that the G4 chip was cheaper than the PIII.
Seriously though, it wasn't as bad in the good old days when the price premium was maybe 10% or so. These days, with all the money you save, you're much better of getting another 256Meg or RAM or something. Also, the Athlon prices really aren't bad at all. Something like $650 for the 1.1 GHz Athlon (on pricewatch) Score!
And this has to be said.
All you memory bus freaks get off of it.
These procs aren't made for servers. If you put these procs in a server you are wasting your time (put slower procs and more memory and/or SMP) Otherwise, for games, 3D rendering, video editing, and 70% of the things that these procs are used for, CPU speed is still king. Example: QuakeIII uses about 200MB/sec of bus bandwidth. That's less than half the sustained (not theoretical) bandwidth of PC100 SDRAM. All the tests between PC100 and PC133 (or even PC66) show very little performance difference compared to bumping up the CPU speed a 100MHz or so. (Check www.sharkyextreme.com the Celeron vs. Duron tests)
But AMD's CPUs AREN'T clones of Intel. And that analogy is still wrong because while AMD and Intel CPUs are instruction set compatible, SSE and 3DNow! aren't. Lastly, you can't say SSE is a "hacktogether" response because I'm pretty sure they were working on it before 3DNow! was released. (What, you think you can put together an instruction set in a couple of months? KNI (Katmai New Instructions) were in planning a while before 3DNow! came out.) Also, SSE is in many ways superior to 3DNow!. It has more developer support, it has a wider range of instructions, and when fully implemented (which it is not in the PIII series) it is twice as fast (due to the whole 128 vs. 64 bit thing.)
A) NVIDIA has some unopenable stuff in the drivers.
B) (Much more important) NVIDIA has no reason to help out Matrox and the others. If you get your head out of your oss ass and look around, you'll notice that all the card companies *except* NVIDIA are having problems with their OpenGL drivers. If you read last months MaximumPC, you'll read an interview with the OpenGL driver developer at Matrox. He says that a GL driver is a lot of work, which is why the Matrox GL drivers aren't 100% yet. NVIDIA has a kick-ass OpenGL driver. A GL driver isn't an ordinary graphics driver. It is a complete implementation of the OpenGL pipeline (an ICD) Now if your implementation of OpenGL was faster than everyone else's (who were having problems with their own implementations and would love to get their hands on yours) wouldn't YOU keep yours closed?
Slashdot Mirror
. But face it, NTFS, HFS and BeFS will never be the native filesystems on a Linux-machine. They are all proprietary, for one thing. The support for them exists first and foremost to help people to migrate files. The reason there exists a superugly hack for HFS is that any binary will break without its resourcefork. If I'm not all wrong, neither BeFS nor NTFS stores any vital information (just configuration-data, extended attributes etc.) in their streams, so if they get lost, at least your computer will survive. I might be off here, though.
>>>>>>>>>>>>
1) BFS is quite openly documented in a book written by the guy who designed it. It's called Practical File System Design. A copy of the FS is used in AtheOS.
2) The extended attributes in BeOS store a lot of vital stuff. (Size, data, permissions, resources) Taking them out will usually hose the system.
Of course, that is only true as long as Linux is limited to servers. When Linux hits the mainstream desktop market, project like Debian which don't use the latest kernels will become increasingly irrelevant. Ever wonder why Windows2K has DirectX 7 support? Because it is meant to be both a desktop and server OS, and keeping two releases is just too much trouble. While there will still be server people using the previous version, the majority of people will simply go with the leading distro makers (eg. Redhat) and install the latest kernel.
Given a German to English translation, what the hell is a French word doing in there?
Well, the Linux world is pretty slow lately so what else is there for Linuxdot to do? They COULD have posted the latest BeOS 3D benchmarks, but they aren't Linux benchmarks are they? At least we would have had a good discussion.
I htink a good test is to see which apps run on which OSs. For example:
Win98, Win95, and Win2000 are the same OS because they (almost always) run each other's programs. However, NT4 is missing DirectX, so it is not the same OS.
None of the BSDs are the same OS, since they aren't 100% binary compatible.
All of the Linux distros are the same OS.
Linux/KDE and Linux/GNOME are two different OSs. (Loading redundant libraries is only a notch above WINE or lxrun from a performance point of view, especially since lxrun runs near-native and RAM gets clobbered in the KDE/GNOME case)
One thing I was thinking is that journaling data or disk cache could be written to a battery backed up RAM-disk. That way, if the power fails, all the data would still be on the RAM disk, and the disk could be properly updated. The RAM disk would be as fast as regular RAM (well, depending on where it is located) so writes would be nice and fast. RAM is cheap, batteries are cheap, so whats holding it up?
The next generation, be-all, end-all filesystem for Linux is...SLOWER? than Ext2? Are you kidding me? I don't really understand what problem he is trying to solve. Current journaling filesystems are a good deal FASTER than ext2. The one I have most experiance with is BeOS. On Bonnie (one of the only disk tests available on BeOS) BFS beats ext2 by nearly 20% with about 40% less processor usage (If you want to see the actual results, I'll post 'em if you want) on the read tests, and by a smaller margin on the write tests. It has problems on the read-back tests, but that is due to BeOS's VM issues. As for ReiserFS, I've used that too and that is also faster than Ext2. So if journaling FSs are faster than the current ones, why bother making one that is slower?
The problem is that the ascension of power is NEVER that easy. Not even Linux is immune from egoists, and if Linus goes away, there is going to be a major transition period while things readjust. As Linux becomes more popular, the "Grand Linux pooba" position will become more coveted. Take, for example, the US government (to strech a metaphor) The main reason why the US government is so phenominally stable is because everything is down on paper. There is none of this "I'd guess Alan Cox..." business. They have it mapped out very far. If this guy dies, this guy gets it. If he dies, this guy gets it. There is no ambiguity, and thus there is little chance of a power struggle. The point is that FreeBSD has plan of what to do if the leadership changes, and how to handle changes of leadership. A constitution if you will. Linux has no such plan, and is susceptible to the problems that come from not having a plan.
"I sent email to [LINUS] a couple of years ago, offering to help, buy stock, port something, whatever. Never heard anything back. So fuck [him] ... (mother joke deleted) ... and the horses [he] rides in on. Fuck [him] [] with a wire brush!"
Listen to yourself rant. Your just bitching because they rejected you. At that time period, Be was extremely supportive of developers. Ask anybody who has worked with them. Just because they didn't get to you doesn't mean that they are somehow evil. And www.beunited.org is a user group, and they are quite a friendly bunch over there.
Or, to coin a phrase ala the Japaneese,t ive"
"ultra-turbo-super-snarky-double-happy-conserva
To get an idea of good sueprlatives, look no further than our good friends in the Japaneese media industry.
Its true though. Is it potshotting to point out flaws in something else? When MS says "Windows is a much more robust enterprise computing solution than Linux" they are taking potshots. When someone points out an actual flaw in a plan or design (like when Mindcraft pointed out that the TCP/IP stack needed some work for high-end hardware) then it is totally valid and in fact useful. In the case of mindcraft, the kernel developers took a look at the problems and fixed it.
Um, Intel has demonstrated P4's too. You can't justifiably class one as vaporware without classifying the other as well, (or vice versa)
1) I think that is because Windows doesn't use the HLT instructions, which not only prevent instructions from executing during idle loops, but cools the CPU down in the process.
4) You can never have enough speed. Not even on a laptop.
5) Uh, that would be hard.
Umm, all the tests conducted ARE real apps. Thankfully, we seem to have evolved past the Winstone era. Unreal Tournament is a real FPS measure, Cinema4D and Povray test actual rendering times, and Bapco Sysmark is a script of around a dozen common Windows applications (Photoshop, Office, Netscape, etc.) So all these results ARE valid, and the loop thing really wouldn't change anything. (The score reported by Bapco on the Photoshop segment is going to be damn close to actual photoshop performance, because it IS actual photoshop perfromance.) The performance is still pretty good though, just not as groundbreaking as Transmeta would have you believe.
It really shouldn't use up that much CPU power. According to the benchmarks, MacOS X is memory hungry, but just as fast as other UNIXes in terms of graphics (dismal I know.) The main thing is that most of the GUI is still bitmapped, its just that the engine has the capability to add all this stuff to it. Plus, if any bright person ever accelerates PDF in hardware, then graphics designers would be in hog heaven.
Ahem, attributes? BeOS has 'em! (Everyone else should too!)
Umm, sorry to point this out, but Mach is anything BUT tight. As if FreeBSD on TOP of Mach. The core of OSX is actuall quite bulky. And whoever thought of the stupid "system-server" idea should be shot. On BeOS if the net_server crashes (which happens about once a day, and don't worry, its being replaced) I can just kill it and restart. Under OSX, even though networking is in usermode, a crash of the networking will crash the entire system. In fact, I can crash just about every server except the app server (even the input server if you have a script kill it and bring it back) without locking the system. The NeXT approach totally loses the advantages of having a microkernel design.
Because of things like page flipping?
>>>>>>>
A 20fps difference because of page flipping? I highly doubt it. At most, you're sucking up around 200MB of bandwidth because of the blitting. That's a drop in the bucket for the GF2. Not to mention the fact that even at low res, the Linux drivers are STILL slower. No, the evidence suggests that something other than the blitting is holding back the GF2.
Because most Linux users routinely have tens of processes running in the background while using their systems?
>>>>>
If those idiots conducted benchmarking with tens of processes running in the background, than it is their own damn fault. Not to mention the fact that any half intelligent user tweeks their machine, cutting out unneeded processes. Of course, half of the people using RH6 are running SendMail in the background (which is loaded by default on those systems.)
Because, as good as the NVIDIA drivers are, they are still new (labeled as Beta, even)?
>>>>>>>
They are still beta, but they are based on rock solid code. What about cross-platform access don't you understand? Any bugs are in the driver/OS glue layer, and I seriously doubt that any major performance bugs could be hiding in there.
Because a good Linux driver should perform some minimal input checking to enforce security (I don't know if NVIDIA does this--more of a DRI-ish
thing)?
>>>>>>>
If security involves a 20-30% performance hit, than I say "welcome crackers!" On a game machine, security at that level is absolutely and totally useless and should be turned of. For a home machine, the only security should be in the network server. There is no need on a desktop to protect the user from local processes.
I think I responded to the wrong person. I agree with you, that the G4 has a worse price/performance than the PIII. I was talking to the guy who said that the G4 chip was cheaper than the PIII.
But you can't just buy a G4 like you can a PIII. You have to buy the $3500 system around it. Apple won't give you a choice.
Seriously though, it wasn't as bad in the good old days when the price premium was maybe 10% or so. These days, with all the money you save, you're much better of getting another 256Meg or RAM or something. Also, the Athlon prices really aren't bad at all. Something like $650 for the 1.1 GHz Athlon (on pricewatch) Score!
And this has to be said.
All you memory bus freaks get off of it.
These procs aren't made for servers. If you put these procs in a server you are wasting your time (put slower procs and more memory and/or SMP) Otherwise, for games, 3D rendering, video editing, and 70% of the things that these procs are used for, CPU speed is still king. Example: QuakeIII uses about 200MB/sec of bus bandwidth. That's less than half the sustained (not theoretical) bandwidth of PC100 SDRAM. All the tests between PC100 and PC133 (or even PC66) show very little performance difference compared to bumping up the CPU speed a 100MHz or so. (Check www.sharkyextreme.com the Celeron vs. Duron tests)
Male chauvanist.
But AMD's CPUs AREN'T clones of Intel. And that analogy is still wrong because while AMD and Intel CPUs are instruction set compatible, SSE and 3DNow! aren't. Lastly, you can't say SSE is a "hacktogether" response because I'm pretty sure they were working on it before 3DNow! was released. (What, you think you can put together an instruction set in a couple of months? KNI (Katmai New Instructions) were in planning a while before 3DNow! came out.) Also, SSE is in many ways superior to 3DNow!. It has more developer support, it has a wider range of instructions, and when fully implemented (which it is not in the PIII series) it is twice as fast (due to the whole 128 vs. 64 bit thing.)
A) NVIDIA has some unopenable stuff in the drivers.
B) (Much more important) NVIDIA has no reason to help out Matrox and the others. If you get your head out of your oss ass and look around, you'll notice that all the card companies *except* NVIDIA are having problems with their OpenGL drivers. If you read last months MaximumPC, you'll read an interview with the OpenGL driver developer at Matrox. He says that a GL driver is a lot of work, which is why the Matrox GL drivers aren't 100% yet. NVIDIA has a kick-ass OpenGL driver. A GL driver isn't an ordinary graphics driver. It is a complete implementation of the OpenGL pipeline (an ICD) Now if your implementation of OpenGL was faster than everyone else's (who were having problems with their own implementations and would love to get their hands on yours) wouldn't YOU keep yours closed?