The age cutoff is arbitrary. But when we do not treat it as inviolate, then we do us all a disservice. In practical terms, minors have no rights, and thus should have less responsibility. That is, they should never be tried as an adult, under any circumstances. It is always their parents' responsibility if their upbringing comes out wrong.

In the inner city, tons of young kids get adult sentences for being involved in the drug trade. So, it is already far from an inviolate already. There is a disproportionate portion of young people convicted as adults who are racial minorities, so that's another big issue with the legal system at present. But, it's silly to say that not being mature enough to automatically be trusted to sign your own contracts inherently means that you should be excused for rape.

IMO, the way it should work is that everything is recorded, and made publicly available after, say, 7 days. In that time, and officer can request that something specific be witheld from the public record. the process would basically be the same as a warrant, where the officer would go to a judge, who would review the footage and would sign off on the redaction. If the footage came up in a court case, it would be possible to petition to get it unsealed. This would cover all sorts of situations. A bust of a child pornographer might involve several minutes of child porn, for example, and you probably wouldn't want to publish that, given the point of bothering to arrest the child porn publisher. Likewise, you might want to protect a source or informant, which could be pretty broadly defined to include 'potential sources,' which would cover shopkeepers who don't want to be specifically on record as being friendly with the cops, but who the cops want to interact with and establish a relationship that may be useful to exploit in the future.

Besides, once there is a year of footage being recorded every day, it may not matter much if you get recorded talking to the cops. Your enemies will have to invest a massive labor force to find footage of you making off color jokes by watching all of it. (Unless the government successfully makes some awesome public facing database for finding this stuff, but in reality they would just hand half a billion dollars to a vendor, wait five years, and then declare failure on a project like that which a startup could have working reasonably well in a few weeks...)

ajax.googleapis.com isn't a tracking domain and your IP shouldn't be in any emails you send unless you run your own mail server.

Erm, that seems like a bit of a failure of imagination. Why wouldn't that be a "tracking domain?" Do you have some specific proof that it's somehow impossible for Google to use normal logging functionality on the web server for that domain? And that this will be true forever? Obviously, the idea that any particular domain can't be used for tracking is just silly. So, if google knows you visited the manufacturer's website, why couldn't they use that for ad tailoring when you log into gmail to send an email? Or anywhere else that you get a Google served ad, for that matter...

I'm not amazingly paranoid about this stuff, but to seriously dismiss the possibility of doing these things is just silly.

It's a good idea because magstrips are easy to erase and contacts are easy to destroy. It's unfortunate that this implementation is so crap, but that doesn't invalidate the concept.

I'm sorry, but no. The concept of contactless payment is just inherently broken. It's really obviously, blatantly, completely invalid. Making it possible for me to pay from a distance wirelessly without having to do anything specific with the payment card/source/token, means that I can be robbed without noticing it. It just takes a big antenna hidden in a backpack, or stuffed under a coat, or in a car. No matter how much you clamp down on the concept, you just require the guy robbing me to have a slightly bigger antenna.

If I absolutely had to design something like this, there would be a requirement for contact even if the data had to go over a wireless channel. Tap your conductive card on the metal plate to send a wakeup signal to the radio, or something similar. No moving parts, no requirements for the contact payment accepting device to keep the contact in pristine condition. Easy.

Well, if you had to cite a source, but all you had was your own recollection that you had heard the word, 'Meanderings of Memory' is pretty much the perfect name for it. It's even possible that within the community of people working on it, it was a well understood practice. Like giving a directing credit to Alan Smithee for a film. (For a guy who never existed, he sure was prolific!)

Related to this, ultimately what matters is the business plan. That will imply a few things...

1 - Why is this algorithm better than what's out there?
2 - Why can't anybody else do what this does? (Patents, at least.)
3 - Why you can't make money with it now, and how you will make money with it if they invest.

Frankly, without a lot more information, I'd be highly skeptical about investing in a video processing algorithm. Are you trying to productize it? Investing in product development is a very different matter from investing in an algorithm inside of a potential product. Are you going to try to license the technology? Why can't you do that without venture capital? It's fairly cheap to call Sony and try to convince them to buy the technology to stuff in their next cameras. Having a bunch more money won't make that a much easier sell.

You dont need a CNC mill. Let me guess, you think you need a supercomputer to write iphone apps? You can make a gun with rudimentary tools that are in many people's garages. How do you think gun smiths in the 1800's did things? You think they fired up their CNC mill and had their horse program the computer to start cutting?

No, but I do think they did it with a lot more skill and time than it would take me to push a button on a box I just picked up at Staples. And, with a less strict landlord than mine. If I had a workshop and the time to learn the skills, it would be awesome. But, in an urban apartment I will never learn how to make a gun by hand no matter how low-tech the process may be. And if I did, I'd never be sure if I got one wrong until I tried it and I checked to see if it blew up when I fired it. When it's a purely automated system making the parts, you can have a lot of confidence in the consistency.

I agree with your point, but would perhaps add a few extra bullet points.

#4. Where they already are. Tons of young coders started writing software for whatever type of computer was available in the living room rather than any rational assesment of which platform had the best dev tools. Tons of people will be handed blackberries by their corporate overlords, and have an itch to scratch. Those people already have full time jobs, so they won't be as prolific as full time mobile developers, but a lot of useful things have been generated by soembody who just wanted to scratch an itch.

