Doctors Without Borders risk their lives giving medical aid to people that are in such dire conditions that "normal" medical people can't or won't work there anymore. They do it without asking the people they treat for any compensation.

How would you put the ability to write JavaScript anywhere in the same ball park? If you want to help out in any way, learn a medical skill and go out in the field with MSF. Don't ride on those heroes names in your arm chair with your covert job seeking advertisement. While you may want to do good, JavaScript can be written anywhere on the planet and used elsewhere. Stopping some four year old kid from bleeding to death because they just got shelled with a "barrel bomb" dropped from a helicopter can't.

This may seem a bit harsh, but my girlfriend works for MSF. She left last Friday to go on a "field trip".

There is contradicting evidence of series of small earth quakes are an indication for a bigger one to follow. Whether the actual earth quakes have an effect on the likelyhood of a bigger one happening is even a step further in the kind of science we are only starting to figure out. Causation, correlation and chance when it comes to earth quakes so far has been historical statistics and no significant trustworthy method has yet been discovered. Sure, we've made progress and statistics are favorable, but right now there's nothing you can trust on in terms of magnitude or time of earth quakes in the (near) future.

If you eat certain food, you could theoretically gain more than 1 gram of weight for every gram of food you eat. The human body is mostly made out of water and you can't go on a "drink less fluids" diet. That means that if you add 1 gram of solids from your food, you could very well add more than one gram of water to your body weight, even if that water holds no calories at all.

Olympic size swimming pools filled with Starbucks coffee for large quantities.

This problem is easily solved by placing the liability of a "proper" locking system on the manufacturer and vendor of the car. If the system gets hacked, the manufacturer should be made liable to come up with a fix for that, or buy the car back from the owner at the original price of sale. In the UK most of the provisions for such a system are already in place. It will just take a relatively small and easy law where the party responsible for sale and/or manufacture of a device that later turns out to be fundamentally broken be made liable for the costs of replacing, reparing or taking back the goods.

This will probably turn in to a discussion of what "fundamentally broken" is, but I'm sure the courts will be able to take care of that.

Systemd has it's downsides. The real downside is that you have so much complex code running as root. most other complaints can be dealt with.

Binary logfiles: You're not supposed to keep important log files on the local machine. Send them to your central logging facility where they are stored in a database. If the machine is still running, you can use the appropriate tools to look at the binary log files for debug. All your logging, stats and alerting should be centralized anyway.

Doesn't feel unixy: Get with the times. It's scriptable and tweakable more than ever. Just get used to the way it works.

Solution looking for a problem: Just not true, see the benefits.

Systemd is one of the options to solve some problems that have been pestering unix for a long time.

Dependency in services: Systemd can restart all dependencies on a service in the right sequence if you have to meddle with one part of a stack

long startup times: Systemd has the possibility to start up things in parallel. No long waits for earlier systems that your service doesn't depend on. Mostly useful for mobile users, but HA systems benefit too due to shorter maintenance downtime

Location/circumstances specific profiles: Depending on where you are and what kind of facilities you have available, your system can "adapt" by changing power profiles, network connectivity, firewalling and whatnot. Primary benefits are for mobile users, but servers changing load depending on things like overheating, having to run on UPS power and such are also quite useful.

Systemd isn't the only project that wants to work this way. Upstart is another one that at least wants to deal with the startup concurrency and dependency problems of classical init. Sun (Oracle) Solaris SMF is also a good example of this line of thinking.

While you can have doubts about the amount of complex code and forks to 3rd party code done by systemd while running as root, I don't think it's useful to complain that someone moved your cheese and took away the init scripts you used to use in the old days. Once you figure out how to work with the new tools, you'll find it's way more tweakable and controllable than classical init. If in the end you choose for init or a different alternative, that's up to you, but at least investigate and educate yourself, before you start complaining with arguments that just aren't true.

they are illegal in most of Europe, which is why this company went through the trouble to make "Cop Detectors".

No, they can't and won't ban these, since they are passive receivers and they detect *any* emergency person carrying a radio. I do suspect that the mobile speed trap teams will switch off their 2-way when working and use their cell phones for connecting with home base. Radar detectors only have a single purpose and because of that purpose they get to ban them for "hindring police investigation". You can come up with semi-legit reasons for having a device that will detect if someone with an emergency service radio, but you can't come up with a single one that will detect speed trap radar signals.

Speed traps with their radios switched off, will only leave unmarked civilian police cars with cameras on board and special "ProVida" brand equipment that are used to film evidence of people speeding by driving behind them that can be detected. Those can't be detected with radar detectors and will be detectable by this system. Still, the amount of speeding people that get caught will be so large with these systems for sale, that I doubt they ar worried much.e

