Since you're brave enough to try Qt 3.1 beta, you should try FreeType 2 from CVS. They've got some really cool stuff in the autohinter that works much better than disabling hinting entirely.
Actually, it all depends on the people making the styles. In this day of OS X's lickable GUI, extremely bright UI's are "in." However, all hope isn't lost. Both Liquid and Keramik do a pretty good job of respecting your color scheme. Khaos is a good dark one, though you might want to tweek the window background. Personally, default Keramik or Liquid is unusably bright on my LCD so I use the Helix theme. Yes it's perriwinkle, but extremely easy on the eyes:)
Actually, Microsoft integrated a browser with the OS. KDE just integrates a browser with a desktop environment. And you can easily use KDE without Konqueror (like RedHat does) or Konqueror without KDE (Konqueror/Embedded).
Um, that doesn't make any sense. The SSE2 unit is also good (usually better than Altivec since the P4 has 3x the memory bandwidth of the G4) at audio, video, and Photoshop. It's just not as good at RC5 because it lacks a permute unit. Quoting RC5 scores showing the G4 beating a P4 or Athlon are thus meaningless unless you're doing a lot of RC5 crunching.
I've using a dual 1.25 at Microcenter, and though it was snappier than the iMac, it still was nowhere near as responsive as WinXP on anything faster than a 2Ghz P4.
To respond to the two whole seconds thing: I'm an impatient person. The human response time is about 1/3 of a second. The computer may spend most of its time waiting for me, but unless every time *I* wait for it is less than this 1/3 of a second, it's still too slow. As for your 300MHz G3 running OS X, I feel sorry for you. I've used OS X on a 800MHz G4 (512MB) and it's unusably slow. Thus you can see why KDE 3.x on a 2GHz P4 is only barely usable to me.
Where do you get twice the speed? Do you mean twice the _clock speed_? Clock speeds really, really, absolutley, do not determine speed or performance. >>>>> CPU Performance = IPC * Clocks_Per_Sec. Clock speed is fully one half of the performance equation, no matter what Apple tells you. It's a simple multiplication. If you can get twice the IPC running the same code, then you can beat a 2x clock speed disadvantage. If you can't (and a G4 can't) you can't. (Note, this is CPU performance only. It's the system designer's responsibility to surround a fast CPU with good memory subsystems, which AMD and Intel do, and so far Apple does not).
Did you know that a P4 takes 20 clock cycles to perform a multiply? >>>> Did you know that the G4+ takes 7 clock cycles to do the same? Actually, both are simplifications. Actual instruction latency charts are published on both Motorola's and Intel's website, I suggest you read them. Yes, it takes a P4 around 20 clocks to do one multiply. If you're doing one multiply per program, then a P4 will be a lot slower. But thanks to something called pipelining (read about it, try ArsTechnica) a P4 can have 20 multiply instructions "in the pipe" at once while a G4 can have 7 "in the pipe" at once.
You can chop up your instructions as much as you want, and increase the clock to hell, but not change performance at all. >>>>>>>> Um, a P4 at 100 GHz, even if it took 20 clocks per multiply would get about 5 billion multiplies per second. A G4 at 1 GHz, even if it took 1 clock per multiply, could only get 1 billion per second. Clock speed does matter. In fact, it's a linear factor!
The chip IBM is making is a mips based chip, and takes fewer cycles to perform all its instructions. >>>>>>> I think you mean "RISC" chip.
It also has a _ton_ more registers, which means you can perform significant operations without going to or from memory. >>>>>> Actually, a G4 has 32 general purpose integer registers, and 16 rename registers (48 total) while the P4 has 8 general purpose integer registers mapped to 128 entry internal register file (128 total). The G4 has the advantage of more registers directly visible to the compiler, but that's a code optimization issue, not so much a data storage issue.
Reading or writing a number to memory is about 100 times slower than an arithmatic instruction. >>>>>> Not quite that much. Again, I suggest you read some actual timings:)
But to use those coprocessors, >>>> x86 FPUs have been integrated since the 486. The MMX and SSE/SSE2 units have always been integrated. They are just another execution unit, like the integer or AGR units.
you have to go into modes like mmx. And bolted on extra instructions like mmx have restrictions on them, like not being to do mmx and floating point math at the same time. >>>>> Nobody uses MMX anymore:) The FPU instruction set isn't "bolted-on" an is fully independent of the integer unit. The SSE/SSE2 units are also fully independent. Of course, that's the external appearence. The internal execution units of the processor look different, even in a G4. The Altivec unit is actually 5 totally different units, while the P4 FPU and SSE units are actually one integrated unit. Of course, these are implementation details that don't really make a difference unless you're doing multiple types of floating point operations at once. In the common case of doing a bunch of the same operation on a bunch of data, they're equivilent.
For the future, 64-bit is the way to go, and x86 is not. >>>> But what if you have a 64-bit x86? What'll happen then? Ah, my reality is being distorted! My puny mind... my puny mind!
Actually, the RC5 test is a famous example of a misleading benchmark. The AltiVec unit in the G4 has a vector permute unit that is very handy for stuff like crypto but little else. The RC5 benchmark is specifically coded to use this unit. It's not a very good indicator of overall performance. As for PPC (discounting the POWER series), I've never liked it very much at all. It never had the insane multi-proc system architecture of a SPARC or MIPS machine or the pure CPU power of an Alpha. In the end, it was just fairly low-end RISC with good power consumption. Even an individual POWER-4 does't look too shiny next to an Alpha or Itanium2, especially given the insane amount of cache (128MB!) that they were using in the SPEC benchmarks.
PS> A Power4 puts out about 125 watts, essentially the same as the 130 watts put out by the most power-hungry Alphas.
I've diatribed before on this topic, and would like to share an insight. AltiVec very well may show some good benchmarks in some cases, but there is a very good explanation for it. The G4 chip is extremely memory bandwidth limited. It's memory bus allows for something like 1.3 GB/sec of bandwidth, and on a dual processor Mac that bandwidth is shared. Altivec can chew through a whole lot more than that in a given second. On datasets that are memory bandwidth limited (anything greater than 2 MB), a P4 will whip a G4's ass due to the 3x memory bandwidth advantage (4.2 GB/sec). On datasets that fit entirely in the internal caches (anything less than 512 KB) the P4 will whip the G4 because it also has several times the internal cache bandwidth (more than 2x depending on clock speed). The only case in which he G4 will win is data sets between 512KB and 2MB. The G4 has a fast DDR-SRAM backwide cache which the P4 doesn't. While a 1.5 MB dataset will spill the P4's cache and hit main memory, the G4 will be able to satisfy it out of the backside cache. This could very well explain certain G4 benchmarks.
On top of this, when comparing the machine side-by-side with a 2.8 Ghz Pentium running XP, I highly doubt you'd notice any perceived speed deficiencies at all on the PowerMac... >>>>> Heh heh. In our library, we've got some 2.26 GHz P4s running XP right next to one of those fancy wide-screen iMacs (800MHz G4). Both machines have 512MB of RAM. While OS X is definately "prettier" (though not as pretty IHO as Keramik, but I digress) the Mac was definately slower. A lot slower. "Feels like a 500 MHz Celeron" slower. And I was just surfing the web and printing some stuff out. It was mostly a snappiness thing. While the WinXP machine did everything immediately, the Mac was more "dignified" about things. I really hate using those things, but I try them every time I get the chance just so I can write stuff like this:)
The frame-rate faster than refresh rate arguement is entirely stupid. If you're getting 150 fps in a game, you're not turning the detail high enough. The truth is that even a brand spanking new P4 2.8 GHz with a Radeon 9700 isn't going to run Doom III at 1600x1200 at more than ~30fps. And I Doom III still doesn't come anything close to the quality of the FMV in games even from the PS-1 days. Also, if you do stuff like DivX encoding, Ogg encoding, etc, you need those gigahertz. Don't get me started on GCC. Compiling templated code in g++ takes several times longer than the equivilent C code, and it's irritating when even a simple templated program takes minutes to compile. Lastly, GNOME and KDE eat up those processor cycles. I don't care if my CPU is only running 5% load on average, but if it can't move the GUI along fast enough, I need an upgrade. Even my P4 2GHz is only barely satisfactory running KDE 3.x (two seconds just to launch Konqueror from cache!).
Well, no wonder that he wasn't satisfied with that: that's a lousy implementation because the two can become disassociated. >>>> You didn't even understand the implementation. Who cares about your opinion of it? The directory was to be a hidden one accessed through a pointer in the inode of the given file. There is no way the two could become disassociated.
A better implementation is to stick both the content and the attributes into a single directory and treat the directory itself as a single document in the GUI. >>>> The problem with the orignal implementation was not disassociation, but performance. Instead of taking one disk access to display a file, it took several. That killed the speed of the file browser. And your implementation is really annoying to the user. I really hate OS X in the way it represents things differently in the GUI than in the actual OS. What if you don't use the GUI for file browsing? You go and modify bash to handle the hack too? With the attribute implementation, the only tools that need modification are those that deal with directories directly. It is much closer to the standard UNIX file semantics and the user's idea of what a file is.
A lot of junk has been dumped into Linux, much of it not very widely used. If the majority of Linux software ever started relying on such features, Linux would cease to be a UNIX-style operating system. UNIX was designed by people rebelling against nonsense like ACLs, file attributes, etc.; it was a deliberate choice. >>>>>>> ACLs and file attributes are just different implementations of metadata and security. I bet you think that utime and the rwx bits are nonsense too? As for being a real UNIX, ACL's are supported in most commercial UNIXes and file attributes come directly out of IRIX.
XML files are supposed to identify what the XML represents. Dumping bits of XML into a file and determining its type through file attributes is contrary to everything XML stands for. Other text files encode their type as part of their file name (usually, an extension). >>> Extensions are an anarchronism. Just because they're popular doesn't mean they don't suck.
1) It's not whether or not the Linux system can technically handle all the threads. It can and has been able to for years now. The problem is that Linux GUI applications are not written in such a way that emphasises interactive performance. And there doesn't have to be that much optimization for it. The BeOS (and Windows to a large extent) kernels "optimize" for interactive performance in the sense that they offer a standard priority scheduler. The GUI itself then uses this to set the priority of GUI apps high by default. The same effect can be achieved in Linux by manually renicing X and your apps (or in the case of a DE, the gnome-session or startkde processes).
2) Sticking attributes in a directory is a bad idea. Giampalo, in his book about the Be file system., talks about how that was his original implementation (each file has an associated atttribute directory) but the GUI's need to access several attributes (timestamps, filetypes, etc) for each file necessitated including a shortcut mechanism at least for certain small attributes. And attributes are a *good* idea. Moving forward, both XFS and Reiser4 will have them, and Linux will support them through a common API. As for filetyping, UNIX's "fingerprint" mechanism is only half a solution. Most files have no detectable fingerprint and this will only become more common as more text-based formats (XML) proliferate. BeOS includes a registrar daemon that uses file fingerprinting to recognize files and attach to them an attribute identifying the type. These attributes can be edited by the user for increased flexibility.
Um, speak for yourself. If all I cared about was applications and hardware support, then I'd use Windows. But I hate Windows (both using it, and bending over for MS for the opportunity to) so I use Linux, despite the fact that Kopete isn't as good as AIM and I've got no real replacement for Photoshop.
Actually, I've been using hacked up preempt/XFS kernels for awhile. But I'm lazy, the default xfs-sources doesn't include preempt (with good reason, they conflict with XFS), and my P4 is fast enough that I don't notice:)
Actually, a thread switch is significantly faster than a context switch. x86 machines don't have a lot of state. EROS can do a thread save and restore in about 20 clock cycles, and Linux is known for very fast thread switching, so I doubt it's much slower. It's not like a full context switch where the TLB gets flushed and the cache gets blown. Besides, modern processors can handle thousands for process (not thread) switches per second without any noticible performance impact. That said, threads, even with a speed hit, are worth it. BeOS wasn't a blazingly fast OS in many cases. tar/gzip would run about 10-15% slower under BeOS than under Linux. But users don't really care about a few seconds difference in tarring a file, but care a lot about even 1/3 a second difference in UI response time.
The whole JPEG thing was stupid (I think he might have been referring to something about videos), but the MIME and multithreading is dead on. Sure UNIX and Windows have had multithreading for awhile, but they still don't do it as well as BeOS. BeOS had threads everywhere. That meant that even if the system was nearly brought to its knees with load, it still felt responsive. My 2 GHz P4 running KDE 3.x (Gentoo, uber-tricked out) still doesn't match the responsiveness of my 300 MHz PII running BeOS (dead stock, no tweeking), though its getting close thanks to 6x the processor and 10x the RAM. People complained it was harder to program because of the insistence on threads, but I personally think it was just different, and hard to get used to unless you learned it that way from the beginning. As for the MIME support, sure every OS supports it, but which ones use it as the standard file typing mechanism? BeOS stored the MIME type of a file in an attribute, and had a registrar that automatically detected the type of new files as they were added to the system. This, combined with an utterly flexible mechanism of defining type handlers resulted in the ultimate file typing solution.
I've got a copy of the game right now. It's pretty good, but no Secret of Mana:) Methinks you're looking in the wrong places. Gobe was offering a bundle of BeOS 5 Pro and Corum III awhile back.
Of course, I'm assuming the developer is smart enough to have a proper build system set up. But when a program is in active development, you'll often have modified files that can take a significant amount of time to recompile. And god forbid you modify a common header. Even if you add one constant to support one source file, almost all build systems will recompile every single file that includes that header.
Re:Some of us do actual -work- with our computers,
on
Gentoo Linux Reloaded
·
· Score: 2
Um, my box has been rock solid stable since I installed Gentoo about a month ago. In the meantime, I've installed tons of beta software (currently running a beta kde on a beta Qt, works great) and have messed around with getting prelinking working twice. Also enlarged my XFS partition on the fly while I was at it. Not only have I yet to hose it, but I haven't figured out how to crash it either. Maybe I should play with the development kernels. After all, they're in the Portage tree now:)
The ebuild system kicks ass. Never has it been easier to hack your packages without losing dependency checking. Right now, I'm running KDE 3.1 beta2 on Qt 3.1 beta2. For awhile, I was running XFree 4.2.99 and Qt 3.0.5 with Xft2 patches. All I had to do was copy the relevent ebuilds, change a few lines, and voila, new package! The simplicity of portage makes it easy for people to make their own ebuilds. Check out the Gentoo forums and you'll find all sorts of ebuilds for totally experimental programs (like Phoenix).
I think the install system is just peachy. None of that user-interface BS. Seriously, though, I've installed Gentoo at least a dozen times, and each time I'm pleasently surprised by how much less crappy it is than those fancy GUI installers. It takes less time, too. Take the (wonderfully written, btw) instructions, print them out, and type exactly the commands as they're shown in the pretty stand-out boxes, replacing/dev/hda3 with/dev/hdaX as needed. No waiting several minutes for a GUI installer to load from CD, no waiting for the Mandrake installer to read the package DB, etc. Maybe 10 minutes of setup, and then a couple of hours of compile and you're done.
This is true. Unfortunately, traditional makefiles tend to encourage compiling each file seperately, so you have to use workarounds like ICC's.il file mechanism to do global optimizations. However, for developers, this distributed processing is a big boost. When you're working on code, you have to recompile a project repeatedly, and distributing the workload pays off in decreased frustration. For those intermediate builds, optimizations don't really matter anyway.
I make copies of game CDs so me and my brother don't have to share a physical CD. Illegal? On the verge of, maybe. But I only keep the game around to play him multiplayer, and $100 (2 copies) to play a single multiplayer game is over the top. Besides, I can play multiplayer in my PS2 games for the cost of one CD, after all. They really need to change licenses to per-household. It's not like anybody buys multiple copies for multiple computers in a house anyway!
Slashdot Mirror
Since you're brave enough to try Qt 3.1 beta, you should try FreeType 2 from CVS. They've got some really cool stuff in the autohinter that works much better than disabling hinting entirely.
Actually, it all depends on the people making the styles. In this day of OS X's lickable GUI, extremely bright UI's are "in." However, all hope isn't lost. Both Liquid and Keramik do a pretty good job of respecting your color scheme. Khaos is a good dark one, though you might want to tweek the window background. Personally, default Keramik or Liquid is unusably bright on my LCD so I use the Helix theme. Yes it's perriwinkle, but extremely easy on the eyes :)
Actually, Microsoft integrated a browser with the OS. KDE just integrates a browser with a desktop environment. And you can easily use KDE without Konqueror (like RedHat does) or Konqueror without KDE (Konqueror/Embedded).
Um, that doesn't make any sense. The SSE2 unit is also good (usually better than Altivec since the P4 has 3x the memory bandwidth of the G4) at audio, video, and Photoshop. It's just not as good at RC5 because it lacks a permute unit. Quoting RC5 scores showing the G4 beating a P4 or Athlon are thus meaningless unless you're doing a lot of RC5 crunching.
I've using a dual 1.25 at Microcenter, and though it was snappier than the iMac, it still was nowhere near as responsive as WinXP on anything faster than a 2Ghz P4.
To respond to the two whole seconds thing: I'm an impatient person. The human response time is about 1/3 of a second. The computer may spend most of its time waiting for me, but unless every time *I* wait for it is less than this 1/3 of a second, it's still too slow. As for your 300MHz G3 running OS X, I feel sorry for you. I've used OS X on a 800MHz G4 (512MB) and it's unusably slow. Thus you can see why KDE 3.x on a 2GHz P4 is only barely usable to me.
Where do you get twice the speed? Do you mean twice the _clock speed_? Clock speeds really, really, absolutley, do not determine speed or performance.
:)
:) The FPU instruction set isn't "bolted-on" an is fully independent of the integer unit. The SSE/SSE2 units are also fully independent. Of course, that's the external appearence. The internal execution units of the processor look different, even in a G4. The Altivec unit is actually 5 totally different units, while the P4 FPU and SSE units are actually one integrated unit. Of course, these are implementation details that don't really make a difference unless you're doing multiple types of floating point operations at once. In the common case of doing a bunch of the same operation on a bunch of data, they're equivilent.
>>>>>
CPU Performance = IPC * Clocks_Per_Sec.
Clock speed is fully one half of the performance equation, no matter what Apple tells you. It's a simple multiplication. If you can get twice the IPC running the same code, then you can beat a 2x clock speed disadvantage. If you can't (and a G4 can't) you can't. (Note, this is CPU performance only. It's the system designer's responsibility to surround a fast CPU with good memory subsystems, which AMD and Intel do, and so far Apple does not).
Did you know that a P4 takes 20 clock cycles to perform a multiply?
>>>>
Did you know that the G4+ takes 7 clock cycles to do the same? Actually, both are simplifications. Actual instruction latency charts are published on both Motorola's and Intel's website, I suggest you read them. Yes, it takes a P4 around 20 clocks to do one multiply. If you're doing one multiply per program, then a P4 will be a lot slower. But thanks to something called pipelining (read about it, try ArsTechnica) a P4 can have 20 multiply instructions "in the pipe" at once while a G4 can have 7 "in the pipe" at once.
You can chop up your instructions as much as you want, and increase the clock to hell, but not change performance at all.
>>>>>>>>
Um, a P4 at 100 GHz, even if it took 20 clocks per multiply would get about 5 billion multiplies per second. A G4 at 1 GHz, even if it took 1 clock per multiply, could only get 1 billion per second. Clock speed does matter. In fact, it's a linear factor!
The chip IBM is making is a mips based chip, and takes fewer cycles to perform all its instructions.
>>>>>>>
I think you mean "RISC" chip.
It also has a _ton_ more registers, which means you can perform significant operations without going to or from memory.
>>>>>>
Actually, a G4 has 32 general purpose integer registers, and 16 rename registers (48 total) while the P4 has 8 general purpose integer registers mapped to 128 entry internal register file (128 total). The G4 has the advantage of more registers directly visible to the compiler, but that's a code optimization issue, not so much a data storage issue.
Reading or writing a number to memory is about 100 times slower than an arithmatic instruction.
>>>>>>
Not quite that much. Again, I suggest you read some actual timings
But to use those coprocessors,
>>>>
x86 FPUs have been integrated since the 486. The MMX and SSE/SSE2 units have always been integrated. They are just another execution unit, like the integer or AGR units.
you have to go into modes like mmx. And bolted on extra instructions like mmx have restrictions on them, like not being to do mmx and floating point math at the same time.
>>>>>
Nobody uses MMX anymore
For the future, 64-bit is the way to go, and x86 is not.
>>>>
But what if you have a 64-bit x86? What'll happen then? Ah, my reality is being distorted! My puny mind... my puny mind!
Actually, the RC5 test is a famous example of a misleading benchmark. The AltiVec unit in the G4 has a vector permute unit that is very handy for stuff like crypto but little else. The RC5 benchmark is specifically coded to use this unit. It's not a very good indicator of overall performance. As for PPC (discounting the POWER series), I've never liked it very much at all. It never had the insane multi-proc system architecture of a SPARC or MIPS machine or the pure CPU power of an Alpha. In the end, it was just fairly low-end RISC with good power consumption. Even an individual POWER-4 does't look too shiny next to an Alpha or Itanium2, especially given the insane amount of cache (128MB!) that they were using in the SPEC benchmarks.
PS> A Power4 puts out about 125 watts, essentially the same as the 130 watts put out by the most power-hungry Alphas.
I've diatribed before on this topic, and would like to share an insight. AltiVec very well may show some good benchmarks in some cases, but there is a very good explanation for it. The G4 chip is extremely memory bandwidth limited. It's memory bus allows for something like 1.3 GB/sec of bandwidth, and on a dual processor Mac that bandwidth is shared. Altivec can chew through a whole lot more than that in a given second. On datasets that are memory bandwidth limited (anything greater than 2 MB), a P4 will whip a G4's ass due to the 3x memory bandwidth advantage (4.2 GB/sec). On datasets that fit entirely in the internal caches (anything less than 512 KB) the P4 will whip the G4 because it also has several times the internal cache bandwidth (more than 2x depending on clock speed). The only case in which he G4 will win is data sets between 512KB and 2MB. The G4 has a fast DDR-SRAM backwide cache which the P4 doesn't. While a 1.5 MB dataset will spill the P4's cache and hit main memory, the G4 will be able to satisfy it out of the backside cache. This could very well explain certain G4 benchmarks.
On top of this, when comparing the machine side-by-side with a 2.8 Ghz Pentium running XP, I highly doubt you'd notice any perceived speed deficiencies at all on the PowerMac... :)
>>>>>
Heh heh. In our library, we've got some 2.26 GHz P4s running XP right next to one of those fancy wide-screen iMacs (800MHz G4). Both machines have 512MB of RAM. While OS X is definately "prettier" (though not as pretty IHO as Keramik, but I digress) the Mac was definately slower. A lot slower. "Feels like a 500 MHz Celeron" slower. And I was just surfing the web and printing some stuff out. It was mostly a snappiness thing. While the WinXP machine did everything immediately, the Mac was more "dignified" about things. I really hate using those things, but I try them every time I get the chance just so I can write stuff like this
The frame-rate faster than refresh rate arguement is entirely stupid. If you're getting 150 fps in a game, you're not turning the detail high enough. The truth is that even a brand spanking new P4 2.8 GHz with a Radeon 9700 isn't going to run Doom III at 1600x1200 at more than ~30fps. And I Doom III still doesn't come anything close to the quality of the FMV in games even from the PS-1 days. Also, if you do stuff like DivX encoding, Ogg encoding, etc, you need those gigahertz. Don't get me started on GCC. Compiling templated code in g++ takes several times longer than the equivilent C code, and it's irritating when even a simple templated program takes minutes to compile. Lastly, GNOME and KDE eat up those processor cycles. I don't care if my CPU is only running 5% load on average, but if it can't move the GUI along fast enough, I need an upgrade. Even my P4 2GHz is only barely satisfactory running KDE 3.x (two seconds just to launch Konqueror from cache!).
Well, no wonder that he wasn't satisfied with that: that's a lousy implementation because the two can become disassociated.
>>>>
You didn't even understand the implementation. Who cares about your opinion of it? The directory was to be a hidden one accessed through a pointer in the inode of the given file. There is no way the two could become disassociated.
A better implementation is to stick both the content and the attributes into a single directory and treat the directory itself as a single document in the GUI.
>>>>
The problem with the orignal implementation was not disassociation, but performance. Instead of taking one disk access to display a file, it took several. That killed the speed of the file browser. And your implementation is really annoying to the user. I really hate OS X in the way it represents things differently in the GUI than in the actual OS. What if you don't use the GUI for file browsing? You go and modify bash to handle the hack too? With the attribute implementation, the only tools that need modification are those that deal with directories directly. It is much closer to the standard UNIX file semantics and the user's idea of what a file is.
A lot of junk has been dumped into Linux, much of it not very widely used. If the majority of Linux software ever started relying on such features, Linux would cease to be a UNIX-style operating system. UNIX was designed by people rebelling against nonsense like ACLs, file attributes, etc.; it was a deliberate choice.
>>>>>>>
ACLs and file attributes are just different implementations of metadata and security. I bet you think that utime and the rwx bits are nonsense too? As for being a real UNIX, ACL's are supported in most commercial UNIXes and file attributes come directly out of IRIX.
XML files are supposed to identify what the XML represents. Dumping bits of XML into a file and determining its type through file attributes is contrary to everything XML stands for. Other text files encode their type as part of their file name (usually, an extension).
>>>
Extensions are an anarchronism. Just because they're popular doesn't mean they don't suck.
1) It's not whether or not the Linux system can technically handle all the threads. It can and has been able to for years now. The problem is that Linux GUI applications are not written in such a way that emphasises interactive performance. And there doesn't have to be that much optimization for it. The BeOS (and Windows to a large extent) kernels "optimize" for interactive performance in the sense that they offer a standard priority scheduler. The GUI itself then uses this to set the priority of GUI apps high by default. The same effect can be achieved in Linux by manually renicing X and your apps (or in the case of a DE, the gnome-session or startkde processes).
2) Sticking attributes in a directory is a bad idea. Giampalo, in his book about the Be file system., talks about how that was his original implementation (each file has an associated atttribute directory) but the GUI's need to access several attributes (timestamps, filetypes, etc) for each file necessitated including a shortcut mechanism at least for certain small attributes. And attributes are a *good* idea. Moving forward, both XFS and Reiser4 will have them, and Linux will support them through a common API. As for filetyping, UNIX's "fingerprint" mechanism is only half a solution. Most files have no detectable fingerprint and this will only become more common as more text-based formats (XML) proliferate. BeOS includes a registrar daemon that uses file fingerprinting to recognize files and attach to them an attribute identifying the type. These attributes can be edited by the user for increased flexibility.
Um, speak for yourself. If all I cared about was applications and hardware support, then I'd use Windows. But I hate Windows (both using it, and bending over for MS for the opportunity to) so I use Linux, despite the fact that Kopete isn't as good as AIM and I've got no real replacement for Photoshop.
Actually, I've been using hacked up preempt/XFS kernels for awhile. But I'm lazy, the default xfs-sources doesn't include preempt (with good reason, they conflict with XFS), and my P4 is fast enough that I don't notice :)
Actually, a thread switch is significantly faster than a context switch. x86 machines don't have a lot of state. EROS can do a thread save and restore in about 20 clock cycles, and Linux is known for very fast thread switching, so I doubt it's much slower. It's not like a full context switch where the TLB gets flushed and the cache gets blown. Besides, modern processors can handle thousands for process (not thread) switches per second without any noticible performance impact. That said, threads, even with a speed hit, are worth it. BeOS wasn't a blazingly fast OS in many cases. tar/gzip would run about 10-15% slower under BeOS than under Linux. But users don't really care about a few seconds difference in tarring a file, but care a lot about even 1/3 a second difference in UI response time.
The whole JPEG thing was stupid (I think he might have been referring to something about videos), but the MIME and multithreading is dead on. Sure UNIX and Windows have had multithreading for awhile, but they still don't do it as well as BeOS. BeOS had threads everywhere. That meant that even if the system was nearly brought to its knees with load, it still felt responsive. My 2 GHz P4 running KDE 3.x (Gentoo, uber-tricked out) still doesn't match the responsiveness of my 300 MHz PII running BeOS (dead stock, no tweeking), though its getting close thanks to 6x the processor and 10x the RAM. People complained it was harder to program because of the insistence on threads, but I personally think it was just different, and hard to get used to unless you learned it that way from the beginning. As for the MIME support, sure every OS supports it, but which ones use it as the standard file typing mechanism? BeOS stored the MIME type of a file in an attribute, and had a registrar that automatically detected the type of new files as they were added to the system. This, combined with an utterly flexible mechanism of defining type handlers resulted in the ultimate file typing solution.
I've got a copy of the game right now. It's pretty good, but no Secret of Mana :) Methinks you're looking in the wrong places. Gobe was offering a bundle of BeOS 5 Pro and Corum III awhile back.
Turn of driver versioning in the kernel. If that doesn't work, that driver wasn't meant to work with your kernel so you'll have to urpmi
Of course, I'm assuming the developer is smart enough to have a proper build system set up. But when a program is in active development, you'll often have modified files that can take a significant amount of time to recompile. And god forbid you modify a common header. Even if you add one constant to support one source file, almost all build systems will recompile every single file that includes that header.
Um, my box has been rock solid stable since I installed Gentoo about a month ago. In the meantime, I've installed tons of beta software (currently running a beta kde on a beta Qt, works great) and have messed around with getting prelinking working twice. Also enlarged my XFS partition on the fly while I was at it. Not only have I yet to hose it, but I haven't figured out how to crash it either. Maybe I should play with the development kernels. After all, they're in the Portage tree now :)
The ebuild system kicks ass. Never has it been easier to hack your packages without losing dependency checking. Right now, I'm running KDE 3.1 beta2 on Qt 3.1 beta2. For awhile, I was running XFree 4.2.99 and Qt 3.0.5 with Xft2 patches. All I had to do was copy the relevent ebuilds, change a few lines, and voila, new package! The simplicity of portage makes it easy for people to make their own ebuilds. Check out the Gentoo forums and you'll find all sorts of ebuilds for totally experimental programs (like Phoenix).
I think the install system is just peachy. None of that user-interface BS. Seriously, though, I've installed Gentoo at least a dozen times, and each time I'm pleasently surprised by how much less crappy it is than those fancy GUI installers. It takes less time, too. Take the (wonderfully written, btw) instructions, print them out, and type exactly the commands as they're shown in the pretty stand-out boxes, replacing /dev/hda3 with /dev/hdaX as needed. No waiting several minutes for a GUI installer to load from CD, no waiting for the Mandrake installer to read the package DB, etc. Maybe 10 minutes of setup, and then a couple of hours of compile and you're done.
This is true. Unfortunately, traditional makefiles tend to encourage compiling each file seperately, so you have to use workarounds like ICC's .il file mechanism to do global optimizations. However, for developers, this distributed processing is a big boost. When you're working on code, you have to recompile a project repeatedly, and distributing the workload pays off in decreased frustration. For those intermediate builds, optimizations don't really matter anyway.
I make copies of game CDs so me and my brother don't have to share a physical CD. Illegal? On the verge of, maybe. But I only keep the game around to play him multiplayer, and $100 (2 copies) to play a single multiplayer game is over the top. Besides, I can play multiplayer in my PS2 games for the cost of one CD, after all. They really need to change licenses to per-household. It's not like anybody buys multiple copies for multiple computers in a house anyway!