I don't like Ford cars. I don't like General Moters cars. I like Jaguars. Does this mean we should have totally seperate road systems for each type of car? Competing implementations + open, FORCED, standards (kinda like the road system?) is the best way to do things.
How said BeOS is better than Linux? I said "BeOS does threading better than Linux." If you've ever seen BeOS on an 8 proc machine, that's just plain true. BeOS also has quicker system response times, a faster graphics interface, a nicer, more consistant API, and innovative features up the wazoo (attributes, messaging, etc). Still, Linux has better (if not faster;) desktop environments, a better filesytem (XFS: like BFS, but bigger and faster!), less limitation in the kernel (32MB add-on limit in BeOS, 256MB library limit), better networking, and just plain more *stuff* (features and programs).
No, Motif forces you to use a standard implementation as well, not to mention the fact that its butt-ugly, and until recently, closed-source. There should be a standard API ala Motif, but not a standard implementation of that API (kinda like OpenGL, the actual implementation is system-dependant)
Its all subjective. Does an OS automatically become trash to you the first time you see the cursor jerk during a CPU intensive processes? I want to start and app and have it on my screen *now* no loading cursor, no nothing. KDE2 doesn't do that for me. While X overall is pretty slow, its not THAT slow.
A) It's BeOS, not BEOS.
B) Win*dows* is multi-tasking and has better threading than Linux. Next question.
C) BeOS has better use of threads and multiple processes than Linux as well.
D) I have no clue what your point is. I said that background processes providing services don't necessarily degrade system performance. You just used it as an excuse to trash Windows and spread misinformation about BeOS.
E) Do you know that your login-name is the same as the guy who wrote the famous Windows Programming Book (C. Petzold)
Right, I'm bitter. That's why I think that Gentoo Linux is the coolest thing since sliced bread, and that XFS is the creation of god. Get over it. I love BeOS, but Linux has so much potential, its just politics and small minds that's holding it back.
Oh, real mature. Thanks for your insightful contributions to a problem plaguing the Linux desktop.
"I can't think of a better idea than dozens of toolkits because my mind is too narrow to accept it. So I think I'll just trash an OS I don't understand!"
It is how X11 is defined. That's why I can use standard X apps with AcceleratedX or XFree without recompiling. If a standard API for the desktop environment was established (maybe pushed into X, maybe not. God knows that the XFree people have more clout than any of the commercial UNIX corps) then you could have all of the implementations and window managers and whatnot, without the incompatibiliy. Before GNOME and KDE, none of my apps cared what window manager I used. Starting with Enlightenment, apps started using DE-specific features, and the freedom to choose your environment went away.
There is obviously a lot of talk here about merging KDE and GNOME. That is not a good idea. There is also a lot of talk to keeping things like it is. Also, not a good idea. The only real way to solve this issue is create a standard desktop API that KDE or GNOME backends can plug in to. I've already espoused the idea dozens of times, and if you want details, look at my back-posts, especially the recent Art of UNIX Programming Thread. If there was an ABI that apps had to follow, then we could open the desktop environment to competition in quality, stability, etc, while still having a consistant desktop, and without fragmenting the application base.
Oh no! Background processes. They only reason you're not using KDE is because of background processes and themes (who says Linux users aren't as style obsessed as the rest of us?) Right now, with no programs running, I've got 17 processes running on BeOS, some with over half a dozen threads. Having background processes really doesn't have any relation to system performance, particularly in the case of Linux, where context switching is very fast.
Did the fix the one major problem with KDE-2, namely the fact that it takes a minumum of 2-3 seconds to start *any* program, no matter how simple? Used to getting split-second response times from even the largest apps under BeOS, KDE-2 is basically unusable for me. KDE-1 was never this slow on my system, so what up with 2?
That's my point. If a company makes fast cards with solid drivers at decent prices, why not advocate them? NVIDIA has its failings, but hell, I like them better than ATI who, until now, made slow cards with crappy drivers that were not worth half of what they cost. We need *more* companies like NVIDIA, closed drivers or not.
You oversimply my viewpoint, and thus get it wrong. There is a difference between the system enforcing policy, and the system enforcing a *particular* policy. In my example of the command line, one could concievable create an add-on that would create different exception based on the user's preferences. Since apps never see the actual command line, but the processed version of it, all apps would automatically accept the new changes.
Yea I know that takes some clever system design. I never said it was easy, just that it was possible.
Second, who said you one would have to use Athena? I'm a big fan of binary interfaces. This is one thing OpenGL gets right. All OpenGL apps are compiled to for the OpenGL ABI. The actual code that gets called varies from implementation to implementation, and in the Windows world, is entirely different for different cards. Yet it still works... wow! Actually, it's not wow, just good design. In the X case, one could have a standard API that all apps would have to write to (maybe a version controlled one like DirectX, so the API could expand) and different implementations could be plugged in at will. Again, it takes good design, but the longevity of UNIX has shown that some well designed stuff does stand the test of time in good shape, so it's not impossible.
I have a huge problem with his statement "the cost of this approach is that when the user can set policy, the user must set policy"
It is simply untrue. It should read
"But the cost of this approach is that application developers get to set policy"
Because UNIX does not enforce policy, policy gets enforced in other places. Specifically, it gets enforced in end-user apps. The problem is, that in this way, the only thing that happens is that an inconsistant/hacked up policy is exposed to the user, instead of a consistant one.
Think about it. Who gets to decide what toolkit you use? Not you, the user, but the app-developer who decides to use GTK. Who decides what desktop you use? Not you, but the Rasterman, who decided to make Enlightenment the only accelerated window manager. Who decides what command-line switches you use? Yep, whoever wrote the program.
The whole, fundemental, problem is that by not enforcing policy at the system level you simply allow the app-developers to decide it. You do didly for the non-programming user.
Consider this, instead of simply providing a text-stream for command line arguements, you provide a strictly-defined messaging interface. The app is just passed a set of messages that describe the command line. Then, the user can choose whatever command line format they want, and can depend on a dynamically loaded system add-on to convert the data.
Take the whole paradigm of message passing. It is an extremely strict interface, yet it allows the user huge flexibility. Take a GUI app for example. Instead of enforcing hotkey policies like Windows, UNIX leaves the developer free to do what they want. Instead, if apps were required to responed to strict message sets to use hotkeys, then the user could send a message from a remote server in Australia to activate the features, or map hotkeys to whatever buttons they chose, IN ANY APPLICATION.
It is a paradox. The more policy you enforce at the API level, the more freedom you give to the user. Yes its hard. Yes it takes a lot of forethought. Yes, it *can* be done. Force developers to use a particular API. Then give the user the freedom to chose any implementation of that API they wish. Force developers to use a standard set of services. Then give the user the freedom to mix and match, replace and rebuild those services as they see fit.
Nope, 1.0 GB partition near the front of the drive. I don't even have a fat32 partition handy;) (right now, my machine is pure BeOS, with Gentoo Linux/XFS being built on a spare partition)
Umm, MS got to be a monopoly by doing tricks like shafting OEMs for using alternate OSs. They got to be a monopoly by playing the API-of-the-day game with IBM. They got to be a monopoly by doing everything they could to get Netscape off of Windows. They got to be a monopoly by tieing vendors to the closed DirectX API.
NVIDIA cannot be a monopoly. Monopoly is more than just market share. NVIDIA, even if it gets 100% market share, cannot be a monopoly because it is based on open standards. They don't have anything like Glide to depend on. The minute somebody comes out with a faster card, they lose the top position. Simple as that.
I never said I was happy about the Be thing. But I can't ignore their fast cards, solid drivers and decent prices. If I did, I'd be as much of a zealot as those (free or DIE!) OSS monkeys. I can buy a Radeon II to support my OS, but that doesn't mean I have to be mad at NVIDIA.
Umm, what do you think that 256MB file called.swap is for? Either way, BeOS does whip QNX on several fronts, like messaging througput (1/2 of system-memory speed for large messages), filesystem througput (and features), media interface, etc, but QNX beats BeOS in terms of GUI features, networking features, cool Plan9-like namespace features, etc. Having used both, I'd have to give the nod to BeOS, but QNX is quite good, if they'd ever get a decent FS.
Slashdot Mirror
I want to erase GTK as well. I want to have a 100% KDE-only system. How can I do that?
Ah, but all programs run on all shells. Using csh doesn't preclude me from running XFree86. Using KDE (and ONLY KDE) precludes me from running GIMP.
I'm not the original poster, but I want compatibility as in I can erase GTK and GNOME-libs and still use GIMP.
I don't like Ford cars. I don't like General Moters cars. I like Jaguars. Does this mean we should have totally seperate road systems for each type of car? Competing implementations + open, FORCED, standards (kinda like the road system?) is the best way to do things.
How said BeOS is better than Linux? I said "BeOS does threading better than Linux." If you've ever seen BeOS on an 8 proc machine, that's just plain true. BeOS also has quicker system response times, a faster graphics interface, a nicer, more consistant API, and innovative features up the wazoo (attributes, messaging, etc). Still, Linux has better (if not faster ;) desktop environments, a better filesytem (XFS: like BFS, but bigger and faster!), less limitation in the kernel (32MB add-on limit in BeOS, 256MB library limit), better networking, and just plain more *stuff* (features and programs).
No, Motif forces you to use a standard implementation as well, not to mention the fact that its butt-ugly, and until recently, closed-source. There should be a standard API ala Motif, but not a standard implementation of that API (kinda like OpenGL, the actual implementation is system-dependant)
Its all subjective. Does an OS automatically become trash to you the first time you see the cursor jerk during a CPU intensive processes? I want to start and app and have it on my screen *now* no loading cursor, no nothing. KDE2 doesn't do that for me. While X overall is pretty slow, its not THAT slow.
What are you talking about?
A) It's BeOS, not BEOS.
B) Win*dows* is multi-tasking and has better threading than Linux. Next question.
C) BeOS has better use of threads and multiple processes than Linux as well.
D) I have no clue what your point is. I said that background processes providing services don't necessarily degrade system performance. You just used it as an excuse to trash Windows and spread misinformation about BeOS.
E) Do you know that your login-name is the same as the guy who wrote the famous Windows Programming Book (C. Petzold)
Right, I'm bitter. That's why I think that Gentoo Linux is the coolest thing since sliced bread, and that XFS is the creation of god. Get over it. I love BeOS, but Linux has so much potential, its just politics and small minds that's holding it back.
Oh, real mature. Thanks for your insightful contributions to a problem plaguing the Linux desktop.
"I can't think of a better idea than dozens of toolkits because my mind is too narrow to accept it. So I think I'll just trash an OS I don't understand!"
It is how X11 is defined. That's why I can use standard X apps with AcceleratedX or XFree without recompiling. If a standard API for the desktop environment was established (maybe pushed into X, maybe not. God knows that the XFree people have more clout than any of the commercial UNIX corps) then you could have all of the implementations and window managers and whatnot, without the incompatibiliy. Before GNOME and KDE, none of my apps cared what window manager I used. Starting with Enlightenment, apps started using DE-specific features, and the freedom to choose your environment went away.
There is obviously a lot of talk here about merging KDE and GNOME. That is not a good idea. There is also a lot of talk to keeping things like it is. Also, not a good idea. The only real way to solve this issue is create a standard desktop API that KDE or GNOME backends can plug in to. I've already espoused the idea dozens of times, and if you want details, look at my back-posts, especially the recent Art of UNIX Programming Thread. If there was an ABI that apps had to follow, then we could open the desktop environment to competition in quality, stability, etc, while still having a consistant desktop, and without fragmenting the application base.
Oh no! Background processes. They only reason you're not using KDE is because of background processes and themes (who says Linux users aren't as style obsessed as the rest of us?) Right now, with no programs running, I've got 17 processes running on BeOS, some with over half a dozen threads. Having background processes really doesn't have any relation to system performance, particularly in the case of Linux, where context switching is very fast.
Did the fix the one major problem with KDE-2, namely the fact that it takes a minumum of 2-3 seconds to start *any* program, no matter how simple? Used to getting split-second response times from even the largest apps under BeOS, KDE-2 is basically unusable for me. KDE-1 was never this slow on my system, so what up with 2?
IBM isn't the entire ATA commitie. Intel has a big part, and they've already said that copy protection would *not* make it into ATA for harddrives.
That's my point. If a company makes fast cards with solid drivers at decent prices, why not advocate them? NVIDIA has its failings, but hell, I like them better than ATI who, until now, made slow cards with crappy drivers that were not worth half of what they cost. We need *more* companies like NVIDIA, closed drivers or not.
You oversimply my viewpoint, and thus get it wrong. There is a difference between the system enforcing policy, and the system enforcing a *particular* policy. In my example of the command line, one could concievable create an add-on that would create different exception based on the user's preferences. Since apps never see the actual command line, but the processed version of it, all apps would automatically accept the new changes.
Yea I know that takes some clever system design. I never said it was easy, just that it was possible.
Second, who said you one would have to use Athena? I'm a big fan of binary interfaces. This is one thing OpenGL gets right. All OpenGL apps are compiled to for the OpenGL ABI. The actual code that gets called varies from implementation to implementation, and in the Windows world, is entirely different for different cards. Yet it still works... wow! Actually, it's not wow, just good design. In the X case, one could have a standard API that all apps would have to write to (maybe a version controlled one like DirectX, so the API could expand) and different implementations could be plugged in at will. Again, it takes good design, but the longevity of UNIX has shown that some well designed stuff does stand the test of time in good shape, so it's not impossible.
I have a huge problem with his statement "the cost of this approach is that when the user can set policy, the user must set policy"
It is simply untrue. It should read
"But the cost of this approach is that application developers get to set policy"
Because UNIX does not enforce policy, policy gets enforced in other places. Specifically, it gets enforced in end-user apps. The problem is, that in this way, the only thing that happens is that an inconsistant/hacked up policy is exposed to the user, instead of a consistant one.
Think about it. Who gets to decide what toolkit you use? Not you, the user, but the app-developer who decides to use GTK. Who decides what desktop you use? Not you, but the Rasterman, who decided to make Enlightenment the only accelerated window manager. Who decides what command-line switches you use? Yep, whoever wrote the program.
The whole, fundemental, problem is that by not enforcing policy at the system level you simply allow the app-developers to decide it. You do didly for the non-programming user.
Consider this, instead of simply providing a text-stream for command line arguements, you provide a strictly-defined messaging interface. The app is just passed a set of messages that describe the command line. Then, the user can choose whatever command line format they want, and can depend on a dynamically loaded system add-on to convert the data.
Take the whole paradigm of message passing. It is an extremely strict interface, yet it allows the user huge flexibility. Take a GUI app for example. Instead of enforcing hotkey policies like Windows, UNIX leaves the developer free to do what they want. Instead, if apps were required to responed to strict message sets to use hotkeys, then the user could send a message from a remote server in Australia to activate the features, or map hotkeys to whatever buttons they chose, IN ANY APPLICATION.
It is a paradox. The more policy you enforce at the API level, the more freedom you give to the user. Yes its hard. Yes it takes a lot of forethought. Yes, it *can* be done. Force developers to use a particular API. Then give the user the freedom to chose any implementation of that API they wish. Force developers to use a standard set of services. Then give the user the freedom to mix and match, replace and rebuild those services as they see fit.
Nope, 1.0 GB partition near the front of the drive. I don't even have a fat32 partition handy ;) (right now, my machine is pure BeOS, with Gentoo Linux/XFS being built on a spare partition)
Umm, MS got to be a monopoly by doing tricks like shafting OEMs for using alternate OSs. They got to be a monopoly by playing the API-of-the-day game with IBM. They got to be a monopoly by doing everything they could to get Netscape off of Windows. They got to be a monopoly by tieing vendors to the closed DirectX API.
NVIDIA cannot be a monopoly. Monopoly is more than just market share. NVIDIA, even if it gets 100% market share, cannot be a monopoly because it is based on open standards. They don't have anything like Glide to depend on. The minute somebody comes out with a faster card, they lose the top position. Simple as that.
I never said I was happy about the Be thing. But I can't ignore their fast cards, solid drivers and decent prices. If I did, I'd be as much of a zealot as those (free or DIE!) OSS monkeys. I can buy a Radeon II to support my OS, but that doesn't mean I have to be mad at NVIDIA.
Well, they wouldn't give Be specs for the cards either. Maybe they are afraid of BeOS competing with the SGI-blessed workstation OS, Linux?
;)
I wish
Kernel Driver
GL Files
They compile and work fine on my CVS build of the 2.4.1-XFS tree.
Umm, what do you think that 256MB file called .swap is for? Either way, BeOS does whip QNX on several fronts, like messaging througput (1/2 of system-memory speed for large messages), filesystem througput (and features), media interface, etc, but QNX beats BeOS in terms of GUI features, networking features, cool Plan9-like namespace features, etc. Having used both, I'd have to give the nod to BeOS, but QNX is quite good, if they'd ever get a decent FS.
He said as he downloaded the free binaries.