Recently posted comments

Human beings do this with politics as much as technology: let those who really groove on communications electronics figure out how to both design and regulate my handset, so I can bother my pretty head* with other matters.

Possibly what's needful is a discussion on how we manage to put "enough" time into limiting the centralization of information management. Promises to be a challenge.

*It's not actually pretty.

We don't get equivalent top speeds until USB4 is released.

Step 1: Get FCC to clarify that ToS home server prohibition is a clear form of network neutrality violation (blocking based on type of application, service or device type (server is a type of device)).

Step 2: Watch as the evolutionary pace of traditional FOSS email service solutions increases in correlation with the number of people who can (in clear conscience with not violating their voluntarily agreed to business contractual obligations with their ISP) test and try out new solutions. And just like compound interest, every bit of that advancement compounds through time, leading to my projections of exponentially advanced pace of FOSS home server software evolution.

Step 3: Profit from that much greater societal access to Free Speech independent of unnecessary potential censors.

For-profit ISPs might believe they could make a greater amount of money differentiating plans and users. The scheme probably works better the less choice of alternate ISP the targeted users have.

If you mean patch critical security issues reported against the python2 packages in existing supported releases of the distro sure. Ubuntu 18.04 has python in it's main archive component and gets regular support until 2025. After that there is another 5 years of "extended security maintinance" but it is not clear what packages will be covered by that (and you have to pay for it).

If you mean support python2 in new releases of their distros going forward that becomes far less likely. The Debian/Ubuntu has stated they intend to remove python2 from main to universe in the next ubuntu LTS release. On the Debian side some lintian tags state that python2 is "likely to be removed after the release of buster", though time will tell how that actually pans out.

Rust and other languages with algebraic data types has this. You get a `Result<T, E>` where in order to access the `T` (the wanted result), you either need to use `.unwrap()` which turns into a panic if an error did occur or you have to pattern match and then there's an obvious error codepath that exists in the code.

The problem with that is the USB A would limit you to something like 12.5W, right? And for a modern phone that's disappointing whereas for a MacBook Pro that isn't even enough to keep it from discharging while idle...

But yes, it sounds like we need a "USB C condom"...
Having that name actually gives me more interesting Google result - but from what I can see so far there have been quite a few requests similar to mine, but only USB-A versions appear to actually exist.

To my knowledge nobody else implements it, although it is a nice idea so it would be good if other terminals pick it up.

Obviously that would be equally useful when charging your USB-C phone.

Regular combining characters are common, much more common among terminal users than right-to-left text in my experience.

It would be interesting to know if any terminals support zero width joiner (U+200D), I don't believe many do.

> East of the Prime Meridian? I don't think so!

I'm not sure I'm following your reasoning here.

The graph shows a lot of changesets from timezones 0, +1 and +2. When the author says "it seems clear that an awful lot of kernel work still happens at or just east of the Prime Meridian", it appears therefore to me he means, very roughly speaking, 0 is at the Prime Meridian and +1 and +2 are just east from it.

But even if we look closer and watch at the geography of these time zones, the statement still holds.

Timezones +1 and +2 are mostly east of Greenwich in winter, and even in summer a large part of +2 is east of Greenwich (in Europe, +2 in summer is CEST. That excludes Portugal, UK, Ireland, Iceland and Greese but includes the rest of Southern and Western Europe and most of Northern and Central Europe. A lot of that is east of Greenwich.

Quite some of the changesets from zones 0 and +1 probably come from west of Greenwich, but even so I imagine part of that is covered by "at the Prime Meridian" (not *exactly at* of course: the line is infinitesimally thin).

It appears that in Africa there is also a lot of land around those longitudes. South Africa, for example is at UTC +2 and can be regarded "just east of the Prime Meridian".

So yes, I'd say a lot of kernel work happens at or just east of Greenwich (i.e. the Prime Meridian).

(For some pedantic nitpicking: Portugal is on Western European Time, but the rest of the Iberian Peninsula (i.e. Spain) is on Central European Time.)

Ah, yes, prices are overinflated, the rest of your argument is absolutely sound. But the value part is kind of core... :-)

With that point taken, the next question that arises is: how to turn email into a more democratic online service?

