Not only is that the case, but the x86 ISA actually turns out to be a useful input to the RISC pipeline, in terms of providing profiling hints to the instruction scheduler for the RISC engine, and it works well for the case of a processor with a million general-purpose registers, because the ISA doesn't have to provide ways to name all of them. A CISC-to-RISC decode stage generally works better than a RISC-to-other-RISC decode stage, and you always need a converting decode stage, because you're going to change your microarchitecture all the time. Having a CISC architecture isn't bad for the code generation side, assuming that the instructions you want are available, and assuming that the performance is like RISC (i.e. instruction fetch isn't a big deal and the time you use depends on the number of operations in the instruction's description).
The 8086 architecture was lousy, but the current x86 ISA is pretty good, and the x86_64 ISA is better. These aren't sane to implement directly, but they're great as the source for translation.
We had an LED-based light bulb for a while. After only a few years, somebody broke off half of the bulb. Of course, it kept working until we replaced the fixture with a porch.
So long as the manufacturer distributes firmware freely (and they generally do, so they can distribute new firmware versions), it's no problem for drivers regardless of OS to load that firmware onto the device. It's generally about the easiest device function to implement. Linux has a standard mechanism for the kernel to get the firmware from userspace.
It's a bit of a pain if the manufacturer doesn't allow redistribution of the firmware, because it means your brand-new wireless card doesn't work until you've got network to download the firmware, but that's a relatively minor issue (and they generally have a CD containing the correct file if you buy a card).
It's a lot more of an issue that manufacturers don't document how to use the device at a hardware level in general, and card manufacturers often give completely unrelated hardware exactly the same name. So it's hard to tell what driver to use, and whether there is a driver for the device. Then there's the issue that most internal modems these days are actually sound cards with phone-line I/O, and the OS is supposed to play the right sound onto the phone line. (Which is lame, but things are coming along for handling it.)
But the need to send a file you can get to the device before it will do stuff isn't really a big deal. I'm actually posting this with a Wifi chipset (ipw3945) that requires firmware, which was automatically handled by Linux (Gentoo), and the firmware is completely independant of operating system, processor architecture, or really anything outside the device.
Our shared libraries support useful versioning. A program gets linked against a library by name, but it records the major version of the library that it used. When you run it, it looks for the newest library with that name and major version. Libraries get new major versions when they change in non-backwards-compatible ways and only new minor versions for bug fixes and backwards-compatible improvements. Also, when a version is supposed to be backwards-compatible, it's generally actually backwards-compatible.
DLLs are only bad because you can't set up a system with a sufficiently complete collection of them at the same time that every program will get the DLL it needs. Just because Microsoft's implementation of something is terminally broken doesn't mean it's not otherwise a great idea.
You're talking about a system you glue to your furniture with a main character who looks like you. It's also not big on speculation, because the target market is mostly not rabid gamers, and normal people are willing to wait a few weeks for systems to be available. So there are probably very few people who got Wiis who didn't actually want them, and few people who want to return them after playing with them.
At least until recently, there was a high rate of expeditions that had to turn back due to weather or other issues, and everybody made it back okay. So it could be accurate that a climber has a 2% chance of dying, a 20% chance of making it to the summit, and a 78% chance of being turned back by conditions, which would fit both sets of statistics. I haven't reanalyzed the statistics from that paper (and note that the 1 in 10 is only for spring), but it's not too far off. And an error of 25% is surprisingly low for science reporting in mainstream news, which is usually off by at least 1000%.
I went to MIT, so I can explain a bit about the culture in which this research was done.
First of all, there's always something you're supposed to be doing. If you have three assignments for a class due at the end of term, you'll definitely have more important things to get done all term, and then you won't have enough time at the end of term to do the assignments. Even if you didn't do anything fun all term, you'll have procrastinated by getting more of each of the assignments for other classes done than you would have had you worked on the end-of-term assignment earlier. It's really hard to give up on an assignment that's due tomorrow because you haven't started on the one due in two months. It's not just that you have a more immediate reward if you procrastinate the stuff that's not due tomorrow; the reward is calculated and reported to you in advance in percentage points, and you definitely lose those points if you don't go after them immediately.
Also, assignments are designed for maximizing the standard deviation, which gives the most detail for grading. This is achieved by having the average be 50. This, in turn, means that, if you're doing fine, you could do twice as much work and still not get everything done. And you could check over your answers if you really wanted to, and take even more effort. So it's not like you're ever done with all your upcoming assignments and have time to work on the long-range ones.
Also, the main risk isn't doing badly in classes or failing them, it's going insane. If you pass any of your classes (or even if you don't, really), you're better of than if you have to take a term off. So doing something fun and relaxing can actually be quite important. I heard claims that sleeping at night sometimes helps, too, but I didn't try that. Relaxing when you need to is always on a shorter deadline than the end of the term, so it takes precedence.
And, of course, every class has something or other due at the end of the term (or a final just after classes end). You're in trouble if you've got three things due for this class at the same time as every other class has some project or exam.
So the optimal strategy is probably to choose deadlines around when your other classes have big assignments and exams, and stick to those deadlines, but tell the professor you'll have everything in at the end of term (but then forget that you didn't specify your deadlines).
The thing I'd find most interesting is how many students chose to have the deadlines at the end of term, but then turned in the first assignment in the first half of the term.
The blurb is misleading. The EPA is changing the test to have a driving profile which prevents hybrids with all-electric modes from using those modes. It's also closer to how someone who's not optimizing their hybrid's gas mileage will drive, so it more accurately reflects what you're likely to get if you just look at the mileage stickers and buy a car, and don't change your driving habits to get the most out of it.
Maybe they ought to add a test for how good your mileage can be under a reasonable set of conditions if you drive efficiently as possible within loose constraints, so that people know whether it's worth bothering to try, but the new test makes more sense for the main number on the sticker.
I think I saw a story in which Nicolas Negroponte was talking about the event, and I misremembered the responsibility.
Re:We keep hearing rumors!
on
The Google Phone?
·
· Score: 2, Insightful
They'll release it when they can get a cellphone chipset in quantity for less than their profit margin on iPods at the time (after the costs of their components have come down over the course of a product cycle). Then they decide that what they'll announce as the difference between iPod generations is that the new ones are incidentally unlocked GSM cell phones.
Alternatively, if they decide people want them enough, they do a generation where the storage difference between the $350 and $250 iPods is less, but the $350 one is a cell phone.
In any case, I bet that Apple will never release a device marketted as a cell phone, because people expect cell phones to be locked, and sold cheap by carriers, and Apple isn't going to want to play that game for a variety of reasons. Nobody's going to pay $350 for an Apple cell phone that plays music, but they'll buy a $350 iPod that makes phone calls, even though these are logically the same device at the same price.
The screen is small in total size, probably has a lot of dead pixels (which are tiny, so who cares?) and doesn't have good color accuracy or consistency. There was an article a while back about how the OLPC project visionary went to an LCD manufacturer and told them that the OLPC screen didn't need any of the features that make LCDs expensive to make, and did need a bunch of different features. They laughed at him, and then he told them that he wanted quantities of millions, and they were suddenly very nice.
The number of LCDs which need to be produced to get a single LCD that works perfectly is exponential in the physical area of the screen, because defects are independant, based on the size of the crystal, and cannot be repaired. This factor means that a "stunning" tiny screen is a whole lot cheaper than a big screen of worse image quality. The OLPC computer is actually smaller than the pictures make it look, because the whole thing is uniformly child-sized.
There are two designs for a dimmer. One is just a variable resistor, which reduces the voltage by just burning the power the light would have used. The other clips the voltage at the specified point (IIRC, it's a triac), so instead of having a nice sine wave, you have this weird truncated thing. That'll save power, although it will seriously mess with anything that needs AC (a light bulb is actually non-polar DC, but if there's a fan in the fixture, you'll probably blow something up), and it's only recently cost-effective to produce.
Recent flash devices do write-leveling internally in hardware. The necessary logic isn't all that complicated, and it's not that different from the logic needed to handle modern hard drives, which remap bad blocks internally. Flash devices are often removable, and people generally use FAT on removable storage (for compatibility and ease of implementation), and FAT does a whole lot of writing to a few sectors. So flash device manufacturers wanted to make their devices not seem unreliable and implemented write-leveling. Bare flash chips don't do it, but it's simpler to implement than the protocols that the devices support (USB, SD, or CF, generally).
ccording to the GPL: "The source code for a work means the preferred form of the work for making modifications to it." Open source applies just as well to fields other than software, but there are a lot of fields in which it is not valuable to the user. There are a lot of types of works where the creation of a modified work is meaningless, because what matters is a particular official version (anyone could create a modified US Constitution, but only the original has any particular force). And there are some where people might create a new work with some relation to the original, but none of its content (if you want to do an alternative ending for Peter Pan, for example, you don't need the source to the original beginning).
So, if you want to have your own laser-engraving business, and you want to do things differently, you have "the source" if you have whatever Adafruit would modify to make the same changes you want to make.
Because it's really hard to write a Java applet that doesn't break user expectations for content inside the browser window. If you do it all with a Java applet, you break the "text size" menu items, the back button, bookmarks, the print menu item, and so forth. If you use AJAX correctly, all of these work (better even than without AJAX, because it makes "next" and "previous" buttons on a big list act like scrolling through it, rather than being additional history items). People want to use web sites like web sites, but with extra-clever controls, not like desktop applications. Java applets are inherently objects embedded in web pages, not integrated with the browsing interaction.
I've got a brand-new washing machine, and the interface is actually quite nice. On one side, it's got a power button, a door button (it's a front-loader, so if you want to interrupt the cycle, it needs to drain the water before opening the door), the start button, and buttons for a couple of special features. On the other side, there's a button to select the profile, and a bunch of buttons to select smaller aspects of the profile. (So you select "normal" or "delicate" or "silk" or "sanitize", and then you can set the water temperature and the spin cycle speed and such, limited to the range that makes sense for the profile.) In the middle, there's a display that shows exactly what it's going to do: water temperature, spin speed, etc. It also has a display of the time remaining (which is an estimate initially; it depends on how much laundry you put in, which it detects automaticly when it fills, and updates the display accordingly.) The little displays show you the absolute settings of parameters you care about (the temperature display is the actual temperature, not the temperature relative to the profile; if you're on sanitize, it's always somewhere at the top, and delicate always puts it near the bottom, so you see things in terms that match the care instructions on clothes).
I think Donald Norman would actually like it a lot. All of the controls directly affect visible state, and they're labelled in an obvious fashion. All of the buttons that do things you don't want to do are clearly not the button you're looking for. The buttons you care about for configuration are in order by significance. If all your laundry is the same, you just put it in and press start. If you have two kinds, you select the appropriate profiles. If you want to do something slightly differently, you can change that independantly.
It's got a lot of features, but it's still simple in the sense that you can easily ignore all the buttons for features you're not using, just like you ignore the part of the washing machine that isn't the control panel. It does a good job of hiding the complexity, because you have only a small set of options that you have to consider at any given time, and you can interpret each display without considering any of the other displays. It's also got bullet-point features that don't impact the interface at all (after the spin cycle, it rotates the drum half a turn in the opposite direction to loosen the clothes; there's no control for this).
Re:A good reason to move to IPv6
on
Map of the Internet
·
· Score: 2, Interesting
Latecomers to the internet, like Harvard and Africa, have their networks structured such that they don't need huge numbers of IP addresses. When MIT originally set up their network, their routing was done by IP address block, so the routers could all decide where to send packets based on a single octet. So, if you have one computer in a location without any other computers, it gets 65536 addresses. Furthermore, the original routing between sites was simplified greatly by having the first octet dictate which site would get the traffic, so it would have been very difficult to give MIT or Federated less than 16777216 addresses, because traffic for all of those addresses would be routed through a single link to the rest of the internet.
These days, any infrastructure device is perfectly capable of looking up addresses in a table, and can discover and store the mappings for your whole network with no trouble at all. With this sort of hardware (which is all that's still available), each computer only needs one address. When there are 16 million computers in Africa on the internet, they can have more addresses. For that matter, MIT would give up most of their addresses if there was a shortage; last time I checked, only 18.*.0.* was generally used.
The real reason to go to IPv6 is not that there aren't enough addresses for everybody, but rather that there aren't enough addresses to not have to worry about allocation. With IPv6, every NIC that'll ever be created can have its own IP address (based on its MAC), plus addresses it gets by being connected through a router, private addresses, loopback, and so forth. There are useful effects of having so many addresses total that you can assign large spaces of them for purposes other than just having an address for each device on the internet.
The screenshot for Jurassic Park looks like a normal Irix screen. But what anybody who actually watched that part of the movie noticed was that the screen in the movie was some weird flying-through-a-virtual-reality-landscape thing, which the kid immediately recognized as UNIX. Almost everybody with actual UNIX experience just laughed at that, because it was classic a Hollywood computer representation. Except that it really was Irix, but running a window manager only available to people whose UNIX system had superfluous accelerated 3D graphics in 1995 (i.e., movie CG folks). What the audience couldn't see, but the kid would have been able to, was that the landscape had, written on the ground, things like "sbin" and "usr", clear signs of a UNIX system of some sort. As for breaking in, when dinosaurs are taking over your facility, chances are you aren't patching sendmail every day. And, in '95, that would have been a problem.
Li-ion cells blow up if you short them, and aren't considered safe to distribute to consumers. What you get are Li-ion battery packs with bunch of protection circuitry and an armored case that keeps the protection circuitry from being bypassed if you drop your laptop. This armor takes up a non-trivial amount of the weight and volume of a battery pack.
A Li-poly battery pack is going to be about the same in terms of weight and volume for a given capacity. It's be somewhat easier to break (no armor), but it won't blow up if you break it (or if the protection circuit is defective). Of course, if you have a very large battery, Li-ion will be more efficient, because the armor is by surface area and the energy is by volume; but if you have a very small battery, Li-ion is impossible, because there's no room for the cell inside the required armor.
This was largely an internal HP thing; half of the people spied on are on the HP board of directors. They're not going to want to mire the corporate entity in litigation. As far as reforming HP, shifting the balance of power to the people who were spied on is far more effective than any sentence that could be carried out on humans.
And the criminal cases are unaffected. That's what matters in the end; this was a case of criminal behavior by individuals in control of a company, not corporate policy.
RFID is getting to be like VoIP: there are a wide variety of applications which fit the acronym but are otherwise unrelated, and people lump them together. These bank cards and inventory tags in clothing have about as much similarity to each other as they have to 802.11. They use radio waves, and they use identification.
A well-designed smart bank card will use SASL to prove its identity to the bank without revealing information that would allow anybody else to use the identity. So it doesn't matter if people can snoop the transmission; they don't find out anything that they can use anyway. And it would use some mechanism (probably a capacitive contact sensor) to detect that somebody's touching it, and only authenticate then.
A particularly well-designed smart bank card would have a touch-sensor keypad, such that you type your PIN into the card to get it to authenticate you to the bank, and the ATM doesn't even find out the PIN. This wouldn't work with magnetic cards, because the card can't interact with both the user and the ATM at the same time, so RFID is needed for improved security of that sort.
Of course, the dumb, buzzword-compliant way to have RFID bank cards would be to just have them broadcast your card number to anyone who happens to ask. But that doesn't actually offer any advantage over magnetic stripes, aside from using a term that most people don't recognize, and those who do find scary. Of course, they could offer the advantage of not having to get out the card when you use it. But since you might have two different cards, you need to somehow tell the one you're not using to stop responding, or tell the one you are using to transmit. So you're holding the thing, and you might as well make physical contact between the card and the machine at that point, since you'll have to touch the machine yourself to type the PIN.
OpenID allows some unknown server to authenticate you to its own satisfaction. That is, if slashdot wants to prohibit random people from posting as iabervon@livejournal.com, such that only someone able to post to livejournal.com as iabervon@livejournal.com can post with that attribution, it can use OpenID to find out. (And OpenID does this in such a way that the site that's required authentication can't turn around and steal your identity.)
But it doesn't have a mechanism for the unknown server to prove that you did something to anybody else. There's no way built in to keep slashdot from fabricating comments as being from a particular livejournal user, even if the livejournal user never authenticates to slashdot, and even if slashdot readers try to verify the comments. There's no signature mechanism, so there's no way to tell if it was actually used at all, or if it was used properly. This obviously means that it's useless for ecommerce, because there's no way for the store to demonstrate that you authorized a purchase.
The interesting thing would be if somebody came up with a system whereby a site could present something for a signature by some OpenID user, such that the user can tell what's being signed, nobody other than that OpenID user can create the signature, and the signature can by verified by anybody who wants to check. That would be the real killer app for OpenID, because then you'd be able to do really secure online purchases. It would be more secure than the current system (the store currently gets enough information to fabricate other purchases by you), as well as using a single sign-on: when you purchase something, the store presents a receipt in a standardized format, and you sign it with the OpenID issued by your bank. The store presents it to the bank for payment, and gets paid. You reveal your bank username, but that doesn't let anyone do anything. You carry out your proof-of-identity and proof-of-intent exclusively with your bank, which you trust.
Magnatune.com has music that's non-DRMed and available for download at CD quality (although not by the track; keeping track of who can get what for individual tracks is more trouble than it's worth for a small site). Of course, it's all independant artists, but you clearly don't like the major label music anyway. And, if you'd like, you can pay a little more (or not).
So you hand count any election that a candidate thinks was close. You've got the actual ballots (and the best thing about optical scan is that all of the ballots it accepts are correct and obvious; otherwise it spits the ballot back out). The main benefit of counting with the scanner is that the results are available immediately, so people can get on with things. If somebody rigs the immediate results, this is revealed the next week, the result is corrected, and they investigate. It doesn't matter to the outcome of the election.
Slashdot Mirror
Not only is that the case, but the x86 ISA actually turns out to be a useful input to the RISC pipeline, in terms of providing profiling hints to the instruction scheduler for the RISC engine, and it works well for the case of a processor with a million general-purpose registers, because the ISA doesn't have to provide ways to name all of them. A CISC-to-RISC decode stage generally works better than a RISC-to-other-RISC decode stage, and you always need a converting decode stage, because you're going to change your microarchitecture all the time. Having a CISC architecture isn't bad for the code generation side, assuming that the instructions you want are available, and assuming that the performance is like RISC (i.e. instruction fetch isn't a big deal and the time you use depends on the number of operations in the instruction's description).
The 8086 architecture was lousy, but the current x86 ISA is pretty good, and the x86_64 ISA is better. These aren't sane to implement directly, but they're great as the source for translation.
We had an LED-based light bulb for a while. After only a few years, somebody broke off half of the bulb. Of course, it kept working until we replaced the fixture with a porch.
So long as the manufacturer distributes firmware freely (and they generally do, so they can distribute new firmware versions), it's no problem for drivers regardless of OS to load that firmware onto the device. It's generally about the easiest device function to implement. Linux has a standard mechanism for the kernel to get the firmware from userspace.
It's a bit of a pain if the manufacturer doesn't allow redistribution of the firmware, because it means your brand-new wireless card doesn't work until you've got network to download the firmware, but that's a relatively minor issue (and they generally have a CD containing the correct file if you buy a card).
It's a lot more of an issue that manufacturers don't document how to use the device at a hardware level in general, and card manufacturers often give completely unrelated hardware exactly the same name. So it's hard to tell what driver to use, and whether there is a driver for the device. Then there's the issue that most internal modems these days are actually sound cards with phone-line I/O, and the OS is supposed to play the right sound onto the phone line. (Which is lame, but things are coming along for handling it.)
But the need to send a file you can get to the device before it will do stuff isn't really a big deal. I'm actually posting this with a Wifi chipset (ipw3945) that requires firmware, which was automatically handled by Linux (Gentoo), and the firmware is completely independant of operating system, processor architecture, or really anything outside the device.
Our shared libraries support useful versioning. A program gets linked against a library by name, but it records the major version of the library that it used. When you run it, it looks for the newest library with that name and major version. Libraries get new major versions when they change in non-backwards-compatible ways and only new minor versions for bug fixes and backwards-compatible improvements. Also, when a version is supposed to be backwards-compatible, it's generally actually backwards-compatible.
DLLs are only bad because you can't set up a system with a sufficiently complete collection of them at the same time that every program will get the DLL it needs. Just because Microsoft's implementation of something is terminally broken doesn't mean it's not otherwise a great idea.
You're talking about a system you glue to your furniture with a main character who looks like you. It's also not big on speculation, because the target market is mostly not rabid gamers, and normal people are willing to wait a few weeks for systems to be available. So there are probably very few people who got Wiis who didn't actually want them, and few people who want to return them after playing with them.
At least until recently, there was a high rate of expeditions that had to turn back due to weather or other issues, and everybody made it back okay. So it could be accurate that a climber has a 2% chance of dying, a 20% chance of making it to the summit, and a 78% chance of being turned back by conditions, which would fit both sets of statistics. I haven't reanalyzed the statistics from that paper (and note that the 1 in 10 is only for spring), but it's not too far off. And an error of 25% is surprisingly low for science reporting in mainstream news, which is usually off by at least 1000%.
I went to MIT, so I can explain a bit about the culture in which this research was done.
First of all, there's always something you're supposed to be doing. If you have three assignments for a class due at the end of term, you'll definitely have more important things to get done all term, and then you won't have enough time at the end of term to do the assignments. Even if you didn't do anything fun all term, you'll have procrastinated by getting more of each of the assignments for other classes done than you would have had you worked on the end-of-term assignment earlier. It's really hard to give up on an assignment that's due tomorrow because you haven't started on the one due in two months. It's not just that you have a more immediate reward if you procrastinate the stuff that's not due tomorrow; the reward is calculated and reported to you in advance in percentage points, and you definitely lose those points if you don't go after them immediately.
Also, assignments are designed for maximizing the standard deviation, which gives the most detail for grading. This is achieved by having the average be 50. This, in turn, means that, if you're doing fine, you could do twice as much work and still not get everything done. And you could check over your answers if you really wanted to, and take even more effort. So it's not like you're ever done with all your upcoming assignments and have time to work on the long-range ones.
Also, the main risk isn't doing badly in classes or failing them, it's going insane. If you pass any of your classes (or even if you don't, really), you're better of than if you have to take a term off. So doing something fun and relaxing can actually be quite important. I heard claims that sleeping at night sometimes helps, too, but I didn't try that. Relaxing when you need to is always on a shorter deadline than the end of the term, so it takes precedence.
And, of course, every class has something or other due at the end of the term (or a final just after classes end). You're in trouble if you've got three things due for this class at the same time as every other class has some project or exam.
So the optimal strategy is probably to choose deadlines around when your other classes have big assignments and exams, and stick to those deadlines, but tell the professor you'll have everything in at the end of term (but then forget that you didn't specify your deadlines).
The thing I'd find most interesting is how many students chose to have the deadlines at the end of term, but then turned in the first assignment in the first half of the term.
The blurb is misleading. The EPA is changing the test to have a driving profile which prevents hybrids with all-electric modes from using those modes. It's also closer to how someone who's not optimizing their hybrid's gas mileage will drive, so it more accurately reflects what you're likely to get if you just look at the mileage stickers and buy a car, and don't change your driving habits to get the most out of it.
Maybe they ought to add a test for how good your mileage can be under a reasonable set of conditions if you drive efficiently as possible within loose constraints, so that people know whether it's worth bothering to try, but the new test makes more sense for the main number on the sticker.
I think I saw a story in which Nicolas Negroponte was talking about the event, and I misremembered the responsibility.
They'll release it when they can get a cellphone chipset in quantity for less than their profit margin on iPods at the time (after the costs of their components have come down over the course of a product cycle). Then they decide that what they'll announce as the difference between iPod generations is that the new ones are incidentally unlocked GSM cell phones.
Alternatively, if they decide people want them enough, they do a generation where the storage difference between the $350 and $250 iPods is less, but the $350 one is a cell phone.
In any case, I bet that Apple will never release a device marketted as a cell phone, because people expect cell phones to be locked, and sold cheap by carriers, and Apple isn't going to want to play that game for a variety of reasons. Nobody's going to pay $350 for an Apple cell phone that plays music, but they'll buy a $350 iPod that makes phone calls, even though these are logically the same device at the same price.
The screen is small in total size, probably has a lot of dead pixels (which are tiny, so who cares?) and doesn't have good color accuracy or consistency. There was an article a while back about how the OLPC project visionary went to an LCD manufacturer and told them that the OLPC screen didn't need any of the features that make LCDs expensive to make, and did need a bunch of different features. They laughed at him, and then he told them that he wanted quantities of millions, and they were suddenly very nice.
The number of LCDs which need to be produced to get a single LCD that works perfectly is exponential in the physical area of the screen, because defects are independant, based on the size of the crystal, and cannot be repaired. This factor means that a "stunning" tiny screen is a whole lot cheaper than a big screen of worse image quality. The OLPC computer is actually smaller than the pictures make it look, because the whole thing is uniformly child-sized.
There are two designs for a dimmer. One is just a variable resistor, which reduces the voltage by just burning the power the light would have used. The other clips the voltage at the specified point (IIRC, it's a triac), so instead of having a nice sine wave, you have this weird truncated thing. That'll save power, although it will seriously mess with anything that needs AC (a light bulb is actually non-polar DC, but if there's a fan in the fixture, you'll probably blow something up), and it's only recently cost-effective to produce.
Recent flash devices do write-leveling internally in hardware. The necessary logic isn't all that complicated, and it's not that different from the logic needed to handle modern hard drives, which remap bad blocks internally. Flash devices are often removable, and people generally use FAT on removable storage (for compatibility and ease of implementation), and FAT does a whole lot of writing to a few sectors. So flash device manufacturers wanted to make their devices not seem unreliable and implemented write-leveling. Bare flash chips don't do it, but it's simpler to implement than the protocols that the devices support (USB, SD, or CF, generally).
ccording to the GPL: "The source code for a work means the preferred form of the work for making modifications to it." Open source applies just as well to fields other than software, but there are a lot of fields in which it is not valuable to the user. There are a lot of types of works where the creation of a modified work is meaningless, because what matters is a particular official version (anyone could create a modified US Constitution, but only the original has any particular force). And there are some where people might create a new work with some relation to the original, but none of its content (if you want to do an alternative ending for Peter Pan, for example, you don't need the source to the original beginning).
So, if you want to have your own laser-engraving business, and you want to do things differently, you have "the source" if you have whatever Adafruit would modify to make the same changes you want to make.
Because it's really hard to write a Java applet that doesn't break user expectations for content inside the browser window. If you do it all with a Java applet, you break the "text size" menu items, the back button, bookmarks, the print menu item, and so forth. If you use AJAX correctly, all of these work (better even than without AJAX, because it makes "next" and "previous" buttons on a big list act like scrolling through it, rather than being additional history items). People want to use web sites like web sites, but with extra-clever controls, not like desktop applications. Java applets are inherently objects embedded in web pages, not integrated with the browsing interaction.
I've got a brand-new washing machine, and the interface is actually quite nice. On one side, it's got a power button, a door button (it's a front-loader, so if you want to interrupt the cycle, it needs to drain the water before opening the door), the start button, and buttons for a couple of special features. On the other side, there's a button to select the profile, and a bunch of buttons to select smaller aspects of the profile. (So you select "normal" or "delicate" or "silk" or "sanitize", and then you can set the water temperature and the spin cycle speed and such, limited to the range that makes sense for the profile.) In the middle, there's a display that shows exactly what it's going to do: water temperature, spin speed, etc. It also has a display of the time remaining (which is an estimate initially; it depends on how much laundry you put in, which it detects automaticly when it fills, and updates the display accordingly.) The little displays show you the absolute settings of parameters you care about (the temperature display is the actual temperature, not the temperature relative to the profile; if you're on sanitize, it's always somewhere at the top, and delicate always puts it near the bottom, so you see things in terms that match the care instructions on clothes).
I think Donald Norman would actually like it a lot. All of the controls directly affect visible state, and they're labelled in an obvious fashion. All of the buttons that do things you don't want to do are clearly not the button you're looking for. The buttons you care about for configuration are in order by significance. If all your laundry is the same, you just put it in and press start. If you have two kinds, you select the appropriate profiles. If you want to do something slightly differently, you can change that independantly.
It's got a lot of features, but it's still simple in the sense that you can easily ignore all the buttons for features you're not using, just like you ignore the part of the washing machine that isn't the control panel. It does a good job of hiding the complexity, because you have only a small set of options that you have to consider at any given time, and you can interpret each display without considering any of the other displays. It's also got bullet-point features that don't impact the interface at all (after the spin cycle, it rotates the drum half a turn in the opposite direction to loosen the clothes; there's no control for this).
Latecomers to the internet, like Harvard and Africa, have their networks structured such that they don't need huge numbers of IP addresses. When MIT originally set up their network, their routing was done by IP address block, so the routers could all decide where to send packets based on a single octet. So, if you have one computer in a location without any other computers, it gets 65536 addresses. Furthermore, the original routing between sites was simplified greatly by having the first octet dictate which site would get the traffic, so it would have been very difficult to give MIT or Federated less than 16777216 addresses, because traffic for all of those addresses would be routed through a single link to the rest of the internet.
These days, any infrastructure device is perfectly capable of looking up addresses in a table, and can discover and store the mappings for your whole network with no trouble at all. With this sort of hardware (which is all that's still available), each computer only needs one address. When there are 16 million computers in Africa on the internet, they can have more addresses. For that matter, MIT would give up most of their addresses if there was a shortage; last time I checked, only 18.*.0.* was generally used.
The real reason to go to IPv6 is not that there aren't enough addresses for everybody, but rather that there aren't enough addresses to not have to worry about allocation. With IPv6, every NIC that'll ever be created can have its own IP address (based on its MAC), plus addresses it gets by being connected through a router, private addresses, loopback, and so forth. There are useful effects of having so many addresses total that you can assign large spaces of them for purposes other than just having an address for each device on the internet.
Even Mosaic wasn't written in C++. I'm looking at the 2.7b4 source now, and it's definitely C.
The screenshot for Jurassic Park looks like a normal Irix screen. But what anybody who actually watched that part of the movie noticed was that the screen in the movie was some weird flying-through-a-virtual-reality-landscape thing, which the kid immediately recognized as UNIX. Almost everybody with actual UNIX experience just laughed at that, because it was classic a Hollywood computer representation. Except that it really was Irix, but running a window manager only available to people whose UNIX system had superfluous accelerated 3D graphics in 1995 (i.e., movie CG folks). What the audience couldn't see, but the kid would have been able to, was that the landscape had, written on the ground, things like "sbin" and "usr", clear signs of a UNIX system of some sort. As for breaking in, when dinosaurs are taking over your facility, chances are you aren't patching sendmail every day. And, in '95, that would have been a problem.
Li-ion cells blow up if you short them, and aren't considered safe to distribute to consumers. What you get are Li-ion battery packs with bunch of protection circuitry and an armored case that keeps the protection circuitry from being bypassed if you drop your laptop. This armor takes up a non-trivial amount of the weight and volume of a battery pack.
A Li-poly battery pack is going to be about the same in terms of weight and volume for a given capacity. It's be somewhat easier to break (no armor), but it won't blow up if you break it (or if the protection circuit is defective). Of course, if you have a very large battery, Li-ion will be more efficient, because the armor is by surface area and the energy is by volume; but if you have a very small battery, Li-ion is impossible, because there's no room for the cell inside the required armor.
This was largely an internal HP thing; half of the people spied on are on the HP board of directors. They're not going to want to mire the corporate entity in litigation. As far as reforming HP, shifting the balance of power to the people who were spied on is far more effective than any sentence that could be carried out on humans.
And the criminal cases are unaffected. That's what matters in the end; this was a case of criminal behavior by individuals in control of a company, not corporate policy.
RFID is getting to be like VoIP: there are a wide variety of applications which fit the acronym but are otherwise unrelated, and people lump them together. These bank cards and inventory tags in clothing have about as much similarity to each other as they have to 802.11. They use radio waves, and they use identification.
A well-designed smart bank card will use SASL to prove its identity to the bank without revealing information that would allow anybody else to use the identity. So it doesn't matter if people can snoop the transmission; they don't find out anything that they can use anyway. And it would use some mechanism (probably a capacitive contact sensor) to detect that somebody's touching it, and only authenticate then.
A particularly well-designed smart bank card would have a touch-sensor keypad, such that you type your PIN into the card to get it to authenticate you to the bank, and the ATM doesn't even find out the PIN. This wouldn't work with magnetic cards, because the card can't interact with both the user and the ATM at the same time, so RFID is needed for improved security of that sort.
Of course, the dumb, buzzword-compliant way to have RFID bank cards would be to just have them broadcast your card number to anyone who happens to ask. But that doesn't actually offer any advantage over magnetic stripes, aside from using a term that most people don't recognize, and those who do find scary. Of course, they could offer the advantage of not having to get out the card when you use it. But since you might have two different cards, you need to somehow tell the one you're not using to stop responding, or tell the one you are using to transmit. So you're holding the thing, and you might as well make physical contact between the card and the machine at that point, since you'll have to touch the machine yourself to type the PIN.
OpenID allows some unknown server to authenticate you to its own satisfaction. That is, if slashdot wants to prohibit random people from posting as iabervon@livejournal.com, such that only someone able to post to livejournal.com as iabervon@livejournal.com can post with that attribution, it can use OpenID to find out. (And OpenID does this in such a way that the site that's required authentication can't turn around and steal your identity.)
But it doesn't have a mechanism for the unknown server to prove that you did something to anybody else. There's no way built in to keep slashdot from fabricating comments as being from a particular livejournal user, even if the livejournal user never authenticates to slashdot, and even if slashdot readers try to verify the comments. There's no signature mechanism, so there's no way to tell if it was actually used at all, or if it was used properly. This obviously means that it's useless for ecommerce, because there's no way for the store to demonstrate that you authorized a purchase.
The interesting thing would be if somebody came up with a system whereby a site could present something for a signature by some OpenID user, such that the user can tell what's being signed, nobody other than that OpenID user can create the signature, and the signature can by verified by anybody who wants to check. That would be the real killer app for OpenID, because then you'd be able to do really secure online purchases. It would be more secure than the current system (the store currently gets enough information to fabricate other purchases by you), as well as using a single sign-on: when you purchase something, the store presents a receipt in a standardized format, and you sign it with the OpenID issued by your bank. The store presents it to the bank for payment, and gets paid. You reveal your bank username, but that doesn't let anyone do anything. You carry out your proof-of-identity and proof-of-intent exclusively with your bank, which you trust.
Magnatune.com has music that's non-DRMed and available for download at CD quality (although not by the track; keeping track of who can get what for individual tracks is more trouble than it's worth for a small site). Of course, it's all independant artists, but you clearly don't like the major label music anyway. And, if you'd like, you can pay a little more (or not).
So you hand count any election that a candidate thinks was close. You've got the actual ballots (and the best thing about optical scan is that all of the ballots it accepts are correct and obvious; otherwise it spits the ballot back out). The main benefit of counting with the scanner is that the results are available immediately, so people can get on with things. If somebody rigs the immediate results, this is revealed the next week, the result is corrected, and they investigate. It doesn't matter to the outcome of the election.