Because that would be Compeltely Retarded(TM) >>>>> Umm, what's completely retarted as that GNOME consists of a dozen RPMS with circular dependencies! Components mean crap if you have to install everything anyway! (Especially bad on Mandrake. I tried installing ssh-server, and it asked to install XFree86!)
GTK+ has been pretty good with speed (as far as Linux goes). Does the 2.0 release make it worse or better? I just upgraded to a Athlon 1700+ and KDE-2 finally runs as fast as Win2K did on my PII-300. Some things, like resizing the web browser, are even a bit faster. Not as much as I was expecting for 5X the clock speed, but at least the Konqueror prefs panel opens about as fast as Word used to...
RPM, self-healing? My ass! RPM is like Microsoft software, it tends to break itself. It doesn't help that many packages basically *require* --force to install because of weird dependency issues (but they work fine afterwards). Besides, neither software heal's itself, you generally have to do it manually. (There is --rebuilddb for RPM, but you generally use that for when RPM hoses the database out and hangs when you try to install (or remove or query) any packages).
Geez, I hope BlueOS doesn't make the mistake of being closed source. For a commercial product, open vs. closed is perhaps debatable, for for a free project, open source is really the only way to make a project viable for the long term. As for binary compatibility, BlueOS might be able to do Linux binary compatibility, which would be good in itself. A think most existing BeOS applications would be recompiled if BlueOS ever became viable (since most of the BeOS developers were quite responsive to the user community) and providing compatibility with Linux/X apps would be useful while a native BlueOS application base built up. The situation would be something like that on OS-X, where older apps, while they don't "mesh" into the new OS, provide a transition base.
Actually, if you use a filesystem like XFS or ReiserFS that dynamically allocates the inodes, your only limit is disk space. In BeOS, each inode is the size of one block (usually 1KB) plus say 1 block of data (another 1KB). Thus, the total space for those 20,000 emails would only be 80MB per year. You could store a lifetime's worth of email without ever running out of space.
Yes, it can. BeOS's workspace feature is basically virtual desktops that can exist at different resolutions. It gets especially cool if you have a monitor that changes resolution without any noise or fuss (like most Sony ones). Then, going to a desktop with a different resolution is just as easy as CTRL-Fx.
Right... And size doesn't matter;) Seriously though, in this age of 400W power supplys, who cares about power usage? Hell, they've stuffed a P4 onto a laptop, so an Alpha can't be far behind...
A GUI that actually uses those checkmarked features! The Linux kernel is a great base for an OS. I think its rather stupid for the OpenBeOS guys to try to write their own kernel. Hell, even XFree86 is fairly decent in its 4.x form. Its everything above xlib that is keeping the Linux desktop behind.
Plently of comparison. File manager or 3D renderer, the UIs of most all program should be the same speed. It doesn't take any longer to open a menu in 3D Studio than it does to open one in explorer. Besides, what's more complex? A file manager or a p2p filesharing program? If its the former, then you're suffering from featuritis.
Have any benchmarks for that? First, half a second is a damn long time. Second, while IE6 will pop up windows as fast as CTRL-N will repeat, Galeon will make you wait for each one. I doubt its something with my install, since I've seen this weakness in EVERY SINGLE Linux distro I've ever tried, and FreeBSD too.
Umm, a new window in Konq (new-window from file menu) takes longer than a new tab in Galeon and several times longer than a new window in IE6. Hell, just opening the options menu in Konq incurs a very noticible delay.
I'm using tabs. Even then, creating a tab in Galeon takes several times longer than opening a whole new window (or three or five) in IE. After using Windows NT and BeOS for the last several years, I have very high expectations for OS speed, and few GUI apps on Linux cut it. Take, for example, ROX. Quite a fast little program. In BeOS, it would have been run-of-the-mill as far as speed goes. For god's sake, it was months before I even realized that the OS had a busy cursor!
Re:GUI without the GUTS
on
BeOS For Linux
·
· Score: 4, Interesting
You do know that Linux's thread model is pretty damn good itself. What was special about BeOS wasn't that it kernel, but the way it was designed. Take multithreading, for example. Linux probably handles apps with multiple threads just as well as BeOS, as long as you stick to 4 CPUs. Yet, multithreading is tons more useful on BeOS because people actually USE it. The thread-phobic UNIX developer community just doesn't take advantage of the responsiveness gains to be had through multithreading. Take Galeon for example. Where BeOS and Net+ were agressively multithreading, Galeon is agressively single-threaded. It seems like the developers did everything they could to make sure that while the browser was doing anything, the whole UI would freeze up. On my PII-300 MHz, surfing the web with dozens of windows open is no problem in BeOS or Windows 2000. Yet, with Linux/Galeon, it is torture because everything I open a complex page in a new tab, the rest of the galeon UI locks up for several seconds while the page renders. I think that this BlueOS project is the greatest thing ever. It takes what is great about Linux (the kernel and the hardware support) and merges it with what's great about BeOS (the UI and development model).
Umm, its fairly common to post your resume as a documentation of your credentials. It doesn't mean she's looking for a job. The context of the link on the main page should have told you that.
There is nothing wrong with competition. Its great that you can go and choose from all the different types of cars you can buy. However, incompatibility is bad. It's not like buying a Ford will limit you to using certain roads. Case in point. KDevelop is a far better IDE than Anjuta. Yet, Evolution is nicer than KMail. What to do? I'm not sadistic enough to run apps from both desktops (too un-asthetic), so I put up with Anjuta just to stay with GTK. The KDE/GNOME application landscape is rife with such choices. The base of GOOD Linux desktop applications is too slim to be divided up among multiple desktops. While I doubt there is anything that can be done about these multiple projects, but its a bad state of affairs nonetheless. Of course, none of this would be a problem if the desktop was in the X server, where ALL apps could use the same set of services, but apparently, nobody had heard of dynamic loading (to make the desktop a plug-in to the X server) when X was designed.
Hmm, on my 300MHz/256MB machine (my 1.5 GHz Athlon is in the mail;) Galeon running under IceWM absolutely crawls, while Windows 2000 + IE6 absolutely flies. Opening a new window in Galeon takes several seconds while a new IE window opens instantaneously. Surfing with dozens of windows open at the same time is absolute hell. There is no "may" about it. Speed-wise, GNOME and KDE are both pieces of shit.
I want all apps to look the same and act the same, at least to the extent they do on windows (I'm not even asking for MacOS-like integration here!) The current situation in Linux is pitiful. Hell, even searching is not standardized. Galeon by default uses CTRL-F while gedit uses F6!
When will people figure out the joys of context sensitive menus? Linux GUIs don't use them nearly enough. While they may add one level of indirection over a shortcut button (such as the middle-mouse crap) its a much more general and flexible method. The middle mouse button is too important to be held hostage to something as specific as copying text. It takes a millisecond to do right click->copy vs middle click (the real meat of the time is in the text selection) and there is no reason why it has taken so long for a decent right-click copy to be implemented. Of course, this is all moot anyway. All of this stuff should have been fully configurable from the beginning.
Damn lazy developers. This fear of multithreaded code is why Linux stuff like galeon is so horrendously single-threaded. BeOS might not have succeeded, but agressive multi-threading is something they got right. There might have been implementation issues, but the concept itself (which is rather effectively used in Windows 2000 as well, though its not hyped as such) but oh what a user experience!
Because parallization isn't the same thing as racheting up the clock speed. If everything else in the system scales (which it doesn't, generally) a 2GHz chip is exactly twice as fast as a 1GHz chip. However, a chip with 4 integer pipes (or two chips with two integer pipes) aren't twice as fast as one chip with two integer pipes, simply because a lot of the time only one can be working due to the serial nature of the code.
Umm, the SB Live! does 131 hardware channels. Also, network capability can be done without a server, it just requires intelligence on the part of the audio library.
Hmm, maybe its a matter of preference. I find the XML style easier as it is more word based rather than symbol based. Also, I think the structure of the file is much more readily apparent with XML than with standard UNIX config files. Of course, I'm one of those hierachical thinkers (you could probably describe my thought process in XML...) so it might just be me...
Slashdot Mirror
GNU HURD is nearly ready for a production release.
Debian finally moves to a 2.4 kernel.
Hell freezes over.
Because that would be Compeltely Retarded(TM)
>>>>>
Umm, what's completely retarted as that GNOME consists of a dozen RPMS with circular dependencies! Components mean crap if you have to install everything anyway! (Especially bad on Mandrake. I tried installing ssh-server, and it asked to install XFree86!)
GTK+ has been pretty good with speed (as far as Linux goes). Does the 2.0 release make it worse or better? I just upgraded to a Athlon 1700+ and KDE-2 finally runs as fast as Win2K did on my PII-300. Some things, like resizing the web browser, are even a bit faster. Not as much as I was expecting for 5X the clock speed, but at least the Konqueror prefs panel opens about as fast as Word used to...
RPM, self-healing? My ass! RPM is like Microsoft software, it tends to break itself. It doesn't help that many packages basically *require* --force to install because of weird dependency issues (but they work fine afterwards). Besides, neither software heal's itself, you generally have to do it manually. (There is --rebuilddb for RPM, but you generally use that for when RPM hoses the database out and hangs when you try to install (or remove or query) any packages).
Geez, I hope BlueOS doesn't make the mistake of being closed source. For a commercial product, open vs. closed is perhaps debatable, for for a free project, open source is really the only way to make a project viable for the long term. As for binary compatibility, BlueOS might be able to do Linux binary compatibility, which would be good in itself. A think most existing BeOS applications would be recompiled if BlueOS ever became viable (since most of the BeOS developers were quite responsive to the user community) and providing compatibility with Linux/X apps would be useful while a native BlueOS application base built up. The situation would be something like that on OS-X, where older apps, while they don't
"mesh" into the new OS, provide a transition base.
Actually, if you use a filesystem like XFS or ReiserFS that dynamically allocates the inodes, your only limit is disk space. In BeOS, each inode is the size of one block (usually 1KB) plus say 1 block of data (another 1KB). Thus, the total space for those 20,000 emails would only be 80MB per year. You could store a lifetime's worth of email without ever running out of space.
Yes, it can. BeOS's workspace feature is basically virtual desktops that can exist at different resolutions. It gets especially cool if you have a monitor that changes resolution without any noise or fuss (like most Sony ones). Then, going to a desktop with a different resolution is just as easy as CTRL-Fx.
Right... And size doesn't matter ;) Seriously though, in this age of 400W power supplys, who cares about power usage? Hell, they've stuffed a P4 onto a laptop, so an Alpha can't be far behind...
A GUI that actually uses those checkmarked features! The Linux kernel is a great base for an OS. I think its rather stupid for the OpenBeOS guys to try to write their own kernel. Hell, even XFree86 is fairly decent in its 4.x form. Its everything above xlib that is keeping the Linux desktop behind.
Plently of comparison. File manager or 3D renderer, the UIs of most all program should be the same speed. It doesn't take any longer to open a menu in 3D Studio than it does to open one in explorer. Besides, what's more complex? A file manager or a p2p filesharing program? If its the former, then you're suffering from featuritis.
Have any benchmarks for that? First, half a second is a damn long time. Second, while IE6 will pop up windows as fast as CTRL-N will repeat, Galeon will make you wait for each one. I doubt its something with my install, since I've seen this weakness in EVERY SINGLE Linux distro I've ever tried, and FreeBSD too.
Umm, a new window in Konq (new-window from file menu) takes longer than a new tab in Galeon and several times longer than a new window in IE6. Hell, just opening the options menu in Konq incurs a very noticible delay.
I'm using tabs. Even then, creating a tab in Galeon takes several times longer than opening a whole new window (or three or five) in IE. After using Windows NT and BeOS for the last several years, I have very high expectations for OS speed, and few GUI apps on Linux cut it. Take, for example, ROX. Quite a fast little program. In BeOS, it would have been run-of-the-mill as far as speed goes. For god's sake, it was months before I even realized that the OS had a busy cursor!
You do know that Linux's thread model is pretty damn good itself. What was special about BeOS wasn't that it kernel, but the way it was designed. Take multithreading, for example. Linux probably handles apps with multiple threads just as well as BeOS, as long as you stick to 4 CPUs. Yet, multithreading is tons more useful on BeOS because people actually USE it. The thread-phobic UNIX developer community just doesn't take advantage of the responsiveness gains to be had through multithreading. Take Galeon for example. Where BeOS and Net+ were agressively multithreading, Galeon is agressively single-threaded. It seems like the developers did everything they could to make sure that while the browser was doing anything, the whole UI would freeze up. On my PII-300 MHz, surfing the web with dozens of windows open is no problem in BeOS or Windows 2000. Yet, with Linux/Galeon, it is torture because everything I open a complex page in a new tab, the rest of the galeon UI locks up for several seconds while the page renders. I think that this BlueOS project is the greatest thing ever. It takes what is great about Linux (the kernel and the hardware support) and merges it with what's great about BeOS (the UI and development model).
What exactly am I supposed to do with a machine like that?
>>>>>>>>>>
Run GNOME at a decent speed?
Umm, its fairly common to post your resume as a documentation of your credentials. It doesn't mean she's looking for a job. The context of the link on the main page should have told you that.
There is nothing wrong with competition. Its great that you can go and choose from all the different types of cars you can buy. However, incompatibility is bad. It's not like buying a Ford will limit you to using certain roads. Case in point. KDevelop is a far better IDE than Anjuta. Yet, Evolution is nicer than KMail. What to do? I'm not sadistic enough to run apps from both desktops (too un-asthetic), so I put up with Anjuta just to stay with GTK. The KDE/GNOME application landscape is rife with such choices. The base of GOOD Linux desktop applications is too slim to be divided up among multiple desktops. While I doubt there is anything that can be done about these multiple projects, but its a bad state of affairs nonetheless. Of course, none of this would be a problem if the desktop was in the X server, where ALL apps could use the same set of services, but apparently, nobody had heard of dynamic loading (to make the desktop a plug-in to the X server) when X was designed.
Hmm, on my 300MHz/256MB machine (my 1.5 GHz Athlon is in the mail ;) Galeon running under IceWM absolutely crawls, while Windows 2000 + IE6 absolutely flies. Opening a new window in Galeon takes several seconds while a new IE window opens instantaneously. Surfing with dozens of windows open at the same time is absolute hell. There is no "may" about it. Speed-wise, GNOME and KDE are both pieces of shit.
Actually, Limewire (java) runs faster than Nautilus (ansi-C) on my P2-300. Retarded? Quite.
I want all apps to look the same and act the same, at least to the extent they do on windows (I'm not even asking for MacOS-like integration here!) The current situation in Linux is pitiful. Hell, even searching is not standardized. Galeon by default uses CTRL-F while gedit uses F6!
When will people figure out the joys of context sensitive menus? Linux GUIs don't use them nearly enough. While they may add one level of indirection over a shortcut button (such as the middle-mouse crap) its a much more general and flexible method. The middle mouse button is too important to be held hostage to something as specific as copying text. It takes a millisecond to do right click->copy vs middle click (the real meat of the time is in the text selection) and there is no reason why it has taken so long for a decent right-click copy to be implemented. Of course, this is all moot anyway. All of this stuff should have been fully configurable from the beginning.
Damn lazy developers. This fear of multithreaded code is why Linux stuff like galeon is so horrendously single-threaded. BeOS might not have succeeded, but agressive multi-threading is something they got right. There might have been implementation issues, but the concept itself (which is rather effectively used in Windows 2000 as well, though its not hyped as such) but oh what a user experience!
Because parallization isn't the same thing as racheting up the clock speed. If everything else in the system scales (which it doesn't, generally) a 2GHz chip is exactly twice as fast as a 1GHz chip. However, a chip with 4 integer pipes (or two chips with two integer pipes) aren't twice as fast as one chip with two integer pipes, simply because a lot of the time only one can be working due to the serial nature of the code.
Sure aRts could still SUPPORT software mixing, but should it force EVERYONE to use it?
Umm, the SB Live! does 131 hardware channels.
Also, network capability can be done without a server, it just requires intelligence on the part of the audio library.
Hmm, maybe its a matter of preference. I find the XML style easier as it is more word based rather than symbol based. Also, I think the structure of the file is much more readily apparent with XML than with standard UNIX config files. Of course, I'm one of those hierachical thinkers (you could probably describe my thought process in XML...) so it might just be me...