bboozzoo

Are you suggesting that debian.org links or should link to Ubuntu's release announcement?

There's a corresponding Ubuntu security notice: https://ubuntu.com/security/notices/USN-4705-1

There's apt-get purge or apt remove --purge to do those manual steps.

How does that prevent you from using Ubuntu as a server with docker or something else of your choosing?

So why not Ubuntu instead of Debian?

Actually being Polish I can say it is correct, at least for the cases mentioned (also correct for suffix -cki). However it is true that there are surnames that do not follow this particular inflection scheme.

Keep in mind that Poles are likely to use a single, male variant of the surname, rather than explain the intricacies of inflection in the Polish language.

> It's not for nothing that Snap is considered dangerous by SUSE and is not officially supported. They even fail basic upstream responsibilities.

Care to provide a link to support your claims?

Can you share a single window in eg. Meet? Do alternative input methods work for accessibility?

FWIW I would like Wayland to finally take off, but each time there some random shit that's still broken despite 12 years of development.

> I know that some remote-first companies tend to group related work by timezone, so that teams can be both distributed and low latency. I take it Gitlab isn't one of those?

Probably depends on the team, individuals being able to self-organize and their experience. While some companies may see timezone distributed teams as disadvantage, I believe it is an opportunity to have a continuity of work and getting things done faster than if you had a single 6-8h time slot.

AFAIK the effort is still ongoing. I believe LWN had some nice coverage on that, with the last majir pain point being attaching a security context to sockets in a way that suits all interested LSMs.

Anyways, I would not expect to have LSM stacking enabled in Fedora or RHEL anytime soon after it lands in mainline, mostly due to political reasons, thought I'd very much like to be surprised when the day comes.

> Flatpak provides the abstraction layer for this; the base OS can be anything and the applications use only libraries from a Flatpak runtime; by default, Flatpak uses OSTree to store applications.

Snaps use squashfs, so instead of a hardlink farm, you have self contained fs images.

> Snap is similar, although it requires AppArmor, so can't run on many popular distros,

I'm not sure why you continue to repeat this factually incorrect information. AppArmor is not required. In fact, guessing you being a Fedora user, you can verify that by installing snapd from your distro repositories.

However AppArmor is used for providing confinement of snaps (aside from sandboxing which requires the same interfaces in the kernel as flatpak or docker do).

> and I think there's only one runtime that you're required to use, so no "mix and match".

Currently there are runtimes based on Ubuntu 16.04, 18.04 and upcoming 20.04. There's some work to support freedesktop runtimes, but it got stuck on defining metadata for describing security profiles of apps using given runtime.

> FlatPak SDKs provide this.

> Snap has an SDK as well, although note the singular, Snap is exclusively controlled by one company.

Wouldn't call it an SDK, but there's a tool called snapcraft to build snaps in a convenient manner. You could just as well use 'snap pack' or mksquashfs directly.

The fuss seems to be about motd phoning home. Disabling it is trivial, as you noted in your blog post.

The remaining bits likely come from Debian. If you believe it's a bug, have you tried reporting one?

I don't think SELinux would help much here, since users usually run as unconfined_t. I'd guess typical users also run `sudo <whatever>` without bothering to switch role/type.

Or cpio. IIRC tar had its own set of issues once you consider old Linux distros or non-Linux systems in general.

Are you saying that upstream is actively stopping you from submitting patches adding kqueue() support or refactoring the codebase to be more portable?

Isn't that exactly what made PS3 hard to develop for?

Or even smaller than 200k people, try KU Leuven for instance.

shady

Logical errors are always an issue, regardless of the language.

As for Erlang's problems, it does have a fair number of warts and special cases, but the biggest of them all is that it's still a niche language. We actually had to dump Erlang for new projects in favor of Go. That may sound ridiculous, but filling positions involving Erlang was next to impossible (even with candidates without any prior knowledge of the language).

Unless you're writing in Erlang, in which case you program the success path and 'let it crash' in a controlled manner.

Can you elaborate? Although haven't tried it myself, I was under the impression that it's quite possible to write low level code for at least for x86 and ARM (and AVR?).