Of course, this makes it rather problematic to print from Linux or any other uncontrolled OS.
Or Windows. Unless you think Palladium will ever be an effective system?;-)
or receive their data in some semi-low resolution full page view
It's a pretty good bet that it's easy to hack even binary-only drivers to feed garbage as a preview.
But I can't give five bucks to my roommate with a credit card, a smart card, or anything else -- except maybe a check.
Currently, the reason for this is because vendor fees for credit cards are so high. Paypay, for instance, lets you transfer funds to said roommate.
This is caused by:
* Fraud: massively reduced with smartcards.
* Processing costs: Massively reduced with smartcards (less human interaction necessary, fraud detection and resolution reduced, trusted local logs of transactions may be kept rather than sending out CC bills, etc)
* Until now, widespread data network access was rare and expensive -- the CC network evolved when many vendors had to make a phone call (well, with a modem) to authorize each number. This is no longer the case, especially with wireless Ethernet and digital cell phones. Hell, your cell phone can act as a smart card/smart card reader these days.
Your censorship system is based upon authenticating websites as either "pedophile or non-pedophile". This elicits the following response:
This is an idea for an authentication system or system containing an authentication system. Your idea will not work. This is because it:
[ ] Fails to establish a trustable connection to its end-user. [ ] Fails to establish a trustable connection from the end-user
interface to a system with knowledge to do the authentication. [ ] Fails to contain a system that may be trusted. [X] Is not finely-grained enough to distinguish between some entities
that should pass authentication and some that shouldn't. [ ] Exposes data that should not be exposed. [X] May be easily DoSed. [ ] Will not be accepted by government. [ ] Will not be accepted by end users. [X] Has an unacceptable degree of false positives. [X] Has an unacceptable degree of false negatives. [ ] Prevents operation of necessary functionality. [ ] Has the potential to fail catastrophically. [ ] Is too hard to implement.
Specifically, your suggestion fails to account for:
[ ] Providing a *trustable* store for the system's authentication data. [ ] Brute-force attacks. [ ] The fact that IP packet source addresses may be trivially forged. [ ] The fact that everyone within the population must use this system
properly to keep it working properly. [ ] The fact that it requires end-users to go through more effort than
they will be willing to undertake to use it. [ ] Security breeches may not be easily repaired. [ ] CPU power available to attack your solution. [ ] Laws prohibiting implementation of your solution. [ ] Asshats. [ ] Limited human memory. [ ] Small/portable devices. [ ] Willingness of the entity being authenticated to to ignore
authentication failures. [ ] Windows. [X] Willingness of users to bypass authentication systems. [X] Ability of technically skilled hackers to distribute easy-to-use
attacks on the system. [ ] User resistance to social change. [ ] Allowing entities other than the authenticating entity to
determine associations between multiple identities that should be
unassociated. [ ] Your blacklists do not scale to the necessary size. [ ] The need for implementation to be phased in. [X] Tainted authentication databases. [X] Unclear criteria involved. [X] Inexpensive creation of new identities.
And the following philosophical objections may also apply:
[ ] Attempts to establish an artificial monopoly. [X] Ideas similar to yours are easy to come up with, yet none have ever been shown practical. [X] Any system that allows complete government monitoring of behavior is
unacceptable. [X] Any system that allows complete corporate monitoring of behavior is
unacceptable. [ ] Authentication systems should use technical solutions rather than
legislative solutions. [ ] Biometrics suck. [X] Why should we have to trust you and your servers? [ ] Incompatibility with open source or open source licenses. [X] Feel-good measures do nothing to solve the problem. [X] I don't want people monitoring me. [X] Censorship sucks, and there are better things you could be doing
with your time. [X] I don't need to break your system, because there are easier ways
around it. [X] This system may be abused horribly by those operating it.
Furthermore, this is what I think about you:
[ ] Sorry dude, but I don't think it would work. [X] This is a stupid idea, and you're a stupid person for suggesting
it. [ ] If you had bothered to ask anyone with any security knowledge
first, your idea would have been immediately shot down.
This is an idea for an authentication system or system containing an authentication system. Your idea will not work. This is because it:
[ ] Fails to establish a trustable connection to its end-user. [ ] Fails to establish a trustable connection from the end-user
interface to a system with knowledge to do the authentication. [X] Fails to contain a system that may be trusted. [ ] Is not finely-grained enough to distinguish between some entities
that should pass authentication and some that shouldn't. [ ] Exposes data that should not be exposed. [X] May be easily DoSed. [ ] Will not be accepted by government. [X] Will not be accepted by end users. [X] Has an unacceptable degree of false positives. [ ] Has an unacceptable degree of false negatives. [ ] Prevents operation of necessary functionality. [ ] Has the potential to fail catastrophically. [ ] Is too hard to implement.
Specifically, your suggestion fails to account for:
[ ] Providing a *trustable* store for the system's authentication data. [ ] Brute-force attacks. [X] The fact that IP packet source addresses may be trivially forged. [ ] The fact that everyone within the population must use this system
properly to keep it working properly. [ ] The fact that it requires end-users to go through more effort than
they will be willing to undertake to use it. [X] Security breeches may not be easily repaired. [ ] CPU power available to attack your solution. [ ] Laws prohibiting implementation of your solution. [X] Asshats. [ ] Limited human memory. [ ] Small/portable devices. [ ] Willingness of the entity being authenticated to to ignore
authentication failures. [ ] Windows. [ ] Willingness of users to bypass authentication systems. [ ] Ability of technically skilled hackers to distribute easy-to-use
attacks on the system. [ ] User resistance to social change. [ ] Allowing entities other than the authenticating entity to
determine associations between multiple identities that should be
unassociated. [ ] Your blacklists do not scale to the necessary size. [ ] The need for implementation to be phased in. [X] Tainted authentication databases.
And the following philosophical objections may also apply:
[ ] Attempts to establish an artificial monopoly. [X] Ideas similar to yours are easy to come up with, yet none have ever been shown practical. [ ] Any system that allows complete government monitoring of behavior is
unacceptable. [ ] Any system that allows complete corporate monitoring of behavior is
unacceptable. [ ] Authentication systems should use technical solutions rather than
legislative solutions. [ ] Biometrics suck. [X] Why should we have to trust you and your servers? [ ] Incompatibility with open source or open source licenses. [X] Feel-good measures do nothing to solve the problem. [ ] I don't want people monitoring me.
Furthermore, this is what I think about you:
[ ] Sorry dude, but I don't think it would work. [ ] This is a stupid idea, and you're a stupid person for suggesting
it. [X] If you had bothered to ask anyone with any security knowledge
first, your idea would have been immediately shot down.
I find it wildly frusterating that there is so much deployed non-smartcard hardware in the US. The antifraud benefits help just about everyone involved (customer doesn't have to worry about his CC data being ripped off and monitoring his bill, the vendor doesn't have to worry about eating fraud losses, the CC vendor doesn't have to worry about hassling with pissed off users and vendors and fraud detection/processing).
Any time a credit card is used, a smart card is almost unilaterally a better choice.
There are a number of problems with adding such code to printers:
* It is difficult to update. All counterfeiters have to do is find *one* image that can get past the blocking code. Futhermore, there is a *huge* set of printers out there that have no such blocking.
* Printers have limited memory and CPU capabilities. I really think that HP will not be thrilled with blowing a bunch of each on doing "currency detection" on every chunk of every page for each country that latches onto this.
* Printers have only the ability to "block". "Blocking" penalties for a detection of counterfeiting is the *easiest* variety of protection, since people just poke at their images until they print. Photoshop or other can "phone home". Some folks might think ahead enough to have a fully-disconnected computer, but as network connectivity grows...and it only takes one "phone home" with a detected serial number of a page of bills that are showing up with bogus numbers to nail someone.
* Printers were never designed to be highly secure embedded devices (for example, a number have easily-replaced firmware slots). It's a good bet that printer manufacturers don't go to a lot of trouble to hide diagnostic data. Sure, no random counterfeiter might be able to crack such a system -- but (a) there's lots of money involved to hire such a geek, and (b) there are major "geek points" involved in figuring out how to break such a system, and legitimate reasons for doing so. Remember the Xbox -- yes, it was cracked so that people could put Linux on it, but it opens things up to piracy. What if people want to improve image quality, add their own rendering engines (because it's not like they can easily build modern printers in their basement)? When someone distributes detailed instructions for how to disable such protection, it won't take a brilliant counterfeiter to beat the thing.
I really think that this is more a case of "we need to do something new with our currency". Currency was designed in a day and age when it was hard to accurately reproduce detailed images on a piece of paper. It was a very good design for that environment. I think that if we had to come up with a new system, we'd have something wildly different today.
You know what *could* make a major improvement?
Smart cards replacing "stupid magnetic strip" credit cards.
Currently, the reason that you can't use credit cards everywhere is because the credit card companies rake in money on each card, and it imposes overhead that not every retailer wants to pay (in vendor fees and per-charge costs).
Smart cards (with *associated readers*) make credit card fraud much more difficult, and thus reduce credit card company costs, and ultimately reduce prices to retailers.
This will help produce smart cards be more commonly used.
Of course, the downside is the big credit card issue -- more easy tracking of money flow, which is a bit Orwellian. Technically, it's possible to build a system that doesn't track fund flows (and still has the hard-to-counterfeit benefits), even if your credit card vendor is malicious, but there is probably little public interest in such a property. Plus, given the commercial value of people's credit card records (and pressure from law enforcement to monitor them) I don't think that it will happen.
It may not be what you're thinking of, but there is a genre of games in which there are not infrequently (in the good specimens) multiple ways to solve problems -- good old text-based interactive fiction. Some of these are quite clever.
Of course, they lack the twitch element, and they won't use your new $300 video card, but when it comes to sophisticated game paths, there are few other genres on par with this one.
I've been very pleased that Microsoft has found such incompetent PR people (Mr. McBride and Mr. Brown) to push Linux as bad for business. I mean, I worried for a while that Linux advocates might be using flawed, emotional arguments, and that their competitors might be presenting moe reasonable arguments -- however, the two have really made the anti-Linux front come off as rather stupid and dishonest.
I mean, seriously, *surely* Microsoft could find someone like the EFF's Eben Moglen, a lawyer who actually understands technology and doesn't have a habit of promulgating bullshit, to try to tear at the GPL's weak points. Instead, whoever is responsible for propaganda and PR at Microsoft has chosen the biggest bunch of chowderheads I've ever seen.
Seriously, if Microsoft had *immediately* gotten a couple of major tech companies to make frequent anti-Linux statements (SGI and Sun would have been great choices) and bought off some comptent people (who might have come off as being paid off by Microsoft, but could *still* have had vaguely reasonable arguments against Linux), they might have had a decent set of anti-Linux PR. Instead, they've consistently done an *awful* job.
Microsoft seriously blew the PR aspect of fighting Open Source. I'm very curious to see what their next move is.
If they start getting hammered, I'm going to assume that they pull out their patent portfolio. If I were them, I'd be making a *long* list of patents (including bogus ones) and going after Open Source projects. How many Open Source developers have the money to fight a lawsuit, or the $2.5K-$20K required to request a patent reexamination from the USPTO?
Furthermore, the social side effects of such a move would be wonderful for Microsoft. Open Source workers would be increasingly polarized against intellectual property law (which makes for *wonderful* PR). Any projects that are stopped serve as both PR and the practical elimination of a competitor. Any projects that continue (especially if they make arguments about not caring about "bullshit patents") can be used as examples of Open Source disregard for intellectual property and easily sued -- Microsoft has far more money to play with legal tactics than a small subset of open source developers do, even with OSDL/EFF/Red Hat backing (and a desperate Microsoft will probably commit more money than a less upset IBM -- especially an IBM with their own large collection of patents, some of which are surely bogus).
If I were Ken Brown, here's what I'd do to make a plausible case. I'd start identifying Microsoft patents (there are a lot to work with) and sending letters to open source developers. They don't even have to be project leads, but members of important projects would look nice. *Then* I'd send out letters saying "It looks like you're infrining on this patent", and quoting out-of-context bits of developer responses. Ken Brown wants to make a case against generally ethical and honest people, and do to that, he needs to exploit irrationality or incorrect beliefs. A good one is the current US patent system, which is generally believed to be excellent, but is actually fairly broken. By saying "there's a patent against this, and you can't make this", he has an *excellent* set of attacks against software.
As an even bigger benefit, Microsoft doesn't need to look like a bad guy (sending out patent threats) or risk estoppel or patent invalidation by claiming that an FLOSS project is infringing on their patents and losing.
Open Source developers are *very* open. In general, our conversational abilities as a society are not yet adapted to the open nature of communication on forums -- we are adjusted to people that maintain a "public stance" and a private stance, and that our messages are forgotten after a while, rather than flawlessly and publically retained for decades. Mr. Brown could go back to Google Groups archives, and dig all sorts of nasty, infringing, and flamebait messages from major figures, finding quotes from Cox or
Linus probably has contributed more code to Linux than anone else...but, sure, there are a lot of other people. He started it, though, and "Linux" sounds cool and friendly, so why change it? Linus has done one hell of a job over the years coding, making engineering decisions, keeping development from forking, managing people...he deserves the credit, and he's certainly no "manager only" type like Jobs is or Gates has become.
Why is ICANN even involved
on
Iraq Wants .iq TLD
·
· Score: 4, Insightful
To avoid political controversy, ICANN *specifically* chose to use ISO country codes. This should be specifically a problem for ISO, and if the ISO standard is updated, ICANN can use the new country codes.
"Hybrid source code" is a phrase coined by former Tocqueville Chairman Gregory Fossedal. The term refers to any product with a license that attempts to mix free and proprietary source code at the same time.
Okay. I cannot imagine what he's talking about here, though. The GPL explicitly forbids such a license being used with any GPLed code, so unless he's just trying to mislead people or doesn't understand the legal nature of the GPL, he's not talking about the GPL.
The only people I can think of that mix "closed" and "open" code would be closed companies. Microsoft, for instance, used the BSD TCP stack.
I get the impression that Mr. Brown is trying to make people make the association between this "hybrid" business and the GPL, which is nonsensical -- of all the people involved, GPL users are the *least* likely to fit under his definition of "hybrid".
While hybrid software appears to be the same as open source, it isn't.
I can't agree -- I don't think that anyone would think that Microsoft's software is open.
Hybrid source code can never be true intellectual property.
Not true. Microsoft's software is presumably their own intellectual property.
The actual purpose of hybrid source is to nullify its value as private property, which makes the hybrid source model significantly different from true open source.
Microsoft has made billions with their IP. I doubt that Ken Brown is correct.
Noone can ever truly accrue any value from owning hybrid source software, because everybody (and anybody) has the rights to every line of improvement in it.
I don't have rights to Microsoft's software.
It sounds like he's talking about the GPL -- but the GPL does not allow mingling of closed and open source. The BSD license at least allows code licensed under it to be placed under such a "hybrid" license -- as Microsoft did. The GPL does not.
Worse, many argue that if hybrid source is used the wrong way, it can make other source code hybrid source as well.
Notice that he said "many argue". This is clearly legally wrong -- there is no legal basis for "accidentally" licensing something under the GPL. If you steal GPL code and put it into your closed-source product, you may be guilty of copyright infringement, but the remainder of your code will not be automatically licensed under the GPL.
The only relevance that GPL-licensing one's code would have is that it would be a guaranteed way to avoid the copyright infringement. This is *more* permissive than the case if a closed company stole source from another closed company -- it would have no such guaranteed out. I guarantee that any company that finds out that Microsoft stole its code and put it into Office is going to have a *field* day suing Microsoft.
I can only guess that he's trying to spread fear about getting anywhere near the GPL.
The hybrid source model negatively impacts the intellectual property model for all software, and inevitably the entire IT economy.
Again, the "hybrid source" argument is just plain silly.
As long as the value of the IT economy is dependent on the preservation of intellectual property, it is counterproductive for the U.S. government to invest in Linux.
Okay, *now* we have a more interesting argument. This may or may not be true. It is true that Microsoft maintaining a monopoly has the potential to bring a huge amount of wealth into the United States. However, even for us USians, there are significant efficiency advantages to allowing anyone, anywhere to be able to freely use and modify their computer's software.
I do not have evidence to rebut this point. On the other hand, I claim that Ken Brown has no evidence to support this point either.
My suspicion would be that "chaper, more open, more widely available" actually globally increases the quality of life of people to such an extent that the loss of local
* A gnome-terminal that can open multiple windows without requiring multiple processes.
* Faster startup time and lower memory usage for GNOME applications.
* A GUI method of enabling emacs keymappings and user-rebindable accelerators.
* User-rebindable accelerators on contextual menus, rather than just regular menus.
* OpenOffice working like the rest of the GNOME applications.
* All config directories (dotfiles and dotdirectories) being moved from ~/.appdir to ~/.config/appdir (including gnome/gnome2 stuff. Less garbage in ~/.
* More types of data being supported in cut-and-paste in GNOME apps. This means being able to cut-and-paste from the GIMP or Inkscape to Open Office and back again.
* The introduction of an "infinite progress bar" widget containing barber pole stripes, a la the Mac OS, to be used on tasks with an indeterminate completion time.
* The finishing of *some* instant messaging client for *some* protocols. All of the GNOME-based IM clients have issues. This is mentioned in the roadmap. IM is a standard feature even at many businesses. To use GNOME, I need to be able to send/recieve files with it and send encrypted messages. This is currently a tremendous pain in the ass (for some reason, encryption support *still* has not been merged into gaim mainstream, despite the fact that the US no longer places encryption limitations on people).
* Security. The GNOME people are busily putting in auto-discovery stuff and the like. If GNOME talks to the network, it needs to be tied down very tightly. I get *very* unhappy when my desktop environment needs to talk to the network.
* Network management. GNOME's GxSNMP is currently dead, and there are no GNOME network management apps. There is nothing like Intermapper.
* Make a GnomeTreeView that's a more intelligent GtkTreeView. It should natively have the ability to reorder or hide columns (say, a popup menu can come up from clicking in an icon in the title line of the GnomeTreeView that has a checkmarked list of columns to make visible) -- this sort of functionality shouldn't really require the application to do anything.
Not only that, if it were accurate, statistically Asians would own the flashiest cars, which goes against my experience. Fat, middle-aged white guys seem to be the ones with the choppers and the sports cars.
Finally, have a friend who has a little experience come over and put that beauty together.
It'd be nice if said friend was given a sound card or a plate of cookies or something, mind, since he's probably put together way too many computers for people.
if only this was about 5 months sooner... then I may still have had some fun off it.
You know, the two games that I've been playing most at the moment are Homeworld (on a Windows box, and yes, I know that there's a Linux port), which was released five years ago and bzflag, which was originally released about twelve years ago.
My, my... it seems to be expensive being a Linux gamer... not to mention late.
Perhaps we'll fund this "expensive" habit with some of the hundreds or thousands of dollars we saved by not buying commercial application software and using free alternatives instead. How many copies of Medal of Honor will Visual Studio.NET and Photoshop buy you?
(I've finally got the Mac version too, but all my friends have moved on...)
It is a shame, that. Designing a game for multiplayer use gives you a cheap and easy way to get good AI and gives you a lot of mechanisms to make piracy a pain in the ass. However, multiplayer games have a lifespan that is rarely more than a few years (with a few exceptions, like Quake). MMORPGs are even worse -- within a few years, *all* MMORPG content, all the stuff you spent time acquiring, will be gone as the services shut down.
Sun open-sourcing their Java implementation is simply ridiculous. I mean, I love open source, but there has to be a reason for it. Open-sourcing an implementation of a compiler has absolutely zero potential win involved -- it's about the least interesting piece of software to open source. If a language is well-defined (as is Java), *all* of the necessary data to properly implement the language is available. There is almost no benefit to anyone from open-sourcing. There are open-source Java implementations already out there. I can't understand how this would help other open-source people.
Honestly, I find it more of a disgrace that the open source world (read: ESR and friends) are begging for a closed-source Java implementation to be open-sourced than producing a *better* Java implementation and showing how great open source is. "Open Source is better", right ESR? Java is patent-unencumbered, and has all the necessary data available. What's stopping you, if open source is really up to snuff?
The only possible thing I could think of would be pure ideology -- that "open source is better". That makes ESR happy. It also lets people crow about how awesome open source is (and then cite things like Open Office and Sun's Java implementation, which are *really* closed source implementations that Sun decided to open source).
But, hey, it's no skin off my back (other than if Sun goes under and "open source" is pointed to as the culprit). I just don't think that Sun should do something like this without some really compelling reasons to do so (other than ESR making fun of how low their per-share price is relative to Red Hat, that is).
The patent owner should not be liable for screwups by the patent office. The initial filing fee should cover all needed research.
The patent filer can, though, be responsible for the data that he submits to the patent office. The patent office is not intended to be responsible for a patent search -- this is the responsibility of the patent filer, and is expected to take place before the initial filing.
I considered increasing the initial fee to cover this, but with a re-examination fee of $8.8K and an initial filing fee of $1K, even if the fee increase of $8.8K was refunded when the patent expired (as a deposit), that would represent a stiff financial barrier to a filer. However, if the filer only pays if his patent is shown to be *invalidated*, he is only faced with the cost if he failed to fully do his research.
My approach simply recognizes that it is not feasible for the patent office to hire the best-of-field domain experts in all areas, and puts the responsibility for filing wrong patents on the filer. This moves the recognized role of the USPTO more towards its "currently real" role of acting as a registry.
Have the patent office refund the challenge-patent fee if the challenge is successful. Challenger makes patent office do pointless extra work, challenger pays $$$. Challenger finds mistake made by patent office, it's not the challenger's fault a bad patent was granted.
I agree with you that the challenger should pay if the patent is not invalidated.
That's related to the 'loser pays' ideas floating around. The problem is that patents are intended to protect small individual inventors, as the big companies are already able to defend themselves. Loser pays systems tend to discourage small inventors.
I agree that "loser pays" systems do generally have this issue. However, I do not think that this is an serious problem in this case, for several reasons:
1) The cost is bounded, and *relatively* small. The increase in worst-case cost is less than order-of-magnitude. This is not like exposing someone to legal liability, where insane judgements can be made. Furthermore, I would expect that if demand for reexamination increases (relative to initial examination), improvements in processing efficiency may be made. Remember that capital had to come from somewhere to patent the thing in the first place.
2) Small inventors are unlikely to have patent portfolios of thousands of patents, and thus have limited risk.
3) Since there are also associated legal costs (unless it is made *much* easier to produce and send in properly-formatted reexamination requests, and corporate lawyers will be the ones sending in such complaints, it is likely that companies will find it easier to simply send an unofficial "we believe we have prior art, and we intend to request a reexamination of your patent" with a reference to the prior art letter to the patent holder. This gives the patent holder the opportunity to give up his patent rights to the public domain, and does not impose legal fees on the company.
1. Make it easier to get patents. Right now, patents are reviewed and issued as if the US PTO was the final arbiter of all truth in the universe. This is of course absurd. A patent should be nothing more than a claim that an idea was developed at a certain date.
The USPTO isn't always right -- that's why they have the reexamination and litigation approaches to change a USPTO decision.
2. Make it easier to cancel patents. Patent office arbitration and the legal system are fine for determining the legitimacy of a claim.
If you're talking about from the patent claimant, I agree absolutely. Patent cancellation should be free.
When a patent expires, it's stamped "public property."
All patents (current and expired) are held forever in an absurdly large database that helps inventors and investigators determine the value of future patents.
This is already the case. In addition to the modern computerized database, there have been numerous patent library depositories around the country to do patent searches through.
Nothing personal, and this is not intended to be an attack on your dad -- but in terms of system reliability (and who I'd want running things if I were in an airplane), those crochety old ATCers and their ad-hoc systems had an incredibly, almost impossibly good safety record. I had some free time and, for fun, ran out to start reading a history of world air disasters. ATC error is almost *never* a factor in air disasters in the United States (things change wildly when you go to other countries). (Actually, if we're speaking about major passenger aircraft (rather than light planes) the US air industry usually suffers problems from mechanical failures -- the rate of pilot error on large aircraft is very low.
Then take a look at the software development world. Reliablity sucks. A lot. Even in systems that we consider to be pretty reliable, like embedded systems, I've seen bad failures (we used to have an HP plotter with flaky firmware that would die, and I've seen occasional issues with other embedded devices, especially workgroup printers). The medical tech industry is better, but still has its share of errors (like the string of disastrous Therac-25 incidents. I will also admit that software in crucial systems in airliners seems to have done well -- but I'm not sure about the equivalent on the ground. I'd be fairly dubious about a shift in the systems.
Secondly, the main benefit of using a consistent interface across applications is intuitiveness. This is not *nearly* as much an issue for specialized applications. Frequently, such general-purpose interfaces can be deterimental to specific applications. For example, the Macintosh HIG states that the menubar shall remain visible at all times. Games violate this, but without doing so, would provide a much less interesting interface. The Macintosh HIG also states that moving the mouse shall have no effect on desktop state. This is not the case with FPSes, where moving the mouse changes the camera angle. If you hand to click to commit a change in camera angle, however, it would be extremely annoying. So, I think that "consistent interfaces above all else" is a wrong-headed idea (though I also will agree that the value of consistent interfaces is frequently underrated).
In the case of ATC software, efficiency at a particular task is important, and training is not an issue. I would be more than willing to believe that ATC folks may know what they are talking about.
There might be some concern in that the ATC union might be trying to do nothing other than ensure job security -- but on the whole, the point of the system is to ensure that airplanes do not collide, and the ATCers have been doing a good job thus far -- their concerns with a radical change in interface would be something that I'm inclined to listen to.
Slashdot Mirror
The vendor is generally the one that eats the loss, not the credit card company.
Of course, this makes it rather problematic to print from Linux or any other uncontrolled OS.
;-)
Or Windows. Unless you think Palladium will ever be an effective system?
or receive their data in some semi-low resolution full page view
It's a pretty good bet that it's easy to hack even binary-only drivers to feed garbage as a preview.
But I can't give five bucks to my roommate with a credit card, a smart card, or anything else -- except maybe a check.
Currently, the reason for this is because vendor fees for credit cards are so high. Paypay, for instance, lets you transfer funds to said roommate.
This is caused by:
* Fraud: massively reduced with smartcards.
* Processing costs: Massively reduced with smartcards (less human interaction necessary, fraud detection and resolution reduced, trusted local logs of transactions may be kept rather than sending out CC bills, etc)
* Until now, widespread data network access was rare and expensive -- the CC network evolved when many vendors had to make a phone call (well, with a modem) to authorize each number. This is no longer the case, especially with wireless Ethernet and digital cell phones. Hell, your cell phone can act as a smart card/smart card reader these days.
Your censorship system is based upon authenticating websites as either "pedophile or non-pedophile". This elicits the following response:
This is an idea for an authentication system or system containing an
authentication system. Your idea will not work. This is because it:
[ ] Fails to establish a trustable connection to its end-user.
[ ] Fails to establish a trustable connection from the end-user
interface to a system with knowledge to do the authentication.
[ ] Fails to contain a system that may be trusted.
[X] Is not finely-grained enough to distinguish between some entities
that should pass authentication and some that shouldn't.
[ ] Exposes data that should not be exposed.
[X] May be easily DoSed.
[ ] Will not be accepted by government.
[ ] Will not be accepted by end users.
[X] Has an unacceptable degree of false positives.
[X] Has an unacceptable degree of false negatives.
[ ] Prevents operation of necessary functionality.
[ ] Has the potential to fail catastrophically.
[ ] Is too hard to implement.
Specifically, your suggestion fails to account for:
[ ] Providing a *trustable* store for the system's authentication data.
[ ] Brute-force attacks.
[ ] The fact that IP packet source addresses may be trivially forged.
[ ] The fact that everyone within the population must use this system
properly to keep it working properly.
[ ] The fact that it requires end-users to go through more effort than
they will be willing to undertake to use it.
[ ] Security breeches may not be easily repaired.
[ ] CPU power available to attack your solution.
[ ] Laws prohibiting implementation of your solution.
[ ] Asshats.
[ ] Limited human memory.
[ ] Small/portable devices.
[ ] Willingness of the entity being authenticated to to ignore
authentication failures.
[ ] Windows.
[X] Willingness of users to bypass authentication systems.
[X] Ability of technically skilled hackers to distribute easy-to-use
attacks on the system.
[ ] User resistance to social change.
[ ] Allowing entities other than the authenticating entity to
determine associations between multiple identities that should be
unassociated.
[ ] Your blacklists do not scale to the necessary size.
[ ] The need for implementation to be phased in.
[X] Tainted authentication databases.
[X] Unclear criteria involved.
[X] Inexpensive creation of new identities.
And the following philosophical objections may also apply:
[ ] Attempts to establish an artificial monopoly.
[X] Ideas similar to yours are easy to come up with, yet none have
ever been shown practical.
[X] Any system that allows complete government monitoring of behavior is
unacceptable.
[X] Any system that allows complete corporate monitoring of behavior is
unacceptable.
[ ] Authentication systems should use technical solutions rather than
legislative solutions.
[ ] Biometrics suck.
[X] Why should we have to trust you and your servers?
[ ] Incompatibility with open source or open source licenses.
[X] Feel-good measures do nothing to solve the problem.
[X] I don't want people monitoring me.
[X] Censorship sucks, and there are better things you could be doing
with your time.
[X] I don't need to break your system, because there are easier ways
around it.
[X] This system may be abused horribly by those operating it.
Furthermore, this is what I think about you:
[ ] Sorry dude, but I don't think it would work.
[X] This is a stupid idea, and you're a stupid person for suggesting
it.
[ ] If you had bothered to ask anyone with any security knowledge
first, your idea would have been immediately shot down.
This is an idea for an authentication system or system containing an
authentication system. Your idea will not work. This is because it:
[ ] Fails to establish a trustable connection to its end-user.
[ ] Fails to establish a trustable connection from the end-user
interface to a system with knowledge to do the authentication.
[X] Fails to contain a system that may be trusted.
[ ] Is not finely-grained enough to distinguish between some entities
that should pass authentication and some that shouldn't.
[ ] Exposes data that should not be exposed.
[X] May be easily DoSed.
[ ] Will not be accepted by government.
[X] Will not be accepted by end users.
[X] Has an unacceptable degree of false positives.
[ ] Has an unacceptable degree of false negatives.
[ ] Prevents operation of necessary functionality.
[ ] Has the potential to fail catastrophically.
[ ] Is too hard to implement.
Specifically, your suggestion fails to account for:
[ ] Providing a *trustable* store for the system's authentication data.
[ ] Brute-force attacks.
[X] The fact that IP packet source addresses may be trivially forged.
[ ] The fact that everyone within the population must use this system
properly to keep it working properly.
[ ] The fact that it requires end-users to go through more effort than
they will be willing to undertake to use it.
[X] Security breeches may not be easily repaired.
[ ] CPU power available to attack your solution.
[ ] Laws prohibiting implementation of your solution.
[X] Asshats.
[ ] Limited human memory.
[ ] Small/portable devices.
[ ] Willingness of the entity being authenticated to to ignore
authentication failures.
[ ] Windows.
[ ] Willingness of users to bypass authentication systems.
[ ] Ability of technically skilled hackers to distribute easy-to-use
attacks on the system.
[ ] User resistance to social change.
[ ] Allowing entities other than the authenticating entity to
determine associations between multiple identities that should be
unassociated.
[ ] Your blacklists do not scale to the necessary size.
[ ] The need for implementation to be phased in.
[X] Tainted authentication databases.
And the following philosophical objections may also apply:
[ ] Attempts to establish an artificial monopoly.
[X] Ideas similar to yours are easy to come up with, yet none have
ever been shown practical.
[ ] Any system that allows complete government monitoring of behavior is
unacceptable.
[ ] Any system that allows complete corporate monitoring of behavior is
unacceptable.
[ ] Authentication systems should use technical solutions rather than
legislative solutions.
[ ] Biometrics suck.
[X] Why should we have to trust you and your servers?
[ ] Incompatibility with open source or open source licenses.
[X] Feel-good measures do nothing to solve the problem.
[ ] I don't want people monitoring me.
Furthermore, this is what I think about you:
[ ] Sorry dude, but I don't think it would work.
[ ] This is a stupid idea, and you're a stupid person for suggesting
it.
[X] If you had bothered to ask anyone with any security knowledge
first, your idea would have been immediately shot down.
I'll second the smartcard suggestion.
I find it wildly frusterating that there is so much deployed non-smartcard hardware in the US. The antifraud benefits help just about everyone involved (customer doesn't have to worry about his CC data being ripped off and monitoring his bill, the vendor doesn't have to worry about eating fraud losses, the CC vendor doesn't have to worry about hassling with pissed off users and vendors and fraud detection/processing).
Any time a credit card is used, a smart card is almost unilaterally a better choice.
Seriously, stuff that tries to stop people from doing things on a computer almost never works.
There are a number of problems with adding such code to printers:
* It is difficult to update. All counterfeiters have to do is find *one* image that can get past the blocking code. Futhermore, there is a *huge* set of printers out there that have no such blocking.
* Printers have limited memory and CPU capabilities. I really think that HP will not be thrilled with blowing a bunch of each on doing "currency detection" on every chunk of every page for each country that latches onto this.
* Printers have only the ability to "block". "Blocking" penalties for a detection of counterfeiting is the *easiest* variety of protection, since people just poke at their images until they print. Photoshop or other can "phone home". Some folks might think ahead enough to have a fully-disconnected computer, but as network connectivity grows...and it only takes one "phone home" with a detected serial number of a page of bills that are showing up with bogus numbers to nail someone.
* Printers were never designed to be highly secure embedded devices (for example, a number have easily-replaced firmware slots). It's a good bet that printer manufacturers don't go to a lot of trouble to hide diagnostic data. Sure, no random counterfeiter might be able to crack such a system -- but (a) there's lots of money involved to hire such a geek, and (b) there are major "geek points" involved in figuring out how to break such a system, and legitimate reasons for doing so. Remember the Xbox -- yes, it was cracked so that people could put Linux on it, but it opens things up to piracy. What if people want to improve image quality, add their own rendering engines (because it's not like they can easily build modern printers in their basement)? When someone distributes detailed instructions for how to disable such protection, it won't take a brilliant counterfeiter to beat the thing.
I really think that this is more a case of "we need to do something new with our currency". Currency was designed in a day and age when it was hard to accurately reproduce detailed images on a piece of paper. It was a very good design for that environment. I think that if we had to come up with a new system, we'd have something wildly different today.
You know what *could* make a major improvement?
Smart cards replacing "stupid magnetic strip" credit cards.
Currently, the reason that you can't use credit cards everywhere is because the credit card companies rake in money on each card, and it imposes overhead that not every retailer wants to pay (in vendor fees and per-charge costs).
Smart cards (with *associated readers*) make credit card fraud much more difficult, and thus reduce credit card company costs, and ultimately reduce prices to retailers.
This will help produce smart cards be more commonly used.
Of course, the downside is the big credit card issue -- more easy tracking of money flow, which is a bit Orwellian. Technically, it's possible to build a system that doesn't track fund flows (and still has the hard-to-counterfeit benefits), even if your credit card vendor is malicious, but there is probably little public interest in such a property. Plus, given the commercial value of people's credit card records (and pressure from law enforcement to monitor them) I don't think that it will happen.
It may not be what you're thinking of, but there is a genre of games in which there are not infrequently (in the good specimens) multiple ways to solve problems -- good old text-based interactive fiction. Some of these are quite clever.
Of course, they lack the twitch element, and they won't use your new $300 video card, but when it comes to sophisticated game paths, there are few other genres on par with this one.
I think what you mean to say is that Jobs had many people *working* for him that achived great things.
I've been very pleased that Microsoft has found such incompetent PR people (Mr. McBride and Mr. Brown) to push Linux as bad for business. I mean, I worried for a while that Linux advocates might be using flawed, emotional arguments, and that their competitors might be presenting moe reasonable arguments -- however, the two have really made the anti-Linux front come off as rather stupid and dishonest.
I mean, seriously, *surely* Microsoft could find someone like the EFF's Eben Moglen, a lawyer who actually understands technology and doesn't have a habit of promulgating bullshit, to try to tear at the GPL's weak points. Instead, whoever is responsible for propaganda and PR at Microsoft has chosen the biggest bunch of chowderheads I've ever seen.
Seriously, if Microsoft had *immediately* gotten a couple of major tech companies to make frequent anti-Linux statements (SGI and Sun would have been great choices) and bought off some comptent people (who might have come off as being paid off by Microsoft, but could *still* have had vaguely reasonable arguments against Linux), they might have had a decent set of anti-Linux PR. Instead, they've consistently done an *awful* job.
Microsoft seriously blew the PR aspect of fighting Open Source. I'm very curious to see what their next move is.
If they start getting hammered, I'm going to assume that they pull out their patent portfolio. If I were them, I'd be making a *long* list of patents (including bogus ones) and going after Open Source projects. How many Open Source developers have the money to fight a lawsuit, or the $2.5K-$20K required to request a patent reexamination from the USPTO?
Furthermore, the social side effects of such a move would be wonderful for Microsoft. Open Source workers would be increasingly polarized against intellectual property law (which makes for *wonderful* PR). Any projects that are stopped serve as both PR and the practical elimination of a competitor. Any projects that continue (especially if they make arguments about not caring about "bullshit patents") can be used as examples of Open Source disregard for intellectual property and easily sued -- Microsoft has far more money to play with legal tactics than a small subset of open source developers do, even with OSDL/EFF/Red Hat backing (and a desperate Microsoft will probably commit more money than a less upset IBM -- especially an IBM with their own large collection of patents, some of which are surely bogus).
If I were Ken Brown, here's what I'd do to make a plausible case. I'd start identifying Microsoft patents (there are a lot to work with) and sending letters to open source developers. They don't even have to be project leads, but members of important projects would look nice. *Then* I'd send out letters saying "It looks like you're infrining on this patent", and quoting out-of-context bits of developer responses. Ken Brown wants to make a case against generally ethical and honest people, and do to that, he needs to exploit irrationality or incorrect beliefs. A good one is the current US patent system, which is generally believed to be excellent, but is actually fairly broken. By saying "there's a patent against this, and you can't make this", he has an *excellent* set of attacks against software.
As an even bigger benefit, Microsoft doesn't need to look like a bad guy (sending out patent threats) or risk estoppel or patent invalidation by claiming that an FLOSS project is infringing on their patents and losing.
Open Source developers are *very* open. In general, our conversational abilities as a society are not yet adapted to the open nature of communication on forums -- we are adjusted to people that maintain a "public stance" and a private stance, and that our messages are forgotten after a while, rather than flawlessly and publically retained for decades. Mr. Brown could go back to Google Groups archives, and dig all sorts of nasty, infringing, and flamebait messages from major figures, finding quotes from Cox or
Linus probably has contributed more code to Linux than anone else...but, sure, there are a lot of other people. He started it, though, and "Linux" sounds cool and friendly, so why change it? Linus has done one hell of a job over the years coding, making engineering decisions, keeping development from forking, managing people...he deserves the credit, and he's certainly no "manager only" type like Jobs is or Gates has become.
To avoid political controversy, ICANN *specifically* chose to use ISO country codes. This should be specifically a problem for ISO, and if the ISO standard is updated, ICANN can use the new country codes.
"Hybrid source code" is a phrase coined by former Tocqueville Chairman Gregory Fossedal. The term refers to any product with a license that attempts to mix free and proprietary source code at the same time.
Okay. I cannot imagine what he's talking about here, though. The GPL explicitly forbids such a license being used with any GPLed code, so unless he's just trying to mislead people or doesn't understand the legal nature of the GPL, he's not talking about the GPL.
The only people I can think of that mix "closed" and "open" code would be closed companies. Microsoft, for instance, used the BSD TCP stack.
I get the impression that Mr. Brown is trying to make people make the association between this "hybrid" business and the GPL, which is nonsensical -- of all the people involved, GPL users are the *least* likely to fit under his definition of "hybrid".
While hybrid software appears to be the same as open source, it isn't.
I can't agree -- I don't think that anyone would think that Microsoft's software is open.
Hybrid source code can never be true intellectual property.
Not true. Microsoft's software is presumably their own intellectual property.
The actual purpose of hybrid source is to nullify its value as private property, which makes the hybrid source model significantly different from true open source.
Microsoft has made billions with their IP. I doubt that Ken Brown is correct.
Noone can ever truly accrue any value from owning hybrid source software, because everybody (and anybody) has the rights to every line of improvement in it.
I don't have rights to Microsoft's software.
It sounds like he's talking about the GPL -- but the GPL does not allow mingling of closed and open source. The BSD license at least allows code licensed under it to be placed under such a "hybrid" license -- as Microsoft did. The GPL does not.
Worse, many argue that if hybrid source is used the wrong way, it can make other source code hybrid source as well.
Notice that he said "many argue". This is clearly legally wrong -- there is no legal basis for "accidentally" licensing something under the GPL. If you steal GPL code and put it into your closed-source product, you may be guilty of copyright infringement, but the remainder of your code will not be automatically licensed under the GPL.
The only relevance that GPL-licensing one's code would have is that it would be a guaranteed way to avoid the copyright infringement. This is *more* permissive than the case if a closed company stole source from another closed company -- it would have no such guaranteed out. I guarantee that any company that finds out that Microsoft stole its code and put it into Office is going to have a *field* day suing Microsoft.
I can only guess that he's trying to spread fear about getting anywhere near the GPL.
The hybrid source model negatively impacts the intellectual property model for all software, and inevitably the entire IT economy.
Again, the "hybrid source" argument is just plain silly.
As long as the value of the IT economy is dependent on the preservation of intellectual property, it is counterproductive for the U.S. government to invest in Linux.
Okay, *now* we have a more interesting argument. This may or may not be true. It is true that Microsoft maintaining a monopoly has the potential to bring a huge amount of wealth into the United States. However, even for us USians, there are significant efficiency advantages to allowing anyone, anywhere to be able to freely use and modify their computer's software.
I do not have evidence to rebut this point. On the other hand, I claim that Ken Brown has no evidence to support this point either.
My suspicion would be that "chaper, more open, more widely available" actually globally increases the quality of life of people to such an extent that the loss of local
Microsoft provides LinuxToday with money.
Which do you find more effective is getting people to choose a platform -- LinuxToday's content or the ad banners?
* A gnome-terminal that can open multiple windows without requiring multiple processes.
* Faster startup time and lower memory usage for GNOME applications.
* A GUI method of enabling emacs keymappings and user-rebindable accelerators.
* User-rebindable accelerators on contextual menus, rather than just regular menus.
* OpenOffice working like the rest of the GNOME applications.
* All config directories (dotfiles and dotdirectories) being moved from ~/.appdir to ~/.config/appdir (including gnome/gnome2 stuff. Less garbage in ~/.
* More types of data being supported in cut-and-paste in GNOME apps. This means being able to cut-and-paste from the GIMP or Inkscape to Open Office and back again.
* The introduction of an "infinite progress bar" widget containing barber pole stripes, a la the Mac OS, to be used on tasks with an indeterminate completion time.
* The finishing of *some* instant messaging client for *some* protocols. All of the GNOME-based IM clients have issues. This is mentioned in the roadmap. IM is a standard feature even at many businesses. To use GNOME, I need to be able to send/recieve files with it and send encrypted messages. This is currently a tremendous pain in the ass (for some reason, encryption support *still* has not been merged into gaim mainstream, despite the fact that the US no longer places encryption limitations on people).
* Security. The GNOME people are busily putting in auto-discovery stuff and the like. If GNOME talks to the network, it needs to be tied down very tightly. I get *very* unhappy when my desktop environment needs to talk to the network.
* Network management. GNOME's GxSNMP is currently dead, and there are no GNOME network management apps. There is nothing like Intermapper.
* Make a GnomeTreeView that's a more intelligent GtkTreeView. It should natively have the ability to reorder or hide columns (say, a popup menu can come up from clicking in an icon in the title line of the GnomeTreeView that has a checkmarked list of columns to make visible) -- this sort of functionality shouldn't really require the application to do anything.
Not only that, if it were accurate, statistically Asians would own the flashiest cars, which goes against my experience. Fat, middle-aged white guys seem to be the ones with the choppers and the sports cars.
Finally, have a friend who has a little experience come over and put that beauty together.
It'd be nice if said friend was given a sound card or a plate of cookies or something, mind, since he's probably put together way too many computers for people.
The credit card companies will cover any losses (they have to by law)
I am very suspicious that they are required to do so by law (well, at least in the US).
if only this was about 5 months sooner... then I may still have had some fun off it.
.NET and Photoshop buy you?
You know, the two games that I've been playing most at the moment are Homeworld (on a Windows box, and yes, I know that there's a Linux port), which was released five years ago and bzflag, which was originally released about twelve years ago.
My, my... it seems to be expensive being a Linux gamer... not to mention late.
Perhaps we'll fund this "expensive" habit with some of the hundreds or thousands of dollars we saved by not buying commercial application software and using free alternatives instead. How many copies of Medal of Honor will Visual Studio
(I've finally got the Mac version too, but all my friends have moved on...)
It is a shame, that. Designing a game for multiplayer use gives you a cheap and easy way to get good AI and gives you a lot of mechanisms to make piracy a pain in the ass. However, multiplayer games have a lifespan that is rarely more than a few years (with a few exceptions, like Quake). MMORPGs are even worse -- within a few years, *all* MMORPG content, all the stuff you spent time acquiring, will be gone as the services shut down.
Sun open-sourcing their Java implementation is simply ridiculous. I mean, I love open source, but there has to be a reason for it. Open-sourcing an implementation of a compiler has absolutely zero potential win involved -- it's about the least interesting piece of software to open source. If a language is well-defined (as is Java), *all* of the necessary data to properly implement the language is available. There is almost no benefit to anyone from open-sourcing. There are open-source Java implementations already out there. I can't understand how this would help other open-source people.
Honestly, I find it more of a disgrace that the open source world (read: ESR and friends) are begging for a closed-source Java implementation to be open-sourced than producing a *better* Java implementation and showing how great open source is. "Open Source is better", right ESR? Java is patent-unencumbered, and has all the necessary data available. What's stopping you, if open source is really up to snuff?
The only possible thing I could think of would be pure ideology -- that "open source is better". That makes ESR happy. It also lets people crow about how awesome open source is (and then cite things like Open Office and Sun's Java implementation, which are *really* closed source implementations that Sun decided to open source).
But, hey, it's no skin off my back (other than if Sun goes under and "open source" is pointed to as the culprit). I just don't think that Sun should do something like this without some really compelling reasons to do so (other than ESR making fun of how low their per-share price is relative to Red Hat, that is).
The patent owner should not be liable for screwups by the patent office. The initial filing fee should cover all needed research.
The patent filer can, though, be responsible for the data that he submits to the patent office. The patent office is not intended to be responsible for a patent search -- this is the responsibility of the patent filer, and is expected to take place before the initial filing.
I considered increasing the initial fee to cover this, but with a re-examination fee of $8.8K and an initial filing fee of $1K, even if the fee increase of $8.8K was refunded when the patent expired (as a deposit), that would represent a stiff financial barrier to a filer. However, if the filer only pays if his patent is shown to be *invalidated*, he is only faced with the cost if he failed to fully do his research.
My approach simply recognizes that it is not feasible for the patent office to hire the best-of-field domain experts in all areas, and puts the responsibility for filing wrong patents on the filer. This moves the recognized role of the USPTO more towards its "currently real" role of acting as a registry.
Have the patent office refund the challenge-patent fee if the challenge is successful. Challenger makes patent office do pointless extra work, challenger pays $$$. Challenger finds mistake made by patent office, it's not the challenger's fault a bad patent was granted.
I agree with you that the challenger should pay if the patent is not invalidated.
That's related to the 'loser pays' ideas floating around. The problem is that patents are intended to protect small individual inventors, as the big companies are already able to defend themselves. Loser pays systems tend to discourage small inventors.
I agree that "loser pays" systems do generally have this issue. However, I do not think that this is an serious problem in this case, for several reasons:
1) The cost is bounded, and *relatively* small. The increase in worst-case cost is less than order-of-magnitude. This is not like exposing someone to legal liability, where insane judgements can be made. Furthermore, I would expect that if demand for reexamination increases (relative to initial examination), improvements in
processing efficiency may be made. Remember that capital had to come from somewhere to patent the thing in the first place.
2) Small inventors are unlikely to have patent portfolios of thousands of patents, and thus have limited risk.
3) Since there are also associated legal costs (unless it is made *much* easier to produce and send in properly-formatted reexamination requests, and corporate lawyers will be the ones sending in such complaints, it is likely that companies will find it easier to simply send an unofficial "we believe we have prior art, and we intend to request a reexamination of your patent" with a reference to the prior art letter to the patent holder. This gives the patent holder the opportunity to give up his patent rights to the public domain, and does not impose legal fees on the company.
1. Make it easier to get patents. Right now, patents are reviewed and issued as if the US PTO was the final arbiter of all truth in the universe. This is of course absurd. A patent should be nothing more than a claim that an idea was developed at a certain date.
The USPTO isn't always right -- that's why they have the reexamination and litigation approaches to change a USPTO decision.
2. Make it easier to cancel patents. Patent office arbitration and the legal system are fine for determining the legitimacy of a claim.
If you're talking about from the patent claimant, I agree absolutely. Patent cancellation should be free.
When a patent expires, it's stamped "public property."
All patents (current and expired) are held forever in an absurdly large database that helps inventors and investigators determine the value of future patents.
This is already the case. In addition to the modern computerized database, there have been numerous patent library depositories around the country to do patent searches through.
Or the management mentality of 'Oh, security is too expensive right now we'll ship it and fix it later'.
To be fair, it's really hard to estimate the economic costs and probability of a security breech.
The insurance industry is in this business, and they have to maintain and analyze *masses* of data to pull this off.
That has to be the best on-the-job IT horror story ever. Thank you.
Nothing personal, and this is not intended to be an attack on your dad -- but in terms of system reliability (and who I'd want running things if I were in an airplane), those crochety old ATCers and their ad-hoc systems had an incredibly, almost impossibly good safety record. I had some free time and, for fun, ran out to start reading a history of world air disasters. ATC error is almost *never* a factor in air disasters in the United States (things change wildly when you go to other countries). (Actually, if we're speaking about major passenger aircraft (rather than light planes) the US air industry usually suffers problems from mechanical failures -- the rate of pilot error on large aircraft is very low.
Then take a look at the software development world. Reliablity sucks. A lot. Even in systems that we consider to be pretty reliable, like embedded systems, I've seen bad failures (we used to have an HP plotter with flaky firmware that would die, and I've seen occasional issues with other embedded devices, especially workgroup printers). The medical tech industry is better, but still has its share of errors (like the string of disastrous Therac-25 incidents. I will also admit that software in crucial systems in airliners seems to have done well -- but I'm not sure about the equivalent on the ground. I'd be fairly dubious about a shift in the systems.
Secondly, the main benefit of using a consistent interface across applications is intuitiveness. This is not *nearly* as much an issue for specialized applications. Frequently, such general-purpose interfaces can be deterimental to specific applications. For example, the Macintosh HIG states that the menubar shall remain visible at all times. Games violate this, but without doing so, would provide a much less interesting interface. The Macintosh HIG also states that moving the mouse shall have no effect on desktop state. This is not the case with FPSes, where moving the mouse changes the camera angle. If you hand to click to commit a change in camera angle, however, it would be extremely annoying. So, I think that "consistent interfaces above all else" is a wrong-headed idea (though I also will agree that the value of consistent interfaces is frequently underrated).
In the case of ATC software, efficiency at a particular task is important, and training is not an issue. I would be more than willing to believe that ATC folks may know what they are talking about.
There might be some concern in that the ATC union might be trying to do nothing other than ensure job security -- but on the whole, the point of the system is to ensure that airplanes do not collide, and the ATCers have been doing a good job thus far -- their concerns with a radical change in interface would be something that I'm inclined to listen to.