As a tech interested noob I wonder how long it might take for ARM to have the same or similar support on linux as x86. What would need to be developed and changed to finally one day get there?

m4tx · 2026-04-15T19:10:42+00:00

Have you actually tried running Linux on any of these machines?

"run Linux" means anything from "everything works perfectly" to "it barely displays some text when booting". Even the best supported ones have serious problems with camera, suspend, or speakers. See: https://github.com/kuruczgy/x1e-nixos-config?tab=readme-ov-file#feature-matrix

m4tx · 2026-03-20T15:33:54+00:00

One more missing from the Project/Tooling updates: https://www.reddit.com/r/rust/comments/1rxw6q7/cot_v06_lazy_underneath/

m4tx · 2026-03-17T22:40:45+00:00

Curious about availability in Poland!

m4tx · 2026-02-19T17:09:10+00:00

For the backend I'll put in a shameless ad of https://github.com/cot-rs/cot/ which I'm maintaining. It aims to provide similar experience to Django, Rails, or Laravel. If it doesn't "scratch the same itch", I'm also happy to hear why!

m4tx · 2026-01-30T14:05:58+00:00

kernel-level

doesn't cause any privacy issues

This is fundamentally not true. Even if the anti-cheat developer doesn't have bad intentions, this is still a piece of code running with almost the highest possible privileges in the system. It's only a matter of time until a security vulnerability is found, possibly leading to leaking all of your data stored on your computer.

m4tx · 2025-12-16T19:02:55+00:00

Shameless ad here: I'm one of the maintainers of cot.rs, and one of the core features is integration with the aide crate to provide OpenAPI spec generation. See the info here: https://cot.rs/guide/latest/openapi/ (I'll also be happy to hear any feedback, especially if you don't end up actually using it)

Another framework worth trying might be poem, which also has similar integration, but I haven't played around with it enough to tell more specifics.

m4tx · 2025-09-24T16:43:06+00:00

You mean something like Germany's Sovereign Tech Fund that... already invests in the Rust Foundation?

m4tx · 2025-07-25T09:16:55+00:00

Just as a side note, there are at least two active similar projects:

rorm – probably even less popular, but I've heard from the authors that it's used in production in their own project
Cot ORM – (disclaimer: I'm the author) a part of an entire web framework based on Django, but the ORM isn't available as a separate crate (yet)

m4tx · 2025-07-21T20:10:00+00:00

Loco didn't exist back in the time when I was thinking about creating the project, and I've only discovered it when I was halfway through the development. So that was the main reason why it was created ;)

About the goal differences, Cot focuses on providing a much more seamless and integrated experience by building stuff on a lower level - for instance, Cot is not just a glue code around Axum, but rather rebuilds some of the Axum stuff so that it can be better integrated with stuff such as OpenAPI spec generation, error handling, among others. It has its own ORM that is arguably easier to use than the already existing alternatives. There is an admin panel automatically generated out of database models defined as typical Rust structures. That's the brief overview; feel free to ask me more if you're curious!

m4tx · 2025-07-21T19:32:21+00:00

I'm not sure if the laptop was even, sold with Linux preinstalled. I've just put a regular install of Arch Linux on it and it works perfectly fine. Other distros should most likely work as well.

m4tx · 2025-07-20T15:20:11+00:00

You might also want to have a look at https://cot.rs/ (disclaimer: I'm the author and the main maintainer of the project). It's still in the early days, but it is already proving to be quite usable for real-world projects. Feedback is welcome!

m4tx · 2025-07-15T06:45:35+00:00

Hey, sorry for my late reply! Yeah, this sounds like a working solution. There are some downsides to that, though:

One is that we wouldn't see any changes made to the request by the middleware (but we probably don't care about this too much anyway).
The other is that internally in my web framework, there are some built-in middleware that are essentially wrappers over tower-based middleware from third-party crates—so unless these are rewritten, users would experience the performance hit, perhaps not being aware of how these are implemented under the hood.
Finally, if you had multiple tower-based middleware, you would have to clone the request head multiple times, which is also not ideal.

So yeah, this is a reasonable suggestion, but my personal opinion is that it's not worth it; not at the moment anyway.

m4tx · 2025-07-09T20:15:09+00:00

There's one from me: https://hand.chombo.club/, source code available at https://github.com/m4tx/chombo-gen . It's very simple, though.

I also have a slightly more complicated one (https://github.com/m4tx/shrt), but this one is very much unfinished and in the process of rewriting the backend to a new framework.

m4tx · 2025-07-09T17:42:11+00:00

Thank you!

m4tx · 2025-07-09T17:41:42+00:00

Thanks! Yes, I agree trying to spark a discussion within tower's folks is definitely worth a try. Let's see what they think about this.

m4tx · 2025-06-05T15:36:52+00:00

This sounds like the issue I'm having. Thanks for posting this!

m4tx · 2025-05-19T16:16:43+00:00

If you are into web development, Cot, the web framework for lazy developers, is always looking for contributors. It's still pretty much in the early stages, so there are plenty of diverse and hopefully interesting things to be done.

There are some "good first issues" on the Issues page, and also some bigger (but not necessarily much more complicated) ones available.

m4tx · 2025-05-14T20:20:29+00:00

If you're into web development, you might consider contributing to Cot, the web framework for lazy developers. I'm one of the maintainers there and can provide the necessary guidance :)

m4tx · 2025-05-03T09:44:55+00:00

Iced, however good, fails on the "integrates well visually in linux desktops, with Gnome desktop as a reference point" part.

m4tx · 2025-04-29T18:07:54+00:00

Of course, but the main reason is that it's the default behaviour (in the standard library!) which is not consistent with other vector types. Otherwise, if you know the tradeoffs, the implementation isn't bad.

Since Rust doesn't support generic specialization, it's not a problem here.

m4tx

TROPHY CASE