EmanueleAina

You are not wrong. But history also somewhat shows that appeasement is even worse.

> because "maintenance"

I like those scare quotes. They really show the lack of respect for the people who actually maintain the stuff you use daily, most of them in their free time, including the ones that get paid (all the paid maintainers I know go well beyond the work hours, by a big margin).

X forwarding works on Wayland compositors that ship XWayland. Just like any other X11 application that does not rely on weird things like intercepting all your keypresses, capturing the content of other applications, etc.

Hold on. CVS?

Not sure how this relates to desktop, but from the article it seems that Arm got some nice involvement going:

> Another huge change is Arm officially joining the party. We were not only given access to some documentation, but they also took an active part in the review process and two developers are currently flagged as co-maintainers of the kernel driver. Some would say that this was already the case when Panfrost got merged, but we have strong reasons to believe Arm's involvement is going to grow outside the kernel space this time.

Except that it never happened.

> I am filled with rage just thinking about how we took a fundamental part of the Internet, simple enough that anyone can implement an HTTP server,

Ahahahahahah, yes, anyone can implement a HTTP server, just badly. HTTP/1.1 is quite complex, the spec alone spans over eight RFCs: if you can implement all of that I doubt the HTTP/2 serialization is much of a concern. :P

Right. In my opinion it's even worse. The thing that piss me off about Spock is that ignoring the emotional component is a very illogic thing to do. :)

Important to whom?

Maybe "In previous Rust versions you could already define traits, ..."?

Right, shaming mothers does more damage than anything else, even if breastfeeding was a big deal (and I think it is, sort of).

Doesn't that applies to the kernel, libc, openssl, the X server, desktop environments, and web browsers?

Arguably, if the situation is the one described, I'm not sure what "the best maintainer" is. :(

Changing name and leaving the old project eventually die or be subsumed by the fork (like egcs did with gcc) would have probably been a better choice.

Arguably, SJ-related topics get their share of downvotes too.

But yeah, I agree with you on the fact that HN is mostly an echo chamber. I'm just less sure that we're hearing the same echo. :)

No need to nudge, `xdg-app` for Debian has already been in the works for quite some time[1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813308

Windows does not have this issue either.

But on sysvinit if you mount efivars rw for any reason and your hands slip a bit a stray `rm` could still brick your motherboard, so it's not really fair to say that without automounting the issue goes away.

It's also the good reason why having systemd mount efivars read-only would have been the wrong thing to do.

What happens if a stray `rm` runs while `grub-install` runs?

The kernel fix prevents that, using mount flags alone only restrict the vulnerability but it doesn't make it go away.

Possibly, but what happens if a faulty script does a `rm` too much in that short time window?

The kernel fix prevents that, using mount flags alone only restrict the vulnerability but it doesn't make it go away.

Your approach still bricks motherboards if somebody forgets to remount ro after having remounted rw.

The kernel fix doesn't have such drawback.

There's a layer between userland and firmware where those things should be handled, and indeed everyone agreed that it should be handled in the kernel

Saying that Lennart is wrong has become a rather popular sport, let's not go overboard to say it even when he's right by all accounts.

I guess everyone is aware of that, thanks,

The parent comments were discussing why choosing dicts over namedtuples for db-originated columns, and the fact that field names are restricted on namedtuples but not on dicts is a very compelling point.

Making examples usind dicts and explaining why namedtuples have restrictions is completely missing the point.

Arguably, it deserves a page because it provides more features.

> just the text of the articles is 8.8GB compressed

Which seems to mean that storing only the version in the user's language should not pose a huge challenge, storage-wise. No?

It surely depends on the projects, but I always found using C# with Mono on Linux to be a pleasure.

Apparently some releases of F# already work on Mono: http://www.mono-project.com/docs/about-mono/languages/

Care to explain?

As I read it, it seems a tautology: if one seeks change, it seems obvious that the initial condition has to be different than the target one.

So it's not "perfect", it's just "high quality".

And what made you think that the code written by Sharp wasn't high quality?

Have you ever seen a work that is perfect?

Do you feel the Linux kernel is perfect by any metric?

You're describing how to maintain the status quo (which is simpler than any other option, indeed). Changing the behaviour of communities is instead how progress works (well, also regression, but I hope you got the point).

The other part is the good sense of not taking them (I mean, they are "bad decision", they should be avoided by definition).