Recently posted comments

And this is cheap, compared to $50 fees just a year and a half ago.

Keep in mind, that each transaction on the blockchain has to be kept there _forever_, replicated to all the nodes that host the full chain. This is quite expensive and wasteful in itself.

When you make public comments you open yourself up to public responses.

That's a fascinating hypothesis. I'd be interested to see what evidence there is to support it.

That is, SCE still wants support in the "transport layer" - such as TCP - to effectively echo back the SCE markings to the sender. Just like TCP with "classic ECN" (RFC 3168), or DCTCP. Otherwise, how would the sender of the packet notice that it needed to slow down?

I don't know why SCE was posted as an IETF draft without referencing "Accurate ECN". "Accurate ECN" aka AccECN, is an experimental TCP draft, which it says is required to implement L4S for TCP. It has been worked on since 2016. "Accurate ECN" was discussed on the bufferbloat.net lists during that time.

I think the AccECN TCP option is generic enough that SCE *could* use it unchanged. Although there is some limitation. The AccECN TCP option is optional and some middleboxes strip it (or block it? something like that anyway). AccECN has a fallback, which I think is only able to echo the ECN CE codepoint. L4S will still be able to work in the fallback mode. SCE congestion signals (ECN ECT(1) codepoint) would not get though in the fallback mode.

"Accurate ECN" also says it can be used to implement the "classic ECN" response to congestion. (I.e. 1 signal per RTT, which the sender treats as a if a packet was dropped, i.e. halves its transmission rate. If I understand correctly). I don't think it explains exactly how this is possible, but it is in good faith and I guess it is as simple as it sounds.

SCE does suggest that instead of echoing the SCE signal to the sender, it is also possible to handle it "entirely by the receiver". The submitted draft-00 suggests the reciever could tweak the receive window. OTOH, when this was politely challenged, Dave Taht said "I kind of wish we'd cut that from the draft".

https://lists.bufferbloat.net/pipermail/bloat/2019-March/...

I think it's premature to decide that SCE "better matches the values" of the Linux networking stack, however. As I understand it, in L4S, the dual-q mechanism is a transition mechanism, and the end state is that everyone - except for old stacks - end up in the second, low-latency, bucket. Whereupon the behaviour of the system is controlled by the end-hosts - very much how the Linux networking community would have it. Linux - if, and it's a big if, the patent issue is solved - would move to the second bucket very fast, give how quickly Linux development goes.

SCE, however, appears to rely on per-flow queueing (FQ) being implemented at any hop that could end up being the bottleneck. FQ is fine if its on your home router and thus under your control. But if it's implemented everywhere, then the network, not the end clients, are controlling the behaviour of the system.

The bufferbloat guys are pushing for FQ to be implemented everywhere. So far, it's not happened because the fast path of ISP-class switches are mostly implemented in ASICs, where queues are a limited resource. If it were to happen, you can be sure that the facility to weight those queues according the the commercial policy of the ISPs would also be implemented also. Despite FQ coming from the grass-roots, the difficulty implementing it at the ISP level may well be, paradoxically, something the open community should be grateful for.

https://mailarchive.ietf.org/arch/msg/tsvwg/Okd59BLGs8ZIg... -- Dave Taht

I'm not sure how to parse it. It says the 2016 "Coupled AQM" release was patent-infested and hence unsafe to review, let alone implement in Linux. But that the "DUALPI2 AQM upstream version" (released 2019?) was "possibly worth reviewing by experts".

However the DUALPI2 commit message links directly to draft-ietf-tsvwg-aqm-dualq-coupled . And the description seems to match the discussion about the patent.

I can understand anger about it being really hard to develop and test interoperability, if understanding the patented details endangers your ability to contribute to implementations of GPL'd AQMs. (Aggravated damages due to "wilful infringement?"). Although that's not how I understood things based on previous LWN articles. The patents are out there and you're going to be stuck fighting them anyway; you need to know the details in order to avoid infringing. That can be a very useful strategy, and then when you implement an alternative *that they had not already considered*, they can't then patent that alternative. (Details apply, e.g. see "patent pending").

-- Patent details! Maybe don't read further if you're not allowed to read short quotes about patent details? --

"[the base probability for the classic queue] is squared to compensate the squareroot rate equation of Reno/Cubic" sounds exactly like -

"The only claim that I could not find prior art for (in the original
EU filing) was a very specific claim about using a square root for the
coupling. The Linux implementation runs this the other way round so that
it only has to do a squaring. So I figured we were safe from that.

