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.
AFAIK, the UEFI spec imposes no requirement that (non-hotplug) devices be re-initializable after you've already initialized them once. Devices are free to take the "ExitBootServices has been called" signal from EFI and use it to latch a mask over their ACPI initialization endpoints, and then depend on the device's physical reset line going low to unmask these (as the device would start off in this unmasked state on first power-on.)
Devices are also free to have an "EFI-app support mode" they enter on power-on, and which they can't enter again once they are told to leave that mode (except by being physically reset.) For example, a USB controller's PS2 legacy keyboard emulation, or a modern GPU's VGA emulation, could both be one-way transitions like this, as only EFI apps (like BIOS setup programs) use these modes any more.
Of course, presuming we're talking about a device that exists on a bus that was designed to support hotplug, the ability to "logically" power the device off and on — essentially, a software-controlled reset line — is part of the abstraction, something the OS kernel necessarily has access to. So devices on such busses can be put back in whatever their power-on state is quite easily.
But for non-hotplug busses (e.g. the bus between the CPU to DRAM), bringing the bus's reset line low is something that the board itself can do; and something that the CPU can do in "System Management Mode", using special board-specific knowledge burned into the board's EFI firmware (which is how EFI bring-up and EFI ResetSystem manage to do it); but which the OS kernel has no access to.
So while a Linux kernel could in theory call ExitBootServices and then virtualize the API of EFI boot services, the kernel wouldn't be guaranteed to be able to actually do what EFI boot services does, in terms of getting the hardware back into its on-boot EFI-support state.
The kernel could emulate these states, by having its native drivers for these devices configure the hardware into states approximating their on-boot EFI-support states; but it would just be an emulation at best. And some devices wouldn't have any kind of runtime state approximating their on-boot state (e.g. the CPU in protected mode doesn't have any state it can enter that approximates real mode.)
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.
I don't like cheaters. If Tridge had done what he said he did, go him, I'm all for people being smart and figuring stuff out. But that is not what he did and it disgusts me that he pretends it is.
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.
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.
As I have seen over and over, when the open source people want something, they will twist themselves in knots to justify getting it, legality be damned.
How about you be better than this and admit that open source is not without its skeletons?
>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.
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.
If a shipping provider loses shipment and refuses to respect the insurance agreement, it sounds like they should be sued for damages. The damages are much more than the cost of the shipment, as the loss itself also undermines operations and causes a lot of financial downside.
In some jurisdictions, the losing side will have to cover the cost. In some jurisdictions there are also small claims courts, which do not need legal representation.
It’s clear that it caused financial distress whereas as happy paying customer I want SourceHut to continue existing.
The reality is that actually getting your rights is often an enormous hassle, in terms of time, money, and/or stress.
If you're BigCorp™® with a Lawyer Department then that's not really a problem: you just send it off to the lawyers and continue with your day. If you're a private individual and/or small business: it very quickly becomes a trade-off.
So imagine SourceHut sues. And they win. And losing shipping company has to pay all of sourcehut's fees. There is a very real non-zero chance they will just say "lol nope, fuck you". And then what? Basically nothing you can do about it. Even in domestic cases this is true, international cases even more so.
In reality a lot of the world runs on goodwill and voluntary adherence to the rules, with not all that much little stopping bad actors from abusing things.
I part agree, but that goodwill and adherence also exist thanks to people who are willing to exercise their rights. A shipping company that suddenly can’t operate in a profitable country because they are in violation of court order will lose a lot of money; chances are, they like money.
Yes, I agree; see e.g Alan Bates for a famous example. But I don't think anyone could be faulted for not being Alan Bates and just moving on with their life.
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'm not sure that this is true, at least not the commercial part. Redis clients are pretty simple (compared to Redis itself, at least).
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).
> 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 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.
Your belief is incorrect. The links you have provided do not provide any data on actual use of these databases in the industry.
I've been working in the MySQL/MariaDB ecosystem for 21 years and am the creator/maintainer of a MySQL and MariaDB specific schema management utility used by hundreds of companies and with over 1.6 million downloads to date. I can tell you conclusively, MySQL usage in the industry significantly exceeds MariaDB's.
While I personally enjoy both systems and do hope MariaDB adoption increases, this doesn't change the facts on the ground. And unfortunately MRDB is a penny stock, Azure is dropping their managed MariaDB offering, Vitess has dropped MariaDB support entirely, AWS Aurora is compatible with MySQL and not MariaDB, Percona Server is based on MySQL and not MariaDB, and so forth.
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).
Yes, I mentioned the losing ground to Postgres aspect in my original comment. But that affects both MySQL and MariaDB, and still does not cause MariaDB to somehow be more popular than MySQL.
As for both working with anecdata, I mean sure, but what else is there? I'm citing my own business's direct experience with MySQL users and customers significantly outnumbering MariaDB users and customers, and seeing clear signs of that trend also being true at several much larger businesses (AWS, Azure, Percona, PlanetScale).
I suspect your view may be skewed by Linux distros / package managers having replaced MySQL with MariaDB many years ago. But even that is starting to change, see https://lwn.net/Articles/960630/ for example.
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.
I wish you the best of luck and when I am able to be involved with OSS again, I will gladly help out with Redict. I think the LGPL is a good choice.
Areas where I would personally want to see Rust in a project like this, a) parsing and talking with the network b) extension mechanism moved to Wasm (Wasmtime for execution) but that plugins would be moved into a Wasm container.
It would also be a nice property if the core of the project maintained a compile to Wasm compatibility so that Redict could be run everywhere.
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.
THANK YOU, for making images based on scratch, rather than Debian or Alpine. It makes redistribution so much easier from a license compliance perspective.
And double thanks for providing an SPDX document for the contents of the image.
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.
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 (see the comments on http://antirez.com/news/121 )
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?
>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 :)