I wonder if Alyssa or anyone else has ideas on how a viable business model for a more democratic email service could look like. I guess that it would have to somehow provide additional benefit through community interaction, like Wikipedia does. Privacy-respecting traditional email providers do exist, but are obviously not successful compared to the monopolist.

I have made use of unit tests in other code as a roadmap to understanding what's at stake.

"We are aware of a number of exploits which will let you escape such containers and get full root privileges on the host. Some of those exploits can be trivially blocked and so we do update our different policies once made aware of them. Some others aren't blockable as they would require blocking so many core features that the average container would become completely unusable."

This may become an opportunity to prepare something for USB3/Thunderbolt?

H.

East of the Prime Meridian? I don't think so! On the Prime Meridian we have the UK, MOST of which is to the WEST of the Prime Meridian (and the Meridian being on the east side of London, even if most UK work is done in London that is also to the west ...). Then we have the Iberian Peninsula, which despite lying on the Meridian is on West European time. I don't know how much work comes from Africa, nor which countries lie on the Meridian, although it does run straight down the centre of the continent.

(East of the Meridian, in the UK, we have Kent, Essex, and East Anglia. That's about it. Maybe a bit of Lincolnshire.)

Cheers,
Wol

The traditional sales pitch for predominant unit testing is lightweight, quick-to-evaluate method-level unit tests as the foundation of the Testing Pyramid thing: build trust in your program functions or methods, then build trust in your internal interfaces as you integrate components, then build trust in your external interfaces (user, API), finally trust you've installed it correctly with few fail-fast smoke tests.

I'm reconsidering whether that's right -- given the London School of Test-Driven design builds tests that reflect your design rather than (Chicago School's approach for) a test approach that evaluates every input (or class of inputs that get equivalent results) to the system via its component pieces. Somewhere, an automated framework reflects the full system in a second-system kind of way -- clearly not an acknowledged part of in-depth automated testing.

K3n.

This is also a significant disincentive for providing services from the home.

Cloud services, where many people need to upload files onto the cloud and get bored about waiting for the upload may lead ISPs to slightly reduce the asymmetry, though.

Even in the lucky case that to migrate away is your own decision or that the VPS provider tells you with sufficient advance that they are shutting down your service, even on a fast internet connection moving away many tens GBs of email from the VPS can be painful and may lead you to exceed the allowed rate/month.

Furthermore, why saving your chats/posts/email at a cheap VPS provider should give you better privacy guarantees than doing it with google, amazon, facebook, etc.?

I think there's a 'not' missing between 'will' and 'be'. At least, I was not highly surprised.

(But it does sound like we're very close, which is excellent news.)

Also, for privileged LXC, two much simpler breakout techniques are available that work on Ubuntu: https://seclists.org/oss-sec/2019/q1/125. The upstream position is that privileged containers cannot be made secure, so "not a security bug". I have no idea if they also work with other container runtimes, would appreciate if someone tests the ideas on Ubuntu and other distributions.

What constitute an external or internal interface might not be obvious for some attack. For example the SATA port on my ThinkPad UltraBay is quite accessible. Disabling FireWire and other unused port in the BIOS is something I've been doing for a long time.

But a USB Type-C connector is something everyone will be using. Considering Thunderbolt 3 will become USB4, it is a real concern. And just telling user to not plug in "untrusted device" is not good enough.

And my understanding is that this can not be fully fixed at the OS level:

"Kernel DMA Protection only protects against drive-by DMA attacks after the OS is loaded. It is the responsibility of the system firmware/BIOS to protect against attacks via the Thunderbolt™ 3 ports during boot."
Ref: https://docs.microsoft.com/en-us/windows/security/informa...

It's pretty shameful that these exploits are happening over and over after the industry's had approximately two decades to learn the risks of giving DMA to external peripherals. The kernel even advertises Firewire debugging as a *feature*!

How and why do you think this is an acceptable thing to post? I'd be very saddened if unsolicited personal abuse (even if it was accurate, which it objectively isn't) was considered OK on LWN these days.

It's not that it's rocket science, or even that it takes *that* much time in absolute terms. It's just that I depend on it, so if something goes wrong I have to drop everything and fix it now, which generally means relearning a bunch of fairly boring stuff that I haven't had to think about in a long time.

I remember well that before Gmail came Yahoo! Mail, and before that Hotmail; I remember, too, that before Wikipedia and DuckDuckGo I went to Google for information, and before that Yahoo!, and before that Altavista, and before that Infoseek. Internet mail was not re-invented each time; the Web was not re-invented each time.

Federation works.

I'm hoping that the updated mitigation patch I've been working on[1] will help work around the concerns about memfd_create(2).

[1]: https://github.com/opencontainers/runc/pull/1984

Scratch this, I just remembered as I was writing this comment that you could just remount it as read-write (not sure why I didn't consider that before). In that case, I will go with the overlayfs solution (where we create an overlayfs and open the upper-layer version of the binary). It will be quite ugly because you can't overlayfs on top of /proc/self -- and bind-mounts won't help either because overlayfs doesn't see them.

I have had a looming feeling for the past month or so it would've just been easier to go the LXC route and tell everyone that running containers as root is a really bad idea, and that they should expect reasonable security from such a configuration.

All of this has resulted in a PR I've posted[1] which solves the problem using a temporary (MNT_DETACH) read-only bind-mount of /proc/self/exe in an attempt to avoid the memory overhead -- and in principle because we create the read-only bind-mount ourselves and detached it's very unlikely a host process will accidentally make it read-write during the "runc init" window. If that fails, we then try memfd_create(2) followed by O_TMPFILE (or failing that, mksotemp(3)) inside the runc state directory -- which we need to have read-write access to in normal operation.

I've also re-sent v5 of the AT_THIS_ROOT patchset (which includes the ability to scope #! resolution) to the ML today.

[1]: https://github.com/opencontainers/runc/pull/1984

It also took almost 10 years for Py3 to gain serious traction.

Also, allow me to interject for a moment, but
https://zaitcev.livejournal.com/251546.html

> Do your friends?
Yes, why

> Does your grandmother?
I had two and both are dead, so no to that

> Setting up a mail server often is time-consuming, ad hoc, and brittle; despite technical literacy and the hours I poured in, I continue to have problems with my e-mail delivery.
Suddenly, the problem came into focus: Alyssa Rozenzweig is worthless at basic computing.

There is still a problem of DDoS though. But she's not even there.

That's your choice, but you don't have the *right* to *force* that trade-off on to me.

"fast, cheap, good. Pick any two ..." There's a whole bunch of things people desire that fall in to this category - choosing one inevitably means you lose another. Just because YOU value freedom of speech above other things, doesn't mean I do.

And, quite frankly, it seems to me all too often that "freedom of speech" is equivalent to "forcing your views down my throat". The American constitutional right "to pursue happiness" all too often means *REDUCING* the total happiness (happiness is not zero-sum...). There's plenty more I could come up with if I thought about it ... :-)

A lot of non-USians see the US as a greedy self-centred bully, and that sort of attitude re-inforces that view. Yes we may not have been any better in our heyday, but I hope some of us have learnt. I'm not sure, though, given the Little England mentality of "let's put the 'Great' back in to Great Britain".

Cheers,
Wol

That sounds a lot like exceptions. Errors get propagated up the call stack until someone handles the error, and if nobody handles it then the application crashes. (Of course exceptions introduce a whole new set of problems so they're just as bad as every other approach to error handling.)

If I remember correctly, for years it existed only as documentation. Then there was the Parrot VM (which was meant to be generic enough to run any dynamic language including Perl 6, which in practice meant the VM developers just wrote a garbage-collected continuation-passing-style assembly language and didn't really care about any high-level language at all; and most of the work was done by two people, but they fell out and one quit). Then someone got fed up with the slow progress of Parrot and wrote Pugs (but that was more of a prototyping tool than a production-quality implementation, and it was written in Haskell so even fewer people would be able to contribute to it).

I stopped paying attention before Rakudo, which appears to be somewhat usable now (though with poor performance)? And apparently the Perl 6 language was declared stable in 2015, twelve years after the first Perl 6 book was published. But it's hard to lose such a long-standing well-deserved reputation as a joke and as a community that doesn't get things done.

In contrast, Python 3 had the misfortune of being successful. By the time people realised it was a terrible idea to break compatibility so heavily for such minor gains, it was too late to stop.

cat /dev/kmsg

The second field is the sequence number. You can read about the format here:

https://www.kernel.org/doc/Documentation/ABI/testing/dev-...

> And guess what: PHP is still a terrible language :^)
Yes it is. Not that Python is much better now.

Perl developers also did all the right things:

1) They hard-forked the language. But Perl5 is supported and is being improved all the time. The current Perl5 interpreter is much faster than 10 years ago, for example. In contrast, Python developers abandoned the Py2 code base (only occasionally shitting on it to break existing software).

2) They used a language fork as an excuse to drastically improve the language: Perl6 has no GIL, it has truly well thought out Unicode support and the language itself has been regularized. Initial 4 versions of Python 3 had no real improvements whatsoever compared to Py2.

3) There's no drive to force everyone to forget Perl 5. No self-celebratory sites "Perl5 days to death" or any other such nonsense.

Just to name a couple of issues.

1) Migration. If there is no possibility to straightforwardly migrate to another instance of the federated service, then it is obvious that all the non-professional servers are doomed from the beginning. Who would put his data on a server that may need to be discontinued without any assurance that he/she can migrate it elsewhere without too much effort. For instance, I think that this is the main reason why the mastodon users all concentrate on 3 servers.

