Great... then we'll have to define what "possible" means. Yes, it is possible to provide a binary for the PDP-11 and the Atari 2600, but will anyone? Doubtful. So in practice, "possible" would end up meaning "Windows and possibly MacOS". And if the maintainers of these binary distributions were to disappear/disband/get hit by a bus, then no more binaries for anyone.
But why would I be upset? I am getting the word processor.
Because you aren't getting the word processor. All you're getting is the ability to run a particular build of the word processor, on a particular OS, on a particular hardware platform. The moment you need to change to another OS or hardware platform, that executable becomes useless to you, and you have no word processor. At that point, the public loses the benefits of the publicly funded research, potentially forever. And that's not even getting into the fact that the public never gets the benefits of seeing how a good word processor can be written, novel and useful extensions to the word processor by 3rd parties, etc.
Sounds like what we really need isn't a requirement that publicly-funded researchers open-source their software, but rather a law preventing the institutions they work for from forbidding them to do so.
That would go a long way towards addressing the complaints brought up in the "con" essay.
Tron is a traditional, evangalistic Protestant Christian film (our purpose is to understand the wishes of our User, and thus to fulfill our role in creation
Religious overtones, perhaps, but not quite Christian--each program had his/her own User. I wonder what the name is for religions where every person has their own individual God, whose interests are separate from (and often conflicting with) those of the other Gods?
With millions of transistors, drawing one by one is not a solution for mass-production.
Hmm... what we need then is an e-beam with some sort of prism-like splitter in front of it... sort of like when you you glue ten pens together to write 10 lines of text at once. If you could split a single e-beam into 1,000 parallel e-beams, separated by the right distances, you could then write 1,000 chips in parallel while still avoiding the need to draw up a mask.
At times, individual ports would be using 7-8 Mb/s, for as long as ten hours at a time.... offenders who chose to ignore it... were warned by mail individually.... and after that, had
their ports shut off and the MAC address of their computers banned from the DHCP pool
I've never understood why colleges think they have to go to all the trouble of hassling students about their bandwidth usage when a much simpler and less aggravating method is obvious. All you really need is a program for your routers that measures bandwidth usage from each internal IP address, and computes a "dynamic priority level" for each IP address based on the total number of bytes it has sent/received in the last (n) hours. Then, when bandwidth availability gets tight, the router can free up bandwidth by forcibly constraining the send/receive rate of the IP addresses who have recently been loading the network the most. The way the "bandwidth hogs" never get in the way of the light users... but since the bandwidth hogs are probably just unattended computers doing downloads or file sharing anyway, their users will probably never even notice the slower speeds.
If this reminds you of the standard Unix CPU scheduler algorithm, it should... it's the same exact idea, applied to network bandwidth instead of CPU time.
Cisco or somebody could make a lot of money selling a product like this to colleges... just think of all the administrative time and student unhappiness (== lost tuition) it would save.
The reason we're often dependent on the name to determine the type of a file is that so far, it seems to be the only thing that really makes sense.
BeOS has an excellent method that makes much more sense:
On filesystems that support file attributes (e.g. BFS), each file is given a string attribute containing the appropriate MIME type. (If a file doesn't have a MIME type, perhaps because it has just been copied in from a foreign file system, a MIME type is generated for it on demand)
On filesystems that don't support file attributes (e.g. FAT), the MIME type is always generated on the fly
Doing it this way is much better, since the user can then name their files any way they like without worrying about confusing the OS. Since other OS's are now beginning to support file attributes, perhaps the time has come for them to start using this technique as well.
Looks like Apple will be lucky to retain market share until they start thinking about THE SPECS of their machines (and not how cute they look).
This would be true if Apple's target market was Slashdot readers. It isn't. The people who are likely to buy one of these little cuties don't know from specs, they just know that it looks 'neat' and it does the things they want to do.
Ten years down the road, [OpenSourced BeOS would] be a crashing, feeezing heap.
What on earth are you basing that on? Would you call Linux or BSD a "crashing, freezing heap"? One of the more important potential benefits of opening the source is to improve reliability, not the other way around.
The key point to keep in mind is that while any idiot can go and change the source on his own machine, only the best code gets accepted back into the "official distributions". (assuming the official project maintainers are even a little bit competent, of course)
I'm totally naive about human-powered airplanes, so flame me if necessary, but: has anyone tried to make human-powered aircraft that uses multiple "human engines"? i.e. would a "twin" with two people pedalling, or even a "slave galley" plane with 10 or 20 people pedalling have more or less trouble staying aloft?
Or, to put it another way, are there any economies of scale to be exploited by adding people to the engine?
It's hard enough to convince a Windows-user that MacOS makes you more productive - the interfaces are so similar that it's possible to approach both MacOS and BeOs with a Windows-infused mind and miss out all the good stuff.
Correct--and that is a good thing. Time spent learning a new interface is not productive time. Most productivity gains can be had these days by making the standard (and well-known/understood) UI metaphors smarter, so that more things "just work" and don't require futzing around or technical knowledge to use... not by reinventing everything just for the sake of doing so.
It's possible to build a user interface that is both obviously different and obviously better
Is it possible? Are you sure? Can you point to any examples? Ones that people actually like to use, as opposed to 'interesting proofs of concept'? It's easy to wave one's hands and say "things ought to be better", and it's possible to write a user interface that is radically different from the standard one we have now (people occasionally do this), but I have yet to see an alternative user interface that is "enough better" to justify requiring everyone to re-learn how to use a computer. Hell, we can't even get people to use Dvorak instead of Qwerty, let alone getting them to give up an interaction paradigm that took many of them years to learn...
Last time I checked, the purpose of open source was to create great software, not to stick to ideals.
Speaking as a recovering BeOS user/developer, I can say that BeOS is/was great software. But because it was closed source, it is now orphan-ware, getting more obsolete every day. When I to upgrade to a new machine, I most likely won't be able to run it at all anymore, since the new hardware won't be supported. If BeOS had been open source, it would still be a viable OS today, since the Be developer community would have taken over development when Be keeled over. (indeed, they are still trying to do just this, but Palm couldn't care less)
The moral of the story is this: for certain "platform" types of software that require a lot of time/money/software investment from the user (such as operating systems, APIs, languages, etc), one of the most important "features" that must be considered is whether or not the software product will continue to be supportable and developed. You can either make that guarantee by being too rich to ever go out of business (if you're Microsoft), or by making the code open source (if you're anybody else).
Or to put it more succinctly, it's gonna be a bummer for all the OS/X users if/when Apple goes out of business, and drags OS/X down with it. Users of open source operating systems have no such worries.
It doesn't just require the user to be stupid (although it does); it also makes it easy for the user to be stupid. In other words, it requires the user to be very careful in disposing of his receipts, or risk getting screwed. And the only reason for making things so error prone is for the business's convenience (it saves them the hassle of developing a more secure system); there is no advantage for the consumer.
As long as these risks are presented upfront, there shouldn't be any lawsuits involved in the first place.
Well that's just the thing, isn't it? When are these risks ever present up front? With the lottery, they publish the odds of winning (in fine print, of course), but up until I saw this article I had no idea that buying a gift card represented any kind of a financial risk (other than the risk of physically losing the card, of course). I suspect that most other people have no idea either, mainly due to companies having no incentive to publicize the risks involved with their products.
Sheesh... Why, oh why, do we need a law to protect people from doing stupid things?
You could argue the same point for any product-safety law. Why do we need a law that forbids companies from selling cars with defective brakes? (and yes, the account-number-on-the-receipt is a defect: specifically, it's a security hole)
I could see a law where the vendor had to inform you to protect the numbers, but not allow them to give you a slip of paper with the number on it? That's pretty paternal, don't you think?
Your tangled mass of spaghetti code paths are probably full of almost incomprehensible little design decisions and seemingly out of place declarations and functions, but most of those were probably added as specific fixes for bugs encountered under real-world use.
... which is why whenever you add one of these "little design decisions" whose purpose isn't blatantly obvious, it's important to put in a comment saying what it does and why it is there. Otherwise someone might come through later on, think it's an error, and remove it.
All honesty im not a beliver in opensource because i belive time *IS* money which means my time should be worth a return in cold hard cash.
Many (in fact most) programs aren't written with the intent to sell them. Most are written to be used in-house by the company who sponsored their development. In this scenario, open source is a win-win situation, because (a) you are able to use and customize already-written code, which saves you lots of time, and (b) because later on others will be able to use your code, saving them time. You'll get your "cold hard" cash anyway, since your company is paying to make stuff work, not to write new code. Forcing everyone to rewrite the same code ultimately helps no one.
A better way to protest: go to your favorite record store, find the copy-protected CDs, and place a big red DEFECTIVE/NONSTANDARD sticker on each one. Then see how well they sell;^)
Slashdot Mirror
I knew it was time bring out the old
;^)
Great... then we'll have to define what "possible" means. Yes, it is possible to provide a binary for the PDP-11 and the Atari 2600, but will anyone? Doubtful. So in practice, "possible" would end up meaning "Windows and possibly MacOS". And if the maintainers of these binary distributions were to disappear/disband/get hit by a bus, then no more binaries for anyone.
Because you aren't getting the word processor. All you're getting is the ability to run a particular build of the word processor, on a particular OS, on a particular hardware platform. The moment you need to change to another OS or hardware platform, that executable becomes useless to you, and you have no word processor. At that point, the public loses the benefits of the publicly funded research, potentially forever. And that's not even getting into the fact that the public never gets the benefits of seeing how a good word processor can be written, novel and useful extensions to the word processor by 3rd parties, etc.
That would go a long way towards addressing the complaints brought up in the "con" essay.
Religious overtones, perhaps, but not quite Christian--each program had his/her own User. I wonder what the name is for religions where every person has their own individual God, whose interests are separate from (and often conflicting with) those of the other Gods?
Hmm... what we need then is an e-beam with some sort of prism-like splitter in front of it... sort of like when you you glue ten pens together to write 10 lines of text at once. If you could split a single e-beam into 1,000 parallel e-beams, separated by the right distances, you could then write 1,000 chips in parallel while still avoiding the need to draw up a mask.
their ports shut off and the MAC address of their computers banned from the DHCP pool
I've never understood why colleges think they have to go to all the trouble of hassling students about their bandwidth usage when a much simpler and less aggravating method is obvious. All you really need is a program for your routers that measures bandwidth usage from each internal IP address, and computes a "dynamic priority level" for each IP address based on the total number of bytes it has sent/received in the last (n) hours. Then, when bandwidth availability gets tight, the router can free up bandwidth by forcibly constraining the send/receive rate of the IP addresses who have recently been loading the network the most. The way the "bandwidth hogs" never get in the way of the light users... but since the bandwidth hogs are probably just unattended computers doing downloads or file sharing anyway, their users will probably never even notice the slower speeds.
If this reminds you of the standard Unix CPU scheduler algorithm, it should... it's the same exact idea, applied to network bandwidth instead of CPU time.
Cisco or somebody could make a lot of money selling a product like this to colleges... just think of all the administrative time and student unhappiness (== lost tuition) it would save.
BeOS has an excellent method that makes much more sense:
Doing it this way is much better, since the user can then name their files any way they like without worrying about confusing the OS. Since other OS's are now beginning to support file attributes, perhaps the time has come for them to start using this technique as well.
I don't think the poster was referring to the type of animal, but rather to the smell...
This would be true if Apple's target market was Slashdot readers. It isn't. The people who are likely to buy one of these little cuties don't know from specs, they just know that it looks 'neat' and it does the things they want to do.
Hmm.... add a magnifying lens and some motor oil, and you've got the computers from the movie Brazil
It's more Reggae than rock at the moment, but I'm sure that will change as CPUs get faster...
sounds like a good way for the ISS to magnetically propel itself right out of orbit...
What on earth are you basing that on? Would you call Linux or BSD a "crashing, freezing heap"? One of the more important potential benefits of opening the source is to improve reliability, not the other way around.
The key point to keep in mind is that while any idiot can go and change the source on his own machine, only the best code gets accepted back into the "official distributions". (assuming the official project maintainers are even a little bit competent, of course)
I'm totally naive about human-powered airplanes, so flame me if necessary, but: has anyone tried to make human-powered aircraft that uses multiple "human engines"? i.e. would a "twin" with two people pedalling, or even a "slave galley" plane with 10 or 20 people pedalling have more or less trouble staying aloft?
Or, to put it another way, are there any economies of scale to be exploited by adding people to the engine?
Correct--and that is a good thing. Time spent learning a new interface is not productive time. Most productivity gains can be had these days by making the standard (and well-known/understood) UI metaphors smarter, so that more things "just work" and don't require futzing around or technical knowledge to use... not by reinventing everything just for the sake of doing so.
It's possible to build a user interface that is both obviously different and obviously better
Is it possible? Are you sure? Can you point to any examples? Ones that people actually like to use, as opposed to 'interesting proofs of concept'? It's easy to wave one's hands and say "things ought to be better", and it's possible to write a user interface that is radically different from the standard one we have now (people occasionally do this), but I have yet to see an alternative user interface that is "enough better" to justify requiring everyone to re-learn how to use a computer. Hell, we can't even get people to use Dvorak instead of Qwerty, let alone getting them to give up an interaction paradigm that took many of them years to learn...
Speaking as a recovering BeOS user/developer, I can say that BeOS is/was great software. But because it was closed source, it is now orphan-ware, getting more obsolete every day. When I to upgrade to a new machine, I most likely won't be able to run it at all anymore, since the new hardware won't be supported. If BeOS had been open source, it would still be a viable OS today, since the Be developer community would have taken over development when Be keeled over. (indeed, they are still trying to do just this, but Palm couldn't care less)
The moral of the story is this: for certain "platform" types of software that require a lot of time/money/software investment from the user (such as operating systems, APIs, languages, etc), one of the most important "features" that must be considered is whether or not the software product will continue to be supportable and developed. You can either make that guarantee by being too rich to ever go out of business (if you're Microsoft), or by making the code open source (if you're anybody else).
Or to put it more succinctly, it's gonna be a bummer for all the OS/X users if/when Apple goes out of business, and drags OS/X down with it. Users of open source operating systems have no such worries.
It doesn't just require the user to be stupid (although it does); it also makes it easy for the user to be stupid. In other words, it requires the user to be very careful in disposing of his receipts, or risk getting screwed. And the only reason for making things so error prone is for the business's convenience (it saves them the hassle of developing a more secure system); there is no advantage for the consumer.
Well that's just the thing, isn't it? When are these risks ever present up front? With the lottery, they publish the odds of winning (in fine print, of course), but up until I saw this article I had no idea that buying a gift card represented any kind of a financial risk (other than the risk of physically losing the card, of course). I suspect that most other people have no idea either, mainly due to companies having no incentive to publicize the risks involved with their products.
You could argue the same point for any product-safety law. Why do we need a law that forbids companies from selling cars with defective brakes? (and yes, the account-number-on-the-receipt is a defect: specifically, it's a security hole)
I could see a law where the vendor had to inform you to protect the numbers, but not allow them to give you a slip of paper with the number on it? That's pretty paternal, don't you think?
Seems like common sense to me.
... which is why whenever you add one of these "little design decisions" whose purpose isn't blatantly obvious, it's important to put in a comment saying what it does and why it is there. Otherwise someone might come through later on, think it's an error, and remove it.
But with VMWare you have to buy/own a Windows license, which kind of nullifies the price advantage.
Many (in fact most) programs aren't written with the intent to sell them. Most are written to be used in-house by the company who sponsored their development. In this scenario, open source is a win-win situation, because (a) you are able to use and customize already-written code, which saves you lots of time, and (b) because later on others will be able to use your code, saving them time. You'll get your "cold hard" cash anyway, since your company is paying to make stuff work, not to write new code. Forcing everyone to rewrite the same code ultimately helps no one.
A better way to protest: go to your favorite record store, find the copy-protected CDs, and place a big red DEFECTIVE/NONSTANDARD sticker on each one. Then see how well they sell ;^)