aexaey

One cubic centimetre of water at 4 degrees Celsius used to define one gram (or more precisely one litre -> one kilogram, which comes out to be the exact same thing) [1], [2].

Although 1 cm^3 of water is still pretty damn close to 1g.

[1] https://en.wikipedia.org/wiki/Grave_%28unit%29

[2] https://www.youtube.com/watch?v=ZMByI4s-D-Y (around 1:50, and actually the whole video is excellent)

Article's author also confuses units:

    "The entire planet’s electrical consumption is right around 5 terawatt-hours."

...consumption is of course power, i.e. watts, not energy, i.e. watt-hours. That is not to mention that 5TW is a wrong estimate:

http://www.wolframalpha.com/input/?i=world+electricity+consu...

Neat idea, although I would probably stick with irssi[1] running on my server and connecting with mosh[2] to that for mobility with instant session resume.

[1] https://en.wikipedia.org/wiki/Irssi

[2] https://mosh.mit.edu/

Well, you kind of need a number to not be a prime to successfully factor it (into anything other than 1 and itself).

Yes; together with the actual code, weird concept of "COMMON WORDS THRESHOLD PERCENT" (original author's capitalization), and a cursory look across imported library by the same author and its scant documentation.

Is there something in particular, apart from generous amounts of gratuitous complexity, that you would like to point reader's attention at?

That is way over-engineered for something that could be done with a 10 lines of bash:

    diff2mail() {
        a=$($@)
        while true; do
            b=$($@)
            if [ "$a" != "$b" ]; then
                echo "$a -> $b" | mail -s "$@ changed" 'root@example.com'
                return
            fi
            sleep 1
        done
    }

    diff2mail ls /tmp

And for a lot of stuff it's even shorter than that:

    make && x="is done" || x="has failed"; echo "build $x" | mail root

It's in linux-next, so this will show up in 4.4:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next...

[EDIT: s/4.5/4.4/]

3 different kinds of NaNs is pretty rad too. No idea what's happening here:

   >>> x = 0*1e400
   >>> set({x, x, float(x), float(x), 0*1e400, 0*1e400})
   set([nan, nan, nan])
   >>> set({x, float(x), 0*1e400, 0*1e400})
   set([nan, nan, nan])
   >>> set({x, float(x), 0*1e400})
   set([nan, nan])

EDIT: it gets worse:

   >>> x = 0*1e400
   >>> y = 0*1e400
   >>> z = 0*1e400
   >>> set({x, x, x})
   set([nan])
   >>> set({x, y, z})
   set([nan, nan, nan])

In the Netherlands, government is actually incentivising people who drive a lot to buy diesel cars, but not those who drive only a little, and that is going on for quite a while already. Here is how it's done:

- Diesel fuel is considerably cheaper at the pump [0], plus diesel cars have better per-liter mileage. Thus per-mile expense for a diesel car is roughly 1/2 of that for a benzine car.

- Diesel car is roughly twice as expensive in yearly road tax (EUR 1580 / year for a 1500kg diesel car vs. EUR 808 / year for a 1500kg bezine car in Amsterdam) [1], plus a diesel car would typically be slightly heavier. Thus per-year expense is much higher for diesel.

Two observations above combine in a well-known locally rule of thumb - if you drive >20000km/year, buy a diesel; otherwise you're better off with a benzine car. This matches perfectly with the inherent technical requirement for a diesel car to be driven mostly in long trips to be efficient or relatively clean.

[0] http://www.anwb.nl/vakantie/reisvoorbereiding/brandstofprijz...

[1] http://www.belastingdienst.nl/rekenhulpen/motorrijtuigenbela...

* not cube (n^3), but fourth degree (n^4)

* not of vehicle weight, but per-axis weight

Trucks are still big "winners" though - see masklinn's calculations here.

The answer to the "knowing what options are" is auto-complete [0], [1]. (Almost) nobody knows all the commands by heart.

[0] http://www.cisco.com/c/en/us/td/docs/security/fwsm/fwsm31/co...

[1] http://zsh.sourceforge.net/Doc/Release/Completion-System.htm...

It is a moot point. Having seen (but not driven) model S, I can't say it looks big enough to warrant comparison to a 7-series, and even then latter is 1800kg [0], so Model S is still 17% heavier or causing 1.85 times road wear.

Point about trucks stands of course, as you've pointed in the other comment. 3-4 orders of magnitude more road wear - that's crazy! I wonder how does that translates to truck road taxes.

[0] http://www.bmw.com/com/en/newvehicles/7series/sedan/2015/sho...

> Electric cars have as much wear-and-tear on roads as gas cars

Sometimes even more. Of course that depends on exact car that is being compared, but as a rule of thumb, an all-electric vehicle would be significantly heavier due to battery weight, and as was pointed out:

> Road damage rises [...] to the fourth power of the axle weight [0].

Salient example is a Tesla model S, which have a curb weight of 2.1 metric tons in standard configuration [1], while comparable gasoline-powered sedan weights in at approximately 1.5 metric tons [2]. That means that applying formula above, "average", electric car causes 3.6 times more road wear than "average" CO2-belching one, just due to being 40% heavier while having same number of axles.

To make matters worse, many countries tax vehicles based on their weight (so to translate a fair share of road repair costs to the vehicle owner). And that makes subsidies (in the form of tax exemptions) to the electric vehicles even more important - otherwise electric cars would not be able to compete at all.

[0] https://en.wikipedia.org/wiki/Gross_axle_weight_rating

[1] http://www.teslamotors.com/support/model-s-specifications

[2] http://www.bmw.com/com/en/newvehicles/3series/sedan/2015/sho...

> The ATMega328 is 8K of RAM

No, just 2K. [0]

> The M0+ chips seems to all come with 64K of RAM

That would be 8K. [1]

[0] http://www.atmel.com/devices/atmega328.aspx

[1] http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1817?sc=...

This gives a very interesting data point to the "open-source" vs. "free software" debate. Normally free/libre software zealots would tout BSD/ISC/Apache licenses as a way to never get back any downstream changes. And yet - cloudflare did contribute back nicely to a BSD-licensed project, in a situation where they were absolutely not under an obligation to do so.

In fact, even GPLv2 would not have imposed an obligation to publish changes here, only a super-strict GPLv3 would.

One data point of course, hardly warrant a far-reaching conclusion; still - that is something very nice to see.

If intent and actual effects of EU cookie law are anything to go by, EU Safe Harbor is going to create:

- a "value-add" or middleman opportunity on service provider side (think hosting companies differentiating themselves as compliant, like in discussed piece, or offers of "one stop EU compliance", and similar check-box ticking);

- more annoying popups for users ("this service is not available in your country", "click here to acknowledge you are outside EU", etc).

That was an excellent story. Was discussed here too: https://news.ycombinator.com/item?id=8305283

Or better yet, integrated into Raspbian, so that containers would be "apt-get install docker" away.

Following that logic, it would make more sense for systemd team to get an own language, something with traits of rust, go and haskell, and port everything to that, at which point it wouldn't be much of a stretch to drop libc and with it all support for "unsafe" languages.

What about free baseband?

http://bb.osmocom.org/trac/

Wouldn't work directly here, as "ip fou add" reserves a local port, while in OP's case it's a reserved remote port. And reserving local port 53 in case of 53<->53 packets would kill dns resolution.

With an extra iptables rule should work though:

  iptables -t nat -A PREROUTING -s my.server -p udp --sport 53 -d DNAT --to 127.0.0.1:5555
  ip fou add port 5555 ipproto 4

Title is a click-bait and a huge exaggeration over what is actually written there:

> IAD will initiate a transition to quantum resistant algorithms in the not too distant future. [...] Until [next Suite of cryptographic algorithms] is developed and products are available implementing the quantum resistant suite, we will rely on current algorithms.

That sounds way over-engineered: Custom protocol-aware BPFs... why???

Why not just use the TCP "push" flag that is added exactly once per application-level message on sender side; and on receiver side, buffer in-kernel until "push" is encountered?

s/peek/peak/

That is by far the best summary of selinux's history to date.

Blanket policy of /48 per end user comes from a (now obsolete) RFC3177. All RIRs now have less generous recommendations - both RIPE [0] and ARIN [1] seem to operate in /56 granularity nowadays, which is a very sensible step forward of course.

[0] https://www.ripe.net/publications/docs/ripe-650

[1] https://www.arin.net/policy/nrpm.html#six7

That's a fine advice for tinnitus prevention, but sadly does exactly nothing applied as remedy.

The statement about IPv6 [internet] having 2^128 addresses is completely and utterly untrue, in the same way as it would be untrue to claim that IPv4 [internet] have 2^48 TCP ports.

What IPv6 have address-space-wise, is 2^64 subnets, out of which 2^61 is actually allocated to be routable over public internet.

Then comes granularity of /48 allocations (= 2^16 subnets) to end users and /32 allocations (= 2^32 subnets) to ISPs. That gives just 2^45 end users and 2^29 ISPs at best. In practice, if handing a user a /48 would become a common practice, all medium and large IPSs would start accumulating multiple /32s, then routing concerns would come back, and largest ISPs will start aggregating to /28s or /24s or whatnot.

That is still a whole lot of addresses (and IPv4 still looks laughably small in comparison), but actual, practical numbers are way, way lower then "340 undecillion" marketing figure being plastered all over the place.

Collision probability is indeed low if you'll assume perfectly generated prefixes, and even in an unlikely case of /48 collision, those themselves would be pretty sparse, so again assuming perfectly random distribution, chance of collision of say fifty /64s on one side with the same amount from the other network is still pretty low.

But bigger point here is that often you will need external connectivity for those ULAs, similar to what everybody used to do in IPv4 world (i.e. NAPT, a.k.a. "nat overload" a.k.a. "IP masquerade"), and that is not something that is available, really. Instead, IPv6 offers prefix translation (a.k.a NPTv6, see RFC6296). So effectively that means that:

- for each LAN segment (i.e. /64) you have to have a "private /64" and a "public /64" (or same at coarser granularity up to /49 or even more). Twice the number of networks to configure and keep track of;

- "NAT as a security measure" argument flies out of the window, as NPTv6 is stateless.

In other words, you get all the hassle of IPv4 NAPT with none of its (meagre) benefits.

You can make a non-routable subnet if you need one by configuring a firewall/access list. Pretty much any router can do that. Plus you get way better granularity in controlling access - office-local subnet, DC-local, branch-local, country-local, whatever-local access - unlike venerable RFC1918.

But never use non-globally-unique addresses as other commentators suggest with wonky probabilistic allocations. There is absolutely zero benefits for that, and it will inevitably end up to be a huge PITA down the line. IPv6 used to have 6-to-6 NAT and site-local addresses, but sanity won, and both were dropped from the current slew of RFCs.