Ech. Backup devices are for sissies;) These days, it's just so much cheaper (and faster, etc) to get a second harddrive and backup to that. Or (my favorite) build a cheap local FTP server and backup to that. It beats tape...
Re:KDE: one of the most successful OSS projects
on
KDE 2.1 Is Out
·
· Score: 2
Yea, but remote objects (in many different forms!) have been around for many many years and STILL nobody uses them. There are bad ideas, and good ideas (not to be confused with cool ideas). This is just one of the former.
M$ has never been able to port NT off of the x86.
>>>>>>>>>>
At one point NT ran on MIPS, Alpha, PPC, and x86. As time progressed NT got worse and now only runs on x86.
If Sun can get 64 bits onto the desk top (they have the StarOffice suite for free,) the connectivity and reliability of Solaris and the horsepower of 64 bits at the low end will make
M$ drop trou . It's all about TCO.
>>>>>>>>>>>>
And the TCO on a SPARC is higher.
This is good news. Sun is positionning themselves to be the favored delivery platform for the next killer apps: Voice recognition and image interpretation. (the ears and eyes of the machine.) No more friggin' passwords. The machine will see that its you!
>>>>>>>>>>>>>.
Umm, a 1.2 GHz Athlon does Voice recognition fine, and image interpretation isn't very usefull outside of passwords. Not to mention the fact commodity x86 hardware is faster and cheaper than whatever Sun is pushing off. 64 bits has no real meaning on the desktop, not yet. Modern CPUs already have 64bit data busses and SSE2 already crunches FP data in 128bit chunks. RISC is nice, but remember, a 1.2 GHz Athlon will very likely outperform whatever Sun can get out at a comparable price point. It will also be better equiped (more memory, fast 3D cards, better sound) and more compatible. While having SPARC on the desktop might seem cool at first, until they can get dual USIII 900MHz's on the desktop at the same price as a dual 1.2 GHz Athlon system, there's no real point in buying one. Methinks this will be much more useful in the server arena for those who want Sun-quality hardware without selling a child.
Re:I have had a fearful thought....
on
KDE 2.1 Is Out
·
· Score: 2
How can you possibly say that Mozilla is usably fast? I think developers should be forced to use systems comparable to the low-end of available systems. Then, jack the proc down for the inherent speedup that a programmer's mind imparts onto its own creations. I'd say if it runs tolerably on a 150MHz with 32MB of RAM, then its really ready for prime time.
Re:I have had a fearful thought....
on
KDE 2.1 Is Out
·
· Score: 2
He he. There was a remark on the BeOS development mailing list once about how 32MB was a *LOT* of code and that BeOS's 32MB memory limit on add-ons wasn't a problem. Then Mozilla hit against it...
Re:I have had a fearful thought....
on
KDE 2.1 Is Out
·
· Score: 2
Yes, conceptually Mozilla is much better. I'm sure that DOM is great, ECMAScript is essential and XML will bring lots of good things. (I still dismiss XUL as wasteful and unecessary. You need a good, font+layout sensative view management system and that's it. XUL is too performance sapping for compartively little gain.) Despite all that, what's the use *now* The web-development community is not exactly known for quick support of standards (especially since IE doesn't support much of this stuff yet) and until the minimum system becomes fast enough to run Mozilla comfortably (I'm typing this on a 500MHz PIII w/ 64MB and Mozilla is god-aweful slow. On my 300Mhz w/ 128MB it's still slow) people will not adopt these new standards. I'd say that adoption of these standards is still a year away, and that is just too far in the future to contemplate about now. So, again, what real, tangible benifets does Mozilla have NOW?
Re:I have had a fearful thought....
on
KDE 2.1 Is Out
·
· Score: 2
XUL is eye candy.
DOM might be useful, but not yet.
ECMAScript support seems good enough on Konqueror.
MathML: What uses it?
Cross platform: Who cares? There are two platforms, *NIX and Windows. (BeOS is too superior to be considered in this discussion;) If you're on *NIX, Konqueror works. If you're on Windows, you're already using IE.
Re:KDE: one of the most successful OSS projects
on
KDE 2.1 Is Out
·
· Score: 2
Umm, about.01% of the computing population uses remote objects. There decision seems to have been that standard communications methods based on TCP/IP are more efficient than doing networking through the object system, and that the other benifets of network objects (not having objects locally) was really outweighed by powerful clients and fast networks. So in the end, you have a lighter, more universally usable object system with less *wow* factor and no REAL disadvantages. I think it was a good decision. (BTW, COM kicks CORBA's ass. CORBA is just too much technology to be used everywhere in a desktop environment. COM (minus the MS crap) is just ABCs exported by DLLs. Can't get much simpler than that.)
You're trolling aren't you?
>>>>>>>>>
Much as you'd like to belive that, I'm not.
If MFC is "just a wrapper" for Win32, then GTK and Qt are "just wrappers" for X11.
>>>>>>>>>>
No, MFC really IS a wrapper. It doesn't do much processing at all. GTK and Qt do their own text drawing, (GNOME and KDE) manage their own clipboard, they have their own printing services, etc. MFC (and presumably OWL) is just a C++ wrapper just makes calls to Win32. It doesn't define any services of its own. The difference is that GTK and Qt implement their own services and define ones not part of standard xlib. MFC doesn't.
Similarly, you can run an app under X written using GTK. It will happily share clipboard data with an app
written using Athena. Or Qt. Or OpenWindows. Or whatever other standard widget set and toolkit you care to
mention. And no, not any of these toolkits shares an API.
>>>>>>>>>>>>>
Let's see. I can implement a component written in VBScript into an application written in MFC. In the next iteration, the application could move to straight Win32, and the component could move to MFC. Everything still works, hell, I don't even have to know *what* language the component is programmed in. Let's see GTK+ and KDE do this (without hacks!)
The API of MFC is not the Win32 API. It merely uses Win32 based operating systems to implement its
functionality.The API of MFC is not the same as the VB API.The API of Qt is not the same as the XLib API. It runs over the top of it, making use of XLib to implement its functionality.
>>>>>>>>>>>>
Qt and GTK (and to a much larger extent GNOME and KDE, what this debate is about) implement their own features independant of XLib. Hence the X-less Qt and GTK ports. MFC doesn't do much of anything except make calls to standard Win32 functions.
And, as if it needs to be said, Qt's API is not the same as the API of GTK. I don't see how you can argue that the situation with APIs and widget sets is any worse on X than it is on Windows. It's exactly the same.
>>>>>>>>>>>>>>>
A) The situation is different. See above cogitation.
B) Even then, how is being the same as Windows remotely near being good?
As for pulling OpenGL into everything, there are, as I said, standard APIs out there, normally defined as defacto standards, for X11. They include the three I've already mentioned. They are Athena, OpenWindows, and Motif. Of these, I've seen at least three Athena (the original, the 3d one, and the NextStep one) implementations, OpenWindows never really took off so never gained much support (and was open source anyway so there was little point in writing a new version), and Motif has at least two (Official Motif and Lesstif).
>>>>>>>>>>
Funny. OpenWindows "never really took off" yet its somehow a "standard"? No matter what, everything you've just mentioned is entirely irrelevant to Linux. None of the interesting apps coming out use Motif, Athena, or OpenWindows. Besides, decreeing "one standard toolkit" is not what I want. I want a binary standard for toolkits. Different APIs can plug into that binary standard and make calls to different implementations supporting that standard and everything just works. That's how OpenGL does it, and it is Good(TM). Maybe I should have made that point clearer.
Trying to play with words and call them toolkits rather than APIs doesn't change the fact that they're as implementation independent, well defined, and open, as OpenGL is.
>>>>>>>>>>>>
But it also doesn't change the fact that people actually USE OpenGL, and (on Linux anyway) nobody *uses* the "standard" APIs. And while the toolkits maybe be implementation independant (theoretically) the one alternative implementation of the three toolkits you mentioned (Lesstif) lies in stark contrast to the dozens of (compatible!) implementations of OpenGL. There is really no comparison beyond the very basic.
Finally, what do you mean by "your way doesn't seem to be working, does it?". I can run Qt apps and GTK apps
on my machine without having to run GNOME or KDE.
>>>>>>>>>>
But do they look the same? Do they interoperate perfectly? Do they respond to the same configuration programs? Do they use the same themes? Do they work with the same applets? If so, please tell me what versions you're using!
Response times are excellent, and this is on a 32 meg
laptop.
>>>>>>>>>>>>
Then your standards are set to low. Nothing, not even QNX or BeOS, has "excellent" response times on a 32MB laptop. On my machine, (300MHz PII 128MB RAM) GNOME runs "decently." KDE-2 runs inexorably slow, NT-4 is snappy, and BeOS runs like a bat-out of hell.
What definition of "working" are you using? Certainly, by most people's definition, being able to run two
programs at once without, most of the time, even caring which widget set it uses, would appear to me to be
"working".
>>>>>>>>>>>>>
Maybe I should have said "working well." Like most people, I make no distinction between the two.
A) Strike "most of the time" from your vocabulary. I *never* have to worry what WRAPPER a Win32 program is written in (hell, I don't even have to worry what LANGUAGE its written in) and I should have to worry on a supposedly superior platform like Linux.
B) I want it to interoperate perfectly. I want it to take zero memory. I want it to predict what I'm going to do. High standards yes, but right now Windows (and some other OSs) are a lot closer to it than GNOME/X/KDE/Tk/Athena/Motif/GTK/Qt/FLTK/GNU/Linux.
As for your additional rantings, I get high quality software on Windows without running dozens of libraries. This is mainly because you're "right tool for the job" BS doesn't hold water, not on Linux as it is today. Qt and GTK (and GNOME and KDE), both progmatically and functionally equivilant. One may prefer one or the other, but one will develop appreciably better on one or the other. There is some use for some of the smaller toolkits, but in that case, methinks it would be better do get something like VBScript (isn't Linux supposed to get a Kylix port?) and keep the total toolkit count to an absolute minumum. The number of toolkits on UNIX is currently much larger than necessary to support "right tool for the job" and the inherent uninteroperability of the toolkits just exacerabtes the problem.
Actually, QNX X apps look just like standard RtP apps, just uglier (except GTK ones, Qt isn't ported yet). There's not seperate "X Window" or anything.
A) I love the subscription music idea. I don't really listen to CDs all that long, and as such, don't buy them. I would, however, pay money to subscribe to music. If the fee were, say, $10 a month, I'd gladly pay it, and that would be $120 going to them that they wouldn't have seen anyway. I don't know why someone hasn't thought of this before! Same thing with micropayment. If you make it easy (and reasonable) for people to spend their money, they will.
B) I don't really see how one can defend copying music as freedom of speech. Freedom of speech is a very specific term. It means that you have the right to say what you want without the government stopping you. We have extrapolated this concept a little to include many different forms of media (newspapers, etc) but still exclude others (public walls). Now if you want to say that repeating somebody else's speech is freedom of speech, then you're going way beyond the definition. Hey, if you want to belt out "Stronger" and sell it, more power to you. But if you simply type cp stonger.mp3 and give it to somebody else, that can't be called freedom of speech. If that's the case, then copying books suddenly becomes fine. Copying software (after all, the difference between Office 2000 and an MP3 is just that when you cat winword.exe >/dev/raw you get static rather than Britney's melodious voice) suddenly becomes legal. I just don't see how one can do that.
There will always be people (maybe a majority, maybe not) that will just want to sit in front of their 10GHz (100W, 2lb heatsink, oh baby!) proc and 25inch monitor and zen. They deserve a better system too.
How did Linux users ever become so obsessed with installed base? I could have easily said, 5 years ago "So what if Linux is technically superior? Nobody uses it yet!" Doesn't good technology count for *something* around here?
It's always had drag and drop:
Drag and Drop programming The fact that many programs don't use it yet is immaturity in the desktop environment (which I mentioned) not immaturity in the core OS.
1. There have been three attempts to create standard widget libraries for X, Athena, OpenWindows and Motif. Of the three, the first quickly became obsolete as time wore on.
>>>>>>>>>
I said standard API. Not standard toolkit. Nothing precludes an API from growing and expanding, and having new toolkits implemented under it. OpenGL (and more so, DirectX) is an excellent example of a standard API that has evolved through many revisions and implementations.
What makes you think that GQt, or whatever your hybrid interface is to be called, wouldn't suffer the same fate?
>>>>>>>>>>>>
Because it would be an API, not a toolkit. It would specify a certain set of services, and whatever toolkit the user wanted could supply those services.
2. Saying that programmers should not be allowed to use toolkits other than the one you desire would, even if possible to implement, have a devastating effect on the programming community. You have to produce toolkits that do what programmers want out of them, or else face not having those toolkits available.
>>>>>>>>>>
Doesn't seem to be much of a problem on the Windows platform. Sure, there is MFC, OWL, VB, etc, but all of those wrap around the same set of Win32 services. An MFC app can exchange clipboard data, objects, whatever, transparently with a Win32 app. The same is not the case with the thousands of *NIX toolkits.
3. MFC is relevent here. It's an alternative API. There are several APIs for programming Windows' GUIs, many of which originate from Microsoft themselves, and many of those are optional.
>>>>>>>>
MFC isn't relevant. Its not an alternative toolkit, but a wrapper over the same Win32 services.
MFC is standard only insofar as the creator of the operating system has declared it such.
>>>>>>>>>
Believe it or not, that's a good way to make it "standard."
It happens to be, according to most programmers I've talked to who use it, a very good API, and MS's Visual C++ encourages the use of it. It's become popular for that reason.
>>>>>>>>>>>>
MFC is a bloated piece of crud. Everyone I've talked to agrees, unless of course you're talking to the "wizard" crowd. (If you need something quick, use a quick language, but for god sakes don't use MFC!)
In conclusion: It seems to me that the demand that programmers be forced to use a particular toolkit for all their GUI programming is unworkable, unreasonable, would contradict standard practice on every other platform
>>>>>>>>>
99% of Win32 apps call the same toolkit functions, whether they are wrapped OWL, MFC, etc is irrelevant. They are not incompatible in the way GTK+ and Qt apps are.
And to what reward, the ability to save a small number of megs of RAM that, as a percentage of the whole OS, is practically insignificant? Much as I abhor code bloat, I have to say that the price is not worth paying.
>>>>>>>>>>>>>
A) Given the current situation with GNOME and KDE, your way doesn't seem to be working, does it?
B) It's not just code bloat, its platform fragmentation. KDE/Linux is not the same OS as GNOME/Linux, at least not for a modern (ie. takes advantage of DE features) GUI app. MFC/Windows and OWL/Windows is. I'm not even saying that the Windows way is the best way to do it, though it's better than the UNIX way. The OpenGL way is the best way to do it. Define an ABI. Then, make both sides replacable. With OpenGL, I can use Java to call NVIDIA's implementation, or use Delphi to call ATI's. All while still having access to the same set of services, and all while interoperating perfectly with apps whose developers didn't make the same decisions as me. That's real good design.
Linux 2.4 w/ XFS really is a marvel. Even though its is supposedly beta quality, it has been rock solid for me (two weeks of benchmarking it against BFS;) and there don't seem to be any real issues using it on Linux. You have to switch to LILO (remember that?) and you lose some as of yet unimplemented features (group quotas) but it is very solid. My benchmarks put the Linux version as faster than BFS and ReiserFS, and feature-wise it has attributes (too bad Linux won't take full advantage of them) and all the other feature seem to have made it to the Linux port unmolested.
As an real, usable alternative to the currently available OSs, QNX RtP is most of the way there. It has a nice, fast, slim core architecture, fast response times, a well-developed package management system, it has a fast GUI, a complete API, and some great networking (GUI transparency, distributed processing, the works). Still, some areas need work. The filesystem needs to be totally replaced, and the VM/swap system needs a good bit of work. Also, the desktop environment, while certainly pretty, needs a lot of work from the usability standpoint, and its configuration services need to be more complete.
I've been playing around with XFS for a few weeks, and I must say it kicks total ass. It's a good bit faster than ReiserFS and seems to have fewer problems with latencies. On the Bonnie benchmark (which are apparently biased according to some kernel developers) XFS get 3x the I/Os per second, and in real world cp and tar testing, it is noticably faster. That said, it seems to also have ACL support.
Widget libraries are ultimately the choice of the programmer.
>>>>>>>>>
That's the problem. If UNIX were really about empowering the user, developers shouldn't get to make these decisions. If developers were forced to write to a standard API (OpenGL, for example) then the user could use whatever implementation of it THEY wanted.
The "right" widget library will depend on a range of factors, from what language you're going to use to the range of features you need.
>>>>>>>>
Easy to fix. Design the standard API well, and include lots of language bindings. OpenGL does both.
There's nothing you can do to get programmers to standardise on a single library, because no single library, not Qt which is C++ specific or GTK* which has a much more procedural outlook, not the various other ones, will ever be the "perfect" catch all does all library.
>>>>>>>>>>>>
Sure you can. The X people seem to have done a pretty good job of tying everyone to X. You just have to make sure that all the nifty features are available through that toolkit only. If the standard API were added to X, most programmers wouldn't bother to use a seperate toolkit (just like most programmers don't bother to use toolkits like OWL on Windows.)
PS> MFC realy isn't applicable here, it is more or less a "standard" API for Windows in addition to Win32.
That's the biggest bunch of BS in the world. Wasted memory is wasted memory. I have no problem with Linux using 90% of my memory to cache my disk, but when it has to use 30-40% to cache the 30MB of graphics binaries, that's a problem. The problem isn't that Linux is caching those binaries, the problem is that the binaries are 30MB in size!
I was using the Mandrake packages. Plus, why do binaries all optimize for 386, with some exceptions optimized for Pentium? Given that everybody has at least a Pentium-class chip (and P6 chips have been around for five years) shouldn't -mpentiumpro be the standard optimization, with some special distros cataring to the 386 crowd? What moron runs KDE2 on a 486 anyway? Thankfully, distros like Gentoo exist (yea, my obsession of the day;) that (will) optimize for Pentium Pro. Check them out at this site
It's not the 10-20MB of diskspace that bothers me, its the 10-20MB of memory. All together, a fully loaded system takes up 30+MB (KDE-1, KDE-2, GNOME, and soon GNOME-2!) Even on a 128MB system, that's just too damn much for the OS to use up. The OS shouldn't use anything more than 10% of avaiable memory, after that its just sick. Not to mention the fact that while GNOME apps run on KDE, you don't get the full experience provided by a "desktop environment." While hacks to load KDE components on GNOME or run GNOME applets in KDE are available, they're just hacks, nothing more.
I would complain. Apps shouldn't require a particular toolkit, but should require the services of that toolkit to be available. On Windows, no app depends on having MS-OpenGL available, but having SOME OpenGL implementation available. Qt provides all the services available in GTK+, so GIMP should work transparently on Qt. Whoa, what a concept! Too bad whoever made shared libraries thought it up first...
Slashdot Mirror
Ech. Backup devices are for sissies ;) These days, it's just so much cheaper (and faster, etc) to get a second harddrive and backup to that. Or (my favorite) build a cheap local FTP server and backup to that. It beats tape...
Yea, but remote objects (in many different forms!) have been around for many many years and STILL nobody uses them. There are bad ideas, and good ideas (not to be confused with cool ideas). This is just one of the former.
M$ has never been able to port NT off of the x86.
>>>>>>>>>>
At one point NT ran on MIPS, Alpha, PPC, and x86. As time progressed NT got worse and now only runs on x86.
If Sun can get 64 bits onto the desk top (they have the StarOffice suite for free,) the connectivity and reliability of Solaris and the horsepower of 64 bits at the low end will make
M$ drop trou . It's all about TCO.
>>>>>>>>>>>>
And the TCO on a SPARC is higher.
This is good news. Sun is positionning themselves to be the favored delivery platform for the next killer apps: Voice recognition and image interpretation. (the ears and eyes of the machine.) No more friggin' passwords. The machine will see that its you!
>>>>>>>>>>>>>.
Umm, a 1.2 GHz Athlon does Voice recognition fine, and image interpretation isn't very usefull outside of passwords. Not to mention the fact commodity x86 hardware is faster and cheaper than whatever Sun is pushing off. 64 bits has no real meaning on the desktop, not yet. Modern CPUs already have 64bit data busses and SSE2 already crunches FP data in 128bit chunks. RISC is nice, but remember, a 1.2 GHz Athlon will very likely outperform whatever Sun can get out at a comparable price point. It will also be better equiped (more memory, fast 3D cards, better sound) and more compatible. While having SPARC on the desktop might seem cool at first, until they can get dual USIII 900MHz's on the desktop at the same price as a dual 1.2 GHz Athlon system, there's no real point in buying one. Methinks this will be much more useful in the server arena for those who want Sun-quality hardware without selling a child.
How can you possibly say that Mozilla is usably fast? I think developers should be forced to use systems comparable to the low-end of available systems. Then, jack the proc down for the inherent speedup that a programmer's mind imparts onto its own creations. I'd say if it runs tolerably on a 150MHz with 32MB of RAM, then its really ready for prime time.
He he. There was a remark on the BeOS development mailing list once about how 32MB was a *LOT* of code and that BeOS's 32MB memory limit on add-ons wasn't a problem. Then Mozilla hit against it...
Yes, conceptually Mozilla is much better. I'm sure that DOM is great, ECMAScript is essential and XML will bring lots of good things. (I still dismiss XUL as wasteful and unecessary. You need a good, font+layout sensative view management system and that's it. XUL is too performance sapping for compartively little gain.) Despite all that, what's the use *now* The web-development community is not exactly known for quick support of standards (especially since IE doesn't support much of this stuff yet) and until the minimum system becomes fast enough to run Mozilla comfortably (I'm typing this on a 500MHz PIII w/ 64MB and Mozilla is god-aweful slow. On my 300Mhz w/ 128MB it's still slow) people will not adopt these new standards. I'd say that adoption of these standards is still a year away, and that is just too far in the future to contemplate about now. So, again, what real, tangible benifets does Mozilla have NOW?
XUL is eye candy. ;) If you're on *NIX, Konqueror works. If you're on Windows, you're already using IE.
DOM might be useful, but not yet.
ECMAScript support seems good enough on Konqueror.
MathML: What uses it?
Cross platform: Who cares? There are two platforms, *NIX and Windows. (BeOS is too superior to be considered in this discussion
Umm, about .01% of the computing population uses remote objects. There decision seems to have been that standard communications methods based on TCP/IP are more efficient than doing networking through the object system, and that the other benifets of network objects (not having objects locally) was really outweighed by powerful clients and fast networks. So in the end, you have a lighter, more universally usable object system with less *wow* factor and no REAL disadvantages. I think it was a good decision. (BTW, COM kicks CORBA's ass. CORBA is just too much technology to be used everywhere in a desktop environment. COM (minus the MS crap) is just ABCs exported by DLLs. Can't get much simpler than that.)
You're trolling aren't you?
.
>>>>>>>>>
Much as you'd like to belive that, I'm not.
If MFC is "just a wrapper" for Win32, then GTK and Qt are "just wrappers" for X11.
>>>>>>>>>>
No, MFC really IS a wrapper. It doesn't do much processing at all. GTK and Qt do their own text drawing, (GNOME and KDE) manage their own clipboard, they have their own printing services, etc. MFC (and presumably OWL) is just a C++ wrapper just makes calls to Win32. It doesn't define any services of its own. The difference is that GTK and Qt implement their own services and define ones not part of standard xlib. MFC doesn't.
Similarly, you can run an app under X written using GTK. It will happily share clipboard data with an app
written using Athena. Or Qt. Or OpenWindows. Or whatever other standard widget set and toolkit you care to
mention. And no, not any of these toolkits shares an API.
>>>>>>>>>>>>>
Let's see. I can implement a component written in VBScript into an application written in MFC. In the next iteration, the application could move to straight Win32, and the component could move to MFC. Everything still works, hell, I don't even have to know *what* language the component is programmed in. Let's see GTK+ and KDE do this (without hacks!)
The API of MFC is not the Win32 API. It merely uses Win32 based operating systems to implement its
functionality.The API of MFC is not the same as the VB API.The API of Qt is not the same as the XLib API. It runs over the top of it, making use of XLib to implement its functionality.
>>>>>>>>>>>>
Qt and GTK (and to a much larger extent GNOME and KDE, what this debate is about) implement their own features independant of XLib. Hence the X-less Qt and GTK ports. MFC doesn't do much of anything except make calls to standard Win32 functions.
And, as if it needs to be said, Qt's API is not the same as the API of GTK. I don't see how you can argue that the situation with APIs and widget sets is any worse on X than it is on Windows. It's exactly the same.
>>>>>>>>>>>>>>>
A) The situation is different. See above cogitation.
B) Even then, how is being the same as Windows remotely near being good?
As for pulling OpenGL into everything, there are, as I said, standard APIs out there, normally defined as defacto standards, for X11. They include the three I've already mentioned. They are Athena, OpenWindows, and Motif. Of these, I've seen at least three Athena (the original, the 3d one, and the NextStep one) implementations, OpenWindows never really took off so never gained much support (and was open source anyway so there was little point in writing a new version), and Motif has at least two (Official Motif and Lesstif).
>>>>>>>>>>
Funny. OpenWindows "never really took off" yet its somehow a "standard"? No matter what, everything you've just mentioned is entirely irrelevant to Linux. None of the interesting apps coming out use Motif, Athena, or OpenWindows. Besides, decreeing "one standard toolkit" is not what I want. I want a binary standard for toolkits. Different APIs can plug into that binary standard and make calls to different implementations supporting that standard and everything just works. That's how OpenGL does it, and it is Good(TM). Maybe I should have made that point clearer.
Trying to play with words and call them toolkits rather than APIs doesn't change the fact that they're as implementation independent, well defined, and open, as OpenGL is.
>>>>>>>>>>>>
But it also doesn't change the fact that people actually USE OpenGL, and (on Linux anyway) nobody *uses* the "standard" APIs. And while the toolkits maybe be implementation independant (theoretically) the one alternative implementation of the three toolkits you mentioned (Lesstif) lies in stark contrast to the dozens of (compatible!) implementations of OpenGL. There is really no comparison beyond the very basic.
Finally, what do you mean by "your way doesn't seem to be working, does it?". I can run Qt apps and GTK apps
on my machine without having to run GNOME or KDE.
>>>>>>>>>>
But do they look the same? Do they interoperate perfectly? Do they respond to the same configuration programs? Do they use the same themes? Do they work with the same applets? If so, please tell me what versions you're using!
Response times are excellent, and this is on a 32 meg
laptop.
>>>>>>>>>>>>
Then your standards are set to low. Nothing, not even QNX or BeOS, has "excellent" response times on a 32MB laptop. On my machine, (300MHz PII 128MB RAM) GNOME runs "decently." KDE-2 runs inexorably slow, NT-4 is snappy, and BeOS runs like a bat-out of hell.
What definition of "working" are you using? Certainly, by most people's definition, being able to run two
programs at once without, most of the time, even caring which widget set it uses, would appear to me to be
"working".
>>>>>>>>>>>>>
Maybe I should have said "working well." Like most people, I make no distinction between the two.
A) Strike "most of the time" from your vocabulary. I *never* have to worry what WRAPPER a Win32 program is written in (hell, I don't even have to worry what LANGUAGE its written in) and I should have to worry on a supposedly superior platform like Linux.
B) I want it to interoperate perfectly. I want it to take zero memory. I want it to predict what I'm going to do. High standards yes, but right now Windows (and some other OSs) are a lot closer to it than GNOME/X/KDE/Tk/Athena/Motif/GTK/Qt/FLTK/GNU/Linux
As for your additional rantings, I get high quality software on Windows without running dozens of libraries. This is mainly because you're "right tool for the job" BS doesn't hold water, not on Linux as it is today. Qt and GTK (and GNOME and KDE), both progmatically and functionally equivilant. One may prefer one or the other, but one will develop appreciably better on one or the other. There is some use for some of the smaller toolkits, but in that case, methinks it would be better do get something like VBScript (isn't Linux supposed to get a Kylix port?) and keep the total toolkit count to an absolute minumum. The number of toolkits on UNIX is currently much larger than necessary to support "right tool for the job" and the inherent uninteroperability of the toolkits just exacerabtes the problem.
Actually, QNX X apps look just like standard RtP apps, just uglier (except GTK ones, Qt isn't ported yet). There's not seperate "X Window" or anything.
A) I love the subscription music idea. I don't really listen to CDs all that long, and as such, don't buy them. I would, however, pay money to subscribe to music. If the fee were, say, $10 a month, I'd gladly pay it, and that would be $120 going to them that they wouldn't have seen anyway. I don't know why someone hasn't thought of this before! Same thing with micropayment. If you make it easy (and reasonable) for people to spend their money, they will.
/dev/raw you get static rather than Britney's melodious voice) suddenly becomes legal. I just don't see how one can do that.
B) I don't really see how one can defend copying music as freedom of speech. Freedom of speech is a very specific term. It means that you have the right to say what you want without the government stopping you. We have extrapolated this concept a little to include many different forms of media (newspapers, etc) but still exclude others (public walls). Now if you want to say that repeating somebody else's speech is freedom of speech, then you're going way beyond the definition. Hey, if you want to belt out "Stronger" and sell it, more power to you. But if you simply type cp stonger.mp3 and give it to somebody else, that can't be called freedom of speech. If that's the case, then copying books suddenly becomes fine. Copying software (after all, the difference between Office 2000 and an MP3 is just that when you cat winword.exe >
This is funny. QNX has this built-in (transparent no less!) See the article on QNet.
There will always be people (maybe a majority, maybe not) that will just want to sit in front of their 10GHz (100W, 2lb heatsink, oh baby!) proc and 25inch monitor and zen. They deserve a better system too.
How did Linux users ever become so obsessed with installed base? I could have easily said, 5 years ago "So what if Linux is technically superior? Nobody uses it yet!" Doesn't good technology count for *something* around here?
It's always had drag and drop:
Drag and Drop programming The fact that many programs don't use it yet is immaturity in the desktop environment (which I mentioned) not immaturity in the core OS.
1. There have been three attempts to create standard widget libraries for X, Athena, OpenWindows and Motif. Of the three, the first quickly became obsolete as time wore on.
>>>>>>>>>
I said standard API. Not standard toolkit. Nothing precludes an API from growing and expanding, and having new toolkits implemented under it. OpenGL (and more so, DirectX) is an excellent example of a standard API that has evolved through many revisions and implementations.
What makes you think that GQt, or whatever your hybrid interface is to be called, wouldn't suffer the same fate?
>>>>>>>>>>>>
Because it would be an API, not a toolkit. It would specify a certain set of services, and whatever toolkit the user wanted could supply those services.
2. Saying that programmers should not be allowed to use toolkits other than the one you desire would, even if possible to implement, have a devastating effect on the programming community. You have to produce toolkits that do what programmers want out of them, or else face not having those toolkits available.
>>>>>>>>>>
Doesn't seem to be much of a problem on the Windows platform. Sure, there is MFC, OWL, VB, etc, but all of those wrap around the same set of Win32 services. An MFC app can exchange clipboard data, objects, whatever, transparently with a Win32 app. The same is not the case with the thousands of *NIX toolkits.
3. MFC is relevent here. It's an alternative API. There are several APIs for programming Windows' GUIs, many of which originate from Microsoft themselves, and many of those are optional.
>>>>>>>>
MFC isn't relevant. Its not an alternative toolkit, but a wrapper over the same Win32 services.
MFC is standard only insofar as the creator of the operating system has declared it such.
>>>>>>>>>
Believe it or not, that's a good way to make it "standard."
It happens to be, according to most programmers I've talked to who use it, a very good API, and MS's Visual C++ encourages the use of it. It's become popular for that reason.
>>>>>>>>>>>>
MFC is a bloated piece of crud. Everyone I've talked to agrees, unless of course you're talking to the "wizard" crowd. (If you need something quick, use a quick language, but for god sakes don't use MFC!)
In conclusion: It seems to me that the demand that programmers be forced to use a particular toolkit for all their GUI programming is unworkable, unreasonable, would contradict standard practice on every other platform
>>>>>>>>>
99% of Win32 apps call the same toolkit functions, whether they are wrapped OWL, MFC, etc is irrelevant. They are not incompatible in the way GTK+ and Qt apps are.
And to what reward, the ability to save a small number of megs of RAM that, as a percentage of the whole OS, is practically insignificant? Much as I abhor code bloat, I have to say that the price is not worth paying.
>>>>>>>>>>>>>
A) Given the current situation with GNOME and KDE, your way doesn't seem to be working, does it?
B) It's not just code bloat, its platform fragmentation. KDE/Linux is not the same OS as GNOME/Linux, at least not for a modern (ie. takes advantage of DE features) GUI app. MFC/Windows and OWL/Windows is. I'm not even saying that the Windows way is the best way to do it, though it's better than the UNIX way. The OpenGL way is the best way to do it. Define an ABI. Then, make both sides replacable. With OpenGL, I can use Java to call NVIDIA's implementation, or use Delphi to call ATI's. All while still having access to the same set of services, and all while interoperating perfectly with apps whose developers didn't make the same decisions as me. That's real good design.
Linux 2.4 w/ XFS really is a marvel. Even though its is supposedly beta quality, it has been rock solid for me (two weeks of benchmarking it against BFS ;) and there don't seem to be any real issues using it on Linux. You have to switch to LILO (remember that?) and you lose some as of yet unimplemented features (group quotas) but it is very solid. My benchmarks put the Linux version as faster than BFS and ReiserFS, and feature-wise it has attributes (too bad Linux won't take full advantage of them) and all the other feature seem to have made it to the Linux port unmolested.
As an real, usable alternative to the currently available OSs, QNX RtP is most of the way there. It has a nice, fast, slim core architecture, fast response times, a well-developed package management system, it has a fast GUI, a complete API, and some great networking (GUI transparency, distributed processing, the works). Still, some areas need work. The filesystem needs to be totally replaced, and the VM/swap system needs a good bit of work. Also, the desktop environment, while certainly pretty, needs a lot of work from the usability standpoint, and its configuration services need to be more complete.
I've been playing around with XFS for a few weeks, and I must say it kicks total ass. It's a good bit faster than ReiserFS and seems to have fewer problems with latencies. On the Bonnie benchmark (which are apparently biased according to some kernel developers) XFS get 3x the I/Os per second, and in real world cp and tar testing, it is noticably faster. That said, it seems to also have ACL support.
Turning on P6 optimizations (on VisualC++) makes my graphics library run 20% faster. I'd say that's quite significant.
Widget libraries are ultimately the choice of the programmer.
>>>>>>>>>
That's the problem. If UNIX were really about empowering the user, developers shouldn't get to make these decisions. If developers were forced to write to a standard API (OpenGL, for example) then the user could use whatever implementation of it THEY wanted.
The "right" widget library will depend on a range of factors, from what language you're going to use to the range of features you need.
>>>>>>>>
Easy to fix. Design the standard API well, and include lots of language bindings. OpenGL does both.
There's nothing you can do to get programmers to standardise on a single library, because no single library, not Qt which is C++ specific or GTK* which has a much more procedural outlook, not the various other ones, will ever be the "perfect" catch all does all library.
>>>>>>>>>>>>
Sure you can. The X people seem to have done a pretty good job of tying everyone to X. You just have to make sure that all the nifty features are available through that toolkit only. If the standard API were added to X, most programmers wouldn't bother to use a seperate toolkit (just like most programmers don't bother to use toolkits like OWL on Windows.)
PS> MFC realy isn't applicable here, it is more or less a "standard" API for Windows in addition to Win32.
That's the biggest bunch of BS in the world. Wasted memory is wasted memory. I have no problem with Linux using 90% of my memory to cache my disk, but when it has to use 30-40% to cache the 30MB of graphics binaries, that's a problem. The problem isn't that Linux is caching those binaries, the problem is that the binaries are 30MB in size!
I was using the Mandrake packages. Plus, why do binaries all optimize for 386, with some exceptions optimized for Pentium? Given that everybody has at least a Pentium-class chip (and P6 chips have been around for five years) shouldn't -mpentiumpro be the standard optimization, with some special distros cataring to the 386 crowd? What moron runs KDE2 on a 486 anyway? Thankfully, distros like Gentoo exist (yea, my obsession of the day ;) that (will) optimize for Pentium Pro. Check them out at this site
It's not the 10-20MB of diskspace that bothers me, its the 10-20MB of memory. All together, a fully loaded system takes up 30+MB (KDE-1, KDE-2, GNOME, and soon GNOME-2!) Even on a 128MB system, that's just too damn much for the OS to use up. The OS shouldn't use anything more than 10% of avaiable memory, after that its just sick. Not to mention the fact that while GNOME apps run on KDE, you don't get the full experience provided by a "desktop environment." While hacks to load KDE components on GNOME or run GNOME applets in KDE are available, they're just hacks, nothing more.
I would complain. Apps shouldn't require a particular toolkit, but should require the services of that toolkit to be available. On Windows, no app depends on having MS-OpenGL available, but having SOME OpenGL implementation available. Qt provides all the services available in GTK+, so GIMP should work transparently on Qt. Whoa, what a concept! Too bad whoever made shared libraries thought it up first...