aexaey

/bin/false is commonly specified instead of a shell in /etc/passwd for accounts that are not supposed to have interactive logins.

There is also an sstrip tool [1], written by the same Brian Raiter already mentioned here. It strips a bit more eagerly:

  $ gcc tiny.c -O3 -o tiny; wc -c tiny
  8456 tiny

  $ strip tiny; wc -c tiny
  6224 tiny

  $ sstrip tiny; wc -c tiny
  4140 tiny

[1] http://www.muppetlabs.com/~breadbox/software/elfkickers.html

Also, you don't actually need a "true" binary for a shell of any reasonable vintage:

  # which true
  /usr/bin/which: no true in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin)

  # true; echo $?
  0

1GB is pretty close to the average it seems:

65,110,000 [1] * 90% [2] * 18.2% [3] = 10665018 subscribers

10PB / 10665018 = 937MB per subscriber per month.

[1] Total population of the UK, https://en.wikipedia.org/wiki/United_kingdom

[2] Guestimate for market penetration figure

[3] Vodafone's market share: https://www.statista.com/statistics/375986/market-share-held...

> Intel platforms also had an ARC processor

That is true for older designs. But didn't Intel switch from ARC to SPARC for their ME core not that long ago? Discussed here a while back:

https://news.ycombinator.com/item?id=8813029

Most Chromebooks have embedded controller running on ARM specifically.

https://www.chromium.org/chromium-os/ec-development

Also:

  nft add rule nat ip saddr {10.0.0.0/8, 192.168.0.0/16} tcp dport {http, https} dnat 1.2.3.4

vs.

  iptables -t nat -A PREROUTING -m tcp -p tcp -s 10.0.0.0/8 --match multiport --dports 80,443 -j DNAT --to 1.2.3.4
  iptables -t nat -A PREROUTING -m tcp -p tcp -s 192.168.0.0/16 --match multiport --dports 80,443 -j DNAT --to 1.2.3.4

> Otherwise, the future is bleak for your smart toaster

Well, no. Smart toaster is going to be just fine. And that's the core of the problem here. Much like it is the case with polluting diesel cars, owners are reasonable happy with their purchase and simply unaware of any problem (until/unless product is recalled). And even being aware, there is very little incentive for owners to address the issue of their property subtly contributing to harming somebody else.

And same again with much-needed BCP-38. It adds very, very little value to the ISP who implements it, so many never bother to. Yet less-then-universal roll-out of BCP-38 hurts Internet as a whole.

Care to elaborate how/why exactly CDN would be different here?

> Ycombinator.com, why do you have a TTL of 12 seconds?

You either meant to say 60 seconds, or forgot to factor your local caching DNS resolver in. Here:

  $ dig +short soa ycombinator.com
  ns-225.awsdns-28.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

  $ dig a ycombinator.com @ns-225.awsdns-28.com. | grep -A3 'ANSWER SECTION'
  ;; ANSWER SECTION:
  ycombinator.com.        60      IN      A       54.240.184.14
  ycombinator.com.        60      IN      A       54.240.184.154
  ycombinator.com.        60      IN      A       54.240.184.206

That said, 60 seconds is still ridiculously low.

From what I understood looking at the photos in the article, "relays" are some fancy-looking external box. It is quite possible that those are "pulse relays", i.e. RPi sends a short voltage pulse to switch relay on, then another short pulse over the same wire to switch off.

From there all you need is two (or more) diodes to handle multiple pulse inputs. Some pulse relays even have diodes built-in (i.e. can handle multiple inputs from the get-go).

You can easily spot this sort of installation - wall-mounted light switches only go one way, and return to original position as soon as let go. And each press changes on/off state - sort of how Caps Lock works.

WiFi handles the same problem by having CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) and MAC-level retransmissions:

http://www.labs.hpe.com/personal/Jean_Tourrilhes/Linux/Linux...

Are you suggesting that people should get paid for receiving traffic?

There are a surprising number of users for ptrace. E.g. upstart uses it to count forks (presumably to mitigate fork bombs), as geofft has pointed out above.

