Indeed. I actually find the rc.d system much easier to use then the sysv-init thing. I tend to get confused by 6 directories with symlinks which have to be kept up to date instead of 1 configuration file.
And frankly, i never use the different runlevels like you're supposed to anyways. I only ever start or stop single services, and reboot the system. I don't start different sets of services.
KDE has a much better set of base libraries i'd say, but the KDE team often really doesn't look into usability.
E.g. konqueror has this feature called multiple view profiles, one for file management and one for browsing. Very nice, but i *really* would want to have a separate home URL for each profile.
I think if some companies would back up KDE, like they do with gnome, this might improve?
No shit this driver fails, it is supposed to support NVidia nforce2 chipset with AMD processors. Not the (also nvidia) network chip in the xbox. The ethernet chip is probably quite similar to the nforce chip, but the rest of the hardware isn't...
The best bet might be to port the linux forcedeth drivers. They're the only OSS drivers for the chip.
With the difference that you can usually steal software without getting cought if you think it's too expensive. I wonder wether cheaper software would lower copying and/or increase profit?
E.g. at euro 50,- would enough people buy office instead of copying that revenue would increase?
That just makes no sense mathematically. Why bother trying to make several minor things 10 times faster, just to gain 1% here and 1% there, when making one major thing even 2 times faster will gain you much more?
1% overall in 10 different places can still be 10%, but that's beside the argument here. I didn't say that you shouldn't do the other things, you should definitely optimize that big case too.
But i as a programmer tend to get the basic design right first; and when that works, i move on to fixing things that work on top of that. Then again, my half-finished projects aren't widely in use.:P
X cannot crash your system if it goes down. It can delete all your files, but like any userspace process, it cannot crash the kernel.
Sorry, but that isn't true. X runs at an elevated privilege to access IO ports etc. It can definitely crash your system. Guaranteed.
Hah! Have you ever written a graphics driver? Go read the DRI or Xgl mailing lists sometime. Mode setting alone is hundreds of kilobytes of code!
I haven't written written one, but i have modified some, since they *crashed* my system. And your number naming for the rest is kind of pointless, I didn't tell you to put a whole X in the kernel. That would indeed be kernel-bloat.
Anyways, i kind of through with this. I think you're exaggerating/misinterpreting some things, you think i am. We prolly both have some points of truth. Let's end it before it becomes a flamewar. Cheers!
And it's all completely overshadowed by the real bottleneck, drawing things on the graphics card!
This is a bullshit argument, i have quite a quick radeon card. You're not telling me that card can't draw a browser window fast enough. Though your argumentation sounds allright for the rest, this can't be correct.
Let's see. Your tradeoff is less than a 1% performance gain for putting a million lines of code into the kernel. Brilliant!
In your last post that was still 6%. Check your numbers. And you keep compare those 1000 cycles to some bigger number, probably the total number of cycles you CPU does each second. Stop that, compare it to the version without the context switch please! If such a change can optimize a call to draw some lines (a buffer full) from several thousand to several hunderd, that's a *huge* improvement. Several such improvements can add up quickly and will mage the whole of X feel less sluggish.
For the rest i never suggested putting a million lines of code in the kernel! BTW, what difference would it make anyways? XFree86 runs with elevated privileges already, and can crash your system anytime it wants to.
What i'd suggest is to put a simple graphics driver into the kernel, videomemory management and maybe some synchronisation between apps in there. In the worst case that are 5000 lines, plus some 10000 for each graphics driver. Apps could draw by themselves, and X and the windowmanager etc can combine each app's buffer onto the screen.
Yes, it's strictly faster. The question is, how much faster is it, and where is the bottleneck? A context switch is on the order of a few thousand cycles, while a system call is on the order of a few hundred cycles. Meanwhile, uploading a 100KB DMA buffer over the PCI-Express bus is on the order of 50,000 cycles. Even if you reduce the context-switch overhead to zero, you're still only improving performance by around 6%.
I think what you're forgetting is, during these 50,000 cycles your app doesn't have to wait. Last time i checked DMA'ing was done mainly independent of the CPU, so your app can keep doing things in the mean time. (at least during the bulk of the 50,000 cycles) Also it's not one context-switch but two: one to X and one from X. Now you see a different picture: a couple of hundred cycles vs several thousand cycles. (ignoring overhead for setting up a DMA transfer...) That's what i was trying to explain to you in the last post.
And your part about synchronization.. please don't tell me you want to add another context-switch to X, just to synchronize every now and then?! (ok, with rendering via X you're not adding one.. but you are in the case of apps using direct rendering) This is the kind of stuff why X needs to do many more things 'direct' via system calls. This synchronization can be implemented way more efficient with kernel primitives then with messages being sent back and forth.
"To execute a specific graphics operation driver will access the memory mapped
command to the card's acceleration engine.
is done entirely from user space."
^^ Quote from page 4 of the DirectFB architecture overview. Sounds to me like directfb does pretty much what i said. (Except even more direct, apparently:P)
"It's not necessarily the X people who object to kernel mode video drivers - it's the people who decide what goes into the kernel. While they make the driver run faster, it's at the expense of stability. When they put the graphics drivers into the NT4 kernel, it allowed user-level code to crash the OS by using invalid parameters to API calls. It took MS a while to get the bounds checking right. But this is off-topic, so I'll leave it here."
^^^ So winnt has graphics drivers in the kernel since nt4. Can't find another quote handy, but iirc since w2k graphics operations even go directly to this kernel driver, instead of via the win32 subsystem.
Of course you're right. I know that's what's really going on. But that doesn't make my argumentation less true: running things "directly" via system calls is a lot faster then going via X. Why do you think DRI/DRM is a lot faster than 'indirect' opengl?!
It becomes an issue as soon as your graphics card isn't the bottleneck in drawing things, but when context-switching to XFree86 draw things is. Any modern card card can draw triangles and lines so insanely fast that extra context-switching *will* slow it down.
If you don't beleive me, check the numerous articles about why w2k has this in the kernel (as opposed to winnt3.5/winnt4), why macosX now has quartx extreme 2d, why dri/drm is so much faster. Doing this avoids extra overhead, and on anything but an s3 trio32 or similar you'll notice the improvement.
As far as i understand it, EXA doesn't make Xlib calls go to the kernel instead of X. It is just a more efficient accelleration framework for X internally.
DRI/DRM makes going through XFree86 for each line, block or texture un-necessary. These functions become a systemcall, which reduces the number of (expensive) context switches by a half.
with all the good work on tranparancy, and nice effects, i'm still missing one big under-the-hood change: use something like DRM/DRI for all 2d graphics too! (similar to directfb, windows, maxosX, etc)
Currently there are hundreds of context-switches between the x-server and your applications just to draw things. Windows doens't have that (since w2k anyways) and it increased windows' graphics performance quite some bit. MacOS has quartz extreme 2d now, and it increased their performance. This really slows things down.:-(
I think before more fancy effects are added that only make the whole thing slower are added, these under-the-hood optimizations should be done!
This remark 'i386 sucks because there is little lowmem' is stupid... let them improve linux to need less lowmem. Why would you always want dentry and inode's in lowmem anyway; it think they could be swapped into highmem just a well. That will still be faster then not having them in mem...
using a 64bit arch is a workaround, a solution would be to fix their memory management. I you don't need huge user processes, just increase kernel address range to 3Gb, and userspace to 1Gb. No more problems with lowmem...
Funny thing is, it isn't purely their HyperTransport. It was developed togerther with Digital for their alpha CPU's. Way to go digital, like many other "modern" features the alpha chips had this baby first. Too bad they died.
you can also look at alpha systems (in this matter any "real workstation design") how to fix this, e.g. with memory interleaving. With 64 memory dimms supplying data to the CPU, it will be the memory running circles around your CPU.:-)
Same goes for IO, most cheap-ass computers are quite fast considering the CPU, but with crappy disks, a slow pci-bus, etc. Go S-ATA, go pci-e; maybe we'll have the possibility to build decent affordable PC's afterall somewhere in the near future.
Pentium 3 chips are quite a lot faster as pentium 4 chips at the same clockrate. An 1Ghz p3 was about as fast as an 1.4Ghz p4, iirc. Though that was the first model p4, they have optimized it a bit so it will be less in favor of the p3.
I wonder when people will ever get pragmatic, and just use the best tool for the job without having big discussions about (subjective) preference for some OS.
Please, base such discussions on facts, you know there is no way you can discuss subjective matters...
Though i admit heavy discussions about subjective things coupled with a few beers can be more fun;)
Then again, for a release that is basically minor enhancements like security patches, updates of contributed software, and more work on SMP/thread safe drivers and other kernel subsystems... what else can you say?
I think untill 6.0 (and possibly even of 6.0; since it's basically focussed on VFS scalability and not new features) you'll keep having such reviews. In the now stable 5.x series they won't roll out big new features.
There aren't big exciting reviews about every 2.6.x release of linux too, there simply isn't much to say.
I'll give you another reason not to use it: it lacks features i'd expect from an OS i feel compatible with.
The openbsd guys are for as i understand it mostly concerned with security and making a nice and integrated system. I feel their kernel work is lacking a little (no SMP until recently, no real threading, no unified buffer cache, etc)
Taking the previous paragraph to the extreme, why don't they make openbsd an improved distro of some other BSD replacing that BSD's userland with their own, since that is what they excel at.
(I know i'm skipping over important things like wireless networking support they worked very hard for)
As far as i know there is no way to restrict a driver from accessing hardware registers it shouldn't access. (some CPU's can.. but most OS's don't use the technique) So i think in case of an exploit the driver can still screw the whole system.
A device driver has unlimited access to software and hardware of the system. Applications with administrator rights still can't access hardware directly. (Though they can install a device driver to do that for them;) So a device driver virus could for example take over your network card, and do nasty stuff without your personal firewall noticing it.
And how will a that help? A device driver is still a device driver, and as such has (and often needs) full access to you computers hardware. So a flaw in one such user-mode driver can still make your whole system vulnerable.
Slashdot Mirror
Unfortunately it won't work the other way round: rebooting every night doesn't get you (different) girl every time ;)
Indeed. I actually find the rc.d system much easier to use then the sysv-init thing. I tend to get confused by 6 directories with symlinks which have to be kept up to date instead of 1 configuration file.
And frankly, i never use the different runlevels like you're supposed to anyways. I only ever start or stop single services, and reboot the system. I don't start different sets of services.
This whole article looks like one of them "BSD is dead!' trolls. Neat trick to post it on the slashdot main page! ;-)
KDE has a much better set of base libraries i'd say, but the KDE team often really doesn't look into usability.
E.g. konqueror has this feature called multiple view profiles, one for file management and one for browsing. Very nice, but i *really* would want to have a separate home URL for each profile.
I think if some companies would back up KDE, like they do with gnome, this might improve?
No shit this driver fails, it is supposed to support NVidia nforce2 chipset with AMD processors. Not the (also nvidia) network chip in the xbox. The ethernet chip is probably quite similar to the nforce chip, but the rest of the hardware isn't ...
The best bet might be to port the linux forcedeth drivers. They're the only OSS drivers for the chip.
With the difference that you can usually steal software without getting cought if you think it's too expensive. I wonder wether cheaper software would lower copying and/or increase profit?
E.g. at euro 50,- would enough people buy office instead of copying that revenue would increase?
That just makes no sense mathematically. Why bother trying to make several minor things 10 times faster, just to gain 1% here and 1% there, when making one major thing even 2 times faster will gain you much more?
1% overall in 10 different places can still be 10%, but that's beside the argument here. I didn't say that you shouldn't do the other things, you should definitely optimize that big case too.
But i as a programmer tend to get the basic design right first; and when that works, i move on to fixing things that work on top of that. Then again, my half-finished projects aren't widely in use. :P
X cannot crash your system if it goes down. It can delete all your files, but like any userspace process, it cannot crash the kernel.
Sorry, but that isn't true. X runs at an elevated privilege to access IO ports etc. It can definitely crash your system. Guaranteed.
Hah! Have you ever written a graphics driver? Go read the DRI or Xgl mailing lists sometime. Mode setting alone is hundreds of kilobytes of code!
I haven't written written one, but i have modified some, since they *crashed* my system. And your number naming for the rest is kind of pointless, I didn't tell you to put a whole X in the kernel. That would indeed be kernel-bloat.
Anyways, i kind of through with this. I think you're exaggerating/misinterpreting some things, you think i am. We prolly both have some points of truth. Let's end it before it becomes a flamewar. Cheers!
And it's all completely overshadowed by the real bottleneck, drawing things on the graphics card!
This is a bullshit argument, i have quite a quick radeon card. You're not telling me that card can't draw a browser window fast enough. Though your argumentation sounds allright for the rest, this can't be correct.
Let's see. Your tradeoff is less than a 1% performance gain for putting a million lines of code into the kernel. Brilliant!
In your last post that was still 6%. Check your numbers. And you keep compare those 1000 cycles to some bigger number, probably the total number of cycles you CPU does each second. Stop that, compare it to the version without the context switch please! If such a change can optimize a call to draw some lines (a buffer full) from several thousand to several hunderd, that's a *huge* improvement. Several such improvements can add up quickly and will mage the whole of X feel less sluggish.
For the rest i never suggested putting a million lines of code in the kernel! BTW, what difference would it make anyways? XFree86 runs with elevated privileges already, and can crash your system anytime it wants to.
What i'd suggest is to put a simple graphics driver into the kernel, videomemory management and maybe some synchronisation between apps in there. In the worst case that are 5000 lines, plus some 10000 for each graphics driver. Apps could draw by themselves, and X and the windowmanager etc can combine each app's buffer onto the screen.
Yes, it's strictly faster. The question is, how much faster is it, and where is the bottleneck? A context switch is on the order of a few thousand cycles, while a system call is on the order of a few hundred cycles. Meanwhile, uploading a 100KB DMA buffer over the PCI-Express bus is on the order of 50,000 cycles. Even if you reduce the context-switch overhead to zero, you're still only improving performance by around 6%.
I think what you're forgetting is, during these 50,000 cycles your app doesn't have to wait. Last time i checked DMA'ing was done mainly independent of the CPU, so your app can keep doing things in the mean time. (at least during the bulk of the 50,000 cycles) Also it's not one context-switch but two: one to X and one from X. Now you see a different picture: a couple of hundred cycles vs several thousand cycles. (ignoring overhead for setting up a DMA transfer ...) That's what i was trying to explain to you in the last post.
And your part about synchronization .. please don't tell me you want to add another context-switch to X, just to synchronize every now and then?! (ok, with rendering via X you're not adding one .. but you are in the case of apps using direct rendering) This is the kind of stuff why X needs to do many more things 'direct' via system calls. This synchronization can be implemented way more efficient with kernel primitives then with messages being sent back and forth.
^^ Quote from page 4 of the DirectFB architecture overview. Sounds to me like directfb does pretty much what i said. (Except even more direct, apparently :P)
^^^ So winnt has graphics drivers in the kernel since nt4. Can't find another quote handy, but iirc since w2k graphics operations even go directly to this kernel driver, instead of via the win32 subsystem.
Of course you're right. I know that's what's really going on. But that doesn't make my argumentation less true: running things "directly" via system calls is a lot faster then going via X. Why do you think DRI/DRM is a lot faster than 'indirect' opengl?!
It becomes an issue as soon as your graphics card isn't the bottleneck in drawing things, but when context-switching to XFree86 draw things is. Any modern card card can draw triangles and lines so insanely fast that extra context-switching *will* slow it down.
If you don't beleive me, check the numerous articles about why w2k has this in the kernel (as opposed to winnt3.5/winnt4), why macosX now has quartx extreme 2d, why dri/drm is so much faster. Doing this avoids extra overhead, and on anything but an s3 trio32 or similar you'll notice the improvement.
As far as i understand it, EXA doesn't make Xlib calls go to the kernel instead of X. It is just a more efficient accelleration framework for X internally.
DRI/DRM makes going through XFree86 for each line, block or texture un-necessary. These functions become a systemcall, which reduces the number of (expensive) context switches by a half.
with all the good work on tranparancy, and nice effects, i'm still missing one big under-the-hood change: use something like DRM/DRI for all 2d graphics too! (similar to directfb, windows, maxosX, etc)
Currently there are hundreds of context-switches between the x-server and your applications just to draw things. Windows doens't have that (since w2k anyways) and it increased windows' graphics performance quite some bit. MacOS has quartz extreme 2d now, and it increased their performance. This really slows things down. :-(
I think before more fancy effects are added that only make the whole thing slower are added, these under-the-hood optimizations should be done!
This remark 'i386 sucks because there is little lowmem' is stupid ... let them improve linux to need less lowmem. Why would you always want dentry and inode's in lowmem anyway; it think they could be swapped into highmem just a well. That will still be faster then not having them in mem...
using a 64bit arch is a workaround, a solution would be to fix their memory management. I you don't need huge user processes, just increase kernel address range to 3Gb, and userspace to 1Gb. No more problems with lowmem ...
But now it's a "social commandline", so it'll probably greet you on opening it, and say goodbye when you leave. ;)
Let the military handle that. They have nice tanks that can blow any infrastructure you tell them to.
Funny thing is, it isn't purely their HyperTransport. It was developed togerther with Digital for their alpha CPU's. Way to go digital, like many other "modern" features the alpha chips had this baby first. Too bad they died.
you can also look at alpha systems (in this matter any "real workstation design") how to fix this, e.g. with memory interleaving. With 64 memory dimms supplying data to the CPU, it will be the memory running circles around your CPU. :-)
Same goes for IO, most cheap-ass computers are quite fast considering the CPU, but with crappy disks, a slow pci-bus, etc. Go S-ATA, go pci-e; maybe we'll have the possibility to build decent affordable PC's afterall somewhere in the near future.
Pentium 3 chips are quite a lot faster as pentium 4 chips at the same clockrate. An 1Ghz p3 was about as fast as an 1.4Ghz p4, iirc. Though that was the first model p4, they have optimized it a bit so it will be less in favor of the p3.
I wonder when people will ever get pragmatic, and just use the best tool for the job without having big discussions about (subjective) preference for some OS.
Please, base such discussions on facts, you know there is no way you can discuss subjective matters...
Though i admit heavy discussions about subjective things coupled with a few beers can be more fun ;)
Then again, for a release that is basically minor enhancements like security patches, updates of contributed software, and more work on SMP/thread safe drivers and other kernel subsystems ... what else can you say?
I think untill 6.0 (and possibly even of 6.0; since it's basically focussed on VFS scalability and not new features) you'll keep having such reviews. In the now stable 5.x series they won't roll out big new features.
There aren't big exciting reviews about every 2.6.x release of linux too, there simply isn't much to say.
I'll give you another reason not to use it: it lacks features i'd expect from an OS i feel compatible with.
The openbsd guys are for as i understand it mostly concerned with security and making a nice and integrated system. I feel their kernel work is lacking a little (no SMP until recently, no real threading, no unified buffer cache, etc)
Taking the previous paragraph to the extreme, why don't they make openbsd an improved distro of some other BSD replacing that BSD's userland with their own, since that is what they excel at.
(I know i'm skipping over important things like wireless networking support they worked very hard for)As far as i know there is no way to restrict a driver from accessing hardware registers it shouldn't access. (some CPU's can .. but most OS's don't use the technique) So i think in case of an exploit the driver can still screw the whole system.
A device driver has unlimited access to software and hardware of the system. Applications with administrator rights still can't access hardware directly. (Though they can install a device driver to do that for them ;) So a device driver virus could for example take over your network card, and do nasty stuff without your personal firewall noticing it.
And how will a that help? A device driver is still a device driver, and as such has (and often needs) full access to you computers hardware. So a flaw in one such user-mode driver can still make your whole system vulnerable.
"Free linux 2.6 software update, we're updating your copy of windows now!"