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.
This is debatable. The default workflow requires access to crates.io, and it is pretty hard to not use crates.io.
Even with using crates from crates.io.
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.
> 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.
> 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.
There were specific reasons for that: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...
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.
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?
We do also, you know, give permission.
https://lwn.net/Articles/118279/
Debian wanted to allow anyone to patch their firefox. Mozilla said OK, but not with our name attached to it.
And this makes sense on some level : No project wants to provide support for someone else's bugs.
I can see why people would be opposed to that.
I'm thinking about LLVM (and, obviously, rustc)
That said, it would certainly be uncomfortable to move from "it compiles with Clang, though it's a pain, or GCC, which works fine" to "it compiles with GCC, if you don't use any of this functionality, or LLVM only, if you want any of these features or anything that depends on them".
So, we're currently expecting that supporting Rust will not place any requirements on the C compiler you use, unless you want to use cross-language LTO (which we'll eventually want to do, but it won't be a hard requirement for a working kernel).
Does Linux even work with LTO right now? It seems to do a lot of weird-linking-magic things that I wouldn't expect to work well with LTO.
https://linuxplumbersconf.org/event/7/contributions/798/ (slide link at the bottom)
Like GCC?
Your point is certainly valid, but I'm not sure it's a new problem.
It's not fully complete. But there is no reason why it couldn't be.
But no, there are other reasons outside of trademarks, some technical ones are in submisson’s article.
> Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No. We are not against all trademarks, only those which explicitly prohibit normal use, patching, and modification.
> As an example, neither Python PSF nor Perl Trademarks currently prohibit patching the code without prior approval. They do prohibit abuse of their trademarks, e.g. you cannot create a company called “Python”, but this does not affect your ability to modify their free software and/or apply patches.
> Due to the anti-modification clause, Rust is a non-permissive trademark that violates user freedom.
[0] https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
> Licensed redistributors of Perl code are permitted by their licenses to use the Perl logo in connection with their distribution services, on product packaging, and in promotional materials.
IANAL, but that text would especially suggest to me that you would have no right to use the trademark even to distribute an unmodified binary of Perl without approval.
I suspect the real reason is Debian and Mozilla had a very public, well-known spat over licensing, and Python and Perl have not had very public, well-known spats with anybody.
It’s typical GNU/Pendantry.
The kernel will not be shipping a rust compiler, patched or otherwise.
Shame really.
1. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
GNU can either cut a deal with the Rust Foundation or use fair-use previsions afforded by trademark law. I think there is some leeway for cases like these.
GNR: Gnr Not Rust
TRust: Treated Rust
...
Some attempts: GRR: Gnu Renames Rust, GAR: Gnu assimilates rust, GER: Gnu non Est Rust (gnu is not rust, but in latin to get an E), GIR: Gnu Isn't Rust, GOR: Gnu Oxidizes Rust, GUR: Gnu Unseats Rust.
You can also go for GunsNRoses, but they won't like it and complain. Which might be good for visibility at the beginning.
But it seems, from an RESF standpoint, that the fact that any C code is out there running at all is a crisis-level problem.