Commercial licenses for closed source software (which uses the library) are how Troll Tech makes money. Not from derivations of the library. >>>>>> Qt is a class library. People use it be deriving from it. Under legal pressure, your QMyapp:public QApplication could be considered a derived work.
Wrong. A GPL'd library would cover all GPL'd uses. You'd still have to pay for an exception to the GPL (like Reserfs, as I mentioned) if you wanted to develop a proprietary, closed source application and distribute it to someone else (internal apps could probably get away without paying). >>>>>>> Doesn't the GPL say that you cannot charge for the right to use to code? Isn't it impossible for Linus to use the GPL, except when it involves Microsoft? Isn't the QPL essentially the GPL with that exception?
That would cause the very problem you were just arguing against! That *would* allow commercial proprietary software to be built on Qt without paying the Trolls. >>>>>>>>> I'm pretty sure that LGPL is there for a reason. If the libraries were GPL'ed, then anything linking to them would would automatically become GPL. Hence to problem I mention lower. So if GPL won't work, and LGPL won't work, what's the problem with QPL?
>GPL'd QT would suck, since that would mean ALL Qt apps would have to be GPL'd.
OK, I'll grant that. Simple solution: Make Qt Free Edition dual licensed by the GPL *and* QPL. That would keep the BSD *and* GPL folks happy. And still charge for the commercial version. What more could you want? >>>>>>>>>> How 'bout it stays the way it is and the GPL folk shut up? They are the ones using QPL code inside GPL code. How, in anyway, does it involved the TrollTech people? Shouldn't KDE change its license to somethign other than the GPL?
Heh, not a bad idea. The GPL is, after all, the only good software license.:-) >>>>> I prefer BSD, but license wars are stupid. It should the entirely the author's choice, and all people who complain are just bitching.
Apparently, people don't seem to understand that MacOSX is not a UNIX from the developer sense. A modern MacOSX developer is sure to use the Cocoa API so that their apps appear to be like the other apps that MacOS X users will be used to. As such, their application still won't be portable to UNIX. I mean technically, it should be simple to port apps between BeOS and Linux, since they both use a POSIX base. However, a significant amount of code in a productivity app is user interface code that is tied to the UI system. Since MacOS X uses a different windowing system, even if the Office people use the BSD API for the port, it would still be hard to port to Linux/BSD/X.
What kind of question is that? Of COURSE x86 is obsolete. (Academically anyway). However, I really could care less if it is. It serves our purposes and we keep it around anyway. Academically, UNIX is obsolete too, better designs have already been made. Still, it work with the apps we have, it does its job decently, and that's why we continue to use it.
Sorry, my mistake. Gotta take the heat when I deserve it. Apparently Mandrake IS aimed at servers, (it says so on their webpage) I hereby retract any comments I made related to servers.
No it does not. I booted of the cd and ran the mandrake installer. I don't think the red hat installer is even included? Or are you talking about the text mode installer. In that case, get a new video card.
You're comments are pretty irrelevant. The reviewer says that he is talking about installes for less advanced systems, so yes, X is the only one that matters. You're probably not going to run Mandrake on a server. Second, the directory structure is the same. It has to be since the crappy RPM format has poor provisions for custom directory structures. The tools might be exportable, but seriously, does anybody care? Stuff like that isn't (and shouldn't) be included in a review. Most of the stuff you say (aside from the command line config tool) are pretty much irrelevant to a review. In fact, including it would be bad writing style. As for your comments about end users and "real" functionality, do I detect a sysadmin bias? 99% of the time, Mandrake users are going to be the end user. Thus the end user focus on the review. You don't balk when reviewers ignore server setup in Corel Linux, so why balk for Mandrake?
Fool. Either way, it means nothing if you aren't familiar with the program. Take xfm. X Friggin' Media? X Floppy Mangler? Xenophobic fruity man? Or pam, Pretty Anoying mercenary, probably angry mutent, possibly attacking molars? Or how about xmms. Xtremely mobile mutent snails? Xtremely mad magic sicophants? The point is that xfm means just as little as Konqueror, but Konqueror sounds nicer.
Blasphemy! You're not a real hacker are you? I like running the latest and the greatest (especially in the case of KDE 2, where it is faster than 1.x). To tell the truth, I am guilty of living VERY bleeding edge. I'm running Mandrake 7.1, kernel 2.4-test, XFree86 4.0, nVidia BetaGL, and I'm dabbling with KDE 2-beta1.
Wouldn't it be nice if this stuff were enapsulated through something like COM? DirectX has 7 very different versions, yet I only have one library, because incompatiblilites can be addressed at a very granular level. (IE. If only a few functions are different, but renders the entire library incompatible, through COM, you can reimplment only those functions in a new interface, and transparently call the old ones.)
No, not better than any distributed system. DCOM probably has lower performance over a network, but locally, it uses COM, and has a great deal more performance. So what happens is, that local performance performs like it should, at a slight expense at network performance and flexibility. I think this is a better trade off for something being integrated into a desktop environment, because the vast majority of apps will run locally. X had this same problem. It had great network performance, but crappy local performance. Fortunately the fixed most of it in 4.0, but there is no reason to start the problem again with a object model. MICO may be rock solid, and not that bad, but only in network mode. In local mode, MICO, and CORBA in general blows.
KDE is shaping up to be quite cool, and blessdly, you no longer have to run GNOME (which is quite a bit slower than KDE) to have a sweet looking desktop. KDE2's imaging and use of high color icons is really nice. However, it is still badly designed, as are all Linux DEs. To put it bluntly, KDE and GNOME simply are not compatible. If you want to run apps from both, (which is necessary if, like me, you like running GNOME but developed in KDevelop) then you have to have both installed. This gets worse, because during the KDE1/KDE2, GNOME1/GNOME2, you'll have to have all four installed to maintain decent compatibility. With just KDE and GNOME loaded, I get 40Meg resident memory use (according to KTop) on my 128 meg system. This is simply unacceptable. Even NT doesn't use that much memory from standstill (more like 30 megs or so) not to mention BeOS (some obscenely small number. Actually, BeOS is the only system that doesn't feel noticable faster in most apps after the upgrade from 64MB to 128MB.) Of course, I'm all for freedom of choice. Can you have your cake and eat it too? Of course! What about a DE that supplied low level stuff, like printing, object model, communication, API, stuff like that, and have a window manager take care of interface aspects and widget sets. This idea takes advantage of the fact that (from the big picture) all GUI software does the same things, and all widget sets provide the same services. So applications are written to the standard API, and whatever WM is loaded, interprets these requests. This would lead to even more customizability for the user (not the programmer, but who cares about he programmer?) All widgets are asked for the same services. So you could have a WM that implments the most efficiant GUI possible, while another one that implements a Windows-like GUI. In both cases, you'd have color dialoges that return an RGB value, so who cares how the dialogue acts. It could implment a standard color wheel, or it could ask the user for an RGB value, or it could randomly pick a number, the interface is the same. Not only would this desktop be more customizable, it would be faster, more stable, and less bloated, because it would have less code than two DEs and more people could be used hacking the core code. I mean you guys are all C programmers right? Ever heard of interface seperate from implementation? The idea at work here folks. Do you care about Bonobo and KParts? Sure. Do you have some insane attachment to one over the other? If so, get help.
This is so Kick ass. I'm a little angry that people don't give Konqueror more credit. It is truly one of KDE's crown jewels. Imagine the past: Here I am with my beautiful, reasonably fast Linux desktop, but right in the middle is the slow and bloated web browser from Motif hell. I've gotten so used to fast, light, nice looking browsers (IE on Windows, Netposetive on BeOS) that using Netscape positivly pained me.
I know this is a troll, but just so nobody gets misinformation. KParts is a lot more like COM than Bonobo. Bonobo is based on CORBA, which is quite different from COM. Back during the object model wars of '94 (its true, you guys think object models are new, but Linux is hideously late to this game) there were two competitors, SOM and COM. SOM was CORBA complient and support inheritance, while COM was a very different MS design, and supported aggregation. I prefer COM, because it is more light weight. CORBA, however is not. Don't you dare mention CORBA and COM in the same sentance 'kay?
Naw, GNOME is mostly fat, no meat whatsoever:) Look, I'm not a Linux newbie, but I simply like KDE better. I'm a speed freak, and KDE tends to be faster and take less memory. Also, I refuse to use a DE that has been tarnished by the bloated piece of shit that is CORBA.
That's bullshit. Why was this moderated up? GNOME and KDE don't help windows users move. In fact, up till recently, GNOME used E as the WM. What GNOME and KDE do, is provide a set of services to graphical applications using the GTK+ and Qt widget sets (respectivaly). (Stuff that should be in the OS proper, but that's a different matter:) Hell, you can use TWM and get as advanced as you want, but without stuff like KDE, no DCOP for you! Also, I get the hint that you think that stuff like integration, and consistancy are for newbies. Not true. They are for smart people who want to get work done without having to spend time learning a new interface.
That is stupid. Derived works are the WHOLE POINT OF A LIBRARY THAT YOU CHARGE FOR. Since nobody uses a widget set simply for the hell of it, derrived works is the only way for Troll Tech to make money. As of now, if you want to use Qt for a professional app, you have to pay. Troll tech can't do that if Qt is GPL'd. Also, even in that case, wouldn't LGPL be more appropriate? GPL'd QT would suck, since that would mean ALL Qt apps would have to be GPL'd. The whole concept is stupid. You're saying that if GPL'd code uses other code, that code atuomatically becomes GPL? Does that mean any BSD code put into Linux automatically becomes GPL? Why not just have a GPLizer program, that automatically incorporates code into GPL'd programs, thus GPL'ing the code!
I am slightly pissed that they reffered to KParts as an object model. An object model is something along the lines of COM and SOM, and simply define a method for easily upgradable, shared objects. When he refers to the fact that KParts handles stuff like where toolbars should go, he gets it wrong. An object model does not handle those thins, that is the work of a embedding system (don't know the jargon for it), along the lines of OLE or OpenDOC. In these cases, OLE and OpenDOC are the embedding system, and they use the object model (COM and SOM respectivaly) to facilitate the embedding.
The reason modprobe does didly for this, is because it only installs a module, not other files that are needed. In Linux, there are no symantics on how a driver should manage files that are not a part of the module itself. So different drivers use different methods for doing this. The reason nVidia's install is so hard is because they are in a peculiar position of having a custom ICD instead of using Mesa. Because of that, it has to replace the Mesa files with its own. The reason you're virge didn't have to do that it uses the standard OpenGL library and didn't have to replace the Mesa files. In Linux, the situation with a card like nVidia's is as such. XFree86 installed some OpenGL files. nVidia comes along and has no idea what files were installed because the system doesn't manage it. Rather than deleting all OpenGL stuff it finds, potentially causing a lot of problems, it requires the user to do it. Say now, that Linux has a Windows way of managing drivers. XFree86 installs. It then installs a Mesa driver as the default driver. This info is listed in a registry somewhere, so when nVidia comes along, it can just look in the registry, uninstall the driver, and put its own it its place. Its kind of like RPM for drivers. It wouldn't take a lot of work, really. XFree86 would have its own RPM, and the Mesa driver would have an RPM. When nVidia came along, it would uninstall the Mesa RPM, and install its own it its place, naming the file appopriatly so all links are still valid. The driver setup thing is irrelevant. If I could just type RPM -Ui nVidiaGL.rpm, I'd be a happy camper. Unfortunatly, Linux has no such system that will allow that.
know, there are a lot of things besides hardware drivers. I use Linux for Real Work (TM) for years, and I never had to upgrade hardware driver. >>>>> If you've never had to upgrade the hardware driver, then you are a dinosaur to say the least. Do you care at all for taking full advantage of your hardware?
That's because I don't need it to play with latest nVidia card, I need it to do real work - write programs. For this, two years old ATI/Matrox/ whatever is good enough, and Linux supposrt them like charm. If fact, I had much more problems with NT on drivers that with Linux. And definitley I'd give all latest 3D support for one good office app on Linux. >>>>> Well, that's you isn't it? Being a student, I don't get paid for my work, but I do real work too. I develop OpenGL programs. I mess around with graphics programs. I write graphics libraries. Key work here, "graphics." There is more to life than database engines and POSIX code. Are you saying that 3D modeling isn't real work? The Pixar guys will have your ass on a stick! Coming from someone who is statisfied with a moldy old Matrox card, what does your opinion matter to what I'm talking about? Home users upgrade reletivly often, gamers play a very large role in that market, and people install new types of hardware quite often. As a programmer who obviously doesn't do any graphics work, your experience has no relation to any of this.
Here is where we need real work to be done. 3D is for toys (or high-end CADing, which is another story) and office apps are for work. >>>>> Bull shit. Utter bullshit. Sit there happy with your database engines and your programs that calculate the amount of paper used in yearly tax forms. I can assure you that they guys who make these "toys" (ie. Carmack) have more programming knowledge than you ever had. I don't like being mean, but somebody with your attitude deserves it. No wonder everybody thinks that Linux users are hardcore sysadmins who wouldn't notice if somebody replaced their PC with an XT, long as the server was still up!
So, if you want to use cutting-enge 3D-graphics toys, you'd have to compile. But if you are using computer as a tool for work, as opposed to playing with lastest-and-greatest gadgets, best chances are you'll never need to upgrade. >>>>>>>>> A) I use computers for work. In fact, I am taking a graphics class which develops in OpenGL. Now let me tell you, running OpenGL on a Matrox is no fun. B) 3D graphics is not a toy. The gaming market currently makes billions of dollars a year and it is games that made PCs powerful enough that you sysadmins would not have to use Suns for everything. C) Okay, say you're a Photoshop guy. We've established that he does real work. (And gets paid quite well I might add.) You saying he can get by with an S3 graphics card?
As for not knowing too to handle ipchains, I'll tell you about one for free - gfcc. There are at least five more I tried, this came out as a winner. Too bad linux.com people don't know about it, but that's not Linux's fault. That's their fault - they don't know their tools, shame on them. >>>>>>>> Ah, but I can handle ipchains. Quite simple if you read the doc. However, I am not representative of an average user. For the average user, Linux.com IS the Linux help source. Them being wrong is like ZDNET being wrong. The entire PC industry gets heat when Windows is too hard, so why shouldn't the entire Linux community get heat for Linux being too hard? -- Si hoc legere scis nimium eruditionis habes.
I don't use ppp so sucks to be me doesn't it? (Actually it doesn't, I have a DSL connection and get a 40 millisecond ping to most quake servers.) Mandrake and Corel make some things easier, but only stuff that is trivial. Installing drivers is non-trivial, but something that is within the scope of many users. Also, you must not be running up to date hardware. As Linux becomes more popular, you'll have to get used to the constant driver updates as vendors make things more stable, faster, etc. (Not that they weren't stable to begin with. nVidia's uni-driver has been stable for years, but keeps getting better every release.) Linux will make you recompile you kernel every time you use hardware that isn't installed by default. Second, I suggest recompiling your kernel. By default, most kernels (RedHat's especially) install a bunch of stuff like SCSI and ISDN that usually serve no purpose, yet visibilly slow the system.
nVidia's packaging problems are representative of problems with Linux as a whole. On Windows, the drivers are dead easy to install, requiring only that the user run an.exe. Linux has no such symantics for managing drivers and updating drivers, or drivers that don't follow that modrobe norm. (OpenGL drivers simply can't, they need to install library files.) It also has pretty crappy module level compatibility, requiring the user to recompile the glue interface for different kernel versions. Is that nVidia's fault? I think not.
Sorry, I was getting poetic. I was trying to refer to the fact that people are concentrating on interface changes, instead of basic things like configuration. To tell the truth, TWM would be easy enough if these tools were in place. Sure Gnome 2.0 will be much better, but it will not be easy to use. Until I see an integrated system for doing everything from managing hardware, to resources, to applications, to installing drivers and configuring settings, it will not be easy to use.
Slashdot Mirror
Commercial licenses for closed source software (which uses the library) are how Troll Tech makes money. Not from derivations of the library.
:-)
>>>>>>
Qt is a class library. People use it be deriving from it. Under legal pressure, your QMyapp:public QApplication could be considered a derived work.
Wrong. A GPL'd library would cover all GPL'd uses. You'd still have to pay for an exception to the GPL (like Reserfs, as I mentioned) if you
wanted to develop a proprietary, closed source application and distribute it to someone else (internal apps could probably get away without
paying).
>>>>>>>
Doesn't the GPL say that you cannot charge for the right to use to code? Isn't it impossible for Linus to use the GPL, except when it involves Microsoft? Isn't the QPL essentially the GPL with that exception?
That would cause the very problem you were just arguing against! That *would* allow commercial proprietary software to be built on Qt without
paying the Trolls.
>>>>>>>>>
I'm pretty sure that LGPL is there for a reason. If the libraries were GPL'ed, then anything linking to them would would automatically become GPL. Hence to problem I mention lower. So if GPL won't work, and LGPL won't work, what's the problem with QPL?
>GPL'd QT would suck, since that would mean ALL
Qt apps would have to be GPL'd.
OK, I'll grant that. Simple solution: Make Qt Free Edition dual licensed by the GPL *and* QPL. That would keep the BSD *and* GPL folks happy.
And still charge for the commercial version. What more could you want?
>>>>>>>>>>
How 'bout it stays the way it is and the GPL folk shut up? They are the ones using QPL code inside GPL code. How, in anyway, does it involved the TrollTech people? Shouldn't KDE change its license to somethign other than the GPL?
Heh, not a bad idea. The GPL is, after all, the only good software license.
>>>>>
I prefer BSD, but license wars are stupid. It should the entirely the author's choice, and all people who complain are just bitching.
Apparently, people don't seem to understand that MacOSX is not a UNIX from the developer sense. A modern MacOSX developer is sure to use the Cocoa API so that their apps appear to be like the other apps that MacOS X users will be used to. As such, their application still won't be portable to UNIX. I mean technically, it should be simple to port apps between BeOS and Linux, since they both use a POSIX base. However, a significant amount of code in a productivity app is user interface code that is tied to the UI system. Since MacOS X uses a different windowing system, even if the Office people use the BSD API for the port, it would still be hard to port to Linux/BSD/X.
What kind of question is that? Of COURSE x86 is obsolete. (Academically anyway). However, I really could care less if it is. It serves our purposes and we keep it around anyway. Academically, UNIX is obsolete too, better designs have already been made. Still, it work with the apps we have, it does its job decently, and that's why we continue to use it.
Sorry, my mistake. Gotta take the heat when I deserve it. Apparently Mandrake IS aimed at servers, (it says so on their webpage) I hereby retract any comments I made related to servers.
Sorry. I'm cranky. I have to write a program in its entirity before tomarrow morning. I mean to include the :), really I did.
No it does not. I booted of the cd and ran the mandrake installer. I don't think the red hat installer is even included? Or are you talking about the text mode installer. In that case, get a new video card.
You're comments are pretty irrelevant. The reviewer says that he is talking about installes for less advanced systems, so yes, X is the only one that matters. You're probably not going to run Mandrake on a server. Second, the directory structure is the same. It has to be since the crappy RPM format has poor provisions for custom directory structures. The tools might be exportable, but seriously, does anybody care? Stuff like that isn't (and shouldn't) be included in a review. Most of the stuff you say (aside from the command line config tool) are pretty much irrelevant to a review. In fact, including it would be bad writing style. As for your comments about end users and "real" functionality, do I detect a sysadmin bias? 99% of the time, Mandrake users are going to be the end user. Thus the end user focus on the review. You don't balk when reviewers ignore server setup in Corel Linux, so why balk for Mandrake?
IPv6 is stable in kernel 2.4 and experimental in 2.2.x. What crack are you on?
Fool. Either way, it means nothing if you aren't familiar with the program. Take xfm. X Friggin' Media? X Floppy Mangler? Xenophobic fruity man? Or pam, Pretty Anoying mercenary, probably angry mutent, possibly attacking molars? Or how about xmms. Xtremely mobile mutent snails? Xtremely mad magic sicophants? The point is that xfm means just as little as Konqueror, but Konqueror sounds nicer.
Go Gfuck Gof, Gnome Gdoes Git Gto.
Blasphemy! You're not a real hacker are you? I like running the latest and the greatest (especially in the case of KDE 2, where it is faster than 1.x). To tell the truth, I am guilty of living VERY bleeding edge. I'm running Mandrake 7.1, kernel 2.4-test, XFree86 4.0, nVidia BetaGL, and I'm dabbling with KDE 2-beta1.
Wouldn't it be nice if this stuff were enapsulated through something like COM? DirectX has 7 very different versions, yet I only have one library, because incompatiblilites can be addressed at a very granular level. (IE. If only a few functions are different, but renders the entire library incompatible, through COM, you can reimplment only those functions in a new interface, and transparently call the old ones.)
No, not better than any distributed system. DCOM probably has lower performance over a network, but locally, it uses COM, and has a great deal more performance. So what happens is, that local performance performs like it should, at a slight expense at network performance and flexibility. I think this is a better trade off for something being integrated into a desktop environment, because the vast majority of apps will run locally. X had this same problem. It had great network performance, but crappy local performance. Fortunately the fixed most of it in 4.0, but there is no reason to start the problem again with a object model. MICO may be rock solid, and not that bad, but only in network mode. In local mode, MICO, and CORBA in general blows.
KDE is shaping up to be quite cool, and blessdly, you no longer have to run GNOME (which is quite a bit slower than KDE) to have a sweet looking desktop. KDE2's imaging and use of high color icons is really nice. However, it is still badly designed, as are all Linux DEs. To put it bluntly, KDE and GNOME simply are not compatible. If you want to run apps from both, (which is necessary if, like me, you like running GNOME but developed in KDevelop) then you have to have both installed. This gets worse, because during the KDE1/KDE2, GNOME1/GNOME2, you'll have to have all four installed to maintain decent compatibility. With just KDE and GNOME loaded, I get 40Meg resident memory use (according to KTop) on my 128 meg system. This is simply unacceptable. Even NT doesn't use that much memory from standstill (more like 30 megs or so) not to mention BeOS (some obscenely small number. Actually, BeOS is the only system that doesn't feel noticable faster in most apps after the upgrade from 64MB to 128MB.) Of course, I'm all for freedom of choice. Can you have your cake and eat it too? Of course! What about a DE that supplied low level stuff, like printing, object model, communication, API, stuff like that, and have a window manager take care of interface aspects and widget sets. This idea takes advantage of the fact that (from the big picture) all GUI software does the same things, and all widget sets provide the same services. So applications are written to the standard API, and whatever WM is loaded, interprets these requests. This would lead to even more customizability for the user (not the programmer, but who cares about he programmer?) All widgets are asked for the same services. So you could have a WM that implments the most efficiant GUI possible, while another one that implements a Windows-like GUI. In both cases, you'd have color dialoges that return an RGB value, so who cares how the dialogue acts. It could implment a standard color wheel, or it could ask the user for an RGB value, or it could randomly pick a number, the interface is the same. Not only would this desktop be more customizable, it would be faster, more stable, and less bloated, because it would have less code than two DEs and more people could be used hacking the core code. I mean you guys are all C programmers right? Ever heard of interface seperate from implementation? The idea at work here folks. Do you care about Bonobo and KParts? Sure. Do you have some insane attachment to one over the other? If so, get help.
This is so Kick ass. I'm a little angry that people don't give Konqueror more credit. It is truly one of KDE's crown jewels. Imagine the past: Here I am with my beautiful, reasonably fast Linux desktop, but right in the middle is the slow and bloated web browser from Motif hell. I've gotten so used to fast, light, nice looking browsers (IE on Windows, Netposetive on BeOS) that using Netscape positivly pained me.
I know this is a troll, but just so nobody gets misinformation. KParts is a lot more like COM than Bonobo. Bonobo is based on CORBA, which is quite different from COM. Back during the object model wars of '94 (its true, you guys think object models are new, but Linux is hideously late to this game) there were two competitors, SOM and COM. SOM was CORBA complient and support inheritance, while COM was a very different MS design, and supported aggregation. I prefer COM, because it is more light weight. CORBA, however is not. Don't you dare mention CORBA and COM in the same sentance 'kay?
Naw, GNOME is mostly fat, no meat whatsoever :) Look, I'm not a Linux newbie, but I simply like KDE better. I'm a speed freak, and KDE tends to be faster and take less memory. Also, I refuse to use a DE that has been tarnished by the bloated piece of shit that is CORBA.
That's bullshit. Why was this moderated up? GNOME and KDE don't help windows users move. In fact, up till recently, GNOME used E as the WM. What GNOME and KDE do, is provide a set of services to graphical applications using the GTK+ and Qt widget sets (respectivaly). (Stuff that should be in the OS proper, but that's a different matter :) Hell, you can use TWM and get as advanced as you want, but without stuff like KDE, no DCOP for you! Also, I get the hint that you think that stuff like integration, and consistancy are for newbies. Not true. They are for smart people who want to get work done without having to spend time learning a new interface.
That is stupid. Derived works are the WHOLE POINT OF A LIBRARY THAT YOU CHARGE FOR. Since nobody uses a widget set simply for the hell of it, derrived works is the only way for Troll Tech to make money. As of now, if you want to use Qt for a professional app, you have to pay. Troll tech can't do that if Qt is GPL'd. Also, even in that case, wouldn't LGPL be more appropriate? GPL'd QT would suck, since that would mean ALL Qt apps would have to be GPL'd. The whole concept is stupid. You're saying that if GPL'd code uses other code, that code atuomatically becomes GPL? Does that mean any BSD code put into Linux automatically becomes GPL? Why not just have a GPLizer program, that automatically incorporates code into GPL'd programs, thus GPL'ing the code!
I am slightly pissed that they reffered to KParts as an object model. An object model is something along the lines of COM and SOM, and simply define a method for easily upgradable, shared objects. When he refers to the fact that KParts handles stuff like where toolbars should go, he gets it wrong. An object model does not handle those thins, that is the work of a embedding system (don't know the jargon for it), along the lines of OLE or OpenDOC. In these cases, OLE and OpenDOC are the embedding system, and they use the object model (COM and SOM respectivaly) to facilitate the embedding.
The reason modprobe does didly for this, is because it only installs a module, not other files that are needed. In Linux, there are no symantics on how a driver should manage files that are not a part of the module itself. So different drivers use different methods for doing this. The reason nVidia's install is so hard is because they are in a peculiar position of having a custom ICD instead of using Mesa. Because of that, it has to replace the Mesa files with its own. The reason you're virge didn't have to do that it uses the standard OpenGL library and didn't have to replace the Mesa files. In Linux, the situation with a card like nVidia's is as such. XFree86 installed some OpenGL files. nVidia comes along and has no idea what files were installed because the system doesn't manage it. Rather than deleting all OpenGL stuff it finds, potentially causing a lot of problems, it requires the user to do it. Say now, that Linux has a Windows way of managing drivers. XFree86 installs. It then installs a Mesa driver as the default driver. This info is listed in a registry somewhere, so when nVidia comes along, it can just look in the registry, uninstall the driver, and put its own it its place. Its kind of like RPM for drivers. It wouldn't take a lot of work, really. XFree86 would have its own RPM, and the Mesa driver would have an RPM. When nVidia came along, it would uninstall the Mesa RPM, and install its own it its place, naming the file appopriatly so all links are still valid. The driver setup thing is irrelevant. If I could just type RPM -Ui nVidiaGL.rpm, I'd be a happy camper. Unfortunatly, Linux has no such system that will allow that.
know, there are a lot of things besides hardware drivers. I use Linux for Real Work (TM) for
years, and I never had to upgrade hardware driver.
>>>>>
If you've never had to upgrade the hardware driver, then you are a dinosaur to say the least. Do you care at all for taking full advantage of your hardware?
That's because I don't need it to play with latest
nVidia card, I need it to do real work - write programs. For this, two years old ATI/Matrox/
whatever is good enough, and Linux supposrt them like charm. If fact, I had much more problems
with NT on drivers that with Linux. And definitley I'd give all latest 3D support for one good office
app on Linux.
>>>>>
Well, that's you isn't it? Being a student, I don't get paid for my work, but I do real work too. I develop OpenGL programs. I mess around with graphics programs. I write graphics libraries. Key work here, "graphics." There is more to life than database engines and POSIX code. Are you saying that 3D modeling isn't real work? The Pixar guys will have your ass on a stick! Coming from someone who is statisfied with a moldy old Matrox card, what does your opinion matter to what I'm talking about? Home users upgrade reletivly often, gamers play a very large role in that market, and people install new types of hardware quite often. As a programmer who obviously doesn't do any graphics work, your experience has no relation to any of this.
Here is where we need real work to be done. 3D is for toys (or high-end CADing,
which is another story) and office apps are for work.
>>>>>
Bull shit. Utter bullshit. Sit there happy with your database engines and your programs that calculate the amount of paper used in yearly tax forms. I can assure you that they guys who make these "toys" (ie. Carmack) have more programming knowledge than you ever had. I don't like being mean, but somebody with your attitude deserves it. No wonder everybody thinks that Linux users are hardcore sysadmins who wouldn't notice if somebody replaced their PC with an XT, long as the server was still up!
So, if you want to use cutting-enge 3D-graphics toys, you'd have to compile. But if you are using
computer as a tool for work, as opposed to playing with lastest-and-greatest gadgets, best chances
are you'll never need to upgrade.
>>>>>>>>>
A) I use computers for work. In fact, I am taking a graphics class which develops in OpenGL. Now let me tell you, running OpenGL on a Matrox is no fun.
B) 3D graphics is not a toy. The gaming market currently makes billions of dollars a year and it is games that made PCs powerful enough that you sysadmins would not have to use Suns for everything.
C) Okay, say you're a Photoshop guy. We've established that he does real work. (And gets paid quite well I might add.) You saying he can get by with an S3 graphics card?
As for not knowing too to handle ipchains, I'll tell you about one for free - gfcc. There are at least
five more I tried, this came out as a winner. Too bad linux.com people don't know about it, but that's
not Linux's fault. That's their fault - they don't know their tools, shame on them.
>>>>>>>>
Ah, but I can handle ipchains. Quite simple if you read the doc. However, I am not representative of an average user. For the average user, Linux.com IS the Linux help source. Them being wrong is like ZDNET being wrong. The entire PC industry gets heat when Windows is too hard, so why shouldn't the entire Linux community get heat for Linux being too hard?
-- Si hoc legere scis nimium eruditionis habes.
I don't use ppp so sucks to be me doesn't it? (Actually it doesn't, I have a DSL connection and get a 40 millisecond ping to most quake servers.) Mandrake and Corel make some things easier, but only stuff that is trivial. Installing drivers is non-trivial, but something that is within the scope of many users. Also, you must not be running up to date hardware. As Linux becomes more popular, you'll have to get used to the constant driver updates as vendors make things more stable, faster, etc. (Not that they weren't stable to begin with. nVidia's uni-driver has been stable for years, but keeps getting better every release.) Linux will make you recompile you kernel every time you use hardware that isn't installed by default. Second, I suggest recompiling your kernel. By default, most kernels (RedHat's especially) install a bunch of stuff like SCSI and ISDN that usually serve no purpose, yet visibilly slow the system.
nVidia's packaging problems are representative of problems with Linux as a whole. On Windows, the drivers are dead easy to install, requiring only that the user run an .exe. Linux has no such symantics for managing drivers and updating drivers, or drivers that don't follow that modrobe norm. (OpenGL drivers simply can't, they need to install library files.) It also has pretty crappy module level compatibility, requiring the user to recompile the glue interface for different kernel versions. Is that nVidia's fault? I think not.
Sorry, I was getting poetic. I was trying to refer to the fact that people are concentrating on interface changes, instead of basic things like configuration. To tell the truth, TWM would be easy enough if these tools were in place. Sure Gnome 2.0 will be much better, but it will not be easy to use. Until I see an integrated system for doing everything from managing hardware, to resources, to applications, to installing drivers and configuring settings, it will not be easy to use.