aexaey

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)

  > apt-get update/upgrade every week

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

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

  1.2 -> 1.0.0.2
  1.2.3 -> 1.2.0.3

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';

...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.

Yes. "100 Continue". [1]

If client intends to send a POST request with request body large enough to try to avoid wasting bandwidth (in case server might reply with 3xx,4xx or 5xx), the client will send only headers including "Expect: 100-continue" header, then server indenting to reply with "200 OK", will instead first reply with "100 Continue" than client will send POST body, and finally server sends "200 OK".

[1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8....

iw is not quite a complete replacement for iwconfig and iwlist. Former don't support some network card drivers, such as [1]. So if you happen to have one of those, you have to use latter two, deprecated or not.

[1] https://github.com/lwfinger/rtl8188eu/

  Channel 14 is only used in Japan

https://en.wikipedia.org/wiki/List_of_WLAN_channels#ref_C

You are right, except:

- "Peer-to-peer" (Ring, Bleep/BittorentChat) and

- "Federated" (Email, Matrix, XMPP/Jabber)

...would be a better way to convey that distinction.

I used term "options" here the way it was defined in RFC 791. [1] It's a standard way to extend IPv4 packet header.

[1] https://tools.ietf.org/html/rfc791

Let me drill down it for you:

Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something?

Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something?

See the difference?

> Largely backwards compatible

how exactly in the case of IP?

For example, introduce two special IP options that would act as "page selector" for source and destination addresses respectively. i.e.

  SRC: 1.1.1.1, DST: 2.2.2.2, no options ->
      from 1.1.1.1 to 2.2.2.2
      (backwards-compatible packet, classic IPv4)

  SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 1.1.1, opt.Y: 2.2.2 ->
      from 1.1.1.1.1.1.1 to 2.2.2.2.2.2.2
      (our faux-IPv6)

  SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 0.0.0, opt.Y: 2.2.2 ->
      from 1.1.1.1 to 2.2.2.2.2.2.2
      ("old" address communicating with "new" address)

Say, for ease of processing on router, require that X and Y would appear only together, in that order, preceding other options (which is a bit of an exception as far as IP options go, but again, a backward-compatible one).

Now, I'm not proposing this seriously of course, but you asked for example - here you go, a plausible, backwards-compatible "IPv4.1", if you like.

[1] All major desktop OS support IPv6 for last 10 years and major mobile OS for last 7. Let's face it - software upgrade turned out (surprisingly) not to be the biggest obstacle.

UTF8 is backward compatible with ASCII just fine - latter is a strict subset of former. It doesn't get more backward-compatible than that!

IPv6, on the other hand, is not at all backward compatible with IPv4 (was never a design goal - magic of OSI stack was supposed to do it's thing). One would argue that incompatibility is in large part responsible for the 6's slow start - even though afterthought bolt-ons eventually did see sunlight - ::ffff:x.x.x.x thing, cornucopia of tunnels and dual-stacks of various degree lite-ness, etc.

Technically, WiFi beam-forming, which is part of the standard since 802.11n and is really taking off with high-end 802.11ac routers, is a phased array to all intents and purposes.

The future is here.

A flow is defined as a unidirectional sequence of packets with some common properties that pass through a network device. [...] for example, flow records include details such as IP addresses, packet and byte counts, timestamps, Type of Service (ToS), application ports, input and output interfaces, etc.

From here: https://tools.ietf.org/html/rfc3954