Trailing behind the POS that is Windows98 by more than 10% (at the higher res tests, more like 25%) is DEFINATELY bad! I gets even worse. This disparity gets bigger when you note that QuakeIII frame-rates in NT4 are even faster (by about 10-15%) than in Win98.
The difference between Linux and Windows at 1280x1024 on the GF2 is the difference between playable framerates and unplayable framerates. 'nuff said.
Actually, I think I need to cogitate more. The NVIDIA Linux drivers are pulled from more or less the same source as the Windows Linux drivers. This means code-wise, the two are fairly even in terms of performance tweeks. Now the Linux drivers will gain a little bit as NVIDIA tweeks glue between the drivers and OS, but I doubt the speed will ever reach that of Windows. Now page-flipping could be one of the things holding back the Linux drivers, but note that even at the lower-res tests, Linux is still behind. All this ignores one point: Shouldn't Linux be undeniable FASTER? Why use the OS of it is only just ALMOST as fast as Windows. Windows is a piece of junk. Why can't Linux beat it?
Uh no. SSE is uses 128bit registers, 3DNow! uses 64bit registers. SSE contains more instructions that does 3DNow! Those two facts alone mean they cannot be clones.
Doesn't it only support 8? Or did they change the constant in R5?
Re:Everyone should speak and write Latin
on
A Transmeta Couplet
·
· Score: 1
Luther wrote in Latin as did most of the Catholic church. Given the fact that most of the educated people of the time were in the clergy, the educated people DID use Latin. Calvin was one of the major guys to write in a non-Latin language. I believe that some of Newtons stuff was written in Latin too (don't quote me on that!)
Just "interesting?" If Microsoft pulled a similar stunt, you guys would be up in arms. Face it, the activities of RedHat recently should really worry the OSS community.
I really doubt there will ever be one distribution. However, I DO think that there will one day be a standard where it really won't matter what distribution you are using. That standard is inevitable, as business users adopt Linux, they will likely buy the same distro. Also, commercial software will only support one distro. You are already seeing the results of this with the popularity of RedHat and its RPM bretheren. Of course, RedHat will continue to be buggy, Slackware continue to be svelte, Mandrake continue to be optimized, and Debian continue to be outdated (no flames from the Debian guys please;) but they will adopt a consistant standard so it won't matter which distro you run.
decent kernel compiled with knowing just a little about what they need (ie if you can't identify it, you don't need it usually).
>>>>>>>>>
Really? I remember when I compiled my first few kernels, I had no clue what TCP/IP did (I wasn't on a network) and I left TCP/IP and networking completely out of the kernel. Then I spent a couple of days wondering why the hell X wasn't working.
Again, you overestimate the power of OSS. OSS developers have almost the same amount of pressure to get a release out as do commercial developer. Paying for a long project is only one reason why commercial developers push out releases early. Other reasons, ones that OSS developers are prone to as well are,
A) Expectations of the people. If somebody said that something was coming out in January, and it comes out in November, a lot of people are going to be pissed. In the real world, you can't afford to piss of your userbase.
B) Competition. If it looked like FreeBSD 5.0 would be out three months before 2.4 would be ready, and it would have tons more features, you can bet that the devs would be under pressure to get 2.4 out the door. Nobody, including OSS developers, wants their software to be obsolete the minute it comes out.
C) Getting bored. Long projects are seriously dull. The longer a project like the kernel wears on in the bug-fix stage (without sexy features to work on) the more tired people are going to be of it, and the more likely they will be to release it.
If you need proof that OSS isn't a magic bullet, take a look at Diakatana. Their parent company really didn't do much to force them to release the thing, and they had tons of time for development. Yet, the product was still released prematurely. OSS prevents a company from breathing down your neck about how much the project is costing. All the other factors are still a problem.
What really irks me is that this kernel is already in -test. What exactly have they been doing to a test kernel? Wasn't the feature freeze months ago? I remember that the 2.2-test series was like a month long. Methinks that someobody was so eager to get 2.4 out the door, that they went to 2.4-test prematurely.
You're argueing that BeOS is harder to use than Linux?
Seriously though, if you are designing a program that will be used on both BeOS and UNIX, you can just NOT USE ATTRIBUTES. They are an immensly useful mechanism on the BeOS, and if you ask any BeOS user, they'll tell you how much you love it. If you haven't used BeOS, how can you comment that it is really not worth putting in attributes? Also, your "solution" to this causes more problems that it solves. At least with attributes, the file remains compatible with existing software. They won't be able to use the extra features, but a gif is still a gif. If you embed gamma information into the file itself, you have essentially either
A) Forked the file format, and/or
B) Tied to file to being read with only one app-level library.
Neither solution is a very "portable" one. I think it is a much better idea to handle those special cases where attributes need to be ported (maybe by making two files out of one attributed file) than to leave out the power of attributes all together. Lastly, attributes (and stroing user, date, creator, whatver) data inside files makes a lot of sense. A file is DATA. Attributes are data ABOUT the data. Two files with different metadate are still contain the exact same data. By using an attribute type mechanism, you maintain some sembelence of structure.
Either way, the point is moot. What matters is that attributes work, and they work well. I'll give you a concrete example of the unique power of attributes:
I'm writing an installer program for BeOS. Normally, I'd have to set up a database file and write code to access, search, and change that file. I don't really feel like coding all that, and I don't like the idea of centralized file info. Instead, I use attributes. I store all installation info inside the attributes of an application folder, and I use the built in query system to automatically detect any installation on the system. Saves me a lot of monotonous coding, and gives the system some cool features (built in seaching without any code on my part, automatic finding of packages anywhere in the system, automatic updating of the database when the folder is moved, the ability to automatically detect dependencies even if they aren't in an installed package, etc.) Sure you could do this stuff without attributes, but it makes my life so much more simple!
"I'm completely fed up with this [windowing system]. I don't see why we need [windowing systems] with 8 diff modes of operation so they can be [source] compatible with software from the 80's. Why can't people make a move to [modern] arc in the PC industry w/o having to have everything be compatible. Can't the major companies who only distribute binaries afford to dist a [BeOS app_server version], a [Berlin version], and another new arch? XFree86, Xig, MetroX, should just give up on this crappy [windowing system] argh."
NT USED to be architecture neutral. Recently though, they gave up the Alpha port (which was really the only port still production quality) and is now more or less x86 only.
Ah, somebody is reading too much into this. RPM works on several other distros too, is AMD in bed with all of them too? (The slut!) I just think they released RPM for two reasons
A) RPM is the most common format for "mainstream" Linux.
B) RedHat is the most common "mainstream" distro.
They have no intention (and nobody really expects them to) to support every bloody distro out there. If you are 'leet enough to use a different distro, then you can figure out how to have alien convert it.
That't the problem with Linux. Rather than being goal oriented, they are people oriented. (It works for me, so it must be great!) All to often, the developers serve their own needs and those of whose needs coincides with theirs. You'd think OSS would be a place of innovation and new technology wouldn't you?
While your're right on the first two points, you're wrong about COM. COM is terribly usefull, when used appropriatly (and as a replacement for C++ objects, which MS is touting them to be isn't one of the correct ways.) COM wasn't designed to be a GP object model. It wasn't designed to be subclassed. What is was designed to do was make major components of applications easily replacable and upgradable. That is a genuinely good idea and Mozilla uses it to (in the form of XPCom.) DirectX is the perfect example. It is stupid to complain why you can subclass from IDirect3DDevice7 because that's not what it was designed to do. Its like asking why you can't subclass from the C functions in OS.h (for non-Be users, that implements a lot of kernel level C interface for BeOS) What COM does in this case is make DirectX easily upgradable. So far, DirectX has gone through 5 (going on 6) revisions. It has been totally overhauled more than once, and has gone from a POS to a super-sexy API (if you can understand it.) One thing that made it possible was COM. By tightly defining the interface between components, DirectX has been able to stay more or less backwards compatible without resorting to multiple libraries for the different versions (one major thing that pisses me off, that kdelibs-1.x and kdelibs 2.x aren't compatible) This idea would be great used in a lot of other places. For example, it could be used to define the app->Desktop environment protocol. That way, you could totally replace KDE with GNOME, and all your apps would continue to work (as long as both GNOME and KDE strictly followed the protocol.) Each would still be seperate projects, and still having vastly different strenghts and weaknesses, but we wouldn't have to have both installed. (Think of it as TCP/IP for the local system.) COM isn't a very big hack at all. You can duplicate much of its functionality (for in-proc servers) through dynamically loadable libraries (add-ons for those Be folks.) You create an abstract class, and use that in the client program. Then you have a class implement that interface, and compile it into a add-on. You use some kind of mechanism to give an app the name of a particular add-ons, and then import a function to pass an instance of the implementing class to the calling program. Voila, everything works quite well. Of course, if you use the other 90% of the COM/OLE API, then god help you. However, if you do that, you get what you deserve.
So, you know very little about Linux, yet you have no problem pointing out all the things it does wrong.
>>>>>>>>>>>
Right. Do you know what a media-node in BeOS is? And you feel that you have the right to critisze it? YES YOU DO! If you've used it, and it doesn't work well, then you have every right to critisize it! I speak from a users point of view (and having used Linux for many years, I think I'm entitled to an opinion). If a user needs to know what a super-block is, then the developer is doing something wrong.
Because they're not portable. They don't work on other systems. Anything that depends on them will not be portable to other
systems. Thus, attributes aren't portable.
>>>>>>>>>>>
Huh? You do realize that you have to define the word "portable" without using the word itself!
You complain constantly about all of the "Linux zealots" who ignore problems in their favorite OS, yet you seem to be the biggest
perpetrator of that particular vice.
>>>>>>>>>>>>>
Really? Would you care to show me when? As I remember, I posted reason why BeOS is not as advanced as QNX the other day, and I posted 9 or 10 problems with BeOS on BeNews. Of course I don't pay attention to useless posts like "BeOS is dying!" or "BeOS has no software!" but everytime I have had an intelligent criticism (like that guy who could only play 8 or 9 MP3s at the same time on BeOS. Turned out to be that I was using SoundPlay, and he MediaPlayer) I responed. Even in my post I pointed out (from the bonnie benchmark) that BeOS had problems with the VM. What more do you want?
...ID3 information is injected into attributes...
Gee, like how it is already embedded in the MP3 itself? Next you'll be saying attributes can also store the title of an HTML
document. What progress!
>>>>>>
Yea, but you can't search based on stuff stored inside the MP3. (If stuff isn't in a central database) And you can have your file-viewer autmotically display that info.
This is true, but does it apply? Are BeOS attributes really trying to improve things, or are they trying to pull that favorite industry
tactic of locking us into a single vendor? (I actually suspect the former, but I have to consider the possibility.)
>>>>>>
Really? Let's see. MacOS X, NeXTSTep, and BeOS all use something similar to attributes. Hell, UNIX uses it in the form of attribute bits (owner, group, date, etc.) Take for example, an installer I'm writing. Instead of having an ugly central database, all uninstall info is stored inside a folder's attributes. No more rebuilding the RPM database. That's just plain cool!
The case can be made that application-level attributes do not belong in the system, but in application-level libraries. By keeping such
information in the files themselves, they are easily transfered to other systems, and do not require system-level support. Meanwhile,
you can still provide a standard API to get at the information with an application-library. Thus, you get the best of both worlds.
>>>>>>>
No, because then there would be 3 dozen different APIs to do the thing. And if it is so easy, then why hasn't Linux done it yet? Plus, by putting it as part of the base system, it makes it much more likely that developers will use it. This is a big help because it allows nifty, usefull features to be implemented in all apps and allows a level of *UNITY* you just don't get in Linux. (Similar to BeOS's universal app scripting, sure you can do it in Linux, but by making it part of the OS, many more developers use the feature.)
No you wouldn't. Slashdot has had countless stories about such things, but you continue your tired crusade every chance you get.
Meanwhile, you will happily ignore yet another legitimate complaint about your favorite OS: That anyone using it is locked into a
single-vendor solution.
>>>>>>>
All Slashdot posts are OSS people saying how OSS is great. And to date, I have not heard from anyone important that propriotary software is dead. Even most OSS people say that they can live harmoniously.
Lines of code isn't a terribly accurate measurement of code bloat. Perhaps those 1.5 million "extra"
lines in Linux go to support things BeOS does not. Drivers. Platforms. Features. Stability. Security.
Whatever. Maybe they're documentation. Maybe they're copyright notices. But then, we really don't
know, do we? We can't know, because BeOS holds us hostage with its source code.
>>>>>>>>>>>>>>>>>
I know lines-of code isn't an accurate measurement. Most of the stuff is features that BeOS doesn't, and probably won't ever, have. I was defending the Linux kernel, don't piss me off. I brought up BeOS just to put things in prespective.
The nice thing about Linux is that nobody is forcing you to run all that "crap", as you so eloquently
put it. If you want a stripped-down, bare-bones system with nothing but X11 and a single app, you
can do that. Don't need the GUI? You can toss that, too. If you have the horsepower and the desire,
you can also run GNOME with Enlightenment and every silly graphics effect you can think of
turned on, plus sixteen different versions of Mozilla at once. Your choice.
>>>>>>>>>>>>>
No, it's not my choice. I want to run gnumeric. Do I have any other choice than to run GNOME (or GNOME inside KDE, or inside TWM or whatever, the RAM requirement is still obscene)??? You don't have a choice! You have to run what the developers want you to run, and if you need gnumeric, or KOffice, or KDevelop, or Mozilla, you have to put up with all the addendant baggage they carry. That's why I favor slim, standardized base systems so much. In the real world, (as opposed the the best case world Linux users seem to live in ie: where everyone can hack the kernel, and change apps to different toolkits on whim) they allow a user much more flexibility in what programs they can run without incurring more bloat. That doesn't necessarily mean one DE. There can be a hundred DEs, as long as they are all binary compatible (you know, kind of like the way it was with those dozens of window managers. I could run any Linux app back then, and have only one WM installed.)
Your analogy is wrong. GNOME is the road, the software is the car.
You analogy equates to:
If your favorite program is GNOME, than you have no choice but to run GNOME. If your favorite company is microsoft, you have no choice but to run Windows.
The correct analogy is:
If your fave program is GNOME, you have no choice other than to run GNOME. If your fave car is Porsche (american cars? Bah!) , you can run it on whatever damn road you please.
I can run my Japanese car on my American roads without importing Japanese roads. And if I move my Japanese car to German roads, I automatically get the benifits that German roads provide. You just don't do that with GNOME and KDE (or most other software) Sure your running KDE, but the app is still running GNOME, and has all the issues that made you run KDE in the first place. The software industry is *FAR* behind the rest of the world in making products interworkable.
First of all, if we except your rather flawed reasoning, then anyone who runs programs they didn't write are slaves. That includes you and your favorite OS.
>>>>>>>>>>>>>>>>
Yea, I know, all software users are slaves. What's your point? Does Slashdot automatically append a "none of this applies for BeOS which is perfect" message to all my posts?
But again, your reasoning is flawed. I can run KDE programs and GNOME programs and old Xt programs and even terminal programs, all at the same time. I
need to have all the libraries a program requires installed, yes, but go ahead and show me a program that will run without a library it needs.
>>>>>>>>>>>>>>>.
It shouldn't have to be that way! I can plug any electric product into any outlet and be reasonably sure it will work. I don't have to have other types of outlets installed in order for it to work. I can buy nails and use them with any hammer, without buying multiple hammers for nails only compatible with one type of hammer.I can buy a Japaneese car without importing Japaneese roads, so why can't all my programs run on whatever DE I choose? Sure this is idealistic, but the software industry is *FAR* behind the rest of the consumer industries in friendlieness. The problem is, everything else has a standard interface. A hammer works on any type of nail mainly because the hammer->nail interface is constant. A road works with any car, because the road->car interface is constant. I can buy a hair-dryer and have it work with any type of hair because the hair->dryer interface is nostant. Going to an even more practical level, I can buy any pair stereo speakers, and be sure they work with my stereo (mostly.) I don't have to worry about what the speaker->stereo interface is, and I don't have to buy multiple stereos for each type of speaker.
Better still, since most of this stuff is Open Source, we can take the program and re-write it to use the desktop environment of our choice. We can even
change the desktop environment if we need to.
>>>>>>>>>>>>>
Yea, and I can leave Iraq if I want to. Just sneak out without Sadam noticing, and get into the US without Uncle Sam noticing. The "But you've got the source!" arugement is just a cop out. Its not really a practical method for getting user input into the software. Does your car manufacturer ask you to submit.diffs to add features you want to his car? Hell no! You write a letter, and the next model year, you've got 20 cup-holders. The problem is programmers write for programmers, and not users. Take half the features in GNOME. They're there because it makes the programmers feel ELITE, not because the users asked for them.
With BeOS, on the other hand, you're locked in, and cannot change it. Sounds like you're the real slave to me
>>>>>>>>>>>>
Excuse me? When does it take an OSS OS to write OSS apps? The BeOS GUI is OpenSource, the architecture is very open (so you can modify the system quit extensivly through add-ons) and there is no clause saying "thou shalt not write OSS apps on BeOS." You can't much with the system, but you can do just about everything else. And all of that is irrelevant. In BeOS, Linux, whatever, its the programmers deciding what you should do, not the users. (Actually, BeOS programs, like other small programming projects, tend to be much more receptive to user demands than larger projects like GNOME.)
Slashdot Mirror
Trailing behind the POS that is Windows98 by more than 10% (at the higher res tests, more like 25%) is DEFINATELY bad! I gets even worse. This disparity gets bigger when you note that QuakeIII frame-rates in NT4 are even faster (by about 10-15%) than in Win98.
The difference between Linux and Windows at 1280x1024 on the GF2 is the difference between playable framerates and unplayable framerates. 'nuff said.
Actually, I think I need to cogitate more. The NVIDIA Linux drivers are pulled from more or less the same source as the Windows Linux drivers. This means code-wise, the two are fairly even in terms of performance tweeks. Now the Linux drivers will gain a little bit as NVIDIA tweeks glue between the drivers and OS, but I doubt the speed will ever reach that of Windows. Now page-flipping could be one of the things holding back the Linux drivers, but note that even at the lower-res tests, Linux is still behind. All this ignores one point: Shouldn't Linux be undeniable FASTER? Why use the OS of it is only just ALMOST as fast as Windows. Windows is a piece of junk. Why can't Linux beat it?
Uh no. SSE is uses 128bit registers, 3DNow! uses 64bit registers. SSE contains more instructions that does 3DNow! Those two facts alone mean they cannot be clones.
Doesn't it only support 8? Or did they change the constant in R5?
Luther wrote in Latin as did most of the Catholic church. Given the fact that most of the educated people of the time were in the clergy, the educated people DID use Latin. Calvin was one of the major guys to write in a non-Latin language. I believe that some of Newtons stuff was written in Latin too (don't quote me on that!)
Just "interesting?" If Microsoft pulled a similar stunt, you guys would be up in arms. Face it, the activities of RedHat recently should really worry the OSS community.
I really doubt there will ever be one distribution. However, I DO think that there will one day be a standard where it really won't matter what distribution you are using. That standard is inevitable, as business users adopt Linux, they will likely buy the same distro. Also, commercial software will only support one distro. You are already seeing the results of this with the popularity of RedHat and its RPM bretheren. Of course, RedHat will continue to be buggy, Slackware continue to be svelte, Mandrake continue to be optimized, and Debian continue to be outdated (no flames from the Debian guys please ;) but they will adopt a consistant standard so it won't matter which distro you run.
decent kernel compiled with knowing just a little about what they need (ie if you can't identify it, you don't need it usually).
>>>>>>>>>
Really? I remember when I compiled my first few kernels, I had no clue what TCP/IP did (I wasn't on a network) and I left TCP/IP and networking completely out of the kernel. Then I spent a couple of days wondering why the hell X wasn't working.
Again, you overestimate the power of OSS. OSS developers have almost the same amount of pressure to get a release out as do commercial developer. Paying for a long project is only one reason why commercial developers push out releases early. Other reasons, ones that OSS developers are prone to as well are,
A) Expectations of the people. If somebody said that something was coming out in January, and it comes out in November, a lot of people are going to be pissed. In the real world, you can't afford to piss of your userbase.
B) Competition. If it looked like FreeBSD 5.0 would be out three months before 2.4 would be ready, and it would have tons more features, you can bet that the devs would be under pressure to get 2.4 out the door. Nobody, including OSS developers, wants their software to be obsolete the minute it comes out.
C) Getting bored. Long projects are seriously dull. The longer a project like the kernel wears on in the bug-fix stage (without sexy features to work on) the more tired people are going to be of it, and the more likely they will be to release it.
If you need proof that OSS isn't a magic bullet, take a look at Diakatana. Their parent company really didn't do much to force them to release the thing, and they had tons of time for development. Yet, the product was still released prematurely. OSS prevents a company from breathing down your neck about how much the project is costing. All the other factors are still a problem.
What really irks me is that this kernel is already in -test. What exactly have they been doing to a test kernel? Wasn't the feature freeze months ago? I remember that the 2.2-test series was like a month long. Methinks that someobody was so eager to get 2.4 out the door, that they went to 2.4-test prematurely.
You're argueing that BeOS is harder to use than Linux?
Seriously though, if you are designing a program that will be used on both BeOS and UNIX, you can just NOT USE ATTRIBUTES. They are an immensly useful mechanism on the BeOS, and if you ask any BeOS user, they'll tell you how much you love it. If you haven't used BeOS, how can you comment that it is really not worth putting in attributes? Also, your "solution" to this causes more problems that it solves. At least with attributes, the file remains compatible with existing software. They won't be able to use the extra features, but a gif is still a gif. If you embed gamma information into the file itself, you have essentially either
A) Forked the file format, and/or
B) Tied to file to being read with only one app-level library.
Neither solution is a very "portable" one. I think it is a much better idea to handle those special cases where attributes need to be ported (maybe by making two files out of one attributed file) than to leave out the power of attributes all together. Lastly, attributes (and stroing user, date, creator, whatver) data inside files makes a lot of sense. A file is DATA. Attributes are data ABOUT the data. Two files with different metadate are still contain the exact same data. By using an attribute type mechanism, you maintain some sembelence of structure.
Either way, the point is moot. What matters is that attributes work, and they work well. I'll give you a concrete example of the unique power of attributes:
I'm writing an installer program for BeOS. Normally, I'd have to set up a database file and write code to access, search, and change that file. I don't really feel like coding all that, and I don't like the idea of centralized file info. Instead, I use attributes. I store all installation info inside the attributes of an application folder, and I use the built in query system to automatically detect any installation on the system. Saves me a lot of monotonous coding, and gives the system some cool features (built in seaching without any code on my part, automatic finding of packages anywhere in the system, automatic updating of the database when the folder is moved, the ability to automatically detect dependencies even if they aren't in an installed package, etc.) Sure you could do this stuff without attributes, but it makes my life so much more simple!
"I'm completely fed up with this [windowing system]. I don't see why we need [windowing systems] with 8 diff modes of operation so they can be [source] compatible with software from the 80's. Why can't people make a move to [modern] arc in the PC industry w/o having to have everything be compatible. Can't the major companies who only distribute binaries afford to dist a [BeOS app_server version], a [Berlin version], and another new arch? XFree86, Xig, MetroX, should just give up on this crappy [windowing system] argh."
;)
I just answered your own question
NT USED to be architecture neutral. Recently though, they gave up the Alpha port (which was really the only port still production quality) and is now more or less x86 only.
Ah, somebody is reading too much into this. RPM works on several other distros too, is AMD in bed with all of them too? (The slut!) I just think they released RPM for two reasons
A) RPM is the most common format for "mainstream" Linux.
B) RedHat is the most common "mainstream" distro.
They have no intention (and nobody really expects them to) to support every bloody distro out there. If you are 'leet enough to use a different distro, then you can figure out how to have alien convert it.
That't the problem with Linux. Rather than being goal oriented, they are people oriented. (It works for me, so it must be great!) All to often, the developers serve their own needs and those of whose needs coincides with theirs. You'd think OSS would be a place of innovation and new technology wouldn't you?
While your're right on the first two points, you're wrong about COM. COM is terribly usefull, when used appropriatly (and as a replacement for C++ objects, which MS is touting them to be isn't one of the correct ways.) COM wasn't designed to be a GP object model. It wasn't designed to be subclassed. What is was designed to do was make major components of applications easily replacable and upgradable. That is a genuinely good idea and Mozilla uses it to (in the form of XPCom.) DirectX is the perfect example. It is stupid to complain why you can subclass from IDirect3DDevice7 because that's not what it was designed to do. Its like asking why you can't subclass from the C functions in OS.h (for non-Be users, that implements a lot of kernel level C interface for BeOS) What COM does in this case is make DirectX easily upgradable. So far, DirectX has gone through 5 (going on 6) revisions. It has been totally overhauled more than once, and has gone from a POS to a super-sexy API (if you can understand it.) One thing that made it possible was COM. By tightly defining the interface between components, DirectX has been able to stay more or less backwards compatible without resorting to multiple libraries for the different versions (one major thing that pisses me off, that kdelibs-1.x and kdelibs 2.x aren't compatible) This idea would be great used in a lot of other places. For example, it could be used to define the app->Desktop environment protocol. That way, you could totally replace KDE with GNOME, and all your apps would continue to work (as long as both GNOME and KDE strictly followed the protocol.) Each would still be seperate projects, and still having vastly different strenghts and weaknesses, but we wouldn't have to have both installed. (Think of it as TCP/IP for the local system.) COM isn't a very big hack at all. You can duplicate much of its functionality (for in-proc servers) through dynamically loadable libraries (add-ons for those Be folks.) You create an abstract class, and use that in the client program. Then you have a class implement that interface, and compile it into a add-on. You use some kind of mechanism to give an app the name of a particular add-ons, and then import a function to pass an instance of the implementing class to the calling program. Voila, everything works quite well. Of course, if you use the other 90% of the COM/OLE API, then god help you. However, if you do that, you get what you deserve.
*IS* there a "Linux" look and feel?
So, you know very little about Linux, yet you have no problem pointing out all the things it does wrong.
>>>>>>>>>>>
Right. Do you know what a media-node in BeOS is? And you feel that you have the right to critisze it? YES YOU DO! If you've used it, and it doesn't work well, then you have every right to critisize it! I speak from a users point of view (and having used Linux for many years, I think I'm entitled to an opinion). If a user needs to know what a super-block is, then the developer is doing something wrong.
Because they're not portable. They don't work on other systems. Anything that depends on them will not be portable to other
systems. Thus, attributes aren't portable.
>>>>>>>>>>>
Huh? You do realize that you have to define the word "portable" without using the word itself!
You complain constantly about all of the "Linux zealots" who ignore problems in their favorite OS, yet you seem to be the biggest
perpetrator of that particular vice.
>>>>>>>>>>>>>
Really? Would you care to show me when? As I remember, I posted reason why BeOS is not as advanced as QNX the other day, and I posted 9 or 10 problems with BeOS on BeNews. Of course I don't pay attention to useless posts like "BeOS is dying!" or "BeOS has no software!" but everytime I have had an intelligent criticism (like that guy who could only play 8 or 9 MP3s at the same time on BeOS. Turned out to be that I was using SoundPlay, and he MediaPlayer) I responed. Even in my post I pointed out (from the bonnie benchmark) that BeOS had problems with the VM. What more do you want?
...ID3 information is injected into attributes...
Gee, like how it is already embedded in the MP3 itself? Next you'll be saying attributes can also store the title of an HTML
document. What progress!
>>>>>>
Yea, but you can't search based on stuff stored inside the MP3. (If stuff isn't in a central database) And you can have your file-viewer autmotically display that info.
This is true, but does it apply? Are BeOS attributes really trying to improve things, or are they trying to pull that favorite industry
tactic of locking us into a single vendor? (I actually suspect the former, but I have to consider the possibility.)
>>>>>>
Really? Let's see. MacOS X, NeXTSTep, and BeOS all use something similar to attributes. Hell, UNIX uses it in the form of attribute bits (owner, group, date, etc.) Take for example, an installer I'm writing. Instead of having an ugly central database, all uninstall info is stored inside a folder's attributes. No more rebuilding the RPM database. That's just plain cool!
The case can be made that application-level attributes do not belong in the system, but in application-level libraries. By keeping such
information in the files themselves, they are easily transfered to other systems, and do not require system-level support. Meanwhile,
you can still provide a standard API to get at the information with an application-library. Thus, you get the best of both worlds.
>>>>>>>
No, because then there would be 3 dozen different APIs to do the thing. And if it is so easy, then why hasn't Linux done it yet? Plus, by putting it as part of the base system, it makes it much more likely that developers will use it. This is a big help because it allows nifty, usefull features to be implemented in all apps and allows a level of *UNITY* you just don't get in Linux. (Similar to BeOS's universal app scripting, sure you can do it in Linux, but by making it part of the OS, many more developers use the feature.)
No you wouldn't. Slashdot has had countless stories about such things, but you continue your tired crusade every chance you get.
Meanwhile, you will happily ignore yet another legitimate complaint about your favorite OS: That anyone using it is locked into a
single-vendor solution.
>>>>>>>
All Slashdot posts are OSS people saying how OSS is great. And to date, I have not heard from anyone important that propriotary software is dead. Even most OSS people say that they can live harmoniously.
Lines of code isn't a terribly accurate measurement of code bloat. Perhaps those 1.5 million "extra"
lines in Linux go to support things BeOS does not. Drivers. Platforms. Features. Stability. Security.
Whatever. Maybe they're documentation. Maybe they're copyright notices. But then, we really don't
know, do we? We can't know, because BeOS holds us hostage with its source code.
>>>>>>>>>>>>>>>>>
I know lines-of code isn't an accurate measurement. Most of the stuff is features that BeOS doesn't, and probably won't ever, have. I was defending the Linux kernel, don't piss me off. I brought up BeOS just to put things in prespective.
The nice thing about Linux is that nobody is forcing you to run all that "crap", as you so eloquently
put it. If you want a stripped-down, bare-bones system with nothing but X11 and a single app, you
can do that. Don't need the GUI? You can toss that, too. If you have the horsepower and the desire,
you can also run GNOME with Enlightenment and every silly graphics effect you can think of
turned on, plus sixteen different versions of Mozilla at once. Your choice.
>>>>>>>>>>>>>
No, it's not my choice. I want to run gnumeric. Do I have any other choice than to run GNOME (or GNOME inside KDE, or inside TWM or whatever, the RAM requirement is still obscene)??? You don't have a choice! You have to run what the developers want you to run, and if you need gnumeric, or KOffice, or KDevelop, or Mozilla, you have to put up with all the addendant baggage they carry. That's why I favor slim, standardized base systems so much. In the real world, (as opposed the the best case world Linux users seem to live in ie: where everyone can hack the kernel, and change apps to different toolkits on whim) they allow a user much more flexibility in what programs they can run without incurring more bloat. That doesn't necessarily mean one DE. There can be a hundred DEs, as long as they are all binary compatible (you know, kind of like the way it was with those dozens of window managers. I could run any Linux app back then, and have only one WM installed.)
Your analogy is wrong. GNOME is the road, the software is the car.
You analogy equates to:
If your favorite program is GNOME, than you have no choice but to run GNOME. If your favorite company is microsoft, you have no choice but to run Windows.
The correct analogy is:
If your fave program is GNOME, you have no choice other than to run GNOME. If your fave car is Porsche (american cars? Bah!) , you can run it on whatever damn road you please.
I can run my Japanese car on my American roads without importing Japanese roads. And if I move my Japanese car to German roads, I automatically get the benifits that German roads provide. You just don't do that with GNOME and KDE (or most other software) Sure your running KDE, but the app is still running GNOME, and has all the issues that made you run KDE in the first place. The software industry is *FAR* behind the rest of the world in making products interworkable.
First of all, if we except your rather flawed reasoning, then anyone who runs programs they didn't write are slaves. That includes you and your favorite OS.
.diffs to add features you want to his car? Hell no! You write a letter, and the next model year, you've got 20 cup-holders. The problem is programmers write for programmers, and not users. Take half the features in GNOME. They're there because it makes the programmers feel ELITE, not because the users asked for them.
>>>>>>>>>>>>>>>>
Yea, I know, all software users are slaves. What's your point? Does Slashdot automatically append a "none of this applies for BeOS which is perfect" message to all my posts?
But again, your reasoning is flawed. I can run KDE programs and GNOME programs and old Xt programs and even terminal programs, all at the same time. I
need to have all the libraries a program requires installed, yes, but go ahead and show me a program that will run without a library it needs.
>>>>>>>>>>>>>>>.
It shouldn't have to be that way! I can plug any electric product into any outlet and be reasonably sure it will work. I don't have to have other types of outlets installed in order for it to work. I can buy nails and use them with any hammer, without buying multiple hammers for nails only compatible with one type of hammer.I can buy a Japaneese car without importing Japaneese roads, so why can't all my programs run on whatever DE I choose? Sure this is idealistic, but the software industry is *FAR* behind the rest of the consumer industries in friendlieness. The problem is, everything else has a standard interface. A hammer works on any type of nail mainly because the hammer->nail interface is constant. A road works with any car, because the road->car interface is constant. I can buy a hair-dryer and have it work with any type of hair because the hair->dryer interface is nostant. Going to an even more practical level, I can buy any pair stereo speakers, and be sure they work with my stereo (mostly.) I don't have to worry about what the speaker->stereo interface is, and I don't have to buy multiple stereos for each type of speaker.
Better still, since most of this stuff is Open Source, we can take the program and re-write it to use the desktop environment of our choice. We can even
change the desktop environment if we need to.
>>>>>>>>>>>>>
Yea, and I can leave Iraq if I want to. Just sneak out without Sadam noticing, and get into the US without Uncle Sam noticing. The "But you've got the source!" arugement is just a cop out. Its not really a practical method for getting user input into the software. Does your car manufacturer ask you to submit
With BeOS, on the other hand, you're locked in, and cannot change it. Sounds like you're the real slave to me
>>>>>>>>>>>>
Excuse me? When does it take an OSS OS to write OSS apps? The BeOS GUI is OpenSource, the architecture is very open (so you can modify the system quit extensivly through add-ons) and there is no clause saying "thou shalt not write OSS apps on BeOS." You can't much with the system, but you can do just about everything else. And all of that is irrelevant. In BeOS, Linux, whatever, its the programmers deciding what you should do, not the users. (Actually, BeOS programs, like other small programming projects, tend to be much more receptive to user demands than larger projects like GNOME.)
Really? That would explain the 15 minutes my NT machine spent showing me every f*cking cluster on my 20gig drive?
ReiserFS is signifcantly faster than Ext2. I'm speaking from having run ResierFS on my computer for a few months.
ReiserFS is signifcantly faster than Ext2. I'm speaking from having run ResierFS on my computer for a few months.