What really frustrates me about that, is that someone put in a lot of effort to be able to write these things out using proper words, but it still isn’t really more readable.

Like, sure, unsigned is very obvious. But short, int, long and long long don’t really tell you anything except “this can fit more or less data”. That same concept can be expressed with a growing number, i.e. i16, i32 and i64.

And when someone actually needs to know how much data fits into each type, well, then the latter approach is just better, because it tells you right on the tin.

Oh man, a zero byte long unsigned integer? Lots of languages represent it as an empty tuple these days (the “unit” type), but from quickly scanning the documentation, it looks like HolyC doesn’t support tuples, so I guess you gotta get creative…

Oof, I was just talking about making things declarative there. If you want to configure it the old-fashioned way, like you would on other distros, then those difficulties don’t apply.

In more general terms, though, it’s a bit of a double-edged sword. The Nix package repository has more packages than other package managers: https://repology.org/repositories/graphs

So, the chance of finding an obscure software, that’s already packaged, is rather high.
Here’s the online package search, if you want to check the availability of some of the obscure software you use: https://search.nixos.org/packages

But then, yeah, the flipside is that, from what I understand, you can’t just download a random executable off of the internet and run it, because of the Filesystem Hierarchy Standard not being adhered to, as the post also mentions.
You can set up Flatpaks, and I believe AppImages would work, because those also live in their own FUSE filesystem. Well, and there is ways to emulate the FHS layout to get normal applications to run, too.

But yeah, way out of my field of expertise there. I have only one software installed which isn’t packaged for Nix, which is a program I wrote myself.
And to get sufficient FHS emulation for that, I just needed this line in my config:

programs.nix-ld.enable = true;

More complex programs will need a bit of extra configuration: https://wiki.nixos.org/wiki/Nix-ld

(I could also add a flake.nix file into my software’s repository, though, which would make it so it could be installed straight from my repo, as if it was packaged.)

Screenshot the document, then paste it into a new document.

…I am just joking, I have no idea what they mean either. 🙃

Welp, I posted my hot take that impl Deref is similar to inheritance as a meme in !rust@lemmy.ml: https://lemmy.ml/post/42514248

Now, let’s see how many feathers get ruffled. 🙃

Oh wow, what the hell. I’m not actually familiar with C++ (just with Rust which gets similar reactions with the ampersands), but that’s insane that it just copies shit by default. I guess, it comes from a time when people mostly passed primitive data types around the place. But yeah, you won’t even notice that you’re copying everything, if it just does it automatically.

And by the way, Rust did come up with a third meaning for passing non-references: It transfers the ownership of the object, meaning no copy is made and instead, the object is not anymore allowed to be used in the scope that passed it on.
That’s true, except for data types which implement the Copy trait/interface, which is implemented mostly for primitive data types, which do then get treated like C++ apparently treats everything.

Yeah, I can understand the frustration. IMHO the Home-Manager way of doing things has some merits:

• You can (generally) manage the installation of packages together with their configuration.
• You can override individual configuration values for different machines (which I guess, you can also do via templating in chezmoi).
• Some programs don’t have a particularly readable configuration file or spread this configuration out over multiple files, or save all kinds of additional garbage into their configuration file which you don’t want to persist. Home-Manager can work around all these issues, and in such a case is likely also better documented than the original configuration file.

That last point is one that’s particularly relevant for me, because KDE Plasma’s configuration files are largely terrible. Home-Manager, together with Plasma-Manager, is the only sane way I know of, to automate the panel configuration in KDE.

But yeah, if you don’t use software with terrible configuration files, then I can certainly understand preferring dumb templating. I have also decided against using the Home-Manager-specific modules in places, or might only translate into the Home-Manager-specific module when I actually want to vary configuration values between two machines.

Just to give a quick impression of how terrible the KDE panel configuration is, this is a snippet out of the fittingly-called plasma-org.kde.plasma.desktop-appletsrc file:

[ActionPlugins][0]
MiddleButton;NoModifier=org.kde.paste
RightButton;NoModifier=org.kde.contextmenu

[ActionPlugins][1]
RightButton;NoModifier=org.kde.contextmenu

[Containments][1122]
activityId=f588743a-9bab-4f56-8f90-3616085ab6e0
formfactor=0
immutability=1
lastScreen=1
location=0
plugin=org.kde.plasma.folder
wallpaperplugin=org.kde.color

[Containments][1122][Wallpaper][org.kde.color][General]
Color=#79740e

Ah sorry, that doesn’t actually show any of the panel configuration, because KDE mixes configuration for the panel and desktop widgets and the Activities feature (like workspaces, but with separate wallpapers and widgets for each Activity) all into the same file.
So, here’s a snippet that actually shows the panel configuration, from just a few lines below the first snippet:

[Containments][1807]
activityId=
formfactor=3
immutability=1
lastScreen[$i]=0
location=5
plugin=org.kde.panel
wallpaperplugin=org.kde.image

