Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Norway is way lower than that (Score 4, Informative) 640

Norway has had 0.02 as the legal limit for _many_ years now, this basically means that you cannot drive after a single half liter of beer, glass of wine or a shot of whisky.

I.e. all driving after drinking is drunk driving. BTW, when Norway introduced a legal driving limit in 1936, it was the first country in the world to do so:


This web site (in Norwegian) shows the current rules: 0.02 to 0.05% leads to a fine of 1.5 months worth of your gross salary (or average income if you're a stock broker or similar), which means that it can get very expensive indeed when if the driver is a rich idiot. (Those fines are for when you are stopped without any accident, in a crash they will go up and your insurance won't cover anything.)

At 0.12%, i.e. 50% over the US limit, you are looking at at least 21 days in prison on top of that huge fine.

We have a lot more Teslas per capita here than in any other country but I haven't heard of a single drunk driving incident so far.

"Fast cars don't kill people, bad drivers kill people."

Comment Re: Makes sense. (Score 1) 109

Keeping the rats and fungi at bay can be tricky; so long-term survival is only assured in optimal cases. That said; the fact that ancient-recipe booze tends to be aggressively unfiltered by the standards of even the most yeast riddled modern variants quite possibly has something to do with the fact that you definitely lose calories if you do the filtering and clarifying necessary to get the 'suitably tinted; but otherwise optically clear' results that are currently favored.

You can recover at least some of the losses if you feed fermentation byproducts to livestock, use them as fertilizer, etc; but if hunger is a real constraint the fact that there's effectively bread sludge suspended in your beer starts to look more like a virtue than a defect.

Comment This seems pretty dubiously useful. (Score 4, Insightful) 142

This seems like a rather touchy solution looking for a problem.

Unless you really enjoy buying replacement hardware; the need to have battery power in order to trigger the kill switch is a problem. If you don't configure the device to self-destruct when its battery is on the verge of no longer having enough energy to perform a self destruct; all the attacker has to do is run the battery down. If you do configure it that way, forgetting to put it on the charger could get expensive and tedious rather fast(in addition to the various other issues that can interrupt battery power: overtemp protection kicking in in a hot car; current delivery capability falling under freezing conditions, etc.)

Plus, the battery, and its connection to the logic boards, tend to be among the larger and more obvious parts of a modern electronic widget. That makes them good candidates for controlled disconnection/destruction, even if you can't open the case without tripping some sort of anti-tamper mechanism.

Finding a good self-destruct temperature is also a bit tricky. The lower you go, the closer you get to the high end of normal operating conditions or the 'device won't operate; but should not be permanently damaged' range. 80 degrees is high for flash memory; but most CPUs will be happy enough to run that hot. The higher you go; the more power you need to be able to deliver to kick off the destruction; and the more vulnerable you are to an attacker who is able to apply coolant to slow you down; limit current or voltage delivered to the resistive heater, or both.

Comment Re:Mozilla...getting it wrong so you don't have to (Score 2) 163

I certainly don't disagree that Flash should be taken out and shot on security grounds; but it is pretty much the last NPAPI plugin that you are likely to piss users off by dropping support for. iOS got away with it; but Safari continues to support it(though grudgingly); Chrome killed NPAPI; but the 'Pepper' plugin interface appears to exist primarily to support Flash; Edge also whitelists Flash; and Flash on Android died mostly because Adobe couldn't make it work very well; not because Google shoved them off the platform.

Given Mozilla's less-than-commanding presence in the browser market; I suspect that they can't afford to take a hard line on flash right now.

Comment Re:Context please (Score 1) 163

