Drew DeVault
A motivated group of Rust developers could build a production ready mostly Linux-compatible kernel from scratch within 5 years without doing any politics on LKML
Passionate 3-4 person hobby OSes have achieved impressive levels of Linux compatibility very quickly. Pour the level of enthusiasm that Rust-in-Linux has into a greenfield project to build a Linux-compatible kernel and you would have astonishing gains very quickly.
:blobcatflower:
feld
Drew DeVault
@feld not really. I re-iterate my request for everyone to shut up about drivers already
feld
Drew DeVault
@convexer it depends on the roadmap and target audience. Rust-in-Linux is an attractive target because everyone already uses Linux and they can get Rust into everything by making their play there. But it's an uphill battle and I think it's overall a bad idea; I blogged about this before and my opinions have been refined a bit since (more thought + watching how it's developed).
Making a new OS which is Linux-compatible would be much, much easier and faster.
Drew DeVault
Making a novel OS design is hard (Redox is trying) but if you are aiming to match the design of an established system and maximize compatibility then it's much, much easier.
convexer
@drewdevault I'm inclined to believe you, but isn't there a case to be made that trying to stay in-tree is the "noble" course of action because it avoid splintering off development effort and forcing users to make a tough choice of when to adopt the new solution?
Martijn Braam
@drewdevault I wonder how long it would take for a rust kernel to compile when it's the same size as the linux kernel.
Drew DeVault
I think there needs to be some time to heal but the Rust-in-Linux folks should really rally around a new Linux-compatible kernel project from scratch. It'd be wild. It would probably actually work, whereas Rust-in-Linux is still a huge gamble and a burnout machine.
Drew DeVault
Rust would be a really good fit for a big Linux-style monolithic kernel and they could realize a lot of gains very, very quickly IMO. Not a great fit when retrofitted onto the Linux establishment.
aeva
@drewdevault RIIR HURD! RIIR HURD!
Drew DeVault
Anyone coming in to @ me with bad-faith insults targeting Rust developers is cruisin' for a blockin'
Drew DeVault
I'd like everyone to shut the hell up about driver compatibility. Seriously. It was an incredibly fucking annoying argument when Linux didn't have a competitive driver suite, too, and somehow we still managed to get to the point where Linux does have great driver support.
Fuck's sake. You write the drivers you need and then use the hardware that's supported, and if you want to support new hardware you write new drivers, you do not need to implement every driver overnight.
Haelwenn /элвэн/ :triskell:
@drewdevault @lucy @duncan_bayne In fact for a kernel I'm pretty sure AGPL "13. Remote Network Interaction" would mean everyone who made modifications would be violating it the moment there's network drivers, or would be rendered nil and so would just be GPLv3, albeit a confusing one.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version […]
Drew DeVault
@lucy @duncan_bayne I'm not this AGPL maximalist where I believe we need to put it into everything. Licenses have use-cases. And for a kernel AGPL makes zero sense. EUPL is a slightly better argument but even then, I don't think that strong of copyleft is well-justified for a kernel project. My kernels are GPL.
Drew DeVault
@duncan_bayne no, GPL is the right choice. GPL 3 probably, but tbh I get Linus's preference for GPL 2.
:blobcatflower:
Duncan Bayne
@drewdevault Please for the love of all that's holy, AGPL it though
Drew DeVault
@deetwenty exactly. 100%
If you get a decent filesystem and a few network drivers (even virtio) and good POSIX support you're in the datacenter too
Botch Frivarg
@drewdevault especially for something niche starting with basic platform drivers, nvme (or alternative like ahci), and basic framebuffer (uefi based?) support, should be plenty for a lot of interesting projects, and provided it is architectured correctly a pretty good base for further expansion
Drew DeVault
Case-study: Tilck
https://github.com/vvaltchev/tilck
Written by one person mostly over the course of about three years in their spare time and it's ABI compatible enough with Linux to run busybox, vim, tcc, lua, micropython, fbdoom -- from unmodified Linux binaries, not source ports
Haelwenn /элвэн/ :triskell:
:blobcatflower:
Drew DeVault
Another one: Managarm
https://github.com/managarm/managarm
Does not aim for ABI compatibility with Linux but has implemented a lot of Linux-specific APIs to great success, including DRM (Direct Rendering Manager), epoll, signalfd, etc, and is capable of running software like Sway
Small group of 4-5 principal contributors working slowly but surely since 2016
Haelwenn /элвэн/ :triskell:
feld
Drew DeVault
@m I'm enthusiastic about Redox but it's a huge gamble and it will require a lot of highly specialized work and frequent revisions of fundamental design assumptions before it starts getting anywhere useful -- and once it gets there, it's not necessarily certain that anyone will use it for anything. It's a novel OS research project. Whereas using the Linux kernel design from the outset gives you a fixed scope and saves you all of the research work and we know it works when it's done.
m_on_stair
@drewdevault@fosstodon.org why not rally behind redox?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.