Rust-Written Redox OS 0.8 Released With i686 Support, Audio & Multi-Display Working

[Developer12]

I2C is NOT SMBus. There are only I2C to USB bridges, not to PS/2. The MAX7311 is an industrial breakout controller, much like a USB dock controller. Nobody uses these for modern laptop touchpads because they're not compatible with the permitted touchpads as part of the Windows logo certification, which every major tier-1 and tier-2 OEM makes their laptops for. The evaluation kit is only designed for Windows compatibility up to Windows Vista. I would hardly call that something modern. ISA is also not accepted in the Windows Logo certification program and hasn't been for many years, since at least Windows 8.0 shipped 10 years ago.

I2C vs SMBus | Differences & Similarities (evision-webshop.de)

Application Note 6.17: Definitions & Differences Between 12C, Access.bus & SMBus - SMSC (microchip.com)

Clearly nobody told you that I2C is a commonly used euphemism for SMBus.

In the age of UEFI SMM drivers, nobody gives a shit about Windows Logo Whatever. They just emulate.

[Danielsan]

I think Redox is a great project made by a bunch of extremely talented dudes, it would be cool watching S76 selling hardware with Redox pre-installed!

[Waethorn]

Clearly nobody told you that I2C is a commonly used euphemism for SMBus.

In the age of UEFI SMM drivers, nobody gives a shit about Windows Logo Whatever. They just emulate.

Except for every name brand PC OEM shipping right now that doesn't exclusively bundle Linux, meaning about 95% of PC's on the market, with Mac's making up the majority of the rest. PS/2 and ISA are not used in these. And I2C still isn't the same as SMBus. Read the docs on the links. Even going back as 2004, they show the differences between I2C bus and SMBus. They aren't the same technology - never were. It's like claiming USB "is the same as a Parallel Port". They're not. Stop pretending that they are, or that Windows logo certification isn't a major contributing factor to the way PC's are designed, to make an argument. You're just making yourself look silly.

[Waethorn]

I think Redox is a great project made by a bunch of extremely talented dudes, it would be cool watching S76 selling hardware with Redox pre-installed!

There's a lot more work that needs to be done with software compatibility and hardware compatibility before it becomes attractive to hardware OEM's producing new hardware. Redox would be better garnered towards low-end hardware because users can't be expected to embrace something with such a small ecosystem with high price tags included. Low-end hardware doesn't have to be out-of-date hardware though. You have options like low-cost Celeron and Pentium SoC's with bundled eMMC controllers for small, cheap storage drives that would fit well with an introductory hardware base for it. To solve the hardware support issue, they could just take the entire driver tree from one of the BSD's and build whatever API's they need to support and bundle the whole thing instead of trying to incorporate it piecemeal. UEFI is available on any x86-64 commodity hardware now. Trying to support ARM is a complete sh*tshow though, what with there not being a standard firmware or bootloader interface, and ARM System Ready is just not readily in use in practically anything. ACPI+UEFI+x86-64 would be the smart target for modern hardware. Anything else is absolutely outdated or a niche, and not worth selling unless you want to be just another niche player. Certainly not worth it if you're trying to start another OS platform. Linux took years before ARM was supported after x86.

[Developer12]

Except for every name brand PC OEM shipping right now that doesn't exclusively bundle Linux, meaning about 95% of PC's on the market, with Mac's making up the majority of the rest. PS/2 and ISA are not used in these. And I2C still isn't the same as SMBus. Read the docs on the links. Even going back as 2004, they show the differences between I2C bus and SMBus. They aren't the same technology - never were. It's like claiming USB "is the same as a Parallel Port". They're not. Stop pretending that they are, or that Windows logo certification isn't a major contributing factor to the way PC's are designed, to make an argument. You're just making yourself look silly.

Learn what euphemism means. People say I2C when they actually mean SMBus. There aren't a lot of other I2C-style busses in an x86 computer. This isn't an ARM SoC.

Nobody actually follows the standards microsoft sets out. No modern computer is modern, everybody cheats on compliance.

[Anux]

To get back to your question "what if a language enables you to use better algorithms that would have been to toublesome in other languages", I don't quite get what kind of algorithm would be "troublesome" to implement in C++?

