I do believe this project is possible, and probably practical.
1) Windows comptability would kick ass in an OSS OS. Not matter what people say, Windows still has the best apps.
2) It might result in a better windows than windows. If the designers of this new OS can take some liberties and leave out support for Win16 stuff, then the whole thing can a true, non-bloated OS capable of running Win32 applications (which btw. are the only ones worth running and the ones that don't already run on stuff like Wabi.) Also, it should be possible to rearchitecture the internals of this OS for speed and efficiency. As Microsoft has shown (with NT), Windows applications are tied to the API, but not so much to the underlying OS. The fact that most major applications survive the transition to NT intact means that the resulting OS needn't look at all like Win9x or NT. Although applications don't access the OSs internals, drivers are pretty dependant on them, so rearchitecturing the OS may lead to driver incomptability.
3) This would probably be a good OS for games. First, games tend to be pretty API complient. DirectX offers most of the features that a game designer needs from an OS, and DirectX itself is fairly well documented. Because of DirectX, there are fairly few Win32 calls in most games. If this new OS could be rearchitectured to mesh well with DirectX, then it would immediatly gain support since games are big business in the consumer sector.
4) From a comptability standpoint, it all depends. If MS doesn't object to them using DirectX and OLE/COM, then the project won't have to many compatability troubles. Its going to be a legal challange more than anything else, especially if they leave out support for older technologies. Most of MS's newer APIs are well documented, so replicating them shouldn't be terribly hard. However, if MS manages to stop them from using OLE/COM and DirectX (since they are closed APIs) then the project is useless. All the apps worth running on Windows use those two technologies. (I mean why do you think NT 4.x was a less than great seller in the consumer market? It's faster, more stable, but lacks good DirectX support.)
5) It's surprising they didn't mention WINE. Apparently they have replicated some Windows libraries, and that will undoubtadly help these guys. Also, the relative success of Wine is a good sign. It shows that applications aren't terribly dependant on the undocumented aspects of Windows, and that an OS replicating the API might work.
6) There's all kind of legal issues at work here.
A) MS might be forced to open up the Windows code/APIs. While this is years away, if it happens, it will coincide with the probably point of maturity for this project. Thus, any missed bits could be incorporated in. B) MS might sue. C) MS might play the "API of the day" game like it did with IBM. But they might be prevented from doing that by the DOJ.
7) The project sounds like a big task. However, I think the biggest mistake they can do is to replicate Windows 100%. The inclusion of FreeDOS in the projects listed page is a bad sign. This OS should NOT contain DOS/Win16 comptability. Most new applications don't use any of those outdated APIs, and it really isn't worth the effort, because things like DosEMU and Wabi exist. Also, native alternatives to older apps like that exist. If they go the track of 100% comptability, I'm afraid they might end up being simply an OSS version of Windows with worse comptability and comprable speed and efficiency.
I posted this after I read the responses to my original post. I'm not out to "prove" anything. I've read a few articles on it awhile ago, and somehow fractals got mixed in with the memory. It was a mistake. I'm sorry. It happens to everybody. As for my comments about WIllamette, I did make some mistakes and had to revise my concept a little bit, however my overall point still stands. In consumer space, Willamette will be a beast. I was wrong about some aspects of it, (for example, I thought the clock doubling applied to the whole pipeline) but nobody has disproven my point. It seems that Intel is trying to take on NVIDIA in the geometry department. In doing so, they make a chip that performs geometry acceleration very well, but is a little weaker per-clock for other tasks. However, the high clock-speeds outweigh this disadvantage, and help greatly for matrix operations where Willmatte is really strong per clock (because the 20 stage pipeline really doesn't have a negative effect on something regular like matrix operations.) Additionally, Intel not only has the motive (geometry accelerators make them less relevant in the all important games market) but the concept makes sense. If Willamette is weaker per clock than K7, but at a higher clock-speed, it's performance should match most of the time. However, the high-clock speed really helps matrix operations, where Willamette doesn't have a per-clock disadvantage. Also, I said that AMD needs to do something to counteract Willamette. AMD doesn't HAVE anything to counteract Willamette. Not only is the next chip (Mustang) not aimed at all at the consumer market, but AMD's chip after that (K8, Sledgehammer) is aimed at competing in server space. Additionally, it appears (if you read the articles recently on ZDNet and CNET) that Intel may be lowering the market they're aiming at with Willamette. If that's the case, then AMD has nothing to counter that. There you go, a summery of the entire thread. Where's the "total bullshit?" Prove me wrong here somewhere, then maybe you've got a point.
Wavelet compression has already been used to compress images. It does this by finding a fractal pattern or something like that. I've actually run the demo that compresses video using wavlets. Its a small animation of a girl brushing her hair, (I think, I don't remember it exactly.) Also, there is a site that contains pictures compressing stuff like a picture of a glass of wine, a cow, etc.
I know this article specifically refers to using wavelets for compressing 3D, but it should be able to be used for video. FYI, wavlet compression is a method that uses fractals to compress an image. If you've seen the wavelet demos, you know just how much better than JPEG wavlet compression looks. Using the same process, it is also possible to compress a sequence of frames as in a video. This is demonstrated in some of the wavlet demos floating around the net. Right now they're in black and white, and are pretty small, but it is conceivable that they'll get better. A big problem with wavelet compression is the CPU cost. Even single images can take a second or two to decompress. However, that can probably be offset by hardware decompression mechanisms, and it doesn't seem that they're will be a shortage of CPU power anytime soon. If you've ever seen how well wavelet lets you compress images 50:1 with so little quality degredation, you'll understand what an impact this method could have on computer video.
As anybody who has ever seen the stependous quality of high-res wavelet images knows, this compression is pretty amazing. Although there are probably other, more legitimate I might add, uses for this, the first thing that comes to mind is porn videos. Seriously! The adult market is one of the only internet ventures making money, and this new compression just helps out the US ecomony some more. (Not to mention the fact, that if wavelet compression allows streaming quality comparable to DVD, then you can cancel your subscription to the Spice channel;)
Well, fun for whom? It seems to me, that if Linux is going to make it mainstream (as so many people want it to) then the developers have to make some concessions. Personally, I would rather design an application that makes the user happy than have some extra freedom about what toolkit to choose. Maybe it's just me, but a better end product is a lot cooler than the philosophy behind the product.
Binary standard in the sense of Windows OpenGL libraries. You can drop in any ICD (which is basically an implementation of OpenGL) and it will work no matter how the ICD is programmed. There isn't a big difference between GNOME and KDE in terms of what they do. If they used the same API and applications were binary compatible (ie. You could run KDE apps on GNOME without installing compatibility libraries) and integrated into each environment (an application would look "at home" in either GNOME or KDE because they would rely on services from the underlying toolkit) then the user could choose what environment to run without having to consider if they apps they want to run support it. In the current situation, the environment to run is largely supported by what apps one uses. It should be entirely about which environment the user likes better. The same thing exists in Windows to some degree. You can replace explorer with Litestep and get a different window mangager. However, all applications remain compatible. This is simply an extension of that concept.
That's not my point at all. There's nothing wrong with wanting something for free (I know I do!) My point is twofold A) He said it is "commerical payware." Just the tone of that sounds like some guy who says, "I'm not going to use ". As if this is in any way on the same level as that. B) I understand that people wnat a free alternative if they can't afford it, they're nothing wrong with that. In fact, the main thing I admire about the OSS community (and probably the ONLY thing I admire) is that they're willing to shut up an code something if the products on the market aren't satisfactory. However, the way that previous poster worded his post, I got the impression that he wasn't going to use it because it wasn't free, and actually expected to find an OpenSource application that come anywhere close. I don't know, just the TONE pissed me off. As for your animation package, good luck. However if you produce anything close to Animo, I suggest you find a way to sell it!
Actually, over the years, MaximumPC's editors have suggested all manners of ways to punish vendors who ship with DMA off. I think one involved a ferret and a wet noodle...
Of course, VIA chipset's also required an upgrade to the kernel as I remember, Not MS's fault that VIA chipsets tend to be flaky. Even still, download drivers, or recompile kernel. I can probably choose which one I want to do on a rainy day;)
I'm not sure I'd agree about a MS forcing everyone to use MFC producing a 'better' library, but it certainly helps produce more of them (both better and worse). After all, by that logic we should all just use WinXX since that has one standard API and all these apps already. Personally I'm looking forward to the day when I can use my Win95 CD as a coaster next to my AOL CD (unfortunately I still need Windows for work). >>>>>> I said better library of APPLICATIONS. MFC is pretty crappy, and I refuse to touch it with a 10 foot pole. However, both GTK and Qt are very good, and there is little need for both. Either way, what I said is that MFC has lead to a great library of applications on Windows. Because of their use of a common library, they all have extremely powerful drag and drop capabilities, are very interoperable, and Windows apps in general tend to have a pretty consistant UI. The common library really allows Windows to be a much more cohesive entity. For example, in most programs, right click support is implemented quite extensivly. The big reason is that MFC provides functionality to ease implementing right click support. Also, MFC exposes a very powerful clipboard API. This allows applications to interoperate very well. By MS decreeing that everybody use MFC, (which is basically a wrapper for Win32 and thus offers the same features) focus shifted away from the toolkit to creating applications that take FULL advantage of the toolkit.
Incidentally, isn't there the OWL framework that Borland was pushing as an alternative to MFC? Wether people used it or not, it was still there and it was still an alternative, and one that some people used. >>>>>>> Yea, but it was killed by Microsoft's influence on everybody using MFC. It was an alternative, but not in the same sense Qt and GTK are. There's no central power forcing people to use GTK or Qt.
There is more then enough room for both KDE and Gnome... provided we develop some standards so that applications written for either can be run by either, and run mostly (not neccessarily 'entirely' although that would be nice) the same. >>>>>>> That's my point. It is POSSIBLE (though it takes planning and thinking, and it seems to me that OSS developers would much rather just code than plan) to have completely seperate DEs that are binary compatible. There's nothing wrong with that. That doesn't cause any fragmentation, leads to competition and better choices, etc. In fact, it leads to even MORE choice. Instead of the application designer choosing what DE the user runs, the USER can decide that. It also reduces bloat and allows developers to take better advantage of the FULL API of the DE.
I think they do that already, and the penalty of loading an extra set of libraries is not that much nowadays. Diversity is a good thing, and one that is most likely not going to disapear soon, since even if one side grabs the developers (and in my opinion, people usually go where the most apps they can use is... all else being equal), the other is doing it because they want to. >>>>>>> The overhead IS significant. On my 128MB system, the overhead of going from KDE 1.1.2 to KDE +GNOME means a 20MB jump in memory. That's 20MB less I can use for GIMP to load a large graphic. It causes my Linux environment to be MORE bloated than NT. Not only that, but it causes two other things. A) The consitancy of the desktop is shot, B) Major application designers tend to use NEITHER interface because they don't want to block out either user. In the end, they go back to using straight X + Motif. Compared to Windows, the average Linux system might as well not have a DE at all, since that's what incompatible DEs lead to. I mean the integration at the KDE-only level is great, easily competitive to Windows. However, Linux as a whole doesn't compare well to Windows simply because none of the good applications use the integrated metaphor. Look at the killer apps on Linux. For a lot of users (namely me;) That's GIMP, KDevelop, Netscape, and Corel WordPerfect. On Windows the equivilent apps have a lot of integration. On Linux there totally seperate entities. My point is that there's a better way to do it. It's probably too late with all the steam KDE and GNOME have gathered, but there's still a better way. PS> In the current model, users don't choose the DE they use, application developers do. It shouldn't be that way. Just as there are standards that allow you to choose to use a NVIDIA graphics card instead of an ATI, there should be standards taht allow you to use GNOME instead of KDE without the consequences of a reduced experience. However, that goes too much into dictating policy, which UNIX developers are loathe to do. I was reading Miguil's comments, and it hit me. SOMEBODY has to implement policy, or the system has no policy!
I have to nitpick on your point. A major problem that Linux is going to have is to have the coders get over themselves and write applications for USERS. One toolkit results in less bloat and a more consistant library of applications. All that makes for a better user experience because user's don't care about the toolkit powering something. In these cases, the quality of the product for the consumer is probably more important than the developer freedom of choice. I'm sure most people don't want to use MFC, but face it, MS making everyone use MFC really DOES result in a better library of apps and a better UI.
Not having a C binding isn't as big a problem as it may seem. Most C coders can fairly easily learn C++, because Qt doesn't use any of the eostoric features of C++. Basically, they use C++ for virtual functions (not really any understanding needed on the developer's part) and C with classes.
A) This is clearly a troll, why did it get modded up? B) Why the hell does it say Score:0 when I'm in the post editor, but Score:2 in the actual thread? C) Qt is faster and easier to program. D) A QT2GTK wrapper would be very slow.
Yes ludicrous concept. The problem is that diversity is useless without standards. If KDE and GNOME were 100% binary compatible, I'd have NO problem with having 2 (or 200) of them. That was the situation before that days of KDE when you only had Window managers. They were all different, all had some nifty features, and all ran all the X11 applications. THAT was GOOD choice bloat because no matter what you chose, you could run all the apps. However, the situation now is BAD choice bloat. KDE/Linux and GNOME/Linux are 2 different operating systems as far as the application is concerned. Without a binary standard to unify them, you end up with the current situation where a lot of users have to have both installed. That's unacceptable, because both GNOME and KDE continue to grow, and continue to subsribe to the emacs "I AM an operating system" concept. Now, Linux is easily 2 or 3 times more bloated than it should be. If this keeps up, "speed, efficiency and elegance" will no longer be one of the advantages Linux has over Windows. If there was a binary standard, then great. But by decreeing that "We must have many choices!" and sticking to it despite the "real world" problems that come with diversity without a standard, you're sticking to ideology instead of pragmatism. And when you can't accept another concept because of ideology, you're guarenteed a crappy product.
Diversity and competition drives innovation, but so does STANDARDS! I could care less if there were two different systems as long as the two were binary compatible! However, in its current state, I've got to put up with GTK+ applications in my KDE desktop (or vice versa) and have to live with 3 *VERY* large libraries in memory at the *SAME* time. Diversity and competition is useless unless there's a way for a person to pick one without having to run them ALL. And exactly what is having to DE's accomplished so far? They're both pretty much the same in features and usability. (though KDE has an edge in speed and stability.) Is there any SANE reason to have to different object models? You can't apply the same concept to everything. Diversity and competition may drive innovation in some places, but in a lot of places, it simply leads to a crappier product. Take the army for example. If you had each person competing with each other, you'd have a crappy army. By having 2 desktop environments, you've got two DEs that are very similar, and a very pissed off user complaining that he needs more RAM to run the damn thing. Microsoft is enough competition for Linux in the short term. Look at what KDE's development has consisted of so far? Take Microsoft features, copy it, improve it, and add it to KDE. So has GNOME's. If you ask me, there's not a lot of innovation going on.
Or, you could thing of legacy as any theme that existed before KDE2? KDE2's theme engine is the latest one availabe. Thus, anything BEFORE it can be considered legacy. When something support a legacy something else, it usually means that that somethign supports a body of somethings that aren't native, but already in existance. Thus, KDE2 supporting legacy themes means it doesn't support these natively, but since a large body of these themes exist, they're making special provisions to support these older themes. Plus, the air between GNOME and KDE is generally full of cooperation and friendship, so why would they do something like that? It seems to me that they weren't really expecting some people to read so much into this and got lazy in their wording. (Legacy Theme Importer as opposed to the Legacy and GTK+ theme importer!)
That's not what "not mission critical" means. Not mission critical means that it is okay if you have to do a reboot and the server is down for 10 minutes. It means that you don't have to have a redundent cluster to make sure that if one goes down you don't need to take the database ofline. Losing an entire 30GB database and having to reload it is unacceptable under any circumstances. Treating it mission critical usually means cost takes a back seat to having 100% uptime. I don't think that's what he needs.
I know, I'm spooling up my printer right now. I posted this, then I looked down the posts, and somebody asked that if the WildCat driver will use DRI or not... But my point about support from other vendors still stands (although is weakened due to the fact that WildCat is the highest performing part and will probably lead to the other supporting it.)
Photoshop is an application. Bind is not really an application, but a system service. In more traditional OSs, stuff like bind and other system services (directory management, ftp servers, etc) come with the OS, and are supported by the OS vendor. If bind on your Solaris box has a problem, (assuming its the bundled bind) then Sun HAS to support it since its THEIR application (and in this case THEY wrote it.) However, in Linux, the writers of these low level system services aren't the distro company, but some independant author. In that case, the distribution manufactuer has to support that piece, because even though they didn't write it, people are used to getting support on things seen as part of the OS distribution from the OS distributer. Linux comes with a lot of software, and I'm not saying that they should support it all. However, most people can figure out that GIMP isn't a part of the system, and go towards the appropriate support. But stuff like bind, gcc, ftp and telnet daemons, sendmail, etc, that are usually supported in the case of other OSs, (for example Microsoft supports problems in IIS, or Sun support problems with their ftp daemon) should be supported by the distro maker.
Oh, I were under the impression that Softimage contained a lot of OpenGL code that was really old and maybe not standards complient. I'm pretty sure there's no IrisGL code in there, because SoftImage's main platform was WindowsNT for awhile (and actually still is.)
That helps to a degree, but guess what, OpenGL accelerators are much more homogeneous than Linux distributions, standards guides or not. And from a company that certifies specific OpenGL accelerators to use, I'm not sure that that document is going to change their stance on supporting multiple distributions.
You know it just hit me. How does one turn on DMA in Linux? "Compile the right chipset into the kernel, then play with hdparm." How does one turn on DMA in Windows? "Click on the DMA enabled checkbox in device manager."
This compared to the Linux crowd whose benchmarks are, "oh, I just installed this and have only used Windows before and Linux is the fastest thing I've ever seen," or "on my 386 33 with 4 MB of RAM, Linux absolutely BLOWS AWAY Windows 2000" or my favorite "I've been using Linux ever since kernel.9 and its so fast! I mean, I played around with the Win2K alpha release, and Linux is SO much faster. What WM am I using? I don't run X, what a silly question! What do you MEAN that my comparison is invalid?"
Slashdot Mirror
I do believe this project is possible, and probably practical.
1) Windows comptability would kick ass in an OSS OS. Not matter what people say, Windows still has the best apps.
2) It might result in a better windows than windows. If the designers of this new OS can take some liberties and leave out support for Win16 stuff, then the whole thing can a true, non-bloated OS capable of running Win32 applications (which btw. are the only ones worth running and the ones that don't already run on stuff like Wabi.) Also, it should be possible to rearchitecture the internals of this OS for speed and efficiency. As Microsoft has shown (with NT), Windows applications are tied to the API, but not so much to the underlying OS. The fact that most major applications survive the transition to NT intact means that the resulting OS needn't look at all like Win9x or NT. Although applications don't access the OSs internals, drivers are pretty dependant on them, so rearchitecturing the OS may lead to driver incomptability.
3) This would probably be a good OS for games. First, games tend to be pretty API complient. DirectX offers most of the features that a game designer needs from an OS, and DirectX itself is fairly well documented. Because of DirectX, there are fairly few Win32 calls in most games. If this new OS could be rearchitectured to mesh well with DirectX, then it would immediatly gain support since games are big business in the consumer sector.
4) From a comptability standpoint, it all depends. If MS doesn't object to them using DirectX and OLE/COM, then the project won't have to many compatability troubles. Its going to be a legal challange more than anything else, especially if they leave out support for older technologies. Most of MS's newer APIs are well documented, so replicating them shouldn't be terribly hard. However, if MS manages to stop them from using OLE/COM and DirectX (since they are closed APIs) then the project is useless. All the apps worth running on Windows use those two technologies. (I mean why do you think NT 4.x was a less than great seller in the consumer market? It's faster, more stable, but lacks good DirectX support.)
5) It's surprising they didn't mention WINE. Apparently they have replicated some Windows libraries, and that will undoubtadly help these guys. Also, the relative success of Wine is a good sign. It shows that applications aren't terribly dependant on the undocumented aspects of Windows, and that an OS replicating the API might work.
6) There's all kind of legal issues at work here.
A) MS might be forced to open up the Windows code/APIs. While this is years away, if it happens, it will coincide with the probably point of maturity for this project. Thus, any missed bits could be incorporated in.
B) MS might sue.
C) MS might play the "API of the day" game like it did with IBM. But they might be prevented from doing that by the DOJ.
7) The project sounds like a big task. However, I think the biggest mistake they can do is to replicate Windows 100%. The inclusion of FreeDOS in the projects listed page is a bad sign. This OS should NOT contain DOS/Win16 comptability. Most new applications don't use any of those outdated APIs, and it really isn't worth the effort, because things like DosEMU and Wabi exist. Also, native alternatives to older apps like that exist. If they go the track of 100% comptability, I'm afraid they might end up being simply an OSS version of Windows with worse comptability and comprable speed and efficiency.
I stand corrected. I read the article a long time ago, and somehow fractals got in there.
I posted this after I read the responses to my original post. I'm not out to "prove" anything. I've read a few articles on it awhile ago, and somehow fractals got mixed in with the memory. It was a mistake. I'm sorry. It happens to everybody. As for my comments about WIllamette, I did make some mistakes and had to revise my concept a little bit, however my overall point still stands. In consumer space, Willamette will be a beast. I was wrong about some aspects of it, (for example, I thought the clock doubling applied to the whole pipeline) but nobody has disproven my point. It seems that Intel is trying to take on NVIDIA in the geometry department. In doing so, they make a chip that performs geometry acceleration very well, but is a little weaker per-clock for other tasks. However, the high clock-speeds outweigh this disadvantage, and help greatly for matrix operations where Willmatte is really strong per clock (because the 20 stage pipeline really doesn't have a negative effect on something regular like matrix operations.) Additionally, Intel not only has the motive (geometry accelerators make them less relevant in the all important games market) but the concept makes sense. If Willamette is weaker per clock than K7, but at a higher clock-speed, it's performance should match most of the time. However, the high-clock speed really helps matrix operations, where Willamette doesn't have a per-clock disadvantage. Also, I said that AMD needs to do something to counteract Willamette. AMD doesn't HAVE anything to counteract Willamette. Not only is the next chip (Mustang) not aimed at all at the consumer market, but AMD's chip after that (K8, Sledgehammer) is aimed at competing in server space. Additionally, it appears (if you read the articles recently on ZDNet and CNET) that Intel may be lowering the market they're aiming at with Willamette. If that's the case, then AMD has nothing to counter that. There you go, a summery of the entire thread. Where's the "total bullshit?" Prove me wrong here somewhere, then maybe you've got a point.
Wavelet compression has already been used to compress images. It does this by finding a fractal pattern or something like that. I've actually run the demo that compresses video using wavlets. Its a small animation of a girl brushing her hair, (I think, I don't remember it exactly.) Also, there is a site that contains pictures compressing stuff like a picture of a glass of wine, a cow, etc.
I know this article specifically refers to using wavelets for compressing 3D, but it should be able to be used for video. FYI, wavlet compression is a method that uses fractals to compress an image. If you've seen the wavelet demos, you know just how much better than JPEG wavlet compression looks. Using the same process, it is also possible to compress a sequence of frames as in a video. This is demonstrated in some of the wavlet demos floating around the net. Right now they're in black and white, and are pretty small, but it is conceivable that they'll get better. A big problem with wavelet compression is the CPU cost. Even single images can take a second or two to decompress. However, that can probably be offset by hardware decompression mechanisms, and it doesn't seem that they're will be a shortage of CPU power anytime soon. If you've ever seen how well wavelet lets you compress images 50:1 with so little quality degredation, you'll understand what an impact this method could have on computer video.
As anybody who has ever seen the stependous quality of high-res wavelet images knows, this compression is pretty amazing. Although there are probably other, more legitimate I might add, uses for this, the first thing that comes to mind is porn videos. Seriously! The adult market is one of the only internet ventures making money, and this new compression just helps out the US ecomony some more. (Not to mention the fact, that if wavelet compression allows streaming quality comparable to DVD, then you can cancel your subscription to the Spice channel ;)
Well, fun for whom? It seems to me, that if Linux is going to make it mainstream (as so many people want it to) then the developers have to make some concessions. Personally, I would rather design an application that makes the user happy than have some extra freedom about what toolkit to choose. Maybe it's just me, but a better end product is a lot cooler than the philosophy behind the product.
Binary standard in the sense of Windows OpenGL libraries. You can drop in any ICD (which is basically an implementation of OpenGL) and it will work no matter how the ICD is programmed. There isn't a big difference between GNOME and KDE in terms of what they do. If they used the same API and applications were binary compatible (ie. You could run KDE apps on GNOME without installing compatibility libraries) and integrated into each environment (an application would look "at home" in either GNOME or KDE because they would rely on services from the underlying toolkit) then the user could choose what environment to run without having to consider if they apps they want to run support it. In the current situation, the environment to run is largely supported by what apps one uses. It should be entirely about which environment the user likes better. The same thing exists in Windows to some degree. You can replace explorer with Litestep and get a different window mangager. However, all applications remain compatible. This is simply an extension of that concept.
That's not my point at all. There's nothing wrong with wanting something for free (I know I do!) My point is twofold
A) He said it is "commerical payware." Just the tone of that sounds like some guy who says, "I'm not going to use ". As if this is in any way on the same level as that.
B) I understand that people wnat a free alternative if they can't afford it, they're nothing wrong with that. In fact, the main thing I admire about the OSS community (and probably the ONLY thing I admire) is that they're willing to shut up an code something if the products on the market aren't satisfactory. However, the way that previous poster worded his post, I got the impression that he wasn't going to use it because it wasn't free, and actually expected to find an OpenSource application that come anywhere close. I don't know, just the TONE pissed me off. As for your animation package, good luck. However if you produce anything close to Animo, I suggest you find a way to sell it!
Actually, over the years, MaximumPC's editors have suggested all manners of ways to punish vendors who ship with DMA off. I think one involved a ferret and a wet noodle...
Of course, VIA chipset's also required an upgrade to the kernel as I remember, Not MS's fault that VIA chipsets tend to be flaky. Even still, download drivers, or recompile kernel. I can probably choose which one I want to do on a rainy day ;)
I'm not sure I'd agree about a MS forcing everyone to use MFC producing a 'better' library,
;) That's GIMP, KDevelop, Netscape, and Corel WordPerfect. On Windows the equivilent apps have a lot of integration. On Linux there totally seperate entities.
but it certainly helps produce more of them (both better and worse). After all, by that logic
we should all just use WinXX since that has one standard API and all these apps already.
Personally I'm looking forward to the day when I can use my Win95 CD as a coaster next to
my AOL CD (unfortunately I still need Windows for work).
>>>>>>
I said better library of APPLICATIONS. MFC is pretty crappy, and I refuse to touch it with a 10 foot pole. However, both GTK and Qt are very good, and there is little need for both. Either way, what I said is that MFC has lead to a great library of applications on Windows. Because of their use of a common library, they all have extremely powerful drag and drop capabilities, are very interoperable, and Windows apps in general tend to have a pretty consistant UI. The common library really allows Windows to be a much more cohesive entity. For example, in most programs, right click support is implemented quite extensivly. The big reason is that MFC provides functionality to ease implementing right click support. Also, MFC exposes a very powerful clipboard API. This allows applications to interoperate very well. By MS decreeing that everybody use MFC, (which is basically a wrapper for Win32 and thus offers the same features) focus shifted away from the toolkit to creating applications that take FULL advantage of the toolkit.
Incidentally, isn't there the OWL framework that Borland was pushing as an alternative to
MFC? Wether people used it or not, it was still there and it was still an alternative, and
one that some people used.
>>>>>>>
Yea, but it was killed by Microsoft's influence on everybody using MFC. It was an alternative, but not in the same sense Qt and GTK are. There's no central power forcing people to use GTK or Qt.
There is more then enough room for both KDE and Gnome... provided we develop some
standards so that applications written for either can be run by either, and run mostly (not
neccessarily 'entirely' although that would be nice) the same.
>>>>>>>
That's my point. It is POSSIBLE (though it takes planning and thinking, and it seems to me that OSS developers would much rather just code than plan) to have completely seperate DEs that are binary compatible. There's nothing wrong with that. That doesn't cause any fragmentation, leads to competition and better choices, etc. In fact, it leads to even MORE choice. Instead of the application designer choosing what DE the user runs, the USER can decide that. It also reduces bloat and allows developers to take better advantage of the FULL API of the DE.
I think they do that already, and the penalty of loading an extra set of libraries is not that
much nowadays. Diversity is a good thing, and one that is most likely not going to
disapear soon, since even if one side grabs the developers (and in my opinion, people
usually go where the most apps they can use is... all else being equal), the other is doing it
because they want to.
>>>>>>>
The overhead IS significant. On my 128MB system, the overhead of going from KDE 1.1.2 to KDE +GNOME means a 20MB jump in memory. That's 20MB less I can use for GIMP to load a large graphic. It causes my Linux environment to be MORE bloated than NT. Not only that, but it causes two other things.
A) The consitancy of the desktop is shot,
B) Major application designers tend to use NEITHER interface because they don't want to block out either user. In the end, they go back to using straight X + Motif. Compared to Windows, the average Linux system might as well not have a DE at all, since that's what incompatible DEs lead to. I mean the integration at the KDE-only level is great, easily competitive to Windows. However, Linux as a whole doesn't compare well to Windows simply because none of the good applications use the integrated metaphor. Look at the killer apps on Linux. For a lot of users (namely me
My point is that there's a better way to do it. It's probably too late with all the steam KDE and GNOME have gathered, but there's still a better way.
PS> In the current model, users don't choose the DE they use, application developers do. It shouldn't be that way. Just as there are standards that allow you to choose to use a NVIDIA graphics card instead of an ATI, there should be standards taht allow you to use GNOME instead of KDE without the consequences of a reduced experience. However, that goes too much into dictating policy, which UNIX developers are loathe to do. I was reading Miguil's comments, and it hit me. SOMEBODY has to implement policy, or the system has no policy!
I have to nitpick on your point. A major problem that Linux is going to have is to have the coders get over themselves and write applications for USERS. One toolkit results in less bloat and a more consistant library of applications. All that makes for a better user experience because user's don't care about the toolkit powering something. In these cases, the quality of the product for the consumer is probably more important than the developer freedom of choice. I'm sure most people don't want to use MFC, but face it, MS making everyone use MFC really DOES result in a better library of apps and a better UI.
Not having a C binding isn't as big a problem as it may seem. Most C coders can fairly easily learn C++, because Qt doesn't use any of the eostoric features of C++. Basically, they use C++ for virtual functions (not really any understanding needed on the developer's part) and C with classes.
A) This is clearly a troll, why did it get modded up?
B) Why the hell does it say Score:0 when I'm in the post editor, but Score:2 in the actual thread?
C) Qt is faster and easier to program.
D) A QT2GTK wrapper would be very slow.
Yes ludicrous concept. The problem is that diversity is useless without standards. If KDE and GNOME were 100% binary compatible, I'd have NO problem with having 2 (or 200) of them. That was the situation before that days of KDE when you only had Window managers. They were all different, all had some nifty features, and all ran all the X11 applications. THAT was GOOD choice bloat because no matter what you chose, you could run all the apps. However, the situation now is BAD choice bloat. KDE/Linux and GNOME/Linux are 2 different operating systems as far as the application is concerned. Without a binary standard to unify them, you end up with the current situation where a lot of users have to have both installed. That's unacceptable, because both GNOME and KDE continue to grow, and continue to subsribe to the emacs "I AM an operating system" concept. Now, Linux is easily 2 or 3 times more bloated than it should be. If this keeps up, "speed, efficiency and elegance" will no longer be one of the advantages Linux has over Windows. If there was a binary standard, then great. But by decreeing that "We must have many choices!" and sticking to it despite the "real world" problems that come with diversity without a standard, you're sticking to ideology instead of pragmatism. And when you can't accept another concept because of ideology, you're guarenteed a crappy product.
Diversity and competition drives innovation, but so does STANDARDS! I could care less if there were two different systems as long as the two were binary compatible! However, in its current state, I've got to put up with GTK+ applications in my KDE desktop (or vice versa) and have to live with 3 *VERY* large libraries in memory at the *SAME* time. Diversity and competition is useless unless there's a way for a person to pick one without having to run them ALL. And exactly what is having to DE's accomplished so far? They're both pretty much the same in features and usability. (though KDE has an edge in speed and stability.) Is there any SANE reason to have to different object models? You can't apply the same concept to everything. Diversity and competition may drive innovation in some places, but in a lot of places, it simply leads to a crappier product. Take the army for example. If you had each person competing with each other, you'd have a crappy army. By having 2 desktop environments, you've got two DEs that are very similar, and a very pissed off user complaining that he needs more RAM to run the damn thing. Microsoft is enough competition for Linux in the short term. Look at what KDE's development has consisted of so far? Take Microsoft features, copy it, improve it, and add it to KDE. So has GNOME's. If you ask me, there's not a lot of innovation going on.
Or, you could thing of legacy as any theme that existed before KDE2? KDE2's theme engine is the latest one availabe. Thus, anything BEFORE it can be considered legacy. When something support a legacy something else, it usually means that that somethign supports a body of somethings that aren't native, but already in existance. Thus, KDE2 supporting legacy themes means it doesn't support these natively, but since a large body of these themes exist, they're making special provisions to support these older themes. Plus, the air between GNOME and KDE is generally full of cooperation and friendship, so why would they do something like that? It seems to me that they weren't really expecting some people to read so much into this and got lazy in their wording. (Legacy Theme Importer as opposed to the Legacy and GTK+ theme importer!)
That's not what "not mission critical" means. Not mission critical means that it is okay if you have to do a reboot and the server is down for 10 minutes. It means that you don't have to have a redundent cluster to make sure that if one goes down you don't need to take the database ofline. Losing an entire 30GB database and having to reload it is unacceptable under any circumstances. Treating it mission critical usually means cost takes a back seat to having 100% uptime. I don't think that's what he needs.
I know, I'm spooling up my printer right now. I posted this, then I looked down the posts, and somebody asked that if the WildCat driver will use DRI or not... But my point about support from other vendors still stands (although is weakened due to the fact that WildCat is the highest performing part and will probably lead to the other supporting it.)
Photoshop is an application. Bind is not really an application, but a system service. In more traditional OSs, stuff like bind and other system services (directory management, ftp servers, etc) come with the OS, and are supported by the OS vendor. If bind on your Solaris box has a problem, (assuming its the bundled bind) then Sun HAS to support it since its THEIR application (and in this case THEY wrote it.) However, in Linux, the writers of these low level system services aren't the distro company, but some independant author. In that case, the distribution manufactuer has to support that piece, because even though they didn't write it, people are used to getting support on things seen as part of the OS distribution from the OS distributer. Linux comes with a lot of software, and I'm not saying that they should support it all. However, most people can figure out that GIMP isn't a part of the system, and go towards the appropriate support. But stuff like bind, gcc, ftp and telnet daemons, sendmail, etc, that are usually supported in the case of other OSs, (for example Microsoft supports problems in IIS, or Sun support problems with their ftp daemon) should be supported by the distro maker.
Oh, I were under the impression that Softimage contained a lot of OpenGL code that was really old and maybe not standards complient. I'm pretty sure there's no IrisGL code in there, because SoftImage's main platform was WindowsNT for awhile (and actually still is.)
That helps to a degree, but guess what, OpenGL accelerators are much more homogeneous than Linux distributions, standards guides or not. And from a company that certifies specific OpenGL accelerators to use, I'm not sure that that document is going to change their stance on supporting multiple distributions.
You know it just hit me.
How does one turn on DMA in Linux?
"Compile the right chipset into the kernel, then play with hdparm."
How does one turn on DMA in Windows?
"Click on the DMA enabled checkbox in device manager."
This compared to the Linux crowd whose benchmarks are, "oh, I just installed this and have only used Windows before and Linux is the fastest thing I've ever seen," or "on my 386 33 with 4 MB of RAM, Linux absolutely BLOWS AWAY Windows 2000" or my favorite "I've been using Linux ever since kernel .9 and its so fast! I mean, I played around with the Win2K alpha release, and Linux is SO much faster. What WM am I using? I don't run X, what a silly question! What do you MEAN that my comparison is invalid?"