This is possibly the biggest waste of a story Slashdot's had in a while.
Not only does it only 'infect' iPods running Linux, but it's not even able to replicate. To call it a virus is stretching the truth, to say the least; it's just a program that trashes your binaries.
The way I have to work is that I produce a spec from client meetings and discussions, which then gets sent off for approval. The client knows the the approvals process is important, because anything that deviates from the spec (when it's down to them getting it wrong, not us) will cost them extra.
We value the spec because it's what we work to, the client values the spec because it's their bottom line. As a result, we work together to ensure the spec is right before we start.
View them? Yes. Sell something infringing upon them without expecting to end up in court? No.
Her point being: if they weren't protected by law, the would-be holders wouldn't be terribly happy about them being freely viewable (I'm sure many aren't happy about it as it is, but you have to pick one: patent protection or trade secret)
You could, but I'd have to wonder what the point would be.
So Wikipedia has a poor standing in academic communities. So what? I bet the Encyclopaedia Britannica doesn't have a much better standing (especially not after that semi-recent study showed that it was only marginally more accurate than Wikipedia, despite being incredibly costly to obtain and having significantly shorter entries in general).
What the academic community seems to want is a nice resource site collating the results of peer-reviewed studies. And, er, that's it.
Wikipedia's poor standing with respect to academia can be countered with a two-word argument: 'So what?'.
If you don't like it, you don't use it. If you quote stuff from Wikipedia without checking out the references it cites (or do so when it doesn't cite any), then _you_ deserve the brunt of the criticism, not Wikipedia. (And instead of complaining about inaccuracies, maybe some of these people could help improve it-it would benefit them and their peers too, after all).
Bollocks.
An implicit contract is formed (although it can be explicit, obviously) between you and a supplier/retailer for them to supply a license (along with--usually, but not exclusively) the physical media of the software.
The license itself is not the contract.
Well, let's see; to have a contract, you need an offer, an acceptance of the offer, a promise to perform, a valuable consideration, terms and conditions of performance, and the performance itself. A license (certainly a EULA) doesn't tick the boxes, and from my reading the US courts that have put it to the test say that if it _is_ a contract, it's an unenforceable one (because it doesn't do what a contract does) or that it's a distinct legal instrument.
There will be an (typically implicit) contract between you and a software retailer, but there is no contract between you and the software producer, just a grant of rights.
Since you're in no position to negotiate, can't see the terms of the agreement, no money changes hands, no papers are signed, and licenses supposedly apply to individuals who are not in a position to enter into legal contracts (e.g., minors), a EULA being a contract would be very difficult indeed.
A license is a grant of rights. It doesn't claim to be anything beyond that, so it's not 'nothing' (if it was nothing, you'd have no permission to use or distribute any software you didn't write yourself).
The only contract involved in consumer-level software is the one formed between the retailer and the buyer when you purchase it (if you obtained it that way), and that's generally an implicit contract anyway.
(Obviously there are contracts involved in software quite regularly; when one individual or company is contracted to produce software for another, but that contract will _contain_ a license if copyright isn't signed over wholesale).
Basically, contracts and licenses are two different kinds of legal instrument, albeit ones which are often confused with one another. Go ask a lawyer.
That's a lovely sentiment, and completely ignores the real issue that you get to (and was raised on the mailing list in response to the 'open letter') if you read past ESR's rant.
Just because ESR is an idiot with a history is irrelevant: _he has a point_. Yum is broken (forced package removal or not). From a user perspective, this means Fedora Core is broken, and in truth it's by no means limited to Fedora Core.
He's written enough software (and HOWTOs, and FOLDOC entries, and everything else) that you can classify him firmly as 'computer-literate', moreso, you can classify him firmly as 'Linux-literate', and having used RH-based distributions for well over a decade, I'd place a firm bet that he's quite versed with the ins and outs of those specific Linux-based variants.
Where in this picture should support come into it, let alone paying for it? X, Y and Z are broken, what do you do? Do you PAY for support so you can be told that yes, they're broken--for the now incountable time, or do you take it back to the shop because it's actually broken?
What would you do if you bought a home appliance and it didn't work?
Software, and computers in general, are supposed to work. They're not supposed to fuck up. The job of programmers--free and proprietary alike--is to produce software that works. Very little of it out there actually does, and yet developers have the barefaced audacity to say 'not my problem, send patches if you don't like it' when some poor sap (experienced or otherwise) who's come along after the invitation of 'hey, use my software!' [or worse: the pre-packaged shiny distribution that screams the same in big letters] and discovers that it doesn't do what it says on the tin and DARES to get a little annoyed about the fraction of their lifespan that they've wasted dicking around with it.
All software has bugs. Bugs aren't the problem, really. The problem is the utter lack of decent QA in these distributions (and don't think I'm just pointing the finger at Linux distributions: huge multi-national software corporations have exactly the same problem with their latest 'Wow factor', too).
I'm sure there used to be a time where things didn't get shipped if people weren't happy with them. Since when did the fact that you're volunteering your time to maintain this stuff mean that you can forego that fairly fundamental step? One of the points of the free software movement was that 'free' meant 'speech', not 'beer'. Right now, an awful lot of free software out there just looks cheap, and it shows.
For the love of god, why can't a bunch of guys get together and produce a distribution that actually works? If it's broken, you don't ship it. If the first release only contains about five packages, all power to them. The next release will contain ten, and the release after that will contain fifty. All of the distributions out there at the moment are building upon upstream work which itself isn't finished, and quietly introducing even more problems whilst noisily fixing some of the glaring upstream ones.
Seriously, I just don't get what the rush is to compete. You can't compete when all you've got is broken software.
In which case, the difference is going to be negligible, especially on a decent system (where launching an additional process has very little overhead).
Re-read what I said.
If cat uses mmap() and the kernel's pipe implementation is good [i.e., such that grep's read() is negligible], then it could do better than a grep implementation alone that simply read()s the files.
...is so littered with basic errors that it really shouldn't be recommended to anybody.
How is 'tar xvf -C tmp/a/b/c newarc.tar.gz' expected to work, for example?
Quote variables with square brackets?
Running subshell commands using ; instead of && ?
No mention of 'xargs -0' ?
Don't pipe from cat to grep? Does anybody actually care that people do this (primarily so that the syntax is consistent between a munged- and unmunged-grep, and also such that the order of the command-line is logical from a human point of view)? Plus, of course, it's possible that cat | grep could yield better performance than grep alone: if cat uses mmap() to efficiently read the input files, and the kernel's pipe implementation is good, then it could do better than a grep implementation alone that simply read()s the files.
Slashdot Mirror
Well, that's part of the point: the potential for an attack vector on something like an iPod is pretty minimal.
This is possibly the biggest waste of a story Slashdot's had in a while.
Not only does it only 'infect' iPods running Linux, but it's not even able to replicate. To call it a virus is stretching the truth, to say the least; it's just a program that trashes your binaries.
The way I have to work is that I produce a spec from client meetings and discussions, which then gets sent off for approval. The client knows the the approvals process is important, because anything that deviates from the spec (when it's down to them getting it wrong, not us) will cost them extra.
We value the spec because it's what we work to, the client values the spec because it's their bottom line. As a result, we work together to ensure the spec is right before we start.
View them? Yes. Sell something infringing upon them without expecting to end up in court? No. Her point being: if they weren't protected by law, the would-be holders wouldn't be terribly happy about them being freely viewable (I'm sure many aren't happy about it as it is, but you have to pick one: patent protection or trade secret)
You could, but I'd have to wonder what the point would be.
So Wikipedia has a poor standing in academic communities. So what? I bet the Encyclopaedia Britannica doesn't have a much better standing (especially not after that semi-recent study showed that it was only marginally more accurate than Wikipedia, despite being incredibly costly to obtain and having significantly shorter entries in general).
What the academic community seems to want is a nice resource site collating the results of peer-reviewed studies. And, er, that's it.
Wikipedia's poor standing with respect to academia can be countered with a two-word argument: 'So what?'.
If you don't like it, you don't use it. If you quote stuff from Wikipedia without checking out the references it cites (or do so when it doesn't cite any), then _you_ deserve the brunt of the criticism, not Wikipedia. (And instead of complaining about inaccuracies, maybe some of these people could help improve it-it would benefit them and their peers too, after all).
Bollocks. An implicit contract is formed (although it can be explicit, obviously) between you and a supplier/retailer for them to supply a license (along with--usually, but not exclusively) the physical media of the software. The license itself is not the contract.
Well, let's see; to have a contract, you need an offer, an acceptance of the offer, a promise to perform, a valuable consideration, terms and conditions of performance, and the performance itself. A license (certainly a EULA) doesn't tick the boxes, and from my reading the US courts that have put it to the test say that if it _is_ a contract, it's an unenforceable one (because it doesn't do what a contract does) or that it's a distinct legal instrument.
There will be an (typically implicit) contract between you and a software retailer, but there is no contract between you and the software producer, just a grant of rights.
Since you're in no position to negotiate, can't see the terms of the agreement, no money changes hands, no papers are signed, and licenses supposedly apply to individuals who are not in a position to enter into legal contracts (e.g., minors), a EULA being a contract would be very difficult indeed.
A license is a grant of rights. It doesn't claim to be anything beyond that, so it's not 'nothing' (if it was nothing, you'd have no permission to use or distribute any software you didn't write yourself).
The only contract involved in consumer-level software is the one formed between the retailer and the buyer when you purchase it (if you obtained it that way), and that's generally an implicit contract anyway.
(Obviously there are contracts involved in software quite regularly; when one individual or company is contracted to produce software for another, but that contract will _contain_ a license if copyright isn't signed over wholesale).
Basically, contracts and licenses are two different kinds of legal instrument, albeit ones which are often confused with one another. Go ask a lawyer.
A software license (be it EULA or something else) is not a contract.
That's a lovely sentiment, and completely ignores the real issue that you get to (and was raised on the mailing list in response to the 'open letter') if you read past ESR's rant.
Just because ESR is an idiot with a history is irrelevant: _he has a point_. Yum is broken (forced package removal or not). From a user perspective, this means Fedora Core is broken, and in truth it's by no means limited to Fedora Core.
And why should he have to, exactly?
He's written enough software (and HOWTOs, and FOLDOC entries, and everything else) that you can classify him firmly as 'computer-literate', moreso, you can classify him firmly as 'Linux-literate', and having used RH-based distributions for well over a decade, I'd place a firm bet that he's quite versed with the ins and outs of those specific Linux-based variants.
Where in this picture should support come into it, let alone paying for it? X, Y and Z are broken, what do you do? Do you PAY for support so you can be told that yes, they're broken--for the now incountable time, or do you take it back to the shop because it's actually broken?
What would you do if you bought a home appliance and it didn't work?
Software, and computers in general, are supposed to work. They're not supposed to fuck up. The job of programmers--free and proprietary alike--is to produce software that works. Very little of it out there actually does, and yet developers have the barefaced audacity to say 'not my problem, send patches if you don't like it' when some poor sap (experienced or otherwise) who's come along after the invitation of 'hey, use my software!' [or worse: the pre-packaged shiny distribution that screams the same in big letters] and discovers that it doesn't do what it says on the tin and DARES to get a little annoyed about the fraction of their lifespan that they've wasted dicking around with it.
All software has bugs. Bugs aren't the problem, really. The problem is the utter lack of decent QA in these distributions (and don't think I'm just pointing the finger at Linux distributions: huge multi-national software corporations have exactly the same problem with their latest 'Wow factor', too).
I'm sure there used to be a time where things didn't get shipped if people weren't happy with them. Since when did the fact that you're volunteering your time to maintain this stuff mean that you can forego that fairly fundamental step? One of the points of the free software movement was that 'free' meant 'speech', not 'beer'. Right now, an awful lot of free software out there just looks cheap, and it shows.
For the love of god, why can't a bunch of guys get together and produce a distribution that actually works? If it's broken, you don't ship it. If the first release only contains about five packages, all power to them. The next release will contain ten, and the release after that will contain fifty. All of the distributions out there at the moment are building upon upstream work which itself isn't finished, and quietly introducing even more problems whilst noisily fixing some of the glaring upstream ones.
Seriously, I just don't get what the rush is to compete. You can't compete when all you've got is broken software.
In which case, the difference is going to be negligible, especially on a decent system (where launching an additional process has very little overhead).
Re-read what I said. If cat uses mmap() and the kernel's pipe implementation is good [i.e., such that grep's read() is negligible], then it could do better than a grep implementation alone that simply read()s the files.
...is so littered with basic errors that it really shouldn't be recommended to anybody. How is 'tar xvf -C tmp/a/b/c newarc.tar.gz' expected to work, for example? Quote variables with square brackets? Running subshell commands using ; instead of && ? No mention of 'xargs -0' ? Don't pipe from cat to grep? Does anybody actually care that people do this (primarily so that the syntax is consistent between a munged- and unmunged-grep, and also such that the order of the command-line is logical from a human point of view)? Plus, of course, it's possible that cat | grep could yield better performance than grep alone: if cat uses mmap() to efficiently read the input files, and the kernel's pipe implementation is good, then it could do better than a grep implementation alone that simply read()s the files.