And for earlier kernel versions, there is an STAP patch:

  1) On the host, save the following in a file with the ".stp" extension:

  probe kernel.function("mem_write").call ? {
          $count = 0
  }
  probe syscall.ptrace {  // includes compat ptrace as well
          $request = 0xfff
  }

  2) Install the "systemtap" package and any required dependencies. Refer
  to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux
  "SystemTap Beginners Guide" document, available from docs.redhat.com,
  for information on installing the required -debuginfo packages.

  3) Run the "stap -g [filename-from-step-1].stp" command as root.

From https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13

Good point, edited to clarify.

  CVE-2016-5195

  This flaw allows an attacker with a local system account to
  modify on-disk binaries, bypassing the standard permission
  mechanisms that would prevent modification without an
  appropriate permission set. This is achieved by racing the
  madvise(MADV_DONTNEED) system call while having the page of
  the executable mmapped in memory.

Excellent example why mounting partition with system binaries (such as /usr) read-only is a good idea. CoreOS does this.

[EDIT] added "read-only"

Indeed, Dutch view this two ways to use bicycle very differently. There are even completely different verbs to describe that:

- fietsen i.e. literally "bicycling" would refer to riding an opafiets [1] bicycle, at moderate speed, without helmet or any sort of cycling attire;

- wielrennen, i.e. literally "wheel running" instead describes sort of cycling that you would see in Tour de France race - racing bike, helmet, lycra gear on, considerably faster.

Second is far less common, and doing so on busy city streets during rush hour is frowned upon, of course.

[1] https://en.wikipedia.org/wiki/Roadster_(bicycle)

Not quite. Weakness is later in the chain.

Secure second-stage loader (BL2) loads secure third-stage loader (BL31) from insecure flash storage, then verifies it by calculating SHA-256 hash of it and comparing that to the value stored in the same insecure flash.

As far as I understood, "high fructose" in HFCS is only high relative to the corn syrup that was hydrolyzed, but not processed with isomerase, i.e. essentially compared to corn syrup with no fructose at all.

Most commonly used HFCS varieties contains 42% or 55% fructose [1], which compares well with 50% in sucrose.

[1] https://en.wikipedia.org/wiki/High_fructose_corn_syrup#Compo...

Why can't I? For the purpose of this argument, Windows and Mac keyboards aren't all that different. See for yourself - modern mac keyboards have two layouts:

- Full / 105-key layout, which is a copy of Windows 105-key layout with renamed and re-shuffled lower row, featuring: control, option(alt), command(win), space, command, option, control; [1]

- Compact (laptop / magic), where lower row has: fn, control, option(alt), command(win), space, command option; [2]

Other (Windows) layouts of the bottom row:

- Full/Desktop 105-key: Ctrl, Win, Alt, Space, Alt, Win, Menu, Ctrl;

- Lenovo laptop: Fn, Ctrl, Win, Alt, Space, Alt, Win[4]. Ctlr; [3]

- Dell laptop: Ctrl, Fn, Win, Alt, Space, Alt, Ctrl. [5]

...etc.

Now, this is ridiculous.

So my point is: sure, there are (ad-hoc) standards, but way too many of them, and all of them try to pack too many keys around core QWERTY field, especially lower row. Chromebook is the first one on record to prune this and offer a clean, usable layout.

[1] http://www.apple.com/shop/product/MB110LL/B/apple-keyboard-w...

[2] http://www.apple.com/shop/product/MLA22LL/A/magic-keyboard-u...

[3] http://www.lenovo.com/images/gallery/main/lenovo-convertible...

[4] On some models, PrintScreen takes place of second Win key

[5] http://kbimg.dell.com/library/KB/DELL_ORGANIZATIONAL_GROUPS/...

For me, killer feature of Chromebook is keyboard layout - standardized throughout lineup, and with all non-essential keys thrown out. Lower row with bare minimum: ctrl, alt, space, alt and ctrl - just plain excellent - clean layout, left ctrl/alt keys are of proper size, making them super-easy to hit with a pinky.

