No, your's can if you actively chose to make it do so in the same way that this chair can smack you squarely over the back of the head if someone actively choses to make it do so.

You seem to be arguing for the right to do something simply because it is possible. Do you really want to live in a world that works that way? Think about it for just a minute (actually, to an extent the world does work that way for some people, but that doesn't make it right...).

And I have absolutely no obligation to allow you, someone who is deliberately chosing to do something that makes my other patrons squeamish, to enter my establishment.

The bar owner isn't banning you from recording everywhere. He simply setting rules of conduct that may preclude you (should you break, or give indication that you intend to break, those rules) from entering his bar.

What people areguing against the bar owner here are aguing for a society where you can do what you want because the technology allows you to do what you want. Do they really want to live in a society that works that way?

Can we assume that you'll take the same attetude when someone happens to walk by when your wife/dughter/girl-friend/mother/sister/what-ever accidentally leave a curtain part open while changing?

You don't have that "absolute right" any more than I have an aboslute right to privacy, but you can bet your arse I'll struggle to maintain my chosen right-that-isn't-quite rather strongly, as will many others, so if you want to take that attetude you go ahead and we'll see which side wins out in our lifetimes.

The bar owner also has rights you know, and chosing to eject people who choose to make his other customers feel unconfortable is one of them. He can't ban you for something that is not a choice (colour, gender, sexual preference, ...) as that would be unfair descrimination, but your use of recording tech is no less a personal choice than the little dick in the corner swearing at everyone else & throwing peanuts (or for a less exagerated exampole: someone who chose to wear trainers that night to a club that has a dress code disallowing them). And to argue that you should be able to because one day they won't be able to stop you is simply bullying: give us your lunch money or we'll come back with more mates and you'll have to give it to us then.

The prosthetic eyeball isn't a valid argument with regard to descrimination, which I think is where you were going with that. We couldn't ban them any more than we could ban pacemakers, but they don't have to be made with recording features - if you chose to have a device with recording features instead of one that doesn't you need to accept that you won't be able to take it everywhere just like there are places I have to use an old non-smart phone (or non at all) instead of the fancier device I generally chose to rely on. Maybe others can't detect that you can record, but they'll know if you publish (intentionally, accidentally, or indirectly through having yoiur data store hacked) and you can expect your face on many a "don't let this prick enter" notices at that point.

Micro USB was not the problem though - it was their existing proprietory dock connector that was too big. They didn't replace mUSB with lightning, they chose lightining over mUSB as the replacement for the old connection method.

They give size as one of the reasons for the change but it is not the only difference, there are apperently both electrical and physical advnatages over mUSB (note: I've not looked into this so it could be astro-turfed marketting tripe for all I know) so I wouldn't jump to criticising the engineers purely on the size thing.

Of course the key reason to my cynical mind is simply because, any real advantages aside, it is different. They want to keep a certain degree of market serperation, however artificial. There are iPods and other music players, there are iPhones and other smart-phones, there are iPads and other tablets. The fact that many peripherals are marketted explicitly as iSomethingOrOther compatible is free advertising for their product range and helps cement the view in their target market's mind that their products are different (and right now that works in their favour: many people see the incompatability as Apple trying to do something better, rather than as a deliberate inconvenience intended to lock them in to an extent other manufacturers would not try right now).

With old hardware you need to adjust the maths a little with regard to the cost of power consumption. Newer processors and power supplies are much better at consuming less power when idle, and that is before accounting for physical components (processor and PSU fans for instance) getting less efficient with age and use. Also any extra waste heat generated is going to cost you in an air conditioned environment (and even if you are in a cold climate, that waste heat is hardly an efficient method of addressing that).

"they" decided no such thing with respect to drive size. Engineers and scientists have used SI prefixes that way for measuring the communication and storing of data for a long time just as they have used them for everything else too.

In the 40s/50s/when-ever "we" decided that 2^10 was more convenient than 10^3 as a basis for memory measurement, deviating from the already accepted standard. Drive manufacturers have always gone with the other engineers and scientists and used the generally accepted standard rather than our forked one.

It still makes sense to measure RAM using 2^10 prefixes because of the way it is built which makes this produce nice round numbers, but people need to get off their high horse about drive manufacturers as they are doing nothing wrong: it also makes perfect sense for them to follow the standard that related fields have followed since long before the general public had heard of "mega" this and "giga" that at all.

In fareness to the manufacturers: that contract you are stuck with is not with them nor was it arranged by them. Though you are right, lack of updates for rather expensive devices after small amount of time is something that puts me off Android based devices at the moment.

Actually, most of the hate is the other way around: people berating MS for forcing mobile optimised elements on the desktop.

If they had limited carrying capacity then it'll have come down to known/unknown factors. They'd have some knowledge of how to identify iDevoce versions (as they are likely to be retail units) and know the back-o-lorry market value for the iPads with some degree of accuracy so they'd know what they were walking away with. The surface units they'd know less about in those regards: it is possible that they are pre-production units or otherwise easily identifed as from there rather than the retail channel, which would make them harder to shift even if there were a good price for them generally on the nicked market right now.

By "some time" I'm meaning days or weeks, not many months or more.

Slap everything commented that doesn't need to persist with a "CLEANUP" tag and scan for them pre-release or at then end of a run of sprints (and/or as you approach a release, where-ever it fits in your flow) as part of your other housekeeping tasks. Give the job to a junior so he/she might learn from the changes (have a more experienced dev to hand in case of questions, and to try make sure the wrong things are not learnt from less "clean" work).

Each open source project will their own preferences and rules which are fine by me, but equally are not my problem currently (if I were to have something to contribute I'd would of course try to fit into the project's preferred coding standards (or just release my changes as-is and if anyone else wants to clean them up and claim the credit they can go right ahead, if not then fair enough too)).

Commenting just code is fine for temporary testing/debugging/rewriting.

Leaving code in a commented state is a comment ("this is how something used to be done here"), but not a terribly helpful one. If you find yourself doing this, as well as commenting the code add a true comment stating why and what code replaces its function (the bit above, the bit below, something elsewhere, nothing (it is truly deprecated)?) and why.

Once some time has passed, unless the change is significant and there is a chance someone will come along and "unchange" it not knowing the history, such comments along with the commented code should be removed as it is all in source control anyway - but keeping it in your face (and the faces of other people working on the code) in the short term can sometimes be quite helpful especially in the case of code several people are actively looking at as one of them may quickly spot a flaw (which may otherwise go unnoticed for a while longer) that makes your new more clean/fast/bugless code far less perfect than you first thought.

The amount of jiggery pokery they'd done to the internals was quite obvious and caused one of Vista's greatest problems. A lot of the internals had changed including several alterations that meant needing new drivers for existing devices which a lot of manufacturers didn't bother producing (why would Epson, to give an example I presonally experienced, spend time writing drivers for their old devices, time they'd see no money back from, when they might instead get some sales of a new devices when peopel discovered Vista didn't like the old ones?), and often the Vista drivers (both for new devices and where they were created to support old ones) were much less tested than the existing XP ones so early adoptors exsperienced a lot of bugs.

Probably at some point, once the relevant evidence is collected and researched. There have been a couple of cases against high profile individuals in recent years (http://en.wikipedia.org/wiki/Roman_Catholicism_in_Belgium#Pedophile_priests_scandal) but collating the right evidence to make a solid case against a large organisation is rather more difficult.

Altering a video convincingly is much harder than an indivdual frame, though still possible.

In this instance a there will be other evidence to back up the video: the sequencing of the lights will follow certain patterns for instance, so changing the colour of lights in the video is likely to create a sequence that simply isn't possible. In most cases where video or photographic evidence is accpeted, it is used in conjunction with other evidence rather than trusted on its face value alone because of how many ways such things can be tampered with.

Also in instances like this it is unlikely to come to court. The insurance company certainly won't fight like that, and the driver will hopefully have either the good sense to not waste the time and money or not have the time/money to throw at such a case anyway. It it really was the insurer calling then it would have been simply to check that they were safe to reject a claim, if not then it will be someone acting on behalf of the driver testing the water to see if there is enough evidence to make a claim (or further appeal) pointless.

The quote is "open-source information" - the lack of capitalisation is significant here: no link to the OSI is intended to be implied.

Open-source information is a fairly common term in some circles, it refers to information that can be obtained or derived from sources that are open to (legitimate) public access. In other words accessing that information does not in itself constitute a break of any law or other rule.

Of course the way he used the information once he had obtained it is another matter.

They can't in this instance. "open-source information" is a phrase that has been used by people intelligence services, academia, and other organisations since long before the OSI existed in any form. Even if they could afford the team of lawyers Microsoft use to defend their sole use of the word "windows" in certain contexts, I doubt this would be one of the contexts where they would win.