You can be scalable without using SVG. Most theme engines aren't pixmaps, but C/C++ programs. Its easy to make those programs change the size of their rendered widgets. The real problem is that none of them bother trying to autodetect the user's resolution to scale its size.
Really? What kind of machine are you on? On my 2GHz P4, its right up there with XP (like that's saying much:), but then again, this is 3.2 CVS on a 2.6-test kernel...
What are you talking about? Greater pixel density is *always* better, as long as your UI can scale. The problem with OS X is that on a 1920x1200 15.2" screen, everything would be too small to see. If OS X made your widgets bigger at higher DPIs (like how fonts get bigger when you run at high DPIs) there would be no problem.
There is a major difference between scaleable vectors done in hardware via cairo graphics >>>>>>> There is no hardware that accelerates Cairo.
and software based hacks which I'm assuming you are talking about done via the CPU. >>>>>>> Software-rendered vector graphics aren't hacks. They have to potential to be slower, but often they aren't. If you're doing a minimal amount drawing (and most themes do), they can be faster because you don't have the setup overhead of making command buffers for the hardware. Read Rasterman's comments about the EVAS OpenGL back-end. Hardware accelerated SVG really comes in useful when you have a ton of stuff to render quickly. Most current apps aren't visually complex enough to require it. Simple widget themes will never be so complex as to require it, because the results would be unusable. Thus, HW SVG makes sense, but not for rendering the entire UI.
Maybe thats why KDE's so called vector based GUIs always break up when you move a window around too fast >>>>>>>>> Um, the theme doesn't do any redraw when you move a window around. Its a simple blit operation. If you mean that they break up when resizing, you're still wrong. The bottleneck is almost never the widget style, even in the simplest windows. The problem is usually a mix of Qt not double-buffering the widget (most are, some aren't) or more generally, a synchronization issue between the window manager and the application. Apps that don't have custom canvases (like KFind or Qt Designer) very rarely show any redraw issues. SVG (even hardware accelerated SVG) would do *nothing* to fix these issues, and these issues can be fixed without hardware accelerated SVG.
I've never seen vectors do this but hey you say its already SVG. >>>>>>> Okay, try to understand this. There are three seperate concepts at work here.
Scalable --- Something that can increase the number of pixels in its output image as resolution goes up.
Vector graphics --- Something that achieves scalability by specifying all drawing in terms of geometric elements.
SVG --- A specific file format for vector graphics.
KDE themes are not really vector-based, nor are they specified in SVG. But they are scalable because they are C++ plugins that have algorithms that can take, as parameters, the output size of the widget. The underlying drawing API that KDE themes use is QPainter, which is vector-based, but pixel oriented. The graphics primitives are vectors (draw line here, draw rectangle there) but the coordinates are in pixels.
Either QPainter needs to be done via cairographics so it can be fast and done via hardware >>>>>>>>> QPainter done in Cairo would be slower, since there is no hardware accelerated Cairo support.
or KDE needs to be ported to vectors >>>>>>>>>> You don't "port" to vectors. Please tell me that English isn't your first language...
either way the current system is too slow and not powerful enough >>>>>>>>> The existing system is fast enough and powerful enough for widget themes.
KDE cant even do alpha channel >>>>>>>> Do you understand graphics at all? Vector graphics are orthogonal to alpha blending. KDE doesn't do alpha blending for windows because X11 doesn't support it. KDE couldn't do alpha blending for windows even if it draw its wigets via Cairo. The concepts are *completely* unrelated.
so if its doing vectors right now its fake software vectors and not legit hardware vectors >>>>>>>> How are software vectors illegitimate? Is your web-browser illegitimate because it runs on your CPU and not your GPU? Are your TTF fonts illegitimate because they are (and probably always will be) rendered via your CPU?
Resolution you idiot. Why do you think fonts need to be anti alaised. >>>>>> WTF are you talking about? Fonts need to be anti-aliased because we have limited resolution. With *just* anti-aliasing, fonts still don't look good. You need complex hinting systems to make them look good. SVG doesn't have those.
Why should a theme creator have to create 30 different versions of their theme for different resolutions? >>>>>>>>> Learn to read. I said that Plastik's widgets were already scalable, its just that the sizes were hard-coded. Not like bitmap hard-coded, but simple constants in the code. They are just parameters for the rendering algorithm. I used a config file to set the parameters, but you could just as easily autodetect the user's resolution and set them accordingly. You could do all that without changing the underlying rendering model.
Resolutions are high enough, I dont know what resolution you are running in >>>>>>>> Can you *read*? I said I had a 133dpi screen. That implies a pretty fucking high resolution. 1600x1200 on a 15" display to be exact.
maybe you run in 800x600 or something, but my laptop goes well above that and currently on my laptop pixels look like shit compared to SVG. >>>>>>>> What does that mean? Pixels look like shit? Everything is a pixel anyway. You mean that scaling a bitmap up to twice its size looks like shit? If that's the case, how is that a response to what I said? KDE and GNOME themes (by and large) aren't bitmaps! My point was that even at 133dpi, an error of 1 pixel is easily visible in small features like button arrows. Even if you did a fully-SVG theme, you would still have to have some special case code to make sure that visual elements lined up properly.
In that sense, wouldn't SVG be capable of replacing TTF (TrueType Font) file format? >>>>>>>>> No. Fonts are very complex beasts. You can't get good on-screen output by just rendering the font outline. You just don't have enough pixels for that. The TTF and Postscript formats have hinting systems that are used by the renderer to optimize output for on-screen display. TTF's hinting format is actually a complete bytecode interpreter for a specialized language that subtly manipulates the glyph outline to make stuff look nice while working with a limited number of pixels. You could add this stuff to SVG, but there'd be no point. TTF already does it. Also, hardware acceleration for fonts would be of limited usefulness. Fonts have the nice property that you can render a few hundred glyphs to tiny bitmaps (the entire alphabet for a few common sizes) and keep them around in a cache. Then, when you need to draw a character, just alpha blend that glyph to the surface. Doesn't get much faster than that. Also, fonts use some very specialized anti-aliasing algorithms (read up on how Cleartype works) and modern HW doesn't accelerate that. And they probably never will, because the algorithms for font rendering keep being improved.
Every time there is an article on vector graphics UIs, a ton of Apple freaks come out of the woodworks and repeat Apple marketing drivel. I consider it my civic duty to set them straight. I have nothing against Apple (I like MacOS Classic's UI, and I love my iPod) but their marketing department needs to be lined up and executed.
Network byteorder has nothing to do with this. When yous end binary info over the net, it gets sent as-is. You can convert it if you want, but the network link doesn't just go and change the byteorder of anything going in or out. And it wouldn't work anyway if you got some images on a CD. The byteorder problem is usually just resolved by saying "the data is in little-endian byteorder, deal with it." Putting things in XML gets rid of that problem.
You don't seem to understand. We're talking about vector graphics. QE uses the CPU for *all* vector graphics. The GPU is only used for window effects. There is nothing in KSVG that would get accelerated by QE, except maybe bitmap compositing.
Vector graphics are almost always rendered via the CPU (even Quartz "Extreme"). There is an OpenGL accelerated renderers for SVG (SVGL), and a few custom 2D APIs on top of OpenGL (like EVAS). However, there isn't really anything production quality yet.
It makes it very easy to parse SVG. It also them easier to transmit to different computers with varying byteorders and whatnot. In practice, SVGs are compressed (gzip compression) so there is very little practical overhead for using an *unicode* format.
SIgh. Apple's UI apparently scales terribly. Its supposedly the reason why Apple is still shipping low-res laptop screens in this age of 1920x1200 15.2" LCDs. If you look closely, OS X is really full of bitmaps. Hell, its got more bitmaps than most KDE or GNOME UIs. The scrollbars in most KDE themes, for example, are rendered on the fly via Qt's Painter API, while in OS X, they are bitmaps.
Too bad you have no idea what you're talking about. OS X is hardly competiton for KDE.
a) SVG has nothing to do with text quality --- current fonts are scalable, but they are rendered by highly optimzed renderers like Freetype to apply font-specific hinting.
b) OS X doesn't use vectors. Most things (widgets, etc) are still bitmaps. The graphics system supports vector graphics (and some apps like Quicktime use them) but most of the eye-candy in OS X is just the result of good UI designers. Hell, it doesn't even use scalable icons --- it starts with large (128x128) bitmaps and uses pixel scaling.
c) OS X doesn't render vectors via hardware. If you look at the tech docs, Quartz 2D is all CPU. OpenGL is merely used for transparency and window-level effects like genie.
d) An all-SVG UI wouldn't necessarily be bad, it would just not be terribly useful. First, UIs are already pretty scalable. For example, I was looking through the code for the Plastik KDE theme the other day. Most of the drawing logic is completely scalable. I was able to rip out of a lot of the hard constants and make them read via a configuration file. You change a few constants, and suddenly scollbars and spinners are wider, *and* properly rendered. All the buttons and tabs are aleady scalable, because Qt is a font-sensitive UI, and changing font-sizes can drastically affect the size of widgets.
However, you still have to care about pixels. Resolutions are still not high enough where you can ignore them. Plastik (and other themes, presumably) still has special cases to handle small pixel shifts (think of a limited case of hinting). Even on my high res screen (133 dpi) a small shift of one pixel on a scrollbar is easily visible as a glitch.
Not could. Does. I'm running KDE CVS right now, which has support for SVG icons. In the CrystalSVG iconset, there is a "scalable" directory containing.svgz files, in addition to pre-rendered.png's.
After you've done the first compile, you don't have to recompile the kernel just to add loadable modules. Just do 'make menuconfig' and then a 'make modules && make modules_install." That will build just any modules that need building, without touching the kernel. In 2.6, its even easier. Just do "make && make install" and the build system will automatically recognize if only a new module needs to be built and just build that.
You'd be wrong. NT is riddled with design flaws. Its true that most of these were not originally there, but they got put there over time. Unlike NT and Darwin, the OSS kernels are actually cleaner today than they were years ago.
Some examples of NT's design flaws:
1) Too much of a dependence on heuristics over stable algorithms. The VM system is a good example of this. 2) Shizo wanabee microkernel. Tons of stuff (even the GDI) is in kernel mode, so there is no stability gain, but there is still the overhead of talking to a system server (crss.exe). 3) Too much stuff overall in the kernel. The GDI doesn't belong in the kernel, and there is talk of putting parts of the CLR and SQL into the kernel to support WinFS. 4) Too many hacks designed to get good interactivity. The priority boosting mechanism is an example of this.
The API for drivers should be static at least for the stable revision of the kernel. This would allow binary drivers to actually work properly. >>>>>>>>>>> Never going to happen. Linus has decided that technical quality takes priority. Also, the kernel developers don't have a dedicated driver compatibility team like Microsoft does, and trying to maintain binary compatibility would be too much trouble. Its easy for user-space programs, but drivers are (necessarily) too close for that. Don't worry, hardware developers will figure it out. NVIDIA seems to be doing fine with it, and if the Linux market is worth it to a company, they'll deal with it. Or better yet, open up hardware specs! I don't care how cool you think or NIC design is, there isn't anything there people haven't seen before...
Windows and MacOS seem to do it. >>>>>>>> Windows and MacOS also have terribly messy, kludgy kernels, burdened by decades of backwards compatibility. Even OS X is a schizo melange of old 4.4BSD, Mach, NetBSD, FreeBSD, and new Apple (the I/O kit) code. They are *not* what you point to in a discussion about kernel design.
I've been using an alternative OS as my main OS for almost three years. The last Windows version I seriously used as NT4. The article, although its made in jest, is absolutely true. Windows is not at all intuitive for somebody not familiar with it. I'm not saying that Linux is any more intuitive, but it does point out the very real fact that most of the kvetching that amateur reviews of Linux do are really based in familiarity with Windows. Let me give some examples:
1) The other day, I wanted to install the latest NVIDIA drivers for XP, so I could play Battlefield 1942. In Linux (Gentoo) its a 1-command, 3 second process. In Windows, I had to find the driver page, download to a directory, navigate to the diectory, click "Next" a dozen times, reboot, and then delete both the installer and temp directory when I was done. So painfully manual!
2) Roblimo's right. IE is a piece of junk. No popup-blocking built in (I hadn't noticed how unusable the Internet has become thanks to popups), no tabs (constant urge to press CTRL-T:) Also, the configure dialog is very confusing compared to Konqueror's.
3) Windows lacks consistency. In KDE, KWord looks like Konqueror, which looks like KDevelop, which looks like KMplayer. MS Office, Visual Studio, IE, and Media Player *all* look different. Also, configure panels are never in the same place. In KDE, they're always right under "Settings". In IE, they're under "Tools" of all places, and I couldn't for the life of me tell you where they are in Visual Studio (there are actually several in VS.NET) or MS Office (again, I think more than one). Outlook's UI, OTOH, is pretty well designed.
4) I can never find what I'm looking for. I want to configure a network share. So I go to control panel. Nothing in control panel about that. Apparently you have to right-click the folder you want to share. I want to clear my "recent documents" menu. Its in the taskbar's property panel! WTF?
This wouldn't work given how kernel development works. Sometimes, a core API will change, and all drivers will have to be updated. This happened recently with the taskqueue change in 2.5, and is happening again with the switch to the new driver API. It would be a royal pain to have drivers in seperate modules. Besides, nothing stops you from compiling drivers independently of your kernel. The NVIDIA and hfs+ drivers are compiled independently, for example.
Linux was on page 1 of the business section of the washington post a week or two ago. I've heard it mentioned on CNN several times. I've seen it in Newsweek a few times.
You're about half a decade out of date. PC refers to all personal computers. Also, there is no such thing as "IBM PCs" anymore. If you mean x86 machines, you say "x86 PC" or "Intel PC". If you mean a Apple machine, then you say "Apple PC".
Slashdot Mirror
You can be scalable without using SVG. Most theme engines aren't pixmaps, but C/C++ programs. Its easy to make those programs change the size of their rendered widgets. The real problem is that none of them bother trying to autodetect the user's resolution to scale its size.
Really? What kind of machine are you on? On my 2GHz P4, its right up there with XP (like that's saying much :), but then again, this is 3.2 CVS on a 2.6-test kernel...
What are you talking about? Greater pixel density is *always* better, as long as your UI can scale. The problem with OS X is that on a 1920x1200 15.2" screen, everything would be too small to see. If OS X made your widgets bigger at higher DPIs (like how fonts get bigger when you run at high DPIs) there would be no problem.
There is a major difference between scaleable vectors done in hardware via cairo graphics
>>>>>>>
There is no hardware that accelerates Cairo.
and software based hacks which I'm assuming you are talking about done via the CPU.
>>>>>>>
Software-rendered vector graphics aren't hacks. They have to potential to be slower, but often they aren't. If you're doing a minimal amount drawing (and most themes do), they can be faster because you don't have the setup overhead of making command buffers for the hardware. Read Rasterman's comments about the EVAS OpenGL back-end. Hardware accelerated SVG really comes in useful when you have a ton of stuff to render quickly. Most current apps aren't visually complex enough to require it. Simple widget themes will never be so complex as to require it, because the results would be unusable. Thus, HW SVG makes sense, but not for rendering the entire UI.
Maybe thats why KDE's so called vector based GUIs always break up when you move a window around too fast
>>>>>>>>>
Um, the theme doesn't do any redraw when you move a window around. Its a simple blit operation. If you mean that they break up when resizing, you're still wrong. The bottleneck is almost never the widget style, even in the simplest windows. The problem is usually a mix of Qt not double-buffering the widget (most are, some aren't) or more generally, a synchronization issue between the window manager and the application. Apps that don't have custom canvases (like KFind or Qt Designer) very rarely show any redraw issues. SVG (even hardware accelerated SVG) would do *nothing* to fix these issues, and these issues can be fixed without hardware accelerated SVG.
I've never seen vectors do this but hey you say its already SVG.
>>>>>>>
Okay, try to understand this. There are three seperate concepts at work here.
Scalable --- Something that can increase the number of pixels in its output image as resolution goes up.
Vector graphics --- Something that achieves scalability by specifying all drawing in terms of geometric elements.
SVG --- A specific file format for vector graphics.
KDE themes are not really vector-based, nor are they specified in SVG. But they are scalable because they are C++ plugins that have algorithms that can take, as parameters, the output size of the widget. The underlying drawing API that KDE themes use is QPainter, which is vector-based, but pixel oriented. The graphics primitives are vectors (draw line here, draw rectangle there) but the coordinates are in pixels.
Either QPainter needs to be done via cairographics so it can be fast and done via hardware
>>>>>>>>>
QPainter done in Cairo would be slower, since there is no hardware accelerated Cairo support.
or KDE needs to be ported to vectors
>>>>>>>>>>
You don't "port" to vectors. Please tell me that English isn't your first language...
either way the current system is too slow and not powerful enough
>>>>>>>>>
The existing system is fast enough and powerful enough for widget themes.
KDE cant even do alpha channel
>>>>>>>>
Do you understand graphics at all? Vector graphics are orthogonal to alpha blending. KDE doesn't do alpha blending for windows because X11 doesn't support it. KDE couldn't do alpha blending for windows even if it draw its wigets via Cairo. The concepts are *completely* unrelated.
so if its doing vectors right now its fake software vectors and not legit hardware vectors
>>>>>>>>
How are software vectors illegitimate? Is your web-browser illegitimate because it runs on your CPU and not your GPU? Are your TTF fonts illegitimate because they are (and probably always will be) rendered via your CPU?
Resolution you idiot. Why do you think fonts need to be anti alaised.
>>>>>>
WTF are you talking about? Fonts need to be anti-aliased because we have limited resolution. With *just* anti-aliasing, fonts still don't look good. You need complex hinting systems to make them look good. SVG doesn't have those.
Why should a theme creator have to create 30 different versions of their theme for different resolutions?
>>>>>>>>>
Learn to read. I said that Plastik's widgets were already scalable, its just that the sizes were hard-coded. Not like bitmap hard-coded, but simple constants in the code. They are just parameters for the rendering algorithm. I used a config file to set the parameters, but you could just as easily autodetect the user's resolution and set them accordingly. You could do all that without changing the underlying rendering model.
Resolutions are high enough, I dont know what resolution you are running in
>>>>>>>>
Can you *read*? I said I had a 133dpi screen. That implies a pretty fucking high resolution. 1600x1200 on a 15" display to be exact.
maybe you run in 800x600 or something, but my laptop goes well above that and currently on my laptop pixels look like shit compared to SVG.
>>>>>>>>
What does that mean? Pixels look like shit? Everything is a pixel anyway. You mean that scaling a bitmap up to twice its size looks like shit? If that's the case, how is that a response to what I said? KDE and GNOME themes (by and large) aren't bitmaps! My point was that even at 133dpi, an error of 1 pixel is easily visible in small features like button arrows. Even if you did a fully-SVG theme, you would still have to have some special case code to make sure that visual elements lined up properly.
In that sense, wouldn't SVG be capable of replacing TTF (TrueType Font) file format?
>>>>>>>>>
No. Fonts are very complex beasts. You can't get good on-screen output by just rendering the font outline. You just don't have enough pixels for that. The TTF and Postscript formats have hinting systems that are used by the renderer to optimize output for on-screen display. TTF's hinting format is actually a complete bytecode interpreter for a specialized language that subtly manipulates the glyph outline to make stuff look nice while working with a limited number of pixels. You could add this stuff to SVG, but there'd be no point. TTF already does it. Also, hardware acceleration for fonts would be of limited usefulness. Fonts have the nice property that you can render a few hundred glyphs to tiny bitmaps (the entire alphabet for a few common sizes) and keep them around in a cache. Then, when you need to draw a character, just alpha blend that glyph to the surface. Doesn't get much faster than that. Also, fonts use some very specialized anti-aliasing algorithms (read up on how Cleartype works) and modern HW doesn't accelerate that. And they probably never will, because the algorithms for font rendering keep being improved.
Every time there is an article on vector graphics UIs, a ton of Apple freaks come out of the woodworks and repeat Apple marketing drivel. I consider it my civic duty to set them straight. I have nothing against Apple (I like MacOS Classic's UI, and I love my iPod) but their marketing department needs to be lined up and executed.
Network byteorder has nothing to do with this. When yous end binary info over the net, it gets sent as-is. You can convert it if you want, but the network link doesn't just go and change the byteorder of anything going in or out. And it wouldn't work anyway if you got some images on a CD. The byteorder problem is usually just resolved by saying "the data is in little-endian byteorder, deal with it." Putting things in XML gets rid of that problem.
You don't seem to understand. We're talking about vector graphics. QE uses the CPU for *all* vector graphics. The GPU is only used for window effects. There is nothing in KSVG that would get accelerated by QE, except maybe bitmap compositing.
Vector graphics are almost always rendered via the CPU (even Quartz "Extreme"). There is an OpenGL accelerated renderers for SVG (SVGL), and a few custom 2D APIs on top of OpenGL (like EVAS). However, there isn't really anything production quality yet.
It makes it very easy to parse SVG. It also them easier to transmit to different computers with varying byteorders and whatnot. In practice, SVGs are compressed (gzip compression) so there is very little practical overhead for using an *unicode* format.
KSVG uses libart.
SIgh. Apple's UI apparently scales terribly. Its supposedly the reason why Apple is still shipping low-res laptop screens in this age of 1920x1200 15.2" LCDs. If you look closely, OS X is really full of bitmaps. Hell, its got more bitmaps than most KDE or GNOME UIs. The scrollbars in most KDE themes, for example, are rendered on the fly via Qt's Painter API, while in OS X, they are bitmaps.
Too bad you have no idea what you're talking about. OS X is hardly competiton for KDE.
a) SVG has nothing to do with text quality --- current fonts are scalable, but they are rendered by highly optimzed renderers like Freetype to apply font-specific hinting.
b) OS X doesn't use vectors. Most things (widgets, etc) are still bitmaps. The graphics system supports vector graphics (and some apps like Quicktime use them) but most of the eye-candy in OS X is just the result of good UI designers. Hell, it doesn't even use scalable icons --- it starts with large (128x128) bitmaps and uses pixel scaling.
c) OS X doesn't render vectors via hardware. If you look at the tech docs, Quartz 2D is all CPU. OpenGL is merely used for transparency and window-level effects like genie.
d) An all-SVG UI wouldn't necessarily be bad, it would just not be terribly useful. First, UIs are already pretty scalable. For example, I was looking through the code for the Plastik KDE theme the other day. Most of the drawing logic is completely scalable. I was able to rip out of a lot of the hard constants and make them read via a configuration file. You change a few constants, and suddenly scollbars and spinners are wider, *and* properly rendered. All the buttons and tabs are aleady scalable, because Qt is a font-sensitive UI, and changing font-sizes can drastically affect the size of widgets.
However, you still have to care about pixels. Resolutions are still not high enough where you can ignore them. Plastik (and other themes, presumably) still has special cases to handle small pixel shifts (think of a limited case of hinting). Even on my high res screen (133 dpi) a small shift of one pixel on a scrollbar is easily visible as a glitch.
Not could. Does. I'm running KDE CVS right now, which has support for SVG icons. In the CrystalSVG iconset, there is a "scalable" directory containing .svgz files, in addition to pre-rendered .png's.
After you've done the first compile, you don't have to recompile the kernel just to add loadable modules. Just do 'make menuconfig' and then a 'make modules && make modules_install." That will build just any modules that need building, without touching the kernel. In 2.6, its even easier. Just do "make && make install" and the build system will automatically recognize if only a new module needs to be built and just build that.
You'd be wrong. NT is riddled with design flaws. Its true that most of these were not originally there, but they got put there over time. Unlike NT and Darwin, the OSS kernels are actually cleaner today than they were years ago.
Some examples of NT's design flaws:
1) Too much of a dependence on heuristics over stable algorithms. The VM system is a good example of this.
2) Shizo wanabee microkernel. Tons of stuff (even the GDI) is in kernel mode, so there is no stability gain, but there is still the overhead of talking to a system server (crss.exe).
3) Too much stuff overall in the kernel. The GDI doesn't belong in the kernel, and there is talk of putting parts of the CLR and SQL into the kernel to support WinFS.
4) Too many hacks designed to get good interactivity. The priority boosting mechanism is an example of this.
The API for drivers should be static at least for the stable revision of the kernel. This would allow binary drivers to actually work properly.
>>>>>>>>>>>
Never going to happen. Linus has decided that technical quality takes priority. Also, the kernel developers don't have a dedicated driver compatibility team like Microsoft does, and trying to maintain binary compatibility would be too much trouble. Its easy for user-space programs, but drivers are (necessarily) too close for that. Don't worry, hardware developers will figure it out. NVIDIA seems to be doing fine with it, and if the Linux market is worth it to a company, they'll deal with it. Or better yet, open up hardware specs! I don't care how cool you think or NIC design is, there isn't anything there people haven't seen before...
Windows and MacOS seem to do it.
>>>>>>>>
Windows and MacOS also have terribly messy, kludgy kernels, burdened by decades of backwards compatibility. Even OS X is a schizo melange of old 4.4BSD, Mach, NetBSD, FreeBSD, and new Apple (the I/O kit) code. They are *not* what you point to in a discussion about kernel design.
I've been using an alternative OS as my main OS for almost three years. The last Windows version I seriously used as NT4. The article, although its made in jest, is absolutely true. Windows is not at all intuitive for somebody not familiar with it. I'm not saying that Linux is any more intuitive, but it does point out the very real fact that most of the kvetching that amateur reviews of Linux do are really based in familiarity with Windows. Let me give some examples:
:) Also, the configure dialog is very confusing compared to Konqueror's.
1) The other day, I wanted to install the latest NVIDIA drivers for XP, so I could play Battlefield 1942. In Linux (Gentoo) its a 1-command, 3 second process. In Windows, I had to find the driver page, download to a directory, navigate to the diectory, click "Next" a dozen times, reboot, and then delete both the installer and temp directory when I was done. So painfully manual!
2) Roblimo's right. IE is a piece of junk. No popup-blocking built in (I hadn't noticed how unusable the Internet has become thanks to popups), no tabs (constant urge to press CTRL-T
3) Windows lacks consistency. In KDE, KWord looks like Konqueror, which looks like KDevelop, which looks like KMplayer. MS Office, Visual Studio, IE, and Media Player *all* look different. Also, configure panels are never in the same place. In KDE, they're always right under "Settings". In IE, they're under "Tools" of all places, and I couldn't for the life of me tell you where they are in Visual Studio (there are actually several in VS.NET) or MS Office (again, I think more than one). Outlook's UI, OTOH, is pretty well designed.
4) I can never find what I'm looking for. I want to configure a network share. So I go to control panel. Nothing in control panel about that. Apparently you have to right-click the folder you want to share. I want to clear my "recent documents" menu. Its in the taskbar's property panel! WTF?
This wouldn't work given how kernel development works. Sometimes, a core API will change, and all drivers will have to be updated. This happened recently with the taskqueue change in 2.5, and is happening again with the switch to the new driver API. It would be a royal pain to have drivers in seperate modules. Besides, nothing stops you from compiling drivers independently of your kernel. The NVIDIA and hfs+ drivers are compiled independently, for example.
Linux was on page 1 of the business section of the washington post a week or two ago. I've heard it mentioned on CNN several times. I've seen it in Newsweek a few times.
Please tell me you're being sarcastic. Otherwise, you've just lowered my opinon of Slashdot users. Permenantly.
Betcha they do. Its kind of hard to miss if you ever read the newspaper.
You're about half a decade out of date. PC refers to all personal computers. Also, there is no such thing as "IBM PCs" anymore. If you mean x86 machines, you say "x86 PC" or "Intel PC". If you mean a Apple machine, then you say "Apple PC".
PC = Personal Computer