In contrast, on Windows/Mac side of things - desktop keyboard is already bad enough with bottom row cluttered with win(command) repeated twice, plus menu/right-click key (why does this thing even exist?); On laptop, it gets even worse by adding add "fn" and often pgup/pgdn and other clutter to the mix. Then there's question of order in which they all come - is it fn, then ctrl, or other way around? was that alt beside spacebar, or is that win? etc...

I wonder how much of this recent IPv4 address count stagnation OP is talking about, is in fact due to increasing prevalence of carrie-grade NAT as opposed to real IPv4 deployment slowdown.

Oops, QUIC is now supported:

https://github.com/mholt/caddy/releases/tag/v0.9.0

Sure, if you want to serve TCP reset / ICMP port-unreachable to blocked users, then yes - iptables or external firewall is a more natural way to do it.

But what if you want to serve different content to "blocked" users? i.e. login page, "we're sorry" page, redirect to read-only version of the site, reminder to connect to office VPN, anything like that...

Another example - more than one site on the same (server) IP, and only part of them are (client) IP-restricted.

- Can Caddy work as a reverse proxy to other backend services?

Yes. Use this in your Caddyfile:

  proxy /api 10.20.30.40:8080 

- And if so, can I use QUIC for the backend

No, QUIC is not supported at the moment: https://caddyserver.com/blog/implementing-http2-isnt-trivial

- and plain TCP for the front-end?

Yes, if you mean HTTP/1.x. Also, you can serve static files from the proxy itself. Everything not mentioned in explicit "proxy" directive would be served from local files in the same directory as Caddifile.

There are some features in Caddy that are simply outstanding - HTTP/2 and Let's Encrypt integration, to name a few - both pretty much work out-of-the-box with zero-configuration.

On the other hand, there are still some gaping holes - for example, to block (or allow) a 192.168.0.0/17 IPv4 subnet in Caddy, one needs to do all of below:

- Install an addon [1];

- Which used to require recompilation, with 0.9 release you can just click an option during download, yay!;

- Add 128 ranges to cover this single subnet: 192.168.0.0-255, 192.168.1.0-255, ...192.168.127.0-255. Configuration doesn't support subnets, only ranges. And only ranges in last octet, i.e. 192.168.1.0-255 (meaning 192.168.1.0/24), or implied ranges by trailing octet(s) omission, i.e. 192.168 (meaning 192.168.0.0/16) [2].

Oh, and ipv6 filtering doesn't exist at all.

[1] https://caddyserver.com/docs/ipfilter

[2] Which is mildly confusing notation too, since traditional UNIX inet_aton() call would interpret this as 192.0.0.168. Try typing "ping 192.168" on Linux.

Well done for first steps. Even (one of) mail servers' IPv6 record has a valid reverse record, very nice!

Now, how about adding reverse to the main AAAA too?

Also, what's up with one of MX'es lacking IPv6 address? With both mail.linkedin.com and mail-c.linkedin.com having the same priority (10), that's a recipe for 50% of delivery attempts randomly failing to IPv4.

  $ dig +short aaaa linkedin.com
  2620:109:c002::6cae:a0a

  $ dig +short -x 2620:109:c002::6cae:a0a
  (no reply)

  $ dig +short mx linkedin.com
  10 mail-c.linkedin.com.
  10 mail.linkedin.com.

  $ for i in mail.linkedin.com. mail-c.linkedin.com.; \
    do echo $i; dig +short aaaa $i; done
  mail.linkedin.com.
  (no reply)
  mail-c.linkedin.com.
  2620:109:c006:104::215

  $ dig +short -x 2620:109:c006:104::215
  mail-c.linkedin.com.

  Helium [...] is critical to [...] MRI scanner

Is that still the case, now that high-temperature superconductors are available, which work just fine while being cooled with much cheaper liquid nitrogen instead of requiring liquid helium?

It would absolutely not survive for very long like this (naked PCB on a key-chain). Mechanical damage from the actual keys on the same chain is what will kill it before water, sweat, washing liquid, pocket lint or ESD do.

First things to fail will be ceramic capacitors torn/cracked and leads of SSOP-20 package bent/shorted.

That said, it is trivial to protect the board from all of above - just wrap it (except USB connector) with insulating tape or better yet, cover with silicone putty, or similar.