#5. Where the competition is light. If the BB10 market turns out to be 1/10 the size of the iOS market, but has less than 1/10 of the developer focus, there may still be money to be made in that market.

#6. Where there are users. A couple of whiny users asking for their platform to be supported is sometimes enough to justify developer time. Especially for things like messaging applications, you want to be everywhere so that all the friends of your potential customer will also be able to get the app and interact with them. I buy multiplayer video games on things like Steam primarily because they support cross platform multiplayer. They don't have to be that great of games, as long as I know my couple of friends who have only OS-X will be able to play with the group.

These may all be relatively small factors for BB10, but it isn't quite dead yet. Just sort of pining for the fjords a bit...

My understanding is that there will indeed be something like RWX control. Not just for security, but also for performance. If boths ides can freely write to a chunk of memory, you can get into difficulties accounting for caches in a fast way.

That said, if the CPU and the GPU are basically sharing an MMU, then the GPU may be restricted from accessing pages that belong to process that aren't being rendered/computed. There's no reason why two different applications should be able to clobber each other's texture memory if they do something stupid. So, having the GPU share pointers with the CPU is potentially a very good thing for security. (How well AMD implements the concept in practice remains to be seen, but I'm optimistic.)

Because when you are doing stuff like OpenCL, dispatching from CPU space to GPU space has a huge overhead. The GPU may be 100x better at doing a problem than the CPU, but it takes so long to transfer data over to the GPU and set things up that it may still be faster to do it on the CPU. It's basically the same argument that led to the FPU being moved onto the same chip as the CPU a generation ago. There was a time when the FPU was a completely separate chip,a nd there were valid reasons why it ought to be. But, moving it on chip was ultimately a huge performance win. The idea behind AMD's strategy is basically to move the GPU so close to the CPU that you use it as freely as we currently use the FPU.

The way the system is set up, the government has to know something exists to be able to askfor it. It may sound slightly silly at first blush, but it's actually quite important. Imagine that a drug dealer is being prosecuted. They have sworn testimony that "yes, that hard drive has a list of drug suppliers called drugsuppliers.doc." from an employee. Failing to share the file is withholding evidence that the government knows exists. On the orher hand, if cops start going door to door to check everybody's computer for anything bad, they don't know what they are looking for. Forcing you to grant access 'just in case' would be a horrible violation. In this case, the judge is saying that the prosecution is just on a fishing trip. There might not even be anything specific to the case on that drive. There might be incredibly horrible evidence that makes this case even bigger. But in any case, the government needs some evidence ro start dismantling a person's life. They can't do it just on the possibility that they may potentially find some evidence.

You end up with unmaintainable code, late deadlines and an environment where numerous employees want to kill each other. Profit? Good luck.

It doesn't matter how talented the asshole is if he\she costs more than they're worth. I'd rather have a few mediocre developers who are nice to each other, write to spec, comment appropriately, and write code that anyone can understand and maintain.

Indeed, hiring an asshole rarely survives a really thorough cost benefit analysis. Unfortunately, the people who hire assholes never seem to take into account the potentially far reaching effects that one epic ass can have on a company. Even people who never have to interact with that person have to deal with the people who do, and the morale impact can be far reaching. I'm sure there are some rare cases where an absolute ass is unarguably the right person for a job, but these cases are few and far between. If there are any objections to be made, the long run cost is generally not worth the trouble.

(Recently had my asshole quotient expanded at the office. Have basically become completely ambivalent about the job. If they convince me to resign, they are losing one of the more qualified people in the US in a very narrow niche that I fill.)

It's kind of a nit pick, but Boston is often assumed to be larger than it is. It's kind of famous and 'important.' But, it doesn't make it on this page of "largest cities on earth:"

http://en.wikipedia.org/wiki/List_of_cities_proper_by_population

It's only about 20% of the population of the smallest city on that page. Not exactly sure where it ranks overall.

This is why. And this is because they don't understand copyright law and don't realize that unless they explicitly put the code into the public domain or apply a license, no one can touch it without violating copyright law.

It's probably a mixture of that and outright laziness.

Is this actually a really big deal? Given the massive number of repositories which probably contain nothing of great consequence, is anybody ever going to really need to fork more than 15% of what is on GitHub? And if they do, in most cases they can just ask the author for a license.

And, not being able to 'touch' may not matter if the author just intended for people to look. It doesn't really matter if something is GPL, proprietary or BSD if all I want is to see an example of how somebody used an obscure and poorly documented API. There are tons of libraries where a working example is worth a thousand apidoc pages that just give terse statements about functions in isolation.

Yeah, there are probably a lot of people who don't understand copyright and either think that they can use something because it is on github, or think that they don't need to pick a license for people to use their code. Most people are stupid. News at 11:00.

Dell is trying to say, "calm down, let's find a point midway that makes us all happy before this bidding war gets out of control." Who knows if that will work, but the likely endgame in all scenarios is that Dell the company will be destroyed.

Which is kind of a shame. Dell actually has some nice products. (Lots of terrible ones as well...) They are almost at the point where I would seriously consider a very large scale storage solution from Dell. (Think many hundreds of TB SAN) They have been acquiring some interesting storage companies and doing good integration work. Given that Isilon and BlueArc are currently both trying to kick their customers in the nuts, there is a good opportunity for Dell in the Datacenter.