However, until just now, I had not noticed that Al-Lu has
retrospectively re-written the claims in the US patent and in the EU
patent application to claim this the other way round - as a squaring."

I know pennies add up, but that really is peanuts compared to all the other costs!

Cheers,
Wol

There is a claim elsewhere in the discussion that an L4S-compliant AQM can be implemented by fq_codel. This would use a different mechanism. It would also allow using L4S, without losing the benefits of fq-codel if you are not using L4S.

https://lists.bufferbloat.net/pipermail/bloat/2019-March/... -- Bob Briscoe

There is some confusion about whether the current L4S has been worded incorrectly, so that it technically prohibits an AQM based on fq_codel, and whether it would actually work fine. If you need more clarity on that *then ask about it*.

https://mailarchive.ietf.org/arch/msg/tsvwg/LBZ24KXwK13DH... -- Greg White

Yes, it would be really nice to *also* rule-in Linux routers to be able to run an L4S AQM in regimes where AQM is still possible in pure software, but flow-queuing is not.

But I don't think that deserves knee-jerking as hard as this article does.

And that's a narrower window of regimes than you might assume. I think the Bufferbloat.NET Official Position (TM) was that the main performance problem for slow home routers is often "shaping", which is not part of fq_codel. So sch_fq_codel can work in many places where sch_codel or sch_pie do. I can't find a reference about upper limits for fq_codel (as opposed to shaping), but I expect the bloat mailing list would be able to find some statements if you need them.

TL;DR for the patent to really be a problem for you, I think you would need to be running something like sch_codel or sch_pie at the moment, and not be able to switch to sch_fq_codel. Is there really anyone doing that?

I Am Not A Lawyer. None Of This Is Legal Advice. But Seriously, Did You Find Any Source Involved In the Linux Side (Dave Taht et al) Who Is As Unhappy About The *Patent* As This Article Reads?

I only skimmed the threads to find a few messages to read, based on author name. At the moment I see the most unhappiness coming from the LWN article. This is mostly re-inforcing my opinion about the amount of salt I need to take with that source :-P. (But I thank them for being good about providing links to the relevant posts.)

It's only a failure if you don't learn from it.

I don't think it's a generation gap, Jim, but a cultural gap that crosses generations.

If you don't have real swap, this doesn't help you, but it might be a useful answer to people who complain about a waste of kernel memory, or who emphasize that it is non-swapable memory (the article mentions both).

I think my version is a little more violent 🤔

Also note that on Android, we don't use disk-based swap. We have a memory based compressed swap called ZRAM, but the archive is already compressed so the suggested idea would provide no benefit (to us).

One thing I have thought of doing in the future is to make the /proc entry of the archive writeable and write an empty string into it thus freeing the archive's allocated memory and requiring a reboot. However at the moment, I am considering only building this as a module for production Android, and as a built-in when debugging. After the patches can make it, and if others want to free that memory, we can cross that bridge there IMO - such as by writing an empty string into the proc entry.

But there's still a bunch of people who don't see the point and think it's just fine to use 10.x.x.x addresses in the data center and only rely on proxies. Forever. But those people would be a problem in any IPv4 backwards compatibility scheme for any new addressing. They'd never see the point in upgrading past the compatibility solution.

Ok....

/me backs slowly away

(aiui, the NoSQL domain was registered / is owned by one of the leading lights in the Pick community. It predates the rise of NoSQL in general, and was intended to trigger exactly that.)

