The email git flow could definitely be better and having the patch added as a regular patch file shouldn’t break things (setting up git-send email was surprisingly cumbersome with email security settings and such). Hopefully they are able to improve (like the normal industry git repos) or at least add a compatibility layer that makes their existing setup work with a web interface for managing commits (I’d like to close/merge two broken issues I made and either I don’t have permission for email commands or I don’t know the proper syntax, so now I’m waiting for it to just expire).

From the article this has lead a group to reverse engineer the proprietary board and start a Kickstarter to make it more accessible, which is pretty exciting (hopefully Apple doesn’t find a way to kill it)

I’m not too bothered by the IRC, it is a bit annoying not being able to get messages/responses while away (unless you rig up something to stay connected), I haven’t tried the mailing lists yet (other than the ones used as part of the Guix patching process (which Guix does provide a nice UI for with issues.guix.gnu.org), but it was a real pain connecting git:send-email as a first time user for the send-email part. There is supposedly some new tool called Mumi, but I haven’t tried it yet.).

I don’t see what you mean about the IRC being a walled garden? It did take a bit more work to connect than registering for Reddit, but I’d say it is comparable to the effort of joining Lemmy (but without the nice persistence of Lemmy). Another reason they might have for not wanting to add more communication channels is maintainer fatigue, every communication channel they officially add has to be watched by someone; and if all their maintainers are comfortable with something else, they will have to take time out of their day (with them already likely being volunteers) to monitor the new channel.

Dang, I had no idea and never thought to inspect it; thank you for pointing that out, now maybe I can finally figure out how to nicely shutdown from the terminal

The concern for code duplication is valid, but as the article mentioned it is also a while off until the Nova project is mainlined. I honestly never thought of how the work to bring in Rust to mainline may in effect lead to a more complete deprecation of older hardware as we start to change API’s older/unmaintained components aren’t updated. On the flip side, trimming out older stuff might save maintainer work going forward.

What I mean with shutdown, is the flags have changed (So, I can’t do ‘shutdown -hP’ or ‘shutdown -hP now’)

I had no idea on the manual version tag, I’ve probably been using an old one for a while… Thanks for pointing that out.

Ya, when it comes to modifying a Guix config, I haven’t gotten used to all the guile commands and different system names that guix uses, maybe eventually I’ll learn the semantics.

I’d add that it might not hurt to expand the build farm again so that the build system (cuirass) can mark submissions as ready faster (I’ve currently got a few patches that I need to ‘bump’ as it seems they have been skipped over and are now ignore since they are several months old now…)

I miss ‘systemctl poweroff’ (haven’t learned the new herd equivalent); also, ‘herd --help’ doesn’t really give any useful information and only lists a few things you can do… Have to really dig into the documentation (someday). Also, the ‘shutdown’ syntax has changed… Otherwise, most stuff has gone well

Have you considered reaching out to folks on the IRC for feedback? These issues look to have been open for a while, so the automated build farm has likely forgotten them; I’d love to have a mainlined approach for Podman

For my non-guix (and foreign) systems I’ve switched to Podman, but for Guix System I’ve fallen back to Docker as I haven’t gotten up the time and courage to deviate too far from the documented/mainline approach so that I can use Podman; hopefully they’ll get some updates to address’s it

Ya, this (if active) looks like it would be a more approachable version of Guix for many folks

Kinda cool, I like the config generator; too bad there isn’t a sway or hyperland one so that I can copy it for my system.

Honestly, pretty effective, I used to balance the mattresses on my head when working in a dorm. Many societies used this approach to move things, and with three of them the have the definition of a geometric plane.

They could then potentially end up spending more time testing every possible combination of input then they would spending compiling with a strongly typed language that prevents the invalid syntax from compiling to begin with…

Honestly, this is maybe the most telling about where OP is coming from… If not straight up flame baiting; that or they mistook /r/rustcirclejerk as a serious subreddit

The constraint on memory isn’t on the compiler it is in the available ram and flash on ultra-lowcost/power microcontrollers, use can find some with less than 1KByte of ram, so that 32bit int could have been 4 8bit ints in your electric toothbrush. The packing of bits is space effecient, but not compute effecient and takes several extra clock cycles to finish when run on an 8bit microcontroller. It’s better to store it in the native 8bit word size for these devices. Further more, on more powerful systems using the smaller size can allow you to optimize for SIMD instructions and actually do multiple operations per clock beyond what you could do with the 32bit size.

There are reasons for these types to exist; as was mentioned elsewhere, if you don’t care you can always just use i32 or i64 for your code and be done with it.

Soooo, an int in most architectures is actually signed, usually a 2’s compliment signed 32 bit value; but the spec does not require it to be 32bits, some platforms might use an 8 bit or 16bit value instead (think older 8bit microcontrollers). That’s why they have ‘int32_t’, ‘uint32_t’, etc for C/C++, it just sounds like you haven’t used these number types (check stdint.h). Rust just requires you to use the more explicit number format by default (which I personally prefer because I have had to jump between embedded and Linux development).

The multiple string types are annoying at first, but its probably better to realize that they are more like two types (String and str) with the apperstand (&) ones being references (think pointer in C/C++). A String is like a C++ std::string and a str is more like a C-String (fixed sized array ish of chars).

Enter embedded programming, believe it or not there is a ton of low level C code being written; also, try adding a new protocol for networking, there are many cases where bitstructure matters, I recently wrote a small bit of code for a project that used bit packing so that we could fit inside of a single Ethernet frame so that we didn’t have to deal with fragmentation and the networking overhead it caused.

For context, what is your past programming background and what are you trying to do? While rust is a great language, it may not be the right tool for what you’re trying to do if these are things that you view as unnecessary

A reason to not distribute a library as a binary is for cross platform support, this allows a library to technically be compiled and used in some other platform; with that said, there are assumptions about having the same system calls (or that the library only handles abstract things that don’t hook into a specific architecture), with that said, making cargo smarter and adding in the option to bundle some prebuilt libraries to be pulled for compatible platforms could speed some compile time (at the likely cost of build size, etc).

Distributing a library as source isn’t some weird rust paradigm, take BOOST for example, which is a large library for C++, and is usually distributed as source (but Linux distros may bundle prebuilt binaries; it is generally intended that you will compile it and use it as a shared library), actually a lot of compiled languages distribute their libraries as source, it also allows you to read their source if you need to see exactly how they’re doing something). I don’t believe there is anything preventing someone from using shared libraries in rust, although they do seem to be less common. Another reason to distribute a library as source is for licensing.

The unstable versioning… Ya, that is definitely annoying, and likely tied to the limited resources available for sustainment for various projects. With that said, compared to C/C++ many of these libraries are something that one might role their own or use in house libraries. Now for Tokio… You don’t have to use it for async, although you probably will want to (see: https://blog.poespas.me/posts/2024/05/24/rust-async-std-and-tokio-comparison/), I do wish there was a nice way to depend on a library and substitute some of its dependencies (aka Tokio); with that said, part of the cargo idea is that you don’t view these libraries as part of your source code for review (although, auditors would likely disagree, so acrediting with the inclusion of many in accredited libraries would probably not be fun)