That sort of stuff works on standard $600 desktop hardware.
Well, I started using Opera because I don't think that FF is responsive enough. I don't understand why FF has a bigger marketshare than Opera: I think that Opera is better than FF.
Well, and you also think that BeOS is better than Linux. It appears your preferences differ from those of most computer users.
The city the bridge is being built at has over 7,000 people.
Well, I have a better idea. Rather than spending $315 million on building these people a bridge, let's pay each of them $45000 in order to move to a bigger city. That way, we won't have to support their apparently very expensive lifestyle with federal tax dollars in the future.
Come to think of it, let's not pay them anything, let's let them just build their own bridge, OK? Then, we can apply the $315 million to, oh, say the federal deficit.
Why should the Federal government pay for the bridges in the city of Ketchikan? If these people want to live in the middle of nowhere, they should have to bear the full cost of their choice. The Federal government should have no interest in supporting such an inefficient lifestyle choice.
The irony of the Republican mantra of self-reliance is that it is primarily the rural, Republican areas that receive financial support from the rich, urban, Democratic areas. If you want to look at the biggest Federal welfare recipients, look at the rural areas in the US.
Well, you didn't look close enough to the demo: he launched 5 application simultaneously and had them running in a snap and whatever he did, the OS stayed responsive and very fast.
So what? I can launch 20 applications simultaneously in Linux and have them running in a snap; that just isn't a big deal. Whether the OS stays responsive and fast depends on the apps.
If you launch Firefox, OpenOffice, F-Spot, Nautilus, MPlayer, Beryl, and Eclipse simultaneously on BeOS, I guarantee you it would also bring it to its knees.
This is an application design issue (need to be supported by the kernel and the libraries of course), we could probably have this on Linux or Windows, but we don't unfortunately..
Firefox is a pig not because of Linux but because of the Firefox developers. Even on Windows, Firefox performs much worse than, say, Opera, and on Linux, the Firefox developers seem to be completely out of their depth (and don't seem to give a damn either). But everybody uses Firefox because, in the end, it's still fast enough.
Well, I was trying to be polite, but, yes, you're right: OS X is basically the same as the 20 year old operating system called NeXTStep. So much for Apple's claims of innovation. At least Objective-C in Leopard will (finally) get garbage collection.
Ah, so you're of the "if it's a single system call, it must be efficient" school of thought. Sorry, you really don't know what you're talking about.
Making a library to make it simple is just the kind of coding it should never be done, design flaws should never be hidden.
Putting complex, large latency operations in the kernel would be a design flaw. Putting the minimum amount of stuff necessary into the kernel and implementing the rest in user code is good design. Now, inotify can probably be improved, but doing what you suggest is just a bad idea.
And that's probably why Linux is still around and BeOS failed.
However, from the user's perspective, it's a very big deal.
Running eight movies in parallel is important... why? And if it were such a big deal, why do users so often choose to configure their systems with slower, more powerful software?
Even Linux on modern hardware doesn't come close to the snappiness of BeOS.
Sure it does. What makes Linux less responsive than BeOS is the apps and the configuration people choose to run, not the kernel. If you want to, you can configure your Linux system to be very snappy. For starters, try Xubuntu, although that's still much more heavy-weight than you might want.
You also can't beat the fact that it could boot from BIOS to the desktop in under 10 seconds (again, on a *very* modest PC).
Sure I can: Linux could (and can) boot that fast as well. The reason distributions don't is because the flexibility of the boot script system is more important than faster boot times. (Another reason is that some modern hardware takes a long time to initialize.)
Windows, Linux, and MacOS simply can't touch the simple elegance and efficiency that BeOS mastered almost 10 years ago, which is an absolute shame.
It's easy to be simple and elegant when you have a tiny user community. The reason for all that crap in Windows, Linux, and OS X is that real users want it, just like real users prefer less snappy apps that do what they want to more snappy apps that don't.
(Remember that BeOS was released alongside Mac OS 9 and Windows 98)
Yes, about 30 years after the concepts in BeOS were originally invented. The fact that Apple and Microsoft released even more obsolete operating systems around that time doesn't make BeOS modern or elegant.
I understand the nostalgia, but it's inappropriate. The BeOS designers believed that the areas that they optimized and were working on were more important than compatibility and functionality, but the market proved conclusively that they were wrong. If BeOS were open sourced tomorrow, I predict it would also fail.
It's ok. Too bad there is no recursive directory support in inotify. Software has to add a watch for every subdirectory of a tree it wants to monitor.
So what? Why do you want to put more functionality into the kernel than necessary? You can write user-mode code around inotify for recursive watches--Beagle does just that. If enough people wanted it, it could be wrapped up as a library.
Not one of the major OSs have truly efficient threading. For that you have to look at the real time kernels,
Real time kernels can get by with very low thread overhead because they don't need to do a lot of things that kernel threads in desktop operating systems must do. But kernel threads aren't the only threads available on Linux anyway.
and to projects like jcsp
In fact, there are a number of thread implementations on top of Linux that are more efficient than Linux's kernel threads, so JCSP is nothing special. And, being part of Linux, they're there if you need them. In fact, even JCSP runs on top of Linux, so it's hard to see how it could be an example of threading that's better than what's available on Linux.
The ability to play eight movies simultaneously is a bad way of determining OS thread performance. Most modern operating systems have efficient, low-overhead threads. How well they play multiple videos depends much more on the display pipeline, the codec, and how the players adapt to load. To say anything about system performance, you'd need to know frame rate, resolution, codec, postprocessing options, etc.
Overall, I really don't see anything in BeOS that you don't get as well or better in a modern Linux system. BeOS has some efficiency gains from having been developed from the ground up with little need for backwards compatibility, but that's probably also why it wasn't successful in the market. And threading and scheduling in particular are highly efficient and mature in Linux.
(Not that OS X is basically a hacked NeXTStep; the NeXTStep kernel is Mach, the same kernel that is the basis of the GNU Hurd.)
but what are these things, for the average person?
The plot of various soap operas, game levels, who's sleeping with whom, whatever. You know, the kind of stuff that has mattered to primates since the days we were still living on trees.
Until then, I'm of the camp that it's not the import of the data that matters, but rather the act of using your mind to remember it.
Your mind automatically remembers what you're working with. Contrary to what the article implies, you're not improving your memory by remembering meaningless numbers, all you're doing is improving your memory for numbers. And, oddly enough, to remember meaningless numbers, people tend to relate them to things that their brains actually were built to remember in the first place: people, places, images, sounds, smells, colors, etc.
Well, "misunderstand" is a polite way of saying "you haven't f*cking read the thing all the way through".
If you have actually read it and you still claim it's viral, then you didn't "misunderstand", you're just a lying s.o.b. with a religious hatred of free software. Which is, I suspect, what you are.
These gadgets are doing exactly what they are supposed to: they are freeing us from the tedium of having to memorize and keep track of meaningless numbers, dates, and times. I don't see why that's a bad thing.
Of course it's serious. That doesn't mean that it affects everything from mobile devices to servers!
It does affect everything from mobile devices to servers, because they all run Java 6 (more mobile devices run mobile Java, but some still run full Java).
but that doesn't materially impact the ability to load and parse the data.
Well, you can keep pretending that all is fine and dandy with the Java language, but the fact is that there is a boatload of native code in Java and Java libraries, and not just old code, but new native code specifically written for Java. When even Sun prefers writing large chunks of the Java implementation in C, that tells you that the Java language just isn't very good at those things.
Other general purpose languages in the past have made it a point to allow the entire system to be implemented in that language, with at most a trivial amount of bootstrapping code and some interfaces to legacy libraries.
Sure, the GPL is viral. I don't think anyone really denies that.
The GPL isn't "viral"; it doesn't "infect" code or spread. All it does is ensure that derivative works of the software fall under the same license as the software itself. That's the same scope most commercial licenses have: they tell you what you can and cannot do with derivative works. The difference is that the GPL lets you do more with derivative works than, say, Windows or OS X.
GPL version 2 had no restrictions on what hardware was required upon which to run the software.
Neither does GPL v3. You can run it on your patented, stolen hardware all you like.
Where the GPL v3 imposes conditions is when you distribute hardware with GPL v3 software, or when you offer services based on GPL v3 software. Those conditions are quite analogous to the GPL v2: when you do so, you must ensure that your users retain the ability to get the source code and modify it.
Forcing people, corporations, or whomever to use freely available code in a certain way is contradictory to freedom.
People can use GPL v3 code in any way they like; the GPL v3 simply requires them to extend the same rights to their users of the software.
GPLv3 affects any hardware that the software is distributed with. I'm pretty sure that this makes it viral *by definition*. I also consider this to make it evil, but that's a separate issue.
Microsoft Windows or OS X also have provisions in their license about what hardware you may and may not use it on, etc. So, the GPL v3 is hardly unusual in this regard.
Only religious fanatics and totalitarian states equate 'morality' with 'legality,
The GPL v3 is a license, not a law. You aren't forced to use GPL v3 software, you do so voluntarily. If you don't like the license, don't use it or software that ships under it. Therefore, talking about "totalitarianism" and "legality" is factually wrong: those terms simply don't apply to the GPL.
As for the relationship between morality and legality, you're a bit out of touch with reality. For better or for worse, morality is a guiding principle of a lot of legislation in every Western democracy. You may prefer a totally utilitarian approach to legislation (and I may too, for that matter), but that's not the way real life works. So, even your erroneous objection is baseless.
And the GPL v3 itself, well, Stallman may talk about "morality", but the license itself is about economics: it prevents people from taking free software without giving back to the community. And in order to achieve that, it contains a number of pragmatic updates to the GPL v2. To me, the fact that the Linux kernel does not enjoy the additional legal protection of the GPL v3 constitutes a significant legal risk. And that's not religion, that's business.
Implementing languages in themselves used to be the norm. If you have a decent language, it's not hard to do. If you have Java, well, then you have to implement big parts of it in C.
If Sun simply rewrote the code in Java (which wouldn't be hard; only time consuming), the problems would go away.
The Java language is a train wreck when it comes to imaging code. You can write something like a JPEG library in "pure" Java, you can even make it fast, but it ends up being worse than writing it in assembly language.
If Sun actually practiced what they preached, they would have fixed this years ago. Unfortunately, all they every seem to write in Java themselves is increasingly bloated "enterprise libraries"; when they need to write something efficient, they define a new library API and implement it in native code.
A buffer overflow in images that only affects desktops and servers supporting image uploads
According to the announcement, it allows applets to elevate their privileges.
Bunch of FUD-spreading fear-mongers. Hrumph.
If applets are vulnerable, that's not FUD, it's serious. Of course, it's only the latest in several such vulnerabilities over the years, which is probably why many people just disable Java.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing library.
Yes, that would be the right thing to do. Unfortunately, Java sucks for writing that kind of code.
I don't have a problem with companies that *gasp* charge for the services they provide directly to those using the service.
I have nothing against for-pay services either. That doesn't change the fact that.Mac is overpriced, but if you have a Mac (like I do), you're largely stuck with it because Apple makes it too painful to do anything else.
Slashdot Mirror
Well, I'm using Linux everyday at work, and I tell you: it doesn't feel responsive.
Well, if it is, you're doing something seriously wrong:
http://youtube.com/watch?v=ZD7QraljRfM
That sort of stuff works on standard $600 desktop hardware.
Well, I started using Opera because I don't think that FF is responsive enough. I don't understand why FF has a bigger marketshare than Opera: I think that Opera is better than FF.
Well, and you also think that BeOS is better than Linux. It appears your preferences differ from those of most computer users.
The city the bridge is being built at has over 7,000 people.
Well, I have a better idea. Rather than spending $315 million on building these people a bridge, let's pay each of them $45000 in order to move to a bigger city. That way, we won't have to support their apparently very expensive lifestyle with federal tax dollars in the future.
Come to think of it, let's not pay them anything, let's let them just build their own bridge, OK? Then, we can apply the $315 million to, oh, say the federal deficit.
Why should the Federal government pay for the bridges in the city of Ketchikan? If these people want to live in the middle of nowhere, they should have to bear the full cost of their choice. The Federal government should have no interest in supporting such an inefficient lifestyle choice.
The irony of the Republican mantra of self-reliance is that it is primarily the rural, Republican areas that receive financial support from the rich, urban, Democratic areas. If you want to look at the biggest Federal welfare recipients, look at the rural areas in the US.
Well, you didn't look close enough to the demo: he launched 5 application simultaneously and had them running in a snap and whatever he did, the OS stayed responsive and very fast.
So what? I can launch 20 applications simultaneously in Linux and have them running in a snap; that just isn't a big deal. Whether the OS stays responsive and fast depends on the apps.
If you launch Firefox, OpenOffice, F-Spot, Nautilus, MPlayer, Beryl, and Eclipse simultaneously on BeOS, I guarantee you it would also bring it to its knees.
This is an application design issue (need to be supported by the kernel and the libraries of course), we could probably have this on Linux or Windows, but we don't unfortunately..
Firefox is a pig not because of Linux but because of the Firefox developers. Even on Windows, Firefox performs much worse than, say, Opera, and on Linux, the Firefox developers seem to be completely out of their depth (and don't seem to give a damn either). But everybody uses Firefox because, in the end, it's still fast enough.
Well, I was trying to be polite, but, yes, you're right: OS X is basically the same as the 20 year old operating system called NeXTStep. So much for Apple's claims of innovation. At least Objective-C in Leopard will (finally) get garbage collection.
Inefficient, the parent poster has a point,
Ah, so you're of the "if it's a single system call, it must be efficient" school of thought. Sorry, you really don't know what you're talking about.
Making a library to make it simple is just the kind of coding it should never be done, design flaws should never be hidden.
Putting complex, large latency operations in the kernel would be a design flaw. Putting the minimum amount of stuff necessary into the kernel and implementing the rest in user code is good design. Now, inotify can probably be improved, but doing what you suggest is just a bad idea.
And that's probably why Linux is still around and BeOS failed.
However, from the user's perspective, it's a very big deal.
... why? And if it were such a big deal, why do users so often choose to configure their systems with slower, more powerful software?
Running eight movies in parallel is important
Even Linux on modern hardware doesn't come close to the snappiness of BeOS.
Sure it does. What makes Linux less responsive than BeOS is the apps and the configuration people choose to run, not the kernel. If you want to, you can configure your Linux system to be very snappy. For starters, try Xubuntu, although that's still much more heavy-weight than you might want.
You also can't beat the fact that it could boot from BIOS to the desktop in under 10 seconds (again, on a *very* modest PC).
Sure I can: Linux could (and can) boot that fast as well. The reason distributions don't is because the flexibility of the boot script system is more important than faster boot times. (Another reason is that some modern hardware takes a long time to initialize.)
Windows, Linux, and MacOS simply can't touch the simple elegance and efficiency that BeOS mastered almost 10 years ago, which is an absolute shame.
It's easy to be simple and elegant when you have a tiny user community. The reason for all that crap in Windows, Linux, and OS X is that real users want it, just like real users prefer less snappy apps that do what they want to more snappy apps that don't.
(Remember that BeOS was released alongside Mac OS 9 and Windows 98)
Yes, about 30 years after the concepts in BeOS were originally invented. The fact that Apple and Microsoft released even more obsolete operating systems around that time doesn't make BeOS modern or elegant.
I understand the nostalgia, but it's inappropriate. The BeOS designers believed that the areas that they optimized and were working on were more important than compatibility and functionality, but the market proved conclusively that they were wrong. If BeOS were open sourced tomorrow, I predict it would also fail.
It's ok. Too bad there is no recursive directory support in inotify. Software has to add a watch for every subdirectory of a tree it wants to monitor.
So what? Why do you want to put more functionality into the kernel than necessary? You can write user-mode code around inotify for recursive watches--Beagle does just that. If enough people wanted it, it could be wrapped up as a library.
Not one of the major OSs have truly efficient threading. For that you have to look at the real time kernels,
Real time kernels can get by with very low thread overhead because they don't need to do a lot of things that kernel threads in desktop operating systems must do. But kernel threads aren't the only threads available on Linux anyway.
and to projects like jcsp
In fact, there are a number of thread implementations on top of Linux that are more efficient than Linux's kernel threads, so JCSP is nothing special. And, being part of Linux, they're there if you need them. In fact, even JCSP runs on top of Linux, so it's hard to see how it could be an example of threading that's better than what's available on Linux.
Let me know when a modern linux system can asynchronously notify a process that a file/directory has been modified.
You mean--like every one? Beagle uses it, and so does Nautilus. It's been there for a number of years.
The ability to play eight movies simultaneously is a bad way of determining OS thread performance. Most modern operating systems have efficient, low-overhead threads. How well they play multiple videos depends much more on the display pipeline, the codec, and how the players adapt to load. To say anything about system performance, you'd need to know frame rate, resolution, codec, postprocessing options, etc.
Overall, I really don't see anything in BeOS that you don't get as well or better in a modern Linux system. BeOS has some efficiency gains from having been developed from the ground up with little need for backwards compatibility, but that's probably also why it wasn't successful in the market. And threading and scheduling in particular are highly efficient and mature in Linux.
(Not that OS X is basically a hacked NeXTStep; the NeXTStep kernel is Mach, the same kernel that is the basis of the GNU Hurd.)
It's the Great Old Ones in their extradimensional prison; they are trying to push out and warping the universe in the process.
Seriously: without some experimental evidence to back up these theories, they aren't worth the paper they are written on.
but what are these things, for the average person?
The plot of various soap operas, game levels, who's sleeping with whom, whatever. You know, the kind of stuff that has mattered to primates since the days we were still living on trees.
Until then, I'm of the camp that it's not the import of the data that matters, but rather the act of using your mind to remember it.
Your mind automatically remembers what you're working with. Contrary to what the article implies, you're not improving your memory by remembering meaningless numbers, all you're doing is improving your memory for numbers. And, oddly enough, to remember meaningless numbers, people tend to relate them to things that their brains actually were built to remember in the first place: people, places, images, sounds, smells, colors, etc.
Try this on for size:
Well, "misunderstand" is a polite way of saying "you haven't f*cking read the thing all the way through".
If you have actually read it and you still claim it's viral, then you didn't "misunderstand", you're just a lying s.o.b. with a religious hatred of free software. Which is, I suspect, what you are.
Clear enough for ya?
These gadgets are doing exactly what they are supposed to: they are freeing us from the tedium of having to memorize and keep track of meaningless numbers, dates, and times. I don't see why that's a bad thing.
Of course it's serious. That doesn't mean that it affects everything from mobile devices to servers!
It does affect everything from mobile devices to servers, because they all run Java 6 (more mobile devices run mobile Java, but some still run full Java).
but that doesn't materially impact the ability to load and parse the data.
Well, you can keep pretending that all is fine and dandy with the Java language, but the fact is that there is a boatload of native code in Java and Java libraries, and not just old code, but new native code specifically written for Java. When even Sun prefers writing large chunks of the Java implementation in C, that tells you that the Java language just isn't very good at those things.
Other general purpose languages in the past have made it a point to allow the entire system to be implemented in that language, with at most a trivial amount of bootstrapping code and some interfaces to legacy libraries.
Sure, the GPL is viral. I don't think anyone really denies that.
The GPL isn't "viral"; it doesn't "infect" code or spread. All it does is ensure that derivative works of the software fall under the same license as the software itself. That's the same scope most commercial licenses have: they tell you what you can and cannot do with derivative works. The difference is that the GPL lets you do more with derivative works than, say, Windows or OS X.
GPL 3 is so different from GPL 2 that I find it hard to claim that it's a revision or iteration.
Well, then you don't understand it (don't worry, lots of people don't either, e.g., Linus).
GPL v3 basically just tidies up a bunch of legal loose ends related to issues that have come up over the last decade.
But GPL v3 does the same thing GPL v2 did: it ensures that any software you use under it, you can obtain the source code for and you can modify.
GPL version 2 had no restrictions on what hardware was required upon which to run the software.
Neither does GPL v3. You can run it on your patented, stolen hardware all you like.
Where the GPL v3 imposes conditions is when you distribute hardware with GPL v3 software, or when you offer services based on GPL v3 software. Those conditions are quite analogous to the GPL v2: when you do so, you must ensure that your users retain the ability to get the source code and modify it.
Forcing people, corporations, or whomever to use freely available code in a certain way is contradictory to freedom.
People can use GPL v3 code in any way they like; the GPL v3 simply requires them to extend the same rights to their users of the software.
GPLv3 affects any hardware that the software is distributed with. I'm pretty sure that this makes it viral *by definition*. I also consider this to make it evil, but that's a separate issue.
Microsoft Windows or OS X also have provisions in their license about what hardware you may and may not use it on, etc. So, the GPL v3 is hardly unusual in this regard.
Only religious fanatics and totalitarian states equate 'morality' with 'legality,
The GPL v3 is a license, not a law. You aren't forced to use GPL v3 software, you do so voluntarily. If you don't like the license, don't use it or software that ships under it. Therefore, talking about "totalitarianism" and "legality" is factually wrong: those terms simply don't apply to the GPL.
As for the relationship between morality and legality, you're a bit out of touch with reality. For better or for worse, morality is a guiding principle of a lot of legislation in every Western democracy. You may prefer a totally utilitarian approach to legislation (and I may too, for that matter), but that's not the way real life works. So, even your erroneous objection is baseless.
And the GPL v3 itself, well, Stallman may talk about "morality", but the license itself is about economics: it prevents people from taking free software without giving back to the community. And in order to achieve that, it contains a number of pragmatic updates to the GPL v2. To me, the fact that the Linux kernel does not enjoy the additional legal protection of the GPL v3 constitutes a significant legal risk. And that's not religion, that's business.
Implementing languages in themselves used to be the norm. If you have a decent language, it's not hard to do. If you have Java, well, then you have to implement big parts of it in C.
If Sun simply rewrote the code in Java (which wouldn't be hard; only time consuming), the problems would go away.
The Java language is a train wreck when it comes to imaging code. You can write something like a JPEG library in "pure" Java, you can even make it fast, but it ends up being worse than writing it in assembly language.
If Sun actually practiced what they preached, they would have fixed this years ago. Unfortunately, all they every seem to write in Java themselves is increasingly bloated "enterprise libraries"; when they need to write something efficient, they define a new library API and implement it in native code.
A buffer overflow in images that only affects desktops and servers supporting image uploads
According to the announcement, it allows applets to elevate their privileges.
Bunch of FUD-spreading fear-mongers. Hrumph.
If applets are vulnerable, that's not FUD, it's serious. Of course, it's only the latest in several such vulnerabilities over the years, which is probably why many people just disable Java.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing library.
Yes, that would be the right thing to do. Unfortunately, Java sucks for writing that kind of code.
I don't have a problem with companies that *gasp* charge for the services they provide directly to those using the service.
.Mac is overpriced, but if you have a Mac (like I do), you're largely stuck with it because Apple makes it too painful to do anything else.
I have nothing against for-pay services either. That doesn't change the fact that