I see two reasons that Linux gurus don't point to the GUI tools: most of us haven't needed a tool for the given task since before the GUI tools were written. Once you configure something on your system, it tends to stay configured. If you ask someone for help getting your sound card working, and their sound card has worked since before there were tools, they probably won't know about the tools.
Also, many Linux gurus have entirely abandoned Windows. They don't know that a Linux feature is like a Windows feature that the user understands, because that feature wasn't in the last version of Windows they used much. Furthermore, they probably ignored the Windows-like features, because they were unintuitive and unfamiliar. I, for instance, don't expect a directory window to switch directories if it has icons in it, because 3.1 and Mac popped up new windows for different directories; the other model I expect is a shell, where programs I run from a directory generally stay in that window. A setup where I don't get a new window for a new directory, but I do get a new window if I run a program, is quite unexpected to me, and I'd be unlikely to tell a user to use a setup I had a hard time remembering how to use...
The essential correct idea of the article is this: the people who know how to explain Linux to new people are the people who learned it themselves recently. They have a similar background and expectations, they find similar interfaces sensible, and they've needed tools since the latest tools because available.
If and when the recent converts are unable to do something, an old guru may be helpful. A guru may also have good advice for customizing a system once the user has some experience (e.g., "Put 'update -Pd co -P' in ~/.cvsrc, 'alias cvs=cvs -q' in your.environment, and you won't have that problem any more). But the stuff a guru can tell you will only make sense once you've run into a problem and have the shared context of wanting the system to do something better.
I don't need to log in to my home linux system. It's set up without any services and so it doesn't have any user passwords (if someone manages to get a username prompt, they've almost certainly broken in anyway). I do need to unlock my ssh identity file, of course, but that's normal. Users exist to allow customization and home directories, not security.
Autodetection of hardware is a sensible feature for geeks as much as anyone else; if you're in to turning random old machines into linux boxes, you probably don't know what the video chipset with all the printing worn off is.
A single click of the mouse is not much simpler than apt-get. In fact, if you're installing something, it's probably simpler to know what the thing is called than to have an icon for it. Even tar zxvf $1-*.tar.gz && cd $1-* &&./configure && make && make install isn't all that difficult, if someone's given you a slip of paper or a shell script to do it.
There's no need to have only one GUI. What's needed is to have the user's GUI of choice available with any distribution. Ideally, a user would be able to fetch their customization info from somewhere, too, and then it wouldn't even be as confusing as sitting down at someone else's windows box (not to mention switching to CE or ME or NT or XP or... how many interfaces did you say?).
The adage doesn't really hold. A good tool can be used by an idiot and used very well by an expert. Looking around my desk, I see a telephone, a box of tissues, a coffee mug, a book, a pair of headphones, a paper bag, etc.; they're all really easy to use and pretty idiot-usable, and every geek I know uses them. Linux should be similar: it works well without fiddling around inside. You can take the cover off and rewire it to make it do other things, but you don't have to.
I mean, I *could* configure things with echo, sed, grep, and cat, and I actually do on occasion, but usually I use a text editor if that makes it easier to get the result I want. If I had a special config tool that worked well, I'd use that instead, so long as it didn't needlessly destroy my hand-tuned files and left files that I could hand-tune if I found I needed to do something not supported. Being a real power user isn't about always using the more powerful tools; it's about using the tool which will have the effect you want in the shortest time.
Yeah, it's just that what makes an iMac an iMac is it's weird shape, and so a non-curved one just wouldn't be the same. They'd have to be very clever to keep product recognition while using a flat screen and actually getting some advantage out of not having a CRT in the box.
Re:Managers Like Names...
on
Future Of IDS
·
· Score: 4, Insightful
If budget isn't a concern, why not install Snort in addition to something else? That way you'll know when to blame company Y and what to blame them for missing. An IDS isn't like a fileserver where you can only really use one or another.
They're going to have to redesign the whole thing if they want flat screens, because the box isn't flat on the front. Either than, or they'll have to make curved-panel displays.
Of course, an iMac box would look really weird without the CRT, because it would be mostly empty, and they probably can't just make the box smaller, because they need vent space. So they'll probably have to come up with a special new shape.
In order to install the system without being present, the installer would have to not be interactive. If you want any configurability, you need to be able to script it (i.e., burn the configuration options on the CD beforehand). But in that case, you really don't need an installer, which primarily wraps a bunch of tools in a UI.
The issue is that an installer wraps a bunch of tools (which generally have UIs) in a special UI that only works if you mostly wipe out your system. If you want to then change anything that you set up, you have to use totally different programs (unless you reinstall). If you like the installer, it sucks to maintain the system; if you don't like the installer, it sucks to install the system. In any case, there's no reason for an installer which does something other than run fdisk, the system config tool, and the package manager. At most, you'd want to have it delay all the slow stuff until after you've done all the configuration.
If the tools include the ability to set up a Linux installation along with a Debian-on-Windows installation, you could skip the installer entirely.
That is, people install Debian under Windows to get the Unix tools that the developers downstairs keep telling them about. After a while, they find they're using mostly Debian programs. They repartition (or stick in, or clean off, another hard drive), and then run the Debian tools to install Linux versions of what they have Windows versions of. The system can thus be installed very much the way the user wants, because the user has a functioning Debian system to point it at.
I've always felt that the idea of a Linux installer is broken: it hides the use of a number of tools that you're likely to know (or need to know eventually) behind an interface that is just different. It would be much better to give direct access to the real tools and provide guidance as to what you're doing with them and what order to do things. If the underlying tools are insufficiently friendly, they should be improved, not wrapped in special-purpose code.
The main justification for an installer, rather than good maintenence tools, is that you can use an installer without having an existing system. But if you can use the Windows installation on a machine as a system under which to run the maintenence tools for a new Linux installation, there's no need for an installer.
It seems like the US Lineage players would tend to be mainly mercenaries, either for money, for experience, or because they think their employer is doing something good.
A separate Lineage game in the US probably wouldn't work very well-- people want to play the "main character", or one of a band of adventurers, while the world must be made mostly of minor characters who are important in groups. On the other hand, if the world has 2 million people playing people in groups, the addition of a few hundred thousand freelance people would probably work fine for game mechanics.
It would probably be very interesting to go on quests in a fully-fleshed-out world inhabited by a large number of PCs and NPCs in realistic arrangements. Thinking about LotR, there are a ton of groups of people who clearly ought to be PCs who don't fit the adventurer model, and it would be very interesting to have a MMRPG with people who actually want to play those roles.
I think that, currently, the threat of a lawsuit is basically meaningless. Any particular pair of entities could find something to sue each other over, and could probably win, provided they weren't asking very much. It doesn't cost anything to ignore a letter.
If the RIAA had actually brought charges, that would be different, and Felton could have reasonably sued them over it. But sending scary junk mail is their First Amendment right, like it or not, and, in the eyes of the law, they never said they were a suitable plaintiff for a First Amendment vs DMCA case against Felton.
The separation is good, but the problem is that the courts never sit down and interpret new laws just so that everyone understands them; they wait until someone is accused of violating the laws, and then they interpret them.
Of course, I can't see any clear reason that it would be any different if the courts weren't separated. In the current scheme, Congress just passes anything they feel like, without regard for the constitutionality of the laws. Having a congressional section which could reject any law they deemed unconstitutional would be as good as having the courts do it, and it would presumably be done promptly. Of course, this branch would have to be essentially court-like, chosen for the ability to interpret legal language, but there's no reason it would have to take actual cases to establish precedent.
Right, so you can't sue someone to get a judgement in a case that hasn't been brought against you.
And, as much as you'd like to, you can't actually find out in advance if what you want to do will be judged legal before you do it. You have to wait until you've actually been sued in order to defend yourself.
That makes sense; otherwise, you'd have McDonalds suing everyone who spills coffee on themselves, alledging that the victem knew the coffee was hot.
Of course, it is a flaw in our government that the legislature creates the laws, and the courts interpret them, but the courts only deal with past events, so there's no way to know what a law means until someone is charged under it. It would be kind of nice to be able to say, "I will do this, but only if it's legal", but that's not possible in the US. This is probably because the court system requires motivated people on both sides and a lot of particulars to consider.
Under the assumption that the Linux version would try to monitor the user under their own UID, rather than attempting to get root access, it would probably be an X program which didn't open any windows and just tracked keyboard and mouse events. You could detect it or defeat it by turning on the "Secure Keyboard" feature of your xterm before typing your password-- this causes the xterm to get exclusive control of the keyboard from the X server while it is on. If it beeps instead of turning inverse video, there's something wrong (like you have a different program in that mode). This feature is in the ctrl-left-button menu.
If it was a root-level attack, it would be very difficult to detect, unless you knew what the code looked like, in which case you could scan for it. However, it would have to exploit a root vulnerability, which is non-trivial; vulnerabilities get fixed, and people often look for evidence of anything getting in after they close the vulnerability.
If they distribute this thing virally, it doesn't matter what the scanners do, because any court in the US would throw out the evidence. Plus, everyone would lynch them as cyberterrorists. What it sounds like they might do, though, is distribute it as a trojan: they send it just to the person they have a warrent against, either directly, by way of a cooperating associate, or by forging it as from someone the person expects to get mail from. It uses the same vector as a virus, but it isn't a virus, because it lacks any mechanism to spread, since they are not allowed to collect evidence about other people.
They can't just spread this everywhere, because citizens would look rather unfavorably on the FBI deciding to do billions of dollars of damage to corporate networks with a virus. In addition, if they did something like that, people would clean it up even if the virus scanners didn't. In order for this to be at all feasible, it has to be stealthy and rare, and, in that case, virus scanning companies will probably never see it.
And even then, there would be no reason to run anti-virus software on Linux. Instead of running software to block, detect, and remove individual viruses, just patch the holes they use.
The reason to run anti-virus software is that you regularly try to execute malicious code. The anti-virus software detects when you are trying to run code that is known to be malicious, and stops you. If you're using a Linux box, the right solution is to not run untrusted code; if something people do leads to running untrusted code, whether it is malicious or not, that is a problem, and it will (ideally) get fixed, not papered over.
These companies provide detection and removal services for widely-distributed and automatic attacks. That is to say, it's their job to clean up when someone releases a virus that spreads all over the place. They discover something spreading, and they make an update.
If the FBI is doing their job well, that's not the situation here. The way they've been describing this working is that they set it up to attack the particular person against whom they've obtained a warrent. It doesn't email itself to the target's addressbook, it doesn't attack random IPs, it doesn't try to infect floppies. That would be both illegal (since it could destroy the data of non-targets) and probably invalidate their evidence (since they don't have a warrent to investigate every individual in the US).
So a virus scanner shouldn't catch Magic Lantern, because it's not really a virus, in the sense that they're scanning for. It's an attack tool, which uses the methods often employed by viruses. Virus scanners don't fix security holes; they look for particular malicious and spreading code on your computer and clean it up. They won't stop Magic Lantern, they won't stop someone hijacking your passport account, and they won't stop even script kiddies breaking into your webserver, because their purpose and system design just aren't good for that.
So far I haven't heard of any IDS companies saying they will ignore ML, nor have I heard of any companies saying they won't fix security holes that ML uses. That's what would be significant.
The line seemed okay to me; it sounded like The Tick had picked it up from hearing other people, and had no clue what it meant. Saying it about a villian or some other person would be out of character, but about a coffee machine is different. The Tick is too innocent to understand why this is odd, and probably too innocent to know that it's naughty. At least to me it came across as something he wouldn't say if he knew that it was something he shouldn't say.
The way anti-virus software generally works is that it detects particular programs and patterns. This isn't like fixing a security hole or something, where a number of programs can be stopped with a single fix.
In this case, they'll probably just not write a detector for ML, and it won't get caught. If someone writes something similar to ML, they'll probably just test their detector to make sure it only catches the intended virus and not ML.
McAfee is in the business of stopping particular exploits, not of fixing anything. That's why people keep getting new viruses that aren't significantly different from old viruses.
Of course, ML doesn't seem to be designed to spread all over the net, so McAfee probably wouldn't do anything about it anyway, any more than they do anything about other non-automated security breaches.
You should risk getting burned on the "pre" versions. That's why they're "pre" versions. There's no reason to rush out a "final" version, especially after even a small change. The reason the "pre" versions were there was so that people could do QA on them. The right move would have been to fork 2.5.0 off of pre9, and just leave pre9 around for a bit. This bug would have turned up in a few days, gotten fixed, and then 2.5.0 would get patched, pre10 would come out, that would sit around a bit, and, if the patch is good, it would become final.
Nothing should change between the last release candidate and the final version, except the version number, and the last release candidate should stay a release candidate until the QA has been done. That's why there are final versions.
That explains why pre9 was released with the bug, but not why the final version was released with it. There really needed to be a "release candidate" notice on things that could become final versions and then a QA pass, before something gets blessed as a "final" version.
The advantage with OSS is that you get frequent releases, which enables you to keep up with development and test the upcoming version to see if it works for you. But that doesn't help much when the upcoming version gets changed and then released without testing.
Of course, there is the other advantage: that the person responsible for a bad bug in a final version will actually spend the day after thanksgiving fixing it, so that this sort of accident gets fixed in a day or two.
Just think, the schools could sell $0.9 billion in premium licenses that MS is legally required to keep track of for the holders to businesses having license problems with MS, buy whatever they want, avoid using software which will be out-of-date and totally useless when the students graduate, and save everyone except MS a whole lot of trouble.
Personally, I think the plantiffs should just go for $10b and actually get refunds for the software that MS forced on them. Or settle for (highest price of Windows - $30) for each plantiff. If MS wants to raise prices later or go to a subscription model, they can just keep paying the plantiffs. After all, the issue at hand is MS overpricing their software, so something should be done about it.
All of their examples are of pages that you want, but most pages you see are not actually content. Would you pay a penny for the google search page? A page of amazon search results? The page confirming your credit card info? An extra cent each time you want to preview a submission? A web page is not a unit of content, but a unit of interaction, and it's the content that the users want.
The comparison to books is apt, but their characterization of books is grossly wrong. If you go into a bookstore, you will find that all of the books are free, so long as you only want to browse them. If you want to read them longer, you can get them from a library. Why do people buy books? Because they've determined that they want to have their own copies.
The sensible model would be for sites to have "buy this content" buttons. They'd let you pay whatever you wanted, with a suggestion and a minimum from the site, and the only effect they would have is that that button wouldn't appear for you again. Sites would only have them on pages that they thought were worth paying for (or nobody would click them, and people would get annoyed). You could decide whether you actually liked the page before deciding to click the button.
Consider: each Onion article gets a button next to it. If you enjoy the article, you click the button and pay them a cent. You look up Afganistan in the Brittanica. If it has the information you want, you click the button and pay a dime; if it isn't up to date enough, or is too vague, or is just the same as the other sources you've found, you don't. You read a web comic. If you're just sampling it and you're not interested, you don't pay; if you read it regularly, you click the button each time. You do a google search. Each time it finds a site you wanted, you click the google button (and the site's button); for all the search results that fit the query but weren't quite what you were looking for, you don't pay. You download an MP3 from a band site. If you like it, you pay a couple of cents. If you like it enough to keep it to listen to frequently, you pay a dollar. If it didn't come through correctly, you don't pay anything.
The essentialy idea is that people will pay for things they like, even if they don't have to, and even if they don't get much out of it. Of course, this also requires convenience; I would pay for, say, web comics, but the accounting and the payment cost more, in time doing boring stuff, than it's worth. Nobody paid for shareware because, while the software was worth $15, it wasn't worth a check, a stamp, an envelope, and the time and effort to combine them.
The CIA and such are, in this case, in the position of the vendors: it is their responsibility to fix the vulnerabilities.
The disclosure should be done by people who identify the vulnerablities. If you know where you can cross a border undetected, you ought to let someone know. Particularly in that case, the hole would probably get closed pretty quickly. And if some random person notices a hole, it would be pretty easy for someone actually looking for a vulnerability to find it.
For example, if in August (or before) someone had said to the general public something like, "You can probably hijack an airplane with legal objects and then destroy a building with it", the passengers wouldn't have let the hijacking get anywhere, and the hijackers probably wouldn't have tried. There's obviously the risk that some groups that wouldn't have thought of it would get the idea, but it would have gotten fixed in policy before anyone could do anything to exploit it.
I think if Linux or MacOS, as they are currently, were the most widely used, MS would still have more reported bugs, because there's just so much MS stuff. There's the kernel, the GUI, many applications, etc. With Linux, bugs in these would be reported against different entities.
Also, MS software is integrated on a large scale without sufficiently restrictive interfaces to cleanly separate it into individual programs. Since the number of potential bugs in a program grow faster than the length, this makes such integrated code more likely to have bugs; and, in fact, many MS bugs are due to interactions between different projects. With the Linux model, code is in relatively small chunks, which communicate over limited interfaces, so there is much less opportunity for cross-project bugs.
So I think that, to a certain extent, the reason that there are so many MS bugs reported is mostly that there are so many opportunities for MS to make mistakes, due to their size and the architecture they have chosen.
I don't know how to do Word macros, I only barely understand the emacs equivalent (I've made trivial changes to other people's.el files), and LaTeX macros are pretty easy (and the ones you're likely to want are probably examples). I found it very difficult to change fonts, and didn't know you could change colors (I've only worked on things that were going to be printed in black and white, so I didn't look).
I've never had any reason to do mail merge, and I'd probably do it with something other than an editor anyway.
What I've tried to do is mainly to write an exam, involving making a lot of questions and then deciding to use only some of them. They had a bunch of figures and tables, which had to be numbered, and they had to refer to sections of text by the page they appeared on. It took forever to deal with every single change, because removing a question would require renumbering all the references, changing the spacing, renumbering the pages, and renumbering the page references.
I managed, after a few months, to figure out how to save changes to the document (rather than making a new copy). We never mangaed to figure out how to have people modify different parts of the file at the same time.
There's nothing emacs does that vim doesn't that's really important. The main point is that you can do things like changing fonts without using a random jumble of keys and menus, and that you can get it to number things and do page layout for you.
Re:Will we have to revise unicode?
on
XML for Ancients
·
· Score: 2
There are Unicode character sets in the 32-bit range; the first 16 bits is only supposed to be used for current languages in active use. So cuniform, along with linear B, runic, and possibly Tolkien's runes (and, unofficially, klingon), will probably end up in the 0x1xxxx range.
UTF-8 is actually perfectly sufficient for 32-bit characters. (And you meant UCS-32; UTF-n is an n-bit/character encoding of >n-bit characters, while UCS-n is the n-bit character set).
Slashdot Mirror
I see two reasons that Linux gurus don't point to the GUI tools: most of us haven't needed a tool for the given task since before the GUI tools were written. Once you configure something on your system, it tends to stay configured. If you ask someone for help getting your sound card working, and their sound card has worked since before there were tools, they probably won't know about the tools.
.environment, and you won't have that problem any more). But the stuff a guru can tell you will only make sense once you've run into a problem and have the shared context of wanting the system to do something better.
Also, many Linux gurus have entirely abandoned Windows. They don't know that a Linux feature is like a Windows feature that the user understands, because that feature wasn't in the last version of Windows they used much. Furthermore, they probably ignored the Windows-like features, because they were unintuitive and unfamiliar. I, for instance, don't expect a directory window to switch directories if it has icons in it, because 3.1 and Mac popped up new windows for different directories; the other model I expect is a shell, where programs I run from a directory generally stay in that window. A setup where I don't get a new window for a new directory, but I do get a new window if I run a program, is quite unexpected to me, and I'd be unlikely to tell a user to use a setup I had a hard time remembering how to use...
The essential correct idea of the article is this: the people who know how to explain Linux to new people are the people who learned it themselves recently. They have a similar background and expectations, they find similar interfaces sensible, and they've needed tools since the latest tools because available.
If and when the recent converts are unable to do something, an old guru may be helpful. A guru may also have good advice for customizing a system once the user has some experience (e.g., "Put 'update -Pd co -P' in ~/.cvsrc, 'alias cvs=cvs -q' in your
I don't need to log in to my home linux system. It's set up without any services and so it doesn't have any user passwords (if someone manages to get a username prompt, they've almost certainly broken in anyway). I do need to unlock my ssh identity file, of course, but that's normal. Users exist to allow customization and home directories, not security.
./configure && make && make install isn't all that difficult, if someone's given you a slip of paper or a shell script to do it.
Autodetection of hardware is a sensible feature for geeks as much as anyone else; if you're in to turning random old machines into linux boxes, you probably don't know what the video chipset with all the printing worn off is.
A single click of the mouse is not much simpler than apt-get. In fact, if you're installing something, it's probably simpler to know what the thing is called than to have an icon for it. Even tar zxvf $1-*.tar.gz && cd $1-* &&
There's no need to have only one GUI. What's needed is to have the user's GUI of choice available with any distribution. Ideally, a user would be able to fetch their customization info from somewhere, too, and then it wouldn't even be as confusing as sitting down at someone else's windows box (not to mention switching to CE or ME or NT or XP or... how many interfaces did you say?).
The adage doesn't really hold. A good tool can be used by an idiot and used very well by an expert. Looking around my desk, I see a telephone, a box of tissues, a coffee mug, a book, a pair of headphones, a paper bag, etc.; they're all really easy to use and pretty idiot-usable, and every geek I know uses them. Linux should be similar: it works well without fiddling around inside. You can take the cover off and rewire it to make it do other things, but you don't have to.
I mean, I *could* configure things with echo, sed, grep, and cat, and I actually do on occasion, but usually I use a text editor if that makes it easier to get the result I want. If I had a special config tool that worked well, I'd use that instead, so long as it didn't needlessly destroy my hand-tuned files and left files that I could hand-tune if I found I needed to do something not supported. Being a real power user isn't about always using the more powerful tools; it's about using the tool which will have the effect you want in the shortest time.
Yeah, it's just that what makes an iMac an iMac is it's weird shape, and so a non-curved one just wouldn't be the same. They'd have to be very clever to keep product recognition while using a flat screen and actually getting some advantage out of not having a CRT in the box.
If budget isn't a concern, why not install Snort in addition to something else? That way you'll know when to blame company Y and what to blame them for missing. An IDS isn't like a fileserver where you can only really use one or another.
They're going to have to redesign the whole thing if they want flat screens, because the box isn't flat on the front. Either than, or they'll have to make curved-panel displays.
Of course, an iMac box would look really weird without the CRT, because it would be mostly empty, and they probably can't just make the box smaller, because they need vent space. So they'll probably have to come up with a special new shape.
In order to install the system without being present, the installer would have to not be interactive. If you want any configurability, you need to be able to script it (i.e., burn the configuration options on the CD beforehand). But in that case, you really don't need an installer, which primarily wraps a bunch of tools in a UI.
The issue is that an installer wraps a bunch of tools (which generally have UIs) in a special UI that only works if you mostly wipe out your system. If you want to then change anything that you set up, you have to use totally different programs (unless you reinstall). If you like the installer, it sucks to maintain the system; if you don't like the installer, it sucks to install the system. In any case, there's no reason for an installer which does something other than run fdisk, the system config tool, and the package manager. At most, you'd want to have it delay all the slow stuff until after you've done all the configuration.
If the tools include the ability to set up a Linux installation along with a Debian-on-Windows installation, you could skip the installer entirely.
That is, people install Debian under Windows to get the Unix tools that the developers downstairs keep telling them about. After a while, they find they're using mostly Debian programs. They repartition (or stick in, or clean off, another hard drive), and then run the Debian tools to install Linux versions of what they have Windows versions of. The system can thus be installed very much the way the user wants, because the user has a functioning Debian system to point it at.
I've always felt that the idea of a Linux installer is broken: it hides the use of a number of tools that you're likely to know (or need to know eventually) behind an interface that is just different. It would be much better to give direct access to the real tools and provide guidance as to what you're doing with them and what order to do things. If the underlying tools are insufficiently friendly, they should be improved, not wrapped in special-purpose code.
The main justification for an installer, rather than good maintenence tools, is that you can use an installer without having an existing system. But if you can use the Windows installation on a machine as a system under which to run the maintenence tools for a new Linux installation, there's no need for an installer.
It seems like the US Lineage players would tend to be mainly mercenaries, either for money, for experience, or because they think their employer is doing something good.
A separate Lineage game in the US probably wouldn't work very well-- people want to play the "main character", or one of a band of adventurers, while the world must be made mostly of minor characters who are important in groups. On the other hand, if the world has 2 million people playing people in groups, the addition of a few hundred thousand freelance people would probably work fine for game mechanics.
It would probably be very interesting to go on quests in a fully-fleshed-out world inhabited by a large number of PCs and NPCs in realistic arrangements. Thinking about LotR, there are a ton of groups of people who clearly ought to be PCs who don't fit the adventurer model, and it would be very interesting to have a MMRPG with people who actually want to play those roles.
I think that, currently, the threat of a lawsuit is basically meaningless. Any particular pair of entities could find something to sue each other over, and could probably win, provided they weren't asking very much. It doesn't cost anything to ignore a letter.
If the RIAA had actually brought charges, that would be different, and Felton could have reasonably sued them over it. But sending scary junk mail is their First Amendment right, like it or not, and, in the eyes of the law, they never said they were a suitable plaintiff for a First Amendment vs DMCA case against Felton.
The separation is good, but the problem is that the courts never sit down and interpret new laws just so that everyone understands them; they wait until someone is accused of violating the laws, and then they interpret them.
Of course, I can't see any clear reason that it would be any different if the courts weren't separated. In the current scheme, Congress just passes anything they feel like, without regard for the constitutionality of the laws. Having a congressional section which could reject any law they deemed unconstitutional would be as good as having the courts do it, and it would presumably be done promptly. Of course, this branch would have to be essentially court-like, chosen for the ability to interpret legal language, but there's no reason it would have to take actual cases to establish precedent.
Right, so you can't sue someone to get a judgement in a case that hasn't been brought against you.
And, as much as you'd like to, you can't actually find out in advance if what you want to do will be judged legal before you do it. You have to wait until you've actually been sued in order to defend yourself.
That makes sense; otherwise, you'd have McDonalds suing everyone who spills coffee on themselves, alledging that the victem knew the coffee was hot.
Of course, it is a flaw in our government that the legislature creates the laws, and the courts interpret them, but the courts only deal with past events, so there's no way to know what a law means until someone is charged under it. It would be kind of nice to be able to say, "I will do this, but only if it's legal", but that's not possible in the US. This is probably because the court system requires motivated people on both sides and a lot of particulars to consider.
Under the assumption that the Linux version would try to monitor the user under their own UID, rather than attempting to get root access, it would probably be an X program which didn't open any windows and just tracked keyboard and mouse events. You could detect it or defeat it by turning on the "Secure Keyboard" feature of your xterm before typing your password-- this causes the xterm to get exclusive control of the keyboard from the X server while it is on. If it beeps instead of turning inverse video, there's something wrong (like you have a different program in that mode). This feature is in the ctrl-left-button menu.
If it was a root-level attack, it would be very difficult to detect, unless you knew what the code looked like, in which case you could scan for it. However, it would have to exploit a root vulnerability, which is non-trivial; vulnerabilities get fixed, and people often look for evidence of anything getting in after they close the vulnerability.
If they distribute this thing virally, it doesn't matter what the scanners do, because any court in the US would throw out the evidence. Plus, everyone would lynch them as cyberterrorists. What it sounds like they might do, though, is distribute it as a trojan: they send it just to the person they have a warrent against, either directly, by way of a cooperating associate, or by forging it as from someone the person expects to get mail from. It uses the same vector as a virus, but it isn't a virus, because it lacks any mechanism to spread, since they are not allowed to collect evidence about other people.
They can't just spread this everywhere, because citizens would look rather unfavorably on the FBI deciding to do billions of dollars of damage to corporate networks with a virus. In addition, if they did something like that, people would clean it up even if the virus scanners didn't. In order for this to be at all feasible, it has to be stealthy and rare, and, in that case, virus scanning companies will probably never see it.
And even then, there would be no reason to run anti-virus software on Linux. Instead of running software to block, detect, and remove individual viruses, just patch the holes they use.
The reason to run anti-virus software is that you regularly try to execute malicious code. The anti-virus software detects when you are trying to run code that is known to be malicious, and stops you. If you're using a Linux box, the right solution is to not run untrusted code; if something people do leads to running untrusted code, whether it is malicious or not, that is a problem, and it will (ideally) get fixed, not papered over.
These companies provide detection and removal services for widely-distributed and automatic attacks. That is to say, it's their job to clean up when someone releases a virus that spreads all over the place. They discover something spreading, and they make an update.
If the FBI is doing their job well, that's not the situation here. The way they've been describing this working is that they set it up to attack the particular person against whom they've obtained a warrent. It doesn't email itself to the target's addressbook, it doesn't attack random IPs, it doesn't try to infect floppies. That would be both illegal (since it could destroy the data of non-targets) and probably invalidate their evidence (since they don't have a warrent to investigate every individual in the US).
So a virus scanner shouldn't catch Magic Lantern, because it's not really a virus, in the sense that they're scanning for. It's an attack tool, which uses the methods often employed by viruses. Virus scanners don't fix security holes; they look for particular malicious and spreading code on your computer and clean it up. They won't stop Magic Lantern, they won't stop someone hijacking your passport account, and they won't stop even script kiddies breaking into your webserver, because their purpose and system design just aren't good for that.
So far I haven't heard of any IDS companies saying they will ignore ML, nor have I heard of any companies saying they won't fix security holes that ML uses. That's what would be significant.
The line seemed okay to me; it sounded like The Tick had picked it up from hearing other people, and had no clue what it meant. Saying it about a villian or some other person would be out of character, but about a coffee machine is different. The Tick is too innocent to understand why this is odd, and probably too innocent to know that it's naughty. At least to me it came across as something he wouldn't say if he knew that it was something he shouldn't say.
The way anti-virus software generally works is that it detects particular programs and patterns. This isn't like fixing a security hole or something, where a number of programs can be stopped with a single fix.
In this case, they'll probably just not write a detector for ML, and it won't get caught. If someone writes something similar to ML, they'll probably just test their detector to make sure it only catches the intended virus and not ML.
McAfee is in the business of stopping particular exploits, not of fixing anything. That's why people keep getting new viruses that aren't significantly different from old viruses.
Of course, ML doesn't seem to be designed to spread all over the net, so McAfee probably wouldn't do anything about it anyway, any more than they do anything about other non-automated security breaches.
You should risk getting burned on the "pre" versions. That's why they're "pre" versions. There's no reason to rush out a "final" version, especially after even a small change. The reason the "pre" versions were there was so that people could do QA on them. The right move would have been to fork 2.5.0 off of pre9, and just leave pre9 around for a bit. This bug would have turned up in a few days, gotten fixed, and then 2.5.0 would get patched, pre10 would come out, that would sit around a bit, and, if the patch is good, it would become final.
Nothing should change between the last release candidate and the final version, except the version number, and the last release candidate should stay a release candidate until the QA has been done. That's why there are final versions.
That explains why pre9 was released with the bug, but not why the final version was released with it. There really needed to be a "release candidate" notice on things that could become final versions and then a QA pass, before something gets blessed as a "final" version.
The advantage with OSS is that you get frequent releases, which enables you to keep up with development and test the upcoming version to see if it works for you. But that doesn't help much when the upcoming version gets changed and then released without testing.
Of course, there is the other advantage: that the person responsible for a bad bug in a final version will actually spend the day after thanksgiving fixing it, so that this sort of accident gets fixed in a day or two.
Just think, the schools could sell $0.9 billion in premium licenses that MS is legally required to keep track of for the holders to businesses having license problems with MS, buy whatever they want, avoid using software which will be out-of-date and totally useless when the students graduate, and save everyone except MS a whole lot of trouble.
Personally, I think the plantiffs should just go for $10b and actually get refunds for the software that MS forced on them. Or settle for (highest price of Windows - $30) for each plantiff. If MS wants to raise prices later or go to a subscription model, they can just keep paying the plantiffs. After all, the issue at hand is MS overpricing their software, so something should be done about it.
Two problems:
All of their examples are of pages that you want, but most pages you see are not actually content. Would you pay a penny for the google search page? A page of amazon search results? The page confirming your credit card info? An extra cent each time you want to preview a submission? A web page is not a unit of content, but a unit of interaction, and it's the content that the users want.
The comparison to books is apt, but their characterization of books is grossly wrong. If you go into a bookstore, you will find that all of the books are free, so long as you only want to browse them. If you want to read them longer, you can get them from a library. Why do people buy books? Because they've determined that they want to have their own copies.
The sensible model would be for sites to have "buy this content" buttons. They'd let you pay whatever you wanted, with a suggestion and a minimum from the site, and the only effect they would have is that that button wouldn't appear for you again. Sites would only have them on pages that they thought were worth paying for (or nobody would click them, and people would get annoyed). You could decide whether you actually liked the page before deciding to click the button.
Consider: each Onion article gets a button next to it. If you enjoy the article, you click the button and pay them a cent. You look up Afganistan in the Brittanica. If it has the information you want, you click the button and pay a dime; if it isn't up to date enough, or is too vague, or is just the same as the other sources you've found, you don't. You read a web comic. If you're just sampling it and you're not interested, you don't pay; if you read it regularly, you click the button each time. You do a google search. Each time it finds a site you wanted, you click the google button (and the site's button); for all the search results that fit the query but weren't quite what you were looking for, you don't pay. You download an MP3 from a band site. If you like it, you pay a couple of cents. If you like it enough to keep it to listen to frequently, you pay a dollar. If it didn't come through correctly, you don't pay anything.
The essentialy idea is that people will pay for things they like, even if they don't have to, and even if they don't get much out of it. Of course, this also requires convenience; I would pay for, say, web comics, but the accounting and the payment cost more, in time doing boring stuff, than it's worth. Nobody paid for shareware because, while the software was worth $15, it wasn't worth a check, a stamp, an envelope, and the time and effort to combine them.
The CIA and such are, in this case, in the position of the vendors: it is their responsibility to fix the vulnerabilities.
The disclosure should be done by people who identify the vulnerablities. If you know where you can cross a border undetected, you ought to let someone know. Particularly in that case, the hole would probably get closed pretty quickly. And if some random person notices a hole, it would be pretty easy for someone actually looking for a vulnerability to find it.
For example, if in August (or before) someone had said to the general public something like, "You can probably hijack an airplane with legal objects and then destroy a building with it", the passengers wouldn't have let the hijacking get anywhere, and the hijackers probably wouldn't have tried. There's obviously the risk that some groups that wouldn't have thought of it would get the idea, but it would have gotten fixed in policy before anyone could do anything to exploit it.
I think if Linux or MacOS, as they are currently, were the most widely used, MS would still have more reported bugs, because there's just so much MS stuff. There's the kernel, the GUI, many applications, etc. With Linux, bugs in these would be reported against different entities.
Also, MS software is integrated on a large scale without sufficiently restrictive interfaces to cleanly separate it into individual programs. Since the number of potential bugs in a program grow faster than the length, this makes such integrated code more likely to have bugs; and, in fact, many MS bugs are due to interactions between different projects. With the Linux model, code is in relatively small chunks, which communicate over limited interfaces, so there is much less opportunity for cross-project bugs.
So I think that, to a certain extent, the reason that there are so many MS bugs reported is mostly that there are so many opportunities for MS to make mistakes, due to their size and the architecture they have chosen.
I don't know how to do Word macros, I only barely understand the emacs equivalent (I've made trivial changes to other people's .el files), and LaTeX macros are pretty easy (and the ones you're likely to want are probably examples). I found it very difficult to change fonts, and didn't know you could change colors (I've only worked on things that were going to be printed in black and white, so I didn't look).
I've never had any reason to do mail merge, and I'd probably do it with something other than an editor anyway.
What I've tried to do is mainly to write an exam, involving making a lot of questions and then deciding to use only some of them. They had a bunch of figures and tables, which had to be numbered, and they had to refer to sections of text by the page they appeared on. It took forever to deal with every single change, because removing a question would require renumbering all the references, changing the spacing, renumbering the pages, and renumbering the page references.
I managed, after a few months, to figure out how to save changes to the document (rather than making a new copy). We never mangaed to figure out how to have people modify different parts of the file at the same time.
There's nothing emacs does that vim doesn't that's really important. The main point is that you can do things like changing fonts without using a random jumble of keys and menus, and that you can get it to number things and do page layout for you.
There are Unicode character sets in the 32-bit range; the first 16 bits is only supposed to be used for current languages in active use. So cuniform, along with linear B, runic, and possibly Tolkien's runes (and, unofficially, klingon), will probably end up in the 0x1xxxx range.
UTF-8 is actually perfectly sufficient for 32-bit characters. (And you meant UCS-32; UTF-n is an n-bit/character encoding of >n-bit characters, while UCS-n is the n-bit character set).