Comment Its Hydrogen Hydroxide (Score 1) 463
Its Hydrogen Hydroxide HOH,
like Lithium Hydroxide LiOH,
and Sodium Hydroxide NaOH,
. . . just walking up the periodic table's left column . . . . that's the way I always thought of it.
Its Hydrogen Hydroxide HOH,
like Lithium Hydroxide LiOH,
and Sodium Hydroxide NaOH,
. . . just walking up the periodic table's left column . . . . that's the way I always thought of it.
There has been research and even products made to do the same thing in recognizing the distinct patterns or each users' typing. I recall first hearing of this in the early 90s, and it probably goes back further than this. Here's two examples:
http://cs.unc.edu/~fabian/papers/fgcs.pdf
http://www.securitysoftwarezone.com/keystroke-recognition-review273-7.html
These passive biometrics are all great(TM) solutions -- they take advantage of highly idiosyncratic, repetitive, and difficult to forge characteristics of each individual, and use technology to accurately recognize these characteristics and authenticate their targets.
Except these solutions fail at unacceptable rates when they encounter real-world exceptions. As mentioned by others, gait and keystroke cadence are both consistent, but easily changed by injury, illness, drugs, varying clothing, and just mood.
At least this research group recognizes this and points to the need for a *suite* of passive biometric indicators. But, they think a 1% false positive error rate is acceptable -- one chance in 100 that the thief gets in!?! It needs to be at least 3 orders of magnitude better.
Looks to me like another example of technologists getting enamored of their technology and failing to actually solve the basic problem.
When will manufacturers, especially software manufacturers, ever understand the concept that it is *MY* computer or device, *NOT THEIRS* ???
As noted above in all the "What could go wrong?" posts, this kind of central control is fraught with problems and unintended consequences..
If they simply take an approach to design and engineering that respects fact that it is not their device, all kinds of problems go away.
A proper approach would be for the lights to broadcast their status and schedule for the next few minutes (i.e., how long until the next change, how long will be the next red, etc.), and allow the vehicle and driver to decide what to do about it.
Sure, If we're at the beginning of a long red, then it is probably best to shut down. But, if we're making a right turn and/or trying to get someone to the hospital at 3AM, have paused to check that there is no crossing traffic, then we should drive on. If the hybrid motor is trying to recharge low batteries, the motor should keep running. Etc. We could even have a dashboard or heads-up display showing the status so the driver can make better decisions. Different car designers can code the best algorithm for *their* particular car design, e.g., a hybrid might use a completely different response pattern than a truck or a sportscar.
What is so hard about that? [Warning - oversimplification following] Decentralized systems are generally more flexible, and have shallower bugs than centralized systems. So, why do they persist in designing that way?
I'm glad to hear that at least one state is starting to implement a reasonable law. Between corporations too cheap to pay for systems that implement even a hint of real security, and perhaps a few lazy developers, we have a mess on our hands. I don't really understand the "yikes" exclamations in TFA. At least now there are some consequences for being so sloppy with your and my data.
My approach to coding web apps is that we are playing theater in the round -- playing to at least three audiences at once. In any pool of users, you have Group-1) probably 98% of users in various states of computer illiteracy for whom you need a very well thought-out UI that gets them through the app with no errors (and good recovery *when* they make errors, you have Group-2) 2% users that have a clue and want things really streamlined, and you have Group-3) a half-dozen bunches of malicious crackers.
All three groups are always present, and you cannot ignore any of them. Ignore Group-1, and you'll pretty much have no audience. Ignore Group-2, and you drive off the 'experts' to whom much of Group-1 looks for advice, and you'll consequently lose not only Group-2 but also a lot of Group-1. Ignore Group-3 and you'll get cracked and mess up a lot pf people's lives by losing their data, and/or you'll get embarrassed.
Unfortunately, too many buyers and devs of software ignore Group-3 because of costs, and the "it'll never happen to us" attitude. They need this kind of stick to nudge them towards doing the right thing.
I come from a very libertarian perspective, and I hate excess regulation, but I'm smart enough to know that the magic Market alone does not fix everything; it needs some smart regulation to prevent excesses or omissions, and appears to this is an example of such good regulation (presuming that they haven't screwed up the details).
The right way for Facebook to do this would have been for them to implement this with a payments system, and obviously, opt-in, instead of in by default and opt-out.
The advertisers should be paying for the use of the photos. The settings should be [Unavailable], and [Available / Price per View], with the price per view set by the user. The setting should be both for the full set of pics, with individual overrides for specific pics (e.g., pics that the user doesn't want used, or wants to set a higher or lower price). Obviously, better pics should command higher prices, and cheaper pics might get used more, and users wanting only fame could set the price to zero.
If properly implemented with accounting and logs (views, display, clicks, earnings, etc.), they'd actually be doing something respectable, instead of just pimping out all their user's property without their permission.
They also seem to have completely overlooked the issue of model's releases, which their vague TOS docs don't really cover. Of course, a good ecommerce/micropayments implementation would cover it properly as in if you set it to available.
"Our secret plan is to watch what gets acquired and fund the next company."
.
Anyone who is following is, by definition, behind.
.
By the time any company grows and gets acquired, the ship has not only left the dock, it has arrived at its next port of call.
.
Even trying to "fund companies doing whichever the next-generation product would have been." is a hopelessly backwards-looking strategy. I've always had the impression that Andreessen is stuck in 1995, so I guess it is no surprise that he hasn't got the confidence to generate any new groudbreaking ideas himself, and the best he can come up with is A) watching what gets bought, and B) trying to fund 24-year olds as if they are wiser.
.
If this is the best he can think of, he's sunk, and the investors deserve what they will get, which is plenty of capital losses for their tax returns.
I've been fortunate enough to have been involved as the lead tech/designer/architect/coder/whatever in co-founding, building and selling several successful software companies. I'm now in physical design manufacturing, and it is very satisfying, and there is a surprising amount of crossover.
Even those purely software ("information economy"?) projects benefited heavily from by earlier experience in physical/manual work through my HS/college years. I tended to strongly emphasize initial design to minimize coding and minimize machine loading before starting to code.
Possibly the biggest lesson transferred from physical work to software work was the lesson to work hard to avoid excess work. I found it worth it to spend many hours to AVOID writing code. This was not being lazy, as it is often initially faster to write code than to not write code. The basic lesson is: What takes time to run? Code. Where are the bugs? In your code. So, write no code that not absolutely required. Simplicity. It takes discipline and work, which is best learned from physical work, and not in a cubicle.
Especially in the late 90's, I became flabbergasted by the people that just wanted to start-writing-code and fix it later. Or, who wanted to just take the short-cut of sticking their fingers in everyone else's code and data structures. Fortunately, I prevailed in most of those debates, and in one company, in about 2yrs we were taking business from a much larger and better funded competitor who (surprise) had scalability problems that we (no surprise) avoided. When you work in the physical world, you learn well that short-cuts are almost always bad ideas, and that time spent sharpening the tool will more than pay off when it comes time to cut your material.
Since selling and leaving the last company, I did a lot of thinking about what to do next. Rather than doing another software business, I chose to start a business in advanced materials, which wound up mostly in composites (carbon fiber, Kevlar, etc.).
What I find remarkable is how much this feels like the computer industry did in the 1980s -- vibrant, interesting new developments and tools popping up all the time, good access to people who know about the tools and materials I'm using or considering (vs having to teach so-called tech support how to do their jobs just to extract an occasional clue). And, while it was really cool to see people happy to use software that we built that helped them do their jobs better, it seems even more satisfying now to build something physical with my own hands and see it used (but, maybe that is just because it is what I'm doing now).
This change, especially since the last economic crash, has also made me think even more how fundamentally bad an idea it is to oursource our manufacturing. It is an extremely dangerous and long-lived MBA fad (and I'm definitely glad to see the MBAs being properly skewered in Dilbert last week).
For our society, I only hope that the lesson is soon learned and that we can reverse the trend. Information Technology, and even management techniques, do have a place. BUT, that place is in support of the actual act of building something. If you never get around to actually building or growing something, you haven't done anything. And, one only need to glance at the trade deficits to see that we're building far too little.
If a thing's worth doing, it is worth doing badly. -- G.K. Chesterton