> This is the one I would use the most. Apparently Ohioans don't understand the term "passing lane".
Many Americans seem to be under the impression that the passing lane is reserved for people who are going faster than the speed limit. In fact, it is every bit as illegal to speed in the left lane as it is in any other lane.
Now, if some idiot's doing 30mph in the passing lane, then you should call the police and report him, because he's definitely not supposed to do that. (Though you should also be aware that passing him on the right is, nonetheless, generally a ticketable offense, although there may be an exception clause for limited-access highways, at least in some states.)
It has generally been my experience, however, that 95+% of the complaints about people "not knowing what a passing lane is" and driving too slow in one are regarding a driver who is in fact within 5mph or so of the posted speed limit, in which case the complaint is invalid. It's generally illegal to pass such a driver on either side (although I think passing on the right may be a worse offense than speeding), and the people who complain about it are, as a rule, impatient sociopathic speed demons who should not be allowed to drive on the road.
> Be it viruses or spyware (a big problem with senior citizens, in fact all non computer aficionados)
You can eliminate 98% of that by setting the computer up for them correctly before you turn them loose on it. People who go to the store and buy a computer are screwed, of course, because the OEMs invariably let the marketing department decide how to set them up. But if a knowledgeable geek is setting the system up initially, this is *MUCH* less of a problem.
Long experience tells me that Windows *does* break by itself, from time to time, sometimes quite horribly.
Sometimes Windows forgets how to use a particular device driver, and it has to be uninstalled and reinstalled if you're lucky; if you're not lucky Windows has to be reinstalled. Sometimes a critical system file becomes corrupted, and Windows has to be reinstalled. Of course, filesystem corruption can happen with any OS if you have an unclean shutdown event (e.g. due to a power outage), but with Windows it can also happen at random while the computer is running, or even during boot-up after a supposedly clean shutdown. This is not a frequent occurance, but it happens.
However, I'm not convinced this makes Windows unsuitable for a senior-citizen setup. I suppose it depends, but in a lot of scenarios needing to reinstall the OS once every three years is not a prohibitive burden.
Most of the problems that happen significantly more often (e.g., malware) can be prevented by setting the computer up correctly in the first place. This takes significant doing, but it can be done. Among other things:
All user accounts must be password-protected. You make the normal limited-user account password easy to remember and teach it to the user, but administrative passwords should be complicated, hard-to-type, written down on a 3x5 card, laminated, and stored in an envelope physically taped to the computer tower. If this is Windows XP, you will need to teach the user to log in as administrator periodically (I recommend once a week on a specific day of the week) and make sure all the Windows Updates install. Set up the admin account with a VERY different visual theme, preferably ugly and based on red, and with no convenient shortcuts for anything *but* Windows Update, so that the user will not want to stay in it for other activities. (Vista makes this last part unnecessary due to UAC, but in that case you have to do user training for how to respond to UAC prompts; specifically you want them trained to only use the admin password when applying updates. No, you do not want end users doing other admin tasks such as installing new software.)
Access to Outlook Express *MUST* be disabled. This is not negotiable. You do *NOT* want to be on the hook for maintaining a system that untrained end users run Outlook on. That's bad juju. I recommend installing Pegasus Mail instead; it's easier to learn to use than webmail (or MSOE for that matter), especially if configured properly when you install it, and it generally handles security issues in the best possible way. The only major drawback to Pegasus (besides that it only runs on Windows, which for your purposes here is probably not important) is that it's MDI, but if you set up the desktop shortcut to run pmail maximized this is not a big deal for un-savvy users. (It would be annoying for a power user, who might want to arrange windows so as to have another app on the screen at the same time, but people who don't know what they're doing with computers pretty much never ever want to do that. Typically the very idea that it's possible gives them a headache.)
You don't want to disable access to IE (because you want it for Windows Update), but you *do* want to remove the shortcut from the desktop and replace it with something else, probably Firefox. Open up about:config and set image.animation.mode to once. Turn off its auto-updates feature unless you're on Vista. (If you think they can handle it, you can have them check for Firefox updates from the admin account once a week when they do the Windows Updates. But in practice an out-of-date Firefox is *MUCH* less dangerous than running in an admin account all the time.)
Install OpenOffice.org so they can open Office documents. Turn off the Java automatic update thingy. Install the Flash player and FlashBlock add-on. Install the Adobe reader, but turn off its check-for-updates feature, and make sure Firefox is set up to open PDFs by launching acroread externally in its own window.
> How about a compilable form that it was never written in originally but is still > "source code" (thinking: convert code to Whitespace before submission)?
use Acme::EyeDrops;
> What about source code comments?
An argument could be made about whether those are really part of the code, but there are other things that are *definitely* part of the code (constant declarations, macro definitions,...) or *can* be embedded in the code (e.g., documentation, such as POD) that you would generally not so much mind revealing to potential competitors.
> And lastly, how big is a "page"? If I print my code in a 90 point font, > not a lot fits on an A4/Letter sheet of paper.
I suspect that when the guideline was set (or the case law established or whatever) up the major popular programming languages were less flexible about this sort of thing. For instance, COBOL and ForTran both have specific ideas built into the language about how many columns the source code should have.
> Apple seems to think their copyright monopoly gives them a monopoly over their commodity hardware business too.
Well, you've used the word "monopoly" in a looser sense than I would have done. Apple is not a monopoly in the antitrust-regulations sense of the term, because they have direct competitors with very considerable market share. In the operating systems market, for instance, Microsoft makes Apple look like a minor player, and in the hardware market, HP and Dell are the big boys. The market where Apple has the largest market share is probably portable music players, but even there they are clearly a minority player, and possibly not even the largest minority player, depending on whether you include the players that use removable media along with the ones that use internal non-removable storage. (Sony for instance sells a *lot* of portable CD players, which arguably compete more or less directly against Apple's music players, especially the larger iPod models. Even if you exclude those, there are a LOT of non-Apple mp3 players on the market.) So Apple is not a monopoly in the sense that would warrant their regulation under antitrust law.
However, terminology aside, I agree with what I think you were trying to say.
Apple believes (or wants to believe, or wants the court to believe) that in addition to their copyright on OS X, which does indeed legally give them the legal right to be the only company selling OS X, they beyond that somehow *also* have the right to be the only company selling hardware it runs on. That, I think, was your point, and it hits the nail right on the head.
Traditionally Apple has used whatever means they could concoct to enforce this. For instance, I believe at one point they were embedding copyright-protected software into the hardware (i.e., firmware, the equivalent of what the BIOS is for PCs). That might have been before they started using Intel processors, though, I'm not sure. I haven't kept up on all the latest Apple news, so that may not still be their current approach to the matter, though if it's not, I don't know really what would be. Trademark law ain't gonna do it if the cloner's stuff doesn't use anything that looks like an Apple trademark, and while the copyright on OS X might *potentially* (IANAL, and I have some doubts about this in any case) *possibly* be able to be used to prevent the cloner from pre-installing OS X (because then they'd be redistributing/reselling it, not just an individual copy like first sale doctrine but systematically), but that *won't* stop the cloner from selling compatible hardware to people who are willing to buy and install the OS themselves, and I strongly suspect Apple would like to stop that too, if they can.
I don't know what the deal is with this "they forgot to register the copyright" thing, but it's obviously some minor point or else a red herring, because the Berne convention is NOT going to let the clone-maker produce and distribute copies of OS X (nor, as far as I can tell, are they trying to do so; presumably their legal department knows better than that, because you don't even *need* a copyright attourney to understand that much copyright law). Maybe it relates somehow to some arcane part of the battle over whether they can *resell* it, or maybe it's mud in the water, I'm not really sure.
Of course, if they were to make their own OS that *behaves* a lot like OS X, that would be a clone, and then you could start getting into trickier arguments about exactly how similar it can look and feel without infringing the copyright. But to my knowledge that's not what the clone-maker is doing, so it's neither here nor there at the moment.
> Windows gets in trouble for tying a goddamn media player THATS FREE to its OS
That's because Microsoft is a regulated monopoly, because Windows has something on the order of 90% market share in the operating systems market. Normal companies that have a minority market share (like Apple's 3% in operating systems, or even their 30% or so in portable mp3 players) are not bound by antitrust regulations in the same way.
Of course, that only means Apple won't get in *trouble* for bundling the hardware and software together. Whether they can convince the court to *enforce* this against the clone company is a separate question. I'm not sure I understand how the copyright on OS X is even relevant, if the cloner is using legit-purchased retail copies of the OS from Apple for each clone computer. But IANAL.
> The Windows update system only updates Windows, and it's components.
Currently, I am not aware of any OS that provides a centralized automatic updates facility for third-party software.
Granted, Linux distros typically include much more software in the distro (and thus within the sphere of what's updated automatically) than Windows, but if you install anything that's *not* part of the distribution, it doesn't get updated unless it provides its own updater.
> Instead, the distrib's auto-update mechanism handle it (apt for Ubuntu/Debian, [etc]). > This is better on many levels, since it prevents a user process from altering the binary.
And this is what ideally *should* be done on all platforms, and it's what Automatic Updates does for IE on Windows.
But there's currently no provision for third-party software to be updated by the OS mechanism. (IMO there should be; the installer should inform the OS, via a provided API, as to where to get updates and what public key(s) to use to verify their authenticity, and the OS should automatically handle the updates. But I don't know of any OS that currently does this for software that's not included with the OS distribution.)
> So yes, Ubuntu automatically "checks and proposes security updates".
Yeah, but he said "at bootup".
Ubuntu doesn't *need* to connect updates with bootup, because the filesystems it uses generally are ones that have inodes, so files can be updated at any time, without a reboot.
If for some reason you were running a *nix system with the root filesystem using a filesystem type that doesn't have inodes (NTFS, FAT, whatever), then the update mechanism would have to arrange for reboots in order to allow all the files to be updated. I'm not aware of any major distro that provides for this possibility, but I also don't know of anyone who runs a modern Linux system on a non-inode filesystem. (Historically there were some distros that supported this, via a mechanism called UMSDOS, but that was back before security updates were a major consideration. I've not heard of anyone using UMSDOS filesystems lately.)
> I even find it awkward that no popular linux distribution checks and proposes security updates at bootup.
Most of the filesystems that are popular on Linux (e.g., ext2, ext3) have inodes, so updates can be applied at any time. Thus there's no particular reason it should happen at the same time as rebooting.
Windows has to do updates at reboot time because NTFS doesn't have inodes, and so open files can't be updated, and so a reboot is required to make sure nothing that needs to be updated is open.
> On a side note, why is a 20sec reboot really this horrible?
Because it causes the users to lose whatever they've been working on for the last twenty minutes and haven't saved yet. (Technically the "rebooting in N seconds" warning *should* give them time to save their work, but some of the users where I work don't know how to save partway through a task, find it again, and finish later. The line-of-business software that we use doesn't make this any easier either.)
> especially if the updates are applied at night while the computer is not being used
The computers are turned off when they're not being used, especially at night, so that wouldn't work.
If WU would just be set to *wait* for 24 hours before doing the reboot thing, there'd be no problem. The computers would always be shut down by then.
> The reason updates "require" reboots is because that's the only way you can be sure with a typically > ignorant end user at the helm, everything that needs to be replaced and/or restarted has been.
There's actually a more technical reason: NTFS doesn't have inodes, so open files can't be updated.
The feature I want in Windows Automatic Updates is for the system administrator to be able to flip a switch somewhere in the control panel, and Automatic Updates are automatically downloaded and installed, but if a reboot is needed, the computer *waits* for up to 24 hours before bothering the user about it.
You see, where I work, the users all shut their computers down at night. Faithfully. But they ABSOLUTELY DO NOT WANT the computer to restart during the day while they're working, so much so that they've taken to calling the second Tuesday of the month "Black Tuesday".
> I think one of the key things here is that Windows seems to require a reboot for > EVERY LITTLE PATCH,
I agree this is a problem, but...
> which is a problem with the way they've hyper-integrated the kernel, the IE engine, and the shell.
You've got the cause wrong. It's actually a consequence of the fact that NTFS doesn't have inodes. When the filesystem doesn't have inodes, open files can't be updated. Files that are part of the operating system are generally open whenever the system is running, so they can't be updated without a reboot.
Updating open files requires that you be able to leave the old, open version of the file contents in place temporarily, but detach it from the directory entry, which will point to the new inode(s), and then garbage-collect the old inode(s) when the last process that had them open lets them go. NTFS isn't designed this way.
> Until recently I worked in a mom and pop PC repair business. About 9 out of 10 systems I > worked on were out of date, typically by a few months. I don't know for sure, but my guess > is that users are switching auto-update off because can't be bothered with 'nag' messages > from their software.
It's also possible that they were dialup users who turn off the computer when they're not using it. In that scenario some of the larger updates (e.g., service packs) become bottlenecks that the system can never get past.
If they were on Windows XP or lower, it's also possible that they never log in as administrator, which would effectively prevent them from ever getting the updates that require human intervention, e.g., WGA Notification. Then *those* become bottlenecks that the system never gets past. (On Vista this is no longer as big a problem due to UAC; although the user does still need to *have* admin credentials, in order to approve things, they don't need to go out of their way to log into a special admin account to do it.)
Still, although these are problems Microsoft needs to address, I still think it's ideal for application updates (not just the browser but any application) to be handled in a centralized fashion through the OS. If the OS updates aren't installed, what makes you think the same users would faithfully install application updates that aren't handled through the OS update mechanism?
(And FWIW, your figure of 9/10 is very skewed. There are a lot of systems out there that aren't up to date, yes, but it's nowhere near 9/10. The ones that are up-to-date don't come in for repair anywhere near as often, so you're getting an inherently biased sample. If I had to guesstimate, I would say the percentage of Windows systems that are months out of date is more like 3/10 or so, but that's a very loose approximation.)
But the best setup is for application updates to be centralized in one place and handled by a mechanism provided by the operating system. Then the user (or sysadmin) only has to manage it (e.g., tell it what time of day to do udpates) in one place. Only one process is doing update-checks, so you don't have umpteen different update-checkers running in the background degrading system performance. Permission to install stuff in places the user doesn't have write privs doesn't have to be granted to every application's separate update mechanism. And so on.
Ideally, whenever the system administrator installs software, the installation mechanism should inform the operating system (through a provided API) as to where the updates for this application can be found, and one or more public keys that can be used to check their authenticity, and then from then on the OS ought to automatically check for updates for that app and install them when they become available. (Most apps would probably just give one public key and sign updates once, but paranoid developers could have multiple people sign their updates with multiple keys, to prevent the compromise of one key from compromising the whole process.)
I don't know of any OS that handles this in this manner right now. IE is only included in Automatic Updates because Microsoft views it as part of Windows, and even Microsoft Update only handles Microsoft products. Non-Microsoft products are totally on their own for updates. Apple's no better about this. Most Linux distributions do security updates for all the software in the distribution, but if you install any third-party software (not just proprietary stuff, but also any open-source software that the distro does not include for whatever reason) it's on its own for updates. This is not ideal.
> Firefox updates upon the point of relaunch. There is no need to restart windows.
Windows users are accustomed to having the computer restart for no reason all the time. I don't think one more restart is really going to matter much. And it happens automatically, so the user doesn't have to *do* anything.
Actually, having the update mechanism built into the OS is superior, because it can happen even if the logged-in user doesn't have the privileges needed to update the browser. The Firefox update mechanism actually doesn't work in that situation at all. (Well, it can still update the user's browser add-ons...) If the user never logs in except to a limited user account, IE will still get updated; Firefox won't. Ever.
Don't get me wrong, I'm not a big Microsoft fan. But this is something they actually got *right*. Debian does the same thing: iceweasel security updates are handled through the normal apt update mechanism, same as security updates for any other part of the system.
> Tools such as the La Susana and the Iron Maiden make it much more interesting.
You can also use car dealership commercials. After about eighty hours of nonstop back-to-back car dealership commercials, the subject begins to lose mental control. That's when you send in the whining children...
> the web content worth reading, slashdot included, are well above that.
You're joking, right?
I would have estimated the reading level on slashdot, on a good day, at about third grade, roughly at the same difficulty level with such childhood favorites as The Wizard in the Tree, The Voyage of the Dawn Treader, and The Adventures of Tom Sawyer.
By ninth grade you're supposed to be able to read Shakespeare.
> I am sure most admins didn't set policies about.wri attachments like they did for.doc stuff either.
The truly paranoid admins who have free reign to do what they want (because their bosses respect their judgment and/or are afraid of them) generally have the mail servers set up to strip email of all attachments and, indeed, everything that's not plain text. (In extreme BOFH cases the attachments go into the bit bucket, and in other cases they are set aside and can be retrieved somehow if they turn out to actually be needed, e.g., you go to the IT guy and say, "Hey, I'm supposed to be getting a quote from B2BCorp for a new high-speed electric paperclip dispenser", and the IT guy finds that one and marks it for delivery.)
Most systems, however, allow Office-format attachments, because all bosses universally think they need to get those.
> > This information is in the article, BTW. > In the what, now?
In the TFA article. You're probably accustomed to people just calling it the TFA, but they mean the TFA article. Similarly, when these people talk about software programs, they usually just call them "software", but it means the same thing. Some people just like to shorten and abbreviate everything.
> Yeah, but it changes them to DOS format when you save, with no option to keep the UNIX line endings:(
Why would you want to? All the Unix software these days understands both formats, so if you've got data that you work with on both kinds of systems, proper ASCII carriage-return/line-feed pairs are the way to go. Not only can you open your files in Notepad then, but you can also send them directly to an ASCII printer without any special drivers or interpretation. (Granted, more and more printers these days expect Postscript, PCL, JetDirect, RPCS, or somesuch instead of ASCII. But there are still a few ASCII printers around, and they tend to be fast and efficient for printing large amounts of plain-text data.)
> You probably wouldn't want to, but you'd have to do what the NSA guys told you. > And why would they want to sniff on my IP? Dunno, maybe just because my name > is Middle Eastern (it's not, but let's assume that it was, for the sake of argument)?
I don't think you have any conception of how big the world is or how many people there are in it.
There are at least half a dozen people with Middle-Eastern names that I know about in the city where I live, a city of only about twelve thousand people, in central Ohio, so that's about 0.05% of the population. Assuming this is anything like typical (and if anything it's probably a lowball figure), if the NSA wanted to read all the email of everybody with Middle-Eastern-sounding names nationwide, they would have to employ *thousands* of people, full-time, to do nothing else but that.
Make no mistake, if the authorities do decide to watch *you*, personally, in particular, they would obviously try to do stuff like read your email and listen to your phone calls. But you or someone close to you would have to get their attention in some especial way, because they do *NOT* have enough time or manpower to watch everyone who looks or sounds "Middle Eastern". And if they did have such a program, they would NOT be able to keep it off the news, because when you get that many people doing something like that, some of them are going to talk to the press.
> I care about keeping DNS requests private. I personal would prefer that my ISP can't > tell where I'm browsing just by grabbing clear-text domain names out of DNS queries.
If your ISP wants to know where you're browsing, they don't need to look at your DNS lookups. In fact, you could put the domain names in your hosts file and never *do* the DNS lookups, and they would still be able to easily know *exactly* where you're browsing. Fundamentally, even if 100% of your traffic is encrypted end-to-end, your ISP still knows where the data is coming from and where it is going. They have to, in order to pass it along to the correct destination. They can also trivially determine how *much* data you're getting from any given site. All they've got to do is sniff the IP headers, which is pretty easy really, and it's fairly trivial to set up a filter that displays (or logs) just the ones related to you. From there it's five or six lines of Perl to make some nice graphs showing which sites you visit most often (or get the most data from), and so forth.
Of course, that's assuming they have some special reason to be specifically interested in where *you*, personally, are browsing. Because there's no way this side of eternity that they would ever have time to monitor the browsing habits of any significant percentage of their many, many users, and even if they did somehow magically have a few thousand man hours per week to blow on such a frivolous project, the sheer volume of inane drivel that constitutes most users' web traffic would probably drive the guy doing the monitoring into deep suicidal depression before he happened to stumble across your stuff.
But yeah, if you've sent threatening letters to your ISP's customer service department in which you mentioned that you know where to find bomb instructions on the internet, you need to be aware of the fact that, yes, encryption or no encryption, your ISP does have the ability to watch what sites you're visiting, if they choose to do so.
> [DNSSEC] effective[ly] publishes your entire zone as a side effect.
Can anyone explain why this is undesirable? To my way of thinking, the *purpose* of DNS is to publish this information. That is the whole point.
If you have servers you don't want the public to know about, in the first place you don't give them public-facing IP addresses at all, and you *certainly* don't put their addresses on a public-facing DNS server. (This is why some networks serve different DNS information internally versus what they publish externally.) I don't see how DNSSEC changes that at all.
The issue of acceptably-strong RSA keys being longer than will fit in a single UDP packet is another issue. The thing I don't understand there is why it's so important to avoid using TCP. Practically every other protocol on the internet runs on TCP, except for a couple of high-bandwidth things that don't need to ensure that all the data get through, e.g., VOIP. Why is sending DNS data via TCP undesirable?
If 1024-bit RSA keys are too weak, why not use 16348-bit RSA keys? It's overkill, of course, but in matters of security where it's difficult to quantify *exactly* how much you need, a bit of overkill is generally a good thing, right? I understand why a key that large won't fit in a UDP packet, but I don't see why using a relatively new and untested crypto algorithm is better than using TCP.
I mean, yes, I know that existing clients try UDP first and only send a TCP query if the result they get back indicates that's necessary, so people using old software would initially experience minor delays as the query has to be repeated on the TCP port. But assuming the ISP updates its DNS cache/resolver software in anything resembling a timely fashion, a lot of the extra traffic would only be going that far; the security-aware resolver would know to go ahead and use TCP in the first place when querying any nameserver that gave DNSSEC results last time it was queried. And eventually even the client software would be updated, and the delays we're talking about here are on the order of doubling the amount of time a name lookup takes, which for most things is not a particularly large delay; certainly it's no worse than what CNAME records do, to say nothing of glueless out-of-bailiwick nameservers, and the end user honstly doesn't even *notice* those delays in most cases, because the actual data takes much longer to transfer than the name lookup anyhow.
Slashdot Mirror
> This is the one I would use the most. Apparently Ohioans don't understand the term "passing lane".
Many Americans seem to be under the impression that the passing lane is reserved for people who are going faster than the speed limit. In fact, it is every bit as illegal to speed in the left lane as it is in any other lane.
Now, if some idiot's doing 30mph in the passing lane, then you should call the police and report him, because he's definitely not supposed to do that. (Though you should also be aware that passing him on the right is, nonetheless, generally a ticketable offense, although there may be an exception clause for limited-access highways, at least in some states.)
It has generally been my experience, however, that 95+% of the complaints about people "not knowing what a passing lane is" and driving too slow in one are regarding a driver who is in fact within 5mph or so of the posted speed limit, in which case the complaint is invalid. It's generally illegal to pass such a driver on either side (although I think passing on the right may be a worse offense than speeding), and the people who complain about it are, as a rule, impatient sociopathic speed demons who should not be allowed to drive on the road.
> Be it viruses or spyware (a big problem with senior citizens, in fact all non computer aficionados)
You can eliminate 98% of that by setting the computer up for them correctly before you turn them loose on it. People who go to the store and buy a computer are screwed, of course, because the OEMs invariably let the marketing department decide how to set them up. But if a knowledgeable geek is setting the system up initially, this is *MUCH* less of a problem.
Long experience tells me that Windows *does* break by itself, from time to time, sometimes quite horribly.
Sometimes Windows forgets how to use a particular device driver, and it has to be uninstalled and reinstalled if you're lucky; if you're not lucky Windows has to be reinstalled. Sometimes a critical system file becomes corrupted, and Windows has to be reinstalled. Of course, filesystem corruption can happen with any OS if you have an unclean shutdown event (e.g. due to a power outage), but with Windows it can also happen at random while the computer is running, or even during boot-up after a supposedly clean shutdown. This is not a frequent occurance, but it happens.
However, I'm not convinced this makes Windows unsuitable for a senior-citizen setup. I suppose it depends, but in a lot of scenarios needing to reinstall the OS once every three years is not a prohibitive burden.
Most of the problems that happen significantly more often (e.g., malware) can be prevented by setting the computer up correctly in the first place. This takes significant doing, but it can be done. Among other things:
All user accounts must be password-protected. You make the normal limited-user account password easy to remember and teach it to the user, but administrative passwords should be complicated, hard-to-type, written down on a 3x5 card, laminated, and stored in an envelope physically taped to the computer tower. If this is Windows XP, you will need to teach the user to log in as administrator periodically (I recommend once a week on a specific day of the week) and make sure all the Windows Updates install. Set up the admin account with a VERY different visual theme, preferably ugly and based on red, and with no convenient shortcuts for anything *but* Windows Update, so that the user will not want to stay in it for other activities. (Vista makes this last part unnecessary due to UAC, but in that case you have to do user training for how to respond to UAC prompts; specifically you want them trained to only use the admin password when applying updates. No, you do not want end users doing other admin tasks such as installing new software.)
Access to Outlook Express *MUST* be disabled. This is not negotiable. You do *NOT* want to be on the hook for maintaining a system that untrained end users run Outlook on. That's bad juju. I recommend installing Pegasus Mail instead; it's easier to learn to use than webmail (or MSOE for that matter), especially if configured properly when you install it, and it generally handles security issues in the best possible way. The only major drawback to Pegasus (besides that it only runs on Windows, which for your purposes here is probably not important) is that it's MDI, but if you set up the desktop shortcut to run pmail maximized this is not a big deal for un-savvy users. (It would be annoying for a power user, who might want to arrange windows so as to have another app on the screen at the same time, but people who don't know what they're doing with computers pretty much never ever want to do that. Typically the very idea that it's possible gives them a headache.)
You don't want to disable access to IE (because you want it for Windows Update), but you *do* want to remove the shortcut from the desktop and replace it with something else, probably Firefox. Open up about:config and set image.animation.mode to once. Turn off its auto-updates feature unless you're on Vista. (If you think they can handle it, you can have them check for Firefox updates from the admin account once a week when they do the Windows Updates. But in practice an out-of-date Firefox is *MUCH* less dangerous than running in an admin account all the time.)
Install OpenOffice.org so they can open Office documents. Turn off the Java automatic update thingy. Install the Flash player and FlashBlock add-on. Install the Adobe reader, but turn off its check-for-updates feature, and make sure Firefox is set up to open PDFs by launching acroread externally in its own window.
> How about a compilable form that it was never written in originally but is still
...) or *can* be embedded in the code (e.g., documentation, such as POD) that you would generally not so much mind revealing to potential competitors.
> "source code" (thinking: convert code to Whitespace before submission)?
use Acme::EyeDrops;
> What about source code comments?
An argument could be made about whether those are really part of the code, but there are other things that are *definitely* part of the code (constant declarations, macro definitions,
> And lastly, how big is a "page"? If I print my code in a 90 point font,
> not a lot fits on an A4/Letter sheet of paper.
I suspect that when the guideline was set (or the case law established or whatever) up the major popular programming languages were less flexible about this sort of thing. For instance, COBOL and ForTran both have specific ideas built into the language about how many columns the source code should have.
> Apple seems to think their copyright monopoly gives them a monopoly over their commodity hardware business too.
Well, you've used the word "monopoly" in a looser sense than I would have done. Apple is not a monopoly in the antitrust-regulations sense of the term, because they have direct competitors with very considerable market share. In the operating systems market, for instance, Microsoft makes Apple look like a minor player, and in the hardware market, HP and Dell are the big boys. The market where Apple has the largest market share is probably portable music players, but even there they are clearly a minority player, and possibly not even the largest minority player, depending on whether you include the players that use removable media along with the ones that use internal non-removable storage. (Sony for instance sells a *lot* of portable CD players, which arguably compete more or less directly against Apple's music players, especially the larger iPod models. Even if you exclude those, there are a LOT of non-Apple mp3 players on the market.) So Apple is not a monopoly in the sense that would warrant their regulation under antitrust law.
However, terminology aside, I agree with what I think you were trying to say.
Apple believes (or wants to believe, or wants the court to believe) that in addition to their copyright on OS X, which does indeed legally give them the legal right to be the only company selling OS X, they beyond that somehow *also* have the right to be the only company selling hardware it runs on. That, I think, was your point, and it hits the nail right on the head.
Traditionally Apple has used whatever means they could concoct to enforce this. For instance, I believe at one point they were embedding copyright-protected software into the hardware (i.e., firmware, the equivalent of what the BIOS is for PCs). That might have been before they started using Intel processors, though, I'm not sure. I haven't kept up on all the latest Apple news, so that may not still be their current approach to the matter, though if it's not, I don't know really what would be. Trademark law ain't gonna do it if the cloner's stuff doesn't use anything that looks like an Apple trademark, and while the copyright on OS X might *potentially* (IANAL, and I have some doubts about this in any case) *possibly* be able to be used to prevent the cloner from pre-installing OS X (because then they'd be redistributing/reselling it, not just an individual copy like first sale doctrine but systematically), but that *won't* stop the cloner from selling compatible hardware to people who are willing to buy and install the OS themselves, and I strongly suspect Apple would like to stop that too, if they can.
I don't know what the deal is with this "they forgot to register the copyright" thing, but it's obviously some minor point or else a red herring, because the Berne convention is NOT going to let the clone-maker produce and distribute copies of OS X (nor, as far as I can tell, are they trying to do so; presumably their legal department knows better than that, because you don't even *need* a copyright attourney to understand that much copyright law). Maybe it relates somehow to some arcane part of the battle over whether they can *resell* it, or maybe it's mud in the water, I'm not really sure.
Of course, if they were to make their own OS that *behaves* a lot like OS X, that would be a clone, and then you could start getting into trickier arguments about exactly how similar it can look and feel without infringing the copyright. But to my knowledge that's not what the clone-maker is doing, so it's neither here nor there at the moment.
> Windows gets in trouble for tying a goddamn media player THATS FREE to its OS
That's because Microsoft is a regulated monopoly, because Windows has something on the order of 90% market share in the operating systems market. Normal companies that have a minority market share (like Apple's 3% in operating systems, or even their 30% or so in portable mp3 players) are not bound by antitrust regulations in the same way.
Of course, that only means Apple won't get in *trouble* for bundling the hardware and software together. Whether they can convince the court to *enforce* this against the clone company is a separate question. I'm not sure I understand how the copyright on OS X is even relevant, if the cloner is using legit-purchased retail copies of the OS from Apple for each clone computer. But IANAL.
> The Windows update system only updates Windows, and it's components.
Currently, I am not aware of any OS that provides a centralized automatic updates facility for third-party software.
Granted, Linux distros typically include much more software in the distro (and thus within the sphere of what's updated automatically) than Windows, but if you install anything that's *not* part of the distribution, it doesn't get updated unless it provides its own updater.
> Instead, the distrib's auto-update mechanism handle it (apt for Ubuntu/Debian, [etc]).
> This is better on many levels, since it prevents a user process from altering the binary.
And this is what ideally *should* be done on all platforms, and it's what Automatic Updates does for IE on Windows.
But there's currently no provision for third-party software to be updated by the OS mechanism. (IMO there should be; the installer should inform the OS, via a provided API, as to where to get updates and what public key(s) to use to verify their authenticity, and the OS should automatically handle the updates. But I don't know of any OS that currently does this for software that's not included with the OS distribution.)
> So yes, Ubuntu automatically "checks and proposes security updates".
Yeah, but he said "at bootup".
Ubuntu doesn't *need* to connect updates with bootup, because the filesystems it uses generally are ones that have inodes, so files can be updated at any time, without a reboot.
If for some reason you were running a *nix system with the root filesystem using a filesystem type that doesn't have inodes (NTFS, FAT, whatever), then the update mechanism would have to arrange for reboots in order to allow all the files to be updated. I'm not aware of any major distro that provides for this possibility, but I also don't know of anyone who runs a modern Linux system on a non-inode filesystem. (Historically there were some distros that supported this, via a mechanism called UMSDOS, but that was back before security updates were a major consideration. I've not heard of anyone using UMSDOS filesystems lately.)
> I even find it awkward that no popular linux distribution checks and proposes security updates at bootup.
Most of the filesystems that are popular on Linux (e.g., ext2, ext3) have inodes, so updates can be applied at any time. Thus there's no particular reason it should happen at the same time as rebooting.
Windows has to do updates at reboot time because NTFS doesn't have inodes, and so open files can't be updated, and so a reboot is required to make sure nothing that needs to be updated is open.
> On a side note, why is a 20sec reboot really this horrible?
Because it causes the users to lose whatever they've been working on for the last twenty minutes and haven't saved yet. (Technically the "rebooting in N seconds" warning *should* give them time to save their work, but some of the users where I work don't know how to save partway through a task, find it again, and finish later. The line-of-business software that we use doesn't make this any easier either.)
> especially if the updates are applied at night while the computer is not being used
The computers are turned off when they're not being used, especially at night, so that wouldn't work.
If WU would just be set to *wait* for 24 hours before doing the reboot thing, there'd be no problem. The computers would always be shut down by then.
> The reason updates "require" reboots is because that's the only way you can be sure with a typically
> ignorant end user at the helm, everything that needs to be replaced and/or restarted has been.
There's actually a more technical reason: NTFS doesn't have inodes, so open files can't be updated.
The feature I want in Windows Automatic Updates is for the system administrator to be able to flip a switch somewhere in the control panel, and Automatic Updates are automatically downloaded and installed, but if a reboot is needed, the computer *waits* for up to 24 hours before bothering the user about it.
You see, where I work, the users all shut their computers down at night. Faithfully. But they ABSOLUTELY DO NOT WANT the computer to restart during the day while they're working, so much so that they've taken to calling the second Tuesday of the month "Black Tuesday".
> I think one of the key things here is that Windows seems to require a reboot for
> EVERY LITTLE PATCH,
I agree this is a problem, but...
> which is a problem with the way they've hyper-integrated the kernel, the IE engine, and the shell.
You've got the cause wrong. It's actually a consequence of the fact that NTFS doesn't have inodes. When the filesystem doesn't have inodes, open files can't be updated. Files that are part of the operating system are generally open whenever the system is running, so they can't be updated without a reboot.
Updating open files requires that you be able to leave the old, open version of the file contents in place temporarily, but detach it from the directory entry, which will point to the new inode(s), and then garbage-collect the old inode(s) when the last process that had them open lets them go. NTFS isn't designed this way.
> Until recently I worked in a mom and pop PC repair business. About 9 out of 10 systems I
> worked on were out of date, typically by a few months. I don't know for sure, but my guess
> is that users are switching auto-update off because can't be bothered with 'nag' messages
> from their software.
It's also possible that they were dialup users who turn off the computer when they're not using it. In that scenario some of the larger updates (e.g., service packs) become bottlenecks that the system can never get past.
If they were on Windows XP or lower, it's also possible that they never log in as administrator, which would effectively prevent them from ever getting the updates that require human intervention, e.g., WGA Notification. Then *those* become bottlenecks that the system never gets past. (On Vista this is no longer as big a problem due to UAC; although the user does still need to *have* admin credentials, in order to approve things, they don't need to go out of their way to log into a special admin account to do it.)
Still, although these are problems Microsoft needs to address, I still think it's ideal for application updates (not just the browser but any application) to be handled in a centralized fashion through the OS. If the OS updates aren't installed, what makes you think the same users would faithfully install application updates that aren't handled through the OS update mechanism?
(And FWIW, your figure of 9/10 is very skewed. There are a lot of systems out there that aren't up to date, yes, but it's nowhere near 9/10. The ones that are up-to-date don't come in for repair anywhere near as often, so you're getting an inherently biased sample. If I had to guesstimate, I would say the percentage of Windows systems that are months out of date is more like 3/10 or so, but that's a very loose approximation.)
But the best setup is for application updates to be centralized in one place and handled by a mechanism provided by the operating system. Then the user (or sysadmin) only has to manage it (e.g., tell it what time of day to do udpates) in one place. Only one process is doing update-checks, so you don't have umpteen different update-checkers running in the background degrading system performance. Permission to install stuff in places the user doesn't have write privs doesn't have to be granted to every application's separate update mechanism. And so on.
Ideally, whenever the system administrator installs software, the installation mechanism should inform the operating system (through a provided API) as to where the updates for this application can be found, and one or more public keys that can be used to check their authenticity, and then from then on the OS ought to automatically check for updates for that app and install them when they become available. (Most apps would probably just give one public key and sign updates once, but paranoid developers could have multiple people sign their updates with multiple keys, to prevent the compromise of one key from compromising the whole process.)
I don't know of any OS that handles this in this manner right now. IE is only included in Automatic Updates because Microsoft views it as part of Windows, and even Microsoft Update only handles Microsoft products. Non-Microsoft products are totally on their own for updates. Apple's no better about this. Most Linux distributions do security updates for all the software in the distribution, but if you install any third-party software (not just proprietary stuff, but also any open-source software that the distro does not include for whatever reason) it's on its own for updates. This is not ideal.
> Firefox updates upon the point of relaunch. There is no need to restart windows.
Windows users are accustomed to having the computer restart for no reason all the time. I don't think one more restart is really going to matter much. And it happens automatically, so the user doesn't have to *do* anything.
Actually, having the update mechanism built into the OS is superior, because it can happen even if the logged-in user doesn't have the privileges needed to update the browser. The Firefox update mechanism actually doesn't work in that situation at all. (Well, it can still update the user's browser add-ons...) If the user never logs in except to a limited user account, IE will still get updated; Firefox won't. Ever.
Don't get me wrong, I'm not a big Microsoft fan. But this is something they actually got *right*. Debian does the same thing: iceweasel security updates are handled through the normal apt update mechanism, same as security updates for any other part of the system.
> Tools such as the La Susana and the Iron Maiden make it much more interesting.
You can also use car dealership commercials. After about eighty hours of nonstop back-to-back car dealership commercials, the subject begins to lose mental control. That's when you send in the whining children...
> the web content worth reading, slashdot included, are well above that.
You're joking, right?
I would have estimated the reading level on slashdot, on a good day, at about third grade, roughly at the same difficulty level with such childhood favorites as The Wizard in the Tree, The Voyage of the Dawn Treader, and The Adventures of Tom Sawyer.
By ninth grade you're supposed to be able to read Shakespeare.
> I am sure most admins didn't set policies about .wri attachments like they did for .doc stuff either.
The truly paranoid admins who have free reign to do what they want (because their bosses respect their judgment and/or are afraid of them) generally have the mail servers set up to strip email of all attachments and, indeed, everything that's not plain text. (In extreme BOFH cases the attachments go into the bit bucket, and in other cases they are set aside and can be retrieved somehow if they turn out to actually be needed, e.g., you go to the IT guy and say, "Hey, I'm supposed to be getting a quote from B2BCorp for a new high-speed electric paperclip dispenser", and the IT guy finds that one and marks it for delivery.)
Most systems, however, allow Office-format attachments, because all bosses universally think they need to get those.
> > This information is in the article, BTW.
> In the what, now?
In the TFA article. You're probably accustomed to people just calling it the TFA, but they mean the TFA article. Similarly, when these people talk about software programs, they usually just call them "software", but it means the same thing. Some people just like to shorten and abbreviate everything.
> Yeah, but it changes them to DOS format when you save, with no option to keep the UNIX line endings :(
Why would you want to? All the Unix software these days understands both formats, so if you've got data that you work with on both kinds of systems, proper ASCII carriage-return/line-feed pairs are the way to go. Not only can you open your files in Notepad then, but you can also send them directly to an ASCII printer without any special drivers or interpretation. (Granted, more and more printers these days expect Postscript, PCL, JetDirect, RPCS, or somesuch instead of ASCII. But there are still a few ASCII printers around, and they tend to be fast and efficient for printing large amounts of plain-text data.)
Besides, bad music isn't the best torture. They should have used car dealership commercials.
> You probably wouldn't want to, but you'd have to do what the NSA guys told you.
> And why would they want to sniff on my IP? Dunno, maybe just because my name
> is Middle Eastern (it's not, but let's assume that it was, for the sake of argument)?
I don't think you have any conception of how big the world is or how many people there are in it.
There are at least half a dozen people with Middle-Eastern names that I know about in the city where I live, a city of only about twelve thousand people, in central Ohio, so that's about 0.05% of the population. Assuming this is anything like typical (and if anything it's probably a lowball figure), if the NSA wanted to read all the email of everybody with Middle-Eastern-sounding names nationwide, they would have to employ *thousands* of people, full-time, to do nothing else but that.
Make no mistake, if the authorities do decide to watch *you*, personally, in particular, they would obviously try to do stuff like read your email and listen to your phone calls. But you or someone close to you would have to get their attention in some especial way, because they do *NOT* have enough time or manpower to watch everyone who looks or sounds "Middle Eastern". And if they did have such a program, they would NOT be able to keep it off the news, because when you get that many people doing something like that, some of them are going to talk to the press.
> I care about keeping DNS requests private. I personal would prefer that my ISP can't
> tell where I'm browsing just by grabbing clear-text domain names out of DNS queries.
If your ISP wants to know where you're browsing, they don't need to look at your DNS lookups. In fact, you could put the domain names in your hosts file and never *do* the DNS lookups, and they would still be able to easily know *exactly* where you're browsing. Fundamentally, even if 100% of your traffic is encrypted end-to-end, your ISP still knows where the data is coming from and where it is going. They have to, in order to pass it along to the correct destination. They can also trivially determine how *much* data you're getting from any given site. All they've got to do is sniff the IP headers, which is pretty easy really, and it's fairly trivial to set up a filter that displays (or logs) just the ones related to you. From there it's five or six lines of Perl to make some nice graphs showing which sites you visit most often (or get the most data from), and so forth.
Of course, that's assuming they have some special reason to be specifically interested in where *you*, personally, are browsing. Because there's no way this side of eternity that they would ever have time to monitor the browsing habits of any significant percentage of their many, many users, and even if they did somehow magically have a few thousand man hours per week to blow on such a frivolous project, the sheer volume of inane drivel that constitutes most users' web traffic would probably drive the guy doing the monitoring into deep suicidal depression before he happened to stumble across your stuff.
But yeah, if you've sent threatening letters to your ISP's customer service department in which you mentioned that you know where to find bomb instructions on the internet, you need to be aware of the fact that, yes, encryption or no encryption, your ISP does have the ability to watch what sites you're visiting, if they choose to do so.
> [DNSSEC] effective[ly] publishes your entire zone as a side effect.
Can anyone explain why this is undesirable? To my way of thinking, the *purpose* of DNS is to publish this information. That is the whole point.
If you have servers you don't want the public to know about, in the first place you don't give them public-facing IP addresses at all, and you *certainly* don't put their addresses on a public-facing DNS server. (This is why some networks serve different DNS information internally versus what they publish externally.) I don't see how DNSSEC changes that at all.
The issue of acceptably-strong RSA keys being longer than will fit in a single UDP packet is another issue. The thing I don't understand there is why it's so important to avoid using TCP. Practically every other protocol on the internet runs on TCP, except for a couple of high-bandwidth things that don't need to ensure that all the data get through, e.g., VOIP. Why is sending DNS data via TCP undesirable?
If 1024-bit RSA keys are too weak, why not use 16348-bit RSA keys? It's overkill, of course, but in matters of security where it's difficult to quantify *exactly* how much you need, a bit of overkill is generally a good thing, right? I understand why a key that large won't fit in a UDP packet, but I don't see why using a relatively new and untested crypto algorithm is better than using TCP.
I mean, yes, I know that existing clients try UDP first and only send a TCP query if the result they get back indicates that's necessary, so people using old software would initially experience minor delays as the query has to be repeated on the TCP port. But assuming the ISP updates its DNS cache/resolver software in anything resembling a timely fashion, a lot of the extra traffic would only be going that far; the security-aware resolver would know to go ahead and use TCP in the first place when querying any nameserver that gave DNSSEC results last time it was queried. And eventually even the client software would be updated, and the delays we're talking about here are on the order of doubling the amount of time a name lookup takes, which for most things is not a particularly large delay; certainly it's no worse than what CNAME records do, to say nothing of glueless out-of-bailiwick nameservers, and the end user honstly doesn't even *notice* those delays in most cases, because the actual data takes much longer to transfer than the name lookup anyhow.
So what's the big objection to TCP?