I mean, I looked at the source of speedofart.com, can't find a blink tag. It's possible I'm not looking hard enough; I've certainly had my fill of tricky Javascript problems today.
I keep hearing this rumor that they make most of their money on ringtones now.
They really, badly need to get back to their core business. It's evolved a bit, but they still have a chance to figure it out before all their artists flip them the bird and go completely independent.
This is the Internet. You have one shot to become the middleman, before someone like Google or Amazon takes that role from you.
if you walked into a bookstore with a laptop, scanned an entire book into the computer with a scanner, and then walked out, it would be illegal.
Agreed, although there are two points to consider here:
You didn't make this analogy. You made another one, which is, in fact, flawed. So it's not a "strawman" argument, I was actually taking issue with your own, real argument, which I can quote word-for-word back to you if you like.
I believe the original discussion was not on the legality of something, but the morality of it. If you had already purchased the book, and you went and re-scanned the book, it absolutely is illegal. But is it immoral?
To answer that second point, well, my landlord is an artist. A musician, specifically. I recently went online and bought one of his albums, in digital form. I mentioned to him that it was somewhat less quality than a CD (it's a very high-quality MP3), though I did make it clear that humans probably can't tell the difference. Nevertheless, he figured that since I paid full price, it would only be fair to lend me a copy of an actual, physical CD to rip into Flac format if I wanted.
Now, the above isn't actually illegal, since I assume he has copyright, therefore it's an authorized copy. But I think it pretty neatly sums up the morality of the issue.
I was willing to go the Microsoft API and MFC as long as they would let me verify the source code.
Part of what's attractive about open source is knowing that someone, somewhere, is probably verifying it. Probably many someones. This is probably true of all code, but in open source, it seems much more likely that they'd be independent, with independent agendas (or none at all).
So, since I can't review all source code, everywhere, I'd much rather start with open source where I can.
And yes, I do "C", although for larger stuff I prefer C++, especially if I am working with others.
I admit to preferring higher-level stuff myself, but C++ seems like the best balance that exists today, except for maybe Perl/Python/Ruby plus C/asm extensions/bindings. (Which is kind of sad...)
I do not like trying to run fullbore OS realtime... If lucky, I can use techniques similar to audio processing, but again, having a dropout in music may be a minor annoyance, having a dropout in an industrial controller usually results in a batch of unusable product.
Well, I wouldn't suggest Ubuntu, I'd suggest a Linux kernel to start with, with some realtime patches. But only after looking at things like TRON or similar commercial products... although I suppose offloading it to a microcontroller makes sense, too.
Oh yes, the tripwire. Stiller had an integrity checker which I based my scanner from. From what I understand, its essentially tripwire. It lets me know if any of its "watched" files have been tampered with.
See, the problem I have with tripwire is:
If anyone's been able to modify a system binary, what's to prevent them modifying the Tripwire binary? Tripwire (or AIDE) only works so long as they aren't writing Tripwire-aware rootkits.
How many files can I actually watch for modifications? If I only watch system binaries, I won't notice someone messing with/etc/passwd. If I watch all of/etc, I'll get a ton of false positives, so I'd tend to ignore the rest. If I watch/etc/passwd, I might not notice when/etc/sudoers becomes important. You'd need someone whose full-time job is to know the system inside and out -- which might be you, but even as a sysadmin, my job was to know the system well enough to add new functionality (a new email server, a backup system, etc.)
Is the system aware of package updates, or new packages? If it is, does it report them? If so, do I drown in the flood of updates? (Spam, as above.) If not, what if someone compromises the update server?
That's all my opinion, of course. Many of my opinions and security habits run directly contrary to the commonly accepted wisdom in the security community.
I will say that if you had at least one person whose full-time job was the system's security, in depth, then an intrusion detection system would make sense -- in fact, more than one. With an open source or shared source system, you could even have one person (or a team of people) review the source code of each patch before you apply it. There are companies that do this.
It is interesting reading about how you have this setup, though! Even if my instinct is to immediately jump all over your approach and suggest some lightweight Ruby or something on the main control computer, or even a web service. I also have this instinct to suggest TCP/IP or even an HTTP stack -- they make em small enough now -- though I imagine you know about this, and probably are sticking with the simplest thing that can work here, for good reason.
I guess we each have our way of doing things - and I guess its good, as it gives the bad guys not only the problem of outsmarting the code, but trying to figure out how we are going to find out he's been romping around
I remember the excitement when people first started using the trimmed down Firefox versions.
I can't say I remember ever seeing a "trimmed down" Firefox version.
Perhaps you mean Firefox itself? Pheonix was a trimmed-down Mozilla. It was renamed to Firebird, then Firefox, to avoid conflicting with existing products, trademarks, and asshats.
That makes your suggestion all the more humorous.
Lean, mean, secure, and eventually the amazing array of extensions people have grown to no longer be able to do without.
Speak for yourself. I do just fine on Konqueror.
The project needs a top to bottom rewrite to deal with orders of magnitude more demanding usage of large numbers of tabs over days or weeks at a time.
You know, I started out using it for days or weeks at a time. Then I learned about its session management features.
Also, you're welcome to try a complete rewrite. In fact, why don't you join one of the complete rewrite projects, like Webkit?
You see, if it's a complete rewrite, why even call it Firefox anymore? Wouldn't it be a completely other platform? And there already are other platforms that don't leak like a sieve.
1) Implement threading both between tab sessions and within tabs themselves
Between tabs might be possible, but you have to understand, first, that large chunks of Firefox itself is written in JavaScript. The extensions, too. JavaScript is, inherently, not threaded. You get a JavaScript thread -- it can communicate asynchronously with other things, but that's it.
So that means, it would really take a significant amount of effort to make tabs independent, but more importantly, if it would really take a complete rewrite (as you say), it would almost certainly kill one of the main features of Firefox -- that its extensions are so powerful and easy to write.
But let's assume that this was possible, even easy. But, "within tabs"? Are you fucking kidding me? That is not a Firefox rewrite. That is a rewrite of the World Wide Web.
You might get away with some iframe hackery, but even that seems extremely unlikely. JavaScript is NOT threaded. I don't care how many times you, or others like you, want it to be -- the day we have to make a single webpage threaded is the day that webpage can no longer be a webpage, as we know it today. The only way it would continue to be a webpage at all is if we redefine the concept of "webpage".
Hey, I wouldn't mind picking, say, Python as the next scripting language for the Internet. But as long as we're stuck with ECMA-262, you get no threads.
3) Implement some sort of standard memory/resource allocation/deallocation API for extensions so that people can bring up a standard window and see:
People who are really curious can already do something like this: Compare RAM usage with Extension Foo loaded, and without Extension Foo loaded.
Most of us aren't going to care, though. How often do you actually look at how much RAM your system is using, aside from Firefox? Right now, I'm running four instances of Konsole, one of Kopete, and one of Konqueror, and I have absolutely no clue how much RAM any of them are taking -- or even of how much RAM I have free. I could check, but why bother? I've got plenty.
This is actually the least wacky of your ideas, but I think there are actually reasons it would be a technical challenge. And I think if you understood the concept of "extension", as distinct from, say, "program", it would be obvious that such a standard display would be impossible, or if it was even remotely possible, would be insanely misleading.
The save active tabs option has helped to allow people shutdown and wipe the memory slate clean but that really is not a solution a decent piece of software should be forced to rely on.
Agreed, except for the fact that most people are going to have to shutdown anyway. You've got to reboot Windows sometime, and you really should at least hibernate once a day (when you sleep) to save power.
But I have to ask: Who, or what, were you replying to? I don't see a "parent", and I certainly didn't see any mention of Walmart in TFA. Maybe I missed it?
The Judge said that the IP's were available to TorrentSpy as the information was present in the RAM at some point. They required that TorrentSpy log that information.
Which, if TorrentSpy were to be believed, would potentially require modification of the software. Merely because something "was present in the RAM at some point" doesn't imply that it's easy to log, otherwise DRM would be even more broken than it currently is.
Now, of course, we've discovered that TorrentSpy were actually lying about this, but it doesn't change the fact that it was an unreasonable request by the judge, especially considering this is discovery. Are you really going to say that people should have to start gathering entirely new evidence to support discovery?
There was the story of someone who, upon seeing the "You wouldn't steal a car" ad at the beginning of the movie, jumped up and shouted "I would if I could fucking download it!"
If you can't see the difference between stealing a physical item and making a copy of a digital item, you need your head examined. I am not saying copying is right, only that it is different.
Perhaps instead, the DRM's keys/algorithm, or at least a standard binary that could decode the DRM, should be stored by the government. Only a few bytes, or at most, a few megabytes for an entire media format. That would eliminate the need for huge amounts of space and the large maintenance costs.
It would also create the risk of there being no surviving copies of the media by the time it's released. And both this and my scheme are greatly complicated by services like Steam. The simpler the unlocking patch, the greater the likelihood a pirate has it already, either stolen or reverse-engineered.
The real problem is that none of this will actually happen in the next 10 years, and we are arguing over what isn't exactly ours.
The government should be ours, and the commons should be ours. And you seem to agree that things should enter the commons (public domain) much sooner, anyway.
I do agree that none of this is likely to happen in the next 10 years, though I can hope.
Except, of course, that.doc has been much more thoroughly reverse-engineered than SWF.
If you were to email me a random.doc, I can almost certainly open it in KWord. But if you were to send me a random SWF, embedded in a webpage or otherwise, I'd have little to no chance viewing it with Gnash.
Of course, that may have something to do with the relative maturity of various open-source projects, but it is worth mentioning -- although you are right that SWF is, in theory, more open (due to being able to get the spec to write generators), and programs that generate SWF are probably more accurate than programs that generate.doc.
I meant to say, none of our current desktop OSes. (Linux can be made realtime, but I imagine most people would rather simply buy a commercial RTOS.)
As long as I have to reply to myself, it's worth mentioning the history of C. It started out as the high-level language, and is now considered a low-level language. A lot of resistance to it, initially, is that programmers could hand-code better (more efficient, etc) assembly. What has eventually happened is that except in a few, very rare circumstances, the compiler is going to write better assembly than you will -- this partly stems from the fact that the ratio of bugs per lines of code stays constant, no matter what the language, so because C is less verbose than assembly, C code will be less buggy.
Of course, it's not perfect. Sometimes, you really do have to dig into assembly, even simply for performance. Hand-tweaked code can always beat compiler-generated code, but the amount of time and potential for error of that hand-tweaking is why compilers are used almost everywhere now.
I'm not advocating that you switch to C, just pointing out that your need to know things in that amount of depth is not always justified.
A bit of background: It was called Tripwire, and I find it isn't actually all that useful. The reason I suggested it was precisely to point out why I think such an approach won't work -- but if it ends up working for you anyway, I can't argue with that.
Faith is great for religions, but when it comes to keeping a petrochemical plant running, I am insecure as hell until I know everything about how it works.
I have a question for you, though:
How much do you know about electrical engineering? Or engineering, period?
Do you know every circuit in that CPU? Do you know exactly where electrons are moving, and how fast?
At a certain point, you have to start taking things on faith to do your job effectively. For you, this might be at a much lower level than most of us, but I should point out that faith in a tried, tested, and proven system is not really a bad thing. (However, none of our current OSes are to the point where I would take them entirely on faith if I had your job -- but there are OSes designed for exactly that kind of realtime processing.)
As for your own ignorance scaring you, at least you have the excuse of not having created those systems. (A current work project has me scared shitless that I've created, in less than a month, an unmanageably huge ball of mud, and that without another month of refactoring, I'll never understand it thoroughly enough to trust it. But I wrote all of it, which makes it worse...)
Unless they are DRM'd, it doesn't particularly matter what format they're in -- you can transcode them to another lossless format, without loss! (Duh.)
Or you could transcode to mp3 and play it anywhere.
That article is specifically mentioned in TFA. Right at the top of TFA, in fact.
For that matter, TFA is strongly agreeing with you that it's not a problem. It's more of an analysis of different ways of solving the problem -- for instance, do we get to keep net neutrality?
* If ISP never really reaches the bandwidth they somehow promised or - god forbid advertised - he'll be sued, anyway.
Except they are very careful to include bullshit language like "up to", so they can never really be sued for this.
* For video? Have buffer time. DVB-T already lags analog cable two seconds on live events just for recoding and buffering.
That has absolutely nothing to do with bandwidth. Unless your buffer time is quite a bit longer than the video itself, you're not going to get high-def video to play over dialup, or over most "broadband" internet today.
I'm not sure I get your last two points, either. Broadband is already fairly cheap, and mesh radio is not currently technically viable for this amount of data.
And people in rural areas will most definitely see the difference. I live in a small town (10,000 people) in Iowa, and I have DSL at home and fiber at work. And that's only because I haven't had the time to get the fiber run to my house yet.
Well, that gets offtopic, but what more I want is the ability to run my own server instead -- and to be able to interoperate/share with the people on the "official" one.
I've only really seen this happen once in recent years -- GTalk. It's Jabber, which means I can always set up my own Jabber server and still be able to chat with people on GTalk -- yet it doesn't diminish, in any way, the value GTalk gives actual Google users.
(At the risk of getting even more offtopic: Oh, how I wish OpenSocial had been based on something like OpenID.)
Ah, I see. Yes there is a risk of that, but I also don't think it would take long to correct. I mean, exactly how hard is it to check up on piracy?
That was an ad-absurdum. My point is simply that I very much doubt any good-faith effort on the part of pirates is going to change the current RIAA/MPAA tactics of... Who knows what the hell their tactics are? Closing their eyes and pointing at a random number in the phone book?
I also think you underestimate the attraction of not requiring a credit card. Some people just don't like sending out sensitive information over the internet, even if it is reasonably secure. Other people don't have credit cards, like children or people with bad credit history.
All of these could be mitigated with a reasonably trusted Paypal-like service. (For example, my Paypal account is tied to my bank account; I don't need a credit card.)
Basically, I think you can only warm the frog so much before it's flesh starts to boil, and it jumps out in terror.
I hope you're right.
Although, at a certain point, the damage has been done. To abuse a metaphor, its flesh is seared and numb, so it can't even tell how much hotter it's getting.
Example: The browser issue. At this point, most of us have accepted that IE is inextricably bound to Windows, and that this is somehow as it should be, and hey, you can still install Firefox and remove the IE icon, right? And hey, it's not so bad, right?
(Yeah... Tell that to someone who worked at Netscape.)
How so? My understanding of it was that DRM must be able to be decoded solely with the information readable from the disk.
Well, using DRM as a blanket term for all copy protection applied to digital media, some DRM relies on certain sectors being unreadable. Some relies on forcing those sectors to be read. Some relies on reading subtle error-correction data which is intentionally off.
Are you referring to DRM that requires the gathering of information via the internet in order to decode the material, or something like that?
Oh, there's that, too -- which, of course, implies that you'd have to archive the server in question, too, which means it's no longer something which can be done without the consent of the copyright holder.
Are you sure, that's 75 years plus lifetime (or more likely 95 years)! Imagine the speeds our computers could go...
Unless they go quantum, or unless a significant problem is found with RSA, a 4096-bit RSA key will survive Moore's Law. In fact, it would likely survive the heat-death of the Universe.
I'm not entirely confident about this, of course. I could be proven wrong in five years. But so could you -- think, even twenty or thirty years ago, how close AI seemed! My god, can you imagine how fast the computers will be in 2005?! Of course we'll have AI that can accurately mimic humans! Everyone will have their own robot, which will speak and understand natural English!
Except, of course, it didn't happen. So I think it goes a bit farther than "not guaranteed", and into the realm of "who the fsck knows?"
The best way to fix this would be to make copyrights last significantly shorter than a lifetime (of both humans and corporations) and make that law requiring a clear copy to be provided to the public.
That's why I like the escrow idea. You see, that law can't squeeze blood from a stone -- if a company completely goes under before copyright is up, they certainly can't afford to modify their software to work without DRM. If funding was provided for that purpose, how much would it take, given how old and rocky the codebase would be by then?
In other words, this gets more into the realm of "messy and not guaranteed", which is why I feel all media should be available in the clear somew
Personally, I would verify all the system executables for match on file length, checksum, and MD5, against the released version
But it does get more complex at a higher level. What, exactly, is the released version? How many permutations might you have of acceptable file length, checksum, MD5 of system EXEs, DLLs, scripts, registry settings, etc?
What do you do when the released version, itself, is compromised?
In general, I tend to be fairly relaxed when it comes to checking my system for rootkits, because I don't give anything the opportunity in the first place. I have autorun disabled on Windows, and there's no equivalent on Linux, and if there were, it would not have sufficient rights to modify system binaries.
The OS should be able to report what any app does, though.
The problem here is, while that's certainly true, Vista shows how problematic that can be, in practice. "You are coming to a sad realization, cancel or allow?"
For that matter, Linux also shows how problematic that can be -- many users love replacing the detailed log that scrolls by every boot with a simple progress bar (even if the progress bar can't be accurate at all) and absolutely no information about what it's doing. Apparently, ignorance is bliss.
I lost respect for Microsoft when they started doing all this "hidden file" stuff. In my way of thinking, a hidden file is very bad news.
Depends what "hidden file" means. For instance, any file on Unix that begins with a dot is hidden from the directory listing, so average users aren't burdened with all kinds of metadata and system settings. But everyone knows this, so it's easy to see a hidden file.
The problem is not hidden files, it's when files are hidden by rootkits.
You hit the nail on the head when you stated if Windows were locked down that tight, I could not intall Linux....I have no problem with that - I actually expect it.
From your explanation of what you expect, I don't think you appreciate the distinction here.
Right now, of course, I cannot install Linux without booting off some media other than the hard drive -- which usually implies leaving a CD in the drive during a reboot, and quite possibly requires additional intervention after that.
What I'm talking about is telling the hardware not to trust anything not signed, and not letting the user choose the signing authority -- which would mean you could not install Linux unless your hardware manufacturer approved of the particular build of the particular kernel that you wanted to install.
That, I think, is in the opposite direction from what you seem to want, which is transparency and control for the user.
So, to summarize, as simply as I can: There's really nothing an OS vendor can do to completely mitigate the risk of a rootkit. The most sensible steps are much simpler than what you suggest, though what you suggest does actually exist (AIDE and such, but that's another discussion). And while open source is very nice for a few other points you bring up -- you like to know things, and not always take them on faith, and this is much easier when source code is freely available -- that's also pretty fairly unrelated to a rootkit installing itself when a CD is inserted.
Can you imagine the outcry if MS decided that Windows no longer had any form of auto run capability? Things like that are what make users switch platforms.
No other platform that I know of has autorun, and no one seems to care, except on Windows.
Specifically, my Linux has an autoplay-like capability -- if it sees an audio CD, it prompts me to run Amarok. If it sees a DVD, it prompts me to run Kaffeine. And if it sees a CD full of images, it might prompt me to run Gwenview. If it doesn't know what to do, it'll prompt me just to open it (to browse).
But it absolutely will not, ever, simply run a program off the CD, even if it had to warn me first (like Vista does).
Slashdot Mirror
I don't see it.
I mean, I looked at the source of speedofart.com, can't find a blink tag. It's possible I'm not looking hard enough; I've certainly had my fill of tricky Javascript problems today.
Fortunately for all of us, sibling post (or is it "uncle" to mine?) has a link to the original comic.
Unfortunately, I can't find the original PVP Online strip, so you'll have to settle for this forum-bastardized version.
I keep hearing this rumor that they make most of their money on ringtones now.
They really, badly need to get back to their core business. It's evolved a bit, but they still have a chance to figure it out before all their artists flip them the bird and go completely independent.
This is the Internet. You have one shot to become the middleman, before someone like Google or Amazon takes that role from you.
My fault for not reading TFA. Sorry.
There was a bit more to the story, though -- something about them actively deleting threads...
Agreed, although there are two points to consider here:
To answer that second point, well, my landlord is an artist. A musician, specifically. I recently went online and bought one of his albums, in digital form. I mentioned to him that it was somewhat less quality than a CD (it's a very high-quality MP3), though I did make it clear that humans probably can't tell the difference. Nevertheless, he figured that since I paid full price, it would only be fair to lend me a copy of an actual, physical CD to rip into Flac format if I wanted.
Now, the above isn't actually illegal, since I assume he has copyright, therefore it's an authorized copy. But I think it pretty neatly sums up the morality of the issue.
By that logic, I haven't stolen anything when I burn a CD. I'm walking around with my own, legally purchased blank CD, which I've burned.
That's what happens when you don't separate the means of storage from the content. Is that the way you want this discussion to go?
Part of what's attractive about open source is knowing that someone, somewhere, is probably verifying it. Probably many someones. This is probably true of all code, but in open source, it seems much more likely that they'd be independent, with independent agendas (or none at all).
So, since I can't review all source code, everywhere, I'd much rather start with open source where I can.
I admit to preferring higher-level stuff myself, but C++ seems like the best balance that exists today, except for maybe Perl/Python/Ruby plus C/asm extensions/bindings. (Which is kind of sad...)
Well, I wouldn't suggest Ubuntu, I'd suggest a Linux kernel to start with, with some realtime patches. But only after looking at things like TRON or similar commercial products... although I suppose offloading it to a microcontroller makes sense, too.
See, the problem I have with tripwire is:
That's all my opinion, of course. Many of my opinions and security habits run directly contrary to the commonly accepted wisdom in the security community.
I will say that if you had at least one person whose full-time job was the system's security, in depth, then an intrusion detection system would make sense -- in fact, more than one. With an open source or shared source system, you could even have one person (or a team of people) review the source code of each patch before you apply it. There are companies that do this.
It is interesting reading about how you have this setup, though! Even if my instinct is to immediately jump all over your approach and suggest some lightweight Ruby or something on the main control computer, or even a web service. I also have this instinct to suggest TCP/IP or even an HTTP stack -- they make em small enough now -- though I imagine you know about this, and probably are sticking with the simplest thing that can work here, for good reason.
I can't say I remember ever seeing a "trimmed down" Firefox version.
Perhaps you mean Firefox itself? Pheonix was a trimmed-down Mozilla. It was renamed to Firebird, then Firefox, to avoid conflicting with existing products, trademarks, and asshats.
That makes your suggestion all the more humorous.
Speak for yourself. I do just fine on Konqueror.
You know, I started out using it for days or weeks at a time. Then I learned about its session management features.
Also, you're welcome to try a complete rewrite. In fact, why don't you join one of the complete rewrite projects, like Webkit?
You see, if it's a complete rewrite, why even call it Firefox anymore? Wouldn't it be a completely other platform? And there already are other platforms that don't leak like a sieve.
Between tabs might be possible, but you have to understand, first, that large chunks of Firefox itself is written in JavaScript. The extensions, too. JavaScript is, inherently, not threaded. You get a JavaScript thread -- it can communicate asynchronously with other things, but that's it.
So that means, it would really take a significant amount of effort to make tabs independent, but more importantly, if it would really take a complete rewrite (as you say), it would almost certainly kill one of the main features of Firefox -- that its extensions are so powerful and easy to write.
But let's assume that this was possible, even easy. But, "within tabs"? Are you fucking kidding me? That is not a Firefox rewrite. That is a rewrite of the World Wide Web.
You might get away with some iframe hackery, but even that seems extremely unlikely. JavaScript is NOT threaded. I don't care how many times you, or others like you, want it to be -- the day we have to make a single webpage threaded is the day that webpage can no longer be a webpage, as we know it today. The only way it would continue to be a webpage at all is if we redefine the concept of "webpage".
Hey, I wouldn't mind picking, say, Python as the next scripting language for the Internet. But as long as we're stuck with ECMA-262, you get no threads.
People who are really curious can already do something like this: Compare RAM usage with Extension Foo loaded, and without Extension Foo loaded.
Most of us aren't going to care, though. How often do you actually look at how much RAM your system is using, aside from Firefox? Right now, I'm running four instances of Konsole, one of Kopete, and one of Konqueror, and I have absolutely no clue how much RAM any of them are taking -- or even of how much RAM I have free. I could check, but why bother? I've got plenty.
This is actually the least wacky of your ideas, but I think there are actually reasons it would be a technical challenge. And I think if you understood the concept of "extension", as distinct from, say, "program", it would be obvious that such a standard display would be impossible, or if it was even remotely possible, would be insanely misleading.
Agreed, except for the fact that most people are going to have to shutdown anyway. You've got to reboot Windows sometime, and you really should at least hibernate once a day (when you sleep) to save power.
But I have to ask: Who, or what, were you replying to? I don't see a "parent", and I certainly didn't see any mention of Walmart in TFA. Maybe I missed it?
I guess when Bill Gates asks what the hell is going on, he gets results!
Which, if TorrentSpy were to be believed, would potentially require modification of the software. Merely because something "was present in the RAM at some point" doesn't imply that it's easy to log, otherwise DRM would be even more broken than it currently is.
Now, of course, we've discovered that TorrentSpy were actually lying about this, but it doesn't change the fact that it was an unreasonable request by the judge, especially considering this is discovery. Are you really going to say that people should have to start gathering entirely new evidence to support discovery?
There was the story of someone who, upon seeing the "You wouldn't steal a car" ad at the beginning of the movie, jumped up and shouted "I would if I could fucking download it!"
If you can't see the difference between stealing a physical item and making a copy of a digital item, you need your head examined. I am not saying copying is right, only that it is different.
It would also create the risk of there being no surviving copies of the media by the time it's released. And both this and my scheme are greatly complicated by services like Steam. The simpler the unlocking patch, the greater the likelihood a pirate has it already, either stolen or reverse-engineered.
The government should be ours, and the commons should be ours. And you seem to agree that things should enter the commons (public domain) much sooner, anyway.
I do agree that none of this is likely to happen in the next 10 years, though I can hope.
Except, of course, that .doc has been much more thoroughly reverse-engineered than SWF.
.doc, I can almost certainly open it in KWord. But if you were to send me a random SWF, embedded in a webpage or otherwise, I'd have little to no chance viewing it with Gnash.
.doc.
If you were to email me a random
Of course, that may have something to do with the relative maturity of various open-source projects, but it is worth mentioning -- although you are right that SWF is, in theory, more open (due to being able to get the spec to write generators), and programs that generate SWF are probably more accurate than programs that generate
Whoops.
I meant to say, none of our current desktop OSes. (Linux can be made realtime, but I imagine most people would rather simply buy a commercial RTOS.)
As long as I have to reply to myself, it's worth mentioning the history of C. It started out as the high-level language, and is now considered a low-level language. A lot of resistance to it, initially, is that programmers could hand-code better (more efficient, etc) assembly. What has eventually happened is that except in a few, very rare circumstances, the compiler is going to write better assembly than you will -- this partly stems from the fact that the ratio of bugs per lines of code stays constant, no matter what the language, so because C is less verbose than assembly, C code will be less buggy.
Of course, it's not perfect. Sometimes, you really do have to dig into assembly, even simply for performance. Hand-tweaked code can always beat compiler-generated code, but the amount of time and potential for error of that hand-tweaking is why compilers are used almost everywhere now.
I'm not advocating that you switch to C, just pointing out that your need to know things in that amount of depth is not always justified.
A bit of background: It was called Tripwire, and I find it isn't actually all that useful. The reason I suggested it was precisely to point out why I think such an approach won't work -- but if it ends up working for you anyway, I can't argue with that.
I have a question for you, though:
How much do you know about electrical engineering? Or engineering, period?
Do you know every circuit in that CPU? Do you know exactly where electrons are moving, and how fast?
At a certain point, you have to start taking things on faith to do your job effectively. For you, this might be at a much lower level than most of us, but I should point out that faith in a tried, tested, and proven system is not really a bad thing. (However, none of our current OSes are to the point where I would take them entirely on faith if I had your job -- but there are OSes designed for exactly that kind of realtime processing.)
As for your own ignorance scaring you, at least you have the excuse of not having created those systems. (A current work project has me scared shitless that I've created, in less than a month, an unmanageably huge ball of mud, and that without another month of refactoring, I'll never understand it thoroughly enough to trust it. But I wrote all of it, which makes it worse...)
Unless they are DRM'd, it doesn't particularly matter what format they're in -- you can transcode them to another lossless format, without loss! (Duh.)
Or you could transcode to mp3 and play it anywhere.
That article is specifically mentioned in TFA. Right at the top of TFA, in fact.
For that matter, TFA is strongly agreeing with you that it's not a problem. It's more of an analysis of different ways of solving the problem -- for instance, do we get to keep net neutrality?
Except they are very careful to include bullshit language like "up to", so they can never really be sued for this.
That has absolutely nothing to do with bandwidth. Unless your buffer time is quite a bit longer than the video itself, you're not going to get high-def video to play over dialup, or over most "broadband" internet today.
I'm not sure I get your last two points, either. Broadband is already fairly cheap, and mesh radio is not currently technically viable for this amount of data.
And people in rural areas will most definitely see the difference. I live in a small town (10,000 people) in Iowa, and I have DSL at home and fiber at work. And that's only because I haven't had the time to get the fiber run to my house yet.
Well, that gets offtopic, but what more I want is the ability to run my own server instead -- and to be able to interoperate/share with the people on the "official" one.
I've only really seen this happen once in recent years -- GTalk. It's Jabber, which means I can always set up my own Jabber server and still be able to chat with people on GTalk -- yet it doesn't diminish, in any way, the value GTalk gives actual Google users.
(At the risk of getting even more offtopic: Oh, how I wish OpenSocial had been based on something like OpenID.)
That was an ad-absurdum. My point is simply that I very much doubt any good-faith effort on the part of pirates is going to change the current RIAA/MPAA tactics of... Who knows what the hell their tactics are? Closing their eyes and pointing at a random number in the phone book?
All of these could be mitigated with a reasonably trusted Paypal-like service. (For example, my Paypal account is tied to my bank account; I don't need a credit card.)
I hope you're right.
Although, at a certain point, the damage has been done. To abuse a metaphor, its flesh is seared and numb, so it can't even tell how much hotter it's getting.
Example: The browser issue. At this point, most of us have accepted that IE is inextricably bound to Windows, and that this is somehow as it should be, and hey, you can still install Firefox and remove the IE icon, right? And hey, it's not so bad, right?
(Yeah... Tell that to someone who worked at Netscape.)
Well, using DRM as a blanket term for all copy protection applied to digital media, some DRM relies on certain sectors being unreadable. Some relies on forcing those sectors to be read. Some relies on reading subtle error-correction data which is intentionally off.
Oh, there's that, too -- which, of course, implies that you'd have to archive the server in question, too, which means it's no longer something which can be done without the consent of the copyright holder.
Unless they go quantum, or unless a significant problem is found with RSA, a 4096-bit RSA key will survive Moore's Law. In fact, it would likely survive the heat-death of the Universe.
I'm not entirely confident about this, of course. I could be proven wrong in five years. But so could you -- think, even twenty or thirty years ago, how close AI seemed! My god, can you imagine how fast the computers will be in 2005?! Of course we'll have AI that can accurately mimic humans! Everyone will have their own robot, which will speak and understand natural English!
Except, of course, it didn't happen. So I think it goes a bit farther than "not guaranteed", and into the realm of "who the fsck knows?"
That's why I like the escrow idea. You see, that law can't squeeze blood from a stone -- if a company completely goes under before copyright is up, they certainly can't afford to modify their software to work without DRM. If funding was provided for that purpose, how much would it take, given how old and rocky the codebase would be by then?
In other words, this gets more into the realm of "messy and not guaranteed", which is why I feel all media should be available in the clear somew
But it does get more complex at a higher level. What, exactly, is the released version? How many permutations might you have of acceptable file length, checksum, MD5 of system EXEs, DLLs, scripts, registry settings, etc?
What do you do when the released version, itself, is compromised?
In general, I tend to be fairly relaxed when it comes to checking my system for rootkits, because I don't give anything the opportunity in the first place. I have autorun disabled on Windows, and there's no equivalent on Linux, and if there were, it would not have sufficient rights to modify system binaries.
The problem here is, while that's certainly true, Vista shows how problematic that can be, in practice. "You are coming to a sad realization, cancel or allow?"
For that matter, Linux also shows how problematic that can be -- many users love replacing the detailed log that scrolls by every boot with a simple progress bar (even if the progress bar can't be accurate at all) and absolutely no information about what it's doing. Apparently, ignorance is bliss.
Depends what "hidden file" means. For instance, any file on Unix that begins with a dot is hidden from the directory listing, so average users aren't burdened with all kinds of metadata and system settings. But everyone knows this, so it's easy to see a hidden file.
The problem is not hidden files, it's when files are hidden by rootkits.
From your explanation of what you expect, I don't think you appreciate the distinction here.
Right now, of course, I cannot install Linux without booting off some media other than the hard drive -- which usually implies leaving a CD in the drive during a reboot, and quite possibly requires additional intervention after that.
What I'm talking about is telling the hardware not to trust anything not signed, and not letting the user choose the signing authority -- which would mean you could not install Linux unless your hardware manufacturer approved of the particular build of the particular kernel that you wanted to install.
That, I think, is in the opposite direction from what you seem to want, which is transparency and control for the user.
So, to summarize, as simply as I can: There's really nothing an OS vendor can do to completely mitigate the risk of a rootkit. The most sensible steps are much simpler than what you suggest, though what you suggest does actually exist (AIDE and such, but that's another discussion). And while open source is very nice for a few other points you bring up -- you like to know things, and not always take them on faith, and this is much easier when source code is freely available -- that's also pretty fairly unrelated to a rootkit installing itself when a CD is inserted.
I mean, good to know, but Ubuntu comes with OpenOffice.org anyway. Without document sharing, I really don't see the point of this...
No other platform that I know of has autorun, and no one seems to care, except on Windows.
Specifically, my Linux has an autoplay-like capability -- if it sees an audio CD, it prompts me to run Amarok. If it sees a DVD, it prompts me to run Kaffeine. And if it sees a CD full of images, it might prompt me to run Gwenview. If it doesn't know what to do, it'll prompt me just to open it (to browse).
But it absolutely will not, ever, simply run a program off the CD, even if it had to warn me first (like Vista does).
The entire reason you need the software to play this music is because when you first inserted the CD, it installed itself and made sure of that.
So if you had autorun/autoplay completely disabled, you could run, say, Windows CD Player, and play it without running any software off the disc.
Or you could boot Linux and just play it.