I've read most of the report and it's got a lot more than "last time". Speaking as someone who has done a lot of my own research on Stallman's bullshit, the depth of this report is astonishing. The allegations it makes regarding the conduct of the rest of the FSF is particularly alarming.
I think you should at least skim it before you comment.
Your cited source is not really a good view of the situation. He did not reverse his position at all on the Minsky/Epstein issue (and the article quotes Stallman doubling down on this, saying he's resigning over "a series of misunderstandings and mischaracterizations" of himself), and he was re-instated at the FSF without ever providing a meaningful apology or a reversal of any of his problematic positions. Following his reinstatement he has continued to maintain and advocate for problematic political views regarding sexual assault, and he has never meaningfully retracted his views on child sexual abuse or apologized for anything he has ever said.
I am sympathetic to the cause. I respect the Linux project as a whole forming a consensus on the right direction for the kernel and I respect the right of the Rust developers to participate in the consensus-making process and advocate for what they believe is the right direction -- and put in the work to get there. I can hold this view and disagree with their opinion at the same time. I celebrate the difficult technical and political work they're doing to advance their cause, and I respect the hell out of that -- the fact that I would make different choices doesn't contradict this in any way.
The fact of the matter is that politics was always going to be difficult, and for all of the respect and admiration I have for the Rust-for-Linux team -- which I do have, thank you -- I am equally sympathetic to the kernel hackers who didn't ask for this project on their doorstep, and for their own needs to be accommodated. I condemn the toxicity that has bubbled up in this process, from C hackers and Rust hackers alike, but even absent that toxicity I think that the political challenges of Rust-for-Linux are enormous and distract from the fundamental work of the project.
People have burnt out and quit the project, and you cannot erase their experience when it questions the viability of the project. I'm offering them compassion and a different path that might celebrate their work without leading to burnout. People having burnt out and quitting the project is a historical fact, and not my fault, even if I'm the easy polemic for you to pin the blame on. I think it'd be a fucking shame if they quit pursing their passions for OS development in Rust over it and I've said as much and that's more than I can say for you and everyone else filling my messages with personal attacks and bad faith reading of everything I have to say.
>This person read that email about one Rust Kernel developer resigning because of burnout. Now he goes into how the Linux project is a “burnout machine” and how his heart goes out to the “developers who have been burned” (how did we get to plural?).[1]
There are several Rust-for-Linux folks who have complained about the same things and been at various levels of burned out over the course of the project. Ignoring them because it raises uncomfortable questions regarding the viability of the project doesn't make it go away, it just erases their experiences.
>The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here.
>The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel.
This article is in response to someone who already decided to abandon the project, and to suggest what's next. I didn't impose the conclusion to abandon it on anyone, and in fact I explicitly supported it if burnout victims choose to return to the fold.
Yes, I stand by the conclusion that Rust-for-Linux is probably not a great idea, and I'm allowed to say that without being anyone's "enemy". I also believe people when they say they're burned out and quitting the project and take their needs seriously, something I think is missing from your comment. All of this is compatible with compassion. I'm not and have never been your enemy: I can say that I think it's not a good idea and wish you well in your efforts nevertheless, and I have.
Cygwin is a POSIX implementation, not a Linux implementation. Linux is mostly POSIX compatible and so Cygwin is source-compatible, but not binary-compatible, with many programs that work on Linux.
I have not contributed much to Linux -- my claim to fame is submitting a one-line patch which generated 50+ emails of arguments from LKML before Linus merged it -- but I have read a ton of the Linux source code and familiarized myself with many of its internals many times, as well as doing extensive low-level systems work in userspace against the Linux API/ABI. I often use it as a reference in my own osdev work, or working on Hare, etc. Have read a lot of the syscall API surface, DRM internals in depth, dcache and several filesystem implementations, io_uring, etc. Not ignorant to what would be involved in making a Linux-compatible kernel.
> Please be aware that there may be certain adult or mature content available on the Website. Where there is mature or adult content, individuals who are less than 18 years of age or are not permitted to access such content under the laws of any applicable jurisdiction may not access such content. Certain areas of the Website and Services may not be available to children under 18 under any circumstances.
Ironic given that the creator is only 17 himself per the original post. Having run a site like this before, you can expect to get some awful stuff uploaded before long, up to and including CSAM. Not sure I can trust a minor to moderate this stuff and push that "report" button in good conscience knowing that a minor will have to view the material to make the call.
Something that hasn't been addressed by comments here yet is that you could implement EFI boot services in the Linux kernel and essentially turn Linux into a firmware interface. Though note that I generally shy away from any attempts to make the kernel into a really fat bootloader.
>So he cheated, he got Linus to run BK commands at his house and he snooped the network. He had no legal access to those bytes. Without those snoops, no chance he reverse engineered it.
Snooping the network is a common and entirely legal means of reverse engineering.
>There is absolutely zero chance he figured out the pull protocol via telnet. I will happily pay $10,000 to anyone could do that with zero access to BK. Can't be done. If I'm wrong, I'll pay up. But I'll have a lot of questions that can't be answered.
I just tried this myself. Here's the telnet session:
I confess that I had to look up the name of the BK_REMOTE_PROTOCOL environment variable after a few false starts to put the pieces together, but it would be relatively easy to guess.
I also looked over Tridge's original sourcepuller code and didn't really see anything that you couldn't infer from this telnet session about how bk works.
Come on, man, you should be better than this. With so many years of hindsight surely you realize by now that reverse engineering is not some moral failing? How much intellectual and cultural wealth is attributable to it? And with Google v. Oracle we've finally settled even in the eyes of the law that the externally visible APIs and behavior of an implementation are not considered intellectual property.
Tridge reverse engineering bk and kicking off a series of events that led to git is probably one of the most positively impactful things anyone has done for the software industry, ever. He does not deserve the flack he got for it, either then or today. I'm grateful to him, as we all should be. I know that it stings for you, but I hope that with all of this hindsight you're someday able to integrate the experience and move on with a positive view of this history -- because even though it didn't play out the way you would have liked, your own impact on this story is ultimately very positive and meaningful and you should take pride in it without demeaning others.
In retrospect, our datacenter partner in the old datacenter was unreliable. But, we had been there from the start, since I was just hosting a personal server there pre-SourceHut, and during the incident they egregiously violated their SLA with us -- we had reason to expect better from them.
We're much more confident in our AMS partner, though.
There was no lost data, and it wasn't just unanswered emails -- several hours on the phone, juggling between subsidiaries on either side of the pond, with no clear responsible party on their end. The customer service for this shipping provider is totally opaque and automated with AI crap throughout. We did eventually get in touch with some humans but they were not ultimately very helpful.
We do have general business insurance and will probably file a claim, but we have two overworked and exhausted staff members, a lot of other priorities, and a budget which is already pretty deeply cut from all of these events, and we just don't have the time and energy to duke it out with an opaque megacorporation right now.
>I'll get on my soap box then. The redis client ecosystem is fractured and awful, and it's mostly Cluster's fault. Getting cluster right is really hard, and most clients do it inconsistently and get something wrong, if they tried at all (hiredict doesn't for example).
Fair point, I think it's prudent to recognize this as a weakness in the ecosystem. But I would also say that applies generally of cluster, sentinel, etc, in all respects. I know this is a focus area for valkey for that reason.
I think you should at least skim it before you comment.