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.

Almost nobody does real 'Beowulf' style clusters anymore, if you use a very precise definition, but in the broader sense this would be a compute cluster. I haven't studied the details of the proposal, but I'm not sure why this would ne revolutionary. Using a cluster for rendering video is pretty common. Burn clusters are used with Autodesk Smoke. Smoke used to be quite obscure but now that it exists on Mac it is seeing pretty wide use. From what I understand, Vegas has network rendering as well. Outside of strict 'editing' and into video comp and color, tons of people use things like Nuke and After Effects on a farm and Baselight uses a cluster. So, the idea isn't really revolutionary. It all boils down to whether or not the implementation is good or not, how it gets used, and wether or not it actually makes my life better.

Distributed processing for video editing is quite tricky. Unless you are doing a lot of fancy effects (which tends to happen in something like Smoke, but as far as I know Openshot has less in the way of professional finishing effects. Some of this would include cheesy stuff like lens flares. Most o it would be stuff like tracked stabilisation and degraining which can be quite slow) actually coming up with a video frame isn't that CPU intensive. When doing ordinary cuts only editing, you just have to seek to the frame in a video file, and decide the frame. For a proper editing format like ProRes, this is about as CPU intensive as decoding a JPEG. For interactive editing, that's pretty much it. Schlepping video frames across the network for that is a huge waste. If the remote system doesn't have the right codec installed, you are sunk. As your timeline gets more CPU intensive, you get more of a payoff for having Extra CPUs to throw at the problem over a relatively high latency and low bandwidth link. Figuring out exactly what to farm out and when is a nontrivial task and it won't be possible to come up with a system that works well for all possible use cases.

Anyhow, I wish them luck. Hopefully they come up with a feature set that matches their users needs. I may have to check out a current version. Last time I played with it, OpenShot wasn't really my cup of tea, but it is always good to see somebody getting support from the community to scratch an itch.

On the subject of working with a big network, and the sort of creative influence that levels of executives can have on a project... Can you please start this interview with a fist fight?

(A probably too obscure reference to the start of the B5 spinoff show, Crusade.)

Or, to put it a bit more seriously, given that you have had frustrations with the role that networks have played on some of your previous projects, how do you see the creative process changing as time moves forward and technology changes the nature of distribution? What do you see as an end-game for these trends moving forward?