This system has been in "testing phase" for quite a while, I remember reading about beta tests probably over a year ago, so it's hardly news. If they'd be worried, there would have been something happening already.

It's up to the OEM and MicroSoft to risk bundling the OS with the machine. It's up to the OEM to add crapware that they actually get paid for to install on the machine. If a consumer wants the machine without the software, they should get the retail price of the software discounted off the price of the bundle.

Who pays for the price difference between the money the consumer gets back their money is between the OEM and MicroSoft. Maybe this will teach both to price stuff reasonably since the consumer now will be able to make a more informed and concious desision on actually paying for the OS, or getting a cheap(er) or free alternative.

Sure, you'll see more people pirating Windows. But right now, many companies have to pay twice for a windows license. Once when they buy the machine and once when they install the enterprise version they have a volume license for. That's just as much theft in my book. Upgraded your main board? Pay again for the windows license. You can't have your cake and eat it too. If you sell software, it's not fair to force people to buy it even if they don't use it, just because otherwise someone might pirate your alternative if the computer is sold without an OS. You want to sell, you take the risk.

Disclosure: I work as a penetration tester In my line of work, we often go for passwords, encrypted or not. Especially on office networks, we go for the LANMAN (yes, we do get to see those on a regular basis still) or NTLM password hashes. Even NTLMv2 are useful to us, although cracking those requires more time.

The reason that LANMAN and NTLM are so useful to us, is that we can just use the hashes to authenticate against remote servers. That's right, knowing the password isn't required, just having the hash is enough for the remote server to authorize us as the person that the hash belongs to. This is "fixed" in NTLMv2 and if you properly implement Kerberos for your AD authentication. However, since legacy systems are abundant, in practically every office network we encounter, the older systems are still in place because of "backwards compatibility requirements".

No amount of password complexity helps against the above problem. Several commercial 2-factor vendors solutions aren't even a solution. Why? Because they replace the password prompt for a prompt for a token generated by their device and once that reply is satisfactory, they simply send the hash themselves. Their solution replaces the password, but not the real weakness, the hash itself.

This may not be a significant problem on the internet, but once an attacker has gained access to your corporate network, this problem usually means doom for anything password protected. This sort of thing happens on a larger scale than most internet users realize. Advanced Persistent Threats (APTs) aren't named that for no reason and they are just a few of the many organizations and individuals attacking companies these days.

Because biometrics can often be cloned, copied or otherwise be "fooled" when used for authentication. Finger print scanners are worthless since so many attacks exist to current finger print readers when someone copies your print. You can't get new finger prints once someone made a copy of yours, so as an authntication method they are worthless.

Some other authentication methods using biometrics exist, but they are generally too expensive to implement in most cases. They may not be "affordably" circumvented yet, but I have no doubt that once it's worth it to put time and effort in it, people will find ways to fool those systems too. I'd hate to have to get new eyeballs because someone copied a scan of mine onto a synthetic ball.....

Apart from this, remote authentication using biometrics replaces the biometrics with some sort of device sending some sort of signal to the remote location with either a signature of the biometric information, or just a version of "I've check this person out and they're okay". You once again transfer the problem from biometrics to some form of digital communication which obviously is just as weak to hack as the technology you are trying to augment for being weak.

You just created one tiny extra step for people stealing the database. If a system is so flawed that an attacker can get your database, they will most likely only take a few extra minutes to get their paws on your salt.

Granted, they need to write their own module for oclhashcat to get this cracked at a decent speed, but once that's done, your proposal isn't functional.

You must have encountered one of the few systems where people actually pay attention to such "details". There are plenty of locations where you can brute all you want and where the entire DB of passwords or hashes is relatively easy to obtain for a hacker. Since people re-use passwords a lot, that's often enough to get into the few locations where brute-forcing is made more difficult.

This is clearly a crime, thought out well in advance by a group of people. Membership of a criminal organization afaik is a felony. Are the owners and management of this company prosecuted for this?

His implementation only uses non-secret memory and should therefor be safe from these patents. The patents described here rely on the contents of the memory of the contraptions to be "secret" to make the process "secure".

You could even say that the original implementation by INSIDE secure doesn't follow the patent since obviously, the memory content isn't that "secret" anymore.

So maybe they also worked 10-20 hours a week longer than the control group? Maybe they ate different things? Maybe they lived in a more urban environment?

There have been so many of this sort of researches carried out that came to the wrong conclusion that while this is worrying, I doubt that there's actually any scientific value in this at all.