News for hackers. Stuff that matters.
Re:Supporting Linux kernel development in Rust by JoshTriplett on Monday August 31, 2020 @04:40PM (#24335708)
The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog posts for details), systemd is not spelled "SystemD", gettext has no dependency on Java (and the link in that post explains that). And in general, decisions about what technologies to use are made by those who show up and do the work to build viable solutions, not by people who snark.

It's a rant by an obscure one-developer distribution that formerly used the Linux kernel. Some people are never happy no matter what you do, and if you make the mistake of treating their rants as useful feedback, you get a list of 30 more demands before they'd consider gracing your little project with the honor of their all-important usage again.

Re:Supporting Linux kernel development in Rust by R0b0t1 on Tuesday September 01, 2020 @12:54PM (#24343820)
>Rust does not require internet access to use

This is debatable. The default workflow requires access to crates.io, and it is pretty hard to not use crates.io.

Re:Supporting Linux kernel development in Rust by steveklabnik on Tuesday September 01, 2020 @12:57PM (#24343867)
It is well supported by the project itself, we offer a variety of tools so that you do not need internet access, and this was also a hard requirement of a lot of our early important users, like Firefox and various distros.

Even with using crates from crates.io.

Re:Supporting Linux kernel development in Rust by R0b0t1 on Tuesday September 01, 2020 @02:57PM (#24345501)
If crates.io was down tomorrow there would be a major disruption to you if you were using Rust for development. That is their point, as well as potentially exploring other reasons.

As someone who uses a source-based distro I hate language package managers. They always end up inferior to a distro package manager and create extra work for everyone, including the language developers, who tolerate it because it is in their favorite language.

Re:Supporting Linux kernel development in Rust by steveklabnik on Tuesday September 01, 2020 @04:33PM (#24346726)
It would only be an issue if I wanted to use crates that weren’t in my local cache already. And that’s gonna be true of any build system. It would also be true of any distro package manager.
Re:Supporting Linux kernel development in Rust by R0b0t1 on Wednesday September 02, 2020 @11:59AM (#24354485)
Most other software is more dispersed and has plenty of mirrors, e.g. the Debian project. The same criticism of crates.io is typically levied against GitHub.
Re:Supporting Linux kernel development in Rust by ColanR on Monday August 31, 2020 @04:57PM (#24335855)
I think you were being "inaccurate and hyperbolic".

> Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for)

What they actually said in the article:

> Historically, some features began as optional ones until they reached total functionality. Then they became forced and difficult to patch out. Even if this does not happen in the case of HDCP, we remain cautious about such implementations.

Re:Supporting Linux kernel development in Rust by JoshTriplett on Monday August 31, 2020 @05:03PM (#24335931)
My comment was entirely based on the second link. Direct quote from that:

> Linux kernel forcing adaption of DRM, including HDCP.

(Which linked to a patch adding driver support for handling HDCP, with absolutely no possibility of it somehow being forced.)

Regarding the quote from that interview: sure, and there's also no guarantee that the Linux kernel won't drop support for every architecture except SPARC, except of course for all the people involved not putting up with it. In what possible universe would Linux developers decide it was a good idea to mandate HDCP? It's completely unfounded and unsupported hyperbole and fearmongering, without even a hint of potential truth.

It's also roughly consistent with what I'd expect from someone who thinks that gettext daring to have support for Java and C# format strings is a horrific problem that should be ripped out by the roots.

Re:Supporting Linux kernel development in Rust by boogies on Monday August 31, 2020 @05:43PM (#24336233)
I don’t know about Linux, but Mozilla has mandated many things that I would have hoped it never would have, like XUL depreciation, and especially added many anti-features to their largest product, deciding each was not their hill to die on https://news.ycombinator.com/item?id=24124954. I left Firefox and have never regretted it. The Hyperbola devs did the same, and I will be happy to try their OS and support them fighting on every hill they find, no matter how tiny or unimportant it seems to larger organizations.
Re:Supporting Linux kernel development in Rust by JoshTriplett on Monday August 31, 2020 @06:06PM (#24336379)
> like XUL depreciation

There were specific reasons for that: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...

Re:Supporting Linux kernel development in Rust by boogies on Tuesday September 01, 2020 @10:57AM (#24342452)
Oops. This is why I try not to rush HN comments. This one I did and tried to remove my partial list of complaints about Mozilla and left one element, that’s not the most important one.¹

Mozilla markets Firefox as ‘the only browser made for people, not profit’. But they’ve done the exact opposite time and time again. Virtually the single most prominent UI element, the omnibar, has been sold out to the single largest threat to the open web, the gatekeeper to the entire internet to the vast majority of its users. I don’t want to spend all day railing against Mozilla, as easily as I could, but I can easily find a couple other examples off the top of my head. The Mr. Robot scandal is another example of selling out and (not necessarily directly harming but very significantly) alienating users. And it’s been a few years since I’ve used FF as my main browser but I still remember every time I installed it on a new device going into settings and changing default after default to revert it back from a profit-seeking product to a personal tool, disabling telemetry, etc.

1: Although it does make a difference to me. I’d use pre-Chromium Edge if it was FLOSS, on my OS, and let me use Pentadactyl. The excuses for XUL’s removal — security, stability, and speed — don’t concern me: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... seems to claim it would allow someone to somehow steal my passwords. I’ve been using Palemoon for years and I don’t have any weird activity on any of my accounts, and I keep my browser sandboxed (something Firefox should do better by default, one way it’s behind Chromium) so I don’t have any other security worries. I have no stability or speed issues, and maintainability seems like a non-issue given that an apparently one-man main team keeps Palemoon running.

Re:Supporting Linux kernel development in Rust by boogies on Monday August 31, 2020 @05:19PM (#24336080)
I was going to comment similarly. The comment could be described as “inaccurate and hyperbolic”: if spelling counts, the second link does not say Linux was “forcing adoption [emphasis added] of HDCP.” Systemd stinks and I don’t care how it’s spelled as long as it’s sent to … nvm. And the Hyperbola devs have shown up, done the work, and ported pacman to their kernel, not making the mistake of listening to hyperbolic haters.
Re:Supporting Linux kernel development in Rust by Foxboron on Monday August 31, 2020 @06:39PM (#24336593)
> And the Hyperbola devs have shown up, done the work, and ported pacman to their kernel, not making the mistake of listening to hyperbolic haters.

Where? I was curious as there has been no upstream improvements. And there are no new code in what I assume is their upstream repository?

https://libregit.org/Hyperbola/hyperman