There are actually several products like that now.
One is this one, which has USB and eSATA -- it's probably available on other places as well, but who doesn't like ThinkGeek? They don't say the manufacturer, but if I'm reading the photo correctly I think it's "NewWave". It goes for $40. In the ad copy there's a mention of a 1TB limit but I don't know if they really mean that or not.
Another, nicer option (IMO), is this one from NewerTech; they call it the "Voyager Q" if that link dies. It speaks USB, eSATA, and both 400 and 800 Mb/s FireWire. MSRP is $100. It specifically mentions that it's compatible with 2TB and larger drives.
I've seen several other models floating around from various manufacturers (some I think are just re-brandings of the same product ThinkGeek is selling) that are all substantially similar.
I'd be a bit concerned about putting a drive through too many insert/remove cycles -- the internal SATA connector isn't really made for repeated connection and disconnection -- but for backup purposes it's a pretty darn slick idea. I'd been thinking for a while about getting my SCSI tape drive set up and working again, but I think I'm just going to do 2.5" disks instead. Yes, the tapes admittedly last longer, but this assumes you can get the equipment to read them (and DAT was always a bit finicky in this regard). Plus, there's no comparing the sheer volume of media produced; it's a lot easier to take care of a small stack of hard drives (for under $100 you can get an air/water-tight Pelican case and a small media-rated fire safe and keep a few drives secure against just about anything except getting nuked) than it is to try and protect a big stack of tapes.
They may not be able to grow, but they can surely wring a lot of licensing revenue out of their users before the game is up.
That translates into dividends, making their stock a fairly good investment, if you are actually looking for an investment, and not an asset on which to speculate on. ("Investment" refers to buying something for, or in the hopes of, the income stream it generates; "speculation" is buying something in anticipation of a change in its market price so you can sell and make a profit. Although a lot of so-called "investment" today is actually speculation, they are very different activities.)
Microsoft shares might or might not be a good speculative target, but they might be a fairly safe investment if you want income. In all but the most ridiculous scenarios, and much as it pains me to admit it, a whole lot of the world is going to be paying the "Microsoft tax" for a good while to come.
At some point in the future, if the decline and fall of the Redmond Empire becomes more clear, I'd expect their stock to start trading more like a bond that's near maturity. When it becomes clear that the income stream is drying up, its price will start to trend downwards, slowly approaching zero when it's felt there's nothing more to be wrung. (Assuming they don't manage to reinvent themselves as a services company, like IBM, or a finance and holding company, like GE.)
Whether or not their stock is a good investment at any particular time is a complex decision that should take into account the current price it's trading at, plus their expected dividends in the future, compared to the returns gained by investing the same amount in other vehicles.
The companies I've seen that use SQL Server typically do so because they feel it's the only thing their staff understands. Basically, they're "Microsoft shops" where given a choice between an MS and non-MS product, they will choose the Microsoft one by default. In some cases this is because the IT staff truly isn't competent to operate anything that's not covered in a MCSE exam study guide, while in others it's a management decision. (Sometimes I think it's a direct reflection of management's dislike of the IT staff, and a desire to not be reliant on any specialized skills of theirs that can't be replaced in 24 hours with a Monster.com ad.)
In the particular case of SQL Server, I think people feel that it's easier to install and manage than DB2 or Oracle, and has lots of GUI management utilities so you don't have to open up that big, scary command line to do anything. (Granted, both DB2 and Oracle have GUI tools, but I'm talking about perception, not reality.)
Plus, it's sort of a "nobody ever got fired for buying..." situation. If you spec PostgreSQL and there's a security flaw, your ass may be on the line for recommending a "hippy-dippy open source product" (actual PHB quote). But if you push SQL Server and down the line there's a problem, you can always mumble something about white papers and pass the buck in the direction of Microsoft.
The Clipper chip concept, as applied to telephones, had several big issues. First (as someone else points out), the mere existence of Law Enforcement / NSA keys, held somewhere in a vault, is a security risk. Those keys could leak at some point, and then the entire infrastructure is worse than useless.
Second, a lot of privacy-minded, government-distrusting people saw the situation Clipper would create as being worse than having no security at all. At least with insecure POTS phones, people of average intelligence get that they're insecure, and can be eavesdropped on pretty easily by both law enforcement and determined third parties with access to the building wiring closet or telephone company switching center. This leads to a demand for secure-communication products (ranging from free products like PGPfone and Zfone, to devices like the Sectera aimed at commercial users), demand which would not exist in an environment where every phone had a Clipper installed.
Put bluntly, the current situation (where "no security" is the default) allows -- some would say forces -- users who have a mild need for security, for instance just enough to prevent casual interception, to buy aftermarket products. These purchases keep a thriving non-governmental security industry going, and essentially subsidize the relatively small number of people who really need security not only from casual interception but from the government as well.
If you take on premise, as I and a fair number of other people do, that it's a Good Thing to have the ability to communicate without being spied on by your government (this is outside whether you personally actually think you need it, much less take advantage of it; just that the capability is there if you for some reason wanted to), then Clipper would have been a disaster. The only way it looks like a good idea is if you negate completely the value of having communication channels free of government backdoors (or even better, if you consider the elimination of any channels free from government snooping to be a net positive), which if it was borderline defensible in 1994 seems truly insane today.
My suspicion is that they'll implement this in DNS. They'll just fix their servers so that Yahoo's (and whomever else's they choose) webmail interface resolves to their server, where they'll set up a "301 Moved Permanently" pointing to their webmail site. They could of course skip the redirect step, and just point Yahoo to their server directly in DNS, but that gets them a lot closer to actually impersonating Yahoo's service (since it would still say 'yahoo.com' in the address bar).
They could do it via transparent proxies or any number of other means, but using DNS is so easy it borders on trivial, and for unsophisticated users it has the exact same effect.
The upside of this, if you can call it that, is that by using OpenDNS or any other non-Fairpoint DNS server, the spoofing will be avoidable.
Overall I think there are two lessons, if my suspicion about their methods is correct: one, we need to attack this sort of behavior legally; two, in considering the future development of DNS, the existence of hostile ISPs should be taken into account, and where possible, the system should make it difficult or impossible even for a server operator to spoof records to clients.
They did not screw up this time around, at least as far as I can tell.
It looks like the page was scanned, and then areas were redacted by pasting white over them. They look too neat to have been done with scissors and paper, but that's the general look of them: white polygons pasted over various areas on the page. The edges aren't quite square so it's like someone clicked with a mouse to define the vertices, rather than selecting lines. (I.e., they were doing it after rasterization and not before, most likely.)
Then at some point after this, the document was OCRed. Hence, no redacted material in the text layer of the PDF.
You can make out, at least in a few cases, the gist of what was blanked out from context. One of the first big redactions obviously describes the sigint capabilities of the Soviets at the time. Interesting to imagine why they're still concerned about that; someone must think that by knowing what we knew about them at a particular time, you could infer something that would be advantageous...
This is quite true. What you have is a pretty classic collective action problem, both at the level of Certificate Authorities, and at the level of e-business companies (banks, retailers, etc.).
If a CA acts badly, by issuing certificates sloppily, then eventually the public will lose faith in the CA system and move to something else. All CAs will probably perish. Thus it would seem to be in the best interest of each CA to be careful about certificate issuance, and carefully verify all applicants. In the long run this may be true, but in the short run a 'lazy' (or just plain corrupt) CA will profit handsomely by being the easiest Authority to get a certificate from.
Similarly, if you're running a e-business website, you just want to get the cheapest browser-approved certificate you can. All that matters to you, specifically, is that the padlock icon comes on in the user's browser. While the overall security of e-commerce may affect you in the long run, in the short run you just need that icon so that users will trust you as much as they trust your competitor who has one.
The combination of these two incentives is what we have right now: there are a ton of low-cost CAs, who apparently will apparently spit out a certificate with just about anything you want on it, for a few bucks. Although their existence hurts the electronic-commerce ecosystem as a whole, they make out like bandits at everyone else's expense. Or, to put it a little differently, they profit individually while the loss or harm is distributed broadly.
The solution is to eliminate the perverse incentive, by making it less profitable to act in an antisocial (in the sense of 'being harmful to the community at large') way. This would be accomplished if browsers were much more aggressive about pulling CAs from the trusted roots if they were issuing certificates sloppily. Browser developers -- or if they're not interested, some third party that produced a list of "trusted" CAs for them -- should be engaged in continuous, highly adversarial audits of CAs, essentially testing them to ensure they're following issuance guidelines. If they're not, they need to be immediately dropped from browser roots via security updates. Short of that, I can't see much way of saving the CA system.
The "push" method of financial transactions is definitely the way to go.
Outside the U.S., and particularly in German-speaking Europe, the push system is fairly common even for paper-based transactions. Instead of writing a check -- which is a "demand instrument," basically a pull-initiated transfer -- a merchant gives you a little slip with their account number on it, which you sign and is sent to your bank, which then transfers the money to them. It would not be hard to do this electronically.
Let's say you go to buy something online. On the checkout page, rather than being prompted for your financial information so the merchant can draw against your account, the merchant instead gives you their account info, and some sort of unique transaction identifier. You open a new browser window and go to your bank's page, and enter the amount and transaction ID, then submit the transaction. When the merchant receives the money, they execute your order; if they don't get it within some period of time (24 hours or so), it's simply dropped.
The backend infrastructure exists for this already, in the form of direct deposits. With an ABA routing and account number, you can send money into an account at most banks, but (in theory, if the bank isn't stupid) can't withdraw it; thus there's no harm to a merchant in exposing this information. It's an intrinsically safer model than one where knowing an account number lets you arbitrarily draw money from it, as credit cards do.
Well, I have to admit I was surprised. I hadn't looked at the list of CAs in a while; it seems like the last time I went in there, it only had a handful of entries in it. (Verisign, Thawte, maybe a couple of others.)
I'm giving some very serious thought right now to just deleting every company on that list that I haven't heard of, or that I don't think has enough of a profile to be seriously harmed by allegations of sloppy issuing. Although from some other comments in the thread it sounds like even the big-name CAs have been lazy for years and haven't gotten called on it.
Having a bunch of Turkish CAs in my trusted root doesn't seem like it adds much in the way of security; the chances of me accessing a site that's legitimately using a cert from them -- near zero -- seems significantly lower than someone taking advantage of them to create a fake cert for my bank. (Not necessarily because their security is worse than a US-based CA, but just because while there's a chance someone at the US CA might have heard of my bank and think that it's funny someone's requesting a CA from their domain, I doubt anyone at the Turkish CA would have heard of it. If I were going to get a forged cert, I'd definitely go to a CA where they'd be unfamiliar with the target, just to stack the odds that much more in my favor. So it would seem that only having "local" CAs, ones you're likely to encounter legitimate certs from, in your trust chain is probably a good idea. Someone in Turkey might want to get rid of the minor US certifiers if they don't use them, too.)
Perhaps at some point during the browser-installation process, users should be prompted to select what countries, regions, or jurisdictions they're interested in installing CA certs for. The question could be phrased as "in what countries do you regularly do e-business or use secure web sites?" or something similar. Sure, this would eliminate much of the international market for CAs -- US-based ebusiness sites couldn't shop around for certificates quite as much as they perhaps do now, and vice versa -- but I think that would be significantly better than allowing the whole idea of certificates to be undermined into uselessness.
Of course, maybe that's just rearranging the deck chairs on the Titanic, and the safest thing to do is just throw away the whole paid Certificate Authority concept, blow away all the preinstalled CAs, and then have users build up trust on a per-site basis. This assumes users won't be stupid about what they accept, though, so it's probably doomed from the start.
Is this widely implemented? I've never heard of it before, although I'm by no means claiming any expertise. How does one go about setting it up?
I did some Googling but perhaps I'm searching under the wrong terms; nothing seems to come up besides people mentioning that it exists in the spec. Or is that all that exists right now?
Mostly because it's harder to register.us domains and they're generally more expensive. The pooch really got screwed with the.us TLD; it should have been made cheaper and easier than gTLD domains, but in reality it was the opposite. So rather than local businesses using localized domains ("joespizza.dc.us" or something similar), we got everyone cramming themselves into the gTLD namespace ("joespizza-washington.com") and trying to avoid running into each other.
Ideally, the gTLD namespace should have been slightly more expensive than the.us one, so that businesses and people who didn't need a global presence could focus on their target market and reduce competition at the gTLD level.
Huh? This has nothing to do with network neutrality. This is just caching. People have been doing this for years; Akamai has built its entire business around doing it; Amazon does it; YouTube almost certainly does it; the BBC does it.
The economics of network transit and peering encourage caching: the closer you get content to the end user, the cheaper it is, both in terms of time and actual dollars. (Imagine you're on a pay-per-MB plan; hitting your browser cache is free. Likewise, to your ISP, a cache located somewhere on their network is essentially "free" since it doesn't require them to pay their upstream provided for transfer. And so on up to the backbone providers.)
In some circumstances, edge caches are a win/win both for the content provider and the ISP/user. The user or ISP gets faster response and lower costs, the content provider relieves load on their servers and reduces costs. In the optimal case, ISPs would set up caching systems without being asked, but the systems are complex, and judging by the fact that ISPs don't seem to be falling over themselves to do that, bandwidth must be cheap enough that the cost/benefit isn't quite there.
But if the content provider is willing to pay for the hardware and maintain the caching system, then it suddenly becomes really worthwhile for everyone. The content provider, for the cost of a server (which they'd be running anyway, in their home datacenter), eliminates a big chunk of bandwidth costs and improves performance for users. The ISP eliminates some traffic that they'd have to pay for the transit of, and their users are happier. The only losers in this scenario are the backbone providers, since they have somewhat less traffic going over them -- but they're not going out of business anytime soon (and I suspect the excess capacity gets soaked up with other traffic pretty much immediately).
The only problem would occur if ISPs started offering discriminatory or wildly different terms to different content providers, for setting up edge caches. As long as the deals aren't exclusive (i.e. Google having edge caches doesn't preclude Yahoo from having them as well), there's no threat to neutrality. In fact, even the people not participating in the caching scheme see some benefit, since there's more BW available for their traffic, since it's not contending with billions of hits on Google's front page.
Caching is a Good Thing and it should be encouraged, since it's helpful to the Internet as a whole; the more we can encourage local traffic, the better use we can make out of the backbone infrastructure, and (to put it very broadly) the more things become possible with what we have available at any given time.
I was looking at some old 35mm black-and-white film a few days ago and thinking that it would actually make a pretty nice data storage medium, if you rigged up a machine to write to it. Sort of a "poor man's microfiche."
You'd need to document the hell out of it, but I think it'd be possible to make a data-storage medium that used film, and would last 100 years easily, and be readable with only a very basic system of sensors and light sources.
I was imagining having eight parallel tracks down the film, although you could probably easily fit many more. Depending on the film grain you could probably get hundreds of tracks, and each "bit" would only have to be a few thousandths of an inch wide, depending on the grain of the film stock. You'd just move the film over the write head, and expose it with short pulses; the result would be like a continuous 2-dimensional bar code. (Maybe you'd want to waste one track with timing information? Probably.) Develop it in some nice high-contrast developer (since you only want two tones, black or clear) and then store it as you would any other film. Modern film stock is very stable; in a cool, dry place in a metal tin, it lasts practically forever. (Old celluloid isn't nearly as good, but chemically modern films have very little in common.)
Reading it wouldn't be that different from decoding a big barcode (and it's very similar to the way digital soundtracks on theatre films are written). But even in the absence of any existing hardware, it's the sort of thing I'd bet any undergrad EE with access to a machine shop and electronics lab could come up with in a couple of days. As long as there's no fancy encoding or compression done to the data, you just read it off as quickly or slowly as your equipment allows.
Anyway, it's totally impractical for a personal backup system, of course, but it might not be a completely ridiculous idea for organizations looking for very long-term archival storage. The advantage I think it has, versus other candidates (e.g. magnetic backup tape) is that reading it would be relatively easy and intuitive. Anyone looking at a piece of film with a magnifying glass or microscope would be able to see that there's something there, plus it's a lot harder to wipe accidentally.
This jives with what I've seen. Although I'll add the additional, final step:
7. Someone decides to clean out that closet full of accumulated crap, asks everyone if they know what the "FooBar_02" project was all about, and hearing nothing, throws it away.
If it's stored on hard drives, tapes, or other reusable media, somebody might at this point grab them out of the trash for re-use at home, but if not they just go to the landfill with the rest of the garbage.
Maybe at some point in the future, archaeologists will puzzle over the more well-preserved specimens, wondering how we managed to survive with such crummy software.
They tossed one over Japan a couple of years ago. That means they've solved a lot of the fundamental problems, and what they have left to do is mostly a question of scale and manufacturing ability.
The vast majority of people in North Korea may live like medieval peasants, but that's because their leadership keeps whatever material wealth the country can generate to themselves, or they sink it into arms production. They should not be underestimated.
Since the country is so opaque, I'd think that it's unsafe to assume that they don't have the ability to hit the West Coast already.
Wouldn't the complexity of the hash algorithm grow as you add more entries to the table?
That is, if you have a table with 1000 values, minimally perfectly hashed (so each value has a corresponding integer key, ranging from 1 to 1000), you are going to have a different hashing algorithm than if you have a table with 10000 entries, similarly perfectly hashed. The hash algorithm -- which you have to run on each input value, in order to search it against the table -- would be more complex in the latter case than in the former case.
I'm interested in why this is not true, if it's incorrect, since it seems like the algorithm to determine the minimal perfect hash from an input would vary depending on the size of the MPH array that's being queried. I can see why the actual query once the hashed input is determined would be constant regardless of table size, or even why the lookup would be constant given varying input sizes (although I'd think this would depend on the hash algorithm), but not how you could make lookups against two tables of wildly varying sizes constant.
Being able to do a lookup against a table with a million (or a quadrillion) entries, in the same time as it takes to do a lookup against one with ten, seems suspiciously like a free lunch.
I hope you're joking. But if you're not, there are a ton of reasons why this is a bad idea.
Just off the top of my head: IP addresses don't map 1:1 to web pages, sites, or even to domains. I would bet you anything that right now, the number of web sites is greater than the number of IP addresses currently in use. Allowing this was what HTTP 1.1 and the "Host" header was all about, and that was created back in 1990! If you go and buy space on a web host, it will use an IP address that could potentially be shared with tons of other sites (probably tens, but potentially lots more). Blocking IP addresses, at least IPv4 ones, could have huge collateral damage associated with it, because of all the tricks that have been used to prevent a shortage of addresses.
Also, it would create problems where reverse-proxies (or load balancers) are in use. Same issue for caching systems. There are lots of situations where content might appear to be coming from an IP address where it doesn't really reside.
It'd also be trivially easy to weaponize via forgery: it's not hard to spoof a packet so it looks like it's coming from somewhere besides where it actually originated. This would be a great way to get your enemies zapped, depending on how the information was being fed into the blacklist database to begin with.
And all this is without even getting into the issues that dynamic IPs create: a person could keep a site going for a long time by putting it somewhere where the IP changes frequently, and then updating the DNS record frequently (as lots of free services, e.g. DynDNS, do). Each time an IP address got blocked, they'd just get a new one from the pool, and somebody else would get the now-blacklisted one.
The result of all these things is that an IP-based blocklist wouldn't work, it would take out vast swaths of innocent systems, and it would break key features of the Internet that (although they may be ugly hacks, e.g. in-protocol multiplexing in the style of HTTP 1.1, or NAT) users depend on.
On second thought, it'd be a great idea, and I think it'd be just terrific if Australia gave it a go. Hopefully a very expensive go, such that when it fails they'll never be tempted to such stupidity again.
Taking what you're saying on premise (and I'm not sure I agree with it at all, but setting that aside for a minute), what it suggests to me is that with a Linux-based infrastructure, at least it will be obvious when your staff is over their heads. With a Windows-based one, it won't. That doesn't seem like a feature to me.
I think I'd rather have people say "look, I have no idea how to do this right, I think we should bring somebody in," than try to cookbook their way through it using tools or techniques they really don't understand. I've seen a lot of really ugly and insecure setups come out of the latter school of thought.
Having lots of support from a vendor is great (and Canonical and Red Hat provide a lot on the Linux side, including security updates and patches, so I think your characterization is an unfair strawman to begin with), but it doesn't replace actual competence. If it does, your whole enterprise is living on borrowed time: cruising along, waiting for the moment when something in your setup differs, as it inevitably will, from the assumptions the vendor makes when they're putting together the latest monthly megapatch. And (perhaps more seriously) it puts you at the complete mercy of the vendor's whims, in terms of what they decide is a serious enough problem to enough customers to warrant a fix, and what they're just going to write off as not worth dealing with. Neither are nearly as much of an issue with a competent IT staff who actually understand the underlying infrastructure: both how it works and why it exists in the way that it does.
If a company is having trouble finding or retaining competent technical staff, my first suspicion (and borne out all too frequently) is that they're undervaluing and undercompensating them. Such a business would be wise to consider how important a solid, reliable infrastructure is to their business, and also to keep in mind that IT isn't like shift-work in a factory: one very skilled and properly motivated person can be worth an army of questionably certified button-clickers.
I accidentally chopped out some fairly important information there while editing... let me clarify:
On the client side, I think I'd probably give an edge to Outlook 2003 over Notes 7; the latter was so filled with cruft and unstable, one of the first things you had to add to any computer using it was a little utility that killed all the zombie processes the thing created when it crashed (without it, you'd have to reboot the whole machine before being able to restart Notes!). Outlook, in contrast, has the usual range of obnoxiously Microsoftian, we-know-best behaviors that ignore decades of Internet practice (strange stripping or inserting of LFs from plaintext, stupid quoting behavior, proprietary 'rich text' message format, to name just a few), but all in all it's not a terrible MUA provided you set it up right. I've used worse, anyway.
I'd also like to point out that I haven't used the latest version of Notes, so my comments are limited to versions 7 and previous. I've heard that the latest versions are much improved from a UI standpoint, particularly for users who don't do anything with the "Notes platform" besides use it for email and calendaring, and is actually based of all things on Eclipse (yes, the IDE), but I've not gotten an opportunity to play with it.
To a certain extent (and jokey sig aside), I'd say this is 50% true.
On the client side, I think I'd probably give an edge to Outlook 2003 over Notes 7; the latter was so filled with cruft and unstable, one of the first things you had to add to any computer using it was a little utility that killed all the zombie processes the thing created when it crashed (without it, you'd have to reboot the whole machine before being able to restart Notes!). It has the usual range of obnoxiously Microsoftian, we-know-best behaviors that ignore decades of Internet practice (strange stripping or inserting of LFs from plaintext, stupid quoting behavior, proprietary 'rich text' message format, to name just a few), but all in all it's not a terrible MUA provided you set it up right. I've used worse, anyway.
However, I think the Notes server edges out Exchange, which is a truly dreadful product. It works most of the time, admittedly, but even when I've had it hosted and run by dedicated outsourcers who do nothing but Exchange, I've found it to be a PITA. Its IMAP implementation is terrible and sometimes fills the logs with nonsense when some clients connect to it, under mysterious conditions neither I nor the administrators have ever been able to figure out. Sometimes it chokes on particular messages in users' mailboxes for no apparent reason, spewing errors until the message is hunted down and removed. While Domino can be validly accused of being far overbuilt and over-engineered for what's typically used for (not much more than email), Exchange has always struck me as something of a kludge.
To be honest I'd really rather use neither. They're both attempts at lock-in by particular vendors, and both are difficult to migrate away from once you've started down the path each vendor provides. The major difference is that while IBM seems to be moving in the direction of more openness, standards-compliance, and interoperability, Microsoft seems to be going in the opposite direction (they "de-emphasized" the RFC-compliant WebDAV protocol in Exchange 2007, in favor of the more-proprietary Exchange Web Services). In the very long run I think that open standards (like iCalendar/RFC2445, WebDAV, and iMIP/RFC2447) will displace proprietary messaging and scheduling systems, but it's going to be a long battle. Barring some major change at Microsoft, I suspect they're going to be the ones fighting against that change though, while IBM will be pushing for it. For that reason alone I think Notes is probably a better product when viewed in the long term, and all else being equal.
This is all true, but I suspect that the number of programmer-hours (which is not a good metric of productivity, but it's a pretty good metric of employment) spent writing shrinkwrapped software is dwarfed by the number of hours spent writing custom code for hire.
I don't know if it's still true anymore, but at one point while I was in school, it was taken as established fact that there were more unique programs written in COBOL* than anything else, because of all the stuff that had been written for businesses and the DOD. There's only one Microsoft Excel, but there are thousands of different custom General Ledger systems, and each one needed to be spec'd, designed, and implemented by a team of programmers and analysts.
So while CS undergrads may envision themselves graduating and working on software that's sold by the millions of copies and used by billions, it's much more likely that they'll end up writing code that's sold exactly once and used by a few dozen or hundred people.
With that as a premise, if (and I'm just saying if) there are some languages that tend towards Microsoftian write-once-sell-forever software, and some languages that tend towards software-as-consulting, custom business logic, most undergrads would be well-advised to learn the latter if their goal is steady and comfortable employment.
OS X puts up a warning when you open a document and it begins, as a result of being associated to a particular app, to run a program that you've never used before. If you explicitly launch an application I don't think it warns you; it assumes you know what you're doing. But since opening a document could have the effect of launching an application you didn't mean to open, and this might be non-obvious even if you're a careful user, it warns you if it's never been run before.
I'm not sure it's really meant as a security feature as much as a convenience one -- I typically get it as a result of just having installed some utility that's associated itself with a wide swath of common file types.
Or, more likely, he gets it home and finds he is happy. End of problem.
Doubtful. I've met few enough Windows users that were actually "happy" with their computers, and virtually zero Vista users. As another commenter pointed out, most of them just either blame themselves for the problems, or just think that computers have to be, and inherently are, inconvenient/broken/slow/bloated/fragile, and require periodic 'maintenance' in the form of complete hard-drive wipes to remove accumulated cruft.
I think the most likely scenario is something like: 1) Guy goes to store and gets hustled by salesperson into buying sub-par product, 2) brings computer home, sets it up, is vaguely annoyed at it but doesn't know how to change it, 3) computer slowly "wears out" under increasing loads of crapware and viruses until it's too slow or unstable to use, 4) guy pays nerdiest high-school student he can find to "fix it," 5) student wipes hard drive and installs pirated copy of favorite version of Windows, 6) cycle repeats from #2 until guy throws computer away and buys a new one.
This cycle is the major reason why I suspect, if you asked a representative sample of average people about their feelings with regard to computers, they feel computers have added complication and stress to their lives rather than simplified them.
using meta data or magic number to determine file format would have the same drawback. how would you determine the format of a file at a glance using meta data? you wouldn't have a safe/accurate and intuitive means of determining file type.
I don't think that there is a 100% "safe and accurate" way to display the file type, assuming you are depending on a possibly-hostile file to supply the information in the first place. There are, however, a few things that an operating system can do to make life safer for users:
1) Clearly mark executable files. Have some visual indication whether a file is set to be executable (this, of course, assumes that your operating system has an execute bit; if it doesn't, that's a bigger problem). This indication should be consistent, universal, and impossible to override with metadata or custom icons. It should apply both to CLI shells and GUIs. (Although not necessarily in the exact same way; however my personal preference for such an indicator, which is putting the file name in bold, would work both in a GUI and CLI environment.)
2) Don't use the same action to execute as to open. Using the same action (the double-click) both to "run" and to "open" -- which are two very different actions -- is probably responsible for the vast majority of user-propagated malware today. I would love to see an operating system rigorously enforce a separate 'run' action, so that a user clicking on what appears or claims to be a data file (intending to open an application and read that file) could not accidentally execute it.
3) Break the filesystem into 'data' and 'executable' sections, and bar files on the 'data' sections from being marked as executable under any circumstances. I don't think this would be as effective as #2, but it would probably involve less user retraining. In order for content to be executed, it would have to be copied or installed onto the executable partition (which in normal operation could even be mounted read-only).
You could do all of this with the data-type indicator as part of the file name, or as a separate piece of metadata; it doesn't really matter. There's no 'safety' advantage to doing it either way, it's just that keeping it in the file name is considered very ugly by a lot of people (myself included). I'm personally a fan of the way that the Mac used to do it, with a two part code (one for the file's actual type, the other for the application that either created it or should be used to open it), except that unlike the Mac, it should be easily editable by the user, and a lot of standardization and interoperability challenges would have to be solved. I'll be surprised if I see the filename.ext thing die in my lifetime, honestly. It's just too entrenched.
The "if you can't defend it then it's not yours" trend is a little worrying. There are plenty of countries that would find it rather hard to hold out were they to be invaded by the armies of a western nation, but they are no less sovereign states.
They're exactly as sovereign as the people with the capability to deny them of that allow them to be. Or in other words, they exercise their sovereignty at the pleasure of more powerful countries.
You can say this is 'wrong' all you want, but it is how the world really works.
If a tiny country with an insignificant military presence decided to really aggravate a major power, they would quickly see their sovereignty disappear. Imagine Panama deciding to use its control of the Canal as a weapon against the U.S., for instance; they probably wouldn't remain sovereign for very long, unless someone powerful decided to step in and prevent the U.S. from intervening.
Of course, there's more to retaining sovereignty than purely military power; there's "soft power" as well, in the form of trade, diplomacy, and global goodwill and public support, but it's ultimately an issue of power, not of objective moral correctness.
You can't act this way on an individual level, because the government would come to your house and arrest you. There is no such overarching authority when you are talking about nations; they are truly independent actors. They may act in concert against or in support of one another, but the nature of sovereigns is (practically by definition) that there's no limits to their power except for other sovereigns.
Slashdot Mirror
There are actually several products like that now.
One is this one, which has USB and eSATA -- it's probably available on other places as well, but who doesn't like ThinkGeek? They don't say the manufacturer, but if I'm reading the photo correctly I think it's "NewWave". It goes for $40. In the ad copy there's a mention of a 1TB limit but I don't know if they really mean that or not.
Another, nicer option (IMO), is this one from NewerTech; they call it the "Voyager Q" if that link dies. It speaks USB, eSATA, and both 400 and 800 Mb/s FireWire. MSRP is $100. It specifically mentions that it's compatible with 2TB and larger drives.
I've seen several other models floating around from various manufacturers (some I think are just re-brandings of the same product ThinkGeek is selling) that are all substantially similar.
I'd be a bit concerned about putting a drive through too many insert/remove cycles -- the internal SATA connector isn't really made for repeated connection and disconnection -- but for backup purposes it's a pretty darn slick idea. I'd been thinking for a while about getting my SCSI tape drive set up and working again, but I think I'm just going to do 2.5" disks instead. Yes, the tapes admittedly last longer, but this assumes you can get the equipment to read them (and DAT was always a bit finicky in this regard). Plus, there's no comparing the sheer volume of media produced; it's a lot easier to take care of a small stack of hard drives (for under $100 you can get an air/water-tight Pelican case and a small media-rated fire safe and keep a few drives secure against just about anything except getting nuked) than it is to try and protect a big stack of tapes.
They may not be able to grow, but they can surely wring a lot of licensing revenue out of their users before the game is up.
That translates into dividends, making their stock a fairly good investment, if you are actually looking for an investment, and not an asset on which to speculate on. ("Investment" refers to buying something for, or in the hopes of, the income stream it generates; "speculation" is buying something in anticipation of a change in its market price so you can sell and make a profit. Although a lot of so-called "investment" today is actually speculation, they are very different activities.)
Microsoft shares might or might not be a good speculative target, but they might be a fairly safe investment if you want income. In all but the most ridiculous scenarios, and much as it pains me to admit it, a whole lot of the world is going to be paying the "Microsoft tax" for a good while to come.
At some point in the future, if the decline and fall of the Redmond Empire becomes more clear, I'd expect their stock to start trading more like a bond that's near maturity. When it becomes clear that the income stream is drying up, its price will start to trend downwards, slowly approaching zero when it's felt there's nothing more to be wrung. (Assuming they don't manage to reinvent themselves as a services company, like IBM, or a finance and holding company, like GE.)
Whether or not their stock is a good investment at any particular time is a complex decision that should take into account the current price it's trading at, plus their expected dividends in the future, compared to the returns gained by investing the same amount in other vehicles.
The companies I've seen that use SQL Server typically do so because they feel it's the only thing their staff understands. Basically, they're "Microsoft shops" where given a choice between an MS and non-MS product, they will choose the Microsoft one by default. In some cases this is because the IT staff truly isn't competent to operate anything that's not covered in a MCSE exam study guide, while in others it's a management decision. (Sometimes I think it's a direct reflection of management's dislike of the IT staff, and a desire to not be reliant on any specialized skills of theirs that can't be replaced in 24 hours with a Monster.com ad.)
In the particular case of SQL Server, I think people feel that it's easier to install and manage than DB2 or Oracle, and has lots of GUI management utilities so you don't have to open up that big, scary command line to do anything. (Granted, both DB2 and Oracle have GUI tools, but I'm talking about perception, not reality.)
Plus, it's sort of a "nobody ever got fired for buying..." situation. If you spec PostgreSQL and there's a security flaw, your ass may be on the line for recommending a "hippy-dippy open source product" (actual PHB quote). But if you push SQL Server and down the line there's a problem, you can always mumble something about white papers and pass the buck in the direction of Microsoft.
The Clipper chip concept, as applied to telephones, had several big issues. First (as someone else points out), the mere existence of Law Enforcement / NSA keys, held somewhere in a vault, is a security risk. Those keys could leak at some point, and then the entire infrastructure is worse than useless.
Second, a lot of privacy-minded, government-distrusting people saw the situation Clipper would create as being worse than having no security at all. At least with insecure POTS phones, people of average intelligence get that they're insecure, and can be eavesdropped on pretty easily by both law enforcement and determined third parties with access to the building wiring closet or telephone company switching center. This leads to a demand for secure-communication products (ranging from free products like PGPfone and Zfone, to devices like the Sectera aimed at commercial users), demand which would not exist in an environment where every phone had a Clipper installed.
Put bluntly, the current situation (where "no security" is the default) allows -- some would say forces -- users who have a mild need for security, for instance just enough to prevent casual interception, to buy aftermarket products. These purchases keep a thriving non-governmental security industry going, and essentially subsidize the relatively small number of people who really need security not only from casual interception but from the government as well.
If you take on premise, as I and a fair number of other people do, that it's a Good Thing to have the ability to communicate without being spied on by your government (this is outside whether you personally actually think you need it, much less take advantage of it; just that the capability is there if you for some reason wanted to), then Clipper would have been a disaster. The only way it looks like a good idea is if you negate completely the value of having communication channels free of government backdoors (or even better, if you consider the elimination of any channels free from government snooping to be a net positive), which if it was borderline defensible in 1994 seems truly insane today.
I suspect this is quite right.
My suspicion is that they'll implement this in DNS. They'll just fix their servers so that Yahoo's (and whomever else's they choose) webmail interface resolves to their server, where they'll set up a "301 Moved Permanently" pointing to their webmail site. They could of course skip the redirect step, and just point Yahoo to their server directly in DNS, but that gets them a lot closer to actually impersonating Yahoo's service (since it would still say 'yahoo.com' in the address bar).
They could do it via transparent proxies or any number of other means, but using DNS is so easy it borders on trivial, and for unsophisticated users it has the exact same effect.
The upside of this, if you can call it that, is that by using OpenDNS or any other non-Fairpoint DNS server, the spoofing will be avoidable.
Overall I think there are two lessons, if my suspicion about their methods is correct: one, we need to attack this sort of behavior legally; two, in considering the future development of DNS, the existence of hostile ISPs should be taken into account, and where possible, the system should make it difficult or impossible even for a server operator to spoof records to clients.
They did not screw up this time around, at least as far as I can tell.
It looks like the page was scanned, and then areas were redacted by pasting white over them. They look too neat to have been done with scissors and paper, but that's the general look of them: white polygons pasted over various areas on the page. The edges aren't quite square so it's like someone clicked with a mouse to define the vertices, rather than selecting lines. (I.e., they were doing it after rasterization and not before, most likely.)
Then at some point after this, the document was OCRed. Hence, no redacted material in the text layer of the PDF.
You can make out, at least in a few cases, the gist of what was blanked out from context. One of the first big redactions obviously describes the sigint capabilities of the Soviets at the time. Interesting to imagine why they're still concerned about that; someone must think that by knowing what we knew about them at a particular time, you could infer something that would be advantageous...
This is quite true. What you have is a pretty classic collective action problem, both at the level of Certificate Authorities, and at the level of e-business companies (banks, retailers, etc.).
If a CA acts badly, by issuing certificates sloppily, then eventually the public will lose faith in the CA system and move to something else. All CAs will probably perish. Thus it would seem to be in the best interest of each CA to be careful about certificate issuance, and carefully verify all applicants. In the long run this may be true, but in the short run a 'lazy' (or just plain corrupt) CA will profit handsomely by being the easiest Authority to get a certificate from.
Similarly, if you're running a e-business website, you just want to get the cheapest browser-approved certificate you can. All that matters to you, specifically, is that the padlock icon comes on in the user's browser. While the overall security of e-commerce may affect you in the long run, in the short run you just need that icon so that users will trust you as much as they trust your competitor who has one.
The combination of these two incentives is what we have right now: there are a ton of low-cost CAs, who apparently will apparently spit out a certificate with just about anything you want on it, for a few bucks. Although their existence hurts the electronic-commerce ecosystem as a whole, they make out like bandits at everyone else's expense. Or, to put it a little differently, they profit individually while the loss or harm is distributed broadly.
The solution is to eliminate the perverse incentive, by making it less profitable to act in an antisocial (in the sense of 'being harmful to the community at large') way. This would be accomplished if browsers were much more aggressive about pulling CAs from the trusted roots if they were issuing certificates sloppily. Browser developers -- or if they're not interested, some third party that produced a list of "trusted" CAs for them -- should be engaged in continuous, highly adversarial audits of CAs, essentially testing them to ensure they're following issuance guidelines. If they're not, they need to be immediately dropped from browser roots via security updates. Short of that, I can't see much way of saving the CA system.
The "push" method of financial transactions is definitely the way to go.
Outside the U.S., and particularly in German-speaking Europe, the push system is fairly common even for paper-based transactions. Instead of writing a check -- which is a "demand instrument," basically a pull-initiated transfer -- a merchant gives you a little slip with their account number on it, which you sign and is sent to your bank, which then transfers the money to them. It would not be hard to do this electronically.
Let's say you go to buy something online. On the checkout page, rather than being prompted for your financial information so the merchant can draw against your account, the merchant instead gives you their account info, and some sort of unique transaction identifier. You open a new browser window and go to your bank's page, and enter the amount and transaction ID, then submit the transaction. When the merchant receives the money, they execute your order; if they don't get it within some period of time (24 hours or so), it's simply dropped.
The backend infrastructure exists for this already, in the form of direct deposits. With an ABA routing and account number, you can send money into an account at most banks, but (in theory, if the bank isn't stupid) can't withdraw it; thus there's no harm to a merchant in exposing this information. It's an intrinsically safer model than one where knowing an account number lets you arbitrarily draw money from it, as credit cards do.
Well, I have to admit I was surprised. I hadn't looked at the list of CAs in a while; it seems like the last time I went in there, it only had a handful of entries in it. (Verisign, Thawte, maybe a couple of others.)
I'm giving some very serious thought right now to just deleting every company on that list that I haven't heard of, or that I don't think has enough of a profile to be seriously harmed by allegations of sloppy issuing. Although from some other comments in the thread it sounds like even the big-name CAs have been lazy for years and haven't gotten called on it.
Having a bunch of Turkish CAs in my trusted root doesn't seem like it adds much in the way of security; the chances of me accessing a site that's legitimately using a cert from them -- near zero -- seems significantly lower than someone taking advantage of them to create a fake cert for my bank. (Not necessarily because their security is worse than a US-based CA, but just because while there's a chance someone at the US CA might have heard of my bank and think that it's funny someone's requesting a CA from their domain, I doubt anyone at the Turkish CA would have heard of it. If I were going to get a forged cert, I'd definitely go to a CA where they'd be unfamiliar with the target, just to stack the odds that much more in my favor. So it would seem that only having "local" CAs, ones you're likely to encounter legitimate certs from, in your trust chain is probably a good idea. Someone in Turkey might want to get rid of the minor US certifiers if they don't use them, too.)
Perhaps at some point during the browser-installation process, users should be prompted to select what countries, regions, or jurisdictions they're interested in installing CA certs for. The question could be phrased as "in what countries do you regularly do e-business or use secure web sites?" or something similar. Sure, this would eliminate much of the international market for CAs -- US-based ebusiness sites couldn't shop around for certificates quite as much as they perhaps do now, and vice versa -- but I think that would be significantly better than allowing the whole idea of certificates to be undermined into uselessness.
Of course, maybe that's just rearranging the deck chairs on the Titanic, and the safest thing to do is just throw away the whole paid Certificate Authority concept, blow away all the preinstalled CAs, and then have users build up trust on a per-site basis. This assumes users won't be stupid about what they accept, though, so it's probably doomed from the start.
Is this widely implemented? I've never heard of it before, although I'm by no means claiming any expertise. How does one go about setting it up?
I did some Googling but perhaps I'm searching under the wrong terms; nothing seems to come up besides people mentioning that it exists in the spec. Or is that all that exists right now?
Mostly because it's harder to register .us domains and they're generally more expensive. The pooch really got screwed with the .us TLD; it should have been made cheaper and easier than gTLD domains, but in reality it was the opposite. So rather than local businesses using localized domains ("joespizza.dc.us" or something similar), we got everyone cramming themselves into the gTLD namespace ("joespizza-washington.com") and trying to avoid running into each other.
Ideally, the gTLD namespace should have been slightly more expensive than the .us one, so that businesses and people who didn't need a global presence could focus on their target market and reduce competition at the gTLD level.
Huh? This has nothing to do with network neutrality. This is just caching. People have been doing this for years; Akamai has built its entire business around doing it; Amazon does it; YouTube almost certainly does it; the BBC does it.
The economics of network transit and peering encourage caching: the closer you get content to the end user, the cheaper it is, both in terms of time and actual dollars. (Imagine you're on a pay-per-MB plan; hitting your browser cache is free. Likewise, to your ISP, a cache located somewhere on their network is essentially "free" since it doesn't require them to pay their upstream provided for transfer. And so on up to the backbone providers.)
In some circumstances, edge caches are a win/win both for the content provider and the ISP/user. The user or ISP gets faster response and lower costs, the content provider relieves load on their servers and reduces costs. In the optimal case, ISPs would set up caching systems without being asked, but the systems are complex, and judging by the fact that ISPs don't seem to be falling over themselves to do that, bandwidth must be cheap enough that the cost/benefit isn't quite there.
But if the content provider is willing to pay for the hardware and maintain the caching system, then it suddenly becomes really worthwhile for everyone. The content provider, for the cost of a server (which they'd be running anyway, in their home datacenter), eliminates a big chunk of bandwidth costs and improves performance for users. The ISP eliminates some traffic that they'd have to pay for the transit of, and their users are happier. The only losers in this scenario are the backbone providers, since they have somewhat less traffic going over them -- but they're not going out of business anytime soon (and I suspect the excess capacity gets soaked up with other traffic pretty much immediately).
The only problem would occur if ISPs started offering discriminatory or wildly different terms to different content providers, for setting up edge caches. As long as the deals aren't exclusive (i.e. Google having edge caches doesn't preclude Yahoo from having them as well), there's no threat to neutrality. In fact, even the people not participating in the caching scheme see some benefit, since there's more BW available for their traffic, since it's not contending with billions of hits on Google's front page.
Caching is a Good Thing and it should be encouraged, since it's helpful to the Internet as a whole; the more we can encourage local traffic, the better use we can make out of the backbone infrastructure, and (to put it very broadly) the more things become possible with what we have available at any given time.
I was looking at some old 35mm black-and-white film a few days ago and thinking that it would actually make a pretty nice data storage medium, if you rigged up a machine to write to it. Sort of a "poor man's microfiche."
You'd need to document the hell out of it, but I think it'd be possible to make a data-storage medium that used film, and would last 100 years easily, and be readable with only a very basic system of sensors and light sources.
I was imagining having eight parallel tracks down the film, although you could probably easily fit many more. Depending on the film grain you could probably get hundreds of tracks, and each "bit" would only have to be a few thousandths of an inch wide, depending on the grain of the film stock. You'd just move the film over the write head, and expose it with short pulses; the result would be like a continuous 2-dimensional bar code. (Maybe you'd want to waste one track with timing information? Probably.) Develop it in some nice high-contrast developer (since you only want two tones, black or clear) and then store it as you would any other film. Modern film stock is very stable; in a cool, dry place in a metal tin, it lasts practically forever. (Old celluloid isn't nearly as good, but chemically modern films have very little in common.)
Reading it wouldn't be that different from decoding a big barcode (and it's very similar to the way digital soundtracks on theatre films are written). But even in the absence of any existing hardware, it's the sort of thing I'd bet any undergrad EE with access to a machine shop and electronics lab could come up with in a couple of days. As long as there's no fancy encoding or compression done to the data, you just read it off as quickly or slowly as your equipment allows.
Anyway, it's totally impractical for a personal backup system, of course, but it might not be a completely ridiculous idea for organizations looking for very long-term archival storage. The advantage I think it has, versus other candidates (e.g. magnetic backup tape) is that reading it would be relatively easy and intuitive. Anyone looking at a piece of film with a magnifying glass or microscope would be able to see that there's something there, plus it's a lot harder to wipe accidentally.
This jives with what I've seen. Although I'll add the additional, final step:
7. Someone decides to clean out that closet full of accumulated crap, asks everyone if they know what the "FooBar_02" project was all about, and hearing nothing, throws it away.
If it's stored on hard drives, tapes, or other reusable media, somebody might at this point grab them out of the trash for re-use at home, but if not they just go to the landfill with the rest of the garbage.
Maybe at some point in the future, archaeologists will puzzle over the more well-preserved specimens, wondering how we managed to survive with such crummy software.
They tossed one over Japan a couple of years ago. That means they've solved a lot of the fundamental problems, and what they have left to do is mostly a question of scale and manufacturing ability.
The vast majority of people in North Korea may live like medieval peasants, but that's because their leadership keeps whatever material wealth the country can generate to themselves, or they sink it into arms production. They should not be underestimated.
Since the country is so opaque, I'd think that it's unsafe to assume that they don't have the ability to hit the West Coast already.
Wouldn't the complexity of the hash algorithm grow as you add more entries to the table?
That is, if you have a table with 1000 values, minimally perfectly hashed (so each value has a corresponding integer key, ranging from 1 to 1000), you are going to have a different hashing algorithm than if you have a table with 10000 entries, similarly perfectly hashed. The hash algorithm -- which you have to run on each input value, in order to search it against the table -- would be more complex in the latter case than in the former case.
I'm interested in why this is not true, if it's incorrect, since it seems like the algorithm to determine the minimal perfect hash from an input would vary depending on the size of the MPH array that's being queried. I can see why the actual query once the hashed input is determined would be constant regardless of table size, or even why the lookup would be constant given varying input sizes (although I'd think this would depend on the hash algorithm), but not how you could make lookups against two tables of wildly varying sizes constant.
Being able to do a lookup against a table with a million (or a quadrillion) entries, in the same time as it takes to do a lookup against one with ten, seems suspiciously like a free lunch.
I hope you're joking. But if you're not, there are a ton of reasons why this is a bad idea.
Just off the top of my head: IP addresses don't map 1:1 to web pages, sites, or even to domains. I would bet you anything that right now, the number of web sites is greater than the number of IP addresses currently in use. Allowing this was what HTTP 1.1 and the "Host" header was all about, and that was created back in 1990! If you go and buy space on a web host, it will use an IP address that could potentially be shared with tons of other sites (probably tens, but potentially lots more). Blocking IP addresses, at least IPv4 ones, could have huge collateral damage associated with it, because of all the tricks that have been used to prevent a shortage of addresses.
Also, it would create problems where reverse-proxies (or load balancers) are in use. Same issue for caching systems. There are lots of situations where content might appear to be coming from an IP address where it doesn't really reside.
It'd also be trivially easy to weaponize via forgery: it's not hard to spoof a packet so it looks like it's coming from somewhere besides where it actually originated. This would be a great way to get your enemies zapped, depending on how the information was being fed into the blacklist database to begin with.
And all this is without even getting into the issues that dynamic IPs create: a person could keep a site going for a long time by putting it somewhere where the IP changes frequently, and then updating the DNS record frequently (as lots of free services, e.g. DynDNS, do). Each time an IP address got blocked, they'd just get a new one from the pool, and somebody else would get the now-blacklisted one.
The result of all these things is that an IP-based blocklist wouldn't work, it would take out vast swaths of innocent systems, and it would break key features of the Internet that (although they may be ugly hacks, e.g. in-protocol multiplexing in the style of HTTP 1.1, or NAT) users depend on.
On second thought, it'd be a great idea, and I think it'd be just terrific if Australia gave it a go. Hopefully a very expensive go, such that when it fails they'll never be tempted to such stupidity again.
Taking what you're saying on premise (and I'm not sure I agree with it at all, but setting that aside for a minute), what it suggests to me is that with a Linux-based infrastructure, at least it will be obvious when your staff is over their heads. With a Windows-based one, it won't. That doesn't seem like a feature to me.
I think I'd rather have people say "look, I have no idea how to do this right, I think we should bring somebody in," than try to cookbook their way through it using tools or techniques they really don't understand. I've seen a lot of really ugly and insecure setups come out of the latter school of thought.
Having lots of support from a vendor is great (and Canonical and Red Hat provide a lot on the Linux side, including security updates and patches, so I think your characterization is an unfair strawman to begin with), but it doesn't replace actual competence. If it does, your whole enterprise is living on borrowed time: cruising along, waiting for the moment when something in your setup differs, as it inevitably will, from the assumptions the vendor makes when they're putting together the latest monthly megapatch. And (perhaps more seriously) it puts you at the complete mercy of the vendor's whims, in terms of what they decide is a serious enough problem to enough customers to warrant a fix, and what they're just going to write off as not worth dealing with. Neither are nearly as much of an issue with a competent IT staff who actually understand the underlying infrastructure: both how it works and why it exists in the way that it does.
If a company is having trouble finding or retaining competent technical staff, my first suspicion (and borne out all too frequently) is that they're undervaluing and undercompensating them. Such a business would be wise to consider how important a solid, reliable infrastructure is to their business, and also to keep in mind that IT isn't like shift-work in a factory: one very skilled and properly motivated person can be worth an army of questionably certified button-clickers.
I accidentally chopped out some fairly important information there while editing ... let me clarify:
I'd also like to point out that I haven't used the latest version of Notes, so my comments are limited to versions 7 and previous. I've heard that the latest versions are much improved from a UI standpoint, particularly for users who don't do anything with the "Notes platform" besides use it for email and calendaring, and is actually based of all things on Eclipse (yes, the IDE), but I've not gotten an opportunity to play with it.
To a certain extent (and jokey sig aside), I'd say this is 50% true.
On the client side, I think I'd probably give an edge to Outlook 2003 over Notes 7; the latter was so filled with cruft and unstable, one of the first things you had to add to any computer using it was a little utility that killed all the zombie processes the thing created when it crashed (without it, you'd have to reboot the whole machine before being able to restart Notes!). It has the usual range of obnoxiously Microsoftian, we-know-best behaviors that ignore decades of Internet practice (strange stripping or inserting of LFs from plaintext, stupid quoting behavior, proprietary 'rich text' message format, to name just a few), but all in all it's not a terrible MUA provided you set it up right. I've used worse, anyway.
However, I think the Notes server edges out Exchange, which is a truly dreadful product. It works most of the time, admittedly, but even when I've had it hosted and run by dedicated outsourcers who do nothing but Exchange, I've found it to be a PITA. Its IMAP implementation is terrible and sometimes fills the logs with nonsense when some clients connect to it, under mysterious conditions neither I nor the administrators have ever been able to figure out. Sometimes it chokes on particular messages in users' mailboxes for no apparent reason, spewing errors until the message is hunted down and removed. While Domino can be validly accused of being far overbuilt and over-engineered for what's typically used for (not much more than email), Exchange has always struck me as something of a kludge.
To be honest I'd really rather use neither. They're both attempts at lock-in by particular vendors, and both are difficult to migrate away from once you've started down the path each vendor provides. The major difference is that while IBM seems to be moving in the direction of more openness, standards-compliance, and interoperability, Microsoft seems to be going in the opposite direction (they "de-emphasized" the RFC-compliant WebDAV protocol in Exchange 2007, in favor of the more-proprietary Exchange Web Services). In the very long run I think that open standards (like iCalendar/RFC2445, WebDAV, and iMIP/RFC2447) will displace proprietary messaging and scheduling systems, but it's going to be a long battle. Barring some major change at Microsoft, I suspect they're going to be the ones fighting against that change though, while IBM will be pushing for it. For that reason alone I think Notes is probably a better product when viewed in the long term, and all else being equal.
This is all true, but I suspect that the number of programmer-hours (which is not a good metric of productivity, but it's a pretty good metric of employment) spent writing shrinkwrapped software is dwarfed by the number of hours spent writing custom code for hire.
I don't know if it's still true anymore, but at one point while I was in school, it was taken as established fact that there were more unique programs written in COBOL* than anything else, because of all the stuff that had been written for businesses and the DOD. There's only one Microsoft Excel, but there are thousands of different custom General Ledger systems, and each one needed to be spec'd, designed, and implemented by a team of programmers and analysts.
So while CS undergrads may envision themselves graduating and working on software that's sold by the millions of copies and used by billions, it's much more likely that they'll end up writing code that's sold exactly once and used by a few dozen or hundred people.
With that as a premise, if (and I'm just saying if) there are some languages that tend towards Microsoftian write-once-sell-forever software, and some languages that tend towards software-as-consulting, custom business logic, most undergrads would be well-advised to learn the latter if their goal is steady and comfortable employment.
* As unique as a COBOL program gets, of course. ;)
OS X puts up a warning when you open a document and it begins, as a result of being associated to a particular app, to run a program that you've never used before. If you explicitly launch an application I don't think it warns you; it assumes you know what you're doing. But since opening a document could have the effect of launching an application you didn't mean to open, and this might be non-obvious even if you're a careful user, it warns you if it's never been run before.
I'm not sure it's really meant as a security feature as much as a convenience one -- I typically get it as a result of just having installed some utility that's associated itself with a wide swath of common file types.
Doubtful. I've met few enough Windows users that were actually "happy" with their computers, and virtually zero Vista users. As another commenter pointed out, most of them just either blame themselves for the problems, or just think that computers have to be, and inherently are, inconvenient/broken/slow/bloated/fragile, and require periodic 'maintenance' in the form of complete hard-drive wipes to remove accumulated cruft.
I think the most likely scenario is something like: 1) Guy goes to store and gets hustled by salesperson into buying sub-par product, 2) brings computer home, sets it up, is vaguely annoyed at it but doesn't know how to change it, 3) computer slowly "wears out" under increasing loads of crapware and viruses until it's too slow or unstable to use, 4) guy pays nerdiest high-school student he can find to "fix it," 5) student wipes hard drive and installs pirated copy of favorite version of Windows, 6) cycle repeats from #2 until guy throws computer away and buys a new one.
This cycle is the major reason why I suspect, if you asked a representative sample of average people about their feelings with regard to computers, they feel computers have added complication and stress to their lives rather than simplified them.
I don't think that there is a 100% "safe and accurate" way to display the file type, assuming you are depending on a possibly-hostile file to supply the information in the first place. There are, however, a few things that an operating system can do to make life safer for users:
1) Clearly mark executable files. Have some visual indication whether a file is set to be executable (this, of course, assumes that your operating system has an execute bit; if it doesn't, that's a bigger problem). This indication should be consistent, universal, and impossible to override with metadata or custom icons. It should apply both to CLI shells and GUIs. (Although not necessarily in the exact same way; however my personal preference for such an indicator, which is putting the file name in bold, would work both in a GUI and CLI environment.)
2) Don't use the same action to execute as to open. Using the same action (the double-click) both to "run" and to "open" -- which are two very different actions -- is probably responsible for the vast majority of user-propagated malware today. I would love to see an operating system rigorously enforce a separate 'run' action, so that a user clicking on what appears or claims to be a data file (intending to open an application and read that file) could not accidentally execute it.
3) Break the filesystem into 'data' and 'executable' sections, and bar files on the 'data' sections from being marked as executable under any circumstances. I don't think this would be as effective as #2, but it would probably involve less user retraining. In order for content to be executed, it would have to be copied or installed onto the executable partition (which in normal operation could even be mounted read-only).
You could do all of this with the data-type indicator as part of the file name, or as a separate piece of metadata; it doesn't really matter. There's no 'safety' advantage to doing it either way, it's just that keeping it in the file name is considered very ugly by a lot of people (myself included). I'm personally a fan of the way that the Mac used to do it, with a two part code (one for the file's actual type, the other for the application that either created it or should be used to open it), except that unlike the Mac, it should be easily editable by the user, and a lot of standardization and interoperability challenges would have to be solved. I'll be surprised if I see the filename.ext thing die in my lifetime, honestly. It's just too entrenched.
The "if you can't defend it then it's not yours" trend is a little worrying. There are plenty of countries that would find it rather hard to hold out were they to be invaded by the armies of a western nation, but they are no less sovereign states.
They're exactly as sovereign as the people with the capability to deny them of that allow them to be. Or in other words, they exercise their sovereignty at the pleasure of more powerful countries.
You can say this is 'wrong' all you want, but it is how the world really works.
If a tiny country with an insignificant military presence decided to really aggravate a major power, they would quickly see their sovereignty disappear. Imagine Panama deciding to use its control of the Canal as a weapon against the U.S., for instance; they probably wouldn't remain sovereign for very long, unless someone powerful decided to step in and prevent the U.S. from intervening.
Of course, there's more to retaining sovereignty than purely military power; there's "soft power" as well, in the form of trade, diplomacy, and global goodwill and public support, but it's ultimately an issue of power, not of objective moral correctness.
You can't act this way on an individual level, because the government would come to your house and arrest you. There is no such overarching authority when you are talking about nations; they are truly independent actors. They may act in concert against or in support of one another, but the nature of sovereigns is (practically by definition) that there's no limits to their power except for other sovereigns.