The data retention directive specifically says they must retain elements that identify the origin and the destination.

Please read it. The level of fachism scares me.

From what they demand to storing URLs, is merely a matter of semantics, and the danger of that being done was predicted long before the directive was approved.

The Data Retention Directive is the equivalente to having a spy per citizen, noting down who he talks with, where and for how long.

Would you accept this in real life? No. Why do you accept it online?

Repeal the Data Retention directive now!

You're right that you don't have to implement an idea to patent it. But your patent still only covers such an implementation, even if it's never done.

It totally begs the question: how is that a benefit to society?

What you write in software is the expression of one idea in a certain language.

You don't "invent" software, software has been invented many eons ago when living beings got brains.

What software patents cover is the concept. If they covered a specific implementation, they would provide a worse legal environment than the copyright, in the point of view of the authors, for it would last many, many years less.

And as anyone who wrote software can tell you, ideas are a dime a dozen, the devil is in the details. It's the expression that counts in software, and not the concept.

Well, suppose you're selling GNU/Linux desktops. Now to make your bidding for a public tender in Portugal you need to NOT USE your own dogfood?

You need to buy from your competitors in order to compete against them?

Seriously folks, this is a REAL issue (plus, this mess was paid with my taxes, I'll have to demand a refund).

I won't dispute your point, only remark that ntfsfix, as other ntfsprogs, tries very hard to be conservative, and bail out if unsupported metadata is found.

For my cases, it has worked correctly. One recurring problem is with a NTFS formated pen disk, that sees some hard shutdowns.

ntfsfix is the equivalent fsck.ntfs

It comes in the package ntfsprogs.

Since you got moderated to "insightful" and I don't have moderation points in this article, I'll have to take the bait:

the Apache license is MUCH more free than the GPL

They're both just as Free Software. Claiming one is "more free" than the other, is a proof that you're confusing issues and still have something to learn about Free Software licensing, because for instance...

in that you can do anything you want with it

No, you can't. You can't claim you're the author, for instance. Actually, it's very hard to find a popular license where you can do that. In some jurisdictions, it is even legally impossible to do so.

including closing it if you are so inclined.

That you can, and it is a crying shame.

Plus you don't have to buy into the feverish and rabid philosophy of the majority of GPL disciples.

Funny you should say that, since your comment is quite philosophically rabid, like the majority of the GPL haters club.

Plus, let's flip this on its head: do you REALLY want to have to publish your changes so that Microsoft can take advantage of your hard work?

No Free Software license mandates publishing. The GNU GPL in particular only mandates that IF AND ONLY IF you publish, then you must provide the same rights and obligations (in a very broad overview, read the text for the gory details) you got when you got a copy of said software.

Besides, when you do publish in a license like Apache's, Microsoft can take advantage of your hard work and it is very likely to do so.

Indeed it has done so, albeit not Apache, but a somewhat similar but quite shorter license, previously.

"Personal responsibility... try it!"

Oh stop being stupid with that red herring!
This isn't about "personal responsibility".
It's about transfer of effort and risk from the company billing you to you yourself.
And about companies removing a service that they have led you to expect will be available. This person is expecting to pay their last bill online, like they expected to (and succeeded in) paying their previous bills online.

"Paperless" or "Online" billing simply makes it entirely your own problem to remember to make the regular effort to access the billing information and print it off or save it (and back it up). It does not remove the requirement to keep your own archives for as long as you need them (which for financial information is as long as the taxman can ask for it!)
Many companies can and will blame you when you don't have a copy of the billing information because you didn't download it or relied on them to keep it available, from utilities to banks.
So the only way is to either archive it yourself, religiously, or have them send you bills.
$30 payment for going paperless, as offered by my bank? $30 doesn't pay for very much of my time spent downloading and saving records. I'll stick to having my bank send me the information in a handy-to-archive form on durable media so I don't have to think about it.

In some parts of the world, notably the North American continent, one cannot expect SMS between carriers to work properly; there are many missing routes, including where there is a route from carrier A to carrier B but not from B to A so you can't get a reply to your SMS. Also even when it works it can be very slow, transit times of hours are within my experience.
It's not like Europe where SMS can be expected to work so well that it effectively always works and is fast.
Of course the North American telcos still charge you for your SMS when it disappears into hyperspace because their network isn't configured properly, but I'm sure you all expected that.

While it is true that SMS is carried in the control channel of GSM [1] and that control channel has reserved bandwidth not available for voice call channels, it is also true that heavy SMS traffic will saturate this control channel and that some carriers have had to increase the control channel bandwidth in order to make room for the volume of SMS. You can observe the control channel saturation (and resulting inability to set up new calls, while existing calls continue fine) in any major city in the UK from around 23:45 on 31 December to 00:30 on 1st January. So the carriers do have to put a bit more bandwidth into lots of SMS.
However there is also an SMS messaging centre to operate, which is a pile of computers to route messages, as well as storage on each cell base station for the SMS waiting to be transmitted to the handset - rather like email it's too cheap to meter, except for all those mail servers you need to forward and store the email.
The profit margin on SMS is clearly huge (consider that bulk SMS rates are at most half the cost of single SMS out-of-plan from a handset in the UK) but it's not 100% profit and 0% cost.

And finally, think about spam: the reason you don't get much SMS spam (compared to email) is that it costs quite a lot to send SMS compared to email. If you make SMS as cheap as email, you'll make it as spammy as email, and you need to think about how to avoid that.

[1] I'm going to ignore CDMA here, I wish the rest of the world would do the same.

This is an interesting test, but some market leaders are missing, notably Trend (El Reg quotes Gartner saying Trend has 13.8% market share, third after Symantec and McAfree). If I am to use this research to pick a solution or to pick a better solution, the chances are high that someone in the management is going to "suggest" (try to make me use...) "Trend" because they've heard of it; if they suggest "McAfee" I can use this research to shoot that down, but not Trend.
Meanwhile, to bang the open source drum, they also didn't test Clam AV. I don't know Clam's market share, but I have to say I like it a lot for its ease of integration into my UNIXy infrastructure compared to the commercial ones I've tried, and I consider it worth testing because of its different development methodology with undoubtedly different strengths and weaknesses compared to the big commercial AV vendors.
So it's all very interesting but not entirely useful to me.