crazyscot

I'm pleased to announce the first release of qcp.

The QUIC Copier (qcp) is an experimental high-performance remote file copy utility for long-distance internet connections with the following features:

• 🔧 Drop-in replacement for scp
• 🛡️ Similar security to scp, using existing, well-known mechanisms
• 🚀 Better throughput on congested networks

qcp exists because I needed to copy multiple large (3+ GB) files from a server in Europe to my home in New Zealand.

I’ve got nothing against ssh or scp. They’re brilliant. I’ve been using them since the 1990s. However they run on top of TCP, which does not perform very well when the network is congested. With a fast fibre internet connection, a long round-trip time and noticeable packet loss, I was right in the sour spot. TCP did its thing and slowed down, but when the congestion cleared it was very slow to get back up to speed.

If you're interested you can find qcp here:

• README
• Source repository
• Documentation
• Rust crate page

With tears in my eyes, I have shredded my LiveJournal account.

Now it's time to share the tool. ljshred@github | Just the script. You'll need Python 2.7. Command-line only. No warranty. Use at own risk. May contain nuts.

I may or may not delete my LJ now, but for the time being you can see the effect over on http://crazyscot.livejournal.com/ .

I have made the decision to leave LJ, because of their new Terms of Service.

I am upset at being coerced into agreeing to a new ToS without prior notice. I was required to click to agree in order to continue using the site, and forcibly logged out if I clicked "Not Now".

The English ToS explicitly says that it is "not a legally binding document" and that the Russian version prevails. For a non-Russian speaker this clause is unconscionable and likely unenforceable. Of course this is unlikely to ever reach a court; SUP would just ToS you if they didn't like the cut of your jib (s2.5).

Assuming the English translation is broadly correct, and taking it at face value, I am upset with the unilateral involvement of Russian domestic law in the user agreement. Some specific qualms with it follow.

• Users (s7.4) and communities (8.4) are subject to article 10.2 of Federal Act 149-ФЗ (by the way that's a Cyrillic Z, not a number 3) of the Russian Federation if they receive more than 3000 accesses within 24 hours. I found an English text of Act 149-FZ. Article 10.2 is several pages long but includes provisions (inter alia) requiring registration of all such blogs and bloggers with an implicitly Russian government body, and bloggers must verify all information that they post. While doubt I'm anywhere near the 3000 viewers threshold, I object to the idea of being non-consensually registered with an overseas government body, without the privacy protections that I expect, if my activity meets their arbitrary threshold.
  
  
• Users are required (9.1.3) to use the Adult Content mechanism to indicate where content is inappropriate for children according to Russian law. I don't know what Russian law says about appropriateness for children, how the norms and mores might differ from where I live, and there's no reasonable way for me to keep up to date with them.
  
  
• Users are required (9.2.7) to not post adverts or "political solicitation" (whatever that means) without explicit agreement (permission?) from SUP. There is no guidance to what "political solicitation" means. As a moderately political person, without knowledge of the definition of solicitation, I am concerned that the occasional political post I make might inadvertently fall foul of this provision.
  
  
• Users are required (9.2.8) to not perform any actions contrary to the laws of the Russian Federation. Given Russia's stance towards the LGBTQ+ community, this is unconscionable for me.
  
  
• SUP claim the right (10.6) to change any level of service without prior notice. Such a unilateral right of change is grossly unbalanced and unreasonable.
  
  
• Any unresolved disputes between users and SUP are to be settled in (implicitly) Russian courts (13.3). To be fair I don't think this is a new term when it comes to online services in general, but this massively disempowers users outside of Russia, and that's before one considers the merits of engaging with an unfamiliar legal system.
  
  
• The entire TOS explicitly doesn't apply to paid accounts (13.4), referring them on to Live Journal Inc. As a permanent account holder, which the site treats as a paid account, I was coerced into agreeing to the new TOS - which explicitly don't apply to me - in order to continue using the site. This clearly hasn't been thought through, but is what I've come to expect from SUP in terms of how they treat their users.

On top of all that, considering that the LJ servers are now physically hosted in Russia (since December 2016), it's a pretty safe bet that all traffic into and out of LJ is available to the Russian security services in real-time, and who knows what they might be doing with it.

So this is my final crosspost from Dreamwidth. Unless there are significant changes to the ToS within the next week or so, I will be deleting my LJ account. I cannot and will not continue to use it.

Will the last person out please turn off the lights?

Every now and then I find myself needing to remember the gcc rune (above) to list the built-in pre-processor symbols. Google knows it, of course, but I just came across a scrap of paper with the scrawling. How very 1990s. So rather than keeping it buried amidst the silt of my physical desk, I'm going to try keeping it buried amid the silt of my virtual consciousness to see if that's a more useful place for it.

I stopped posting publicly, largely because of privacy concerns.

There doesn't seem to be any point in retrospectively hiding my back posts because the internet already has them archived.

Previously...

I played around with MTUs, which might have helped a little but there aren't many data points.

My current suspicion is that my own slightly wacky network setup may have been to blame.

• I had been running two different IP nets on the same physical net.
  
• Clients were allocated an address by DHCP (running on my server), server was DNS and gateway (amongst other things) to the second logical net. (My server has but a single ethernet interface.)
  
• Only my server and the DSL modem were on the second logical net.
  
• The DSL modem was itself running NAT.

So my desktop was behind double-NAT, which the internets (and my colleague Thomas) pointed out were likely to break many things. Having moved the DSL modem to be on the same part of RFC1918-space as the rest of the wired net, I have started using the DSL modem as a direct gateway for desktop clients - and it all works much better. I don't think I've had a single blackhole event since making the change a couple of days ago.

The only downside that I can see is that I no longer have the fine-grained firewall control that I enjoyed with iptables. Right?

rustica insists I propagate this link, so: Netflix win at customer service. http://imgur.com/gallery/e0LcT6J
Almost makes me want to subscribe, but we can't get it here...

OK, internets, help me out here, my google-fu is deserting me and possibly because I'm using the wrong terminology...

I have some regular weirdness with networking on my desktop PC at home. I regularly lose the ability to route packets to certain destinations. It tends to be the same destinations. For a long time it was feedproxy; now it's that and facebook. The interface remains up, and I can reach those destinations from the Linux PC that is the immediate router; just that those failing destinations seem to be blackholed on my desktop.

So it's obviously (?) entirely my machine at fault.

If I bounce the interface, it all works again. For a while, but it usually blackholes again soon.

It may be relevant that I am running the dreaded double NAT; once on my router/fileserver PC, and again on the DSL modem. I did briefly try to make the DSL modem not do NAT, but couldn't readily make it work. I suppose I ought to try again; and I could also try putting my PC outside the inner NAT to see if that makes a difference (though it wouldn't then be able to see the fileserver unless I reconfigured that *sigh*).