If Flash is being whitelisted; the main news will be Java applets(much rarer than they used to be; but a distant second to Flash in the embedded-blobs-of-stuff-that-can't be done in HTML, at least not when this site was built market); maybe Shockwave; if anyone still uses that; and then mostly shitware(at least at one point, Acrobat or Acrobat Reader would install something to grab PDF handling, some AV packages would inject their little contribution; Cisco has a hilariously vulnerable Webex support plugin that makes joining webex sessions incrementally easier and remote code execution a lot easier).

There really just isn't all that much anymore(which is presumably why FF is doing it; and why Chrome already did). Much as Oracle is a bit petulant about it(just visit the java download page in Chrome to see a nice little whine about how Google 'disabled the standard plugin mechanism'); relatively few people care; Flash is still hanging on; but Shockwave is pretty much dead; and most of the seriously hardcore legacy cases, the ones that will probably outlive some of us now talking about it; tend to involve ActiveX somewhere; so NPAPI plugin support is irrelevant; because NPAPI-only browsers never worked; and if they also need Java or something it continues to be available as an ActiveX plugin.

Comment Inevitable (Score 5, Insightful) 97

We already dropped 32-bit support in DFly. There are many good reasons for doing it on Linux and the other BSDs as well. I will outline a few of them.

(1) The big reason is that kernel algorithms on FreeBSD, DragonFly, and Linux are starting to seriously rely on having a 64-bit address space to be able to properly size kernel data structures and KVM reservations. While (for FreeBSD) 32 bit builds still work, resource limitations are fairly confining relative to the resources that modern machines have (even 32-bit ones).

(2) Being able to have a DMAP makes kernel programming a whole lot easier. You can't have one on a 32-bit system unless you limit ram to something like 1GB. Being able to make a DMAP a kernel-standard requirement is important moving forwards.

(3) Modern systems are beginning to rely more and more (on x86 anyway) on having the %xmm registers available. To the point where many compilers now just assume that they will exist. ARM's 64-bit architecture also has some nice goodies that it would be nice to be able to rely on being available in-kernel.

(4) Optimizations for 64-bit systems create regressions on 32-bit systems. Memory copies, zeroing, and setmem, for example. Even if 32-bit support is kept, performance on those systems will continue to drop.

(5) There is a lot of ancient cruft in 32-bit code that we kernel programmers don't like to have to sift through. For example, being able to get rid of the EISA and most of the ISA support went a long ways towards cleaning up the codebase. Old drivers are a stick in the craw because nobody can test them any more, so the chances of them even working on an old system is reduced for every release. Eventually it gets to the point where there's no point trying to maintain the old driver.

(6) People should not expect modern features on old machines. The cost of replacing that old machine is minimal. Live with it. It's part of the price of progress. If the industry is a bit slow understanding what 'old' means, than the fewer systems which support these older architectures the better, it will make the point more obvious to the corporations who've lost their innovative edge.

(7) For ARM, going back to the corporate point, there's really no reason under the sun to continue to produce 32-bit cpus, even for highly embedded and IOT stuff. The world has moved on, and even embedded systems have major resource limitations in 32-bit configurations. If kernel programmers have to put an exclamation mark on that point, then so be it.


Comment Re:EMC/UL testing?! (Score 1) 67

It is true that there is no requirement about intereference resistance(unless perhaps you are selling fancy gear to the DoD or the like); but, unless rather carefully engineered, badly shielded systems tend to leak both ways; and a contemporary high resolution display isn't exactly short on very high frequency signal lines and similar sources of RF noise.

The FCC doesn't care if your device falls over as soon as someone gives it a funny look; but unless this display was beautifully engineered for low emissions from the circuitry, without reliance on additional shielding; it's a trifle surprising that wholly inadequate shielding wouldn't involve RF leaking out, as well as in.

Comment Re:Go fuck yourself... (Score 2) 67

This issue is an obvious defect from a customer perspective($1,000 for a computer peripheral that malfunctions if the wifi is too close? Are you kidding?); but from a regulatory perspective I'm not sure why LG would be in any trouble. If failure modes don't include catching fire/electrocuting the user; it's not like UL or the consumer products safety commission cares; and the FCC's usual stance is

"This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation."

Which would justify a beatdown if the LG monitors were disrupting other devices; but allows(indeed, requires) products to suck it up and deal with the presence of licensed RF and FCC-compliant ISM/misc background noise. The customer obviously has reason to be displeased; but regulatory bodies are mostly concerned either with devices that are overtly dangerous; or devices that do RF things that step on other people's toes. Pitiful resistance to interference isn't their concern.

Comment Re:Another instance of "cheaper than possible" (Score 1) 55

Good to know. I've been poking at the idea of trying to purge my environment of wall warts and line lumps by moving AC-DC conversion duties to a single high efficiency PSU in a case with a whole bunch of front panel connectors; but (in addition to bells and whistles like load monitoring) I'm trying to avoid any unforeseen issues that would either set things on fire or damage equipment. I knew fuses were a good plan; but I'll definitely have to take note of the diode consideration.

Comment Re:Another instance of "cheaper than possible" (Score 1) 55

I had forgotten about those; but you are correct about them existing. It's a pity that the cigarette-lighter socket, while entrenched for historical reasons; has got to be one of the more ridiculous power connectors to have ever approached mass market use.

Slashdot Top Deals

User hostile.