My current laptop I bought used and didn't realize that HD wasn't 1080p, but rather 720p... (1080p is apparently FHD), whoops. I'm currently using a Latitude 7290 for reference and it more than meets all my regular needs (other than the screen resolution...). I have been using a tiling window manager and moving to apps that don't waste as much space on my screen to try to help compensate.

Assuming Desktop is 1080p is probably reasonable, but there are a ton of good used business laptops that are still 720p, so it's probably going to stick around for a while (also, why encourage e-waste).

For reference, my laptops specks are:

1. i7-8650u
2. 32 GB RAM
3. 2TB SSD

As long as I stay out of VM's and do my development in lightweight editors and containers, this hardware could technically last me a while (also, I think the 7x90 series Latitudes are some of my favorite laptops).

Looks like they've posted a Guix user survey: https://guix.gnu.org/en/blog/2024/guix-user-contributor-survey-2024/ It sounds like they may be looking for feedback

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

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