[Containments][1807][Applets][1808]
immutability=1
plugin=org.kde.plasma.showActivityManager

[Containments][1807][Applets][1810]
immutability=1
plugin=org.kde.plasma.pager

[Containments][1807][Applets][1810][Configuration][General]
showOnlyCurrentScreen=true
showWindowIcons=true
wrapPage=true

[Containments][1807][Applets][1811]
immutability=1
plugin=org.kde.plasma.panelspacer

[Containments][1807][Applets][1812]
activityId=
formfactor=0
immutability=1
lastScreen=-1
location=0
plugin=org.kde.plasma.systemtray
popupHeight=432
popupWidth=432
wallpaperplugin=org.kde.image

What those numbers in e.g. [Containments][1807][Applets][1812] are? Ah, they just count those from 0 to infinity, whenever you add a widget through the UI.
And in case you were wondering since when INI allows for nesting section keys via [multiple][brackets]: It doesn’t. That’s a custom extension of the INI format, specifically in use by KDE.

Like, man, I love KDE for its features, but this is the stuff of nightmares.

I guess, if you come from garbage-collected languages, you might be used to not needing the ampersands, because everything is automatically a reference in those…

Ah yeah, via deref coercion, which is also called “auto-dereferencing” at times. Not to be confused with “auto-referencing”, which is also a thing^[1].

You can do some wild shit with deref coercion. And when I say “wild”, I guess, I’m talking about the most normal thing for Java devs, because well, it’s a lot like inheritance. 😅

Basically, this concept of being able to pass &String into a parameter that takes &str also applies to the self parameter. Or in other words, methods implemented on str can also be called on String, as if String extends str.
And well, obviously you can also make use of that yourself, by writing your own wrapper type. You can even “override” existing methods in a sense by re-defining them in the wrapper type.

I had to play around a bit with it myself, so here’s a playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=af65ed396dec88c8406163acaa1f8f8d

The rule of thumb I always tell people is that they should generally put owned data into struct fields and references into function parameters.

Seems like there’s now an option for that in Home-Manager: https://nix-community.github.io/home-manager/options.xhtml#opt-wayland.windowManager.sway.config.keybindings

But yeah, if you tried to use it when Sway wasn’t yet well-supported, or just want to use some obscure software in general, then yeah, things can get more complicated…

I mean, you don’t really need a fork for that. Anyone who’s motivated to actually improve the situation here, can just write appropriate documentation.

I guess, a fork would give you a new name, and therefore a clean slate where there’s not loads of contradicting information already out there. But yeah, that’s also a lot of work…

In my experience, this happens in two ways. Yeah, sometimes a senior just overdoes it due to a lack of experience or shitty requirements or whatever.

But it also happens a lot that juniors just don’t understand why the layer makes sense to introduce. For example, juniors will readily intermix IO and logic, because they don’t yet understand that this makes code untestable and adds a load of additional complexity into already complex logic code. From that viewpoint, pulling all the IO code out will look like unnecessary complexity, when it’s not.

Well, advertising is more or less a zero-sum game. Showing more ads to someone does not mean they have more money to spare.
So, there’s only so many slices you can cut the advertising cake into. And this concept just feels like someone is spending far too much money for far too small of a slice, for them to be able to make that money back.

Well, and the nozzle company did go bankrupt as someone else commented, so I guess, that answers that question either way…

Well, it’s largely legible, so yes.

One time, I was staring at a piece of code for a solid 10 minutes or so, and could not understand why it gave me a compile error.
So, I ask the senior for help, start explaining what I’ve been trying to do, scroll down to show some other code snippet, scroll back up and the compile error was gone. My IDE simply had not re-rendered properly. I have rarely sweared as much as in that moment.

This is a somewhat hacky solution, but I’ve set up a thing in the past, where I would share a URL to my desktop via KDE Connect. And then on my desktop, I configured the default browser to be a script that I wrote.
This script would check, if the URL is a YouTube URL, and if so then open it via MPV (with yt-dlp also installed on the system).
If not, then just open it in Firefox as normal.

That’s really not a good sign, though. A review process to check for basic sanity is just a bandaid fix for a lack of discipline, which ultimately requires more work to be done. So, the person that asked the magic pattern machine should review that code, as they should be deeper into the context of what needs to be done, and they know which parts of the code were generated and which parts they actually logically thought about.

Built upon Mono and Gtk#

Oof, I tell you. Oof.

I doubt many devs will want to subject themselves to a Microsoft stack, so I wouldn’t put too much hope into a fork. Probably rather worth seeing if any of the current music players have a similar UX…

Yeah, I did not expect them to do that title justice, because how in the hell could anyone try 200 music players, but how did they get down to 7 and somehow skip some of the most popular players…? Did all of those somehow look broken on their setup? 🫠