aexaey's comments

How does function sound for a syntactic sugar?

  $ today() { date +%F; }
  $ echo Today, $(today) is a great day!
  Today, 2019-01-08 is a great day!

Since nobody mentioned Zulip's REST API yet, I'll do. There is one, and and it is really good.

There are also native language-specific wrappers for that API, for example in python[1], which lets you write a bot in 5 lines:

  import zulip
  client = zulip.Client()
  def onmsg(m):
     print ("at %d, %s said: %s" %
          (m['timestamp'],
           m['sender_email'],
           m['content']))
  client.call_on_each_message(callback=onmsg)

[1] https://pypi.org/project/zulip/

  > apt-get update/upgrade every week

Have a look at: https://wiki.debian.org/UnattendedUpgrades

Yes, you're right.

What I was trying to say is - On Linux, INADDR_ANY (0.0.0.0) supplied to connect() or sendto() calls is treated as a synonym for INADDR_LOOPBACK (127.0.0.1) address.

Not so for bind() or course.

0, which is a shorthand for 0.0.0.0 is likely the most code-golf-y way to write localhost, as many [EDIT: Linux] systems alias 0.0.0.0 to 127.0.0.1:

  $ ping 0
  PING 0 (127.0.0.1) 56(84) bytes of data.
  64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms

Of course, don't expect this to work universally. A lot of software will try to be clever with input validation, and fail.

Tangentially related: https://fosdem.org/2018/schedule/event/email_address_quiz/

  1.2 -> 1.0.0.2
  1.2.3 -> 1.2.0.3

But then, much of software would fail here - Firefox/Chrome for example would both threat that as bareword and redirect to search page.

SD cards and eMMC chips[0] do have controller inside. Usually not a great one (tens to hundred-ish MB/s), but that's good enough - overwhelming majority of smartphones/tablets use eMMC for internal storage.

UFS/eUFS cards keep (sort of) same form-factor [1] but bring significant speed boost. [2]

[0] Technically, it is incorrect to say "eMMC chip", as there are typically two (or more) silicon chips inside the same plastic BGA package. One of them is controller.

[1] https://www.dpreview.com/news/6387181333/samsung-launches-fi...

[2] https://en.wikipedia.org/wiki/Universal_Flash_Storage#Versio...

There are ready-made boards for this being sold for less than $2. Just search "eMMC Adapter 153 without flash" on ebay.

153 is number of balls on the eMMC chip OP is using. You might need a different adapter for different eMMC chip.

Percent, rather than asterisk.

  UPDATE t SET foo='bar' WHERE baz LIKE '$INPUT';

This will do no changes when $INPUT is empty, and only with $INPUT set to '%' will it update every record.

...and, if especially unlucky, that would be the trunk you're using to connect to that switch.

One example where XIP would be really useful is MT7688KN [1], which is a variant of MT7688 WiFi router SoC, already well supported by Linux/OpenWRT, plus 8MB of RAM on the same package.

Since no external RAM is required this makes for some very compact WiFi repeaters [2,3]. But all of them ship with VxWorks. I've tried to tinker with OpenWrt on this chip, but with 2-3MB free RAM after kernel boots (and that's before wifi modules are loaded), it doesn't look too good. With XIP, on the other hand, MT7688KN can potentially become a useful OpenWRT platform.

[1] https://www.mediatek.com/products/smartHome/mt7688k

[2] https://fccid.io/2AK8V-WF8300

[3] Xaiomi Mi Wifi+

Heavily compressed and carefully pruned, it is still possible to squeeze modern (4.9) kernel into under 1.44MiB, and kernel+rootfs into 3-ish MiB:

http://downloads.lede-project.org/releases/17.01.4/targets/i...

LineageOS (ex-CyanogenMod)'s flavour of Android 7 works just fine [1] on Nexus 5.

On the other hand - yes, hammerhead is stuck on Linux kernel 3.4, which is no longer maintained, and current best effort to forward-port to mainline kernel [2] is far from complete.

Among other things this means that there is no workaround for Meltdown on this hardware, which it is likely vulnerable to. [3]

[1] https://download.lineageos.org/hammerhead

[2] https://wiki.postmarketos.org/wiki/Google_Nexus_5_(lg-hammer...

[3] "11 stage integer pipeline with 3-way decode and 4-way out-of-order speculative issue superscalar execution" - from https://en.wikipedia.org/wiki/Krait_(CPU)

Warp is pretty good, but it doesn't support websockets.

For what it worth, Dutch has "ij", which could be a letter, or diphthong, or two unrelated letters (in words borrowed from French, for example), and could also be written as "ij", or as "ÿ", or even "y".

There is no dedicated key on computer keyboard for it, but you are supposed to remember it's a unit when capitalizing, for example IJmuiden.

https://en.wikipedia.org/wiki/IJ_(digraph)

fail2ban [1] would take care of this by automatically firewalling off IPs that fail to authenticate too frequently.

[1] https://www.fail2ban.org/

I think GP meant "metallicity" as a property of stellar objects:

https://en.wikipedia.org/wiki/Metallicity

You can skip sshuttle's magic and do exactly the same thing manually with "ssh -D" + "iptables -j REDIRECT" + redsocks, but that's a lot moving parts.

Well-known unpredictable TCP-over-TCP performance would only explain OpenVPN/TCP results.

But OP has posed also OpenVPN/UDP performance that is 2x...3x slower than SSH port forwarding, so I'd guess there is more to this story (see also andmarios's impromtu test results above).

> ESP8266 is fine with 5V

Yes and no. ESP8266 would typically survive 5V applied on any pin, and sometimes even sort-of work with 5V power applied (although with much higher power consumption and no WiFI).

But there is a catch. Pretty much all CMOS chips (ESP8266 inclided) have body diodes from each IO pin to power/ground. This means - you can't have voltage higher than VCC+0.6v or lower than GND-0.6v on any pin. So what happens when you have ESP8266 powered from 3.3v and connected to 5V I/O is - ESP will get (partially) powered via I/O pin. Depending on what 5V part is connected to that I/O, that might be bad for that part (excess of I/O sink current). And in extreme cases (5V I/O pin that can deliver high current, or ESP is in deep sleep), this will supply current into 3.3V VCC rail, bringing it up as high as 5 - 0.6 = 4.4v potentially. Which could be bad for anything else on that rail.

As a practical example - let's say we have ESP8266 powered by a switching supply with MP2307DN [1] chip delivering 3.3v, and connected to a 5v AVR. In normal operation, ESP takes ~70mA, which exceeds 40mA driving capability of AVR, so it's all good [2]. However once ESP8266 goes to deep sleep, all 40mA from AVR's I/O go via ESP's body diode back to MP2307DN switch, which usually would fail catastrophically and end up shorting input to output, supplying 12 (or whatever the input is) volts to ESP's VCC. Which is likely to fail as well, sending 12v further and frying the whole thing.

[1] MP2307DN is widely and cheaply available on "Mini360 DC-DC buck convertor" boards and it really doesn't like current being back-fed into its output

[2] Except I/O drive transistor in AVR is overloaded, which might or might not lead to its failure eventually.