My googling did take me as far as a possible kernel bug to do with ARP caching and ICMP redirects and suggested echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_redirects - but it hasn't helped. ip route list cache shows affected destinations as redirected, but I'm not entirely sure what that means or how I might prevent it.

31.13.75.17 via 192.168.1.1 dev eth0  src 172.20.45.26 
    cache   ipid 0xc125 rtt 206ms rttvar 67ms cwnd 10
31.13.75.17 from 172.20.45.26 via 192.168.1.1 dev eth0 
    cache   ipid 0xc125 rtt 206ms rttvar 67ms cwnd 10

172.20.45.26 is my desktop. 192.168.1.1 is the DSL router.

Any ideas?

Here in NZ, if you want to build a building, you need (amongst other things) Building Consent. It's pretty similar to the system of building regulations and building control surveyors in the UK - just that we have a more stringent Building Code owing to the, ah, more lively nature of the ground here. Like in the UK, they are administered at a local government level. The consent-issuing bodies are audited and accredited by International Auditing NZ, which provides a compliance and conformance oversight.

Here in Chch, there has been a storm brewing since a few weeks ago, when it emerged that the city council here were at risk of having their accreditation to issue building consents revoked. ( Local politics )

I am quite a heavy Google Maps user. I got an invite to try the new Google Maps.

I found it completely unusable, at least on my home machine; the CPU pegged out at 100% constantly and whenever I moved, it took many seconds for the screen to update. Even typing into the feedback form took many seconds to show my keystrokes. Thankfully the email welcoming me to the preview program had a return-to-classic link that worked, taking me to a more useful (ordinary-web-based) feedback survey.

Possibly it's because I'm a Luddite with a five-year-old machine with an elderly graphics card, running Linux where the driver support is often lacking. But I am not really minded to spend $$$ upgrading when my current machine works perfectly adequately for my existing needs, TYVM.