The word is "lying", not "lieing" -- and yes, they did. If I gently suggest that you're prevaricating, and coach that suggestion such as to avoid being boldly offensive, I'm still stating to the outside world (or at least that portion which is listening closely enough to catch my meaning) that I believe you lied. And no, I didn't interpret the IG report as "prima facia lying"; I interpreted it as an accusation of prima facia lying. It's a pretty damn clear accusation, at that.
But, anyone with a sense of professional journalistic integrity should know that it is inappropriate for a headline writer to express his or her own opinions via the choice of words used in the headline.
Bullshit. News media -- particularly the new media of which slashdot is a part, but traditional media as well -- has never been impartial, and for a media outlet to claim impartiality by suppressing overt references to the positions it takes is dishonest to its readership.
The report does state that the TSA has engaged in behaviour that is prima facia lying, even though said report doesn't use that word. Consequently, Bruce isn't disputing the report; rather, he's recasting its conclusions in a less favorable light, without arguing with the facts it found. Since there's no question of fact -- merely interpretation of facts which are agreed on by both the report and Bruce -- the/. editors are behaving entirely within the bounds of proper ethics in their claims.
If the person that said that the precautions were in place honestly thought that they were in place he wasn't lying.
You're speaking as to whether an individual member of the organization lied. What's at question, however, is whether the organization itself lied.
If a company spokesperson is given incorrect information, believes that information to be the truth, and proceeds to provide it to the public, the spokesperson may not be lying -- but the company still is.
Not enough samples there to make a good training set, though. Without more -- a lot more -- you'd end up with a system that could recognize the activities taken by the 9/11 hijackers preparatory to their actions... but not necessarily anyone else, or even the same individuals using different procedures.
And because they're illegal, its REALLY HARD to get drugs.
No, it's not. I don't use illegal drugs -- never did much and haven't at all in a long time -- but I know firsthand that they're not at all hard to get, so long as you know the right people. Further, in just about every neighborhood I've lived in, I've had a pretty good idea of who the right people were there, even if I've never taken advantage of that knowledge. If you use drugs, you know the right people to get them -- and finding those people isn't exactly hard.
I don't have any firsthand knowledge here, but I'd be shocked if this statement didn't follow as well: If you're a professional criminal interested in using them, you know the right people to get unregistered or illegally modified guns. I'm pretty sure I know [can identify, not really know] people who happen through my current neighborhood on occasion who could introduce me to said people. I'd be taking plenty of risks, sure -- but criminals who are sufficiently risk-averse don't use guns.
I ask because I work at a startup, and it's *very* well understood how the company's financial wellbeing will contribute to our own. My stock options are such that ((current_share_price - strike_price) * (number_of_options)) is well over 50% the price of my house, and anything that can be done to boost that share price a bit more... well, the benefit is obvious.
So, see, I don't mind giving good ideas to the company, because they boost that share price, and thus my potential future earnings. Not only that, but ignoring the company's benefit in exchange for focusing on my own cheats not only me and the company -- but the folks I've worked with over the last few years as well. So from where I stand, trying to keep good ideas for oneself is shortsighted (I can probably make more off these ideas w/ the company backing them) and selfish (sharing the ideas w/ the company means it's not just my own benefit but that of my cohorts as well).
Google may not really be a startup anymore -- but from what I can gather, they do their very best to stay an engineering shop -- and a good chunk of the company is in the hands of their employees. If you want to see the worst when you look at them, you're welcome to do so -- but those of us who are a bit less cynical (and who have worked in environments closer to the ideal they strive for -- my last employer was also a startup engineering shop with a damn-near-elite engineering team [and is, incidentally, still in business]) can see a far less tainted side of things.
Mmm. I've seen document archival formats available (patented, I think) taylored for printed documents -- using one of these, it should be possible to get your typical page well below 100K, and stay in that general range even with drawn illustrations (though anything w/ color or photo-style images is no longer suitable). DjVu is a prime example of these, though others exist.
So keeping the scanned images shouldn't really require such a tremendous amount of space.
PyMusick could send any public key it wants, but if it doesn't know the private key it doesn't do it any good.
If you actually read the parent post in full and thought about it for a moment, you'd know that he supposed that the private key were reverse-engineered out of iTunes -- not exactly a hard thing to do, given that it's necessarily included in every copy.
Ok- now I see what kind of a moron I am dealing with.
One bad thing about ad hominems -- they tend to backfire.
But X11->VNC=>VNC is more efficient than X11->Simulated-Framebuffer=>MS-Windows, because the Simulated-Framebuffer=>MS-Windows part is inefficient.
I concede that point. I've always conceded that point. It's the special-purpose apps that having a framebuffer is useful for, granted -- but in a previous life, I had to do a lot of stuff with such special-purpose apps.
Sure, and there are some special-purpose apps where that is useful. But we're talking about running Knoppix under Windows.
Nuh-uh. The head of this thread asked, in effect, "is there anything QEMU is better than coLinux for?", rather than "is there any good reason Knoppix should use QEMU rather than coLinux?". Those are two very, very different questions, and the first one is the one I've been trying to answer.
That's right. I don't see SourceForge using it. (They've certainly shown how unscalable CVS is, with the way they've had to bend over backwards just to provide reliable anonymous read access to a large number of clients -- something a dumb-server-model VC system can do literally as easily as scaling up webspace).
This whole thread is really, really silly.
If you're familiar with Arch (from which Baz-NG copies the good ideas and throws away the bad ones), it's scalable by design. The "server" is dumb storage (like an unmodified [as in, unlike SVN, no new modules applied] Apache WebDAV or sftp server). Consequently, no forking on the server, so there's no chance that adding additional clients could possibly overwhelm the server.
If you're referring to very large trees, many of Arch's internal operations are based on tools along the lines of tar, patch, etc; it's inventory and friends that are natively implemented and potentially time-consuming. So, what does this mean? If inventory or its equivalent turns out to be too slow in Baz-NG, it (individually) gets to be implemented as a C module. Not a problem!
The cases where there could be scalability problems are things like locking algorithms for the repository, and the Arch world has come up with a number of solutions for that -- either using a PQM to serialize writes, or using filesystem-based locking (and requiring clients to wait on their write operations until the lock is released or broken).
So, do you have any more grounds for this "it's-written-in-Python-so-it-must-be-unscalable" kick?
Not if you do it right. A 320kbps mp3 is a whole lot less 'artifacted' than apple's own compression scheme. You wouldn't lose any quality, just a little time.
Nope. Here's the thing:
Lossy audio codecs have a model they use to determine which data out of the stream can be heard by the human ear and which data can't; they then proceed to throw away the latter.
So, taking the AAC data, you've already thrown away the data you can't hear when you're listening to the data that it decided you can. When you then reencode to MP3, you're layering a second model on top of it, and only keeping the data that's marked audible from both. That means that if the models have two different and non-overlapping ways to get you to recognize a given frequency, the final result comes out with neither.
This is why encoding with a lossy compression algorithm coming from another lossy algorithm is a Bad Thing.
I don't see that many riders with loud pipes dressing completely in yellow, which they would do if making others aware of their presence was really the foremost consideration.
Incidentally, Aerostich sells a bright yellow suit, of the same color used for clothing for road workers. There have been studies done with those (in the context of road workers, not motorcyclists), and it's quite clear that they do promote visibility. So -- yes, point conceded, inasmuch as proven-effective alternatives exist and are commercially available, yet infrequently used. (As an aside, an Aerostitch saved my skin -- literally -- more times than I'd like to admit).
There is no statistical proof that loud motorcycles increase rider safety, and any anecdotal evidence is easily overcome by anecdotal evidence that people are annoyed by motorcycle noise.
Maybe. I'd be curious to know how our definitions of "loud" differ. From my perspective, for the purposes of this conversation, even a bike with stock pipes is comparitively loud (as opposed to the sound of the fuel-cell vehicle here, or an average gasoline-powered highway-going vehicle). Aftermarket pipes, or pipes w/ the muffler knocked out with a piece of rebar (as one of my friends did to his bike) are beyond the point where I'll grant even without evidence that returns are likely diminishing. As for the judgement call wrt which anecdotal evidence is controlling without real numbers on either side, I think we may just have to agree to disagree on that 'till someone does a study and numbers become available.
(Unfortunetly, the best methodology that comes to mind for gathering numbers would involve having a proper driving simulator, complete with rear windows and such that the driver needs to turn their head to check their blind spots; if it weren't for the trouble and expense of building or borrowing such equipment, I'd think such a study would be a fairly good candidate for being done in an academic environment). OTOH, maybe one of the insurance companies would fund and provide equipment for such a thing.
As an additional aside, I've seen some rather quiet BMW police bikes in use in northern.ca.us; it'd be interesting to hear feedback from the officers involved.
You might think I'm being paranoid, but I firmly believe that a healthy dose of paranoia makes for a healthier rider.
Agreed as to the principal -- though wouldn't one application of said paranoia be tending towards the use of a (potential but unproven) safety precaution, so long as one is cautious not to allow said precaution to promote overconfidence?
...yet a Harley can drive up my street at 2 AM and not be considered a problem, while this person was on the way to work in the morning and got ticketed because the windows were down in the car and the cop could hear the music.
Would it make a difference whether the Harley driver were going in to work at 2AM? If not, how does it matter what your friend was doing at the time?
I'll grant that it's possible to over-the-top wrt loud pipes -- but the biggest risk to a competant motorcyclist is cagers who don't know about their presence. Driving a silent vehicle sure seems to me like it would exaserbate that risk.
The VNC server is an optimized software implementation of X11, the same implementation you run on a framebuffer device. It sends screen deltas through an efficient IPC mechanism to a client.
Yup, but is the X11->VNC=>VNC viewer really going to be more efficient than X11=>X server? I'm a hard sell on that one.
Think about it: if you run an X11 server on an emulated framebuffer, the framebuffer emulation gets no information about what parts of the frame buffer have been updated; it needs to figure all of that out and then reverse engineer graphics calls to the host window system.
Sure. If you want performance, the existant approach (X server on the host) makes most sense -- more, I'd argue, than VNC on the host. The point of running a framebuffer is to support things like Qt/E or Gtk/FB or native framebuffer apps or so forth, not to replace {X,VNC} on the host.
OTOH, having an area of memory that's a DirectX surface (mapped directly to video memory if possible) available to the coLinux instance as a framebuffer doesn't strike me as being all *that* hard (though I'm sure I'd understand what bits are tricky better if I tried to implement it), and that -would- be reasonably performant.
CoLinux works like a charm using VNC: you run a VNC server on the Linux side and a VNC client on the Windows side.
VNC is not exactly fast or efficient -- being a local display mechanism isn't what it's designed for, and it shows.
That's irrelevant for Knoppix. Furthermore, no, I have not wanted to run Freedos or the SLES9 installer.
I know that. That's why I addressed "the presently relevant set of cases" and a more general situation independantly.
Every post in this thread I've written from Firefox running in a coLinux instance displaying via the Cygwin X server. I use coLinux, I like coLinux, but that's not to say that other solutions like QEMU have no place. The parent asked if there existed any advantage of QEMU over coLinux -- not specific to Knoppix but in general. I answered that question.
Increasingly, yes, investors look primarily at the short term.
That's not the way it used to be, though, and not everyone takes that view. Implying that all investors -- and all investment companies -- are alike in their outlook is misleading.
From the reports I've seen, qemu is VERY slow. Is there an advantage to qemu over coLinux?
Sure, even when you restrict it to the presently relevant set of cases (x86/Linux inside x86/Win32): coLinux has no (non-experimental) framebuffer support; the experimental version that does exist has its performance measured in seconds per frame. The only way to run X is by having an X server on your Windows box, and you can't run Qt/E or GtkFB or such at all. If you want to do embedded systems development, this can be a substantial issue.
If you don't restrict yourself to that subset of cases, then QEMU wins on account of having support for far more than just a custom build of the Linux kernel. (Want to play with FreeDOS? Test your new build of of GRUB? Run through the SLES9 installer? The first two of these simply aren't possible in coLinux, and the 3rd one requires a lot of work to make it happen).
Also, COFS is so experimental/unstable I'm not sure I'd claim it as a feature yet.
You can try to rationalize not-for-profit piracy all you want, but it's still illegal.
Prior to 1996 or so, noncommercial infringement was illegal but there weren't any penalties for it. I think there are those who would welcome a return to that state.
I already said that (in the subject line of my message). Why do you ask me to repeat myself?
Arguably, this is considerably worse than your conventional personal-use copying inasmuch as it's done for purposes of financial gain. Whereas most presently ongoing software piracy would have been unactionable prior to redefinition of the relevant laws (to include receipt of other protected works as "gain"), this in particular would have been illegal even under the older regulations.
(I'm likewise inclined to argue that from a moral perspective, use of copyrighted material without a license is considerably more reprehensible when done with the expectation of financial gain).
What the article is really talking about is what would it take to get nearly everyone downloading music legally.
Just so, though there's more to that than price. I'd make exclusive use of a music download service that charged $.15/song and let me use the format of my choice (including DRMless ones). If I had to use a DRM-hobbled format, paying even $.05 would be pushing it -- I want to take my music on my laptop, the big system at home, my private AFS share at work (so I can listen when borrowing someone else's workstation), etc; needing to download a separate copy for each system (and risk some of them not working with Linux) would be a dealbreaker.
Whadaya mean, "the/. position"? There is no one/. position.
The sane position, though, is this:
CherryOS isn't stolen code, because copyright infringement and theft are two different things. It does, however, contain code which is illegally distributed without a license (since the auther fails to accept and follow the terms of the GPL), hence its authors are evil bastards.
Just like any other license (other than release into public domain), the GPL has conditions on it. If you follow those limitations, it's OK to use GPLd code. If you don't, it's not.
No, but seriously; they (CherryOS bastards) are advertising the fact that you can do something illegal
Their grounds are what? Tortuous interference with a contract? That requires actual damages to stick.
Unless you induce someone to break a contract in such a way to cause damage to the party whom the contract was with, it's not grounds to sue -- and no, it's not "illegal" in the sense of a criminal violation; it's merely potential grounds for a civil suit (but see above).
Slashdot Mirror
The IG report did not accuse TSA of lieing
The word is "lying", not "lieing" -- and yes, they did. If I gently suggest that you're prevaricating, and coach that suggestion such as to avoid being boldly offensive, I'm still stating to the outside world (or at least that portion which is listening closely enough to catch my meaning) that I believe you lied. And no, I didn't interpret the IG report as "prima facia lying"; I interpreted it as an accusation of prima facia lying. It's a pretty damn clear accusation, at that.
But, anyone with a sense of professional journalistic integrity should know that it is inappropriate for a headline writer to express his or her own opinions via the choice of words used in the headline.
Bullshit. News media -- particularly the new media of which slashdot is a part, but traditional media as well -- has never been impartial, and for a media outlet to claim impartiality by suppressing overt references to the positions it takes is dishonest to its readership.
Otherwise, I'm not interested in their opinions.
Then stop reading.
The report does state that the TSA has engaged in behaviour that is prima facia lying, even though said report doesn't use that word. Consequently, Bruce isn't disputing the report; rather, he's recasting its conclusions in a less favorable light, without arguing with the facts it found. Since there's no question of fact -- merely interpretation of facts which are agreed on by both the report and Bruce -- the /. editors are behaving entirely within the bounds of proper ethics in their claims.
BTW, it's "lying", not "lieing".
If the person that said that the precautions were in place honestly thought that they were in place he wasn't lying.
You're speaking as to whether an individual member of the organization lied. What's at question, however, is whether the organization itself lied.
If a company spokesperson is given incorrect information, believes that information to be the truth, and proceeds to provide it to the public, the spokesperson may not be lying -- but the company still is.
Is Slashdot vouching for the fact that the TSA lied? One investigation says it didn't, and one individual says it did.
The investigation said that the TSA claimed to have privacy precautions in place when, in fact, it didn't.
Even if the investigation didn't use the word -- how is that not lying?
Not enough samples there to make a good training set, though. Without more -- a lot more -- you'd end up with a system that could recognize the activities taken by the 9/11 hijackers preparatory to their actions... but not necessarily anyone else, or even the same individuals using different procedures.
Please, reread for my sarcasm.
Oops. Sorry.
And because they're illegal, its REALLY HARD to get drugs.
No, it's not. I don't use illegal drugs -- never did much and haven't at all in a long time -- but I know firsthand that they're not at all hard to get, so long as you know the right people. Further, in just about every neighborhood I've lived in, I've had a pretty good idea of who the right people were there, even if I've never taken advantage of that knowledge. If you use drugs, you know the right people to get them -- and finding those people isn't exactly hard.
I don't have any firsthand knowledge here, but I'd be shocked if this statement didn't follow as well: If you're a professional criminal interested in using them, you know the right people to get unregistered or illegally modified guns. I'm pretty sure I know [can identify, not really know] people who happen through my current neighborhood on occasion who could introduce me to said people. I'd be taking plenty of risks, sure -- but criminals who are sufficiently risk-averse don't use guns.
Where do you work?
I ask because I work at a startup, and it's *very* well understood how the company's financial wellbeing will contribute to our own. My stock options are such that ((current_share_price - strike_price) * (number_of_options)) is well over 50% the price of my house, and anything that can be done to boost that share price a bit more... well, the benefit is obvious.
So, see, I don't mind giving good ideas to the company, because they boost that share price, and thus my potential future earnings. Not only that, but ignoring the company's benefit in exchange for focusing on my own cheats not only me and the company -- but the folks I've worked with over the last few years as well. So from where I stand, trying to keep good ideas for oneself is shortsighted (I can probably make more off these ideas w/ the company backing them) and selfish (sharing the ideas w/ the company means it's not just my own benefit but that of my cohorts as well).
Google may not really be a startup anymore -- but from what I can gather, they do their very best to stay an engineering shop -- and a good chunk of the company is in the hands of their employees. If you want to see the worst when you look at them, you're welcome to do so -- but those of us who are a bit less cynical (and who have worked in environments closer to the ideal they strive for -- my last employer was also a startup engineering shop with a damn-near-elite engineering team [and is, incidentally, still in business]) can see a far less tainted side of things.
Mmm. I've seen document archival formats available (patented, I think) taylored for printed documents -- using one of these, it should be possible to get your typical page well below 100K, and stay in that general range even with drawn illustrations (though anything w/ color or photo-style images is no longer suitable). DjVu is a prime example of these, though others exist.
So keeping the scanned images shouldn't really require such a tremendous amount of space.
PyMusick could send any public key it wants, but if it doesn't know the private key it doesn't do it any good.
If you actually read the parent post in full and thought about it for a moment, you'd know that he supposed that the private key were reverse-engineered out of iTunes -- not exactly a hard thing to do, given that it's necessarily included in every copy.
Ok- now I see what kind of a moron I am dealing with.
One bad thing about ad hominems -- they tend to backfire.
But X11->VNC=>VNC is more efficient than X11->Simulated-Framebuffer=>MS-Windows, because the Simulated-Framebuffer=>MS-Windows part is inefficient.
I concede that point. I've always conceded that point. It's the special-purpose apps that having a framebuffer is useful for, granted -- but in a previous life, I had to do a lot of stuff with such special-purpose apps.
Sure, and there are some special-purpose apps where that is useful. But we're talking about running Knoppix under Windows.
Nuh-uh. The head of this thread asked, in effect, "is there anything QEMU is better than coLinux for?", rather than "is there any good reason Knoppix should use QEMU rather than coLinux?". Those are two very, very different questions, and the first one is the one I've been trying to answer.
Hmm yes, 'cos no one has proven SVN scalable.
That's right. I don't see SourceForge using it. (They've certainly shown how unscalable CVS is, with the way they've had to bend over backwards just to provide reliable anonymous read access to a large number of clients -- something a dumb-server-model VC system can do literally as easily as scaling up webspace).
This whole thread is really, really silly.
If you're familiar with Arch (from which Baz-NG copies the good ideas and throws away the bad ones), it's scalable by design. The "server" is dumb storage (like an unmodified [as in, unlike SVN, no new modules applied] Apache WebDAV or sftp server). Consequently, no forking on the server, so there's no chance that adding additional clients could possibly overwhelm the server.
If you're referring to very large trees, many of Arch's internal operations are based on tools along the lines of tar, patch, etc; it's inventory and friends that are natively implemented and potentially time-consuming. So, what does this mean? If inventory or its equivalent turns out to be too slow in Baz-NG, it (individually) gets to be implemented as a C module. Not a problem!
The cases where there could be scalability problems are things like locking algorithms for the repository, and the Arch world has come up with a number of solutions for that -- either using a PQM to serialize writes, or using filesystem-based locking (and requiring clients to wait on their write operations until the lock is released or broken).
So, do you have any more grounds for this "it's-written-in-Python-so-it-must-be-unscalable" kick?
Lossy audio codecs have a model they use to determine which data out of the stream can be heard by the human ear and which data can't; they then proceed to throw away the latter.
So, taking the AAC data, you've already thrown away the data you can't hear when you're listening to the data that it decided you can. When you then reencode to MP3, you're layering a second model on top of it, and only keeping the data that's marked audible from both. That means that if the models have two different and non-overlapping ways to get you to recognize a given frequency, the final result comes out with neither.
This is why encoding with a lossy compression algorithm coming from another lossy algorithm is a Bad Thing.
(Unfortunetly, the best methodology that comes to mind for gathering numbers would involve having a proper driving simulator, complete with rear windows and such that the driver needs to turn their head to check their blind spots; if it weren't for the trouble and expense of building or borrowing such equipment, I'd think such a study would be a fairly good candidate for being done in an academic environment). OTOH, maybe one of the insurance companies would fund and provide equipment for such a thing.
As an additional aside, I've seen some rather quiet BMW police bikes in use in northern .ca.us; it'd be interesting to hear feedback from the officers involved.
Agreed as to the principal -- though wouldn't one application of said paranoia be tending towards the use of a (potential but unproven) safety precaution, so long as one is cautious not to allow said precaution to promote overconfidence?...yet a Harley can drive up my street at 2 AM and not be considered a problem, while this person was on the way to work in the morning and got ticketed because the windows were down in the car and the cop could hear the music.
Would it make a difference whether the Harley driver were going in to work at 2AM? If not, how does it matter what your friend was doing at the time?
I'll grant that it's possible to over-the-top wrt loud pipes -- but the biggest risk to a competant motorcyclist is cagers who don't know about their presence. Driving a silent vehicle sure seems to me like it would exaserbate that risk.
The VNC server is an optimized software implementation of X11, the same implementation you run on a framebuffer device. It sends screen deltas through an efficient IPC mechanism to a client.
Yup, but is the X11->VNC=>VNC viewer really going to be more efficient than X11=>X server? I'm a hard sell on that one.
Think about it: if you run an X11 server on an emulated framebuffer, the framebuffer emulation gets no information about what parts of the frame buffer have been updated; it needs to figure all of that out and then reverse engineer graphics calls to the host window system.
Sure. If you want performance, the existant approach (X server on the host) makes most sense -- more, I'd argue, than VNC on the host. The point of running a framebuffer is to support things like Qt/E or Gtk/FB or native framebuffer apps or so forth, not to replace {X,VNC} on the host.
OTOH, having an area of memory that's a DirectX surface (mapped directly to video memory if possible) available to the coLinux instance as a framebuffer doesn't strike me as being all *that* hard (though I'm sure I'd understand what bits are tricky better if I tried to implement it), and that -would- be reasonably performant.
Every post in this thread I've written from Firefox running in a coLinux instance displaying via the Cygwin X server. I use coLinux, I like coLinux, but that's not to say that other solutions like QEMU have no place. The parent asked if there existed any advantage of QEMU over coLinux -- not specific to Knoppix but in general. I answered that question.
Increasingly, yes, investors look primarily at the short term.
That's not the way it used to be, though, and not everyone takes that view. Implying that all investors -- and all investment companies -- are alike in their outlook is misleading.
From the reports I've seen, qemu is VERY slow. Is there an advantage to qemu over coLinux?
Sure, even when you restrict it to the presently relevant set of cases (x86/Linux inside x86/Win32): coLinux has no (non-experimental) framebuffer support; the experimental version that does exist has its performance measured in seconds per frame. The only way to run X is by having an X server on your Windows box, and you can't run Qt/E or GtkFB or such at all. If you want to do embedded systems development, this can be a substantial issue.
If you don't restrict yourself to that subset of cases, then QEMU wins on account of having support for far more than just a custom build of the Linux kernel. (Want to play with FreeDOS? Test your new build of of GRUB? Run through the SLES9 installer? The first two of these simply aren't possible in coLinux, and the 3rd one requires a lot of work to make it happen).
Also, COFS is so experimental/unstable I'm not sure I'd claim it as a feature yet.
You can try to rationalize not-for-profit piracy all you want, but it's still illegal.
Prior to 1996 or so, noncommercial infringement was illegal but there weren't any penalties for it. I think there are those who would welcome a return to that state.
I already said that (in the subject line of my message). Why do you ask me to repeat myself?
Arguably, this is considerably worse than your conventional personal-use copying inasmuch as it's done for purposes of financial gain. Whereas most presently ongoing software piracy would have been unactionable prior to redefinition of the relevant laws (to include receipt of other protected works as "gain"), this in particular would have been illegal even under the older regulations.
(I'm likewise inclined to argue that from a moral perspective, use of copyrighted material without a license is considerably more reprehensible when done with the expectation of financial gain).
What the article is really talking about is what would it take to get nearly everyone downloading music legally.
Just so, though there's more to that than price. I'd make exclusive use of a music download service that charged $.15/song and let me use the format of my choice (including DRMless ones). If I had to use a DRM-hobbled format, paying even $.05 would be pushing it -- I want to take my music on my laptop, the big system at home, my private AFS share at work (so I can listen when borrowing someone else's workstation), etc; needing to download a separate copy for each system (and risk some of them not working with Linux) would be a dealbreaker.
Whadaya mean, "the /. position"? There is no one /. position.
The sane position, though, is this:
CherryOS isn't stolen code, because copyright infringement and theft are two different things. It does, however, contain code which is illegally distributed without a license (since the auther fails to accept and follow the terms of the GPL), hence its authors are evil bastards.
Just like any other license (other than release into public domain), the GPL has conditions on it. If you follow those limitations, it's OK to use GPLd code. If you don't, it's not.
What's so difficult about this?
Unless you induce someone to break a contract in such a way to cause damage to the party whom the contract was with, it's not grounds to sue -- and no, it's not "illegal" in the sense of a criminal violation; it's merely potential grounds for a civil suit (but see above).