Rust-for-Linux VS linux

You're welcome.

> Any concerns of the same kind of thing?

Here's the canonical list: https://github.com/Rust-for-Linux/linux/issues/2

There's a lot, and I don't know the status of many of them, personally. But I don't see anything there that I know is not gonna work out, like for example, they aren't using specialization. Most of it feels like very nuts and bolts codegen options and similar things.

That said, back in August, the Rust Project announced their goals for the second half of this year: https://blog.rust-lang.org/2024/08/12/Project-goals.html

They say that they're committed to getting this stuff done, and in particular: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st...

> Closing these issues gets us within striking distance of being able to build the RFL codebase on stable Rust.

So, things sound good, in my mind.

The goal of rust for linux isn't to wholesale translate linux into rust, but simply to be able to write pieces of linux (largely new ones) in rust. I think it's very unlikely anyone (including google) will take on a wholesale translation anytime soon. That said

> It's unlikely that Google has much sway here

Google has helped fund the rust for linux project pretty much from the start [1], they're one of three organizations mentioned on the homepage due to their sponorship [2]. They're actively involved in it, and have already ported their android "binder" driver into it with the intent to ship it in android. This strikes me as a very weird take.

[1] https://www.memorysafety.org/blog/supporting-miguel-ojeda-ru...

[2] https://rust-for-linux.com/

Rust is backwards compatible when you stick to stable features, but the kernel uses unstable features that can and do incur breaking changes.

https://github.com/Rust-for-Linux/linux/issues/2

> How would this work?

Don't know exactly what you're asking.

> And why would it be a better idea?

Poorly written device drivers are a significant attack vector. It's one of the reasons Linux is now exploring using Rust for its own device drivers.[0] You may be asking -- why Rust and not some other language? Rust has many of the performance and interoperability advantages of C and C++, but as noted, makes certain classes of memory safety issues impossible. Rust also has significant mindshare among systems programming communities.

[0]: https://rust-for-linux.com

Rust-for-Linux issue tracker

The latest kernel as of today still supports the 486SX ! (https://github.com/torvalds/linux/blob/v6.17-rc1/arch/x86/Kc...)

11k defines is nothing, the files in nbio are so big, github even refuses to parse them:

https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

That's 38900 lines worth of defines.

struct page in Linux is this taken to its logical conclusion.

https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317...

- https://github.com/torvalds/linux/blob/master/Documentation/...

> Electron Performance Crisis: Modern email clients built with Electron and React Native suffer from severe memory bloat and performance issues. These cross-platform frameworks, while convenient for developers, create resource-heavy applications that consume hundreds of megabytes to gigabytes of RAM for basic email functionality.

No (real) customer has ever, or will ever, care about this. Discord and Slack are pretty much case-in-points: bloated Electron apps that just about everyone on the planet has installed on their computers. I personally hate React, but technology decisions are irrelevant to the long-term success of startups. (As long as they don't grossly interfere with customer experience, the feature set, etc.)

> Final Warning: After analyzing hundreds of email startups, the evidence is overwhelming - 80%+ fail completely. Email isn't broken, and trying to "fix" it is a guaranteed path to failure.

First, I'd bet money that figure is actually wrong: the failure rate is likely way higher than 80%. And I'm honestly not sure how anyone could seriously think a 20% exit rate is bad in just about any vertical (but especially a "boring" one like email).

> Resources: Volunteer developers can't sustain enterprise-level software

What am I even reading here? Author does realize openssl[1], Linux[2], and many other "enterprise-level" pieces of software are entirely (or almost entirely) maintained by volunteer developers, right?

Anyway, the post had its opposite intended effect on me: it made me think about ways I could reinvent email.

[1] https://github.com/openssl/openssl

[2] https://github.com/torvalds/linux

Yeah, it's very easy. Real devices usually adhere to the specs.. only very few exceptions: https://github.com/torvalds/linux/blame/master/drivers/hid/h... .. /s

What is the source of “Firefox Moves to GitHub”? It could just be a mirror, just like Linux also has an official mirror on GitHub.

https://github.com/torvalds/linux

It's basically the same in the x86 world : your bios is customised to the board

The sad part is that on ARM the kernel is usually also custom compiled for the board.

If you go and look in https://github.com/torvalds/linux/tree/master/arch/arm you see a zillion "mach-xxx" directories for different SoC architectures, even if they all use Arm.

Device-tree is a partial solution, but no-one seems to have an incentive to finish the job and let a single image run on any (sufficiently recent) arm board. It's difficult for the community to fix because most people have only their own board. Someone would need to pay for a CI rig with every board, and some kernel devs to do the work of building a single kernel to run across everything.

Linux is a open source OS Kernel Unix based created by Linus Torvals in 1997 and released on GitHub and this OS turn so popular because is 100% free to download, make your own OS called Distro(Distribution or Linux Distribution) and every Distro are ruled to be Free and a lot of Linux based Distros was make, the most popular is :