Relevance is not "HotTopics" but what people actually use, and a change in which effects the general computing arena. Right now, Linux is relevant. Changes and happenings in Linux affect the entire computing sector. Windows is relevent. A change in Windows effects hundreds of millions of people. OpenGL is relevant. Numerous games use it and changes to it affect a lot of the gaming market. Direct3D is relevant. 3D graphics card companies live and die by their D3D drivers. GNOME is relevant, KDE is relvant. If the entire GNOME project suddenly drops off the map, IBM, HP, and the entire linux community has to deal with it. Similarly KDE. In these cases, KDE and GNOME are relevant not because they directly have an impact on the majority of computer users, but because their sucess or failures affect the sucess or failures of Linux, which affects Windows, which directly effects the user. Things that aren't relevant are things that really don't affect the majority of computer users, or don't have any future.
OS/2, for example, is irrelevant. If IBM drops OS/2 right now, only a handful of people will be affected. QuickDraw3D is irrelvant since it has no future. One can make an OS now that has no QuickDraw3D. The same cannot be said for something relevant like OpenGL. Even major players like IBM's POWER3 are irrelvant largely because their sucess or failure doesn't (even indirectly) effect the general computing public. A common theme here is that things that are relevant are NOT just fads. Windows is relevant, and has been for years, and it will be for years. Similarly, Linux will be relevant for years, as will OpenGL, Direct3D, et al.
Relvance is a topic that depends on target market. However, that target market vaires widely in size. If one is talking about the high end computing market, then POWER3 is suddenly relevant. A better example is OS/2. The comuting market as a whole considers OS/2 largely irrelevant. However, get into banking and ATMs, and OS/2 suddenly becomes relevant. In a converstation, relevance is relative to the topic of the conversation. In this conversation, the topic is GNOME. Thus, the target audiance is those people that use GNOME. Thus, relevance is judged by what is relevant or irrelvent to the majority of those people. What is GNOME's target audiance? People switching from Windows, people needing a good looking desktop, and people who need a broad range of software. To these people, GNUStep is largely irrelevant. If GNUStep falls off the face of the planet tomarrow, it wouldn't affect the majority of GNOME users.
You miss my point entirely when talking about the unfication of GNOME and KDE. I'm saying that they should use a common API. This has nothing to do with their user-interfaces, it has nothing to do the actual code powering those APIs, it has nothing to do with developers (they aren't the target market of GNOME/KDE anyway.) We're not talking about the usual UNIX contingent here. The article was about GNOME, and due to GNOME's support from HP and IBM as the next CDE, business users (for whom you say appearance and profitability come first) are EXACTLY those users who we're talking about. It just happens that the same concepts apply to home users as well, and together, home and business users for the majority of KDE/GNOME target audiance. For them, my arguement applies. Either KDE or GNOME will win, and the other will become irrelevant. Even if the other becomes very relevant in the Phython-developers segment, it won't be relevant to the business/consumer segment as a whole. A unified API prevents that kind of fall into irrelevance.
I might seem like I'm using a lot of generalizations, and groupings, and compartmentalizations here. But ask any marketing person, they'll tell you that it WORKS! No matter how individualistic a particular person is, a segment as a whole is very uniform and predictable.
I never said that GNUStep was dead. My point is that it's not RELEVANT. People work on OS/2 software as well, but it doesn't mean it's relevant. I'll even go on a limb and say that in it's present state, BeOS isn't really relevant either. With less than a million users, it is of no signficance. That doesn't mean that people aren't perfectly happy using it, or that people don't activly develop for it. It just means that what goes on in it's development doesn't really have a significance to the computing community as a whole. (In BeOSs defense, it's popularity seems to be increasing, it is still on the upswing. In contrast, it seems that GNUStep is kind of trudging along.) Until recently Linux was "dead" so to speak. Sure some people used it, but it was only recently that the computing community as a whole cared about what happened to it. That is the case with GNOME and KDE. If one "wins" (as one undoubtedly will) there will still be people using the other. There will still be development going on for the other. However, the majority of compter users will find that the number, variaty, and quality of apps on that environment do not suit their needs. That's why a common API is so important. if there is acommon API, it ensures that both stay RELEVANT, not just alive.
Actually you make a very good point. Connecting power with difficulty of use is a work of laziness. A great example is Alias's Maya. The interface is fairly easy to use, given the sheer power of the program. If you're a novice just learning it (okay, novices don't use Maya, but bear with me) then you've got buttons, etc. There all logically laid out, and that's something helpful to novices and the "elite" alike. However, if you fell at anypoint constrained by the GUI, you can always write your own components in the form of MEL scripts. At that point, you've got an interface that is easy enough for a beginner to use proficantly, but one that even an expert can lose himself in (feature-wise, not GUI-wise).
They don't have to use the same component model or same widget set. What the need to use is the same API. Then what would matter would be the back end. Which one was faster, which one had the better GUI, which one took less memory, which one was more robust, etc. That's what peopl need to compete on. Competing on features is a sure way to disaster. It leads to bloat, which is bad. Think hard. Do you need multiple component models, or multiple widget sets? Is KDE appreciable different from GNOME as it is? As I've said, they both have the same featuers and expose them in more or less the same way. Given those circumstances, why not let them be programmed the same way? They could take a cue from Microsoft's DirectPlay. You've got a common API for communication, and you can use whatever underlying method (TCP/IP, IPX/SPX, etc) that you want. Or from OpenGL drivers. They all have a common API, but you can't possibly say that Matrox's is anywhere near as usable as NVIDIA's. In that case, they are competing on quality, which results in a better product. Take another cue from MS. MS tries to compete by incorperating new features in every release. Without a common API, it becomes much easier to compete on features than on quality. Look where it led MS? To the lovely, bloated beast that is Win2K, and the horrid convultated API that is Win32.
Do you expect GNUStep to make a comeback anyday now? OSS projects may not die, but being totally irrelevant is about as bad as being dead as far as most people are concerned. (Example: OS/2) Eventually, sheer software support is god, and affects both OSS and non-OSS projects. If the two use a common API, then yes, KDE and GNOME will both stay alive and force the other to improve. However, that would mean reducing the number of toolkits, and the UNIX nerds with their passion for multiple-redundant toolkits would NEVER agree to that.
Whoa! Do you really want software creating the interfaces? Don't you think programmers should have some accountability? It is remnicscant of the horrid "code generators" Windows programmers are so fond of, yet everyone else hates. Of course if it's in KDE, it's got to be cool!
A) Given two choices, there is always competition. It happens in everything from computing, to religion, to sandwiches. Live with it.
B) Competition is good. However, there is a difference between competition and infighting. The current situation here between GNOME and KDE is infighting, not healthy competition. The problem is that they aren't binary compatible. You suggest to stop fighting and write code. For which DE? If KDE and GNOME want to make a better product, they have to adopt a common API, and let the competition be in terms of features, quality, stability, speed, usability, and all that good stuff, instead of on which environment has more software support.
C) A common API guarentees that they will both stay "alive." People seem to have this notion that OSS projects can't die. That may be true, but they sure as hell can become totally irrelevant. No offence to the GNUStep guys, but can you consider that project "alive?" A common API can do wonders for an OSS project. The reason GNUStep is more or less irrelevant is because there really isn't any software. Since an OSS app can't really "die" per se, a common API guarentees that no matter how much more popular one DE becomes, others can always overhual there's and make a comeback. In the end, the user benifets because they use whatever product they feel is best without bloating up their system, and without being enslaved to the wishes of software developers.
In the current state of things, one DE will undoubtedly win. That's the dynamics of proprietory APIs. Do you really think OS/2 would be totally irrelevant if it was Windows95 ABI compatible? On the flip-side, do you think NetBSD or OpenBSD would be used by anyone if it wasn't UNIX-API compatible?
Actually, I think StormLinux and Corel linux already have them. The problem is that even they detect cards incorrectly. For example, Mandrake says I've got a Riva128 isntead of a TNT. They're not even the same ARCHITECTURE!
Price is not totally revelvant. In fact, a 600MHz 64MB Dell computer with RedHat is actually MORE expensive than a similarly configured one with Win2k. Even for machines where Linux IS cheaper, for most businesses, the extra $50-100 really isn't a big factor in the overall cost of the system. It certainly won't beat any advantages in usability or software that Windows has. Linux really can't compete in price, because the bulk of the cost still lies in support contracts. Thus it HAS to compete on technical quality, usability, and software availability.
Nobody ever suggested using it for serious database chores. However, having basic database capabilities in the OS makes all sorts of cools thing possible. The catalouging of MP3s, the organization of "people" records, etc. That's the only type of database that it makes sense to integrate into the file system of a genral purpose OS. As for the old filesystem, back then the bfs WAS a database, but it was changed due to performance concerns.
If a diverse number of applications require it, yes. What you don't seem to get is that if there are 5 different toolkits that each implement major, but redundant services, and the available body of applications uses each of the toolkits equally, then you HAVE to have them installed. For example, it is pretty hard to avoid having KDE or GNOME installed because there are several great applications (KOffice or KDevelop) that require it. I'm sure you agree that several redundant toolkits lead to bloat, and if people actually take advantage of those toolkits, it no longer becomes a mattar of what YOU want, but what the application programmer decided you need.
Actually your missing an obvious point. Client/server relationships make it much easier to asynchronos calls. Fill a buffer, send it off the the graphics card and get on with our processing. Since most calls are hardware accelerated, client-server architectures make it much easier to exploit the parallel processing characteristics of modern systems. Also, in cases like OpenGL, having a client/server model allows the server to reorganize the input data. Since a state change often lowers performance more than the additional processing, a client/server model turns out to be faster.
I'm not using Mandrake. I'm using Slackware. Sound is not really a big deal using OSS either, but why settle for a sub-standard sound system? Of course, there is a trade-off. If I use mandrake, I have more problems networking since it doesn't detect my two ethernet cards correctly. Of course, the NVIDIA drivers SHOULD take 5 minutes, but it doesn't. First of all, it's not really a good idea to install the older Mesa RPMS over XFree86 4.0. However, Mesa is necessary because XFree4.0 by default doesn't come with libGLUT and libGLU. So I've got to get the Mesa3.3 RPMS (it seems that Mesa3.3 only exists in RPM and source) turn them into GZs and install them. Then, I've got to go through the ridiculous motion of deleting the XFree GL libraries. Then, I can't install the kernel driver because kernel 2.4-test6 and up broke the NVIDIA drivers. Sure I tweek my system, but I tweek NT as well. It never takes this long. If you want to live with a stock system, then okay, it doesn't take that long to install. But why live with a stock system? Installing isn't terribly hard if you're willing to live with less than perfect results. Configuring anything non-trival is the hard part.
BTW> The stock kernel on RedHat 6.1 is NOTICIBLY slower than a custom kernel.
A) The memory usage I'm talking about is real memory usage. I discounted file-buffers in both cases.
B) The Linux+KDE Beta +GNOME=WinNT point IS valid. I think you agree that the base components are equal in both cases. The only services running on both are NAT, and I made sure to compile a custom, modular kernel with only the necessary items. (The kernel weighs in at 550K) I even made sure to not load PPP and SLIP since I'm using DSL not dialup.
The KDE Beta2 is needed because it is currently the only environment that can use embeding and component technologies throughout the system. Since these services are built into WindowsNT (in the form of OLE and COM) they are necessary. Comparing NT to a lighter weight environment like FVWM or even plain Enlightenment wouldn't be fair as NT would have many more features. Since KDE 1.2 doesn't offer KParts, and GNOME 1.2's component services aren't totally complete, KDE2 Beta was the only choice. Given the fact that KDE2 is in very late beta, I think it is an appropriate choice. (Actually, KDE is needed for another reason. KDevelop won't run without it.) Now GNOME. GNOME is necessary, because there are several important applications that require GNOME. In NT you can neglect OWL, Qt, and Cygwin because no important applications use them. You can run 99% of all apps without them. The situation, however is different in Linux. Since GNOME has more than 50% of all the important "DE aware" applications, it has to be a part of the comparison. You might think it is unfair because of the duplicated code, but those are the realities of two incompatible DEs. (BTW I didn't count Mozilla in the mix. I can't stand Active Desktop. That gives Linux an advantage because IE takes less memory than Mozilla or Netscape.) Under these circumstances, Linux takes up more memory than WindowsNT 4.0.
Your assumptions are wrong? Why the hell would I compare a tuned desktop to and untuned one? (Why would I use Slackware if I had an untuned system?) The only things running in the background are the things I can't kill. I don't even run atd. As for running two desktops, that is to represent the fact that you HAVE to run both or else not be able to run all the applications. (BTW, the NT machine actually has more services running, though I've got NAT on both, NT is acting an ftp server for my network, and also has some rpc services that I don't start in Linux)
As for NT not using memory, qualify THAT! And your concept of memory use is twisted. The SYSTEM should NOT use memory just because it's there. The system should leave as much memory as possible for the APPLICATIONS. I could care less if GNOME didn't exist, I'm running the applications not the DE.
XF86 is far from being a problem. However, the fact that I have to edit the (largely undocumented from an ALSA point of view)/etc/modules.conf file to install my soundcard, or give the bloody thing a IRQ (it's plug and play hardware for god's sake!) is what pisses me off. Or the fact that the kernel breaks the NVIDIA drivers every few days. Or the fact that it isn't documented whether or not you should turn on ISAPNP in ALSA if you've already got it in the kernel. How about the fact that KDE2 not only doesn't have Slack packages (the latest ones are 1.91) but has a compile system where I've got to cd into a dozen directories, and wait half and hour for each one to compile. THAT'S what pisses me off.
BTW> Slackware kicks ass. Getting networking and NAT configured in a few mintutes was awesome. I never did like SysV scripts.
Wow, good for you. What kind of machine are you running where it takes less than half an hour to compile X 4.0? How do you configure and recompile the kernel in less than half an hour? (Or do you actually use the stock kernel! Did you every look at how much bigger it is!) How long does it take you to fuss with the NVIDIA drivers? How did you get ALSA installed in 30 minutes? Sure I can install Linux in less than half an hour, but how long does it take to CONFIGURE the thing as a USABLE desktop system. Windows NT, from inserting the disk, to NAT server takes an hour or so, including time to tune everything. Linux takes a LOT more than that.
Actually, for a desktop OS the integration between the CLI and the GUI is fantastic. If your using it as a desktop system, you've nearly everything you do in Linux. As for multi-user, in a desktop OS really isn't necessary. As for ftpd, check/boot/home/config/settings/network. If you want graphical configuration, grab the X server and go for it! You've got a lot of standard config stuff in/etc, or mostly text-readable ones in/boot/home/config/settings.
1. The Windows 9x GDI contains a lot of assembly code, including some 16-bit code which runs in
virtual 8086 mode. In this mode, there is no distinction between user and kernel mode (or ring 3 and
ring 0 in Intel-speak), because this functionality didn't exist until the 386, and the Windows 9x GDI
has never been a client/server architecture, so talk of 'moving GDI into the kernel' on Windows 9x is
complete and utter nonsense.
>>>>>>>>>
I've been duely chastised. However, I do have to point out that during Window 95's release, more of the GDI (which is almost all 16 bit) was rewritten in assembly. This was a major selling point of Win95 against NT. As for being in the kernel, the Windows 95 architecture is so confusing it might was well be. This is how I understand it, correct me if I'm wrong. Most of Windows consists of a set of DLLs (including the GDI) that are mapped into the address space of the application. I consider anything in these DLLs to be more or less in the kernel. However, a call into the GDI causes it to switch to the Win16 VM which runs it in V8086 mode. My question is this. Isn't the Win16 VM running in protected mode? As I recall, the real mode version of Win 3.1 really didn't work very well.
2. The NT GDI was designed as a client/server architecture, and contains no 16-bit code whatsoever
(or thunking, except when 16-bit applications are run, and their 16-bit calls are thunked to 32-bit
Win32 APIs). On pre-4.0 versions of NT, when an application made a graphics API call, this would
invoke an LPC (local procedure call) into the CSRSS (Client/Server Runtime Subsytems) process,
which would then carry out the graphical work. With NT 4.0, the GDI was restructured, and more of
it was moved into kernel mode (the video drivers, of course, have always run in kernel mode, since
they require access to the hardware). The impact of this change is often exaggerated, ignoring the
simple fact that a CSRSS crash would bring down a pre-4.0 version of NT anyway. Similarly, an X
server crash on UNIX brings down all of the applications which were being run in the X session, and
often the system as well. In other words, the effect is largely the same. The exception would be
UNIX servers which are also used as interactive workstations, in which case an X crash might not
bring down all of the services which were running. Of course, using a system both interactively, and
as a critical server, is an extremely bad administrative decision.
>>>>>
I was never talking about NT. However, the moving of the GDI did have a large impact. Graphics performance improved quite a bit.
3. Client/server architectures for graphics will always be slow. The fundamental issues are:
(a) A client/server architecture requires several context switches for each call to the graphics system
(at least client -> kernel -> server -> kernel -> client, often more, since the server frequently has to
communicate with drivers running in kernel mode), where as a kernel-mode architecture requires
only two (client -> KM server -> client), and a kernel-mode server can communicate directly with
kernel-mode drivers without any context switching.
>>>>>
Not entirely true. For example, the BeOS uses a buffered graphics API. Graphics calls are batched and sent when the buffer is full. So the result is a context switch into the kernel to send the messages. When the graphics server is next scheduled, it will carry out those messages. BeOS uses a dual-mode graphics driver API. The majority of driver functions run in a user-space module loaded by the graphics server (called an accelerant.) The only time the server has to switch into kernel mode are to handle shared resources and do interrupt handling. Everything else (including primative acceleration) can be done through the user-mode module. In practice, this method is pretty damn fast.
Finally, the Windows GDI is not 'notoriously slow'. In fact, the excellent graphics performance
offered by Windows in the early/mid 1990s, based on the hardware acceleration of GDI routines, is
one of the things that attracted me to the platform (coming from UNIX and Macintosh, which still
used simple frame-buffer architectures). MacOS and XFree86 now take advantage of this GDI
acceleration to some extent (since many of their primitive routines are similar to, or the same as,
the GDI routines which the hardware implements), but Windows probably still has an edge in this
respect, since it's what the accelerators were and are designed for.
>>>>>>>>>>>
The GDI IS notoriasly slow. Coming from a game-programming POV, you'll notice that the use of the GDI is banned for everything except rendering text into bitmaps for later blitting. In fact, I've done some tests between the GDI and the BeOS graphics system and the BeOS graphics system tends to win.
Slashdot Mirror
Dare I say it... BeOS?
Well, that depends on the target audiance. If you're targetting be-fan groupies (I know you're out there) then I'm quite relevant ;)
Then apparently DOS is the ultimate render farm OS.
Relevance is not "HotTopics" but what people actually use, and a change in which effects the general computing arena. Right now, Linux is relevant. Changes and happenings in Linux affect the entire computing sector. Windows is relevent. A change in Windows effects hundreds of millions of people. OpenGL is relevant. Numerous games use it and changes to it affect a lot of the gaming market. Direct3D is relevant. 3D graphics card companies live and die by their D3D drivers. GNOME is relevant, KDE is relvant. If the entire GNOME project suddenly drops off the map, IBM, HP, and the entire linux community has to deal with it. Similarly KDE. In these cases, KDE and GNOME are relevant not because they directly have an impact on the majority of computer users, but because their sucess or failures affect the sucess or failures of Linux, which affects Windows, which directly effects the user. Things that aren't relevant are things that really don't affect the majority of computer users, or don't have any future.
OS/2, for example, is irrelevant. If IBM drops OS/2 right now, only a handful of people will be affected. QuickDraw3D is irrelvant since it has no future. One can make an OS now that has no QuickDraw3D. The same cannot be said for something relevant like OpenGL. Even major players like IBM's POWER3 are irrelvant largely because their sucess or failure doesn't (even indirectly) effect the general computing public. A common theme here is that things that are relevant are NOT just fads. Windows is relevant, and has been for years, and it will be for years. Similarly, Linux will be relevant for years, as will OpenGL, Direct3D, et al.
Relvance is a topic that depends on target market. However, that target market vaires widely in size. If one is talking about the high end computing market, then POWER3 is suddenly relevant. A better example is OS/2. The comuting market as a whole considers OS/2 largely irrelevant. However, get into banking and ATMs, and OS/2 suddenly becomes relevant. In a converstation, relevance is relative to the topic of the conversation. In this conversation, the topic is GNOME. Thus, the target audiance is those people that use GNOME. Thus, relevance is judged by what is relevant or irrelvent to the majority of those people. What is GNOME's target audiance? People switching from Windows, people needing a good looking desktop, and people who need a broad range of software. To these people, GNUStep is largely irrelevant. If GNUStep falls off the face of the planet tomarrow, it wouldn't affect the majority of GNOME users.
You miss my point entirely when talking about the unfication of GNOME and KDE. I'm saying that they should use a common API. This has nothing to do with their user-interfaces, it has nothing to do the actual code powering those APIs, it has nothing to do with developers (they aren't the target market of GNOME/KDE anyway.) We're not talking about the usual UNIX contingent here. The article was about GNOME, and due to GNOME's support from HP and IBM as the next CDE, business users (for whom you say appearance and profitability come first) are EXACTLY those users who we're talking about. It just happens that the same concepts apply to home users as well, and together, home and business users for the majority of KDE/GNOME target audiance. For them, my arguement applies. Either KDE or GNOME will win, and the other will become irrelevant. Even if the other becomes very relevant in the Phython-developers segment, it won't be relevant to the business/consumer segment as a whole. A unified API prevents that kind of fall into irrelevance.
I might seem like I'm using a lot of generalizations, and groupings, and compartmentalizations here. But ask any marketing person, they'll tell you that it WORKS! No matter how individualistic a particular person is, a segment as a whole is very uniform and predictable.
XFree86 4.0 gets rid of modlines and XF86Setup. One step forward, one step back.
I never said that GNUStep was dead. My point is that it's not RELEVANT. People work on OS/2 software as well, but it doesn't mean it's relevant. I'll even go on a limb and say that in it's present state, BeOS isn't really relevant either. With less than a million users, it is of no signficance. That doesn't mean that people aren't perfectly happy using it, or that people don't activly develop for it. It just means that what goes on in it's development doesn't really have a significance to the computing community as a whole. (In BeOSs defense, it's popularity seems to be increasing, it is still on the upswing. In contrast, it seems that GNUStep is kind of trudging along.) Until recently Linux was "dead" so to speak. Sure some people used it, but it was only recently that the computing community as a whole cared about what happened to it. That is the case with GNOME and KDE. If one "wins" (as one undoubtedly will) there will still be people using the other. There will still be development going on for the other. However, the majority of compter users will find that the number, variaty, and quality of apps on that environment do not suit their needs. That's why a common API is so important. if there is acommon API, it ensures that both stay RELEVANT, not just alive.
Actually you make a very good point. Connecting power with difficulty of use is a work of laziness. A great example is Alias's Maya. The interface is fairly easy to use, given the sheer power of the program. If you're a novice just learning it (okay, novices don't use Maya, but bear with me) then you've got buttons, etc. There all logically laid out, and that's something helpful to novices and the "elite" alike. However, if you fell at anypoint constrained by the GUI, you can always write your own components in the form of MEL scripts. At that point, you've got an interface that is easy enough for a beginner to use proficantly, but one that even an expert can lose himself in (feature-wise, not GUI-wise).
They don't have to use the same component model or same widget set. What the need to use is the same API. Then what would matter would be the back end. Which one was faster, which one had the better GUI, which one took less memory, which one was more robust, etc. That's what peopl need to compete on. Competing on features is a sure way to disaster. It leads to bloat, which is bad. Think hard. Do you need multiple component models, or multiple widget sets? Is KDE appreciable different from GNOME as it is? As I've said, they both have the same featuers and expose them in more or less the same way. Given those circumstances, why not let them be programmed the same way? They could take a cue from Microsoft's DirectPlay. You've got a common API for communication, and you can use whatever underlying method (TCP/IP, IPX/SPX, etc) that you want. Or from OpenGL drivers. They all have a common API, but you can't possibly say that Matrox's is anywhere near as usable as NVIDIA's. In that case, they are competing on quality, which results in a better product. Take another cue from MS. MS tries to compete by incorperating new features in every release. Without a common API, it becomes much easier to compete on features than on quality. Look where it led MS? To the lovely, bloated beast that is Win2K, and the horrid convultated API that is Win32.
Do you expect GNUStep to make a comeback anyday now? OSS projects may not die, but being totally irrelevant is about as bad as being dead as far as most people are concerned. (Example: OS/2) Eventually, sheer software support is god, and affects both OSS and non-OSS projects. If the two use a common API, then yes, KDE and GNOME will both stay alive and force the other to improve. However, that would mean reducing the number of toolkits, and the UNIX nerds with their passion for multiple-redundant toolkits would NEVER agree to that.
Whoa! Do you really want software creating the interfaces? Don't you think programmers should have some accountability? It is remnicscant of the horrid "code generators" Windows programmers are so fond of, yet everyone else hates. Of course if it's in KDE, it's got to be cool!
A) Given two choices, there is always competition. It happens in everything from computing, to religion, to sandwiches. Live with it.
B) Competition is good. However, there is a difference between competition and infighting. The current situation here between GNOME and KDE is infighting, not healthy competition. The problem is that they aren't binary compatible. You suggest to stop fighting and write code. For which DE? If KDE and GNOME want to make a better product, they have to adopt a common API, and let the competition be in terms of features, quality, stability, speed, usability, and all that good stuff, instead of on which environment has more software support.
C) A common API guarentees that they will both stay "alive." People seem to have this notion that OSS projects can't die. That may be true, but they sure as hell can become totally irrelevant. No offence to the GNUStep guys, but can you consider that project "alive?" A common API can do wonders for an OSS project. The reason GNUStep is more or less irrelevant is because there really isn't any software. Since an OSS app can't really "die" per se, a common API guarentees that no matter how much more popular one DE becomes, others can always overhual there's and make a comeback. In the end, the user benifets because they use whatever product they feel is best without bloating up their system, and without being enslaved to the wishes of software developers.
In the current state of things, one DE will undoubtedly win. That's the dynamics of proprietory APIs. Do you really think OS/2 would be totally irrelevant if it was Windows95 ABI compatible? On the flip-side, do you think NetBSD or OpenBSD would be used by anyone if it wasn't UNIX-API compatible?
Actually, I think StormLinux and Corel linux already have them. The problem is that even they detect cards incorrectly. For example, Mandrake says I've got a Riva128 isntead of a TNT. They're not even the same ARCHITECTURE!
Price is not totally revelvant. In fact, a 600MHz 64MB Dell computer with RedHat is actually MORE expensive than a similarly configured one with Win2k. Even for machines where Linux IS cheaper, for most businesses, the extra $50-100 really isn't a big factor in the overall cost of the system. It certainly won't beat any advantages in usability or software that Windows has. Linux really can't compete in price, because the bulk of the cost still lies in support contracts. Thus it HAS to compete on technical quality, usability, and software availability.
Nobody ever suggested using it for serious database chores. However, having basic database capabilities in the OS makes all sorts of cools thing possible. The catalouging of MP3s, the organization of "people" records, etc. That's the only type of database that it makes sense to integrate into the file system of a genral purpose OS. As for the old filesystem, back then the bfs WAS a database, but it was changed due to performance concerns.
Is it in the standard kernel? Obviously if it hasn't been integrated into the kernel, there are issues that prevent it from being integrated, no?
If a diverse number of applications require it, yes. What you don't seem to get is that if there are 5 different toolkits that each implement major, but redundant services, and the available body of applications uses each of the toolkits equally, then you HAVE to have them installed. For example, it is pretty hard to avoid having KDE or GNOME installed because there are several great applications (KOffice or KDevelop) that require it. I'm sure you agree that several redundant toolkits lead to bloat, and if people actually take advantage of those toolkits, it no longer becomes a mattar of what YOU want, but what the application programmer decided you need.
Actually your missing an obvious point. Client/server relationships make it much easier to asynchronos calls. Fill a buffer, send it off the the graphics card and get on with our processing. Since most calls are hardware accelerated, client-server architectures make it much easier to exploit the parallel processing characteristics of modern systems. Also, in cases like OpenGL, having a client/server model allows the server to reorganize the input data. Since a state change often lowers performance more than the additional processing, a client/server model turns out to be faster.
I'm not using Mandrake. I'm using Slackware. Sound is not really a big deal using OSS either, but why settle for a sub-standard sound system? Of course, there is a trade-off. If I use mandrake, I have more problems networking since it doesn't detect my two ethernet cards correctly. Of course, the NVIDIA drivers SHOULD take 5 minutes, but it doesn't. First of all, it's not really a good idea to install the older Mesa RPMS over XFree86 4.0. However, Mesa is necessary because XFree4.0 by default doesn't come with libGLUT and libGLU. So I've got to get the Mesa3.3 RPMS (it seems that Mesa3.3 only exists in RPM and source) turn them into GZs and install them. Then, I've got to go through the ridiculous motion of deleting the XFree GL libraries. Then, I can't install the kernel driver because kernel 2.4-test6 and up broke the NVIDIA drivers. Sure I tweek my system, but I tweek NT as well. It never takes this long. If you want to live with a stock system, then okay, it doesn't take that long to install. But why live with a stock system? Installing isn't terribly hard if you're willing to live with less than perfect results. Configuring anything non-trival is the hard part.
BTW> The stock kernel on RedHat 6.1 is NOTICIBLY slower than a custom kernel.
A) The memory usage I'm talking about is real memory usage. I discounted file-buffers in both cases.
B) The Linux+KDE Beta +GNOME=WinNT point IS valid. I think you agree that the base components are equal in both cases. The only services running on both are NAT, and I made sure to compile a custom, modular kernel with only the necessary items. (The kernel weighs in at 550K) I even made sure to not load PPP and SLIP since I'm using DSL not dialup.
The KDE Beta2 is needed because it is currently the only environment that can use embeding and component technologies throughout the system. Since these services are built into WindowsNT (in the form of OLE and COM) they are necessary. Comparing NT to a lighter weight environment like FVWM or even plain Enlightenment wouldn't be fair as NT would have many more features. Since KDE 1.2 doesn't offer KParts, and GNOME 1.2's component services aren't totally complete, KDE2 Beta was the only choice. Given the fact that KDE2 is in very late beta, I think it is an appropriate choice. (Actually, KDE is needed for another reason. KDevelop won't run without it.) Now GNOME. GNOME is necessary, because there are several important applications that require GNOME. In NT you can neglect OWL, Qt, and Cygwin because no important applications use them. You can run 99% of all apps without them. The situation, however is different in Linux. Since GNOME has more than 50% of all the important "DE aware" applications, it has to be a part of the comparison. You might think it is unfair because of the duplicated code, but those are the realities of two incompatible DEs. (BTW I didn't count Mozilla in the mix. I can't stand Active Desktop. That gives Linux an advantage because IE takes less memory than Mozilla or Netscape.) Under these circumstances, Linux takes up more memory than WindowsNT 4.0.
Your assumptions are wrong? Why the hell would I compare a tuned desktop to and untuned one? (Why would I use Slackware if I had an untuned system?) The only things running in the background are the things I can't kill. I don't even run atd. As for running two desktops, that is to represent the fact that you HAVE to run both or else not be able to run all the applications. (BTW, the NT machine actually has more services running, though I've got NAT on both, NT is acting an ftp server for my network, and also has some rpc services that I don't start in Linux)
As for NT not using memory, qualify THAT! And your concept of memory use is twisted. The SYSTEM should NOT use memory just because it's there. The system should leave as much memory as possible for the APPLICATIONS. I could care less if GNOME didn't exist, I'm running the applications not the DE.
XF86 is far from being a problem. However, the fact that I have to edit the (largely undocumented from an ALSA point of view) /etc/modules.conf file to install my soundcard, or give the bloody thing a IRQ (it's plug and play hardware for god's sake!) is what pisses me off. Or the fact that the kernel breaks the NVIDIA drivers every few days. Or the fact that it isn't documented whether or not you should turn on ISAPNP in ALSA if you've already got it in the kernel. How about the fact that KDE2 not only doesn't have Slack packages (the latest ones are 1.91) but has a compile system where I've got to cd into a dozen directories, and wait half and hour for each one to compile. THAT'S what pisses me off.
BTW> Slackware kicks ass. Getting networking and NAT configured in a few mintutes was awesome. I never did like SysV scripts.
Wow, good for you. What kind of machine are you running where it takes less than half an hour to compile X 4.0? How do you configure and recompile the kernel in less than half an hour? (Or do you actually use the stock kernel! Did you every look at how much bigger it is!) How long does it take you to fuss with the NVIDIA drivers? How did you get ALSA installed in 30 minutes? Sure I can install Linux in less than half an hour, but how long does it take to CONFIGURE the thing as a USABLE desktop system. Windows NT, from inserting the disk, to NAT server takes an hour or so, including time to tune everything. Linux takes a LOT more than that.
BTW> Can you script GUI apps through the bash prompt under Linux? Check out "hey."
Actually, for a desktop OS the integration between the CLI and the GUI is fantastic. If your using it as a desktop system, you've nearly everything you do in Linux. As for multi-user, in a desktop OS really isn't necessary. As for ftpd, check /boot/home/config/settings/network. If you want graphical configuration, grab the X server and go for it! You've got a lot of standard config stuff in /etc, or mostly text-readable ones in /boot/home/config/settings.
1. The Windows 9x GDI contains a lot of assembly code, including some 16-bit code which runs in
virtual 8086 mode. In this mode, there is no distinction between user and kernel mode (or ring 3 and
ring 0 in Intel-speak), because this functionality didn't exist until the 386, and the Windows 9x GDI
has never been a client/server architecture, so talk of 'moving GDI into the kernel' on Windows 9x is
complete and utter nonsense.
>>>>>>>>>
I've been duely chastised. However, I do have to point out that during Window 95's release, more of the GDI (which is almost all 16 bit) was rewritten in assembly. This was a major selling point of Win95 against NT. As for being in the kernel, the Windows 95 architecture is so confusing it might was well be. This is how I understand it, correct me if I'm wrong. Most of Windows consists of a set of DLLs (including the GDI) that are mapped into the address space of the application. I consider anything in these DLLs to be more or less in the kernel. However, a call into the GDI causes it to switch to the Win16 VM which runs it in V8086 mode. My question is this. Isn't the Win16 VM running in protected mode? As I recall, the real mode version of Win 3.1 really didn't work very well.
2. The NT GDI was designed as a client/server architecture, and contains no 16-bit code whatsoever
(or thunking, except when 16-bit applications are run, and their 16-bit calls are thunked to 32-bit
Win32 APIs). On pre-4.0 versions of NT, when an application made a graphics API call, this would
invoke an LPC (local procedure call) into the CSRSS (Client/Server Runtime Subsytems) process,
which would then carry out the graphical work. With NT 4.0, the GDI was restructured, and more of
it was moved into kernel mode (the video drivers, of course, have always run in kernel mode, since
they require access to the hardware). The impact of this change is often exaggerated, ignoring the
simple fact that a CSRSS crash would bring down a pre-4.0 version of NT anyway. Similarly, an X
server crash on UNIX brings down all of the applications which were being run in the X session, and
often the system as well. In other words, the effect is largely the same. The exception would be
UNIX servers which are also used as interactive workstations, in which case an X crash might not
bring down all of the services which were running. Of course, using a system both interactively, and
as a critical server, is an extremely bad administrative decision.
>>>>>
I was never talking about NT. However, the moving of the GDI did have a large impact. Graphics performance improved quite a bit.
3. Client/server architectures for graphics will always be slow. The fundamental issues are:
(a) A client/server architecture requires several context switches for each call to the graphics system
(at least client -> kernel -> server -> kernel -> client, often more, since the server frequently has to
communicate with drivers running in kernel mode), where as a kernel-mode architecture requires
only two (client -> KM server -> client), and a kernel-mode server can communicate directly with
kernel-mode drivers without any context switching.
>>>>>
Not entirely true. For example, the BeOS uses a buffered graphics API. Graphics calls are batched and sent when the buffer is full. So the result is a context switch into the kernel to send the messages. When the graphics server is next scheduled, it will carry out those messages. BeOS uses a dual-mode graphics driver API. The majority of driver functions run in a user-space module loaded by the graphics server (called an accelerant.) The only time the server has to switch into kernel mode are to handle shared resources and do interrupt handling. Everything else (including primative acceleration) can be done through the user-mode module. In practice, this method is pretty damn fast.
Finally, the Windows GDI is not 'notoriously slow'. In fact, the excellent graphics performance
offered by Windows in the early/mid 1990s, based on the hardware acceleration of GDI routines, is
one of the things that attracted me to the platform (coming from UNIX and Macintosh, which still
used simple frame-buffer architectures). MacOS and XFree86 now take advantage of this GDI
acceleration to some extent (since many of their primitive routines are similar to, or the same as,
the GDI routines which the hardware implements), but Windows probably still has an edge in this
respect, since it's what the accelerators were and are designed for.
>>>>>>>>>>>
The GDI IS notoriasly slow. Coming from a game-programming POV, you'll notice that the use of the GDI is banned for everything except rendering text into bitmaps for later blitting. In fact, I've done some tests between the GDI and the BeOS graphics system and the BeOS graphics system tends to win.