The branding is done at the manufacturer, though. Silkscreening is done at the same time as manufacturer logos, and firmware preload is done at the manufacturer.
On a transflective screen, external light goes through the color filters twice, as they're in front of everything. On this, the color filters are between the backlight and the actual liquid crystal setup. Therefore, with the backlight off (or with ambient light that overwhelms the backlight,) the contrast is equivalent to a (quite excellent) monochrome display - but it IS a monochrome display at that point.
No, you haven't had to get "into the layers of the LCD" for many, many years. It's a sealed unit, and a commodity one at that. Remove old panel, put new panel in.
I just turn Flash off, except on sites that need it. (Actually, all plugins - Opera is all or nothing for a given site.)
And, one tech site that I'm on (come to think of it, it spun off of Ars circa 2000) actually watches the forums for complaints about the ads (from their content, to CPU hogging Flash, to unsolicited sound (maybe all sound, I forget.))
That argument breaks down horribly in a representative democracy, especially if it's one that uses plurality voting, but even in representative democracies that use "ungameable" voting systems, you still don't get a direct say, and someone who shares all of your viewpoints may not exist, and may not desire to run for office.
Require the user to contact tech support and have them remotely access the machine to close it. If the machine has no active network connection, or remote access would cause a security problem, then do it Windows activation style: they read off a code containing the error, or type it into their phone, tech support gives them a code and then walks them through the problem.
GEOS UIs are, as I understand, somewhat like HTML+CSS forms in function (that is, you define your window elements by function, and then the system places them according to window size, screen size, and such.)
Here's the thing. You can also define your functions by how "complex" they are for a user, and then, each program can be run at different "levels" of complexity. So, newbies get a drastically stripped down UI, intermediate users get a lightly stripped down UI, experts get the full thing. Same program, and it takes just a couple clicks to change levels. Oh, and you can customize the available functions, too, if you're, say, a newbie, but need some function available in the expert level.
Of course, because it's rendering the UI dynamically, it just doesn't render the elements that are from higher levels.
Therefore, you can pander to the idiots of the world, while not negatively affecting those who have clue.
Use standarized colors for the ethernet and phone cables.
Assume that the user knows what an RJ-11 port looks like.
Now...
Ethernet port: "That thing that looks like a fat phone jack" Ethernet cable: "The blue cable" (if that's your standard) or, if you have no standard, "the one that doesn't fit in a phone jack, but looks like a phone cable." Telephone port: We already determined that the user knows that. Telephone cable: "The light grey cable with a phone plug on the end" USB port: "The small rectangular one" USB cable: "The one with a small rectangular plug"
Keep in mind that I've read plenty of stories of people shoving TI-89 motherboards and LCDs into TI-83 cases to cheat on tests. So, the extremes have been gone to, even using 100% TI parts, no homebrew anything. (It's not hard, though, as the TI-83 uses the exact same physical case as the TI-89. The only problems you'd have are that the buttons wouldn't match up with their actual functions, and the LCD is higher resolution, and an observant teacher may notice that something's "off.")
Also, you could wire the reset button to another pin on the CPU. The stuff I'm talking about doesn't even involve the OS at all, it's done purely in user software, sometimes even in BASIC (although the good ones are assembly, because you can break out of any BASIC program, using a standard key sequence, IIRC) - a program that simulates the entire UI of the calculator's OS, and behaves exactly like the calculator would when being reset, showing an empty calculator at the end of the reset.
So, in such a situation... your user program checks for, say, the serial link to go active. The serial link is connected to the reset button, of course. When it goes active, the resulting interrupt (I'm not sure if serial traffic causes an interrupt on a TI, this is just an example - you could poll it, for that matter) will cause the app to go into its simulation of a cleanly reset device.
Except that's where a carefully written fake UI program that pretends to wipe the calculator memory when the teacher goes through the menus comes in handy. Special key combo, calc drops into the real UI, and all of your stuff is intact.
(Or, if the calc's an HP 49g+ or 50g, you can just move everything off to an SD or MMC card, pocket the card before going into the class, and after resetting and going to your desk, insert it.)
Of course, in a manual TDI, if it gets smoky as hell while doing this, turning the key off doesn't work, and you can safely do it, get to a high gear, and then jam the brakes on hard while in gear. You've either got a car that doesn't weigh anything (Mk3) or a car with four disc brakes, and it can stop itself against the engine (even when the engine's running away) just fine.
Then, you might save the engine AND yourself.
(Being a diesel, it can run on its own engine oil, so if something happens to cause engine oil to end up in the intake (usually turbo failure,) you need to cut the air supply (try turning the key off on a Mk4 or Mk5 - not a bad idea on a Mk3, either, because you'll at least cut the normal fuel, but not the wrong fuel,) and if that doesn't work, you need to load the engine to the point that it stalls out, hence the brakes. In an automatic, if cutting the air doesn't work, you're screwed - the torque converter can't work backwards, so might as well go into neutral and let the engine destroy itself.)
Park -> Reverse -> Neutral -> Drive -> (lower gears - these are sometimes laid out in different ways.)
Sometimes it's a gated shifter, but just as often, it's a straight shifter - push in a button, shifter can slide anywhere in the travel.
But, most cars nowadays use an electronic shifter, rather than cables to the transmission. Jamming the shifter into park is bad, so software can detect this and ignore the input until the vehicle's stopped. On the downside, apparently this means that not having valve float from a mild engine overrev from suddenly removing load from an engine on the rev limiter (by putting it into neutral) is more important than their customer's lives.
And, the torque converter wouldn't slip in such a condition, it would just spin. "Slippage" would only occur if the torque converter were stalled - that is, if there were so much force that the engine side of the torque converter couldn't overcome the load of turning the transmission side, or if the transmission was turning faster than the engine.
Mechanical throttle? Sure about that? They're electronic on almost everything now. If there's not a steel cable going from the accelerator pedal to the throttle body or injection pump, it's electronic throttle.
Service brakes are (except for, IIRC, a couple years of Mercedes that were epic fail, and are no longer sold) always able to function mechanically. Parking/emergency brakes are moving towards electronic push-button actuation, though.
Gear selection is electronic on most stuff nowadays.
Your key almost certainly does physically disconnect power to the ignition system, though. There's usually three rails of +12V in a car: always-on +12V, key-on +12V, and starter +12V. Relays control where things go from there. So, there's a timed relay (or similar) that's on always-on +12V and is switched by key-on +12V. Key-on +12V goes away, accessory power goes away 5 minutes later. The ECU (and ignition system, if present) won't be on that accessory power relay.
The problems theoretically affect all cars that Toyota sells, but I'm guessing that well over 90% of their cars (at least in the US) are automatics, and manuals provide more ways to stop an unintended acceleration incident.
I know VW's implementation of a brake override only kicks in if you hit the accelerator before the brake - hitting the brake, then hitting the accelerator won't cause the accelerator to be locked out, IIRC, at least on manual cars.
And my 86 Golf diesel had its idle set a touch LOWER than it should've been.
For that matter, in my Miata, which has nothing at idle, I'm letting off the clutch and moving off the brake onto the gas in the same motion. Granted, that's because I'm very familiar with how it responds to things, so I know how I have to do things to not cause excessive wear, and not roll back.
The thing is, the two-footed driver doesn't know to put it in neutral.
And, I've heard rumors that sometimes, you can't get into neutral while moving at freeway speed.
And, the fatalities in question were in cars with push-button ignition, so you couldn't just turn the key off - and the push-button is ATX-style for killing power when not in park.
(One nice thing, BTW, about every car I've owned - two VWs, a Honda, and a Mazda - is that there is no lock position. Off, accessory, on, start. To lock the wheel, turn the key to off and remove the key. It unlocks when you reinsert the key and turn it back to on.)
Or, you could include the ZFS source code and the Linux kernel source, and build a Linux+ZFS on installation of the OS, I guess. Problem is, you'll have to have a scratch disk to do this on, and then boot off of that scratch disk to partition and install. Or, use FUSE. Or, use a BSD for the installer.
Remember that the entertainment system will have a horrendously bloated GUI, on a luxury car.
Oh, and on a luxury car, central convenience will also have control over seat massagers and such. HVAC and central convenience will have control together over seat heating and cooling. Entertainment will talk to the safety computer to control suspension settings.
Slashdot Mirror
The branding is done at the manufacturer, though. Silkscreening is done at the same time as manufacturer logos, and firmware preload is done at the manufacturer.
This isn't an ordinary transflective screen.
On a transflective screen, external light goes through the color filters twice, as they're in front of everything. On this, the color filters are between the backlight and the actual liquid crystal setup. Therefore, with the backlight off (or with ambient light that overwhelms the backlight,) the contrast is equivalent to a (quite excellent) monochrome display - but it IS a monochrome display at that point.
No, you haven't had to get "into the layers of the LCD" for many, many years. It's a sealed unit, and a commodity one at that. Remove old panel, put new panel in.
I've heard claims that 15.4" and 17" MacBook Pros have IPS displays.
Also, ThinkPad X201 Tablets have PVA displays.
I just turn Flash off, except on sites that need it. (Actually, all plugins - Opera is all or nothing for a given site.)
And, one tech site that I'm on (come to think of it, it spun off of Ars circa 2000) actually watches the forums for complaints about the ads (from their content, to CPU hogging Flash, to unsolicited sound (maybe all sound, I forget.))
That's one of the exceptions, but in practice, the racism would have to be proved in a lawsuit.
PayPal, being a business, also has the right to refuse any business they want.
Freezing funds gets screwy, though.
The thing is, in Europe, wire payments seem to work quite well for this sort of thing.
It's just that here, domestic wire payments only make sense for transfers in the thousands of dollars.
What about not playing it at all? Don't buy it, don't pirate it. That'll kill them financially, and kill their mindshare.
Only if it's a direct democracy.
That argument breaks down horribly in a representative democracy, especially if it's one that uses plurality voting, but even in representative democracies that use "ungameable" voting systems, you still don't get a direct say, and someone who shares all of your viewpoints may not exist, and may not desire to run for office.
No, that allows clicking through.
What I'm saying is to make SOMEONE ELSE interpret the error and dismiss it.
Obviously, this would only work in corporate environments.
Make it more modal, not less modal.
That is, don't allow the user to close it.
Require the user to contact tech support and have them remotely access the machine to close it. If the machine has no active network connection, or remote access would cause a security problem, then do it Windows activation style: they read off a code containing the error, or type it into their phone, tech support gives them a code and then walks them through the problem.
What about something like the GEOS approach?
GEOS UIs are, as I understand, somewhat like HTML+CSS forms in function (that is, you define your window elements by function, and then the system places them according to window size, screen size, and such.)
Here's the thing. You can also define your functions by how "complex" they are for a user, and then, each program can be run at different "levels" of complexity. So, newbies get a drastically stripped down UI, intermediate users get a lightly stripped down UI, experts get the full thing. Same program, and it takes just a couple clicks to change levels. Oh, and you can customize the available functions, too, if you're, say, a newbie, but need some function available in the expert level.
Of course, because it's rendering the UI dynamically, it just doesn't render the elements that are from higher levels.
Therefore, you can pander to the idiots of the world, while not negatively affecting those who have clue.
Use standarized colors for the ethernet and phone cables.
Assume that the user knows what an RJ-11 port looks like.
Now...
Ethernet port: "That thing that looks like a fat phone jack"
Ethernet cable: "The blue cable" (if that's your standard) or, if you have no standard, "the one that doesn't fit in a phone jack, but looks like a phone cable."
Telephone port: We already determined that the user knows that.
Telephone cable: "The light grey cable with a phone plug on the end"
USB port: "The small rectangular one"
USB cable: "The one with a small rectangular plug"
Keep in mind that I've read plenty of stories of people shoving TI-89 motherboards and LCDs into TI-83 cases to cheat on tests. So, the extremes have been gone to, even using 100% TI parts, no homebrew anything. (It's not hard, though, as the TI-83 uses the exact same physical case as the TI-89. The only problems you'd have are that the buttons wouldn't match up with their actual functions, and the LCD is higher resolution, and an observant teacher may notice that something's "off.")
Also, you could wire the reset button to another pin on the CPU. The stuff I'm talking about doesn't even involve the OS at all, it's done purely in user software, sometimes even in BASIC (although the good ones are assembly, because you can break out of any BASIC program, using a standard key sequence, IIRC) - a program that simulates the entire UI of the calculator's OS, and behaves exactly like the calculator would when being reset, showing an empty calculator at the end of the reset.
So, in such a situation... your user program checks for, say, the serial link to go active. The serial link is connected to the reset button, of course. When it goes active, the resulting interrupt (I'm not sure if serial traffic causes an interrupt on a TI, this is just an example - you could poll it, for that matter) will cause the app to go into its simulation of a cleanly reset device.
Except that's where a carefully written fake UI program that pretends to wipe the calculator memory when the teacher goes through the menus comes in handy. Special key combo, calc drops into the real UI, and all of your stuff is intact.
(Or, if the calc's an HP 49g+ or 50g, you can just move everything off to an SD or MMC card, pocket the card before going into the class, and after resetting and going to your desk, insert it.)
Did they fix it in 4.0c? Because I recall doing exactly that and the plane just bouncing.
Of course, in a manual TDI, if it gets smoky as hell while doing this, turning the key off doesn't work, and you can safely do it, get to a high gear, and then jam the brakes on hard while in gear. You've either got a car that doesn't weigh anything (Mk3) or a car with four disc brakes, and it can stop itself against the engine (even when the engine's running away) just fine.
Then, you might save the engine AND yourself.
(Being a diesel, it can run on its own engine oil, so if something happens to cause engine oil to end up in the intake (usually turbo failure,) you need to cut the air supply (try turning the key off on a Mk4 or Mk5 - not a bad idea on a Mk3, either, because you'll at least cut the normal fuel, but not the wrong fuel,) and if that doesn't work, you need to load the engine to the point that it stalls out, hence the brakes. In an automatic, if cutting the air doesn't work, you're screwed - the torque converter can't work backwards, so might as well go into neutral and let the engine destroy itself.)
Where are you?
Here in the US, it's usually:
Park -> Reverse -> Neutral -> Drive -> (lower gears - these are sometimes laid out in different ways.)
Sometimes it's a gated shifter, but just as often, it's a straight shifter - push in a button, shifter can slide anywhere in the travel.
But, most cars nowadays use an electronic shifter, rather than cables to the transmission. Jamming the shifter into park is bad, so software can detect this and ignore the input until the vehicle's stopped. On the downside, apparently this means that not having valve float from a mild engine overrev from suddenly removing load from an engine on the rev limiter (by putting it into neutral) is more important than their customer's lives.
And, the torque converter wouldn't slip in such a condition, it would just spin. "Slippage" would only occur if the torque converter were stalled - that is, if there were so much force that the engine side of the torque converter couldn't overcome the load of turning the transmission side, or if the transmission was turning faster than the engine.
Mechanical throttle? Sure about that? They're electronic on almost everything now. If there's not a steel cable going from the accelerator pedal to the throttle body or injection pump, it's electronic throttle.
Service brakes are (except for, IIRC, a couple years of Mercedes that were epic fail, and are no longer sold) always able to function mechanically. Parking/emergency brakes are moving towards electronic push-button actuation, though.
Gear selection is electronic on most stuff nowadays.
Your key almost certainly does physically disconnect power to the ignition system, though. There's usually three rails of +12V in a car: always-on +12V, key-on +12V, and starter +12V. Relays control where things go from there. So, there's a timed relay (or similar) that's on always-on +12V and is switched by key-on +12V. Key-on +12V goes away, accessory power goes away 5 minutes later. The ECU (and ignition system, if present) won't be on that accessory power relay.
The problems theoretically affect all cars that Toyota sells, but I'm guessing that well over 90% of their cars (at least in the US) are automatics, and manuals provide more ways to stop an unintended acceleration incident.
I know VW's implementation of a brake override only kicks in if you hit the accelerator before the brake - hitting the brake, then hitting the accelerator won't cause the accelerator to be locked out, IIRC, at least on manual cars.
It also works pretty well on diesels.
And my 86 Golf diesel had its idle set a touch LOWER than it should've been.
For that matter, in my Miata, which has nothing at idle, I'm letting off the clutch and moving off the brake onto the gas in the same motion. Granted, that's because I'm very familiar with how it responds to things, so I know how I have to do things to not cause excessive wear, and not roll back.
The thing is, the two-footed driver doesn't know to put it in neutral.
And, I've heard rumors that sometimes, you can't get into neutral while moving at freeway speed.
And, the fatalities in question were in cars with push-button ignition, so you couldn't just turn the key off - and the push-button is ATX-style for killing power when not in park.
(One nice thing, BTW, about every car I've owned - two VWs, a Honda, and a Mazda - is that there is no lock position. Off, accessory, on, start. To lock the wheel, turn the key to off and remove the key. It unlocks when you reinsert the key and turn it back to on.)
Technically, it's BSD-compatible open source.
Or, you could include the ZFS source code and the Linux kernel source, and build a Linux+ZFS on installation of the OS, I guess. Problem is, you'll have to have a scratch disk to do this on, and then boot off of that scratch disk to partition and install. Or, use FUSE. Or, use a BSD for the installer.
Remember that the entertainment system will have a horrendously bloated GUI, on a luxury car.
Oh, and on a luxury car, central convenience will also have control over seat massagers and such. HVAC and central convenience will have control together over seat heating and cooling. Entertainment will talk to the safety computer to control suspension settings.
It goes on and on.