2) Poor support for things that users expect to be global. If you have a social-network like service or a chat/voice/voice+video communication service you expect to be able to search the person you want to talk to "globally". This is one of the reasons why things like facebook or skype are so successful. Once someone tells you "I'm on facebook" or "I'm on skype", even if you are not told the username or you forget it, you are typically able to find him/her. In many federated systems, search only works at the level of the single server you are on, and this means that in terms of features and easiness of use, you would be better off if there were only one server.

(1) dynamic IP and dynamic DNS

(2) email servers are complex beasts compared to other types of servers

---

HTTPS used to be on the list but Letsencrypt solved that

---

I think probably everybody here has the internet at home, has a spare always-on box (be it a lowly rPi or a mighty Mac Pro), but getting a fixed IP address (how does one do that?) and managing your email locally and properly without going insane (how does one do that?).

Other countries have many ISPs that can't care less about running home servers. Situation is not different at all there - the reason why home servers are not used is not a legal regulation or a contractual claus, it's the inefficiency and cost of doing it.

The alternative to taking a cut-down feed (which is fractional de-federation, I suppose) is to have an account on an enormous server, where the feed volume is aggregated between the active users, and the message database is physically shared.

WhatsApp might just be XMPP, but it works because it's single node, an enormous SMP system has been competently engineered and refined to the limits of current technology. Cleaving that into federated pieces would necessarily complicate and slow down message delivery and introduce all sorts of synchronization and protocol issues. Seems like a reasonable design trade-off, if you can make it work. More secure than SMS and it's inter-exchange signalling issues.