But to implement a Pick database, really all you need is a decent key/value datastore, and a way of handling n-dimensional data (as provided by Pick's DataBASIC language). In maths, the general always trumps the specific, and Pick's n-dimensional data store trumps relational's 2-dimensional store.

Cheers,
Wol

I pay £12/year (plus VAT) for a .com domain; if I settled for .co.uk it would only be £6/year. What kind of ridiculously lower were you thinking of?

If you're a company with programmers on tap, then most things are *possible*.

Thing is, I'm a private individual with no real kernel experience (although my C was pretty decent), so getting old binaries to work is not *practical*.

That's what I feel is often missed here - what is *possible* is not always *practical*.

I'd love a guarantee like the IBM mainframes - I believe you can run "dawn of computing" mainframe software on the latest megabeasts, because the current system can emulate the previous system, which can emulate the one before that, which can emulate the one before that ... turtles all the way down. But that COSTS MONEY, which us little guys don't have, and most people don't seem to consider important enough to do as a project, be it commercial or private.

Cheers,
Wol

Is it really realistic that any network protocol not supported by Linux be adopted at any internet significant scale?
Given the number of Linux based servers, networking devices and Android phones I would have thought not.

Last time we had a quick chat on IRC he mentioned his illness and how he was going... I didn't hear from him since then, and today I found this notice on LWN.

As others said, thank you for what you've done, and you will be missed, Peter.

This is what is happening right now - you still have legacy IPv4 infrastructure with NAT-ed clients and newer IPv6 infrastructure without NATs. They both live together side-by-side seamlessly, thanks to Happy Eyeballs RFC.

> But even if you drop the stateful NAT option, under this scheme, or a 6to4-only-IPv6 phase, clients with mere IPv4 access can talk to the full IPng internet. For servers, there's no good reason not to opt-in to IPng.
No they can not. IPv4 clients can only connect to IPv4 addresses, so the server will have to use IPv4. Peer-to-peer with IPng is still impossible.

He will be missed.

http://vger.kernel.org/lpc-bpf2018.html#session-2

Wake up people!

(1) My observation is that technology adoption is driven by how much better the new is than the old.

(2) If IPv6 were that much of an improvement over v4, then Egress-Only Ingernet Gateways[1] would make no sense.

(3) Maybe CIDR is "good enough".

[1] https://docs.aws.amazon.com/vpc/latest/userguide/egress-o...

The same thing that stops you from disabling TCP congestion control or using a congestion-oblivious UDP transport. I.e. nothing, until you become a big enough problem that ISPs start blocking your traffic.

And how on earth is the algorithm supposed to know what the url is supposed to be?

Pages re-direct and re-write urls all the time. IME AI is *useless* at knowing what I want (eg pretty much ALL Thunderbird scam warnings I see come up on legit emails that don't even have anything that looks scammy to me !!!).

I seriously would NOT trust ANY form of AI to check whether an URL "looks right".

Cheers,
Wol

This makes everything even worse, a dual stack IPv4/ng client won't know which protocol to use to connect to a V4 address.

Unless ISPs are going to filter at ingress points (and so break the end-to-end congestion management anyway), surely everyone has to agree and implement the same rules or it won't work - regardless of patents or politics.

Apparently they got it down to 1.5MB. Why are people still talking about shipping header tarballs? Is the BTF work just not well known? Since the motivating use case is BPF, which already requires a specialized tool chain, I don't see the downside.

Paper ballots are enormously easier to understand. Anyone could watch pieces of paper being put in a box, watch that nobody interferes with the box, and then count the pieces of paper when they come out. No expertise is required.

Maybe paper ballots aren't *really* more trustworthy than well-implemented electronic ones - there are still plenty of ways to corrupt the process - but they're good enough to be at a point where the average person's perception of trustworthiness is more important than the actuality. One of the benefits of well-run democracies is that nearly everyone accepts the result, even when they lose, because they believe it legitimately reflects the will of the people. Maybe it's the will of people who are stupid and wrong, but you can spend the next few years convincing them to vote the right way next time. But if the voting system is too complex for you to personally understand, you have no reason to believe in its legitimacy, and you're more likely to think your only meaningful option is violent regime change.

Later on, he actually made me blush when reading my morning dose of Linux news: https://lwn.net/Articles/569096/ .

He was also a man you could not have met withoug loving him; at least, I cannot imagine anyone not remembering him like that, if he engaged with one, he left a deep impression of caring.

Thank you Peter, for all you've done for us, and for all that you've been for all of us.

IPng-to-IPng-over-link is obviously native IPv6.

IPng-to-IPng-over-IPv4 is covered by 6to4, Teredo, 6rd, and 6in4.

IPng-to-IPv4, without the option field, is NAT64. DNS translation is also mandatory, working in concert with the NAT64 gateway, if you intend to allow IPv4-only hosts to establish connections to "IPng" servers. Like *any* simplistic address extension scheme—including NAT44 and CGNAT—it has numerous shortcomings due to the fact that one side of the link is blissfully unaware of the need for address extensions. For a start, any protocol which relies on embedded IPv4 addresses will be unusable since (a) one side doesn't have a public IPv4 address to embed, and (b) there is no room to store an extended address even if the NAT64 gateway were modified to intervene and translate addresses at the application layer. The best you can hope for in that case is a new "IPng"-compatible protocol with space for address extensions and an application-level proxy running on the gateway to perform the translation.

Sure. But the counting is done in many different places in any of which you would need people that massively miscount the ballots. Since paper ballots are physical objects, it is intuitively and obviously clear which one has the majority. Faking them is a lot of work and cannot be done in big numbers without being noticed.

So any system that makes it very expensive and difficult to cheat can be trusted (up to a certain level). For electronic systems this is not the case, and I cannot see any way that they ever could be trusted.

It will make Firefox even faster for all of its users. This is so welcome because what has been holding back Firefox's adoption for so long was its slow pre-Quantum user experience. So hurrah for that.

It will inconvenience me and the four other people in the world who care enough about their extension configurations to version them. Boo-hoo, but several people have pointed out that git has an answer to this. I had actually made up my mind to write a script that would transparently encode my JSON files as a database, and whenever an extension writes to the database, I get a (JSON) pull request by email which I can accept or not. But several commenters ruined my fun by pointing out that such a tool already exists.

I do this with git fairly frequently. For years I had maintained a script which automated the process of binary-searching a sequence of commits to find the one that introduced a bug. It started off as a shell script, then I rewrote it in ruby, then I rewrote it in python when I forgot ruby. Then somebody told me about git bisect. I should skim every single git man page at some point, I bet there are more gems.

(Speaking of which. April Fools' Day approaches. I'll leave this Markov-chain based git man page generator here so that people can torment their SVN-using friends: https://git-man-page-generator.lokaltog.net/)

Sure, but given that the hardware and software are open, there are ways of avoiding the need for so much trust:

- Order more voting machines than you need. 1% of randomly chosen voting machines get opened and compared with the schematics.

- But in swing states, even having one in a thousand biased voting machines might be enough to influence the election, with a low probability of being caught. So in those states, maybe disassemble 50% of the machines after the election.

- Build the firmware and software yourself, and reflash every single voting machine.

- Take a selection of voting machines, connect them up to a fake version of the server where they send their results, with an NTPd that reports that today is election day, etc. Press buttons on the voting machine, intercept the results, see if they match. Do the same thing with vanilla unflashed voting machines and see if their behaviour is any different.

etc. You raise a good point about trust being a component even of paper voting. But I wouldn't be so dismissive of quantitative changes in trust; if people really care about this, we can easily get to a situation where electronic voting requires less trust than paper, even if there is still some trust necessary. I doubt people will care until somebody demonstrably sabotages an election, though. Even then, probably only the saboteur's opponents will care, supporters will convince themselves that it's a ploy.

I think most Android devices don't have swap. They prefer to just kill background apps whenever RAM gets low.

https://facebookmicrosites.github.io/bpf/blog/2018/11/14/...

This would be even more useful for mobile devices where data transfer is ridiculously expensive.

At some level, elections have always relied on trust--with paper ballots, for example, you have to trust that the people doing the counting are doing so honestly (and even that doesn't account for the possibility of honest mistakes in counting). Multipartisan observer teams are a good way to combat that, of course, but still not literally impossible to corrupt.

My point isn't that we should make the perfect the enemy of the good; rather, at some point, unless we do away with ballot secrecy and start assembling in public and raising our hands, so everyone can count for themselves how many hands were raised and be satisfied that the announced total is correct (which is not feasible in a modern society), we're going to have to accept that there's a degree of "trust us" inherent in every system.

If someone is thinking that it is good to see the URL to check that it is what it should be, I would say that those checks can possibly be done better by algorithms.

Glad to see someone else had the same idea. Might it make sense to reduce the in-kernel policy a bit by letting user-space handle the tmpfs? One possible (!) implementation would be to have a device which a) lets you read out the archive and b) lets you free the in-kernel memory holding the archive after you have done with it. (Maybe that could mean putting it into __init first and copying it from there to free-able kernel memory.)

Then again, perhaps the same thing could be achieved without it ever being in kernel memory. Tagged onto the end of the kernel binary? Something similar to initramfs? I was going to write "put into initramfs", which would avoid kernel changes altogether, but the thought of bloating that even more is not appealing.

image.animation_mode=none should prevent animated GIFs from playing, though I haven't tried it. No idea about CSS animations.

I did not in any way or form intend to slight the work done by ADRIANE and KNOPPIX - and for what it's worth, I am not a web developer so I may be talking out my arse.

Having said that, I did write "not very accessibility enhanced" - what I meant by this is that it is *my* impression that websites that use responsive design often do so via libraries like bootstrap etc, that - again, my impression - support a11y better than what random web developers may be inclined to support by themselves.
They support screen and braille readers via CSS and what not - at least that is my impression.

So in my mind 'responsive ~= a11y'

With all that said, it would be fairly comical if the documentation sites for said responsive design templates themselves are not a11y-enhanced.