Look at Mozillas servo project, they had massive trouble implementing it performant and threadsafe in C++. That's one of the reasons they supported/used rust, becuse thread safety is really hard in C++ but you get it for free in rust.

[ssokolow]

That's interesting. I'll certainly look into that problem a bit.

Most of my projects are single-threaded, or they have some minimal amount of multi-threading, so I wasn't thinking about that kind of a problem before.

In fact, "Quantum CSS" (Firefox's current CSS engine) is the Rust-written CSS code from Servo. As for "they had massive trouble implementing it performant and threadsafe in C++"...

By 2017, Mozilla had made two previous attempts to parallelize the style system using C++. Both had failed.

-- Implications of Rewriting a Browser Component in Rust

TL;DR: It's about how rewriting something in Rust doesn't obviate the need to watch out for reintroducing logic bugs when doing a rewrite.

[mmstick]

Truthfully, every algorithm and real world project with complexity is going to much more difficult to implement in C++ than Rust. There's a reason why Rust has been ranked as the most loved programming language by Stack Overflow for seven years in a row, and why people constantly rant about how productive they are with it. The mythical 10X programmer is just a normal programmer writing software in Rust.

[Waethorn]

Learn what euphemism means. People say I2C when they actually mean SMBus. There aren't a lot of other I2C-style busses in an x86 computer. This isn't an ARM SoC.

Nobody actually follows the standards microsoft sets out. No modern computer is modern, everybody cheats on compliance.

Everything you just stated is just completely unfactual.

[ssokolow]

Ok, now I have a question (in order to avoid reading a big pile of documentation, lazy me).

I need (at the minimum):
- friend classes and friend functions
- multiple inheritance
- "shared" multiple inheritance (virtual base classes)
- at least, all the features of generic programming (templates)
- constexpr
- lambdas
- generic lambdas
- concepts (type constraints on templates)
- something resembling the Boost library

What's the current status of Rust on each one of those features?

• All things within the same module (i.e. namespace) are effectively friends. A module can either be a file or a mod MODNAME { ... } block inside a file.
• Rust isn't a traditional OOP language and instead follows a design more along the lines of Haskell's typeclasses. Rust's trait system allows multiple inheritance and you can write default implementations of functions in a trait (like an abstract class), but Rust only does interface inheritance (eg. anything that implements Error must also implement Display). If you want implementation inheritance, you need to use a third-party crate like delegate. Traits are different enough from classical inheritance that it's better to just read up on them rather than trying to explain things point-form. On the plus side, you can impl your own traits on other people's types, which is how the Serde crate retrofits serialization and deserialization onto standard library types. Also, you can #[derive(...)] for various traits when there's a simple, obvious way to implement a trait based on the implementations of that same trait for the data type's members. (eg. #[derive(Debug)] will generate a debug formatter for a struct or enum which delegates to the Debug implementations of the fields and requires them to be present.)
• Rust has type-constrained generics and hygienic, AST-based macros for generic programming.
• Rust's approach to constexpr is that you can write const fn instead of fn when declaring functions if you only call functions or methods which are also const fn. Then, once you've explicitly promised that as part of your API using const fn, the function is eligible to be called in constant initializers. Every new release of Rust includes the announcement of a few more standard library functions/methods being made const.
• Rust does have lambdas. They're relied on heavily in things like the iterator API.
• Rust's lambdas are type-inferred (auto) by default but I've never needed to look into whether you can use generics when explicitly specifying type signatures.
• Rust requires type constraints on its generics. The caller chooses whether to monomorphize or use dynamic dispatch. (And you never have to worry about whether a struct is POD because the vtable is handled by using a (data, vtable) fat pointer, not by stuffing it into the struct instance.) If you want to use duck-typing, you have to use Rust's AST-based macro system or implement something yourself using the Any trait, which enables runtime-checked downcasting.
• The Rust ecosystem generally doesn't like big, monolithic libraries and attempts to create such "extended standard library" compilations have withered due to lack of interest, given the quality of the dependency management, including things like the cargo vendor command. However, the contents of Boost do exist. Here's a post I made nine months ago in response to someone else asking about a Boost equivalent. See also https://blessed.rs/