Somewhere between Linux woes, gaming, open source, 3D printing, recreational coding, and occasional ranting.
🇬🇧 / 🇩🇪
It initially was that. Also the name wasn’t meant to stick around forever.
But, out of a sudden, between updates, not even the new website URLs ready?
I don’t follow Minetest development that closely anymore, but last time I checked there were no issues or pull requests on their GitHub, nor something official regarding a name change in the forums.
This feels like there are just a bunch of people haphazardly deciding there is a new name now.
It IS a terrible name. But it also is an over one decade old brand.
It will be hard to propagate the new name and have it as recognizable as “Minetest”.
Luh-Anti?
Also luanti.net (which would be the most logical step to use that address because of the same TLD).
Why isn’t something like this done prior to announcing the new name …
Is this an out-of-season April Fools’ joke?
That’s a cute idea but it completely ignores that it isn’t 2005 anymore. Algorithms are good enough to detect that.
At all stages I want to be left alone and just do what I’m paid for.
So Arch now is a corporate distribution?
You cannot even record single windows without having your DE patching that in for you.
X11 […] has become an unmaintainable patchwork of additions.
Wayland will be an unmaintainable patchwork of protocols, once it will have the same functionality as X11 has.
Now, 12 years later, it still is not production ready.
I use it on both my laptop and my desktop computer. It got better during the last 1-2 years.
While my laptop (13" 1080p screen) is pretty much fine running with Hyprland on an integrated Intel GPU, my desktop computer with a 28" 4K screen scaling is messed up completely and needs tweaking, sometimes down to a per-program base. Sometimes the font is gigantic sometimes I need a microscope to see anything. That was definitely better on X11.
On my desktop I run labwc, that does not come with own functionality regarding this: I just recently got whole-screen video recording and now have to wait likely another year or two for single-window recording. (There is a protocol for this, that took two years to be merged, which is just ridiculous for such a low-level base functionality that should be implemented from the beginning on.)
Other than that, all my common programs are running okay with Wayland.
I personally think it is a very bad idea to “speed run development” of protocols.
Stalling the development of protocols for nearly a decade is bad, too.
They should talk and meet somewhere between “Just develop in production!” and “I personally dislike it for non-technical reasons, so I will block it for everyone!”
I actually just run the update commands individually when I feel like.
su -l 'pacman -Syu' # All regular packages
pakku -Syu # All AUR packages (I know this updates regular packages, too.)
flatpak-update # Update Flatpak packages with a function I wrote
Since I do not trust Flatpak (especially when it comes to driver updates and properly removing unused crap) I once created this monstrosity.
flatpak-update () {
LATEST_NVIDIA=$(flatpak list | grep "GL.nvidia" | cut -f2 | cut -d '.' -f5)
flatpak update
flatpak remove --unused --delete-data
flatpak list | grep org.freedesktop.Platform.GL32.nvidia- | cut -f2 | grep -v "$LATEST_NVIDIA" | xargs -o flatpak uninstall
flatpak repair
flatpak update
}
The initial problem with Flatpak thinking it would be a good idea to add dozens of Nvidia drivers and re-download and update all of them on every update (causing a few gigabytes of downloaded files on every run of a normal flatpak update even if nothing needed to be updated) is reportedly fixed, but I just got used to my command.
It first checks if ~/.bashrc.d is an existing directory. If this it the case it then iterates over all entries in that directory. In this iteration it checks if the entry is a file and if this is the case it sources that file using the bash-internal shorthand . for source.
So it basically executes all scripts in ~/.bashrc.d. This makes it possible for you to split your bash configuration into multiple files. This quite common and a lot of programs already support it (100% depends on the program, though).
This is absolutely harmless as it is. But: if you or a program places anything in the directory ~/.bashrc.d it WILL be sourced everytime you start a bash.
A slightly better variant would be iterating over ~/.bashrc.d/*.sh instead of just ~/.bashrc.d/* to make sure to only grab files with the .sh suffix (even if suffixes are basically meaningless from a technical point of view) and also test for the file being executable (-x instead of -f).
This would make sure that only files that are ending with .sh and that are executable are sourced. The “attack vector”, if you want to call it like that, would then be a bit more narrow than just placing a file in a directory.
As for why it’s there: Did you ever touch your .bashrc? If not, maybe it is there since the beginning because it’s in the so-called skeleton (see /etc/skel/.bashrc) that was used to initialize certain files on user account creation.
If a function takes all types of variables it’s your own fault!
Warp is closed source and [needs a mandatory account, and] Wave is an Electron app.
There were plenty of those threads and discussions happening during the past few years. This is a constant topic that came up in the forums and sometimes GitHub over and over again.