The rationale for not programming the core of the OS in C++ is that C++ is much less predictable than C. While C is very straightforward and extremely procedural, stuff happens in C++ much more automatically. Thus, a constructor might get called at an inoportunate moment, or an STL class might suddenly run an allocator that you can't run at that moment. Then the changing nature of C++ also becomes a problem. You can't keep changing the API every time a cool new feature comes out. That's why the majority of C++ APIs tend to stick with the "core" features of C++ (which really just make C++ a better C) instead of going to the eostoric stuff. For example, BeOS's (and AtheOS's) GUI API uses virtual function overloading to replace callbacks. Instead of passing a pointer to a C function that overrides the "draw" function of a window, you pass an instance of a class that overrides a virtual Draw() function. Not earth shatteringly different, but slightly cleaner and nicer to work with.
I don't know how hard that would be. The BeOS and AtheOS APIs have a lot in common, and there is a BeOS X server. Plus, AtheOS has some networking features that BeOS doesn't, and porting Wine and X to AtheOS would probably be quite easy.
There's a reason you can't take back the GPL license on previously released code. Say, for example, you release something under the GPL. Then an OSS project incorporates some of your code. Then you could relicense it under something else, then tell the OSS project to either stop using your code, or sue them for license infringement. What the GPL does is it prevents that from happening. With the GPL, the same case would result in the OSS project keeping the old code, but not being able to get access to any of the new code that exists under the closed license.
The more data you need to suck off of disk the longer the user waits. GameCube has 6:1 compression for textures which is supported directly by the graphics chip, not only decreasing load times, but also decreasing internal bus bandwidth needs. Or at least offsetting them to make room for more cool effects.
If the extra space is needed I doubt it would be much more expensive to pack in two disks.
In general though, I don't see why it would be needed. The GPU can make some pretty nice stuff realtime.
>>>>>>>>>>>>&g t;>>>>>
Oh, no, where'd we here this arguement before? All that's missing is the insistance that MIDI music will be "good enough."
I think too many people focus too much on "big" things rather than things that work. The next "big thing" will not be a desktop environment with objects that can be remotely embedded into PalmPilots over an infrared link. The next "big thing" will not be a totally different graphics model ala DPDF. The next "big thing" will not be a 3D interface with force feedback effects. All of that BS is just intellectual masturbation for programmers who have no real work to do.
The next big thing will be a users desktop. A desktop that is configurable enough, powerful enough, easy enough, nice looking, cohesive, efficient, fast, and stable. To date, no such desktop exists. KDE and GNOME are slow, Windows is unstable and (fairly) ugly, QNX and Be lack useful features like object models, and all of the X window managers are not cohesive enough. The guy who manages to make a desktop which does all of the above will be a hero to the masses, even if the intellectuals chide him for having no vision.
Actually, I think you miss the point entirely. The Win2K UI look decent (even nice with litestep), is very functional, has tons of features, and is FAST. KDE-2 or GNOME look good, are very functional, have lots of features (but not as many as Win2K yet), and are SLOW. I think that's the point everyone complaining about speed is trying to convey. If MS can make a powerful desktop that runs quickly, why can't the OSS community do the same thing?
PS> MS isn't even the fastest. BeOS and QNX have desktops that are even faster! When you're competing with MS for last place, you know you have a problem!
Actually, GTK+ and Qt both have a sizable base of applications. They have also demonstrated themselves to be extremely portable. Wouldn't it be possible to design a simple windowing system (maybe on top of some of the EVAS work so as to get hardware acceleration) and port GTK+ and Qt to it? The only thing that would really be needed (aside from writing said window system) would be to port driveres, but both XAA and DRI seem very modular, so I don't know how hard it would be to port the interface. Of course, I have never touched a bit of X code, so I'm just hypothesizing, but from here, it looks entirely doable.
I think BeOS took a hell of a stab at being usable, and we can all see how far that's gotten those guys. I don't know about you, but I don't see Palm being the ones who get BeOS pre-loaded on most new PCs sold, either. BeOS is living proof that a great desktop GUI doesn't equate with popularity.
>>>>>>>>>>
Actually, I think the reason BeOS tanked is because it didn't have Linux's open-ness. No big company has the balls to compete with MS on the desktop, and no little company has the resources to compete with MS period. BeOS lacked an OSS community that could keep improving it even without profits rolling in. Linux, on the other hand, is missing many of the features of a good desktop GUI, and is thus not taking over the desktop for a different reason.
Now assume for a minute that I, as the Uberhacker that I am, decide I'm not quite happy. GNOME sucks, I want something better. I take "Linux" and change the GUI environment and create... "GarvIX". One of two scenarios may play out:
>>>>>>>>>
Actually, in the ideal scenario, it would be the APIs that would be standardized, not the desktop environment. So you'd just write GarvIX to implement the standard API and then distribute it to all your followers. This is the same concept as OpenGL, btw. You write to the API, and the implementation is totally up to you. Of course, if you don't like the API, you just have to deal with it. After all, you don't see people rewriting OpenGL do you? (D3D is a subject for another discussion...)
Don't you see that the more integration there is between the apps and the desktop environment, the fewer choices you will have?
>>>>>>>>>
No, that just gives developers power. Take a hypothetical user using Linux for development. He loves VisualC++, so he uses KDevelop. So, who decides what desktop he uses? Not him, no. The guys who wrote KDevelop get to decide that. He can either run KDE-2, or he can live with a desktop that doesn't mesh together. If all these DEs interoperated perfectly, he could erase KDE2 and Qt from his harddrive, and still run his favorite app in HIS choice of desktop environments. THAT'S real choice.
PS> No, this is not a KDE vs. GNOME flame. They both suck...
Actually, programmers use vi, so its a non-issue. Seriously, though, I don't see legions of Windows programmers up in arms over Windows being bad for programming. All Linux window managers and Windows work mostly the same way, so what exactly is the difference? I'd just like some concrete examples of when the configurability (or multiplicity) of Linux GUIs has allowed somebody to do something really useful.
As far as speed is concerned, twm and blackbox are very fast.
>>>>>>>>
Yea, and they have none of the features of Windows. Windows has the features of KDE and GNOME without being as slow as them. And I use Win2K on a PII-300, so its not my hardware that makes Win2K seem fast!
Wow, that's out there. Doing what you're doing is like loading up that poor machine with a debug builds of Linux 2.4.x-pre1, XFree86 4.1, KDE-2, GNOME 1.4, and E16. Let me tell you, that's not a fast config either. First of all, XP is a RAM hog. Hell, so is KDE-2 and GNOME, so deal with it. Second, That's an XP beta. What were you thinking? How can you possibly base an opinion on a BETA release of Windows?
That's just the same under Windows, where any program requires that you also install all the dlls that it requires
>>>>>>
Actually, its two totally different things. All the GUI libraries I know of on Windows use the underlying Win32 services. They use the same drawing services, the same printer services, etc. While it may be true (as the replyer to your post said) that there are different GUI libraries on Windows, the fact that they use the same underlying services makes it a moot point. The fact that loading both kde-libs and gnome-libs uses up an ass-load of resources is regretable, but not the main problem. The main problem is that apps using the two different systems don't interoperate perfectly with each other. On Windows, this problem doesn't exist, since there is only ONE object model, ONE printing system, ONE clipboard system, etc.
Thank you! That's what nobody seems to understand. Windows's interface is the easiest for the sole reason that that's what everyone knows. I'm not sure that most/.'ers remember this, but an entire generation of normal people used CLI machines to do regular business work. It wasn't any more difficult for them than GUIs are today. What is easy is what you understand, its as simple as that.
Using your logic, an engine that uses MMX is "hardware accelerated." As nice as Altivec may be, it still can't compare to the 57 million transistors on a GeForce3 that are dedicated to graphics work. Atlivec is (because it has to be) much more general than the ASIC on the GeForce3, and by that virtue is slower.
What? I used Mandrake (as in Linux Mandrake) as an example of a company that had no asthetic sense, due to their lavander icons. I wasn't confusing them with Mandrake the programmer.
Most acceleration is really just BitBlits. Take anti-aliasing for example. Most hardware doesn't do alpha blending in 2D mode. Thus, all of the nice AA text in a GUI has to be rendered in software. Then there are the transparency effects (fading menus and such). Again, since alpha-blending isn't accelerated, this effect has to be done in software. Things that are trivial to do in OpenGL (transparent windows, special effects) are really expensive on most 2D architectures.
Once you start down the path of chaos, you're pretty much screwed that way too. There's nothing that prevents people from making a desktop standard, then letting different people implement it (just like ICCM and the X window managers). That's probably the best trade-off, IMNHO.
But KDE and GNOME aren't really compatible. Sure you can run programs from both environments at the same time, but they don't really interoperate at all, they just happen to exist on the same desktop. I can run X applications on my Win2K desktop, but that doesn't mean that Win32 an X are compatible.
Until know, people have been sitting on their desktop (Windows people anyway, the Linux people all use S3s as we all know...) with super powerful 3D cards in their computers, but kept them idle a large portion of the time. Even in Windows, only a portion of the GUI is really hardware accelerated. EVAS is a brilliant idea that lets you use the 3D accelerator that you already have to make a great looking desktop that also runs really fast. I don't know about you, but that's a pretty big thing. Maybe not CLI -> GUI big, but those only happen once every few decades, and if you reserved "Next Big Thing" for stuff of that magnitude, journalists would never be able to use the phrase. And it IS such a nice phrase, is it not?
E17 very well might be the technology that makes advanced drawing APIs popular on desktop applications. NeXT never really made it very far into the market, and OS-X, while popular, is still pretty slow. I know 10.1 is supposed to be faster, but there is only so much you can do with software rendering! My only concern with EVAS is whether or not it will hurt the performance of windowed 3D apps (like 3D modelers).
As an aside, this Rasterman guy is the only person in the OSS community that has any asthetic sense. While the Mandrake guys are busy designing lavander icons, the SuSE people are busy with the (ugly) Lizard motif, and the KDE2 guys are trying to make their desktop look like something out of Mattel, E genuinely looks good. I know there are themes, but the "look" of KDE or Mandrake are unescapable. Mandrake freezes you into installing their freaky purple desktop by making every X app depend on mandrake_desk. (No, I don't have the time to try to figure out the menu config file format and change it back!) And with KDE2, everytime something SIGs out, a cute little dragon comes up to inform you that your app crashed. Here's my theory. The KDE project is trying to capitalize on the success of the PaperClip from Hell (TM).
Slashdot Mirror
The rationale for not programming the core of the OS in C++ is that C++ is much less predictable than C. While C is very straightforward and extremely procedural, stuff happens in C++ much more automatically. Thus, a constructor might get called at an inoportunate moment, or an STL class might suddenly run an allocator that you can't run at that moment. Then the changing nature of C++ also becomes a problem. You can't keep changing the API every time a cool new feature comes out. That's why the majority of C++ APIs tend to stick with the "core" features of C++ (which really just make C++ a better C) instead of going to the eostoric stuff. For example, BeOS's (and AtheOS's) GUI API uses virtual function overloading to replace callbacks. Instead of passing a pointer to a C function that overrides the "draw" function of a window, you pass an instance of a class that overrides a virtual Draw() function. Not earth shatteringly different, but slightly cleaner and nicer to work with.
I don't know how hard that would be. The BeOS and AtheOS APIs have a lot in common, and there is a BeOS X server. Plus, AtheOS has some networking features that BeOS doesn't, and porting Wine and X to AtheOS would probably be quite easy.
There's a reason you can't take back the GPL license on previously released code. Say, for example, you release something under the GPL. Then an OSS project incorporates some of your code. Then you could relicense it under something else, then tell the OSS project to either stop using your code, or sue them for license infringement. What the GPL does is it prevents that from happening. With the GPL, the same case would result in the OSS project keeping the old code, but not being able to get access to any of the new code that exists under the closed license.
\.? What is that? Is there a Windows version of /. floating around somewhere?
The more data you need to suck off of disk the longer the user waits. GameCube has 6:1 compression for textures which is supported directly by the graphics chip, not only decreasing load times, but also decreasing internal bus bandwidth needs. Or at least offsetting them to make room for more cool effects.
If the extra space is needed I doubt it would be much more expensive to pack in two disks.
In general though, I don't see why it would be needed. The GPU can make some pretty nice stuff realtime.
>>>>>>>>>>>>&g t;>>>>>
Oh, no, where'd we here this arguement before? All that's missing is the insistance that MIDI music will be "good enough."
I think too many people focus too much on "big" things rather than things that work. The next "big thing" will not be a desktop environment with objects that can be remotely embedded into PalmPilots over an infrared link. The next "big thing" will not be a totally different graphics model ala DPDF. The next "big thing" will not be a 3D interface with force feedback effects. All of that BS is just intellectual masturbation for programmers who have no real work to do.
The next big thing will be a users desktop. A desktop that is configurable enough, powerful enough, easy enough, nice looking, cohesive, efficient, fast, and stable. To date, no such desktop exists. KDE and GNOME are slow, Windows is unstable and (fairly) ugly, QNX and Be lack useful features like object models, and all of the X window managers are not cohesive enough. The guy who manages to make a desktop which does all of the above will be a hero to the masses, even if the intellectuals chide him for having no vision.
Actually, I think you miss the point entirely. The Win2K UI look decent (even nice with litestep), is very functional, has tons of features, and is FAST. KDE-2 or GNOME look good, are very functional, have lots of features (but not as many as Win2K yet), and are SLOW. I think that's the point everyone complaining about speed is trying to convey. If MS can make a powerful desktop that runs quickly, why can't the OSS community do the same thing?
PS> MS isn't even the fastest. BeOS and QNX have desktops that are even faster! When you're competing with MS for last place, you know you have a problem!
Actually, GTK+ and Qt both have a sizable base of applications. They have also demonstrated themselves to be extremely portable. Wouldn't it be possible to design a simple windowing system (maybe on top of some of the EVAS work so as to get hardware acceleration) and port GTK+ and Qt to it? The only thing that would really be needed (aside from writing said window system) would be to port driveres, but both XAA and DRI seem very modular, so I don't know how hard it would be to port the interface. Of course, I have never touched a bit of X code, so I'm just hypothesizing, but from here, it looks entirely doable.
I think BeOS took a hell of a stab at being usable, and we can all see how far that's gotten those guys. I don't know about you, but I don't see Palm being the ones who get BeOS pre-loaded on most new PCs sold, either. BeOS is living proof that a great desktop GUI doesn't equate with popularity.
>>>>>>>>>>
Actually, I think the reason BeOS tanked is because it didn't have Linux's open-ness. No big company has the balls to compete with MS on the desktop, and no little company has the resources to compete with MS period. BeOS lacked an OSS community that could keep improving it even without profits rolling in. Linux, on the other hand, is missing many of the features of a good desktop GUI, and is thus not taking over the desktop for a different reason.
Now assume for a minute that I, as the Uberhacker that I am, decide I'm not quite happy. GNOME sucks, I want something better. I take "Linux" and change the GUI environment and create... "GarvIX". One of two scenarios may play out:
>>>>>>>>>
Actually, in the ideal scenario, it would be the APIs that would be standardized, not the desktop environment. So you'd just write GarvIX to implement the standard API and then distribute it to all your followers. This is the same concept as OpenGL, btw. You write to the API, and the implementation is totally up to you. Of course, if you don't like the API, you just have to deal with it. After all, you don't see people rewriting OpenGL do you? (D3D is a subject for another discussion...)
Don't you see that the more integration there is between the apps and the desktop environment, the fewer choices you will have?
>>>>>>>>>
No, that just gives developers power. Take a hypothetical user using Linux for development. He loves VisualC++, so he uses KDevelop. So, who decides what desktop he uses? Not him, no. The guys who wrote KDevelop get to decide that. He can either run KDE-2, or he can live with a desktop that doesn't mesh together. If all these DEs interoperated perfectly, he could erase KDE2 and Qt from his harddrive, and still run his favorite app in HIS choice of desktop environments. THAT'S real choice.
PS> No, this is not a KDE vs. GNOME flame. They both suck...
You know, BeOS treats ALL hardware like that. The only time you have to step in and do configuration is cases where something goes terribly wrong.
Actually, programmers use vi, so its a non-issue. Seriously, though, I don't see legions of Windows programmers up in arms over Windows being bad for programming. All Linux window managers and Windows work mostly the same way, so what exactly is the difference? I'd just like some concrete examples of when the configurability (or multiplicity) of Linux GUIs has allowed somebody to do something really useful.
As far as speed is concerned, twm and blackbox are very fast.
>>>>>>>>
Yea, and they have none of the features of Windows. Windows has the features of KDE and GNOME without being as slow as them. And I use Win2K on a PII-300, so its not my hardware that makes Win2K seem fast!
Wow, that's out there. Doing what you're doing is like loading up that poor machine with a debug builds of Linux 2.4.x-pre1, XFree86 4.1, KDE-2, GNOME 1.4, and E16. Let me tell you, that's not a fast config either. First of all, XP is a RAM hog. Hell, so is KDE-2 and GNOME, so deal with it. Second, That's an XP beta. What were you thinking? How can you possibly base an opinion on a BETA release of Windows?
That's just the same under Windows, where any program requires that you also install all the dlls that it requires
>>>>>>
Actually, its two totally different things. All the GUI libraries I know of on Windows use the underlying Win32 services. They use the same drawing services, the same printer services, etc. While it may be true (as the replyer to your post said) that there are different GUI libraries on Windows, the fact that they use the same underlying services makes it a moot point. The fact that loading both kde-libs and gnome-libs uses up an ass-load of resources is regretable, but not the main problem. The main problem is that apps using the two different systems don't interoperate perfectly with each other. On Windows, this problem doesn't exist, since there is only ONE object model, ONE printing system, ONE clipboard system, etc.
Thank you! That's what nobody seems to understand. Windows's interface is the easiest for the sole reason that that's what everyone knows. I'm not sure that most /.'ers remember this, but an entire generation of normal people used CLI machines to do regular business work. It wasn't any more difficult for them than GUIs are today. What is easy is what you understand, its as simple as that.
Using your logic, an engine that uses MMX is "hardware accelerated." As nice as Altivec may be, it still can't compare to the 57 million transistors on a GeForce3 that are dedicated to graphics work. Atlivec is (because it has to be) much more general than the ASIC on the GeForce3, and by that virtue is slower.
What? I used Mandrake (as in Linux Mandrake) as an example of a company that had no asthetic sense, due to their lavander icons. I wasn't confusing them with Mandrake the programmer.
Actually, GL 1.2 have pretty nice imaging extensions. And, with newer cards, all of those are accelerated, something that can't be said of PDF.
Most acceleration is really just BitBlits. Take anti-aliasing for example. Most hardware doesn't do alpha blending in 2D mode. Thus, all of the nice AA text in a GUI has to be rendered in software. Then there are the transparency effects (fading menus and such). Again, since alpha-blending isn't accelerated, this effect has to be done in software. Things that are trivial to do in OpenGL (transparent windows, special effects) are really expensive on most 2D architectures.
Once you start down the path of chaos, you're pretty much screwed that way too. There's nothing that prevents people from making a desktop standard, then letting different people implement it (just like ICCM and the X window managers). That's probably the best trade-off, IMNHO.
But KDE and GNOME aren't really compatible. Sure you can run programs from both environments at the same time, but they don't really interoperate at all, they just happen to exist on the same desktop. I can run X applications on my Win2K desktop, but that doesn't mean that Win32 an X are compatible.
Until know, people have been sitting on their desktop (Windows people anyway, the Linux people all use S3s as we all know...) with super powerful 3D cards in their computers, but kept them idle a large portion of the time. Even in Windows, only a portion of the GUI is really hardware accelerated. EVAS is a brilliant idea that lets you use the 3D accelerator that you already have to make a great looking desktop that also runs really fast. I don't know about you, but that's a pretty big thing. Maybe not CLI -> GUI big, but those only happen once every few decades, and if you reserved "Next Big Thing" for stuff of that magnitude, journalists would never be able to use the phrase. And it IS such a nice phrase, is it not?
E17 very well might be the technology that makes advanced drawing APIs popular on desktop applications. NeXT never really made it very far into the market, and OS-X, while popular, is still pretty slow. I know 10.1 is supposed to be faster, but there is only so much you can do with software rendering! My only concern with EVAS is whether or not it will hurt the performance of windowed 3D apps (like 3D modelers).
As an aside, this Rasterman guy is the only person in the OSS community that has any asthetic sense. While the Mandrake guys are busy designing lavander icons, the SuSE people are busy with the (ugly) Lizard motif, and the KDE2 guys are trying to make their desktop look like something out of Mattel, E genuinely looks good. I know there are themes, but the "look" of KDE or Mandrake are unescapable. Mandrake freezes you into installing their freaky purple desktop by making every X app depend on mandrake_desk. (No, I don't have the time to try to figure out the menu config file format and change it back!) And with KDE2, everytime something SIGs out, a cute little dragon comes up to inform you that your app crashed. Here's my theory. The KDE project is trying to capitalize on the success of the PaperClip from Hell (TM).