The main reason people try to keep it so that 12pt is the natural size is because all application developers are idiots and make it difficult to configure fonts properly. There are so many X apps that have bad font management it isn't even funny.
Consumer-grade video hardware has quickly outpaced SGI's best offerings. A GeForce3 has the same processing power as their best offerings from just two years ago, and doesn't cost as much as a new car.
>>>>>>>>>>
Yea, isn't it ironic that SGI now uses NVIDIA hardware in their low-end workstations?
What I don't get is the obsession with 1.0 release numbers. Is it a bad thing that a project has matured and can definately be considered more than a 1.0 release?
They pretty much are. For example, they constantly remind you (in less than polite ways) that GCC 2.96 is unsupported. Then, they discourage people from distributing binaries so people will be forced to compile it themselves.
Coupla points:
1) Actually, 3D meshes perfectly with absolute measurement systems, since 3D has never used pixels. OpenGL, for example, is enitrely based on abstract units.
2) I think Berlin does this.
Speaking of build tools, there is a really nifty one called CONS It does automatic dependecy management, interfaces to repositories, and is written in Perl! I messed around with makefiles for a long time before I found this, and it made a fairly messed up kernel tree a cinch to build.
Unfortunately, KDE has the small problem that everything takes days to load. Its far more polished than GTK+/GNOME, but damn is it slow. Funny thing. I was using Windows XP the other day at Circuit City. I was amazed how speedy it was. Considering how badly configured store-display machines are, this did not say much for KDE...
1) Attributes are the future. XFS has them, they must be okay!
2) HFS is oddball in terms of design. Instead of explicit inodes and directories and whatnot, all file records are bunched together in the catalog file. This was cool back in 1980, but today, it means that the filesystem has to be single threaded (giant subsystem mutexes are so passe) and concurrency blows. BFS, on the other hand, is rather standard. Its got explicit inodes, B+ trees for directories, and uses a bitmap to manage free blocks. Nothing oddball at all.
Would you care to quantify that statement? I know that it's quite fashionable in this forum to parrot Linus Torvalds' blithe dismissal of Mach, but nobody ever seems interested in backing it up with any hard data.
>>>>>>>>
Read the GNU/HURD mailing lists about people wanting to switch HURD over to L4 because Mach just wasn't cutting it.
What an odd and incorrect statement. I don't really know where to begin. Do you really think that during the entire time that Mach was being used as the core of various incarnations of NeXTstep (on both 680x0 and ia32), MkLinux (on PPC, ia32 and PA-RISC) and MacOS X, not to mention countless other projects, that it was not "massaged" and updated significantly?
>>>>>>>
Tons of projects, yes. Huge leaps in capability? No. Take a look at all of the nifty stuff FreeBSD has been doing in the meantime. The VM subsystem has significantly overhauled (read Cranor's UVM paper and Matt Dillon's articles for info) as has the swap system and (with FreeBSD 5.x) the threading model and SMP system. Advances of that magnitude just haven't been made on Mach, plain and simple.
You dance with who brought you. OSX is based on NeXTstep, and NeXTstep was built on the Mach/BSD core. That codebase was stable, mature, and proven to be portable. They had, and have, no sane reason to rip it out.
>>>>>>>>>>
Umm, Apple ended up rewriting a lot of the upper-level software anyway. I would guess that porting to FreeBSD (given that both Mach/BSD and FreeBSD have the same API) wouldn't have cost very much time.
More mindless parroting of theparty line. Mach/BSD is in no way unstable, and stability is not the only benefit. Think "portability, modularity, features and elegance."
>>>>>>>>>>
1) Portability: Do you really think that Mach/BSD is more portable than any monolithic kernel, like Linux or NetBSD? Besides, Apple is the one who is making OS-X uniplatform!
2) Modularity: You call a monolithic system server moduler? Multi-servers are moduler. They're a great use of some of the inherent advantages of microkernels. Monoservers are just stupid.
3) Elegant: How? You take a basterdize the microkernel concept by sticking a monolithic system server on top of it!
So everyone keeps saying, but nobody seems willing to actually back up that assertion with anything other than vague handwaving.
>>>>>>>>>
Umm, just think this through. Say I want to read a byte from a device. Which is going to be faster, sending a message to the system server (which involves one system call to send the message, a slow context switch to change to the system server, code to process the message, another system call to send another message, and another context switch to change to the calling process), or invoking a single system call which involves no context switches?
As for porting, please remember that they ended up porting a good deal of FreeBSD 3.2 to Mach anyway.
If security has not improved why should I believe that stability has?
>>>>>>>>>
Because people who've actually used the thing can tell you that NT's based OSs have been very stable for years now. Win2K is stable just as NT4 was stable. Live with it. Get over it. Fix Linux.
Obviously, you've never seen good fonts. OSX fonts bite.
Not only are they all blurry, but the blur doesn't
even hide the crappy non-hinted font rendering!
If you want to see real quality fonts, check out
KDE2 (which uses FreeType2) or QNX Photon (which
uses BitStream's FontFusion). With good fonts, FT2
is as good as FontFusion, except maybe the AA, which
is of slightly lower, but still very good, quality.
Hey, I love BeOS as much as the next fanatic, but (as much as I would love to) I can't use it because its compiler is old and there is no support for the rear-channel on my SB Live!
The fact that BeOS wasn't open source is what ultimately killed yet. OSS code is hard to kill. Hell, HURD is still plodding along after all these years! (Put down the pitchforks, that was a joke!) BeOS was stagnated. Be didn't have the money to improve it (and yes, there are tons of things that could have been improved) and nobody had access to the source so they could. If it was open source, at least the OpenBeOS BlueOS guys could have put their efforts into improving BeOS, rather than replicating work that had been done long before. And the "OSS leads to fragmentation" idea is bullshit. Just take a look at FreeBSD! Even Linux (the kernel) is rather tightly unified, given the vast number of sources working on it (kernel devs, SGI, IBM, RedHat, Mandrake, etc).
1) HFS doesn't have true attributes. It has two forks.
2) HFS sucks. Its more advanced than FAT32, true, but Giampalo was right when he called HFS the "oddball cousin" of the filesystem world.
My machine has been all Linux for several months now. Its not as bad as I thought it was going to be, but its not great either. After tons customization (XFS, pre-kernels, preemptive + lock breaking patches, custom compilations, f**king with fonts for days on end, etc) Linux feels almost as fast as Win2K. Most of the time, anyway. All my Galeon windows still freeze up for several second at a time while one of them is loading/. (I miss multithreading), AbiWord still has butt-ugly non AA fonts, XMMS still sometimes skips when I'm doing multiple compiles at the same time, GTK+ apps still dump on me at totally random moments, Sylpheed won't copy and paste into gedit, and the GNOME file panal is still as braindead as ever. Its not all bad, however. Compiles run faster than they used to. Urpmi is truely nifty. Sylpheed is a good mail client, and XFS is an awesome filesystem. I finally have good compile tools (ICC), and I've found the power of 'vi' because I've been forced (thanks/etc!) to use it so much. Still, its not BeOS. This is depressing...
Gah. No. OSX has performance issues, yes, but they have zilch to do with Mach/BSD. That codebase is over 15 years old, and is quite mature and refined, thank you.
>>>>>
You miss an important distinction. OSX is based on old code. Mach was never very good as a microkernel to begin with, and it hasn't been heavily updated in years. FreeBSD on the other hand, is very mature, just like Mach, but has had the benifet of years of massaging in the intervening years. Apple really was out to lunch when it decided to use a Mach/BSD combo. First, it has no real benifets, since the monolithic system server eats any potential gains in stability. Worse, it loses performance for being based on a microkernel. What would have made much more sense for Apple would have been to base OS-X on top of FreeBSD. They would have gotten a much better core OS, the FreeBSD guys would have gotten access to nifty things like XML configuration, and Apple wouldn't have to be in the core OS business.
Basically, you have for each kernel version you have several -preX kernels. Once you get the thing stable, you rename the line to -rcX kernels. From here, you accept only bug-fixes. When the -rcX kernel gets really stable, you rename it to -final, without changing anything else.
Re:What is "preemtive" for ?
on
Kernel 2.4.17 Out
·
· Score: 3, Informative
Ah! Partially right! But sorry, no dice. The only cooperative multitasking that is done in Windows 9x is with 16 bit applications, since all 16-bit apps are run in the same virtual machine. All 32-bit apps are fully preemptively (userspace multitasked. As for memory protection, that's only partially true. Application memory is indeed protected from each other. However, there is a big 1GB region of shared memory that is unprotected. Apps that use this region and asking to hose the system. Also, some bits of kernel memory are unprotected because DOS apps need access to them.
As for NT, it is a fully preemptible kernel, both in userspace and kernel space. Like all preemptive kernels, of course, it is not preemptible when interrupts are disabled (since the clock interrupt can't happen). The main reason why NT has always been preemptive is because its always been SMP. The locking requirements on SMP are similar to to locking requirements for a preemptible kernel, so you can get both together for the price of one. Indeed, the preemptive patch for Linux is very small because it uses the existing SMP locking mechanism.
Because they have a sane versioning system and don't try to be all 'leet and artificially keep their version numbers down! What is it about OSS developers that makes them dispise version numbers above 1.0?
Re:What is "preemtive" for ?
on
Kernel 2.4.17 Out
·
· Score: 4, Informative
There are two things here. Preemptive in userspace, and preemptive in kernel space. Linux is preemptive in user space, meaning that when a process is running application code, it can be preempted. When it is running kernel code, however (ie. during a system call) the scheduler will not preempt the thread, even if a higher priority one becomes available. Essentially (on a single processor) the kernel code is cooperatively multitasked. Kernel code runs until schedule() is called to invoke the scheduler. Some kernel code paths are very long, which leads to long periods where the current process cannot be preempted, which kills latency.
Also, to expand on the original question, there are a couple objections to the patch: It has the potential total throughput, because more locking must be used since the kernel can be preempted at any time, not just at specified points. However, in practice, the effect on throughput seems to be negligible. It also increases complexity, due to additional locking, but most of the complexity is there anyway, in the form of the SMP locks.
You couldn't really use templates in KDE, since the virtual functions are essentially set up as a clean callback method. A draw callback, for example, isn't implemented as function pointer, but overriding a virtual Draw() method in a view object. The two techniques are so similar at the low lever, however (deference a pointer and call the function found there), it should be possible to make KDE's load performance no slower than GTK+ or Xt's.
I don't think its that bad of a problem. a.out had other issues that made people hate it (specifically, shared libraries were a bitch to build and the semantics of shared and dynamic libraries were different). The only problem with prelinking is that on x86 machines, you soon run out of that paltry 4GB address space. On my machine,/usr/lib,/lib, and/usr/local/lib add up to about 460MB. These images become bigger in RAM since the BSS (zero-initialized data) isn't present. On a larger system, you could easily blow the address space with all the libraries (think Microsoft apps!) With 64bit archs, this is a non-issue, however. The good thing about the scheme, however, is that you potentially don't need position independant code, since you could relocate the library once at install time and not have to touch it afterward.
Honestly, KDE has few features that aren't present, for example, in WinXP. If Microsoft can make WinXP run as fast as Win2K (which is blazingly so), and decrease their already low app-startup times significantly, KDE must be doing something wrong. It's ironic, though. The Linux kernel blows away the Win2K kernel, especially in terms of process creation/switching times. XFree86 4.1 (with NVIDIA drivers anyway) is just as fast as the Win2K GDI. Yet, the GUI user experience on KDE or GNOME blows in terms of responsiveness. (Don't get me wrong, I love Linux, but I have to wait several seconds for Galeon to pop up a new tab on my PII 300MHz. IE can open whole new windows as fast as I can push CTL-N!)
Slashdot Mirror
The main reason people try to keep it so that 12pt is the natural size is because all application developers are idiots and make it difficult to configure fonts properly. There are so many X apps that have bad font management it isn't even funny.
Consumer-grade video hardware has quickly outpaced SGI's best offerings. A GeForce3 has the same processing power as their best offerings from just two years ago, and doesn't cost as much as a new car.
>>>>>>>>>>
Yea, isn't it ironic that SGI now uses NVIDIA hardware in their low-end workstations?
What I don't get is the obsession with 1.0 release numbers. Is it a bad thing that a project has matured and can definately be considered more than a 1.0 release?
They pretty much are. For example, they constantly remind you (in less than polite ways) that GCC 2.96 is unsupported. Then, they discourage people from distributing binaries so people will be forced to compile it themselves.
Coupla points:
1) Actually, 3D meshes perfectly with absolute measurement systems, since 3D has never used pixels. OpenGL, for example, is enitrely based on abstract units.
2) I think Berlin does this.
Speaking of build tools, there is a really nifty one called CONS It does automatic dependecy management, interfaces to repositories, and is written in Perl! I messed around with makefiles for a long time before I found this, and it made a fairly messed up kernel tree a cinch to build.
Unfortunately, KDE has the small problem that everything takes days to load. Its far more polished than GTK+/GNOME, but damn is it slow. Funny thing. I was using Windows XP the other day at Circuit City. I was amazed how speedy it was. Considering how badly configured store-display machines are, this did not say much for KDE...
1) Attributes are the future. XFS has them, they must be okay!
2) HFS is oddball in terms of design. Instead of explicit inodes and directories and whatnot, all file records are bunched together in the catalog file. This was cool back in 1980, but today, it means that the filesystem has to be single threaded (giant subsystem mutexes are so passe) and concurrency blows. BFS, on the other hand, is rather standard. Its got explicit inodes, B+ trees for directories, and uses a bitmap to manage free blocks. Nothing oddball at all.
When will people learn that stupid names aren't cool! Besides, its like GNU/Linux. It'll never catch on!
Would you care to quantify that statement? I know that it's quite fashionable in this forum to parrot Linus Torvalds' blithe dismissal of Mach, but nobody ever seems interested in backing it up with any hard data.
>>>>>>>>
Read the GNU/HURD mailing lists about people wanting to switch HURD over to L4 because Mach just wasn't cutting it.
What an odd and incorrect statement. I don't really know where to begin. Do you really think that during the entire time that Mach was being used as the core of various incarnations of NeXTstep (on both 680x0 and ia32), MkLinux (on PPC, ia32 and PA-RISC) and MacOS X, not to mention countless other projects, that it was not "massaged" and updated significantly?
>>>>>>>
Tons of projects, yes. Huge leaps in capability? No. Take a look at all of the nifty stuff FreeBSD has been doing in the meantime. The VM subsystem has significantly overhauled (read Cranor's UVM paper and Matt Dillon's articles for info) as has the swap system and (with FreeBSD 5.x) the threading model and SMP system. Advances of that magnitude just haven't been made on Mach, plain and simple.
You dance with who brought you. OSX is based on NeXTstep, and NeXTstep was built on the Mach/BSD core. That codebase was stable, mature, and proven to be portable. They had, and have, no sane reason to rip it out.
>>>>>>>>>>
Umm, Apple ended up rewriting a lot of the upper-level software anyway. I would guess that porting to FreeBSD (given that both Mach/BSD and FreeBSD have the same API) wouldn't have cost very much time.
More mindless parroting of theparty line. Mach/BSD is in no way unstable, and stability is not the only benefit. Think "portability, modularity, features and elegance."
>>>>>>>>>>
1) Portability: Do you really think that Mach/BSD is more portable than any monolithic kernel, like Linux or NetBSD? Besides, Apple is the one who is making OS-X uniplatform!
2) Modularity: You call a monolithic system server moduler? Multi-servers are moduler. They're a great use of some of the inherent advantages of microkernels. Monoservers are just stupid.
3) Elegant: How? You take a basterdize the microkernel concept by sticking a monolithic system server on top of it!
So everyone keeps saying, but nobody seems willing to actually back up that assertion with anything other than vague handwaving.
>>>>>>>>>
Umm, just think this through. Say I want to read a byte from a device. Which is going to be faster, sending a message to the system server (which involves one system call to send the message, a slow context switch to change to the system server, code to process the message, another system call to send another message, and another context switch to change to the calling process), or invoking a single system call which involves no context switches?
As for porting, please remember that they ended up porting a good deal of FreeBSD 3.2 to Mach anyway.
If security has not improved why should I believe that stability has?
>>>>>>>>>
Because people who've actually used the thing can tell you that NT's based OSs have been very stable for years now. Win2K is stable just as NT4 was stable. Live with it. Get over it. Fix Linux.
Obviously, you've never seen good fonts. OSX fonts bite.
Not only are they all blurry, but the blur doesn't
even hide the crappy non-hinted font rendering!
If you want to see real quality fonts, check out
KDE2 (which uses FreeType2) or QNX Photon (which
uses BitStream's FontFusion). With good fonts, FT2
is as good as FontFusion, except maybe the AA, which
is of slightly lower, but still very good, quality.
Hey, I love BeOS as much as the next fanatic, but (as much as I would love to) I can't use it because its compiler is old and there is no support for the rear-channel on my SB Live!
The fact that BeOS wasn't open source is what ultimately killed yet. OSS code is hard to kill. Hell, HURD is still plodding along after all these years! (Put down the pitchforks, that was a joke!) BeOS was stagnated. Be didn't have the money to improve it (and yes, there are tons of things that could have been improved) and nobody had access to the source so they could. If it was open source, at least the OpenBeOS BlueOS guys could have put their efforts into improving BeOS, rather than replicating work that had been done long before. And the "OSS leads to fragmentation" idea is bullshit. Just take a look at FreeBSD! Even Linux (the kernel) is rather tightly unified, given the vast number of sources working on it (kernel devs, SGI, IBM, RedHat, Mandrake, etc).
1) HFS doesn't have true attributes. It has two forks.
2) HFS sucks. Its more advanced than FAT32, true, but Giampalo was right when he called HFS the "oddball cousin" of the filesystem world.
My machine has been all Linux for several months now. Its not as bad as I thought it was going to be, but its not great either. After tons customization (XFS, pre-kernels, preemptive + lock breaking patches, custom compilations, f**king with fonts for days on end, etc) Linux feels almost as fast as Win2K. Most of the time, anyway. All my Galeon windows still freeze up for several second at a time while one of them is loading /. (I miss multithreading), AbiWord still has butt-ugly non AA fonts, XMMS still sometimes skips when I'm doing multiple compiles at the same time, GTK+ apps still dump on me at totally random moments, Sylpheed won't copy and paste into gedit, and the GNOME file panal is still as braindead as ever. Its not all bad, however. Compiles run faster than they used to. Urpmi is truely nifty. Sylpheed is a good mail client, and XFS is an awesome filesystem. I finally have good compile tools (ICC), and I've found the power of 'vi' because I've been forced (thanks /etc!) to use it so much. Still, its not BeOS. This is depressing...
Gah. No. OSX has performance issues, yes, but they have zilch to do with Mach/BSD. That codebase is over 15 years old, and is quite mature and refined, thank you.
>>>>>
You miss an important distinction. OSX is based on old code. Mach was never very good as a microkernel to begin with, and it hasn't been heavily updated in years. FreeBSD on the other hand, is very mature, just like Mach, but has had the benifet of years of massaging in the intervening years. Apple really was out to lunch when it decided to use a Mach/BSD combo. First, it has no real benifets, since the monolithic system server eats any potential gains in stability. Worse, it loses performance for being based on a microkernel. What would have made much more sense for Apple would have been to base OS-X on top of FreeBSD. They would have gotten a much better core OS, the FreeBSD guys would have gotten access to nifty things like XML configuration, and Apple wouldn't have to be in the core OS business.
Basically, you have for each kernel version you have several -preX kernels. Once you get the thing stable, you rename the line to -rcX kernels. From here, you accept only bug-fixes. When the -rcX kernel gets really stable, you rename it to -final, without changing anything else.
Ah! Partially right! But sorry, no dice. The only cooperative multitasking that is done in Windows 9x is with 16 bit applications, since all 16-bit apps are run in the same virtual machine. All 32-bit apps are fully preemptively (userspace multitasked. As for memory protection, that's only partially true. Application memory is indeed protected from each other. However, there is a big 1GB region of shared memory that is unprotected. Apps that use this region and asking to hose the system. Also, some bits of kernel memory are unprotected because DOS apps need access to them.
As for NT, it is a fully preemptible kernel, both in userspace and kernel space. Like all preemptive kernels, of course, it is not preemptible when interrupts are disabled (since the clock interrupt can't happen). The main reason why NT has always been preemptive is because its always been SMP. The locking requirements on SMP are similar to to locking requirements for a preemptible kernel, so you can get both together for the price of one. Indeed, the preemptive patch for Linux is very small because it uses the existing SMP locking mechanism.
Because they have a sane versioning system and don't try to be all 'leet and artificially keep their version numbers down! What is it about OSS developers that makes them dispise version numbers above 1.0?
There are two things here. Preemptive in userspace, and preemptive in kernel space. Linux is preemptive in user space, meaning that when a process is running application code, it can be preempted. When it is running kernel code, however (ie. during a system call) the scheduler will not preempt the thread, even if a higher priority one becomes available. Essentially (on a single processor) the kernel code is cooperatively multitasked. Kernel code runs until schedule() is called to invoke the scheduler. Some kernel code paths are very long, which leads to long periods where the current process cannot be preempted, which kills latency.
Also, to expand on the original question, there are a couple objections to the patch: It has the potential total throughput, because more locking must be used since the kernel can be preempted at any time, not just at specified points. However, in practice, the effect on throughput seems to be negligible. It also increases complexity, due to additional locking, but most of the complexity is there anyway, in the form of the SMP locks.
You couldn't really use templates in KDE, since the virtual functions are essentially set up as a clean callback method. A draw callback, for example, isn't implemented as function pointer, but overriding a virtual Draw() method in a view object. The two techniques are so similar at the low lever, however (deference a pointer and call the function found there), it should be possible to make KDE's load performance no slower than GTK+ or Xt's.
I don't think its that bad of a problem. a.out had other issues that made people hate it (specifically, shared libraries were a bitch to build and the semantics of shared and dynamic libraries were different). The only problem with prelinking is that on x86 machines, you soon run out of that paltry 4GB address space. On my machine, /usr/lib, /lib, and /usr/local/lib add up to about 460MB. These images become bigger in RAM since the BSS (zero-initialized data) isn't present. On a larger system, you could easily blow the address space with all the libraries (think Microsoft apps!) With 64bit archs, this is a non-issue, however. The good thing about the scheme, however, is that you potentially don't need position independant code, since you could relocate the library once at install time and not have to touch it afterward.
First, it does have an X server port. Second, it has the app_server, which does essentially the same thing.
Honestly, KDE has few features that aren't present, for example, in WinXP. If Microsoft can make WinXP run as fast as Win2K (which is blazingly so), and decrease their already low app-startup times significantly, KDE must be doing something wrong. It's ironic, though. The Linux kernel blows away the Win2K kernel, especially in terms of process creation/switching times. XFree86 4.1 (with NVIDIA drivers anyway) is just as fast as the Win2K GDI. Yet, the GUI user experience on KDE or GNOME blows in terms of responsiveness. (Don't get me wrong, I love Linux, but I have to wait several seconds for Galeon to pop up a new tab on my PII 300MHz. IE can open whole new windows as fast as I can push CTL-N!)