drewdevault

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.

Why would you even say something like that?

The original aerc prototype was written in C. It wasn't great.

https://git.sr.ht/~sircmpwn/aerc-legacy

Singapore has the death penalty for drug offenses.

From the terms of service:

> 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:

https://paste.sr.ht/~sircmpwn/0b3f1f1d77896a96b0777471785cdc...

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.

So, do I just send you my bank account number or?

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.

Both. We restored from backups and touched up the diff out of band. We then had the drives removed and destroyed.

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.

Agreed. This is ridiculous.

>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.

We're excited to see valkey innovate in these areas! We wish you the best of luck and wish that we could have merged our forks, but alas.

>Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open

I'm not sure that this is true, at least not the commercial part. Redis clients are pretty simple (compared to Redis itself, at least). Redict is leading an effort to encourage community forks of the official Redis clients, as well as sending patches downstream to third-party clients. We set as an explicit goal to fork the ecosystem as well; we've started this work with hiredict and don't intend to stop.

I think there was some mention at some point about our two forks working together on maintenance of the protocol specification independently of Redis Ltd, which would be a good way to ensure that the clients remain broadly compatible with both of our forks.

I'll defer to your on the ground expertise as to the relative popularity of each, but I will point out that we're both working with anecdata here. I might also suggest that MySQL is losing a lot of ground to Postgres and I don't expect that trend to reverse in any case.

In any case it's not very relevant to this thread because you're quite right in pointing out that MySQL uses a free software license (GPL).

>Are you sure? I'd asked antirez to clarify 6 years ago, and he said he had transferred the Redis IP to Redis Labs, without being more specific

Well, trademarks are a form of IP. But in any case the copyright was never antirez's to transfer to anyone. In the absence of a CLA with a copyright assignment, every contributor retains the copyright to their contributions, and licenses them to everyone else (Redis Ltd included) under the terms of the BSD license. Legally speaking, Redis Ltd's SSPL code is, in effect, a fork of the Redis BSD code, in the same way that Redict is.

>In any case, congratulations on the very fast release of Redict, rewriting references to Redis is not a simple s/Redis/Redict/g sed job. How do you feel about possible competition with the Valkey project, apart from the licensing differences?

Thanks for the congratulations!

As for Valkey, so far they've put a lot of time and energy getting the various corporate stakeholders on board with their fork and getting some marketing out (which is no small feat, to be sure, I shudder to imagine the number of lawyers involved), but they still have a lot of boots-on-the-ground work to do getting their fork up and running so it may be a while before our projects are interacting directly. From the limited communication we've had with them, it seems likely that we'll be able to collaborate insofar as reducing incompatibilities is concerned, maybe co-maintenance on the protocol specification, but not much more. Redict does plan on pulling useful patches from Valkey once they get the code going, though it's unfortunately not possible for them to pull from us unless they're on board with switching to a copyleft license -- and we encourage them to do so :)

>MariaDB is also somewhat widely used, but not nearly as much as MySQL.

I believe this is factually false. Consider just one datapoint:

https://repology.org/project/mysql/versions

https://repology.org/project/mariadb/versions

No problem :)

Thanks! It would be great to have your help.

I think your Rust/wasm goals are a little bit dramatic for the goals we established among ourselves, but by all means start a conversation about it. Good support for compile-to-wasm is probably something that we'd be down to have upstream, though.

It's essentially a do-ocracy in practice, though we have discussed the possibility of putting together a foundation to steward it, particularly if we start to get money involved. There are currently five people who have admin rights with respect to their various competencies, and anyone who establishes trust with the community and gets stuff done will also be promoted to their level of competence, as it were. Though I hesitate to describe it like this, I think of "admin" more as a clerical role than an authoritarian one. You're good at code review? Everyone generally trusts you? Then merge rights are just a tool to help you do your work better.

I don't think anyone is going to be very excited about introducing Rust unless there's a compelling reason to, but feel free to bring it up on the issue tracker for discussion and see if you can form a consensus on the matter with the rest of the community.

Just passing by with a quick nit to pick:

>And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it

FYI we're publishing to registry.redict.io, so s:redis:registry.redict.io/redict:g

https://redict.io/docs/redis-compat/containers/

Not that it detracts from your point in any way :)

To clarify, they did not purchase the copyright -- they purchased the trademark, and are using it to attempt to capture the practical value of the copyright. The copyright is by far the more valuable of the two, but they do not actually own it. Of the actual valuable object (the copyright, i.e. the codebase), about 80% was written by people outside of the employ of Redis Labs né Redis Ltd.

I agree with dartos, but I will state for the record that you can use Redict for free in production even if you do sell a hosted version of it.

>That said, correct me if I’m wrong, but, as far as I understand, what Redis Ltd did, they could do regardless of the license. Copyleft wouldn’t have stopped them, given the CLA.

Redis never had a CLA and Redis Ltd does not hold the copyright for the work, it's held in aggregate by all contributors. Redis Ltd did use a CLA for their products surrounding Redis, like RedisJSON, but Redis itself did not use a CLA.

>To people outside of Redis Ltd who don’t want to be Redis Ltd customers this move is indistinguishable from them just closing down business and stopping development of Redis.

Redis Ltd was only ever responsible for about 20% of the development of Redis. If they wanted to shut down operations in good faith they would just hand it over to the other 80% to manage. Instead they used their trademark to try and do a hostile takeover of the IP.

I don't see any reason why this is off-topic. Naturally the license change is a distinguishing feature of Redict and a reasonable subject for discussion.

I lost the password to my old account.