My point was that, under Linux, "creator" isn't very useful. Most of my files are created by "emacs" (or "cp" or "sed" or something, when I copy a template), but what I normally do with them is compile them. The filename extension only matters a bit (saves having to tell the compiler what language it is explicitly); having a type code would have the same effect, but having the creator wouldn't help at all.
MacOS and Windows are designed such that you tend to use the same program to deal with a given file, no matter what you're doing with it. If you have a JPEG you made with the GIMP, you'll view it in the GIMP. If you're going to compile a source file, you edit it in the compile's IDE, and you view it in the IDE. *nix is designed such that you use different programs for different operations (edit, view, compile, render, etc), and use the same program for a given operation for a number of different file types (C, HTML, English text, etc).
Of course, Windows gets the worst of both worlds-- you have monolithic applications which do everything to a given program, but you don't have the creator metadata, so it picks a program badly.
I think it would be nice to have file types under Linux; currently, there are a number of partial solutions: emacs has an "Edit this file in -mode" directive, most binary types have magic numbers (e.g., GIF89a, , ^?ELF, JFIF, etc), and some programs look at some extensions. Of course, there would have to be a number of different types associated with a given file (Java source, UTF-8, plain text, etc), and it would have to be simple to specify the type of a new file when you create it, which is currently done partially by naming it in accordance with a convention and partially by putting in data which looks like a certain type, both of which you'd want to do anyway.
The difference is that what the machine does is what your mother tells it to do, not what the file tells it to do. If she downloads a file that she thinks is text and tries to read it, and it's a binary, she gets a screenful of garbage. If she's intentionally running programs, that's one thing; if she's running a program when she means to be just looking at something, that's a problem.
Windows has all of the problems that MacOS does, except worse, because it's badly implemented.
Actually, it's no big deal linking against a weirdly-named library; you just have to specify the exact filename instead of -lfoo. The shortcut
isn't about the extension, either: you'll have just as much of a problem with files that don't start with "lib". The linker doesn't actually care at all what the filename is; it's just that it provides a quick way of writing some filenames.
The compiler, is, in fact, an exception. Ideally, perhaps, it would try to identify the file type by looking at the file; in any case, you can tell it what you mean if it isn't guessing correctly from the name.
Linux has traditionally not bothered very much with file type. The user generally knows what to do with the file, and does so. What look like extensions are actually just generically part of the filename; there are conventions for them, but they are no more strict than the conventions for filenames in general (Makefile is probably a makefile, README is plain text, foo.c is C source, etc.).
An important thing to realize is that file type, like, for instance, size, can be determined from looking at the data. In fact, many programs look at data files and determine the file format from the data; "file" does a pretty good job of detecting non-human-readable formats, even without knowing any information at all about the file type.
Where this all breaks down, of course, is when the user wants to omit the program name. On a Mac, you normally double-click on a data file to open it (and hope to get a program that does what you want). On *nix, you traditionally have to specify the program-- and much of the time, you select a different program depending on the desired result: for foo.c, I could use emacs, or gcc, or I might want gcc -M (get dependencies), or even wc (to see how big it is), not to mention less or grep or etags.
I think part of the Mac fascination with file type is due to the monolithic program structure; you find the file, and then you open a single program that does to it anything that you will ever do to it. In this model, there is a right program, and which program is right is based on file type. Windows clearly suffers greatly from having this model but not having a more reliable fashion of determining file type than Linux.
Incidentally, has anyone else noticed that the MacOS scheme is equivalent to having 4 character extensions which aren't displayed, with the corresponding problem of having malicious executables named README.txt (or even README)?
Having the error messages go somewhere use is actually worthwhile, although there are plenty of programs that will either not tell you anything useful if they die or will send so much output that they'd tie up an xterm if you let them.
Most GUI programs are executable programs, so you can run them from a shell prompt; some of these make a lot of sense, because they take arguments which you don't keep the same (e.g., xfig ) and care about the directory you run them from. Others aren't really useful to run from the command line, because they don't take these kinds of arguments (e.g., xfontsel). For the latter kind, they might as well not be accessible from the command line.
I think the main thing is that distros assume you want to run services. For a desktop box, you probably don't want to run any, except maybe identd, which can be fake anyway. It's really easy to administer a Linux box; the kernel rarely has remotely exploitable bugs. What's hard is administering all of those random programs that tend to get installed.
You're right in thinking there needs to be a standard installation method. The technical details of it don't matter at all to the average end user, so long as it can be automated. Autoconf, aside from being a huge complex and hard-to-debug hack, is, in some ways, the best, though. If you had a program which displayed four bars, one for "tar -zxvf $1", one for "./configure", one for "make", and one for "make install", the user wouldn't know the difference between a binary installation and a source installation, except that the source one would be a bit slower and wouldn't mind having different builds of the libraries.
An uninstaller would be really nice. It would probably actually solve many problems if "install" were the only program able to put things in/usr/local (aside from in directories owned by apps, which would, as directories, be subject to this policy), and if "install" kept track of what program put what where.
Very good point about the GUI applications. If you can't *use* the application with a command line, there's no reason you should be able to *run* it that way.
It is an interesting exercise, if you have time, to build a Linux system exclusively from the original sources. It really makes you aware of the programs you actually want when you have to go get everything individually, and you realize at some point just how much stuff you don't need.
Re:My problems with this essay
on
Mob Software
·
· Score: 2
He's talking about a situation where each person knows the behavior of each other person, but there aren't any overall rules at all, or at least, none that were explicitly designed. Protocols are actually relatively local behavior.
It's really the other way around with routing. Nodes don't know the local behavior at other nodes, but do know the overall rules, which are explicitly designed.
IBM will ditch AIX in favor of Linux if they think Linux is better. Well, I should hope so. Since they aren't trying to fund their company with the OS, but just want it to take advatage of their expensive hardware, it makes sense that they'd want to provide their customers with the best OS for the hardware. If that means they don't have to work on AIX any more, so much the better.
They'd probably say the same about BSD if they thought it might get that good on IBM hardware.
Re:My problems with this essay
on
Mob Software
·
· Score: 2
People can work on internet infrastructure because they can treat all of the other devices as following the same set of rules with variation in the details. Everything is constructed such that the large-scale behavior is obvious from the rules that all of the devices have agreed to follow.
The Mob Software idea would have packets routed somewhat randomly at each router, with that router deciding, without relying on system-wide uniformity, where to send the data next. It's possible that this would work, but it would certainly lead to a much greater variation in latencies and dropped packets.
I'm glad to see that the things that were confusing my HTML parser last night have mostly been fixed already. Now I'll have to find a different source for difficult HTML...
My problems with this essay
on
Mob Software
·
· Score: 5, Insightful
In addition to the stuff we all know about open source, there's a good point in here about the benefits of the quick-and-dirty approach. This idea is that too much design leads to unimplementable projects which are optimized for situations that don't actually arise; it is better to do only a little design and then implement something, so that you can find out what the implementation issues actually are.
It also talks about large systems having emergent properties. All of the examples come from nature, not computer science. To a large extent, I think that this is a mistake. It might be a good idea if you can stand a lot of unpredictability and have to deal with very messy input (like in the physical world), but seems mostly to be exemplified by Windows DLLs: you never know what will affect what, and you can't necessarily repeat something, because the conditions will be different.
I think that modularity is a much better method. This reduces the sizes of the parts that anyone has to understand: the linux kernel is pretty big, but is manageable, at least when ignoring all of the specific drivers (which essentially are constrained by simple interfaces); all of the parts of a linux system, if they were not separated out, would be totally unmanageable. If these parts are constrained, it is possible to understand.
A somewhat methodical approach is far superior to an evolutionary approach, where you essentially change things at random and see what works. While too much attention to getting things perfect as written leads to shortsightedness, not understanding the code you're writing makes for a totally unsupportable program.
Skylarov was arrested because Adobe was pissed off at him. Since he still hasn't actually been charged with anything, we don't know what he did that actually caused him to be arrested.
As pointed out by recent analysis, while the consumer has a right to make backups, there isn't an exception permitting anyone to make software for that purpose.
But there are plenty of other problems in the case, such as jurisdiction and whether his software actually does anything non-trivial. He's also not been charged yet, so it's still unknown what, if anything, the government will think will stand up in court.
Anyway, this is all quite different from the whole Felton thing, which was my point-- regardless of whether the DMCA really applies to anything, it clearly doesn't apply to what Felton's been doing.
Skylarov broke a deployed standard, whereas Felton broke a proposed standard. Considering that, when he announced that he'd broken it, there was nothing actually copyprotected with SDMI, his method could hardly be used to circumvent copyprotection; furthermore, as it was already broken, it wouldn't be considered an effective copyprotection method if it were now used to encode something.
Just in case it works, try "CTRL-ALT-KEY_PAD_PLUS". That will switch between the currently configured resolutions, if there are more than one. The resolutions (and many other things related to hardware and graphics) are configured in/etc/X11/XF86Config. There is some documentation floating around on how to write your own video modes (getting a little bit more resolution, getting the image to line up nicely on your monitor, etc), but that's not terribly necessary with new monitors. Recent XFree86 also seems to know internally about a number of resolutions.
Note that changing resolution while running only changes how much appears on the screen-- the server will scroll the screen when you move the mouse to the edge so that you can get to the whole thing. The total size of the screen is set by the largest video mode listed for the depth (== bits/pixel), and can only be changed by editing the config file and restarting X.
If you want to change the color depth, either start X with the -depth <n> option or change the DefaultDepth parameter in the Screen section (where the resolutions are).
This information is from a number of different versions of XFree86, so not all of it will be right for your particular configuration. If all else fails, read the XFree86 man page (man XFree86) and possibly some of the other documentation it refers to.
As a more general point, there's a lot of good documentation for Linux stuff. The main problem is that it takes a certain amount of sophistication to know which thing you're dealing with, so you can read the applicable documentation. E.g., resolution is determined by XFree86, but background color/pattern is done by xsetroot, which may be called from a number of places, and what happens when you click on the background depends on your window manager.
It might be possible to make a program that, given a sircam-infected file, would send something to the originator of the message. It could send a message with an attachment that looked for sircam, and, if it found it, removed it and installed the program. That way, it would take a sircam-infected machine and make it respond to future attacks by spreading to the originating machine but do nothing to anyone else.
The message could even say that was what it was doing.
"My advise is to run this script to remove the virus and to pass the information on to other people"
This wouldn't really be a virus at all: the people receive it in response to a request for advice and it is something you actually think they should be running. It doesn't try to infect other machines, except by advising their users to use it; no more illegal than Norton responding to a download request with a program.
While you're at it, why not set up your server to document that it does that? E.g.
Go <a href="default.ida">here</a> to check your server for the Code Red worm and remove it if found.
Unlike an actual anti-security-hole virus, in this situation you are providing a legitimate and documented response to an actual request. If you're not scanning other machines unless they actually ask (either by following the link or by attacking you), it's not really any more unethical than, say, active FTP (if you send this message, I will open a connection back to you and send some data over it). It is no more using the other person's machine than, say, slashdot forcing my machine to render an HTML document or an FTP server forcing my machine to store the document I download.
The AC3 format isn't sold to anyone. Content encoded in the AC3 format is sold to consumers, who can do with it what they want, provided that they don't independantly break any laws with it (you're not allowed to murder someone with a DVD, e.g.). You also can't use someone's patented method to decode the content just because you own the content.
The customer may have no right to use something they've purchased because they don't know any way to use it other than the patented method. If they can come up with a way to decode it without violating Dolby's patents, they are free to. If they have a license to use Dolby's decoding method (by way of having a licensed player), they are free to use that.
The important point here is that it's not the "Disney still owns your DVDs" idea in this case, but the "Dolby owns the usual method for decoding DVDs" idea. Dolby doesn't care about the ownership of the content.
This isn't all that similar to the DVD problems, or DMCA problems. This is much like the GIF problems, except that Dolby's patents are probably valid and their behvior is honest.
You can patent encoding and decoding methods for a non-trivial format. You can then license the methods to people who want to use the format. Then people who want to encode or decode the format (using the standard methods) have to pay you for the privilege or wait until your patent expires.
A cleanroom implementation is still in violation of the patents if it uses the same methods, because the point of patents is that there be no reason to reinvent something that someone has already invented, unless you come up with a better method.
The issues with GIF were that the patent holder didn't actually apply for a patent within the required time period after publishing it, published it without a "patent pending" warning (which essentially mean it's prior art), and did not inform the violator of the patent until the method had been incorporated into a 3rd party standard. These don't apply here: Dolby made the standard themselves and never pretended it was not patent-encumbered.
Of course, Dolby may well be willing to license the patents to FreeBSD (or to the ac3dec people) so long as the license on the software prevents commercial use. If they didn't bother the FreeBSD people, Sony could make a FreeBSD-based player that just used ac3dec and thus avoid needing a license for Dolby's technology. Since Dolby's business is figuring out good ways to encode things, they need to be able to make money at it. On the other hand, they might not mind having their technology used for free in places where it would simply not be used if payment was required; they don't lose any income they'd have, and they might gain income on the encoding side.
Considering how many companies are running their windows fileservers on linux (possibly without the management knowing), it's quite possible that MS has already lost control of the filesharing protocol to the point that they can't really extend it now. If they'd stuck something with a patent in originally, they might have a chance, but if the deal is that, in order to talk to standard XP clients (or servers?) you need to use MS stuff, people are likely to just use 3rd party stuff because their existing infrastructure requires the old version.
Aside from the issue of whether the US has jurisdiction relevant to his DMCA-related actions, it's still not clear whether the DMCA could be applied to this situation without applying just as well to essentially anything.
After all, reading a "copy-protected" eBook involves three steps: XOR each byte with 102, a substitution cipher simpler than your average magazine puzzle; LZW decompression, a method invented in the 70s and widely used since; and reading a PDF, a very recent and relatively difficult technique. Of these, the most technologically advanced is the step that his software doesn't do, and Adobe's own software without copy protection checks does do.
Does his software assist in evasion of copy protection? Sure. Do WinZip, Acrobat, and Windows? Sure. Network drivers, memory controllers, and so forth? Quite important, in fact. The fact is that any use of a copy protected item is likely to involve almost exclusively the technology that is needed to defeat the copy protection: once you get access to it once to use it as licensed, you'll need only very simple technoloy, if any, to distribute it.
I'd really like to see DMCA prosecutions of the government for Echelon (can copy copyrighted documents from users' screens) and the-software-formerly-known-as-Carnevore (can copy email). Even if they aren't used for piracy or even intended for piracy, they can circumvent relatively effective copy protection (not giving the document to anyone else).
But the hardware manufactures aren't the ones collecting the patent royalties, they're the ones paying them. Manufactures can make money off of anything they can sell. I wouldn't be surprised if the various MP3 player hardware started supporting Ogg, just because it's royalty-free and the decoder source is available. It's not a big effort to include support, and customers might want it, so it's a good feature to have.
The people who can't make money off of a free codec are the people who make the codec; in this case, the Ogg team.
All of these infected hosts ramping up with attacks on other servers and sending gratuitously inefficient traffic takes up a lot of bandwidth... but not compared to the bandwidth the 'net has these days. 200,000 hosts (high point last month) sending lots of tiny packets is probably less traffic than slashdot readers viewing videos from articles.
Having those hosts sending packets that break routers and printers is more of an issue, but those have generally been fixed last month, because they couldn't very well just have been left off until the thing went dormant.
The internet's infrastructure has grown significantly in capacity (although not necessarily in smart physical placement) since it was easy to DOS the whole thing with a worm (or with the start of the school year, for that matter), and it's happened in response to actual use of the bandwidth. All of the clients generating web requests easily overcome the traffic all of the servers running IIS could possibly generate, not to mention the traffic that goes over any large, bulldozer-accessible cable.
Considering the nature of this thing, when it went dormant, probably most people just forgot about it. It doesn't really need to spread again, since it's still out there all over the place.
This is not really all that different from an average virus-- it spreads for a while, activates, causing a lot of damage and panic and such, people panic for a while, it deactivates and spreads some more.
The people who are all worried about it coming back repeatedly should be at most disappointed that it doesn't just kill itself after a month. But there's no reason they should expect it to.
In fact, this is still less of a problem than an old-style virus: it order to stop those, you had to get a clever program to catch and disable this code. With Code Red you merely have to patch or replace IIS and it stops being an issue.
Slashdot Mirror
My point was that, under Linux, "creator" isn't very useful. Most of my files are created by "emacs" (or "cp" or "sed" or something, when I copy a template), but what I normally do with them is compile them. The filename extension only matters a bit (saves having to tell the compiler what language it is explicitly); having a type code would have the same effect, but having the creator wouldn't help at all.
MacOS and Windows are designed such that you tend to use the same program to deal with a given file, no matter what you're doing with it. If you have a JPEG you made with the GIMP, you'll view it in the GIMP. If you're going to compile a source file, you edit it in the compile's IDE, and you view it in the IDE. *nix is designed such that you use different programs for different operations (edit, view, compile, render, etc), and use the same program for a given operation for a number of different file types (C, HTML, English text, etc).
Of course, Windows gets the worst of both worlds-- you have monolithic applications which do everything to a given program, but you don't have the creator metadata, so it picks a program badly.
I think it would be nice to have file types under Linux; currently, there are a number of partial solutions: emacs has an "Edit this file in -mode" directive, most binary types have magic numbers (e.g., GIF89a, , ^?ELF, JFIF, etc), and some programs look at some extensions. Of course, there would have to be a number of different types associated with a given file (Java source, UTF-8, plain text, etc), and it would have to be simple to specify the type of a new file when you create it, which is currently done partially by naming it in accordance with a convention and partially by putting in data which looks like a certain type, both of which you'd want to do anyway.
The difference is that what the machine does is what your mother tells it to do, not what the file tells it to do. If she downloads a file that she thinks is text and tries to read it, and it's a binary, she gets a screenful of garbage. If she's intentionally running programs, that's one thing; if she's running a program when she means to be just looking at something, that's a problem.
Windows has all of the problems that MacOS does, except worse, because it's badly implemented.
Actually, it's no big deal linking against a weirdly-named library; you just have to specify the exact filename instead of -lfoo. The shortcut
isn't about the extension, either: you'll have just as much of a problem with files that don't start with "lib". The linker doesn't actually care at all what the filename is; it's just that it provides a quick way of writing some filenames.
The compiler, is, in fact, an exception. Ideally, perhaps, it would try to identify the file type by looking at the file; in any case, you can tell it what you mean if it isn't guessing correctly from the name.
Linux has traditionally not bothered very much with file type. The user generally knows what to do with the file, and does so. What look like extensions are actually just generically part of the filename; there are conventions for them, but they are no more strict than the conventions for filenames in general (Makefile is probably a makefile, README is plain text, foo.c is C source, etc.).
An important thing to realize is that file type, like, for instance, size, can be determined from looking at the data. In fact, many programs look at data files and determine the file format from the data; "file" does a pretty good job of detecting non-human-readable formats, even without knowing any information at all about the file type.
Where this all breaks down, of course, is when the user wants to omit the program name. On a Mac, you normally double-click on a data file to open it (and hope to get a program that does what you want). On *nix, you traditionally have to specify the program-- and much of the time, you select a different program depending on the desired result: for foo.c, I could use emacs, or gcc, or I might want gcc -M (get dependencies), or even wc (to see how big it is), not to mention less or grep or etags.
I think part of the Mac fascination with file type is due to the monolithic program structure; you find the file, and then you open a single program that does to it anything that you will ever do to it. In this model, there is a right program, and which program is right is based on file type. Windows clearly suffers greatly from having this model but not having a more reliable fashion of determining file type than Linux.
Incidentally, has anyone else noticed that the MacOS scheme is equivalent to having 4 character extensions which aren't displayed, with the corresponding problem of having malicious executables named README.txt (or even README)?
Having the error messages go somewhere use is actually worthwhile, although there are plenty of programs that will either not tell you anything useful if they die or will send so much output that they'd tie up an xterm if you let them.
Most GUI programs are executable programs, so you can run them from a shell prompt; some of these make a lot of sense, because they take arguments which you don't keep the same (e.g., xfig ) and care about the directory you run them from. Others aren't really useful to run from the command line, because they don't take these kinds of arguments (e.g., xfontsel). For the latter kind, they might as well not be accessible from the command line.
I think the main thing is that distros assume you want to run services. For a desktop box, you probably don't want to run any, except maybe identd, which can be fake anyway. It's really easy to administer a Linux box; the kernel rarely has remotely exploitable bugs. What's hard is administering all of those random programs that tend to get installed.
/usr/local (aside from in directories owned by apps, which would, as directories, be subject to this policy), and if "install" kept track of what program put what where.
You're right in thinking there needs to be a standard installation method. The technical details of it don't matter at all to the average end user, so long as it can be automated. Autoconf, aside from being a huge complex and hard-to-debug hack, is, in some ways, the best, though. If you had a program which displayed four bars, one for "tar -zxvf $1", one for "./configure", one for "make", and one for "make install", the user wouldn't know the difference between a binary installation and a source installation, except that the source one would be a bit slower and wouldn't mind having different builds of the libraries.
An uninstaller would be really nice. It would probably actually solve many problems if "install" were the only program able to put things in
Very good point about the GUI applications. If you can't *use* the application with a command line, there's no reason you should be able to *run* it that way.
It is an interesting exercise, if you have time, to build a Linux system exclusively from the original sources. It really makes you aware of the programs you actually want when you have to go get everything individually, and you realize at some point just how much stuff you don't need.
He's talking about a situation where each person knows the behavior of each other person, but there aren't any overall rules at all, or at least, none that were explicitly designed. Protocols are actually relatively local behavior.
It's really the other way around with routing. Nodes don't know the local behavior at other nodes, but do know the overall rules, which are explicitly designed.
IBM will ditch AIX in favor of Linux if they think Linux is better. Well, I should hope so. Since they aren't trying to fund their company with the OS, but just want it to take advatage of their expensive hardware, it makes sense that they'd want to provide their customers with the best OS for the hardware. If that means they don't have to work on AIX any more, so much the better.
They'd probably say the same about BSD if they thought it might get that good on IBM hardware.
People can work on internet infrastructure because they can treat all of the other devices as following the same set of rules with variation in the details. Everything is constructed such that the large-scale behavior is obvious from the rules that all of the devices have agreed to follow.
The Mob Software idea would have packets routed somewhat randomly at each router, with that router deciding, without relying on system-wide uniformity, where to send the data next. It's possible that this would work, but it would certainly lead to a much greater variation in latencies and dropped packets.
I'm glad to see that the things that were confusing my HTML parser last night have mostly been fixed already. Now I'll have to find a different source for difficult HTML...
In addition to the stuff we all know about open source, there's a good point in here about the benefits of the quick-and-dirty approach. This idea is that too much design leads to unimplementable projects which are optimized for situations that don't actually arise; it is better to do only a little design and then implement something, so that you can find out what the implementation issues actually are.
It also talks about large systems having emergent properties. All of the examples come from nature, not computer science. To a large extent, I think that this is a mistake. It might be a good idea if you can stand a lot of unpredictability and have to deal with very messy input (like in the physical world), but seems mostly to be exemplified by Windows DLLs: you never know what will affect what, and you can't necessarily repeat something, because the conditions will be different.
I think that modularity is a much better method. This reduces the sizes of the parts that anyone has to understand: the linux kernel is pretty big, but is manageable, at least when ignoring all of the specific drivers (which essentially are constrained by simple interfaces); all of the parts of a linux system, if they were not separated out, would be totally unmanageable. If these parts are constrained, it is possible to understand.
A somewhat methodical approach is far superior to an evolutionary approach, where you essentially change things at random and see what works. While too much attention to getting things perfect as written leads to shortsightedness, not understanding the code you're writing makes for a totally unsupportable program.
Skylarov was arrested because Adobe was pissed off at him. Since he still hasn't actually been charged with anything, we don't know what he did that actually caused him to be arrested.
As pointed out by recent analysis, while the consumer has a right to make backups, there isn't an exception permitting anyone to make software for that purpose.
But there are plenty of other problems in the case, such as jurisdiction and whether his software actually does anything non-trivial. He's also not been charged yet, so it's still unknown what, if anything, the government will think will stand up in court.
Anyway, this is all quite different from the whole Felton thing, which was my point-- regardless of whether the DMCA really applies to anything, it clearly doesn't apply to what Felton's been doing.
Skylarov broke a deployed standard, whereas Felton broke a proposed standard. Considering that, when he announced that he'd broken it, there was nothing actually copyprotected with SDMI, his method could hardly be used to circumvent copyprotection; furthermore, as it was already broken, it wouldn't be considered an effective copyprotection method if it were now used to encode something.
Just in case it works, try "CTRL-ALT-KEY_PAD_PLUS". That will switch between the currently configured resolutions, if there are more than one. The resolutions (and many other things related to hardware and graphics) are configured in /etc/X11/XF86Config. There is some documentation floating around on how to write your own video modes (getting a little bit more resolution, getting the image to line up nicely on your monitor, etc), but that's not terribly necessary with new monitors. Recent XFree86 also seems to know internally about a number of resolutions.
Note that changing resolution while running only changes how much appears on the screen-- the server will scroll the screen when you move the mouse to the edge so that you can get to the whole thing. The total size of the screen is set by the largest video mode listed for the depth (== bits/pixel), and can only be changed by editing the config file and restarting X.
If you want to change the color depth, either start X with the -depth <n> option or change the DefaultDepth parameter in the Screen section (where the resolutions are).
This information is from a number of different versions of XFree86, so not all of it will be right for your particular configuration. If all else fails, read the XFree86 man page (man XFree86) and possibly some of the other documentation it refers to.
As a more general point, there's a lot of good documentation for Linux stuff. The main problem is that it takes a certain amount of sophistication to know which thing you're dealing with, so you can read the applicable documentation. E.g., resolution is determined by XFree86, but background color/pattern is done by xsetroot, which may be called from a number of places, and what happens when you click on the background depends on your window manager.
Server: Apache/1.3.14 (Unix) PHP/4.0.3 AuthMySQL/2.20
Getting MySQL to fit on a TRS-80 is even more impressive, I think.
It might be possible to make a program that, given a sircam-infected file, would send something to the originator of the message. It could send a message with an attachment that looked for sircam, and, if it found it, removed it and installed the program. That way, it would take a sircam-infected machine and make it respond to future attacks by spreading to the originating machine but do nothing to anyone else.
The message could even say that was what it was doing.
"My advise is to run this script to remove the virus and to pass the information on to other people"
This wouldn't really be a virus at all: the people receive it in response to a request for advice and it is something you actually think they should be running. It doesn't try to infect other machines, except by advising their users to use it; no more illegal than Norton responding to a download request with a program.
While you're at it, why not set up your server to document that it does that? E.g.
Go <a href="default.ida">here</a> to check your server for the Code Red worm and remove it if found.
Unlike an actual anti-security-hole virus, in this situation you are providing a legitimate and documented response to an actual request. If you're not scanning other machines unless they actually ask (either by following the link or by attacking you), it's not really any more unethical than, say, active FTP (if you send this message, I will open a connection back to you and send some data over it). It is no more using the other person's machine than, say, slashdot forcing my machine to render an HTML document or an FTP server forcing my machine to store the document I download.
The AC3 format isn't sold to anyone. Content encoded in the AC3 format is sold to consumers, who can do with it what they want, provided that they don't independantly break any laws with it (you're not allowed to murder someone with a DVD, e.g.). You also can't use someone's patented method to decode the content just because you own the content.
The customer may have no right to use something they've purchased because they don't know any way to use it other than the patented method. If they can come up with a way to decode it without violating Dolby's patents, they are free to. If they have a license to use Dolby's decoding method (by way of having a licensed player), they are free to use that.
The important point here is that it's not the "Disney still owns your DVDs" idea in this case, but the "Dolby owns the usual method for decoding DVDs" idea. Dolby doesn't care about the ownership of the content.
This isn't all that similar to the DVD problems, or DMCA problems. This is much like the GIF problems, except that Dolby's patents are probably valid and their behvior is honest.
You can patent encoding and decoding methods for a non-trivial format. You can then license the methods to people who want to use the format. Then people who want to encode or decode the format (using the standard methods) have to pay you for the privilege or wait until your patent expires.
A cleanroom implementation is still in violation of the patents if it uses the same methods, because the point of patents is that there be no reason to reinvent something that someone has already invented, unless you come up with a better method.
The issues with GIF were that the patent holder didn't actually apply for a patent within the required time period after publishing it, published it without a "patent pending" warning (which essentially mean it's prior art), and did not inform the violator of the patent until the method had been incorporated into a 3rd party standard. These don't apply here: Dolby made the standard themselves and never pretended it was not patent-encumbered.
Of course, Dolby may well be willing to license the patents to FreeBSD (or to the ac3dec people) so long as the license on the software prevents commercial use. If they didn't bother the FreeBSD people, Sony could make a FreeBSD-based player that just used ac3dec and thus avoid needing a license for Dolby's technology. Since Dolby's business is figuring out good ways to encode things, they need to be able to make money at it. On the other hand, they might not mind having their technology used for free in places where it would simply not be used if payment was required; they don't lose any income they'd have, and they might gain income on the encoding side.
Considering how many companies are running their windows fileservers on linux (possibly without the management knowing), it's quite possible that MS has already lost control of the filesharing protocol to the point that they can't really extend it now. If they'd stuck something with a patent in originally, they might have a chance, but if the deal is that, in order to talk to standard XP clients (or servers?) you need to use MS stuff, people are likely to just use 3rd party stuff because their existing infrastructure requires the old version.
Aside from the issue of whether the US has jurisdiction relevant to his DMCA-related actions, it's still not clear whether the DMCA could be applied to this situation without applying just as well to essentially anything.
After all, reading a "copy-protected" eBook involves three steps: XOR each byte with 102, a substitution cipher simpler than your average magazine puzzle; LZW decompression, a method invented in the 70s and widely used since; and reading a PDF, a very recent and relatively difficult technique. Of these, the most technologically advanced is the step that his software doesn't do, and Adobe's own software without copy protection checks does do.
Does his software assist in evasion of copy protection? Sure. Do WinZip, Acrobat, and Windows? Sure. Network drivers, memory controllers, and so forth? Quite important, in fact. The fact is that any use of a copy protected item is likely to involve almost exclusively the technology that is needed to defeat the copy protection: once you get access to it once to use it as licensed, you'll need only very simple technoloy, if any, to distribute it.
I'd really like to see DMCA prosecutions of the government for Echelon (can copy copyrighted documents from users' screens) and the-software-formerly-known-as-Carnevore (can copy email). Even if they aren't used for piracy or even intended for piracy, they can circumvent relatively effective copy protection (not giving the document to anyone else).
But the hardware manufactures aren't the ones collecting the patent royalties, they're the ones paying them. Manufactures can make money off of anything they can sell. I wouldn't be surprised if the various MP3 player hardware started supporting Ogg, just because it's royalty-free and the decoder source is available. It's not a big effort to include support, and customers might want it, so it's a good feature to have.
The people who can't make money off of a free codec are the people who make the codec; in this case, the Ogg team.
All of these infected hosts ramping up with attacks on other servers and sending gratuitously inefficient traffic takes up a lot of bandwidth... but not compared to the bandwidth the 'net has these days. 200,000 hosts (high point last month) sending lots of tiny packets is probably less traffic than slashdot readers viewing videos from articles.
Having those hosts sending packets that break routers and printers is more of an issue, but those have generally been fixed last month, because they couldn't very well just have been left off until the thing went dormant.
The internet's infrastructure has grown significantly in capacity (although not necessarily in smart physical placement) since it was easy to DOS the whole thing with a worm (or with the start of the school year, for that matter), and it's happened in response to actual use of the bandwidth. All of the clients generating web requests easily overcome the traffic all of the servers running IIS could possibly generate, not to mention the traffic that goes over any large, bulldozer-accessible cable.
Considering the nature of this thing, when it went dormant, probably most people just forgot about it. It doesn't really need to spread again, since it's still out there all over the place.
This is not really all that different from an average virus-- it spreads for a while, activates, causing a lot of damage and panic and such, people panic for a while, it deactivates and spreads some more.
The people who are all worried about it coming back repeatedly should be at most disappointed that it doesn't just kill itself after a month. But there's no reason they should expect it to.
In fact, this is still less of a problem than an old-style virus: it order to stop those, you had to get a clever program to catch and disable this code. With Code Red you merely have to patch or replace IIS and it stops being an issue.