My point was that you can't outright say "why is Intel doing such a dumb thing?" (Which the original poster did). Intel is not a stupid company (like MS). They have been very sucessful, not based only on their monopoly status (AMD has been making significant inroads into their turf) but because of the quality of their products. Within the constraints of the x86 architecture, Intel's chips have been incredible. Even now, the P4 looks really promising in its 2GHz+ varients. You just can't discount such a company so easily.
KDE-2. That and GNOME 1.4 are the only fair comparison to Win2K. I can't really tell the difference between BlackBox and Windows 2000, I'm guessing Win 3.1 (which BlackBox is technologically equivilent to) would be faster. Either way, I have to use either Konqueror or Galeon, and its unnaceptable to me to have my apps all look different.
Re:Pentium 4 Multithreading?
on
Itanium Update
·
· Score: 2
No, its just that the technology probably isn't mature enough to release. Its different from the 486SX, which is closer to the whole Celeron thing.
Yea, they are. As I remember it, 128 general purpose integer and 128 general purpose fp. Download the Intel C++ docs for some info about the ASM-viewpoint architecture of the Itanium.
My only question is for the OS guys out there. How does an OS handle context switches with 328 registers? With 8 bytes per register, thats more than 2K of data to dump out every context switch!
Intel has a lot of smart people working for it (smarter than either you or I). They have done some dumb things, but overall they've been on the mark a surprising number of times (even the P4 looks pretty impressive now that clock-speeds have ramped up). It would be a serious mistake to underestimate them like that. If Intel is putting this product on the market, you can bet that they've fixed the compiler problem. Initial benchmarks of the Itanium seem to show that it can keep right up there with the Alphas and SPARCs in terms for performance (fp, at least).
As for compilers, don't discount Intel so easily. They make incredible compilers. The features of ICL for x86 make compiler designers cream their pants. Read this article for some info about Itanium's compiler design.
Been doing that since Slack 3.5. Doesn't help a bit. Also, its not just X, but Linux GUI applications in general. Windows developers, in my experience, go to a lot more trouble to make sure that their GUIs perform better. IE, for example, resizes very smoothly, while Konqueror rubber-bands like hell. You just see a whole lot more flicker in Linux programs.
PS> Hmm, office machines are notorious about being badly configured. Also, what WM are you running? Its not really fair to compare Win2K to something like BlackBox after all.
Not really. Win2K has an ass-load of features, but it runs great on my PII-300/w 256MB of RAM. I think its just that MS is willing to make some concessions in idealized architecture for the sake of performance. COM, for example, isn't as well suited as CORBA for remote interfacing. That's why DCOM was hacked in. However, most uses of objects is local, so COM makes a lot more sense. GNOME CORBA architecture might be more "pure" but MS's performs better for 99% of people's uses.
needs work, gobe and hancom office's is supposed to be very good
>>>>
Gobe's isn't that great, at least in 2.0. Maybe they've improved it since then.
kparts
>>>>
Would be so kind as to point me to where I can embed my gnome apps into KDE without ugly hacks? How about my Athena apps? My FLTK apps? You see, Windows has only Win32 apps (stuff like MFC and OWL just wraps over Win32), so all this stuff is supported automagically.
what is not proper about it now?
>>>>>
First, half of the advanced desktop apps (GNOME apps) don't seem to support AA. Then there is the fact that it uses a seperate API, which means that many older, but still very usefull apps (XPlayMidi!) may never get AA support. Lastly, font handling could be more unified between the DEs, and a proper GUI interface to XftConfig could be made.
just use all kde apps. kde is quite integrated. hopefully gnome2 will also be.
>>>>>>>>>
What about GIMP? But if you use GNOME, then what about KDevelop? That's just a plain STUPID idea.
windows is faster than Linux? Uhh.
>>>>>
Yea. On the desktop, the Windows GUI is a lot more responsive. Sure its due to ugly hacks in the scheduler (giving apps priority boosts for display) and VM (giving the front-most app first dibs on RAM), but it *works* Maybe Win2K processes SETI packets slower than Linux, but peak throughput isn't the biggest priority for desktop OSs.
not sure what to make of this:
>>>>>>>
I think he means that the platform should have standards. Like a standardized way to display text, standardized way to access components, standardized way to use widgets, etc. Note, however, that this needn't unncessarily curtail freedom. All that is needed is standard interfaces, not standard implementations. X had the right idea of how to do this. ICCM allows any window manager to work with any X application. Why the KDE and GNOME guys ditched this paradigm is beyond explanation...
Honestly, people are able to use command lines. Ten years ago, Windows wasn't common at all. Yet, businesses all over the country used DOS programs without any problems. These weren't technologically elite people, they were just business users who have been doing the same word-processing tasks for the last century. They shifted from doing it by hand, to typewriter, to primitive PC machines, to primitive GUIs, all the way to Office XP. People haven't gotten dumber since then, the software industry's perception of them has.
Ugly text in X? I've tried KDE 2.2, both with and without anti-aliased fonts, and I can't tell the difference. To me, X looks no better with anti-aliasing. Or are you going to blame my monitor resolution (1280x1024x32 on a 17", a typical user's setup) or my eyesight (20/17, better than normal), or are you just going to attack my lack of aesthetic sensiblities?
>>>>>>>>>>
Actually, eyesight has nothing to do with it. My eyes are pretty bad, and I really can tell the difference between MS's good fonts and QNX's even better ones. Its a subjective thing. Many people with perfect hearing can't tell the difference between crappy speakers and good speakers. Same thing with monitors. Some people are just more sensetive to these details than others.
Well, just because it's okay for you don't mean its okay for everyone. Some people are just more sensitive to things than others. I think that AA fonts (good implementations, at least) look noticibly better than non-AA ones.
For a great implementation of AA fonts, check out QNX's RtP. The Font Fusion powered Photon has the most god-damn gorgeous fonts in the entire universe. Download RtP just to take an eyeful of the fonts!
I suggest you to take a few readings on qnx.com about realtime OS and you'll know what does it take to make a realtime OS.
>>>>>
I think you missed my point. I never said anything about QNX in the embedded space, I was talking about RtP in desktop space. According to QNX's docs, RtP is competing in desktop space. In that space, speed is more important than determinism. Maybe QNX doesn't want to fork the OS or change its deterministic policies, but then they shouldn't be competing in desktop space!
PS> Yes, all modern FSs should have journeling. Its not the fsck that matters, but the fact that in order to achieve good consistancy, it must use synchronus writes to the disk for metadata. That why the old BSD's without softupdates were so slow for compiling and untarring (very metadata intensive uses) and which is why QNX is slow for the same tasks.
PS2> QNX RtP really isn't used in nuclear reactors. QNX4 is used for those tasks. So far, the only thing QNX RtP (or QNX6 in general) has been used for embedded devices, which don't have the same life-or-death requirements of determinism that do nuclear reactors.
Anemic VM and filesystem? The VM and filesystem are fine - it'd be good if you gave a real example of how they were bad (the one below dosent count as I nip it in the bud...).
>>>>>>>>>
How 'bout these?
1) The filesystem is as slow as molasses. Untarring an archieve takes twice as long as on Linux. Throughputs above 10MB/sec (on my 7200RPM drive that gets 27MB/sec in Linux) are hard to come by. Apparently, something in libc has been fixed with 6.1, but the underlying FS problems are there. Also, no journeling, no softupdates, no features of any kind.
2) The VM cannot keep an mmap()'ed file in sync with with the disk if you use read/write to modify the file. That tells a lot about the deficiecies of the underlying implementation.
3) The VM and buffer-cache are not integrated. This was a big fault of BeOS's, and really hurt its I/O performance. BeOS and QNX are apparently the last big OSs without a unified buffer-cache/VM.
As for "nipping" the swap problem, you haven't. You still have to call munlockall(). So you either have to modify program source, or (if you have binary programs that don't call it) just live with it. Also, it was apparently put in just to support GCC, so I wouldn't be too sure that the underlying impelementation is very good.
I thought that I saw somewhere that QSSL was making parts of QNX open source? Anybody hear anything about that? An Photon Linux port would really rock. Photon has tons of features, is really small and fast, and the fonts and UI graphics look orgasmically good. QNX's kernel is nice for embedded systems, but on the desktop (which RtP tries to support) it is kinda flaky due to an anemic VM and filesystem. For example, it doesn't support paging directly, an app has to be coded with it in mind. Great for RT, but for GCC.
Actually, as far as I can find, the only thing that has been fixed is that the old libc (which wrote a few bytes at a time) has been replaced by a new one from Dinkumware. Nothing drastic, though.
When are they going to fix the QNX filesystem? It runs real bad on every machine I've tried it on (and it is #1 on the qnxstart.com wishlist). Eventually, people are going to put those cool IBM microdrives on their PDAs and start noticing the deficiencies of the filesystem. They have Dominic Giampalo (of BFS fame) working for them, so what's he doing?
A) First, all the gee-wiz features in MacOS-X and the new Linux WMs (except EVAS) are software accelerated. THAT'S slow.
No. KDE `gee whiz' (which I read as: usability - I like to be albe to read letters on screen - YMMV) done in XRender, which is hardware accelerated in almost every instance. GNOME 2.0 will also do a whole bunch of cute XRender stuff.
>>>>>>>>>
However, many more apps have accelerated OpenGL drivers than XRender drivers.
EVAS is something two people will use precisely because it uses a nonstandard method of rendering graphics that sends crap down the wire
>>>>>>>>>>
Sorry to break this to ya, but XRender is the non-standard method. OpenGL is a much more established (and supported!) standard, plus it does a lot more than XRender.
They don't, and that's the point. The standard excuse when it's pointed out Berlin gives app developers fewer options seems to be that those options are being given to the users instead, in the form of themes. But themes don't cut it.
>>>>>>>>
Entirely true. However, nobody said that themes were the only thing. There is configurability too. With the combination of the two, you get a good deal of power for the user. Also, nobody says that the toolkit must be the same in every case. Since Berlin is interfaced through Corba, it is entirely plausible that somebody would rip out the standard toolkit and implement a different one in its place. All app would still work, since the CORBA interface would remain unchanged.
They don't offer the same sorts of flexibility that the developer needs to create the right interface for a particular application. Sure, many (most?) developers abuse that responsibility instead of using it responsibly, but - as I said - you can't deny them that flexibility without a downside.
>>>>>>>
Are you honestly deluded enough to believe that application developers can USE all that flexibility? If that was true, Linux would be full of incredible great desktop applications. Its not. The problem with your thinking is that you want to give all the power to the developers, assuming that they somehow know more than the users. Besides, if a particular interface really is RIGHT for a particular application, nothing prevents that developer from implementing it himself. As long as you can still do raw drawing and get raw access to the interface devices, you can make whatever type of interface you want. True, that makes it harder for a developer to make a custom interface, but that's probably a good thing. If the app really needs that interface, then they'll go the extra mile to implement it. If it really doesn't, there is no point in breaking the standardization, now is there?
When did "people can't handle flexibility, we should abandon flexibility in favor of conformity" become the mantra around here?
>>>>>>>>
Its called society. Look outside the window. Conformity allows the world to run smoothly. I'm not saying that you should always conform, but you'd better have a good reason not to.
That's Windows thinking. It's totally opposite to the philosophy that underlies UNIX in general or Linux in particular.
>>>>>>>>>>
BS. UNIX is EXTREMELY standardized. Take the whole text-stream paradigm. It allows all apps to work together, no matter what they do. You think UNIX's CLI would have achieved the same level of usefulness if every developer had decided to use a different "but, it fits my app better!" method of exchanging text data?
Do you think all of your favorite X-window-manager toys - transparent and oddly-shaped title bars, dockable apps, virtual desktops just the way you like them - are going to survive a transition to Berlin?
>>>>>>>>
Yes, as long as the grognards want them, they'll get ported. However, many people DON'T like transparent, oddly-shaped title bars. Many people LIKE coherence and conformity. With Berlin, the rest of us aren't forced to pay for your weird sense of asthetics.
Think again. Because developers no longer have such flexibility, the environment you'd get with Berlin will be oh so spartan and sterile. But at least it'll be consistent, so I guess it's OK, right? Have you all tired of freedom so soon?
>>>>>>>>
Yes, that's why Windows apps have NO personality and inefficient interfaces. 3D Studio, Fireworks, Dreamweaver, Poser, Truespace, and Bryce are really just figments of my imaginiation and don't really exist.
Huh? How do themes relate to this? Themes are usually on the users end, so how do they relate to developers? I heard the word "flexibility." I don't like the word "flexibility." It usually means that some developer wants to mess with my desktop...
Cuz they are faster and cheaper and (until recently) had much better graphics HW. And much better standard sound cards. And an actual choice of speakers. And Sony monitors, gotta love those Sony monitors...
I think what he means is this. You take a Pinto, polt a Farrari engine, a BMW suspension, and a nice after-market Honda exhaust, its will still be a Pinto. On the other hand, if a car is designed with these performance components in mind, it will be a better car.
Extensions really aren't as cool as they're made out to be.
A) They aren't uniform. Say you add an extension for a high-speed way to access the display. All your old apps use the old (slow) method, and only a few new apps use the new, fast method. That sucks.
B) They duplicate functionality. In the above example, you now have 2 methods of accessing the display, when only one is needed. That sucks.
X has a perfect example right now. You have a standard font renderer, and you have a nice AA render extension. Not only do you now have to change the code in all your apps to use the new extension (or more likely, just live with un-AA text in some apps), but you have two sets of APIs that do the exact same thing! Its like Windows and its CreateWindow, CreateWindowEx, and CreateWindow16ThunkHack API.
Actually, "innovation" is a dangerous tool. You don't give it to monkeys. Blender has very specialized needs, and people are willing to spend some time learning it if the new UI is vastly more efficient than the standard. A spreadsheet, however, doesn't really benifet much by having a different UI, and its a much bigger help for the user if the UI of the spreadsheet matches the UI of the word processor. My point is that sometimes a different interface really is needed, and that can be implemented with a little work. Often times, however, a different interface is just put in because the developer thought it looked cool, and in those cases, the additional work required to implement non-standard interfaces will probably keep the developer from doing so.
Slashdot Mirror
My point was that you can't outright say "why is Intel doing such a dumb thing?" (Which the original poster did). Intel is not a stupid company (like MS). They have been very sucessful, not based only on their monopoly status (AMD has been making significant inroads into their turf) but because of the quality of their products. Within the constraints of the x86 architecture, Intel's chips have been incredible. Even now, the P4 looks really promising in its 2GHz+ varients. You just can't discount such a company so easily.
KDE-2. That and GNOME 1.4 are the only fair comparison to Win2K. I can't really tell the difference between BlackBox and Windows 2000, I'm guessing Win 3.1 (which BlackBox is technologically equivilent to) would be faster. Either way, I have to use either Konqueror or Galeon, and its unnaceptable to me to have my apps all look different.
No, its just that the technology probably isn't mature enough to release. Its different from the 486SX, which is closer to the whole Celeron thing.
Yea, they are. As I remember it, 128 general purpose integer and 128 general purpose fp. Download the Intel C++ docs for some info about the ASM-viewpoint architecture of the Itanium.
My only question is for the OS guys out there. How does an OS handle context switches with 328 registers? With 8 bytes per register, thats more than 2K of data to dump out every context switch!
Intel has a lot of smart people working for it (smarter than either you or I). They have done some dumb things, but overall they've been on the mark a surprising number of times (even the P4 looks pretty impressive now that clock-speeds have ramped up). It would be a serious mistake to underestimate them like that. If Intel is putting this product on the market, you can bet that they've fixed the compiler problem. Initial benchmarks of the Itanium seem to show that it can keep right up there with the Alphas and SPARCs in terms for performance (fp, at least).
As for compilers, don't discount Intel so easily. They make incredible compilers. The features of ICL for x86 make compiler designers cream their pants. Read this article for some info about Itanium's compiler design.
Well, your opinion about QNX's fonts are irrelevant, as we have already established that you are font-blind...
As for QNX, X can't hold a candle to Photon. Photon is smaller, faster, looks better, is easier to program, and has more features!
Been doing that since Slack 3.5. Doesn't help a bit. Also, its not just X, but Linux GUI applications in general. Windows developers, in my experience, go to a lot more trouble to make sure that their GUIs perform better. IE, for example, resizes very smoothly, while Konqueror rubber-bands like hell. You just see a whole lot more flicker in Linux programs.
PS> Hmm, office machines are notorious about being badly configured. Also, what WM are you running? Its not really fair to compare Win2K to something like BlackBox after all.
Not really. Win2K has an ass-load of features, but it runs great on my PII-300 /w 256MB of RAM. I think its just that MS is willing to make some concessions in idealized architecture for the sake of performance. COM, for example, isn't as well suited as CORBA for remote interfacing. That's why DCOM was hacked in. However, most uses of objects is local, so COM makes a lot more sense. GNOME CORBA architecture might be more "pure" but MS's performs better for 99% of people's uses.
needs work, gobe and hancom office's is supposed to be very good
>>>>
Gobe's isn't that great, at least in 2.0. Maybe they've improved it since then.
kparts
>>>>
Would be so kind as to point me to where I can embed my gnome apps into KDE without ugly hacks? How about my Athena apps? My FLTK apps? You see, Windows has only Win32 apps (stuff like MFC and OWL just wraps over Win32), so all this stuff is supported automagically.
openoffice, koffice, staroffice, hancomoffice, gobe
>>>>>
OpenOffice: Unreleased.
KOffice: Unfinished.
StarOffice: Slow (5.2) Unreleased (6.0)
Gobe: Unfeatured.
what is not proper about it now?
>>>>>
First, half of the advanced desktop apps (GNOME apps) don't seem to support AA. Then there is the fact that it uses a seperate API, which means that many older, but still very usefull apps (XPlayMidi!) may never get AA support. Lastly, font handling could be more unified between the DEs, and a proper GUI interface to XftConfig could be made.
just use all kde apps. kde is quite integrated. hopefully gnome2 will also be.
>>>>>>>>>
What about GIMP? But if you use GNOME, then what about KDevelop? That's just a plain STUPID idea.
windows is faster than Linux? Uhh.
>>>>>
Yea. On the desktop, the Windows GUI is a lot more responsive. Sure its due to ugly hacks in the scheduler (giving apps priority boosts for display) and VM (giving the front-most app first dibs on RAM), but it *works* Maybe Win2K processes SETI packets slower than Linux, but peak throughput isn't the biggest priority for desktop OSs.
not sure what to make of this:
>>>>>>>
I think he means that the platform should have standards. Like a standardized way to display text, standardized way to access components, standardized way to use widgets, etc. Note, however, that this needn't unncessarily curtail freedom. All that is needed is standard interfaces, not standard implementations. X had the right idea of how to do this. ICCM allows any window manager to work with any X application. Why the KDE and GNOME guys ditched this paradigm is beyond explanation...
Honestly, people are able to use command lines. Ten years ago, Windows wasn't common at all. Yet, businesses all over the country used DOS programs without any problems. These weren't technologically elite people, they were just business users who have been doing the same word-processing tasks for the last century. They shifted from doing it by hand, to typewriter, to primitive PC machines, to primitive GUIs, all the way to Office XP. People haven't gotten dumber since then, the software industry's perception of them has.
Ugly text in X? I've tried KDE 2.2, both with and without anti-aliased fonts, and I can't tell the difference. To me, X looks no better with anti-aliasing. Or are you going to blame my monitor resolution (1280x1024x32 on a 17", a typical user's setup) or my eyesight (20/17, better than normal), or are you just going to attack my lack of aesthetic sensiblities?
>>>>>>>>>>
Actually, eyesight has nothing to do with it. My eyes are pretty bad, and I really can tell the difference between MS's good fonts and QNX's even better ones. Its a subjective thing. Many people with perfect hearing can't tell the difference between crappy speakers and good speakers. Same thing with monitors. Some people are just more sensetive to these details than others.
Well, just because it's okay for you don't mean its okay for everyone. Some people are just more sensitive to things than others. I think that AA fonts (good implementations, at least) look noticibly better than non-AA ones.
For a great implementation of AA fonts, check out QNX's RtP. The Font Fusion powered Photon has the most god-damn gorgeous fonts in the entire universe. Download RtP just to take an eyeful of the fonts!
I suggest you to take a few readings on qnx.com about realtime OS and you'll know what does it take to make a realtime OS.
>>>>>
I think you missed my point. I never said anything about QNX in the embedded space, I was talking about RtP in desktop space. According to QNX's docs, RtP is competing in desktop space. In that space, speed is more important than determinism. Maybe QNX doesn't want to fork the OS or change its deterministic policies, but then they shouldn't be competing in desktop space!
PS> Yes, all modern FSs should have journeling. Its not the fsck that matters, but the fact that in order to achieve good consistancy, it must use synchronus writes to the disk for metadata. That why the old BSD's without softupdates were so slow for compiling and untarring (very metadata intensive uses) and which is why QNX is slow for the same tasks.
PS2> QNX RtP really isn't used in nuclear reactors. QNX4 is used for those tasks. So far, the only thing QNX RtP (or QNX6 in general) has been used for embedded devices, which don't have the same life-or-death requirements of determinism that do nuclear reactors.
Anemic VM and filesystem? The VM and filesystem are fine - it'd be good if you gave a real example of how they were bad (the one below dosent count as I nip it in the bud...).
>>>>>>>>>
How 'bout these?
1) The filesystem is as slow as molasses. Untarring an archieve takes twice as long as on Linux. Throughputs above 10MB/sec (on my 7200RPM drive that gets 27MB/sec in Linux) are hard to come by. Apparently, something in libc has been fixed with 6.1, but the underlying FS problems are there. Also, no journeling, no softupdates, no features of any kind.
2) The VM cannot keep an mmap()'ed file in sync with with the disk if you use read/write to modify the file. That tells a lot about the deficiecies of the underlying implementation.
3) The VM and buffer-cache are not integrated. This was a big fault of BeOS's, and really hurt its I/O performance. BeOS and QNX are apparently the last big OSs without a unified buffer-cache/VM.
As for "nipping" the swap problem, you haven't. You still have to call munlockall(). So you either have to modify program source, or (if you have binary programs that don't call it) just live with it. Also, it was apparently put in just to support GCC, so I wouldn't be too sure that the underlying impelementation is very good.
I thought that I saw somewhere that QSSL was making parts of QNX open source? Anybody hear anything about that? An Photon Linux port would really rock. Photon has tons of features, is really small and fast, and the fonts and UI graphics look orgasmically good. QNX's kernel is nice for embedded systems, but on the desktop (which RtP tries to support) it is kinda flaky due to an anemic VM and filesystem. For example, it doesn't support paging directly, an app has to be coded with it in mind. Great for RT, but for GCC.
Actually, as far as I can find, the only thing that has been fixed is that the old libc (which wrote a few bytes at a time) has been replaced by a new one from Dinkumware. Nothing drastic, though.
Really, could you point me to some details? (Not facetious, I just want to find out more!)
When are they going to fix the QNX filesystem? It runs real bad on every machine I've tried it on (and it is #1 on the qnxstart.com wishlist). Eventually, people are going to put those cool IBM microdrives on their PDAs and start noticing the deficiencies of the filesystem. They have Dominic Giampalo (of BFS fame) working for them, so what's he doing?
A) First, all the gee-wiz features in MacOS-X and the new Linux WMs (except EVAS) are software accelerated. THAT'S slow.
No. KDE `gee whiz' (which I read as: usability - I like to be albe to read letters on screen - YMMV) done in XRender, which is hardware accelerated in almost every instance. GNOME 2.0 will also do a whole bunch of cute XRender stuff.
>>>>>>>>>
However, many more apps have accelerated OpenGL drivers than XRender drivers.
EVAS is something two people will use precisely because it uses a nonstandard method of rendering graphics that sends crap down the wire
>>>>>>>>>>
Sorry to break this to ya, but XRender is the non-standard method. OpenGL is a much more established (and supported!) standard, plus it does a lot more than XRender.
They don't, and that's the point. The standard excuse when it's pointed out Berlin gives app developers fewer options seems to be that those options are being given to the users instead, in the form of themes. But themes don't cut it.
>>>>>>>>
Entirely true. However, nobody said that themes were the only thing. There is configurability too. With the combination of the two, you get a good deal of power for the user. Also, nobody says that the toolkit must be the same in every case. Since Berlin is interfaced through Corba, it is entirely plausible that somebody would rip out the standard toolkit and implement a different one in its place. All app would still work, since the CORBA interface would remain unchanged.
They don't offer the same sorts of flexibility that the developer needs to create the right interface for a particular application. Sure, many (most?) developers abuse that responsibility instead of using it responsibly, but - as I said - you can't deny them that flexibility without a downside.
>>>>>>>
Are you honestly deluded enough to believe that application developers can USE all that flexibility? If that was true, Linux would be full of incredible great desktop applications. Its not. The problem with your thinking is that you want to give all the power to the developers, assuming that they somehow know more than the users. Besides, if a particular interface really is RIGHT for a particular application, nothing prevents that developer from implementing it himself. As long as you can still do raw drawing and get raw access to the interface devices, you can make whatever type of interface you want. True, that makes it harder for a developer to make a custom interface, but that's probably a good thing. If the app really needs that interface, then they'll go the extra mile to implement it. If it really doesn't, there is no point in breaking the standardization, now is there?
When did "people can't handle flexibility, we should abandon flexibility in favor of conformity" become the mantra around here?
>>>>>>>>
Its called society. Look outside the window. Conformity allows the world to run smoothly. I'm not saying that you should always conform, but you'd better have a good reason not to.
That's Windows thinking. It's totally opposite to the philosophy that underlies UNIX in general or Linux in particular.
>>>>>>>>>>
BS. UNIX is EXTREMELY standardized. Take the whole text-stream paradigm. It allows all apps to work together, no matter what they do. You think UNIX's CLI would have achieved the same level of usefulness if every developer had decided to use a different "but, it fits my app better!" method of exchanging text data?
Do you think all of your favorite X-window-manager toys - transparent and oddly-shaped title bars, dockable apps, virtual desktops just the way you like them - are going to survive a transition to Berlin?
>>>>>>>>
Yes, as long as the grognards want them, they'll get ported. However, many people DON'T like transparent, oddly-shaped title bars. Many people LIKE coherence and conformity. With Berlin, the rest of us aren't forced to pay for your weird sense of asthetics.
Think again. Because developers no longer have such flexibility, the environment you'd get with Berlin will be oh so spartan and sterile. But at least it'll be consistent, so I guess it's OK, right? Have you all tired of freedom so soon?
>>>>>>>>
Yes, that's why Windows apps have NO personality and inefficient interfaces. 3D Studio, Fireworks, Dreamweaver, Poser, Truespace, and Bryce are really just figments of my imaginiation and don't really exist.
Just checked out some of the code examples, and it looks like DirectDraw! Finally, somebody recognizes how cool the DirectX API really is!
Huh? How do themes relate to this? Themes are usually on the users end, so how do they relate to developers? I heard the word "flexibility." I don't like the word "flexibility." It usually means that some developer wants to mess with my desktop...
Cuz they are faster and cheaper and (until recently) had much better graphics HW. And much better standard sound cards. And an actual choice of speakers. And Sony monitors, gotta love those Sony monitors...
I think what he means is this. You take a Pinto, polt a Farrari engine, a BMW suspension, and a nice after-market Honda exhaust, its will still be a Pinto. On the other hand, if a car is designed with these performance components in mind, it will be a better car.
Extensions really aren't as cool as they're made out to be.
A) They aren't uniform. Say you add an extension for a high-speed way to access the display. All your old apps use the old (slow) method, and only a few new apps use the new, fast method. That sucks.
B) They duplicate functionality. In the above example, you now have 2 methods of accessing the display, when only one is needed. That sucks.
X has a perfect example right now. You have a standard font renderer, and you have a nice AA render extension. Not only do you now have to change the code in all your apps to use the new extension (or more likely, just live with un-AA text in some apps), but you have two sets of APIs that do the exact same thing! Its like Windows and its CreateWindow, CreateWindowEx, and CreateWindow16ThunkHack API.
Actually, "innovation" is a dangerous tool. You don't give it to monkeys. Blender has very specialized needs, and people are willing to spend some time learning it if the new UI is vastly more efficient than the standard. A spreadsheet, however, doesn't really benifet much by having a different UI, and its a much bigger help for the user if the UI of the spreadsheet matches the UI of the word processor. My point is that sometimes a different interface really is needed, and that can be implemented with a little work. Often times, however, a different interface is just put in because the developer thought it looked cool, and in those cases, the additional work required to implement non-standard interfaces will probably keep the developer from doing so.