The multi-dimensional discrepancies between network terms-of-service, national speech laws and population-group sensibilities is one of the more interesting struggles of our age, IMO.

We actually do. OpenSSL git master is licensed ASL 2.0 now: https://github.com/openssl/openssl/commit/151333164ece49f...

The next OpenSSL release will include the license change. We just don't yet have OpenSSL 3.0.0, which is the next release, apparently: https://www.openssl.org/docs/OpenSSLStrategicArchitecture...

Which just means that I think there would be a world of difference in the state of the art (today, 5 years ago, 10 years ago, 5 years from now...) if the FCC had specified that server prohibition ToS is a functionally and legally equivalent form of the net neutrality violation of blocking based on application, service, or device type. I suspect most in this audience can see the functional equivalence (in the case of people who choose to read and obey that extremely small fraction of the very wordy contractual terms of service). However most of the general public may not understand that. Generational effects may change that however.

(*) it does matter _a little_ for the user perspective, in a sense. The hope might be that it matters so little for long enough that other factors eventually obviate it and make it a moot point.

Of course, if I sent a wedding notice to everyone I ever met, it would be naive to expect that not to hit Microsoft or Google mail servers. Whereas if I'm passing some company info to a work colleague that sits at the next room, the logical thing would be that it shouldn't need to get out of the company, getting to his inbox passing through a third-party server hosted on another country (which is what -shockingly- many companies are doing nowadays with their mail servers, even technically competent ones).

