But it's ... it's not ... cool.

Apparently what is cool is to buy a gaudy plastic band to wrap around the edge to make up for this design defect, then bedazzle the shit out of it.

Make it harder sells it better
Work 'em faster Apple's stronger
More than ever iPhone after
iPod works the Android over

A free but limited version and a full, paid one is completely reasonable. There's several ways to do it too, but I think perhaps the best division is between the casual and the dedicated user. Casual users are unlikely to pay if forced, but they can still be good advocates for the app, so it may be worth it making sure they still have something to use.

The Aedict Japanees dictionary, for instance, is one of my most used apps. It has a free version that is really the full old (pre-Android 4) version of the app; and a paid version that is newer, better, more polished and with lots of added funcitonality. You can use the core functionality in the old app, but you really want all the improvements in the new one.

Games could have just the first few levels. Productivity apps could limit the document size or number of simultaneous documents. But I do think that making the free version usable for the occasional user likely pays off over time. Casual users advocate the app, and they may become dedicated users over time.

ynow... there is a moral to this tale: if businesses and individuals making money from software (libre) had properly funded it, putting some of the money that they saved from not purchasing proprietary software into the hands of those software teams, would we be talking about this now? in all probability, the answer is no. the reason is because those teams would be able to expand, take on more people, pay for security audits and so on which they would otherwise, as we have discovered, not be in a position to do.

so my take on this is that it is really really simple: businesses have received what they paid for, and got what they deserved.

i have been through this experience - directly - a number of times. i worked on samba - quietly - for three years. whilst the other members of the team were receiving shares from the Redhat and VA Linux IPOs, which they were able to sell and receive huge cash sums - i was busy reverse-engineering Windows NT Domains so that businesses world-wide could save billions of dollars.... and not one single one of those businesses called me up to say thank you, have some cash. as a result, about a year after terminating work on samba i was working on a building site as a common labourer.

it was the same story with the Exchange 5 reverse-engineering, which the Open Exchange Team mirrored (copied, minus the Copyright and Credits).

there is a moral to this tale: unlike proprietary software, which has a price tag commensurate with its perceived value, the process of even *offering* payment to individuals working on a software libre project that has been downloaded, usually from a completely different location (via a distro), is completely divorced from the developers actual efforts.

even in shops in rural districts, it is understood that if the door is unlocked and the shopkeeper not there, you help yourself, open the till, sort out your own correct change and walk out. but in the software libre world there is often not even that level of expectation! the software is quotes free quotes therefore it is monetarily zero cost therefore we should not have to pay, right? and businesses are pretty pathological about taking whatever they can get without paying for it.

so the short version is: there is a huge disconnect in software libre between service provision (the software) and paying for that service, and i really cannot see a solution here. perhaps this really should be bigger news: perhaps in this openssl vulnerability we have an opportunity to make that clear.

[...] but getting a fake hand for the sake of a fake hand is just being vain IMHO.

People are vain. People do care what other people think of them, and people do want to make a good impression on others. And it's completely rational; we are being judged by how we look, what we wear, how we behave. What we think of that is besides the point.

So yes, it turns out most people care about what their prostheses look like as much or more than how well they function. Any maker that disregards that is setting themselves up to become a niche within a niche; and most likely a long-term failure.

Idk about you, but I'd think an obvious robot hand would be easier to deal with than a fake looking piece of plastic mimicking a human hand.

It's probably impossible to know until you are actually in the same situation. There have been highly functional, highly useful hand prosthesis long before robotics - the classical hook is just one example - but the vast majority of patients have always preferred a hand mimic, even when it is completely nonfunctional and even when the mimiry is far from perfect.

Not getting stared at, and fitting in, is critically important to people, in this case as in others. Should'nt be too surprising when you think about it in such terms.

Thank you for your answer. There is almost no end to the FUD stream, and as I said, it's hard to pick out the signal from the noise.

Many Interneted Thingies work fine on your own cloud. You can find alternatives that don't feed the big Googly database, but you have to shop carefully. Fitbit and Nest don't give you the option; but some of the home automation systems like Vera need no clouds at all.

Password: hedgehog, no doubt.

Would you like your food data shared with your insurance company? How about your weight? Your BMI went above 22 this month. Not good, lower it or else. Your running? You didn't meet your jogging goals for the week. That's it, we're raising your health care premiums. That's a lot of beer you're drinking, and you put a lot of miles on your car, so it looks like we'll have to cancel your auto policy because statistically you're likely a drunk driver.

If you say "OK, share my data", it can go a lot of places you may not intend.

someone else answered about OSX. NT, based on the MACH kernel, has been fully re-entrant and multi-threaded for a looong time. also, given that the service control manager (which is a parallelised start/stop daemon service) is fully parallelised i'd be incredibly surprised if the same attention to detail wasn't also carried through on device-driver initialisation as well. although.... the only evidence against that is the "Debug Startup" mode, which initialises drivers in sequence (and shows you the sequence), but that could well be due to the request for "Debug Mode" rather than an underlying design. honest answer: don't know.

