aexaey

Whole page is an enlightening read, with quite a few disappointing discoveries, such as:

  There are several privacy, security and freedom issues
  with [Purism Librem laptops], due to the Intel chipset

> They've stayed relevant in the GPU market, though.

And in APU (or "non-mobile SoC", if you will) market too: Xbox1 _and_ PS4 - that's a huge success by any measure.

Offered example is missing this in the "you can inline" snippet:

    <head>
      <noscript>
        <link rel="stylesheet" href="small.css">
      </noscript>
    </head>

..least whole point of this excercise is to make life a little bit more miserable for those pesky users who dare to disable js.

PEP20 sound amazing, but then when this only way end up being way too verbose/ugly, you are kind of stuck with it. Compare:

    #python
    import re
    m = re.search('(a.+)(d.+)', 'abcdef')
    if m:
      print(f"{m.group(1)},{m.group(2)}")

    #perl
    if('abcdef' =~ /(a.+)(d.+)/){
      print "$1,$2";
    }

python3 is supported:

https://github.com/nineties/py-videocore/commit/7b192779e844...

Two more remarks:

1. Original article on FreeBSD mailing list is from 2010;

2. Original article claims 20% speed improvement for --mmap. This option is gone since:

http://permalink.gmane.org/gmane.comp.gnu.grep.bugs/5049

Article urges to consider Clang. Full stop.

Regarding GCC, it says in the conclusion:

> [...] stick with GCC unless you have a compelling reason to do so otherwise[1].

[1] original article's grammar.

In somewhat similar test, it took almost 11.5 million writes over 3 weeks to burn though 2401 EEPROM chip. [1]

SD card case is both simpler: no need for custom hardware, and at the same time harder: there is flash translation layer [2] between RPi and actual flash erase-blocks, so write patterns, block size, etc. do affect lifetime.

[1] http://dangerousprototypes.com/2010/05/25/prototype-flash_de...

[2] https://en.wikipedia.org/wiki/Wear_leveling

Ubuntu Snappy Core does not work on Raspberry Pi Zero, or for that matter on any ARMv6, such as most RPi models: 0,A,A+,B and B+. All of above are based on BCM2835/BCM2708 SoC.

UbuntuSC requires ARMv7 ISA CPU, which among Raspberry Pi models is only featured on the BCM2836/BCM2709 SoC in "Rasbperry Pi 2 Model B" (note the "2").

Totally agree with i3wm choice.

Regarding terminal emulator glitches - may I suggest "simple terminal" [1]? It might seem a bit brutal by requiring to recompile the whole thing every time you change config and to apply a patch to get a working scroll-back [2], but than - it compiles in under a second, and how often do you reconfigure your terminal anyway...

[1] http://st.suckless.org/

[2] http://st.suckless.org/patches/scrollback

> Good luck exchanging your fried RAID controller for a "comparable" model

