Comment by hexagonal-sun

Yeah, for example embassy-rs is an RTOS that uses rust async on tiny microcontrollers. You can hook task execution up to a main loop and interrupts pretty easily. (And RTIC is another, more radically simple version which also uses async but just runs everything in interrupt handlers and uses the interrupt priority and nesting capability of most micros to do the scheduling)

I find it interesting that this fulfills some of Dennis Ritchie's goals for what became the STREAMS framework for byte-oriented I/O:

> I decided, with regret, that each processing module could not act as an independent process with its own call record. The numbers seemed against it: on large systems it is necessary to allow for as many as 1000 queues, and I saw no good way to run this many processes without consuming inordinate amounts of storage. As a result, stream server procedures are not allowed to block awaiting data, but instead must return after saving necessary status information explicitly. The contortions required in the code are seldom serious in practice, but the beauty of the scheme would increase if servers could be written as a simple read-write loop in the true coroutine style.

The power of that framework was exactly that it didn't need independent processes. It avoided considerable overhead that way. The cost was that you had to write coroutines by hand, and at a certain point that becomes very difficult to code. With a language that facilitates stackless coroutines, you can get much of the strengths of an architecture like STREAMS while not having to write contorted code.

Ok, I see. I spent a lot of time with .Net VMs, where you cannot simply separate await from the heavy machinery that runs it. I now understand that in a kernel context, you don't need a complex runtime like Tokio. But you still need a way to wake the executor up when hardware does something (like a disk interrupt); but this indeed is not a runtime dependency.

EDIT: just found this source which explains in detail how it works: https://os.phil-opp.com/async-await/

There’s got to be some complexity within the executor implementation though I imagine as I believe you have to suspend and resume execution of the calling thread which can be non-trivial.

Original author of smoltcp here! I couldn't have imagined how much of a cornerstone of the Rust ecosystem it would become. Very excited to see it get used like this, and yeah, #![no_std] use cases were the original and primary motivation to build the stack in the first place.

Great, an MIT license to accelerate planned obsolescence and hardware junk. Truly a brilliant move

> There’s an LLVM fork for every esoteric architecture now

Can you provide examples of these? I'm aware of temporary forks for things like Xtensa, but these typically get merged back upstream.

Seriously.

To the author: kudos for the interesting project, but please strongly consider a copyleft license moving forward.

While the FSF's vision for the GPL is clear, the GPL itself is not so powerful that it is more than a "gift" that has some terms if you want to do certain things you are not obligated to do. It is like a grant that enforces some reasonable conditions so the money isn't just misappropriated. I wouldn't give that to a friend for their birthday, but I think it's reasonable that powerful organizations should not be free to do whatever they want. Not that the GPL is perfect for that use, but it's good.

> It's more like a contractual agreement with something provided and specific, non-negotiable obligations.

The obligation is not to the author of the code, it is to the public. MIT-style licenses are gifts to people and companies who produce code and software, copyleft licenses are gifts to the public.

I don't give a shit about the happiness of programmers any more than the happiness of garbage collectors, sorry. I don't care more that you have access to the library you want to use at your job writing software for phones than I care that somebody has access to the code on their own phone. You're free to care about what you want, but the pretense at moral superiority is incoherent.

It is non-negotiable. GPL is basically proprietary software. It's owned by the public, and all of the work that you do using it belongs to the public. If you steal it, you should be sued into the ground.

MIT is throwing a free party where food and drinks are paid for, and copyleft is where food is paid for but you BYOB. Both are fine, so what's the problem?

I agree, and even if a company doesn't give back, they further the popularity and sustainability of the project. Isn't Python an MIT-like license (PSFL)? As well as React and Godot? And Tensorflow is also permissive with Apache 2.0, corrrect?

A gift where the recipient can remove the freedoms that they've been enjoying themselves is a bad deal for ensuring those freedoms are available to everyone. A permissive license is a terrible idea for a F/LOSS kernel.

This is the paradox of tolerance, essentially.

Also, seeing F/LOSS as a "gift" is an awful way of looking at it.

Thay "holier than thou" attitude from BSD/MIT proponents seems like some kind of ego talking. Freedom to deny others the freedom you had is not noble.

GPL is a gift that keeps giving.

No, but if someone takes the free food and builds a business by selling it to others, without giving anything back to the original places, it harms everyone other than the person doing that.

F/LOSS is not a charity or a gift, so your analogy is not appropriate. It is a social movement and philosophy with the goal of sharing knowledge and building software for the benefit of everyone. It invites collaboration, and fosters a community of like-minded people. Trust is an implicit requirement for this to succeed, and individuals and corporations who abuse it by taking the work of others and not giving anything back are harmful to these goals. Copyleft licenses exist precisely to prevent this from happening.

MIT is a fine license for many projects, but not for an operating system kernel.

yes

>> I take this as an oblique critique of TFA's choice of license. What's it to you? Why must we all use the GPL always in order to satisfy busybodies?

Thank you for reading it correctly. I originally had a </sarcasm> to make sure nobody thought I liked the license choice. What's it to me? Well someone posted it to HN here so we could comment on it, so I did.

I think the MIT license has its place, but IMHO it does not belong on an OS like that. Reason is indicated in my original comment.

This has been discussed ad nauseam and this adds nothing new. There's value in the memory safety for the majority of the code even if there are some escape valves ("unsafe" keyword, assembly).

There are no programs written in 100% safe Rust—the std library is written with unsafe as needed. But typically the majority of lines in the program—sometimes even all outside std or some well-audited foundational creates—are safe. Those lines can not directly cause any unsoundness, which has tremendous value.

Correct me if I'm wrong, but I think all of these are solved problems.

LGPL should only pose a problem if you explicitly want your program to be used with non-free software. And then only if said non-free software doesn't give you a way to rebuild it yourself, should you want to modify the LGPL program. (So not a problem for open-core or public-source projects, either.)

If, for some reason, you insist on allowing static linking for all the projects, I think the MPL allows this. (People often seem to think of the LGPL, but it's not the only weak-copyleft licence around.)

Otherwise, when releasing your project under GPLv3+, you don't have to put blind faith into the FSF; you can designate a proxy which will decide whether the new version should be allowed for your project or not. This proxy can be yourself, or it can be a different organisation you choose to trust. Plus, I'm pretty sure the GPL allows you to make linking exceptions of your liking.

A derogatory term for copyfree licenses

Permissive license + complaining when companies don't contribute back from their forks.

It’s a play on “permissive” license.

'Pushover licence' is a licence which may grant freedom, but doesn't care to protect it. One may modify software under a pushover licence and release their modifications as non-free software. Another, more common name is 'permissive licence'.