bratch

It looks like only IPv4 is affected. IPv6 is working fine to a couple of test endpoints.

   3  2a02:c28:1:6506::106  2.131 ms  2.124 ms  2.117 ms
   4  2a02:c28:11:6::100  15.695 ms  15.689 ms  15.682 ms
   5  2a02:c28:1:1900::19  15.998 ms  15.991 ms  15.985 ms
   6  2a02:c28:0:1819::18  15.259 ms  15.051 ms  16.975 ms
   7  2a02:c28:0:1718::17  16.968 ms  16.403 ms  15.619 ms
   8  2a02:c28:0:1731::31  15.406 ms  18.620 ms  18.554 ms
   9  2001:7f8:4::3f94:2  12.025 ms * *
  10  * * *
  11  2001:41d0:aaaa:100::5  21.622 ms  38.813 ms 2001:41d0:aaaa:100::3  37.231 ms
  12  * * *
  13  * 2001:41d0::25f1  19.507 ms 2001:41d0::c68  20.892 ms
  14  2001:41d0::513  19.685 ms  19.674 ms 2001:41d0::50d  18.248 ms
  15  2001:41d0:0:50::5:10a1  19.092 ms  19.917 ms 2001:41d0:0:50::5:10a5  20.126 ms
  16  2001:41d0:0:50::1:143f  19.375 ms 2001:41d0:0:50::1:143b  24.609 ms 2001:41d0:0:50::1:143d  18.933 ms

All day every day since 2009 :)

I've kept an eye on other phones throughout the years, but nothing quite ticks the same boxes (and by far most things aren't even remotely close).

There are some other interesting phones on the horizon (Librem, PinePhone), but then again things like Maemo Leste are ready to breathe new life into the N900, so I might be using it for very long time yet!

This was my first thought too. I have done this successfully to get Cat5e everywhere in a house that used to have coax everywhere. If you do it, I recommend attaching multiple pull strings to the coax, then pulling the coax out, then using one of the new pull strings for the Cat5e - otherwise you risk the Cat5e and the coax becoming detached from one another in the wall.

I'm surprised to hear of problems with Firefox and ALSA. On all my Gentoo machines I simple compile Firefox with USE="-pulseaudio" which sets --enable-alsa within Firefox's build. Still working fine up to and including Firefox 66 directly to ALSA.

To name some big ones: Alpine, Gentoo, Slackware.

I was delighted that a fun toy didn't need JS for once. If the concern is one of privacy, the author could just be sending the text to the server in the background with JS too.

The package contains microcode for old CPUs but it isn't necessarily still updated or recent.

Here for example is what's available for my router's CPU, from the latest package:

  # grep model\ name /proc/cpuinfo
  model name      : Intel(R) Core(TM)2 Duo CPU     E4500  @ 2.20GHz

  # iucode_tool -S -l /lib/firmware/intel-ucode/* | tail -n1
  iucode_tool: system has processor(s) with signature 0x000006fd
    030/003: sig 0x000006fd, pf_mask 0x01, 2010-10-02, rev 0x00a4, size 4096

Last updated almost eight years ago, so doesn't contain any Spectre/Meltdown fixes.

It is useful in the case that you want a predictable and expected delay immediately, rather than unpredictable delays for an unknown length of time to come.

`cal` does try to use the expected first day of the week based on the locale. It seems to at least use LC_TIME from some quick local testing:

  bratch@serenity ~ $ LC_TIME=en_GB cal | head -n2
        May 2017      
  Mo Tu We Th Fr Sa Su
  
  bratch@serenity ~ $ LC_TIME=en_US cal | head -n2
        May 2017      
  Su Mo Tu We Th Fr Sa

I find the opposite - without JS permitted for at least a couple of domains, one only sees the mobile site and extremely low resolution images.

Edit: And even with JS, images remain low resolution (or invisible) until you stop middle-button scrolling which makes for scanning through articles very painful.