A better example for XMPP than the mentioned WhatsApp, and the one I was expecting to see was GTalk. While WhatsApp has always been a closed system, Google Talk peered with other XMPP servers. Its UI was designed around the idea that you would connect with other Gmail users, but it allowed talking with people that were on other jabber servers, as well as connecting there with a different XMPP client if theirs didn't suit you. Many people -and communication platforms suffer greatly of this trap effect, where an individual can't migrate on its own- may not care/know about better options and use eg. Facebook chat. But if you could interoperate with other systems, it wouldn't put you in the dichotomy of migrating your conversations to that new client that works better (for you) or staying there because that's the only that your granny knows to use.

> Not just “fixed”. In various important areas, Python 3 is now considerably faster than Python 2 ever was.
That had been not so for many years, I'd say until later 2017.

Also in a better world Py3 branch would have been abandoned and improvements ported into Py2, resulting in even more speedup.

PHP (amazingly) did the right thing by abandoning PHP6 and instead focusing on improving existing version.

If you just want an email server where you can receive any email from other people, without $COMPANY technically having access to them, or 'deciding' which mails are worth appearing into your inbox or not, it is relatively easy.

However, if you also want not to receive _certain_ emails, that is a different, and harder, problem. We enter into the realm of deciding which emails you _want_ and which not. And yes, the algorithms used by Gmail would probably be better than a bare SpamAssessin/rspamd, if anything for the amount of email that they can peek into in order to detect mass-campaigns. However, they too have false positives, and sometimes mark legitimate messages as spam. So if you delegate into their antispam for organising your inbox, you also have to bear their failures (of course, you can't "just" import their antispam without also using other pieces).

Depending on your email flow, that may not be such a problem. You may eg. prefer to review manually every received email, and create -if needed- local rules on your MUA. Or go the opposite way and only let direct access to your inbox from a few whitelisted domains/users.

In fact, for the scenario by Polynka of a small community, it should be easy to use a mailing list that needs approval and where only subscribers can send.

Most countries that like to call themselves "democracies" are actually nothing of the sort, they are "representative governments" - we call ourselves a "parliamentary democracy" but, seeing as we vote representatives into parliament who then mostly vote as their party leaders tell them to, that's hardly democratic *or* representative. And for the majority of the electorate there is little real choice in our vote anyway, which is why so many people don't bother!

The problem, of course, is that as the number of people that are truly enfranchised goes up, so does the potential for rigging the system, or even just for people who don't actually have a clue mucking the system up. One only has to look at the chaos surrounding Brexit to see the havoc that a true democracy can generate ...

Cheers,
Wol

When somebody starts moaning about the freedom of speech it's always that.

Further, the lack of federation keeps people trapped in silos. So an annoyed gmail user can switch to outlook.com and still communicate with the same bunch of people using their original email addresses. If the same user gets annoyed by whatsapp and wants to switch to hangouts, they have to persuade all their friends to switch with them because whatsapp and hangouts won't federate.

If a silo doesn't federate, the barrier to switching is orders of magnitude higher, which is why the major silos hate federation. I honestly think they'd actually remove email federation if they thought they should get away with it ... Google has been making moves to regard smaller email servers as more spammy, which seems to be an attempt to gauge the backlash involved in removing federation. After all, if you have to have a google account to talk to your hangout buddies, why shouldn't you need a gmail one to talk to your gmail ones.

Again, the important thing isn't that everyone is saying things that require them to have extreme lack of communication channel censors. The important thing is that everyone *COULD IF THEY WANTED TO*. It may just be my USA democracy/freespeech propaganda upbringing talking here, but I think it's critically important to the health of democracy to hold a hard-line on free speech issues. And messily complicated as it is to draw the whole of modern internet technology into the equation, I think it's necessary to do so. And from my understanding of things, the ability to host your own server facilitating such minimization of external censorship opportunities, is a necessary part of that equation.

Or we can try to change yours. I'm sure Google and Microsoft before them would be happier if consumers knew their place and stopped complaining to their representatives urging regulation of 'predatory' business practices.

Perhaps Snowden ushered in a pendulum swing, but prior to 2013 I certainly felt that not enough people recognized the predator-prey nature of their relationships to technology and multibillion dollar international tech companies. I don't think that pendulum has swung too far yet. That's one hell of a capitalist predator we have in the oval office these days...

LOVINT...