A society with laws does not meet the definition of free.
Certainly it does. Even the definition you point to mentions that America is a free nation. (Which is a great achievement, since the last time I checked, it wasn't even a nation either!)
Dictionaries give multiple possible definitions for every single word. To "meet the definition", something must match only one of those definitions, not all of them. For example, look at the background color behind the word "Slashdot" to the upper left. Does it meet the definition of "green"?
Yes it does, even though that color is not a "grassy law or plot".
Claiming that something must meet all definitions of a word to be worthy of the term is a silly game.
We are using Sun's JVM and compilers to build the agents and the testers. I was think about using gcj/classpath to build that programs, but that would be really 'reliable' ?
I've seen Java "agent" code work fine under both gcj and Sun or IBM's JVM. I mean stuff like Coabs.
How my project would be intepreted in scientific congress when people see it is not developed under Sun's JVM but on GNU's one ?
Nobody with a scientific mindset should care at all. Scientists view choice of software provider as an inconsequential implementation issue. Both Sun Java and GCJ have certain problems with numerical accuracy that bother some scientists, but as long as you correctly report what you used, you'll be fine.
doesn't sound very pleasant for the programmers.
Pleasant for programmers? That depends on what they're doing. In general there's so much more support for official Sun Java in IDEs and what have you that it'll be easier to jump right in and get started without thinking about configuration. And since most Java programmers probably use the Sun version anyway, it'll be simplest to stick with what they're used to.
However, there are situations where GCJ is actually much easier to use than Java. Especially if you're an experienced Unix C++ or GCC programmer, or if you need to work with programs that combine C/C++ and Java in one executable, then GCJ can be better.
To illustrate my point I will give this questions to the three lettered leaders and all you other OSS ethusiasts.
Your questions are absolutely meaningless, because software is scalable.
Do you grow your own foods, and i mean all of them ? Do you weave and grow your flax, and such for fabrics that you wear ? again all the clothes you wear ?
There are people who can answer yes to both those questions. They're rare, and modern society views them as freaks, but they do exist. They do things the hard way for fun, or to prove themselves, or for spiritual satisfaction.
But that has nothing to do with OSS. Because a few hundred devoted self-sufficient farmers cannot attempt to feed the whole rest of the world- the number of people who can use the product is proportionate to the number working on it. To double the eaters, you must first double the farmers.
But in software, it's completely plausible that 100 dedicated programmers could provide the majority of the software needs for the entire planet. That's because with software, the number of users is independent of the producers. When the number of users of software doubles, the number of programmers can stay the same. The additional usage costs zero additional effort!
Yes, GCC varies from the C standard implemented by other C compilers. But whenever that happens, they point it out in the documentation! When Sun's manual describes a Java feature not implemented by alternatives, they naturally don't mention this fact.
It's possible you link to a proprietary library without noticing.
Only if the proprietary library is on your computer. If you actually care about that issue, then it's very easy to prevent. There are several Linux distributions that scrupulously install only "Free" software.
you very rarely (if ever) need to resort to using proprietary libraries (Sun or not).
Wrong! Tell me what open-source alternatives there are for Swing. It's nearly impossible to convince a programmer writing with Sun's Java to build to any other GUI library.
Java is found on almost all machines with a web browser in it.
I'm near a lab with 100+ machines. All of them have web browsers. But aside from the 3 Sun boxes, none of them have Java. Sun's continual refusal to put Java in Linux distributions is chronically hampering their adoption (because someone who uses Linux will have an above-average chance to care about cross-platform programming).
Shockwave Flash actually has greater penetration here...
What PDA do you have, exactly? I can only remember seeing PDAs running things like PersonalJava, which although an offical Sun product, is not compatible with programs written for real Java.
The quotes you printed make Microsoft look evil. They appear to have succeeded not on strength of technology, but on cleverly quasi-fraudulent contracts.
The real truth behind the J++ dispute has two parts, and you've omitted one of them. Yes, J++ was faster than Sun Java (at least under MS Windows). But that only mattered in combination with the fact that Microsoft was adding new language keywords to J++. Programs written for J++ wouldn't compile under regular Sun Java. Therefore they had no real right to call it a "Java" compiler.
And yet it hasn't led to a GNU-C linguistic forkfest.
GNU C was significantly forked from C in the 2.x series. In 3.x, they've removed most of those "improvements" and concentrated more in implementing the official standards.
However, C isn't a good comparison to Java anyway. It was always an accepted part of the C language design that the interpretation of some things would be hardware-dependent and nonportable. Forking a language causes a loss of portability- but if it wasn't portable anyway, then no big deal.
It's called "capacity planning". If you're buying a bigger machine than your capacity calls for, then of course you're spending extra money.
You didn't read what I said. I wasn't buying a "bigger" machine than needed- there was no SGI big enough! Only a $200k Origin2000 could've matched that $3k Dell. That's how far behind CPUs were on the "UNIX" side.
if you can put your web server, email server, domain server. file server, etc. all in the same box, then you're saving money over the proliferating x86 boxes.
Ha ha. The trend is that Linux x86 consolidates those services from diverse expensive UNIXes.
Sun makes some very nice Ultrasparc Rackmount and Blade systems starting at $999. That's pretty hard to beat, even for Dell.
Sun is losing money. They've been running at a loss for years. Excessive price-cuts in a desparate attempt to retain a few customers is part of the reason for this.
but Dell has also been charging exorbitant yearly maintenance fees for their server products.
They're happy to soak anyone whose still in the UNIX-y "server means constant payment" mentality. But if you're smart, you can shop around. Or bid HP and IBM against Dell.
That's one of the two fundamental reasons to stay away from "UNIX" servers (in favor of Unix-like Linux): vendor lock-in. If your applications were built for Solaris, AIX, Iris, or HPUX, then there's only possible vendor when you need to scale up. Their salesmen can devour you negotating the new prices. But running on Intel/AMD, you can always threaten a switch to a more affordable hardware vendor (without significant reworking of your apps)
The other fundamental reason is economy of scale. Intel/AMD systems are both faster and cheaper as a consequence of their popularity.
All those points sound good, which is why UNIX(tm) salemen still use them. Too bad they're lies.
1. It takes fewer Unix boxes to accomplish the same job as the ever multiplying rabbits^W x86 machines.
Wrong. In 2000 when SGI offered me an O2 for $25,000, it would've taken 5 of them to do the same job as one $3,000 Dell Pentium2.
Reliability, uptime, maintainability, etc. are all worth paying extra for.
Those are all areas where an x86 PC trounces Sun or SGI systems. With Sun, the annual maintenance fee can often exceed the lifetime ownership cost of a PC variant.
I suppose that in the 4 years that've gone by since a UNIX dealer has last tried to sell me anything, they might've gone more into a desperation mode and started reducing prices to get competitive with Intel/AMD systems again. But they just won't be able to catch up. Because x86 is used for home/business as well as the server room, it's got an unmatchable economy of scale subsidizing R&D and manufacturing costs.
Long term, Unix machines still win the day.
True, but only because Unix!=UNIX(tm). Dell P5s with Linux are Unix, and they win.
I am not sure why, but slashdot puts in spaces in some places.
Because if the page contained a single word 200 characters long, web browsers would be forced to scroll horizontally back and forth to read each sentence of every of the 100s of other posts. Horizontal scrollbars suck.
One is that the law of libel and slander is part of English Common Law; as such, it pre-dates the U.S. Constitution, never mind the First Amendment,
Why does a foreign code matter at all, just because it happens to be older? Hammurabi's Code predates both the Constitution and Common Law, so by your reasoning, I guess it's "still" in force.
there's no sense in which subsequent acts of Congress governing it have *abridged* the right to free speech by making it less free.
Of course there's no sense- nobody said something foolish like that. Obviously, North American free speech rights were *created* by Congress in proposing the Bill of Rights. They extended it well beyond traditional English law. Where did you get "abridged"?
The second is that defamation is not a crime; you *do* have the right to libel or slander someone. But they have the right to sue you when you do.
Are you claiming that libel is not a criminal offense? That's just wrong. It's on a state-by-state basis.
It only takes one person to break the DRM. As soon as that happens and the music is released online in non-DRM format then its over.
Not quite. There are three main forms of copyright infringment publishers should fear:
Counterfeiting: sale of bootleg discs by traditional criminals
Internet / P2P: Large networks like Napster and Kazaa.
Casual duplication between actual friends
DRM can't do anything about the first two categories. However, there are legal remedies: counterfeiters and P2P sharers make themselves high-profile targets for arrest.
The third area is where DRM might be effective. If one person in a group of 10 friends buys a music CD, and then casually makes hard-drive copies whenever they visit each other, then the industry is (arguably) out 90% of their income, with little opportunity to prosecute the infringer. (Unless one of those 9 other people rats him out, which is unlikely)
To be successful, the industry only needs to create a barrier of inconvenience such that you can't simply jam a CD into the drive and click "Rip to My Music".
When I install a new program, I usually don't know very much about it, so it would be rather hard to tell what behaviors are needed.
True. That's why it should be possible to quickly adjust those permissions after installation, such as when a running program tries to do something unallowed. One obvious thing is that some programs which can use the internet don't always need to do so. The OS can check with you the first time the program tries to connect outside, and allow the connection just that once, or for 30 minutes, or forever. (Some desktop firewall products already do that exact behavior)
It might work for you, but it would be a disaster for most.
It's already a disaster for most. So every little bit of help will be an improvement. And I don't think it'll really be unmanagable. Yes, there are an enormous number of capabilities that could be toggled for each individual program. But in 95% of cases, a new program will fall cleanly into a well defined category like "file viewer", "network client", "video game".
For example, lets look closely at the videogame category. Today if I want to download a free puzzle game, but don't want it uploading my email addressbook to its programmer, my choices are limited. The most elegant approach is to have a separate username on my PC just meant for running games. But that's awkward (at minimum, it prevents me from running the game on the same desktop as my normal apps). If there was some way I could install the program attached to my normal username, but with only a subset of my full permissions, that'd be much better.
How about this: When you start to install the program, it identifies itself (to the OS) as in the "game category", which implies that it doesn't need the ability to read/write arbitrary files (only files inside its directory tree, like savegames and texture maps), but it does need freeform network access (for multiplayer). The OS can just pop up a quick dialog box "Is this really a game?", which encapsulates all the recommended settings for the category.
Only rarely should someone have to exercise more finely-grained control.
does it appear and spread instantaneously? I would argue that it very often does not, especially in the abstract field of information technology.
It's true that info takes time to disseminate. But so do software products. You need to compare the relative speeds of the two. There'll always be at least a short time when a product is available but unknown- the zeroth customer, after all, has no previous reports to rely on. However in general that's a minor effect- early adopters know they're taking a little risk with unproven products.
But when the "product" is software, the situation gets worse. The product's lifecycle can be so rapid that the marketplace has no opportunity to fully digest the implications of version 1 before version 2 is pushing it aside. (Consider how Microsoft updates change not just the feature sets of their products, but also the EULA terms)
In that case, consumers must depend less on information describing each program and more on an overall reputation of the programmers. If buyers really care about avoiding malware, then I'd hope they'd gravitate towards publishers who are known to be "above" that kind of thing- or even better, choose operating systems that include protection against malware.
In my semi-idealist world, if consumers truely disliked spyware toolbars installing themselves into IE whenever they hit a porn popup, then they'd migrate towards web-browsers and OSes that protect them from inadvertently installing software.
(Yet another way the MS monopoly hurts the public? Could be!)
Like many people, Garkfinkel is proposing a legislative solution to something that'd be better handled technically.
(Legislative solutions are suboptimal/dangerous for many reasons. They are over-broad, in that they apply even to consenting adults who wish to engage in the behavior without meddlesome government oversight; cf prostitution. And they're too-narrow, in that they can by necessity only apply within the country's legal jurisdiction, whereas software distribution is an international operation)
Turn now to the second page the Pure Software proposal. The list of potential warning-labels it suggests is: Hook, Dial, Modify, Monitor, Popup, Remote Control, Self-Updates, and Stuck.
All of those things are basically technical features which a well-designed operating system could prohibit programs from using, without permission. The root of the problem is that even after 30+ years of software publication, most programs are still just completely arbitrary lists of instructions: once they're executing, they do whatever they do, and nothing can stop them.
The big exception there is that most OSes, at least, restrict programs on a per-user basis. A program cannot read or edit files to which the executing user has no permission. That's an important step, but one that Unix has had firmly in place since the 80s. As time passes, we need to go further: program priviledges should be restricted not just at the per-user level, but also at finer granularity.
When I download and install a program, I don't want just the option of "run it or don't". I should be able to run it, but without it being able to read any files except those it came with. Or being allowed to read files, but only if I pick them from a system-supplied dialog box. Or read any files, but not write to them, except in a directory I've chosen (and that it can't override). Or write files, but only in specific approved formats (such as those which can't possibly contain executable code). Similar kinds of restrictions suggest themselves for GUI and network areas (including the important points of "phone home" and "data tainting")
To a small extent, Java frameworks (like "Web Start") have attempted to do this, with a list of features the user can individually permit a program to execute. Microsoft.Net also makes overtures in this direction. It will be a challenge for OS vendors to allow users to have this amount of control, without overwhelming them with so many choices they'll give up and just give full permissions to everythig (in the pattern of "I always run as administrator, because it's the only way to get stuff done"). But those challenges can be surmounted with skilled interface design.
The best way to prevent software from doing something is to use software that prevents it from doing it. (As Lawrence Lessig said, the best and most effective laws for code are more code)
principle of a marketplace with "open information"
In most cases, "open information" (or a close approximation) will happen automatically, unless steps are taken to prevent it. Some consumers will examine the products they buy and exchange that information with other potential customers, so the truth quickly gets out. Or secondary businesses will spring up providing reviews of availabile products.
But in reality, there are often legal obstacles to this free exchange of info: Intellectual Property laws means that to some extent, the government is conspiring with corporations to blind consumers. Occasionally the government will be forced to respond and create new laws that open up certain information demanded by the public. (A question: Is it better to hurt something and then partially fix it, or not hurt it at all?)
In the case of software, I'd follow the rule of thumb that less legisilation = better. Rather than creating new laws on how programs must be labelled with warning icons instead of text hidden in the EULA, the government should just rule (clarify?) that typical EULAs have no legal validty. That won't solve the problem, but it'll take it off the government's hands and leave it up to the free market. (Assuming that the DMCA doesn't ban public spreading of software-data...)
So, who exactly (besides the corporations themselves) is against the idea of government forcing the opening of information to buyers?
The way you phrase your questions is quite different from the "Pure Software" proposal in the article. You use the word "buyer", implying that rules would only apply if money changes hands.
Garfinkel, however, proposes something much broader: "mandatory labelling for all software distributed in the United States". That broadness right there makes the "Act" dangerous, because it'd apply to all software, including amateur/hobbyist, "Free Software", and academic Computer Science books.
Is it really such a hard line to draw (between what buyers *should* know and what is proprietary information)?
It's easy to draw the line: almost nothing should be considered proprietary information, except for the actual copyrighted program files themselves. Anything else should be fair game.
This means that no Arrest can take place without a Direct Connection to an Injury or the imminent liklihood of such.
You're trying to reverse the direction of circular logic; to disprove something that's already circular.
Legally, an "Injury" is any violation of the "Law". Therefore "Injury" is defined in terms of "Law", and not the other way around, like you're claiming.
If "Injury" legally meant the same thing it did in English (as you claimed), then it'd be impossible for copyright infringment, tresspassing, vandalism, or even fraud to be illegal, since none of them cause injury.
For the most part, they're exchanging occasional single-sentence messages that are on a predefined topic.
Also important is that those kinds of radio users ("pro drivers) are usually talking about what they're doing. Cops, firemen, and bus-drivers all talk to their co-workers. Where and how they're driving is the usual subject of conversation.
One of the big reasons cellphones are dangerous is that nonprofessional users often discuss something totally unrelated to their driving, making it a bigger distraction.
Notwithstanding some of the comments posted here, having to drive manually pretty much forces you to be competent. If you're not a competent driver, eventually you're probably going to die.
That's a silly position! I hadn't realized Luddites were allowed to use the WWW. As technology marches along, old skills like firebuilding, equestrianism, and Morse code are forgotten. Some people will always lament the passing of old ways, but those specializations are genuinely no longer needed.
(Side note: We're all going to die. Pointing out that someone is probably going to die proves nothing)
And the way things are going, eventually we probably will have full auto-pilot, which means you won't need to pay any attention at all.
This is a major inconsistency in your argument. Here you say there will be "full auto-pilot", but through the rest of the message only a minor driver-assist mechanism is assumed. Full autopilot is clearly the longterm objective (of both automakers and consumers), and it's the topic that deserves the most consideration. (Everything thing else is an intermediate transitionary stage, which isn't important in the long run)
What if, as has happened on airplanes, there's some other problem that one of these automatic systems masks while it's on?
What if any machine is built in a stupid way? It'll be dangerous! The fact that something can be done wrongly is no argument against it, because it's possible for a dedicated fool to screw up anything.
For another, the systems themselves cannot be foolproof.
More empty rhetoric. Nothing can be foolproof... does that mean we shouldn't do anything?
Automobile autopilot doesn't have to be foolproof to be worthwhile. It only needs to be better than the alternatives- and the alternative is human drivers, which (in the US) kill one person per 58,000,000 miles travelled.
The only good question is: Do you think that computerized car-drivers will kill people at a greater or lesser rate? Everyone must answer it according to her own optimism for technological improvement.
I certainly feel that within at most 30 years, computer software will have achieved a measurably lower deaths/mile rate than human drivers. At that point, it'd be foolishly unsafe not to use them (not to mention inconvenient)
Wikis are just a rebranding of the same hypertext model used since the birth of the Web.
Not exactly... Wikis aren't a "rebranding", they are a return to the original concept of the Web that was never strongly supported in software before.
Tim Berners-Lee's original WWW idea was quite different from the browser model popular for the last decade. He had conceived that editing web pages would be accomplished seamlessly within the same software that views them (and within 2 orders of magnitude as frequently). The splitting up of web tools into common clients and rare authoring/hosting products subverted that vision.
Wikis are a relization of a founding idea that wasn't achieved before.
Slashdot Mirror
A society with laws does not meet the definition of free.
Certainly it does. Even the definition you point to mentions that America is a free nation. (Which is a great achievement, since the last time I checked, it wasn't even a nation either!)
Dictionaries give multiple possible definitions for every single word. To "meet the definition", something must match only one of those definitions, not all of them. For example, look at the background color behind the word "Slashdot" to the upper left. Does it meet the definition of "green"?
Yes it does, even though that color is not a "grassy law or plot".
Claiming that something must meet all definitions of a word to be worthy of the term is a silly game.
We are using Sun's JVM and compilers to build the agents and the testers. I was think about using gcj/classpath to build that programs, but that would be really 'reliable' ?
I've seen Java "agent" code work fine under both gcj and Sun or IBM's JVM. I mean stuff like Coabs.
How my project would be intepreted in scientific congress when people see it is not developed under Sun's JVM but on GNU's one ?
Nobody with a scientific mindset should care at all. Scientists view choice of software provider as an inconsequential implementation issue. Both Sun Java and GCJ have certain problems with numerical accuracy that bother some scientists, but as long as you correctly report what you used, you'll be fine.
doesn't sound very pleasant for the programmers.
Pleasant for programmers? That depends on what they're doing. In general there's so much more support for official Sun Java in IDEs and what have you that it'll be easier to jump right in and get started without thinking about configuration. And since most Java programmers probably use the Sun version anyway, it'll be simplest to stick with what they're used to.
However, there are situations where GCJ is actually much easier to use than Java. Especially if you're an experienced Unix C++ or GCC programmer, or if you need to work with programs that combine C/C++ and Java in one executable, then GCJ can be better.
To illustrate my point I will give this questions to the three lettered leaders and all you other OSS ethusiasts.
Your questions are absolutely meaningless, because software is scalable.
Do you grow your own foods, and i mean all of them ?
Do you weave and grow your flax, and such for fabrics that you wear ? again all the clothes you wear ?
There are people who can answer yes to both those questions. They're rare, and modern society views them as freaks, but they do exist. They do things the hard way for fun, or to prove themselves, or for spiritual satisfaction.
But that has nothing to do with OSS. Because a few hundred devoted self-sufficient farmers cannot attempt to feed the whole rest of the world- the number of people who can use the product is proportionate to the number working on it. To double the eaters, you must first double the farmers.
But in software, it's completely plausible that 100 dedicated programmers could provide the majority of the software needs for the entire planet. That's because with software, the number of users is independent of the producers. When the number of users of software doubles, the number of programmers can stay the same. The additional usage costs zero additional effort!
You could say the same thing for GCC.
Yes, GCC varies from the C standard implemented by other C compilers. But whenever that happens, they point it out in the documentation! When Sun's manual describes a Java feature not implemented by alternatives, they naturally don't mention this fact.
It's possible you link to a proprietary library without noticing.
Only if the proprietary library is on your computer. If you actually care about that issue, then it's very easy to prevent. There are several Linux distributions that scrupulously install only "Free" software.
you very rarely (if ever) need to resort to using proprietary libraries (Sun or not).
Wrong! Tell me what open-source alternatives there are for Swing. It's nearly impossible to convince a programmer writing with Sun's Java to build to any other GUI library.
Java is found on almost all machines with a web browser in it.
I'm near a lab with 100+ machines. All of them have web browsers. But aside from the 3 Sun boxes, none of them have Java. Sun's continual refusal to put Java in Linux distributions is chronically hampering their adoption (because someone who uses Linux will have an above-average chance to care about cross-platform programming).
Shockwave Flash actually has greater penetration here...
Take my pda for example..
What PDA do you have, exactly? I can only remember seeing PDAs running things like PersonalJava, which although an offical Sun product, is not compatible with programs written for real Java.
due to poorly written code or using libraries that should not be used if you are looking to run it on multiple platforms
Or simply expecting floating-point arithmetic to give the same answer when the same two numbers are multiplied...
Facts as flamebait?
The quotes you printed make Microsoft look evil. They appear to have succeeded not on strength of technology, but on cleverly quasi-fraudulent contracts.
The real truth behind the J++ dispute has two parts, and you've omitted one of them. Yes, J++ was faster than Sun Java (at least under MS Windows). But that only mattered in combination with the fact that Microsoft was adding new language keywords to J++. Programs written for J++ wouldn't compile under regular Sun Java. Therefore they had no real right to call it a "Java" compiler.
And yet it hasn't led to a GNU-C linguistic forkfest.
GNU C was significantly forked from C in the 2.x series. In 3.x, they've removed most of those "improvements" and concentrated more in implementing the official standards.
However, C isn't a good comparison to Java anyway. It was always an accepted part of the C language design that the interpretation of some things would be hardware-dependent and nonportable. Forking a language causes a loss of portability- but if it wasn't portable anyway, then no big deal.
Java is already open-source. It's called GCJ.
Even RMS knew better than to claim that GCJ "is" Java.
"Java" is a trademark for a whole suite of related software products. It includes programming languages, libraries, compilers, and virtual machines.
GCJ is just an incomplete (but useful) replacement for only one of those components.
It's called "capacity planning". If you're buying a bigger machine than your capacity calls for, then of course you're spending extra money.
You didn't read what I said. I wasn't buying a "bigger" machine than needed- there was no SGI big enough! Only a $200k Origin2000 could've matched that $3k Dell. That's how far behind CPUs were on the "UNIX" side.
if you can put your web server, email server, domain server. file server, etc. all in the same box, then you're saving money over the proliferating x86 boxes.
Ha ha. The trend is that Linux x86 consolidates those services from diverse expensive UNIXes.
Sun makes some very nice Ultrasparc Rackmount and Blade systems starting at $999. That's pretty hard to beat, even for Dell.
Sun is losing money. They've been running at a loss for years. Excessive price-cuts in a desparate attempt to retain a few customers is part of the reason for this.
but Dell has also been charging exorbitant yearly maintenance fees for their server products.
They're happy to soak anyone whose still in the UNIX-y "server means constant payment" mentality. But if you're smart, you can shop around. Or bid HP and IBM against Dell.
That's one of the two fundamental reasons to stay away from "UNIX" servers (in favor of Unix-like Linux): vendor lock-in. If your applications were built for Solaris, AIX, Iris, or HPUX, then there's only possible vendor when you need to scale up. Their salesmen can devour you negotating the new prices. But running on Intel/AMD, you can always threaten a switch to a more affordable hardware vendor (without significant reworking of your apps)
The other fundamental reason is economy of scale. Intel/AMD systems are both faster and cheaper as a consequence of their popularity.
All those points sound good, which is why UNIX(tm) salemen still use them. Too bad they're lies.
1. It takes fewer Unix boxes to accomplish the same job as the ever multiplying rabbits^W x86 machines.
Wrong. In 2000 when SGI offered me an O2 for $25,000, it would've taken 5 of them to do the same job as one $3,000 Dell Pentium2.
Reliability, uptime, maintainability, etc. are all worth paying extra for.
Those are all areas where an x86 PC trounces Sun or SGI systems. With Sun, the annual maintenance fee can often exceed the lifetime ownership cost of a PC variant.
I suppose that in the 4 years that've gone by since a UNIX dealer has last tried to sell me anything, they might've gone more into a desperation mode and started reducing prices to get competitive with Intel/AMD systems again. But they just won't be able to catch up. Because x86 is used for home/business as well as the server room, it's got an unmatchable economy of scale subsidizing R&D and manufacturing costs.
Long term, Unix machines still win the day.
True, but only because Unix!=UNIX(tm). Dell P5s with Linux are Unix, and they win.
I am not sure why, but slashdot puts in spaces in some places.
Because if the page contained a single word 200 characters long, web browsers would be forced to scroll horizontally back and forth to read each sentence of every of the 100s of other posts. Horizontal scrollbars suck.
One is that the law of libel and slander is part of English Common Law; as such, it pre-dates the U.S. Constitution, never mind the First Amendment,
Why does a foreign code matter at all, just because it happens to be older? Hammurabi's Code predates both the Constitution and Common Law, so by your reasoning, I guess it's "still" in force.
there's no sense in which subsequent acts of Congress governing it have *abridged* the right to free speech by making it less free.
Of course there's no sense- nobody said something foolish like that. Obviously, North American free speech rights were *created* by Congress in proposing the Bill of Rights. They extended it well beyond traditional English law. Where did you get "abridged"?
The second is that defamation is not a crime; you *do* have the right to libel or slander someone. But they have the right to sue you when you do.
Are you claiming that libel is not a criminal offense? That's just wrong. It's on a state-by-state basis.
Not quite. There are three main forms of copyright infringment publishers should fear:
DRM can't do anything about the first two categories. However, there are legal remedies: counterfeiters and P2P sharers make themselves high-profile targets for arrest.
The third area is where DRM might be effective. If one person in a group of 10 friends buys a music CD, and then casually makes hard-drive copies whenever they visit each other, then the industry is (arguably) out 90% of their income, with little opportunity to prosecute the infringer. (Unless one of those 9 other people rats him out, which is unlikely)
To be successful, the industry only needs to create a barrier of inconvenience such that you can't simply jam a CD into the drive and click "Rip to My Music".
When I install a new program, I usually don't know very much about it, so it would be rather hard to tell what behaviors are needed.
True. That's why it should be possible to quickly adjust those permissions after installation, such as when a running program tries to do something unallowed. One obvious thing is that some programs which can use the internet don't always need to do so. The OS can check with you the first time the program tries to connect outside, and allow the connection just that once, or for 30 minutes, or forever. (Some desktop firewall products already do that exact behavior)
It might work for you, but it would be a disaster for most.
It's already a disaster for most. So every little bit of help will be an improvement. And I don't think it'll really be unmanagable. Yes, there are an enormous number of capabilities that could be toggled for each individual program. But in 95% of cases, a new program will fall cleanly into a well defined category like "file viewer", "network client", "video game".
For example, lets look closely at the videogame category. Today if I want to download a free puzzle game, but don't want it uploading my email addressbook to its programmer, my choices are limited. The most elegant approach is to have a separate username on my PC just meant for running games. But that's awkward (at minimum, it prevents me from running the game on the same desktop as my normal apps). If there was some way I could install the program attached to my normal username, but with only a subset of my full permissions, that'd be much better.
How about this: When you start to install the program, it identifies itself (to the OS) as in the "game category", which implies that it doesn't need the ability to read/write arbitrary files (only files inside its directory tree, like savegames and texture maps), but it does need freeform network access (for multiplayer). The OS can just pop up a quick dialog box "Is this really a game?", which encapsulates all the recommended settings for the category.
Only rarely should someone have to exercise more finely-grained control.
does it appear and spread instantaneously? I would argue that it very often does not, especially in the abstract field of information technology.
It's true that info takes time to disseminate. But so do software products. You need to compare the relative speeds of the two. There'll always be at least a short time when a product is available but unknown- the zeroth customer, after all, has no previous reports to rely on. However in general that's a minor effect- early adopters know they're taking a little risk with unproven products.
But when the "product" is software, the situation gets worse. The product's lifecycle can be so rapid that the marketplace has no opportunity to fully digest the implications of version 1 before version 2 is pushing it aside. (Consider how Microsoft updates change not just the feature sets of their products, but also the EULA terms)
In that case, consumers must depend less on information describing each program and more on an overall reputation of the programmers. If buyers really care about avoiding malware, then I'd hope they'd gravitate towards publishers who are known to be "above" that kind of thing- or even better, choose operating systems that include protection against malware.
In my semi-idealist world, if consumers truely disliked spyware toolbars installing themselves into IE whenever they hit a porn popup, then they'd migrate towards web-browsers and OSes that protect them from inadvertently installing software.
(Yet another way the MS monopoly hurts the public? Could be!)
Like many people, Garkfinkel is proposing a legislative solution to something that'd be better handled technically.
.Net also makes overtures in this direction. It will be a challenge for OS vendors to allow users to have this amount of control, without overwhelming them with so many choices they'll give up and just give full permissions to everythig (in the pattern of "I always run as administrator, because it's the only way to get stuff done"). But those challenges can be surmounted with skilled interface design.
(Legislative solutions are suboptimal/dangerous for many reasons. They are over-broad, in that they apply even to consenting adults who wish to engage in the behavior without meddlesome government oversight; cf prostitution. And they're too-narrow, in that they can by necessity only apply within the country's legal jurisdiction, whereas software distribution is an international operation)
Turn now to the second page the Pure Software proposal. The list of potential warning-labels it suggests is: Hook, Dial, Modify, Monitor, Popup, Remote Control, Self-Updates, and Stuck.
All of those things are basically technical features which a well-designed operating system could prohibit programs from using, without permission. The root of the problem is that even after 30+ years of software publication, most programs are still just completely arbitrary lists of instructions: once they're executing, they do whatever they do, and nothing can stop them.
The big exception there is that most OSes, at least, restrict programs on a per-user basis. A program cannot read or edit files to which the executing user has no permission. That's an important step, but one that Unix has had firmly in place since the 80s. As time passes, we need to go further: program priviledges should be restricted not just at the per-user level, but also at finer granularity.
When I download and install a program, I don't want just the option of "run it or don't". I should be able to run it, but without it being able to read any files except those it came with. Or being allowed to read files, but only if I pick them from a system-supplied dialog box. Or read any files, but not write to them, except in a directory I've chosen (and that it can't override). Or write files, but only in specific approved formats (such as those which can't possibly contain executable code). Similar kinds of restrictions suggest themselves for GUI and network areas (including the important points of "phone home" and "data tainting")
To a small extent, Java frameworks (like "Web Start") have attempted to do this, with a list of features the user can individually permit a program to execute. Microsoft
The best way to prevent software from doing something is to use software that prevents it from doing it. (As Lawrence Lessig said, the best and most effective laws for code are more code)
principle of a marketplace with "open information"
In most cases, "open information" (or a close approximation) will happen automatically, unless steps are taken to prevent it. Some consumers will examine the products they buy and exchange that information with other potential customers, so the truth quickly gets out. Or secondary businesses will spring up providing reviews of availabile products.
But in reality, there are often legal obstacles to this free exchange of info: Intellectual Property laws means that to some extent, the government is conspiring with corporations to blind consumers. Occasionally the government will be forced to respond and create new laws that open up certain information demanded by the public. (A question: Is it better to hurt something and then partially fix it, or not hurt it at all?)
In the case of software, I'd follow the rule of thumb that less legisilation = better. Rather than creating new laws on how programs must be labelled with warning icons instead of text hidden in the EULA, the government should just rule (clarify?) that typical EULAs have no legal validty. That won't solve the problem, but it'll take it off the government's hands and leave it up to the free market. (Assuming that the DMCA doesn't ban public spreading of software-data...)
So, who exactly (besides the corporations themselves) is against the idea of government forcing the opening of information to buyers?
The way you phrase your questions is quite different from the "Pure Software" proposal in the article. You use the word "buyer", implying that rules would only apply if money changes hands.
Garfinkel, however, proposes something much broader: "mandatory labelling for all software distributed in the United States". That broadness right there makes the "Act" dangerous, because it'd apply to all software, including amateur/hobbyist, "Free Software", and academic Computer Science books.
Is it really such a hard line to draw (between what buyers *should* know and what is proprietary information)?
It's easy to draw the line: almost nothing should be considered proprietary information, except for the actual copyrighted program files themselves. Anything else should be fair game.
This means that no Arrest can take place without a Direct Connection to an Injury or the imminent liklihood of such.
You're trying to reverse the direction of circular logic; to disprove something that's already circular.
Legally, an "Injury" is any violation of the "Law". Therefore "Injury" is defined in terms of "Law", and not the other way around, like you're claiming.
If "Injury" legally meant the same thing it did in English (as you claimed), then it'd be impossible for copyright infringment, tresspassing, vandalism, or even fraud to be illegal, since none of them cause injury.
Wrong. Indecisiveness is good. Acting certain when you're not is much worse than honestly admitting an incompetency.
For the most part, they're exchanging occasional single-sentence messages that are on a predefined topic.
Also important is that those kinds of radio users ("pro drivers) are usually talking about what they're doing. Cops, firemen, and bus-drivers all talk to their co-workers. Where and how they're driving is the usual subject of conversation.
One of the big reasons cellphones are dangerous is that nonprofessional users often discuss something totally unrelated to their driving, making it a bigger distraction.
Notwithstanding some of the comments posted here, having to drive manually pretty much forces you to be competent. If you're not a competent driver, eventually you're probably going to die.
That's a silly position! I hadn't realized Luddites were allowed to use the WWW. As technology marches along, old skills like firebuilding, equestrianism, and Morse code are forgotten. Some people will always lament the passing of old ways, but those specializations are genuinely no longer needed.
(Side note: We're all going to die. Pointing out that someone is probably going to die proves nothing)
And the way things are going, eventually we probably will have full auto-pilot, which means you won't need to pay any attention at all.
This is a major inconsistency in your argument. Here you say there will be "full auto-pilot", but through the rest of the message only a minor driver-assist mechanism is assumed. Full autopilot is clearly the longterm objective (of both automakers and consumers), and it's the topic that deserves the most consideration. (Everything thing else is an intermediate transitionary stage, which isn't important in the long run)
What if, as has happened on airplanes, there's some other problem that one of these automatic systems masks while it's on?
What if any machine is built in a stupid way? It'll be dangerous! The fact that something can be done wrongly is no argument against it, because it's possible for a dedicated fool to screw up anything.
For another, the systems themselves cannot be foolproof.
More empty rhetoric. Nothing can be foolproof... does that mean we shouldn't do anything?
Automobile autopilot doesn't have to be foolproof to be worthwhile. It only needs to be better than the alternatives- and the alternative is human drivers, which (in the US) kill one person per 58,000,000 miles travelled.
The only good question is: Do you think that computerized car-drivers will kill people at a greater or lesser rate? Everyone must answer it according to her own optimism for technological improvement.
I certainly feel that within at most 30 years, computer software will have achieved a measurably lower deaths/mile rate than human drivers. At that point, it'd be foolishly unsafe not to use them (not to mention inconvenient)
Wikis are just a rebranding of the same hypertext model used since the birth of the Web.
Not exactly... Wikis aren't a "rebranding", they are a return to the original concept of the Web that was never strongly supported in software before.
Tim Berners-Lee's original WWW idea was quite different from the browser model popular for the last decade. He had conceived that editing web pages would be accomplished seamlessly within the same software that views them (and within 2 orders of magnitude as frequently). The splitting up of web tools into common clients and rare authoring/hosting products subverted that vision.
Wikis are a relization of a founding idea that wasn't achieved before.
socat > netcat. If you need that fancy flexibility, and can handle more obtuse commandlines.