A lot of the animosity towards Monsanto comes from their overall behavior. Creating the terminator gene is first to mind. Next are the numerous allegations about misconduct: complaints that they do inadequate studies, they hire certain researchers expecting certain study outcomes, that they tamper with study results, and that they have bribed government officials. However, most of those reports come from the wacko anti-GMO crowd (who are really a bunch of anti-anything idiots), so it's hard to know if there's a shred of truth to any of the complaints.

The biggest gripe I have is their drive to produce pest- and herbicide-resistant crops. Every one of these is putting other farmers' crops at risk, because they're creating pesticide-resistant super-bugs and herbicide-resistant super-weeds. Those bugs and weeds don't limit themselves to Monsanto-seeded fields, they're natural organisms that spread, and those bugs are now attacking non-Monsanto crops, and the weeds are infesting non-Monsanto fields. Monsanto knew this was going to happen from the start of the program, they estimated it would take about 20 years for it to happen (it actually took less than 10 for the corn rootworm to evolve Bt resistance), yet they went ahead and did it anyway.

Had they focused their modifications only on creating high yield and high nutrition crops, instead of trying to fight the resistance battle, their overall agricultural activities would have been a lot more responsible.

LED lamps do not put out nearly as much heat as High Pressure Sodium (HPS) lamps. I have a (disconnected) 400W HPS that I could easily have cooked on the top of the reflector, and probably broiled meat directly beneath it. I replaced it with a 144W LED floodlamp, and now I can hold the operating heat sink in my hand; the glass lens pane on the bottom is at room temperature. I am no longer concerned about fire safety in my house.

One major difference, though, is I'm growing orchids, which require far less light than cannabis. I need only two 144W LED floodlamps to illuminate a 72 square foot area. The pot growers will cram as many 400 W lamps in a grow operation as they can, sometimes a dozen or more in a single small room, whatever they can draw from the circuit breaker panel. They'll keep a large external vent fan running year round, including the dead of winter, to keep the room from igniting.

If I were to grow pot, I'm sure I'd need a lot more light fixtures, but even a dozen LED lamps in the same room probably wouldn't risk burning my house down.

Oracle consultants were in the midst of the mess, they saw the failings, they repeatedly reported to the state that the project was going off the rails, and yet they still managed to cash their paychecks.

Had the consultants actually threatened them with "either you hire a professional to do the systems integration or we're off the job," and had they then removed themselves from the failing project, they'd be 100% blameless. But they didn't walk away, they just wrote some CYA memos and collected their money.

Oracle gets to take as much blame as anyone for their mess.

That would be fine if it were true, and if it were the end of it. But it's not. The enablers take over. If the bad ideas aren't stopped early by facts, their owners proceed down whatever path they've concocted, and the further they get without objection the more convinced they are that it's the correct path. An enabler will not tell them they're on the wrong path; or they'll say it once, but never correct them again for fear of losing their job (only a blocker says "you're still on the wrong path".) Without honest feedback about the mistakes being made, you can go a long way before realizing that you've led yourself astray.

One big problem is the belief that all problems can be stopped by governance processes. Therefore, all these processes are designed to be a form of change prevention. The idea is that by preventing incorrect changes, you avoid risk. But a process cannot distinguish between an incorrect change and a valuable change until after it has executed, so it must slow them all down equally. A process also handles the unknown poorly - it is designed to handle only certain changes, and everything else is awkward or not streamlined.

Change approval processes also encourage lies. When someone has to get a change through a process, they will tick whichever checkboxes will get them through the process with the least amount of effort, struggle, or paperwork; they will not voluntarily tick the box that ensures a microscopic review of their change, even when it may be appropriate.

Worse than all of the above, governance processes are hugely inefficient in that they're after the fact: create a large pile of changes, try to deploy it, then wait around days, or weeks to learn only then that the changes aren't approved. The feedback from governance is so late that the developer has long moved on to other tasks. Stakeholders get their changes in months instead of minutes.

Another sign the process is off the rails is if the disapproval is issued due to failure to follow the process, not with problems in the task being attempted. Too many failing processes leads further around the vicious cycle of process 'improvement', that then creates a process to follow the process, inserting delays into the delays. (Yo, dawg, I heard you like process, so I put process in your process...)

If you ever want to read a story about how bad process can get in the real world, read Red Plenty by Francis Spufford. He tells an interesting tale of just how far the Soviet Union's bureaucracy went, including goofiness such as one process that valued a machine by weight. The more modern machine that doubled production weighed less than the older machine it replaced, therefore the older machine was more valuable, and the budget rules that ensured progress did not permit replacing a more expensive machine with a cheaper machine.

Instead of after-the fact governance process, strive for continual, automated testing, starting with Test Driven Development. Have a repeatable method for delivering products that have quality built in from their very design. Once you've established the trust, you can minimize the processes. Something else valuable is a fail-forward philosophy: if you acknowledge that bugs will happen no matter what ("Failure is always an option"), you can often survive by putting in place the ability to recover from defects within minutes by being able to push out new patches. So instead of trying to avoid all risk by using a big process, you can get away with minimal process by accepting a little risk. This is a great approach because everything moves fast, especially the delivery of benefits.