851–860 of 1001 posts
It’s absurd that the C/C++ community is so hard-headed about Rust. Is the Linux kernel in fifty years still going to be written in the same language it is now?
I hope so
Earlier quoted context omitted.
How do you respond at your job when people don't do what you want? Do you weaponize social media against them? Also, the person rejecting the patch seems to have never claimed to want rust in the kernel.
How would I respond at my job if someone openly antagonized my project(s) and completely refused to work with me? Probably complain to management.
Earlier quoted context omitted.
I personally don't think GitHub's PR model is superior to e-mail based patch management for two reasons. First, e-mail needs no additional middleware at git level to process (I can get my mails and directly start working on my machine), plus e-mail is at least one of Git's native patch management mechanisms. This is not about spam, server management or GitLab/Gitea/whatever issue. This is catering to most diverse wor…
> Your mail provider is failing? It'll be up in 5 minutes tops, or your disk is full probably, go handle it yourself. Well until you deal with email deliverability issues, which are staggeringly widespread and random. Email were great to send quick patches between friends like you'd exchange a USB key for a group project. For a project the size of Linux? It doesn't scale at all. There is a reason why Google, Meta, Re…
Earlier quoted context omitted.
That doesn't match my experience of what we do, so I'd like to see those "many such examples". IMO, if you're going to make charges like this, which would be serious if they were true, you should include links so readers can make up their own minds.
https://news.ycombinator.com/item?id=42461200 https://news.ycombinator.com/item?id=42907076 https://news.ycombinator.com/item?id=42783776 https://news.ycombinator.com/item?id=42780835 https://news.ycombinator.com/item?id=42718838 https://news.ycombinator.com/item?id=42708579 https://news.ycombinator.com/item?id=42700319 https://news.ycombinator.com/item?id=43034231 https://news.ycombinator.com/item?id=43031405 https:…
Of the 10 links you listed, 7 seem to me obviously to break the site guidelines and I've flagkilled them. One, incidentally, was from an account that we banned earlier today (https://news.ycombinator.com/item?id=43042278), and another was from an account that we banned a couple days later (https://news.ycombinator.com/item?id=42483610).
Of the remaining 3 of the 10, I disagree with you about saagarjha's comment: https://news.ycombinator.com/item?id=42907076. That one seems thoughtful and in keeping with the site guidelines. It does use a lot of sort-of trigger words (I counted "trans", "vegan", "left wing", "Democrat", "progressive", "conservatism", "Republican"), but surely we're not going to punish people just for using words like that.
The other two seemed borderline to me, although I confess that one was so long that I couldn't read it before becoming le tired.
> I could find many, MANY more examples.
I'd be interested in seeing them, and I hope it's clear that I mean that. I don't want to argue about this—I want to see what you're seeing.
Earlier quoted context omitted.
Marcan's career as a developer includes lots of development on hostile systems where he's jailbreaking various consoles to allow homebrew. Asahi Linux is similar, given how hostile and undocumented Apple Silicon is, but it has a great amount of expectations of feature completeness and additional bureaucracy for code changes that really destroys the free-wheeling hacker spirit.
> Asahi Linux is similar, given how hostile and undocumented Apple Silicon is, […] «Undocumented» – yes, but «hostile» is an emotionally charged term that elicits a strong negative reaction; more significantly, though, it constitutes a flagrant misrepresentation of the veritable truth as stipulated within the resignation letter itself: When Apple released the M1, I realized that making it run Linux was my dream proje…
Earlier quoted context omitted.
Marcan's career as a developer includes lots of development on hostile systems where he's jailbreaking various consoles to allow homebrew. Asahi Linux is similar, given how hostile and undocumented Apple Silicon is, but it has a great amount of expectations of feature completeness and additional bureaucracy for code changes that really destroys the free-wheeling hacker spirit.
Why not develop a distro based on BSD/darwin kernel then?
The BSDs. You can fork a BSD. Maybe he could try to mainline into the BSD, but would probably face a similar battle with the BSDs. Right, one again, the benefit mainlining into linux, and there is some (maybe limited) support to include Rust, is you can narrow your scope. You don't need to worry as much about some things because they will just sorta work, I am thinking like upper layers of the kernel. You have a CPU scheduler and some subsystems that, may not be as optimized for the hardware, but at least it is something and you can focus on other things before coming around to the CPU scheduler. You can fork a BSD, but most would probably consider it a hard fork. I also don't think any of the BSDs have developers who are that interested in brining in Rust. Some people have mentioned it, but as far as I know, nothing is in the works to mainline any kind of Rust support in the BSD kernels. So he would probably meet similar resistance if he tried to work with FreeBSD. OpenBSD isn't really open to Rust at all.
Earlier quoted context omitted.
I believe the Rust for Linux project was started by a Linux guy, rather than a Rust guy, and many of the Rust for Linux maintainers have come at this from a perspective of "we are Linux maintainers who want to use Rust" rather than "we are Rust users who want our code to be in Linux". I think it's important to be wary of simplistic narratives (such as "C vs Rust"). Maintaining a complex piece of software comes with t…
It is entirely unclear to me where the value actually is. It seems google is funding it for some reason. And some people clearly have a lot of opinions that this is "the future". People had similarly strong opinions about various other things in the past.
See, for example:
https://xcancel.com/linaasahi/status/1577667445719912450?s=4... https://vt.social/@lina/113056457969145576 https://asahilinux.org/2022/11/tales-of-the-m1-gpu/
In fairness, this is one team working on one project, but if they're attributing much of their success to Rust, it's probably worth listening to and understanding why, particularly as I don't believe they were particularly evangelistic about Rust before this project.
I have no idea about the Google funding, but Marcan's blog post is very explicit they they do not have any corporate sponsorship. If you believe that to be untrue, please explain your reasoning rather than spreading unsubstantiated rumours.
Earlier quoted context omitted.
How would I respond at my job if someone openly antagonized my project(s) and completely refused to work with me? Probably complain to management.
What if management tells you to keep going the way you are, but offers no support?
Well that's unfortunate. It seems like there's a balancing act between the benefits of writing drivers in Rust (easier, more maintainable), and getting those drivers mainlined (apparently soul-destroying, morale killing), I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly (redox being an obvious candidate, but maybe one of the BSDs?). Given the narrow set of har…
FreeBSD may be open to it? It's been awhile, and I haven't kept up to date on it for a year or two. But once again, I think you'd have to start from scratch. So everything for R4L that was built before Asahi Linux needs to be done on the FreeBSD side.
NetBSD is probably a no go. NetBSD supports architectures that Rust (due to LLVM) can't support. Which means it is most likely a no go for NetBSD, NetBSD's schtick is that it can run on anything and they will fully do everything in their power to make sure NetBSD can run on any hardware and be maintained. Hardware portability matters for them.
The attitude I've seen from OpenBSD devs is, the answer is to 'git gud' at C and, not replace C code with Rust. Or in other words, they have no interest in Rust in the OpenBSD kernel.
I don't really know where DragonFlyBSD falls in this. Its the BSD I know the least about.