It's dangerous for managers to cling to buzzwords, and assume that making the buzzwords go away will fix things.
Reaching this point with Perl speaks of a development culture that will recreate the same problem in a few years with [insert cool new language here]. They didn't understand (or perhaps didn't listen to those telling them) that code maintenance and understanding are even more important than having the code written in the first place.
It is possibly to write maintainable Perl; they aren't doing it, and that is the "legacy" they need to get rid of.
Don't they realize that implementing something from scratch, much less something this complex, undoes all of the security and other bug fixes found by hundreds of people over more than a decade (not to mention invalidating the experience of thousands of people with established systems)? They're guaranteed to end up with something that has unknown quirks, and that's after it's released to market years later than it's supposed to be.
I'll allow that Microsoft is capable of good ideas. But they'd be much smarter to build on solid foundations and just bring the good ideas to market.
There is plenty of past evidence to suggest that completely rebuilding something can have consequences (e.g. introducing new problems). And I would have to have complete faith in the competency of the people doing it, which pretty much disqualifies modern government.
But here's another question: why the hell start with *this*? Of all the aging infrastructure in this country that could use millions of dollars invested, the Internet is not very archaic. How many outdated things are holding the power grid together? Roads? Bridges? Air traffic control? I'm sure if they actually thought about this, they could spend $12M wisely.
As it is, it sure feels like somebody just doesn't like how free and clear today's Internet is. By becoming a founder in a "new" Internet, they'd be in a great position to control the universe, which sounds like a pretty stupid thing for the rest of us to buy into.
My company nitpicks about a few thousand in travel costs, because it knows its investors will act if money is spent unnecessarily.
Then there's the government. It is supposed to work the same way, as an organization that could have its ass handed to it at any moment by its "investors", so it had better do well. Especially since it has WAY more money, and WAY more "shareholders".
Instead, the government has no fear. It can write a check for a billion dollars, without anywhere near as much scrutiny as a company applies to a stupid plane ticket. You know the people in government haven't done the homework, a billion dollars is just a "nice round number" to make politicians look tough on crime. And if anyone were to stand up and protest this spending, they'd probably be labelled a pornographer themselves and bashed into oblivion. (That reminds me of the equal bull of committing "treason" for opposing any and all military spending.)
Companies like to encourage employees to help them save, to nickel and dime things, acting "like it's your own money". And ridiculously, I've seen people who put real effort into helping their stupid company, on a scale that is insignificant compared to government spending; while those same people have never lifted a finger to question the government. They give a huge percentage of their money away and don't care what happens to it. What's wrong here?
The article mentions developers changing little in 15 years, and sadly this is a huge problem (on any platform). It's unclear that developers would have smartened up, even *if* Microsoft gave them a well-needed kick in the butt to enter the 21st century.
Consider the Mac. Programmers using the Carbon API have been crying for many weeks about the idea of having to learn something new (Cocoa). Rather than see it as an important jump for their professional development, or an opportunity to clean up their code bases, a lot of these developers are sitting still and turning blue (if public mailing lists are any measure).
I wish I knew more developers interested in keeping things moving. Many are conservative, and this *kills* projects in the long term.
Part of it may be from incredibly short-sighted managers, relying on buzzwords like "customer focus" to plan exclusively around new features from "users". Then of course there's no time left for developers: no time frame set aside to gut a couple of modules so that things remain manageable, and probably not enough time to write tests! In that situation, maybe most programmers would develop a fear of change.
But that time has passed. These inexperienced programmers have to be cut down by their peers and just told to grow up, in my opinion. If you are a software professional, you have to have the attitude of building the best application you can. And this requires change.
If UAC dialogs are annoying and unnecessary, they're really just behaving like other Windows alerts. There's a whole mentality on the platform for being irritating and bothering users with pointless information.
Still, this was a new class of alert, to be taken seriously. Microsoft had a chance to break with "tradition" and put real thought into what would make a useful dialog, such as (only) information critical for making a good decision and prompting no more than necessary. But instead, we have self-congratulatory "aren't you glad we're looking out for your computer" text, a lot of color, and "abcapqyt.exe" as the only thing distinguishing one UAC dialog from the next. The dialogs therefore essentially read as "You have no idea WTF is running. [OK]" to most people.
I compare this to legalese. Microsoft is taking the "throw 400 pages of crap in the user's face, make them entirely responsible for understanding the ramifications, if they click OK they're responsible" approach to security. When I see legal documents, I *really* appreciate companies who go to the effort to "humanize" what they present. In about a paragraph of extremely readable English, they say hey, this is what we're talking about here, and this is why we have this agreement. Why *couldn't* UAC dialogs do the security equivalent of this deciphering for users, so "abcapqyt.exe" is not my only clue?
If Microsoft is doing this because it worked for Apple, Microsoft may want to look at a few more important details from Apple's situation. It isn't really the same at all.
One, Apple chose a 30-year-old established code base with familiar APIs. This instantly made the solid part of the OS accessible and compatible with *some* software; so the OS could do useful work on day 1, even if nothing else were added on top. Microsoft's going to create some shiny new API, and many of the APIs people actually know won't work, so Windows 7 will be a lousy platform out of the gate.
Two, when Mac OS X arrived, not many were asking Apple to hobble along with updates to Mac OS 9; the customers were *looking* for a new system, there was a clear need for one. Conversely, Microsoft has just tried and failed with Vista...their customers aren't looking for any more heroic engineering efforts, they're looking for a decent upgrade to their PCs. Microsoft needs to offer, in 1-2 years, some really good Windows update (probably XP-based) to restore customer faith. It may still be wise for them to try reinventing Windows in parallel, but mostly for the sake of their future; it shouldn't be the only thing they ship in the next decade.
I did read it, I know there's money awarded. But it's the *same* money regardless of which machine is taken over, so (as I said) this leaves the type of hardware as an incentive to favor one OS target over another.
I've been a little suspicious of this contest simply because of the different hardware prizes. It is possible that a hacker's motivation for the contest is driven by the nice hardware of the machine, and *not* the OS running on it. In other words, of course they're going to try to hack the nicest machines, and every system has holes (regardless of record), so it isn't necessarily news that "nicest machine was hacked first".
Not that it's easy to level this particular playing field, but you could argue that at least the Vista and Ubuntu machines can run on exactly the same type of laptop. Maybe even "3 MacBooks running VMware" would still be considered fair for testing the built-in strengths of all 3 operating systems. The idea is to take away the hardware incentive, so the results are more interesting.
Installing employee can't legally bind his company
on
UK Report Slams EULAs
·
· Score: 1
Dealing with EULAs is a real annoyance for software used at work, because of a simple fact: lawyers don't install software, I do. Why the hell is the software shoving this crap in my face, since I don't have the authority to legally bind my company to scary terms?
The result is simple: I can't bind the company so I don't use the software. In other words, software companies, your EULA directly reduces your sales. It makes me recommend free/open software to my managers every single time. A bullshit-free, get-on-with-your-day, you-won't-go-to-jail software installation process makes for a very productive group that day, whereas sending something to a legal department for review can take months. (And no, I am NOT kidding...lawyers can be slow as hell when it comes to these things.)
Of course at home, I frankly ignore an EULA and grumble about its very existence every single time. Except when I encounter a window that helpfully disables the Agree button until I scroll down to the bottom, simulating absorption of mindless legalese before being allowed to continue (in which case, I also grumble about those who wrote the installer).
I have an XP machine available at work (that I thankfully don't have to use constantly, as I have a Linux workstation). But file copying is a problem on XP, too: it's slow! Frankly, on my Linux workstation I'm regularly dealing with files over NFS that create, delete, rename, or symlink instantaneously, so how Windows can take several seconds to do these things on its *local* hard drive is beyond me. My Mac at home works fine too.
In theory, the slow-down is caused by anti-virus, backup or other random stuff that IT might have on the PC. But really, I don't care: I blame Microsoft anyway, because the extra crap interfering with basic file activities wouldn't even *be* there if the OS didn't need it all to remain even reasonably secure and reliable.
If you actually read the intros and responses written by the TSA blog maintainers, it does seem (to their credit) fairly sensible and honest so far; so it has a decent shot at being effective. Yes, it's moderated, but not in a draconian way: they're trying to keep things as written, throwing away only the obvious personal attacks or things rife with ads, etc.
Posters here do not seem to be aware of Python's __future__ module. It is the mechanism by which scripts can gracefully move forward before the rug is pulled out from under them. This is not unique to 3.0.
The whole idea is that Python can add features to the language in __future__, that are available at least one version before they become the new default. A script can adopt a new feature ahead of time (e.g. "from __future__ import with_statement").
It wouldn't surprise me if Python 2.6 has __future__ entries for Python 3.0 capabilities.
Documentation is very effective if it focuses on only crucial parts (Unix man-page style), and is written in simple English (what I call "8th grade English").
You don't want to answer every imaginable question, or you end up with an unwieldy book. Describe the common cases, leave finer details unspecified. Give credit to your employees, a few common-sense people can find a solution to unusual problems; or, put a list in the document of people to ask for help.
Simple English is important for a few reasons. One, it's easier to read. Two, it's more accessible to non-native speakers. And third, it keeps documentation on task: the goal is to be helpful, not to show off. (Whenever I've seen a hundred-page file rife with 12-character words, it was written by people with superiority complexes; and no, the documents were never useful.)
Switching may not be that bad, since they built in an incremental mechanism (the same mechanism that lets you put code from ANY two supported languages into the same source file). You could take your 99%-Perl-5 source and add a Perl 6 segment to it, and over time make it fully Perl 6.
What is the embedded-device equivalent of a full system backup?
I don't have an iPhone, but if I ever acquire a device that complicated, I'd accept malware risks if all I had was some kind of a "device rollback": a way to periodically copy the device's software and firmware state. So once in a blue moon if your device is hosed, you plug in something to upload a previous unhosed state and you're back in business.
I don't mind seeing software companies trash their customers' investments this way. It just means that more people will learn (albeit the hard way) just how tied they are to the whims of their vendors, and seek a way to end the pain. The outcomes of that are generally a step forward for the industry.
For example, this could cause some people to start demanding more of their software vendors (e.g. open formats, better support contracts, whatever). Or it could cause them to look at free/open formats and software as a way to avoid this problem in the future.
I can only hope they plan to redefine the interface on top of the Windows core (e.g. like they do in ATMs), because the default Windows interface would be absolutely terrible for a laptop given to a child.
So would any windowing interface, which is why OLPC spent so much time developing an alternative interface that is decent for education.
Let's see what Microsoft puts on top of Windows...let's see if they actually care about children and what is best for education. If this laptop boots into the standard Windows desktop, I'll assume they have no clue about what is good for a child and are just in it to preserve their monopoly.
Ask yourself: is the GUI adding anything over a text editor? In other words, never "literally translate" a file to a GUI. If your file is a bunch of name-value pairs, your "GUI" shouldn't just be a list box that lets the user edit strings.
Some good starts (far from complete):
1. Filter information; hide advanced material by default, and maybe force the really advanced stuff to require a separate text editor. Use progressive disclosure, so that only a subset is ever visible.
2. Present information, don't just map it to the file. For example, maybe you physically store a color as "r: 0.6, g: 1.0, b: 0.75", but you wouldn't give the user an R field, G field and B field: you'd show the actual color, and allow editing in any way supported by the system (e.g. on a Mac you can enter CMYK, or even pick crayons!).
3. De-jargon your terminology. For example, if your file says "alpha: 0.7", your GUI should say "transparency" or "opacity" and use a slider with a live graphical sample or other more intuitive method to set the fraction.
4. Avoid editing strings most of the time. Even if a setting "can" have any value, it is often useful to give the user a menu of common values with an option to add anything else they want. For example, why not keep track of recent values a person has been using?
5. Don't force users to use your crappy text editor for really complex stuff. Usually, if your file format is at least plain text, this is avoidable. But if you store some huge paragraph of text in a database I can't see, and your GUI gives me the crappiest editor imaginable as the only way to change it, then your GUI is causing more problems than it solves (and the real project should have been to write a text importer for your opaque database).
Jack Thompson is someone best ignored. I think it is better to stop making headlines every time he goes off his rocker, and let him not be heard, than to give him free publicity for his stunts.
Rulemakers like the TSA need to be forced to explain the rationales for every decision.
But, before they're allowed to get all legalese on us, there should also be a brevity requirement. Like the Nutrition Facts on the side of your average can of soup, probably one of the best examples I can think of where a government requirement *didn't* turn into 4 paragraphs of fine print, but rather is presented in a way Joe Sixpack can understand.
I'd like to see something like: TSA Security Facts -------------- Restriction: No lithium batteries. Applies to Flights: International Rationale: We don't have a clue but we read something bad about them in Newsweek. Since: 2007 Terrorist Plots Known to Use This Method: 0
It seems these days, and not just with Microsoft, products are screwing up a lot more of the "basics". The kind of bugs that make you not even bother trying to find the source of a problem in higher level software, because you've stopped trusting that the foundation has been properly tested!
I'm not sure why...maybe testing these basics is boring, maybe money is never put into it, or maybe companies are trying to see how sloppy they can be with its beta te...uh I mean customers, without losing revenue.
But professionally speaking, this stuff is scary. It hints at major regression testing holes in software processes we can't see, that society depends on crucially. Yes, software is infinitely complex, yada yada, but at the end of the day you *can* make at least these kinds of problems go away, and a multi-billion-dollar corporation sure as hell can be expected to minimize them. Maybe society needs to demand more from its software providers, and not just sit still when "basic" assumptions about software reliability aren't met.
Slashdot Mirror
It's dangerous for managers to cling to buzzwords, and assume that making the buzzwords go away will fix things.
Reaching this point with Perl speaks of a development culture that will recreate the same problem in a few years with [insert cool new language here]. They didn't understand (or perhaps didn't listen to those telling them) that code maintenance and understanding are even more important than having the code written in the first place.
It is possibly to write maintainable Perl; they aren't doing it, and that is the "legacy" they need to get rid of.
Don't they realize that implementing something from scratch, much less something this complex, undoes all of the security and other bug fixes found by hundreds of people over more than a decade (not to mention invalidating the experience of thousands of people with established systems)? They're guaranteed to end up with something that has unknown quirks, and that's after it's released to market years later than it's supposed to be.
I'll allow that Microsoft is capable of good ideas. But they'd be much smarter to build on solid foundations and just bring the good ideas to market.
There is plenty of past evidence to suggest that completely rebuilding something can have consequences (e.g. introducing new problems). And I would have to have complete faith in the competency of the people doing it, which pretty much disqualifies modern government.
But here's another question: why the hell start with *this*? Of all the aging infrastructure in this country that could use millions of dollars invested, the Internet is not very archaic. How many outdated things are holding the power grid together? Roads? Bridges? Air traffic control? I'm sure if they actually thought about this, they could spend $12M wisely.
As it is, it sure feels like somebody just doesn't like how free and clear today's Internet is. By becoming a founder in a "new" Internet, they'd be in a great position to control the universe, which sounds like a pretty stupid thing for the rest of us to buy into.
My company nitpicks about a few thousand in travel costs, because it knows its investors will act if money is spent unnecessarily.
Then there's the government. It is supposed to work the same way, as an organization that could have its ass handed to it at any moment by its "investors", so it had better do well. Especially since it has WAY more money, and WAY more "shareholders".
Instead, the government has no fear. It can write a check for a billion dollars, without anywhere near as much scrutiny as a company applies to a stupid plane ticket. You know the people in government haven't done the homework, a billion dollars is just a "nice round number" to make politicians look tough on crime. And if anyone were to stand up and protest this spending, they'd probably be labelled a pornographer themselves and bashed into oblivion. (That reminds me of the equal bull of committing "treason" for opposing any and all military spending.)
Companies like to encourage employees to help them save, to nickel and dime things, acting "like it's your own money". And ridiculously, I've seen people who put real effort into helping their stupid company, on a scale that is insignificant compared to government spending; while those same people have never lifted a finger to question the government. They give a huge percentage of their money away and don't care what happens to it. What's wrong here?
The article mentions developers changing little in 15 years, and sadly this is a huge problem (on any platform). It's unclear that developers would have smartened up, even *if* Microsoft gave them a well-needed kick in the butt to enter the 21st century.
Consider the Mac. Programmers using the Carbon API have been crying for many weeks about the idea of having to learn something new (Cocoa). Rather than see it as an important jump for their professional development, or an opportunity to clean up their code bases, a lot of these developers are sitting still and turning blue (if public mailing lists are any measure).
I wish I knew more developers interested in keeping things moving. Many are conservative, and this *kills* projects in the long term.
Part of it may be from incredibly short-sighted managers, relying on buzzwords like "customer focus" to plan exclusively around new features from "users". Then of course there's no time left for developers: no time frame set aside to gut a couple of modules so that things remain manageable, and probably not enough time to write tests! In that situation, maybe most programmers would develop a fear of change.
But that time has passed. These inexperienced programmers have to be cut down by their peers and just told to grow up, in my opinion. If you are a software professional, you have to have the attitude of building the best application you can. And this requires change.
If UAC dialogs are annoying and unnecessary, they're really just behaving like other Windows alerts. There's a whole mentality on the platform for being irritating and bothering users with pointless information.
Still, this was a new class of alert, to be taken seriously. Microsoft had a chance to break with "tradition" and put real thought into what would make a useful dialog, such as (only) information critical for making a good decision and prompting no more than necessary. But instead, we have self-congratulatory "aren't you glad we're looking out for your computer" text, a lot of color, and "abcapqyt.exe" as the only thing distinguishing one UAC dialog from the next. The dialogs therefore essentially read as "You have no idea WTF is running. [OK]" to most people.
I compare this to legalese. Microsoft is taking the "throw 400 pages of crap in the user's face, make them entirely responsible for understanding the ramifications, if they click OK they're responsible" approach to security. When I see legal documents, I *really* appreciate companies who go to the effort to "humanize" what they present. In about a paragraph of extremely readable English, they say hey, this is what we're talking about here, and this is why we have this agreement. Why *couldn't* UAC dialogs do the security equivalent of this deciphering for users, so "abcapqyt.exe" is not my only clue?
If Microsoft is doing this because it worked for Apple, Microsoft may want to look at a few more important details from Apple's situation. It isn't really the same at all.
One, Apple chose a 30-year-old established code base with familiar APIs. This instantly made the solid part of the OS accessible and compatible with *some* software; so the OS could do useful work on day 1, even if nothing else were added on top. Microsoft's going to create some shiny new API, and many of the APIs people actually know won't work, so Windows 7 will be a lousy platform out of the gate.
Two, when Mac OS X arrived, not many were asking Apple to hobble along with updates to Mac OS 9; the customers were *looking* for a new system, there was a clear need for one. Conversely, Microsoft has just tried and failed with Vista...their customers aren't looking for any more heroic engineering efforts, they're looking for a decent upgrade to their PCs. Microsoft needs to offer, in 1-2 years, some really good Windows update (probably XP-based) to restore customer faith. It may still be wise for them to try reinventing Windows in parallel, but mostly for the sake of their future; it shouldn't be the only thing they ship in the next decade.
I did read it, I know there's money awarded. But it's the *same* money regardless of which machine is taken over, so (as I said) this leaves the type of hardware as an incentive to favor one OS target over another.
I've been a little suspicious of this contest simply because of the different hardware prizes. It is possible that a hacker's motivation for the contest is driven by the nice hardware of the machine, and *not* the OS running on it. In other words, of course they're going to try to hack the nicest machines, and every system has holes (regardless of record), so it isn't necessarily news that "nicest machine was hacked first".
Not that it's easy to level this particular playing field, but you could argue that at least the Vista and Ubuntu machines can run on exactly the same type of laptop. Maybe even "3 MacBooks running VMware" would still be considered fair for testing the built-in strengths of all 3 operating systems. The idea is to take away the hardware incentive, so the results are more interesting.
Dealing with EULAs is a real annoyance for software used at work, because of a simple fact: lawyers don't install software, I do. Why the hell is the software shoving this crap in my face, since I don't have the authority to legally bind my company to scary terms?
The result is simple: I can't bind the company so I don't use the software. In other words, software companies, your EULA directly reduces your sales. It makes me recommend free/open software to my managers every single time. A bullshit-free, get-on-with-your-day, you-won't-go-to-jail software installation process makes for a very productive group that day, whereas sending something to a legal department for review can take months. (And no, I am NOT kidding...lawyers can be slow as hell when it comes to these things.)
Of course at home, I frankly ignore an EULA and grumble about its very existence every single time. Except when I encounter a window that helpfully disables the Agree button until I scroll down to the bottom, simulating absorption of mindless legalese before being allowed to continue (in which case, I also grumble about those who wrote the installer).
I have an XP machine available at work (that I thankfully don't have to use constantly, as I have a Linux workstation). But file copying is a problem on XP, too: it's slow! Frankly, on my Linux workstation I'm regularly dealing with files over NFS that create, delete, rename, or symlink instantaneously, so how Windows can take several seconds to do these things on its *local* hard drive is beyond me. My Mac at home works fine too.
In theory, the slow-down is caused by anti-virus, backup or other random stuff that IT might have on the PC. But really, I don't care: I blame Microsoft anyway, because the extra crap interfering with basic file activities wouldn't even *be* there if the OS didn't need it all to remain even reasonably secure and reliable.
If you actually read the intros and responses written by the TSA blog maintainers, it does seem (to their credit) fairly sensible and honest so far; so it has a decent shot at being effective. Yes, it's moderated, but not in a draconian way: they're trying to keep things as written, throwing away only the obvious personal attacks or things rife with ads, etc.
Posters here do not seem to be aware of Python's __future__ module. It is the mechanism by which scripts can gracefully move forward before the rug is pulled out from under them. This is not unique to 3.0.
The whole idea is that Python can add features to the language in __future__, that are available at least one version before they become the new default. A script can adopt a new feature ahead of time (e.g. "from __future__ import with_statement").
It wouldn't surprise me if Python 2.6 has __future__ entries for Python 3.0 capabilities.
Documentation is very effective if it focuses on only crucial parts (Unix man-page style), and is written in simple English (what I call "8th grade English").
You don't want to answer every imaginable question, or you end up with an unwieldy book. Describe the common cases, leave finer details unspecified. Give credit to your employees, a few common-sense people can find a solution to unusual problems; or, put a list in the document of people to ask for help.
Simple English is important for a few reasons. One, it's easier to read. Two, it's more accessible to non-native speakers. And third, it keeps documentation on task: the goal is to be helpful, not to show off. (Whenever I've seen a hundred-page file rife with 12-character words, it was written by people with superiority complexes; and no, the documents were never useful.)
Switching may not be that bad, since they built in an incremental mechanism (the same mechanism that lets you put code from ANY two supported languages into the same source file). You could take your 99%-Perl-5 source and add a Perl 6 segment to it, and over time make it fully Perl 6.
What is the embedded-device equivalent of a full system backup?
I don't have an iPhone, but if I ever acquire a device that complicated, I'd accept malware risks if all I had was some kind of a "device rollback": a way to periodically copy the device's software and firmware state. So once in a blue moon if your device is hosed, you plug in something to upload a previous unhosed state and you're back in business.
MacBook Air sounds more like an airline devoted to Mac users, doesn't it? I wonder what that would be like...
I don't mind seeing software companies trash their customers' investments this way. It just means that more people will learn (albeit the hard way) just how tied they are to the whims of their vendors, and seek a way to end the pain. The outcomes of that are generally a step forward for the industry.
For example, this could cause some people to start demanding more of their software vendors (e.g. open formats, better support contracts, whatever). Or it could cause them to look at free/open formats and software as a way to avoid this problem in the future.
Heh, well most of them unfortunately. It's easier to Google for blue-screening ATMs (since it hasn't happened just once).
I can only hope they plan to redefine the interface on top of the Windows core (e.g. like they do in ATMs), because the default Windows interface would be absolutely terrible for a laptop given to a child.
So would any windowing interface, which is why OLPC spent so much time developing an alternative interface that is decent for education.
Let's see what Microsoft puts on top of Windows...let's see if they actually care about children and what is best for education. If this laptop boots into the standard Windows desktop, I'll assume they have no clue about what is good for a child and are just in it to preserve their monopoly.
And Mac OS X has "fink".
Ask yourself: is the GUI adding anything over a text editor? In other words, never "literally translate" a file to a GUI. If your file is a bunch of name-value pairs, your "GUI" shouldn't just be a list box that lets the user edit strings.
Some good starts (far from complete):
1. Filter information; hide advanced material by default, and maybe force the really advanced stuff to require a separate text editor. Use progressive disclosure, so that only a subset is ever visible.
2. Present information, don't just map it to the file. For example, maybe you physically store a color as "r: 0.6, g: 1.0, b: 0.75", but you wouldn't give the user an R field, G field and B field: you'd show the actual color, and allow editing in any way supported by the system (e.g. on a Mac you can enter CMYK, or even pick crayons!).
3. De-jargon your terminology. For example, if your file says "alpha: 0.7", your GUI should say "transparency" or "opacity" and use a slider with a live graphical sample or other more intuitive method to set the fraction.
4. Avoid editing strings most of the time. Even if a setting "can" have any value, it is often useful to give the user a menu of common values with an option to add anything else they want. For example, why not keep track of recent values a person has been using?
5. Don't force users to use your crappy text editor for really complex stuff. Usually, if your file format is at least plain text, this is avoidable. But if you store some huge paragraph of text in a database I can't see, and your GUI gives me the crappiest editor imaginable as the only way to change it, then your GUI is causing more problems than it solves (and the real project should have been to write a text importer for your opaque database).
Jack Thompson is someone best ignored. I think it is better to stop making headlines every time he goes off his rocker, and let him not be heard, than to give him free publicity for his stunts.
Rulemakers like the TSA need to be forced to explain the rationales for every decision.
But, before they're allowed to get all legalese on us, there should also be a brevity requirement. Like the Nutrition Facts on the side of your average can of soup, probably one of the best examples I can think of where a government requirement *didn't* turn into 4 paragraphs of fine print, but rather is presented in a way Joe Sixpack can understand.
I'd like to see something like:
TSA Security Facts
--------------
Restriction: No lithium batteries.
Applies to Flights: International
Rationale: We don't have a clue but we read something bad about them in Newsweek.
Since: 2007
Terrorist Plots Known to Use This Method: 0
It seems these days, and not just with Microsoft, products are screwing up a lot more of the "basics". The kind of bugs that make you not even bother trying to find the source of a problem in higher level software, because you've stopped trusting that the foundation has been properly tested!
I'm not sure why...maybe testing these basics is boring, maybe money is never put into it, or maybe companies are trying to see how sloppy they can be with its beta te...uh I mean customers, without losing revenue.
But professionally speaking, this stuff is scary. It hints at major regression testing holes in software processes we can't see, that society depends on crucially. Yes, software is infinitely complex, yada yada, but at the end of the day you *can* make at least these kinds of problems go away, and a multi-billion-dollar corporation sure as hell can be expected to minimize them. Maybe society needs to demand more from its software providers, and not just sit still when "basic" assumptions about software reliability aren't met.