If you are running Linux/*BSD/SmartOS, the best RAID controller is a JBOD controller, i.e. one that that exposes all connected disks as-is to the host OS, and than it would be in-kernel soft-RAID implementing the actual logic.

This approach gives you a more predictable system with no vendor-specific idiosyncrasies or extra cache level to worry about (BBU in OP's article); you end up running RAID code that is peer-reviewed, fully integrated into fsync() algorithm, and surprisingly, often gives you better performance too.

"True hardware RAID controllers", on the other hand, are nothing more than an application-specific computer with its own (non-upgradeable and often outdated) CPU, RAM, I/O and hard-to-upgrade proprietary software.

And if you buy into the view described above, than replacing a JBOD controller for RAID use is exactly the same thing as replacing JBOD controller for ZFS use, by definition.

(Lack of) native X11 support. I want to compile Awesome [1] and use that as my window manager.

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

    They'd probably rather have a *tip*

I couldn't agree more. Indeed, if one would typically tip in a restaurant, why not here?

That's a remarkably trivial result.

Also, Docker is apparently more efficient than LXC, despite the fact that Docker is nothing more that a bunch of UI on top of LXC - either directly or with even more intermediation (libvirt/systemd)?

Impossible. "M$" spelling is an artefact of at least 10-15 years ago. And author should have been at least 12 back then to pick this up.

Regardless, author does have a valid point here, despite somewhat puerile literary style.

That would be next version of this.

This completely ignores the "evil maid" scenario.

Sounds like that is an excellent opportunity for this person to invest some time into honing one's technical skills.

> why not just stick with Windows?

Hm... because Windows is essentially a platform for Microsoft and assorted 3rd parties (most of which are not even affiliated with them) to spy on and meddle with you beyond any reasonable control or limitations?

I've seen a (reasonably big) company that has deployed a Citrix VDI cluster exactly for this purpose - for MacOSX/Linux users to deal with both of problems you have listed, plus a third one:

* Legacy Intranet websites that only work in IE.

> why not switch to OS X or Linux

To non-Canonical Linux or FreeBSD/OpenBSD please.

OSX and Ubuntu spy and expose you too, although Windows is by far the biggest offender here.

Hold on... Economist wants both subscription fee and to serve 3rd party malware (a.k.a. ads) to me?

What's wrong in running Ubuntu/Fedora in a VM, if you really interested in trying it out?

You really shouldn't plan battery storage for winter/summer cycle. Batteries are for day/night cycle. If stretched a bit, then maybe batteries will cover "that rainy day, when I need to do laundry" and similar. But not much more, as you've seen yourself - this is prohibitively expensive.

For winter/summer cycle, if you're south of 40° N (and north of 40° S) just oversize PVs. Otherwise, you need a second power source - grid, wind or geothermal.

Not to mention that having a second source is really good if you ever plan for maintenance or emergency repairs.

Looks like times have changed in France, since Thomas Piketty had no problem working there and writing his "Capital in the Twenty-First Century" which went on to have millions of copies sold?

Actually, in public Internet traceroutes are reasonably reliable. It's corporate networks where you would expect weird stuff like that.

> (About #12, WTF? Weird!)

There is a fairly boring explanation to that. Similar to public IPv4 exhaustion, RFC1918-style private IPv4 addresses can easily be exhausted in a big private network as well. If you have noticed, MS has actually run out of RFC1918, and uses RFC6598 (a.k.a. 100.64.0.0/10) network in Azure for their "classic" segment. 100.64.0.0/10 was not supposed to be used as RFC1918-style general-purpose private IP space, but rather as a local side of a CGN pool. But then again, if you squint a bit, well... it's still private, so will never be advertised into the Internet, so it's fair game to use it if you run out of RFC1918, right?

Some people choose to squint even further, and declare anything that is not advertised into public BGP as a fair game. I've seen a big ISP "borrowing" 44.0.0.0/8 (amateur radio AX.25) subnet to deploy video segment of their huge "triple-play" network. 33/8 (US DoD) is also popular as "borrowed" private space, 1/8 was fairly popular until it actually became real public address space handed to APNIC (oops!). Now we have an example of using 25/8 like that as well.

ILPIP look promising. I'll try it, thanks!

Speed test though... hm... 22Mbit/s is not exactly unrestricted, plus not sure how long is the burst that "speedtest-cli" makes. In my experience A0's uplink is burstable (but unusably slow when recovering from a burst), with long-term average being bang-on 5Mbps.

I do of course see exactly one "my" private IP in traceroute, but I'm not talking about that. I meant there are microsoft's private IPs (#12-#15) and dropped packets (#16 and on).

And of course, "platform doesn't forward ICMPs" is an annoyance in itself - i can't even ping my own VM.

    # target IP anonymized, but still have enough granularity to reproduce the traceroute
    traceroute to xxxxx.cloudapp.net (191.235.128.128), 30 hops max, 60 byte packets
     1  192.168.1.1 (192.168.1.1)  0.093 ms  0.117 ms  0.063 ms
     2  193.47.232.12 (193.47.232.12)  0.785 ms  0.785 ms  0.776 ms
     3  microsoft.mix-it.net (217.29.66.112)  1.219 ms  1.233 ms  1.225 ms
     4  xe-0-1-1-0.fra-96cbe-1a.ntwk.msn.net (207.46.42.12)  8.700 ms  8.902 ms  8.430 ms
     5  * * *
     6  * * *
     7  104.44.9.142 (104.44.9.142)  42.112 ms  39.194 ms  38.987 ms
     8  * * *
     9  be-6-0.ibr01.dub30.network.microsoft.com (104.44.4.142)  39.738 ms  38.266 ms  38.929 ms
    10  * * *
    11  ae2-0.db3-96c-3b.ntwk.msn.net (204.152.141.81)  36.986 ms  36.984 ms  36.925 ms
    12  25.149.64.247 (25.149.64.247)  36.951 ms  36.775 ms  37.152 ms
    13  10.10.132.81 (10.10.132.81)  36.917 ms  37.477 ms  37.287 ms
    14  10.60.31.77 (10.60.31.77)  37.317 ms  37.699 ms  37.899 ms
    15  10.60.31.69 (10.60.31.69)  37.653 ms  37.326 ms  37.441 ms
    16  * * *
    17  * * *
    18  * * *
    19  * * *
    20  * * *
    21  * * *
    22  * * *
    23  * * *
    24  * * *
    25  * * *
    26  * * *
    27  * * *
    28  * * *
    29  * * *
    30  * * *

P.S. #12 - lol!

Yes, you are absolutely right that IPv4 addresses are scarce.

Which bring a related question - what's up with none of AWS/Azure/GCE supporting IPv6?

> I thought it was 10Mb/s?

Alas... Also, in my experience, throttling is really slow to react, i.e. you get a chunk of data out at 10-20Mb/s, then everything freezes for few seconds until average would drop below 5Mbps, then another speed-up/slow-down cycle. Long-term average is exactly 5Mbps as per their spec-sheet [1].

[1] http://download.microsoft.com/download/4/1/1/411621F0-D0BF-4...

[2] https://www.oaklight.us/2014/06/azure-network-speed-quick-te...

Wouldn't work for me, as the {Get,Add}-Azure* scripts are windows/powershell-only. But then again, existence of CLI tools means there's an API. So, with a bit of luck, we might one day see a portable CLI tool (maybe boto3 [1] ported to azure API... one can dream! :-)

Thanks for pointing those out!

[1] https://github.com/boto/boto3

I'm getting approximately the same CPU & storage performance out of Azure's A0 machine w/Debian8, as from AWS t2.micro instance with spinning rust storage and Debian8 (both are cheapest offer available, and price is quite similar between them).

Network on Azure though is a totally wrecked thing:

- A0 instance is capped to a miserable 5 megabit/s uplink (downlink is fine);

- If you want TCP/UDP ports open, you need to open them one-by-one, going through a 2-page wizard with 8 fields in total to fill in for each port you are opening, and then waiting 15-20 seconds for each "change" to be applied. Good luck opening a 1024-port range for your SIP server;

- You can't open ICMP/GRE/IPSEC or any other custom protocol;

- There are ton of really weirdly configured network gear between your VM and the Internet - packet drops and private IPs in traceroute, etc...

- On a plus side, you can enable so called "direct server return" and you will get incoming packets with your public IP as a destination IP; a really nice feature sorely missing on AWS.