The motes done by crossbow that I've seen all use STmicro accels. They're 2d but we went and sourced a 3d version rather than try to do the math on a pair of 2d guys.
You can buy the same part the wiimote uses for about 8 dollars from digikey. Or a better one. I don't know where you get your numbers from. It's not as cheap as Nintendo gets it, but if you're considering a serious deployment you should just ask for engineering samples. Intertial navigation just doesn't work. Sensors aren't perfect, so you lose some position that way, and you can only sample so fast, so any short variations can potentially be lost, or brief peaks extrapolated for much further than they really were. And even then, the ADC that samples the voltage isn't perfect, so more accuracy is lost there! Nintendo's own engineering team states this has been their experience, in an interview, which is why they have the sensor bar. It is not, as the article implies, only to gather the initial position of the tv relative to the wiimote. It's there because inertial navigation deviates over time. You can easily correct the deviations with say, a GPS device, or the sensor bar, though.
I don't understand why you're crediting the Wii with making the parts so cheap - it was STmicro that put together the factory, and STmicro was selling them cheaply before the Wii was huge.
Because they're not done yet. Supposedly, that'll happen soon. When that happens I imagine Debian will be among the first to distribute the GPL source derived binaries. What they have thus far is the hotspot jvm and javac. There's a few parts left, before it's really useful without the closed source tools. You're of course welcome to be skecptical until they make good on that deadline.
Jumping ship so often also cannot be easily explained when you have a long term pattern of it. If I were interviewing someone, regardless of what they said, it would raise major red flags.
Of course, so far all his jobs have been offers given to him while he was still employed. Each company hired him away from the last one, probably knowing the situation. If you refuse to hire anyone with signs of disloyalty, you'll be limiting your candidate search to the unemployed. More long term, it sounds like he's a young contractor. Its probably safe to say that he's getting the screws, paywise, and slowly finding out. Like your last paragraph implies, contractors usually don't know the financial details of the arrangement. It's very hard to feel bad about leaving a headhunter that's billing $115 hourly and paying you $28. Or the company who entered such an arrangement. Maybe it means poor business sense on behalf of the candidate, but I've never seen companies happy to hire people that are also talented compensation negotiators.
As far as advice to the candidate, I don't know who you should speak with regarding compensation as a contractor, but it might be easier on the CV to approach them and say, "Hey, I keep getting job offers and it's getting harder and harder to turn down a 50 percent raise. So unless you can match, I think we're through". Keep in mind the headhunter has been billing their client for nearly 4 times what you earn, and can live with a 50 percent increase in wages (and probably already does in some cases -- your coworkers may be paid twice as much as you!). Basically, you are their profit center. In the worst case, just be prepared to walk like you normally do. The good news is that a resume is supposed to be a highlight of accomplishments, not a life story. Obviously some places have an application requesting everywhere you've ever worked, and it may come up during interview. Just say you were young and naive, but that the market eventually found a solution. Probably the best way to stop this is to figure out what they're charging your clients, and base you salary requirements not on how much more you'd be making, but an improvement on how much they're keeping.
Managers hate headhunters, for reasons the parent stated, but there's not much in the way of alternatives. The traditional way of seeking all qualified candidates through HR requires sifting through thousands of applications for a single position, and interviewing dozens. On the one hand, you can reduce the candidate pool by poorly advertising, but you're also risking missing out on high quality people who aren't looking for employment.
I'm not sure the aesthetics argument holds water though. You can find fluorescents in plenty of temperatures, including ones that match incandescent. But one reason the efficiency regulation works better than an outright incandescent ban is that it targets exactly what is wrong with incandescents today, and it provides a model for improving future regulations. If you feel the need to legislate market availability, just up the lumens / watt ratio. If incandescents or other technology comes along that consumers should switch to (but don't either because they don't realize, or don't think they can afford a "long-term" investment like that), then it's simple to amend existing regulation, instead of unbanning high efficiency incandescents, etc.
Probably the best way the Opposable Thumbs author could have countered the article was a response in kind. Where Jones cites GTA, present an equal and opposite anecdote: Beyond Good and Evil. Failing that, maybe point out the interesting distinction that you can customize everything about your character in San Andreas except the color of his skin, and the implications. Jones's main argument is that blacks spend too much time playing games and not enough making them. Becoming a game developer is a bad career move. As programmers they typically make less than counterparts elsewhere would. The same holds true with nearly every game related endevor. Moreover, the best game developers I know barely play (similar perhaps to how drug dealers don't do drugs and remain dealers long). The kinds of skills and interests that make making games fun are wholly different than those that make playing them fun. They're doing this because they're interested in the kinds of problems making games present, not to please their socio-economic peers. Trust me, nobody makes Spongebob Squarepants to impress their friends.
But after consideration, I think more Americans making console games would be a good start. Consider how many games featuring all white casts are made by the Japanese studios, and how weird that is for a second.
I think Linus's point was that certain GNOME developers refuse features not because they're too hard to do but because UI is some cathedral that requires perfection. Take the first question in the FAQ from the metacity README : "Will you add my feature?"
The guy basically says "Only if everyone would like it to be there." And lets take the article linked to after that explanation: http://ometer.com/free-software-ui.html The contradiction of "Not enough UI designers" and "Too many cooks" might not be obvious, especially if you feel that designers aren't programmers. But open source software doesn't make that distinction. I actually find it nice in this regard: it avoids situations in which some volunteers tell other volunteers what to do, and more importantly, what not to do. There's a fairly recent parable of the mice and the bell. It can easy to propose and vote that something should be done, but sometimes doing it is another thing. Open source projects focused on patch sets eliminate this.
GNOME is not a platform for programmers. GNOME developers should not be surprised then, when programmers notice this and either avoid it or complain in some fashion.
Which means the problem is much larger. It's not about covering a single van's route, its about covering the United States' domestic deliveries.
Indeed, there exists algorithms that solve related problems that can solve this one better than n!. We should expect this, given the nature of proving an algorithm NP-Complete. But the GP didn't suggest them, they suggested a brute force technique. And I assume there's a polynomial time algorithm that gets you as close to optimal as you want to spend the time running. That said, wikipedia suggests that current quantum computer models can't solve NP-complete problems in polynomial time, though there's no proof either way.
A UPS Van driver usually has about 100 packages when it leaves, I'd guess. Even 100 might sound small if you consider multiple packages for a given destination and relatively fast computers. But remember that there's a ton of these vans per distribution center making runs, and all permutations is n! (There are faster algorithms for optimal TPS solutions, but they're still exponential).
Re:Sounds good, a quasi Wikipedia like development
on
Everybody Votes on the Wii
·
· Score: 2, Insightful
One other important aspect of the Everybody Votes that isn't brought up by any press releases is that it smoke tests their online services server. Presumably the wiishop and system update online services are different (and secured) than what they intend to be used for mario kart and other online games. Hopefully Everybody votes is using the same tools they intend to give developers, so they can iron out the performance flaws before a million people try out online match making with mario kart. I'm guessing that the Mii parade wasn't built with this in mind, so things like storing user profiles in a database (for comparison purposes) weren't tested. I haven't seen any post-mortems, but I imagine that the Nintendo Wi-Fi connection was primarily pwned by the database backends not being stress tested before being released on the world. T
Obviously, they won't be just posting every submitted question; moderation for something publicly available like this is important. But I can't imagine them adding a "submit a question" without potentially using them.
I have no doubt that UPS, the company that trains their drivers to turn the ignition key with one hand and buckle up with the other simultaneously, TO SAVE TIME, is interested in improving solutions to the traveling salesman problem. They're probably pretty close, but I bet they'd love another 1 percent improvement in performance. I don't know whether UPS's problem can be stated well enough to make quantum computers speed it up any, but the TSP doesn't require straight lines in space, just estimated times between destinations (which is another problem UPS should be interested in).
I'm not sure what your point about conventional computers calculating TSP meant; time complexity is a way of describing how runtime grows with input size. The time complexity remains the same, but it's still taking exponetially more time to run as the input increases in size. This argument that you just need to hook up more memory applies equally to quantum computers -- if you can't represent the problem in the space you have, theres no way you can solve it like that either. A practical limitation, but one that could be reduced in say, 50 years.
as far as I know, the nvidia drivers break things like suspend. and most developers refuse to invest time and effort into driver support for closed source technologies. Especially now that we're seeing OSS progress on NVidia, I think you'll have a had time convincing people to make it work for free. Canonical probably will, if you hand them over the cash ($250/yr).
I suppose it depends on the teaching, but we run our students through synchronization routines in our Operating Systems course. They should know when they leave that multithreading requires protection. Of course, there's not much for the ones that leave school before this course (the course is a bear and the ones likely to avoid it are also likely to drop, but not before adding "Java" to their resume). Not all of them could propose a good fix, but they'd at least know that they should be looking for locks or something and encounter the "synchronized" keyword. Seems the biggest problem regarding java multithreading is efficiency and broken ways to avoid the synchronized keyword.
I'm not an expert on the java semantics of notify(), but after reading the javadoc and spec, if you intend to preserve the order of notification, it seems your point was to prove Java inadequate for the job: notify() has no parameters and merely signals waiting threads. It does not enforce any queuing on multiple notifies. If you were ready to run before the notify, you're still ready afterwards, but not necessarily running. Solving the problem becomes a lot less parallel, as publishes will have to copy, then block on pending publishes, AND for all subscribing threads to block again. If you signal multiple times, assuming the subscribers were waiting on themselves, using notify actions for publish potentially races with the waking thread's event handler due to the thread scheduler.
In fact, we're slowly building message queues as that's whats needed to satisfy the spec. We need FIFO processing of values and java's primitives fail the FIFO test. Fortunately, the paper decides to abandon java at this point for a pet language and introduces typical parallel language features like networking and the rest of distributed programming. Hopefully though students are scared enough of multithreading to look into how a given language's synchronization works.
Why does the notify allow() for throwing exceptions? The only exception I can see that it throws is IllegalMonitorState, and that seems easy enough to fix. I vaguely recall something about runtime exceptions or whatnot always being throwable, but really, there's nothing the Observer can do about such things except carry on with the rest of notifications. This is bad for debugging, so one solution would be to hold the exceptions until all notifications have been done and then deal with them all at once. Simply ignoring exceptions isn't an option, multi-threaded or not. If anything, this is an example of how instructional curricula have failed Java programmers.
If publishing triggers a subscriber to trigger another publish, that's either programming error or intended behavior in my book. A strict reading of the spec you've provided suggests we must notify all subscribers all publishes, not merely the newest. This eliminates a possible optimization should this trigger not occur every time.
My approach, without reading the paper, would be to make a copy the subscriber list on a publish. Synchronizing add and copy should be as simple as synchronizing on the subscriber's data structure. If this is prone to deadlock, I'm afraid you shouldn't be using Java.
Indeed, I work with TinyOS, an open source platform for embedded sensor network systems. One of the features is a task queue. Unfortunately, it doesn't support associating data with a given task in the queue, which would make life much easier for me, and much harder for the people authoring the system. The whole thing's written in "nesC" which is basically C with a few extras and some component oriented things to modularize C.
As a language, its design is to take interrupts and parallelism and make it part of the language. You're allowed to label sections atomic, and the compiler enforces this. Currently it just turns off interrupts, but analysis could improve this by removing useless atomics and perhaps identifying when one atomic section won't interfere with another. But for now, turning off interrupts is cheap enough that it's hard to justify stronger synchronization primitives at runtime. Currently the system assumes a single task from the queue will be running, so one can guarantee atomicity between them, but I don't know if the langauge / system explicitly states this.
Unfortunately, this article claims to have inspected the subject of embedded systems and parallelism, but aside from some head-nodding to VxWorks, there's not much meat on for the subject. Which is probably ok. The paper focuses on compute bound domains like BLASTp, the stuff we work with is limited more by battery longevity and the speed at which connected devices work. If a 12bit ADC is going to take some time, we'd rather go into a low power state if possible. Same goes for writing to SD over i2c. Yet some of the conventional wisdoms the authors put forth are true. Transistors (atmega128s) are cheap, but battery power is not. The cost of going out to the field and replacing a battery could approach the cost of replacing the device. Many deployments just ignore battery failures, since once you have a hundred of these things deployed you're not gonna find the failed one anyways. But there's still a few that are just junk for us, such as floating point vs memory and the potential for faster CPUs. But as I noted above, our software isn't trying to solve some compute intensive problem, it's controlling hardware.
Actually, I should make a correction. By the time Carmony was not associated with mp3.com it was already too late. Carmony clearly suffers from association with mp3.com, as nobody's bothered to point out this to me. Carmony may be able to slowly repair Robertson's (a name I recall so well now that I wonder how I briefly forgot it) opportunistic practices, but it remains clear to me that Linspire's motivations do not run in harmony with open source. It saddens me a bit that Robertson's off to other ventures (AJAX, how web 2.0!), as it had a sort of poetic justice to it.
As an aside there was no way mp3.com could have avoided the same impending avalanche that youtube now faces and remained anything close to what it did. Lindows was started in the same get rich quick manner that ultimately harmed their long term goals. Even the name tried to make bank off of someone else's efforts.
"The university does have an absolute right to dictate how their network is used. That doesn't mean that nothing they do is ignorant or boneheaded."
That's not quite true. As a university, their mission is furthering educational development. They can argue over how such and such use does or doesn't advance educational goals, but there should be no dispute that education is the goal. The campus IT department then, as an administrative branch, is in a unique position of trying to accommodate all party's interests, rather than dictate the limited uses of "their" infrastructure. They're supposed to make it happen, not "enforce the AUP".
How, By turning into exactly the thing we despise?
Kevin Carmony has repeatedly demonstrated a preference for short term results, and reckless disregard for copyright law. That said, I find some justice the world -- he's now in charge of a company to fix the problem he helped cause with mp3.com. Perhaps we should enlist him to convince President Bush to be the US Ambassador to Iraq come 2008.
Slashdot Mirror
The motes done by crossbow that I've seen all use STmicro accels. They're 2d but we went and sourced a 3d version rather than try to do the math on a pair of 2d guys.
You can buy the same part the wiimote uses for about 8 dollars from digikey. Or a better one. I don't know where you get your numbers from. It's not as cheap as Nintendo gets it, but if you're considering a serious deployment you should just ask for engineering samples. Intertial navigation just doesn't work. Sensors aren't perfect, so you lose some position that way, and you can only sample so fast, so any short variations can potentially be lost, or brief peaks extrapolated for much further than they really were. And even then, the ADC that samples the voltage isn't perfect, so more accuracy is lost there! Nintendo's own engineering team states this has been their experience, in an interview, which is why they have the sensor bar. It is not, as the article implies, only to gather the initial position of the tv relative to the wiimote. It's there because inertial navigation deviates over time. You can easily correct the deviations with say, a GPS device, or the sensor bar, though.
I don't understand why you're crediting the Wii with making the parts so cheap - it was STmicro that put together the factory, and STmicro was selling them cheaply before the Wii was huge.
Because they're not done yet. Supposedly, that'll happen soon. When that happens I imagine Debian will be among the first to distribute the GPL source derived binaries. What they have thus far is the hotspot jvm and javac. There's a few parts left, before it's really useful without the closed source tools. You're of course welcome to be skecptical until they make good on that deadline.
As far as advice to the candidate, I don't know who you should speak with regarding compensation as a contractor, but it might be easier on the CV to approach them and say, "Hey, I keep getting job offers and it's getting harder and harder to turn down a 50 percent raise. So unless you can match, I think we're through". Keep in mind the headhunter has been billing their client for nearly 4 times what you earn, and can live with a 50 percent increase in wages (and probably already does in some cases -- your coworkers may be paid twice as much as you!). Basically, you are their profit center. In the worst case, just be prepared to walk like you normally do. The good news is that a resume is supposed to be a highlight of accomplishments, not a life story. Obviously some places have an application requesting everywhere you've ever worked, and it may come up during interview. Just say you were young and naive, but that the market eventually found a solution. Probably the best way to stop this is to figure out what they're charging your clients, and base you salary requirements not on how much more you'd be making, but an improvement on how much they're keeping.
Managers hate headhunters, for reasons the parent stated, but there's not much in the way of alternatives. The traditional way of seeking all qualified candidates through HR requires sifting through thousands of applications for a single position, and interviewing dozens. On the one hand, you can reduce the candidate pool by poorly advertising, but you're also risking missing out on high quality people who aren't looking for employment.
If its any consolation, #4 is no extra crap installed.
Call me a bit crazy, but I think I saw a bulb form CF. It might not be the dim, clear, visible lighting element lightbulb you're looking for though.
I'm not sure the aesthetics argument holds water though. You can find fluorescents in plenty of temperatures, including ones that match incandescent. But one reason the efficiency regulation works better than an outright incandescent ban is that it targets exactly what is wrong with incandescents today, and it provides a model for improving future regulations. If you feel the need to legislate market availability, just up the lumens / watt ratio. If incandescents or other technology comes along that consumers should switch to (but don't either because they don't realize, or don't think they can afford a "long-term" investment like that), then it's simple to amend existing regulation, instead of unbanning high efficiency incandescents, etc.
Probably the best way the Opposable Thumbs author could have countered the article was a response in kind. Where Jones cites GTA, present an equal and opposite anecdote: Beyond Good and Evil. Failing that, maybe point out the interesting distinction that you can customize everything about your character in San Andreas except the color of his skin, and the implications. Jones's main argument is that blacks spend too much time playing games and not enough making them. Becoming a game developer is a bad career move. As programmers they typically make less than counterparts elsewhere would. The same holds true with nearly every game related endevor. Moreover, the best game developers I know barely play (similar perhaps to how drug dealers don't do drugs and remain dealers long). The kinds of skills and interests that make making games fun are wholly different than those that make playing them fun. They're doing this because they're interested in the kinds of problems making games present, not to please their socio-economic peers. Trust me, nobody makes Spongebob Squarepants to impress their friends.
But after consideration, I think more Americans making console games would be a good start. Consider how many games featuring all white casts are made by the Japanese studios, and how weird that is for a second.
I think Linus's point was that certain GNOME developers refuse features not because they're too hard to do but because UI is some cathedral that requires perfection. Take the first question in the FAQ from the metacity README : "Will you add my feature?"
The guy basically says "Only if everyone would like it to be there." And lets take the article linked to after that explanation: http://ometer.com/free-software-ui.html The contradiction of "Not enough UI designers" and "Too many cooks" might not be obvious, especially if you feel that designers aren't programmers. But open source software doesn't make that distinction. I actually find it nice in this regard: it avoids situations in which some volunteers tell other volunteers what to do, and more importantly, what not to do. There's a fairly recent parable of the mice and the bell. It can easy to propose and vote that something should be done, but sometimes doing it is another thing. Open source projects focused on patch sets eliminate this.
GNOME is not a platform for programmers. GNOME developers should not be surprised then, when programmers notice this and either avoid it or complain in some fashion.
So does the magical Christian majority believe in evolution, or just that the truth of creationism isn't an important topic as lower taxes?
Which means the problem is much larger. It's not about covering a single van's route, its about covering the United States' domestic deliveries.
Indeed, there exists algorithms that solve related problems that can solve this one better than n!. We should expect this, given the nature of proving an algorithm NP-Complete. But the GP didn't suggest them, they suggested a brute force technique. And I assume there's a polynomial time algorithm that gets you as close to optimal as you want to spend the time running. That said, wikipedia suggests that current quantum computer models can't solve NP-complete problems in polynomial time, though there's no proof either way.
A UPS Van driver usually has about 100 packages when it leaves, I'd guess. Even 100 might sound small if you consider multiple packages for a given destination and relatively fast computers. But remember that there's a ton of these vans per distribution center making runs, and all permutations is n! (There are faster algorithms for optimal TPS solutions, but they're still exponential).
One other important aspect of the Everybody Votes that isn't brought up by any press releases is that it smoke tests their online services server. Presumably the wiishop and system update online services are different (and secured) than what they intend to be used for mario kart and other online games. Hopefully Everybody votes is using the same tools they intend to give developers, so they can iron out the performance flaws before a million people try out online match making with mario kart. I'm guessing that the Mii parade wasn't built with this in mind, so things like storing user profiles in a database (for comparison purposes) weren't tested. I haven't seen any post-mortems, but I imagine that the Nintendo Wi-Fi connection was primarily pwned by the database backends not being stress tested before being released on the world. T
Just a suspicion on my part.
Obviously, they won't be just posting every submitted question; moderation for something publicly available like this is important. But I can't imagine them adding a "submit a question" without potentially using them.
I have no doubt that UPS, the company that trains their drivers to turn the ignition key with one hand and buckle up with the other simultaneously, TO SAVE TIME, is interested in improving solutions to the traveling salesman problem. They're probably pretty close, but I bet they'd love another 1 percent improvement in performance. I don't know whether UPS's problem can be stated well enough to make quantum computers speed it up any, but the TSP doesn't require straight lines in space, just estimated times between destinations (which is another problem UPS should be interested in).
I'm not sure what your point about conventional computers calculating TSP meant; time complexity is a way of describing how runtime grows with input size. The time complexity remains the same, but it's still taking exponetially more time to run as the input increases in size. This argument that you just need to hook up more memory applies equally to quantum computers -- if you can't represent the problem in the space you have, theres no way you can solve it like that either. A practical limitation, but one that could be reduced in say, 50 years.
as far as I know, the nvidia drivers break things like suspend. and most developers refuse to invest time and effort into driver support for closed source technologies. Especially now that we're seeing OSS progress on NVidia, I think you'll have a had time convincing people to make it work for free. Canonical probably will, if you hand them over the cash ($250/yr).
I suppose it depends on the teaching, but we run our students through synchronization routines in our Operating Systems course. They should know when they leave that multithreading requires protection. Of course, there's not much for the ones that leave school before this course (the course is a bear and the ones likely to avoid it are also likely to drop, but not before adding "Java" to their resume). Not all of them could propose a good fix, but they'd at least know that they should be looking for locks or something and encounter the "synchronized" keyword. Seems the biggest problem regarding java multithreading is efficiency and broken ways to avoid the synchronized keyword.
I'm not an expert on the java semantics of notify(), but after reading the javadoc and spec, if you intend to preserve the order of notification, it seems your point was to prove Java inadequate for the job: notify() has no parameters and merely signals waiting threads. It does not enforce any queuing on multiple notifies. If you were ready to run before the notify, you're still ready afterwards, but not necessarily running. Solving the problem becomes a lot less parallel, as publishes will have to copy, then block on pending publishes, AND for all subscribing threads to block again. If you signal multiple times, assuming the subscribers were waiting on themselves, using notify actions for publish potentially races with the waking thread's event handler due to the thread scheduler.
In fact, we're slowly building message queues as that's whats needed to satisfy the spec. We need FIFO processing of values and java's primitives fail the FIFO test. Fortunately, the paper decides to abandon java at this point for a pet language and introduces typical parallel language features like networking and the rest of distributed programming. Hopefully though students are scared enough of multithreading to look into how a given language's synchronization works.
Why does the notify allow() for throwing exceptions? The only exception I can see that it throws is IllegalMonitorState, and that seems easy enough to fix. I vaguely recall something about runtime exceptions or whatnot always being throwable, but really, there's nothing the Observer can do about such things except carry on with the rest of notifications. This is bad for debugging, so one solution would be to hold the exceptions until all notifications have been done and then deal with them all at once. Simply ignoring exceptions isn't an option, multi-threaded or not. If anything, this is an example of how instructional curricula have failed Java programmers.
If publishing triggers a subscriber to trigger another publish, that's either programming error or intended behavior in my book. A strict reading of the spec you've provided suggests we must notify all subscribers all publishes, not merely the newest. This eliminates a possible optimization should this trigger not occur every time.
My approach, without reading the paper, would be to make a copy the subscriber list on a publish. Synchronizing add and copy should be as simple as synchronizing on the subscriber's data structure. If this is prone to deadlock, I'm afraid you shouldn't be using Java.
Indeed, I work with TinyOS, an open source platform for embedded sensor network systems. One of the features is a task queue. Unfortunately, it doesn't support associating data with a given task in the queue, which would make life much easier for me, and much harder for the people authoring the system. The whole thing's written in "nesC" which is basically C with a few extras and some component oriented things to modularize C.
As a language, its design is to take interrupts and parallelism and make it part of the language. You're allowed to label sections atomic, and the compiler enforces this. Currently it just turns off interrupts, but analysis could improve this by removing useless atomics and perhaps identifying when one atomic section won't interfere with another. But for now, turning off interrupts is cheap enough that it's hard to justify stronger synchronization primitives at runtime. Currently the system assumes a single task from the queue will be running, so one can guarantee atomicity between them, but I don't know if the langauge / system explicitly states this.
Unfortunately, this article claims to have inspected the subject of embedded systems and parallelism, but aside from some head-nodding to VxWorks, there's not much meat on for the subject. Which is probably ok. The paper focuses on compute bound domains like BLASTp, the stuff we work with is limited more by battery longevity and the speed at which connected devices work. If a 12bit ADC is going to take some time, we'd rather go into a low power state if possible. Same goes for writing to SD over i2c. Yet some of the conventional wisdoms the authors put forth are true. Transistors (atmega128s) are cheap, but battery power is not. The cost of going out to the field and replacing a battery could approach the cost of replacing the device. Many deployments just ignore battery failures, since once you have a hundred of these things deployed you're not gonna find the failed one anyways. But there's still a few that are just junk for us, such as floating point vs memory and the potential for faster CPUs. But as I noted above, our software isn't trying to solve some compute intensive problem, it's controlling hardware.
No, he worked for mp3.com, but i was confusing him with Michael Robertson, serial entrepreneur.
I guess he has a practical example now to demonstrate the difference with to his students ;)
Actually, I should make a correction. By the time Carmony was not associated with mp3.com it was already too late. Carmony clearly suffers from association with mp3.com, as nobody's bothered to point out this to me. Carmony may be able to slowly repair Robertson's (a name I recall so well now that I wonder how I briefly forgot it) opportunistic practices, but it remains clear to me that Linspire's motivations do not run in harmony with open source. It saddens me a bit that Robertson's off to other ventures (AJAX, how web 2.0!), as it had a sort of poetic justice to it.
As an aside there was no way mp3.com could have avoided the same impending avalanche that youtube now faces and remained anything close to what it did. Lindows was started in the same get rich quick manner that ultimately harmed their long term goals. Even the name tried to make bank off of someone else's efforts.
"The university does have an absolute right to dictate how their network is used. That doesn't mean that nothing they do is ignorant or boneheaded."
That's not quite true. As a university, their mission is furthering educational development. They can argue over how such and such use does or doesn't advance educational goals, but there should be no dispute that education is the goal. The campus IT department then, as an administrative branch, is in a unique position of trying to accommodate all party's interests, rather than dictate the limited uses of "their" infrastructure. They're supposed to make it happen, not "enforce the AUP".
I think the bigger problem is that they still figured out it was him!
How, By turning into exactly the thing we despise?
Kevin Carmony has repeatedly demonstrated a preference for short term results, and reckless disregard for copyright law. That said, I find some justice the world -- he's now in charge of a company to fix the problem he helped cause with mp3.com. Perhaps we should enlist him to convince President Bush to be the US Ambassador to Iraq come 2008.