Interesting... all of the "papers" are either just abstracts or behind paywalls. The website (cannae.com) is just a shell, and there are no publicly available papers/designs for a curious observer to read. All we have for sure are a couple of press releases and a few paragraphs from a NASA lab.
WHERE'S THE DATA?
It makes me very suspicious...
Isn't this what a Notary is for?
But can he do the job?
- Joe Vs the Volcano
Seriously, slashdot has been providing us a great site for how many years now? And at the first sign they are doing something we might not like everyone turns on them like a pack of rabid wolves. It's a bit disappointing.
Yeah, the beta site is ugly, and it lacks a bunch of features. it's *BETA*, as in NOT FINISHED YET. Can we give them a little room to work on it before leaving en-masse? "Release early, release often" is how you get software into shape. When they asked for feedback, they needed constructive criticism, not useless abuse. So they didn't instantly respond to everything you posted complaints about. THEY'RE BUSY. Give them a little time.
This avalanch of ranting, conspiracy theories and threats isn't helping any, and it's a poor way to repsond to people who have supported our community for so long.
I would attempt, wherever possible, to eliminate the human error factor in referees. Tag the ball, wire the field, use computer vision, radar, whatever. Take the pressure off of the human refs and let it be done as objectively as possible. So we don't have entire championships going down in history as "bad call, dude."
I had various problems with email address collisions as well. Then when I had to change ISPs, I decided to get my own domain name. It's a little different when you own your own email address. If you register a domain, you can be email@example.com or such. Then you just forward from your actual email host to the registered email address. It's only a few dollars a year. Then YOU decide who gets an email address for your domain, and you can have whatever policy you want to avoid collisions.
Slashdot commenters are a bunch of hard-core, bleeding-edge and highly opinionated geeks. Surely that's got to be worth something in the tech industry? I mean, where else can you find such a concentration of tech knowledge and experience in people willing to share it?
One thing slashdot could do is to 'rent out' its Ask Slashdot and Poll features to companies who need that kind of feedback. Established companies can get a feel for what new features in a product will attract the tech-savvy. Startups can troll for new product ideas. It could even be used for market failure analysis: "why didn't you guys buy this?"
Of course, slashdot will have to be extra careful about what information it discloses, and also about what it allows on the site. If it turns into just another thinly-disguised ad system, no one will participate. The renters have to be seeking real answers to questions, and not just trying to sell us more crap.
There are three methods of authentication: Something you know, something you have, something you are. Passwords are the first category. In the case of amnesia, you lose all that. Any method of reclaiming passwords that also requires you to know something will also fail with amnesia, so a device with a PIN or another layer of passwords or those stupid "security questions" won't work. You can transform case 1 into case 2 easily by putting your passwords in some type of lock box. However, if you have amnesia, how do you remember where you put it, and how to open it? If you do get into your safety deposit box and find a piece of paper with 'myxlplix' on it, how do you know what that means, or what it's for, if you can't remember? The third category is basically biometrics, which might work, unless the same accident that gave you amnesia also cut off your right hand, or put out your eye, or lost whatever body part is needed to authenticate you. And of course, you have to remember that you have biometric authentication, how to use it, and what it's for.
And then there's this: any method for storing or reclaiming passwords that is outside your head weakens the security of your passwords. If you can get your passwords back without needing to know something only you know, then someone else can as well.
I'd really like to be able to customize my phone any way I want, without having to jump through so many hoops because of the lock-downs the manufacturer, carrier, or whoever have put on to attempt to control what I do with it.a) it doesn't work, b) it's really annoying and c) it's my phone, not yours, as is made clear any time it needs repair.
I might feel slightly differently if updates and fixes came out in an expedient fashion, but the lag time is months for updates, if there are any.
And what is it with them crippling features on my phone? Why are parts of the bluetooth stack turned off? Why can't I use wifi tethering? Where's the API for the IR port? Why is it so difficult to put things on an SD card? I know the base OS can handle these things. I know the phone has the capabilities to do them. So why are they deliberately disabled?
...but we are NOT DULL!!!
The hardest part of software development is the schedule. Managers and so forth want to have the comfort of knowing when some piece of code is going to be finished. The ugly truth is that it's all guesses. That's why almost any significant software project is usually late. You can't tell ahead of time what is going to bite you. The whole thing may have to be redesigned because of problems you couldn't see at the beginning. The requirements may change. And then there is the debugging, which is really unpredictable.
My theory about why open source code can be better than commercial code is because FOSS is released "when it's done", not on some arbitrary date. The worst kind of scheduling is when you start with the end date and work backwards. Inevitably something (quality, features) gets lost.
The rule for estimating time to write code is this: take your best guess, double it, add one and convert to the next higher units. So if you think you can code something in 3 days, tell them it will take 7 weeks. By the time you flush out the design, write and comment the code, debug it, write the tests, test it, document it and deliver it, you'll be lucky to meet the deadline.
And over-estimating doesn't do you any good either. All it takes is finishing early ONCE, and from then on your estimates are considered "inflated".
"Everything takes longer than you expect -- even when you expect it to take longer than you expect."
- Ashleigh Ellwood Brilliant
I for one would love to have a smart license plate. Just think of the hacking opportunities!
Jailbreak your license plate and display snarky messages to the other drivers on the road. Change your state to "confusion". Temporarily change your plate number and see how many red light cameras you can trip in a row. "Borrow" your rude neighbor's id and run up their toll bill. Steal a smart plate and hack it so you don't have to pay to register your vehicle. The possibilities are endless.
Any "smart" whatever can and will be hacked. If the incentives are large enough, those hacks will get widely distributed and used. How many incidents of license plate hacking will it take before the police decide it's just an expensive way to enable smart criminals? Not too many, I'd guess.
I've been on both sides of this issue.
As a user, I am often frustrated by the terse, non-informative error messages I get when something goes worng. "Cannot open file" is typical. Which file? In which directory? Why couldn't it be opened? What is the file for? What is supposed to be in it? What part of the program was trying to open the file?
The available on-line help is mostly not helpful in these cases, and FAQ's written by the developers, not the users are useless. Even finding out where the log is kept, much less actually seeing useful information in it? Good luck with that.
How can I as a user file an informative bug report with such scarce information?
So first suggestion: build into your programs meaningful error messages, along with enough information to accurately diagnose the problem. Include options to turn on debug output. When an error is detected, log complete information about it into the log file (the location and format of which should be documented). That way the user has a chance of making a good bug report. And be sure to ask for that information when the bug is filed, with specific directions about how to find and include it. "Append log file" isn't enough, you have to tell them where and how to find the log file.
As a developer, I know the frustration of vague bug reports, that leave out vital information. Simple things like which version of the program was being used, or the configuration settings. You have to make it clear to the reporter that you cannot solve the problem if you don't have enough information. One company I worked for actually had a bug state named "Not Enough Information." The only cure for this is to engage with the end user who reported the bug. And the biggest incentive for that person to engage with you, is the prospect of getting his bug fixed, soon.
So second suggestion: be very reactive to people who report bugs. Get back to them, tell them what's going on, ask questions, and let them test the fix. There is nothing that kills the enthusiasm for bug reporting like going through the process, waiting weeks to get a response, and then be told "Yeah, OK, it'll be fixed in the next version, due out in about 9 months. Thanksbye." And don't underestimate the effect of some user saying to his peers "I reported this bug, and they fixed it for me" to encourage others to report bugs, and make good bug reports.
Of course, there will always be lame bug reports, no matter how you do it. But you can at least encourage good ones, raising the signal to noise ratio.
"Catch a wave and you're sitting on top of the world." - The Beach Boys