It pains me to say this, but voidlinux, though I’m still not in the stage of “this one is not for me”, it has potential and hopefully I can sort all the issues I’ve encountered so far.
I’ve tried multiple distros, and also used artix for a while so I’m used to not using systemd but man void is really another thing, this isn’t the first time I’ve used it, I tried it a year ago and gave up, recently I decided that I’m up for the challenge and began using it again, here’s what has happened so far:
Well right now I’m dealing with the pc freezing when quitting the user session, for some reason I need to exit i3 before logging out, otherwise the system freezes.
Also I wasn’t able to get a clean boot screen even though I had the typical kernel parameters quiet, loglevel, etc, it even prints info on the login prompt where I should be putting my username, though I managed to mitigate this a lot by passing a kernel parameter that tells it to use another tty for the boot messages.
file-roller is broken, I can’t compress some directories to 7zip, the weird thing is that it only happens to some directories and not all.
Though the very good news is that they fix issues very fast, puddletag was broken and they fixed it in like 2 hours after I reported the issue.
Edit: It is not just file-roller that is broken, it is all of 7zip on void, I can’t compress with xarchiver either
Wayland is great! Except for all list of not-a-bugs that I’d like to see fixed. Still, I’m not going back to X, so take that how you will.
What are the not-a-bugs? Things like covering up a Wayland window will block it’s rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private. Every game dev on the other hand is asking “WTF!?” as it causes their games to break randomly.
Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.
A lot of this is slowly (painfully?) changing, and the adversarial nature is a bit frustrating. Wayland fixes so many little things that I find it well worth it though, and I say that as a game developer frustrated by many of the core design decisions.
Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.
I would like them to keep that behaviour. At least make it an option or allow whitelisting certain applications. Nothing I hate more in an OS than windows stealing focus without asking.
Focus stealing is one of the worst things in the world, I am so glad I haven’t had to deal with it since I switched to wayland. (Except for stupid firefox tabs stealing focus from other tabs, that still happens obviously and happened to me during a test for my university and almost invalidated my score)
Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private.
I do like that. I have encountered a number of bullshit things like HR mindless training videos (ok, the fourth time I’ve seen this guy contemplate accepting a bribe… I get it. Don’t accept bribes! Leave that shit to Clarence Thomas) or ad playbacks that refuse to proceed unless they are focused. It’s annoying as hell. The problem you point out also sounds really annoying.
What are the not-a-bugs? Things like covering up a Wayland window will block it’s rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private. Every game dev on the other hand is asking “WTF!?” as it causes their games to break randomly
Please don’t make up what “Wayland core folks” think. You don’t know it, and your claims are waay off.
It’s not about security. It was intended to allow the compositor to throttle apps to improve efficiency… Which of course in practice doesn’t work like this at all, because OpenGL swap buffers and Vulkan FIFO presentation modes were never intended to be used this way.
As for why that hasn’t been fixed yet, it’s not as big of a problem anymore:
Mesa (at least for Vulkan) and Xwayland gurantee one frame per second as a minimum refresh rate
toolkits and libraries use mailbox presentation internally and check frame callbacks themselves for when to render
xdg shell now contains a flag for apps to know to inhibit rendering because they’re hidden. That doesn’t guarantee that presentation won’t otherwise block though
a (set of) protocol(s) is being worked on to replace frame callbacks with a mechanism actually suited for OpenGL and Vulkan
Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.
That’s not even close to how activation works on Wayland, and no, it’s not just a security thing, it’s a usability thing. Apps can only raise themselves if the currently focused app gives them focus, so that random apps can’t cover up what you’re working on just cause they need to show you an ad or an “important” pop up question or whatever. If it doesn’t work for a specific app, make a bug report about it to the app.
A bit of a zombie thread, but I’m not making anything up here. The blocking issue gets discussed a lot in gamedev circles, and there are issue threads that have been locked by folks with the power to do so because they just said “no”. One of them (Maybe Sebastian Wick? I don’t remember… doesn’t really matter) gave verbatim that use case where a video service they use would stop playing videos when the browser was in the background, and that is why they won’t report . Maybe they weren’t a “core” developer, but they had the ability to say “no” and end the discussion thread.
As for it being not a problem anymore, it still occurs even on Fedora 39. The 1 second present timeout still only works for XWayland, and that’s… not a great solution. Also, realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does. We are already supporting multiple rendering APIs, and combining that with multiple UI libraries just to get a window to draw a triangle into is a combinatorial explosion. Last I remember reading from the SDL folks, they were waiting for the functionality to appear in Wayland before they could implement it, and they weren’t expecting anything to change soon either. Speaking personally, my current game project is single player so I can just pave over the timing issues when they come up:
Long frame detected: 6463.731931 ms. Skipping ahead!
The most frustrating part to me is much more meta. You get discussions with other game devs that have heard about this stuff and they continue to think that supporting Linux is just way too much work. Sometimes they are right, but rarely for the right reasons it seems. I believe in the glorious Wayland future… I just wish it would get here a bit faster. ;) On the other hand, if we rushed it and botched it then it would never arrive at all I suppose. (sigh)
As for how window activation works, you got me there. I just heard other people discussing that one, but it did explain why on Wayland I would just get “Firefox is ready” notifications when opening links instead of just showing me the page like X did. Though I’m quite happy that it’s gone now in Fedora 39. Progress is good!
The 1 second present timeout still only works for XWayland
Oof, I thought the corresponding MR for Wayland was merged… But it was from Sebastian and after he got into a heated discussion again and started cursing, the MR got closed by someone else :|
realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does
SDL does handle it, but only for OpenGL; it can’t do anything about Vulkan. GLFW doesn’t do anything about it either, so that is pretty annoying.
I believe in the glorious Wayland future… I just wish it would get here a bit faster
Don’t we all. Let’s hope the current upstream approach to fix this issue gets somewhere sooner than later…
I’m hoping their translation software ends up supporting Chinese/Japanese. Also come to Android please! Hopefully on Android in and out of reader mode.
I like using the terminal because of 3 main reasons:
I like using my keyboard
I like doing multiple things in one window
Verbosity
I’m pretty quick with typing, but sometimes I can’t see !y mouse at first, so it’s just faster for me to type out what I want to do as long as I know the right arguments for it.
My average workflow at work as me doing frequent saml logins and going between multiple kinds of databases. It’s just easier for me to run the saml cli command and then run the SQL CLI command I need instead of messing with datagrip settings and stuff. Also I recreationally run some servers and it’s just easier to ssh into the server, make the changes I need in something like nano or the redis CLI tools and then log back out. This means I’m just plain more comfortable on the terminal in certain situations like config editing, writing posts for my gemini capsule, etc.
Sometimes when I run a GUI program I’ll get big loud silence and don’t know what to do. In that case I genuinely enjoy using the terminal and running an equivalent command with verbosity settings so I can see what it’s doing or not and can track down any errors.
On top of those reasons, I’ve been playing with RISC-V architecture lately and, while the xorg riscv64 port is admirable, I just get better performance rn by running my RISC stuff through tty.
I recognize that not everybody is going to have the same use case and workflows as me, but I’m pretty comfortable with what I’ve got 😅
Thanks. That helped a lot. It gave me a good basis for some further googling.
It ended up that the Internal Clock of the hardware interface was deselected in alsamixer. Enabling it fixed the no audio issue.
For the channel remapping I tried a bunch of different config files until finally one actually managed to not be ignored. It’s absurd how many separate configuration files and sound settings menus exist for linux audio and there’s no guarantee the one your editing is even being used. An absolute mess IMO and it’s no wonder people shy away from linux for desktop purposes.
Funny enough, despite getting the channel remapping to work, it’s completely ignored unless you put pulseaudio -k into your user profile. And even now, because the remapped output device doesn’t show up on boot, it has to be manually set to the default output every login.
At least I have the right channels mapped though.
I love linux but god damn is it a hot mess for the simple stuff.
Glad you were able to figure it out. Yeah, there are a lot of settings and different moving parts involved in doing audio. And the config files are all over the place. It can get nasty.
There has to be a way to make your settings and that pipeline the (system) default. Or at least change the profile that gets loaded for your specific soundcard and change and override the channel mapping so it won’t load something else first.
I use it for storing luks credentials, so every time I boot I get dropped at my login manager. It leaves my system vunerable to attacks to it, but its quite convenient.
Besides, if anyone tries to boot any other OS which is not mine, the keys are erased.
Can you explain a bit on how the key erasure works? AFAIK TPM only refuse to release the key when certain PCR dont match, is there a setting to let it erase key?
It talsk about pcr, every time another OS is booted some pcsrs are changed, and if the keys are installed on the correct ones, this will lead to it being erased
Besides, if anyone tries to boot any other OS which is not mine, the keys are erased.
There are forensic tools that can capture the contents of RAM, and so access your decrypted LUKS encryption key.
I guess it depends on who you are protecting against, but if for example law enforcement wants evidence against you for what they think is a serious enough crime, they just may go through the trouble to do it.
I’ve found nixos is perfect for me since I like how precisely I can configure it.
Oddly enough, I’ve had a decent chunk of my only barely technical friend group switch to it for the opposite reason. They all just copypaste snippets of config between each other, and if something breaks they just go back a revision. I doubt any of them spend much time configuring anything. It really is the perfect idiot proof distro and I don’t normally see people talking about that side of it
Yeah, I think Nix is a good concept but I feel like 99% of the config work could be managed by the OS itself and a GUI to change everything else. I also feel like flakes should be the default, not this weird multiple systems thing they have. I also wish most apps would have a sandbox built in, because nix apps would then rival flatpak and, if ported to Windows, become a universal package manager. Overall good concept but not there yet.
It is a great book, although a bit outdated. In particular, nowadays egrep is not recommended to use. grep -E is a more portable synonim.
Some notes on you script:
You don’t need to escape slashes in grep regex. In the sed s/// command better use another character like s### so you also can leave slashes unescaped.
You usually don’t need to pipe grep and sed, sed -n with regex address and explicit printing command gives the same result as grep.
You could omit leading slash in your egrep regex, so you won’t need to remove it later.
nowadays egrep is not recommended to use. grep -E is a more portable synonim
Not directed at you personally, but this is the kind of pointless pedantry from upstream developers that grinds my gears.
Like, I’ve used egrep for 25 years. I don’t know of a still relevant Unix variant in existence that doesn’t have the egrep command. But suddenly now, when any other Unix variant but Linux is all but extinct, and all your shell scripts are probably full of bashisms and Linuxisms anyway, now there is somehow a portability problem, and they deem it necessary to print out a warning whenever I dare to run egrep instead of grep -E? C’mon now … If anything, they have just made it less portable by spitting out spurious warnings where there weren’t any before.
GNU grep, the most widespread implementation, does not include egrep, fgrep and rgrep for years. Distributions (not all, but many) provide shell scripts that simply run grep with corresponding option for backward compatibility. You can learn this from official documentation.
Also, my scripts are not full of bashisms, gnuisms, linuxisms and other -isms, I try to keep them portable unless it is really necessary to use some unportable command or syntax.
GNU grep, the most widespread implementation, does not include egrep, fgrep and rgrep for years. Distributions (not all, but many) provide shell scripts that simply run grep with corresponding option for backward compatibility. You can learn this from official documentation.
It seems you need to read the official documentation yourself. While it’s new information to me that egrep is no longer a symlink, as it used to be a couple of years ago, but a shell script wrapper to grep -E instead, the egrep command is to this day still provided by upstream GNU grep and is installed by default if you run ./configure; make; make install from source. So it is not a backward compatibility hack provided by the distribution.
You can check for yourself. Download the source from ftp.gnu.org/gnu/grep/grep-3.11.tar.gz, unpack and look for src/egrep.sh or line 1756 of src/Makefile. Apparently the change from symlink to shell script was done in 2014, and the deprecation warning was added only last year.
In any case, my larger point is that the depreciation of egrep was a pointless and arbitrary decision that does not benefit users, especially not veterans like myself who have become accustomed to its presence. I don’t mind change, but let’s be honest, most people are not in the habit of checking the minutiae of every little command line utility they use, so a change like this violates the principle of least surprise. It’s one thing if things are changed with a good reason and the users do not only suffer the inconvenience of the change but get to reap the benefits of it as well, but so far I haven’t found any justification for it yet, nor can I think of any.
So if there is a portability problem with using egrep now, it’s a self-inflicted portability problem that they caused by deprecating egrep in the first place.
Also, my scripts are not full of bashisms, gnuisms, linuxisms and other -isms, I try to keep them portable unless it is really necessary to use some unportable command or syntax.
I’m sorry for your loss, however the egrep deprecation is a fact. Of course you can continue using it as a veteran, but it is not correct to recommend this to beginners.
You are strawmanning, and your links are not countering any point I made. I never disputed the depreciation as fact, and I never recommended that beginners should use egrep over grep -E
I disputed your claims that the egrep command has just been a distro hack all these years, when in fact GNU to this day still distributes egrep through its source tarballs and only very recently started to warn about it through the wrapper script. And again, the only “portability problem” here is the fact that they deprecated it in the first place, i.e. a self-inflicted one.
Then as a Linux and Unix veteran I gave my subjective opinion by lamenting and criticizing the fact that this depreciation happened, and how changes like this always feel like unnecessary pedantry to me. Yes it’s an expression of frustration, but I am allowed to feel frustrated about it. I don’t need people like you invalidating how I feel about breaking changes in software that I use daily.
Ubuntu’s package managers won’t stop fighting with each other so I can’t complete an upgrade easily. Also, I hate apt. Trusting prebuilt binaries from PPAs seems a little dangerous to me compared to trusting build scripts in the AUR, so I don’t feel comfortable with that. I do like it otherwise, though.
Linux Mint is fine, I guess, but no Wayland yet and I don’t like Cinnamon. Same PPA issues. Has some more outdated packages than Ubuntu.
openSUSE is great, but the package managers won’t stop fighting with each other and it’s lacking a few packages. I like the Open Build System a lot less than the AUR.
Fedora is fine, while missing some packages, but it broke on me after a week and I had no idea how to fix it so I stopped using it.
Pop_OS makes everything about GNOME worse.
Debian’s packages are too old.
Manjaro is more work than Arch and the packages are out of sync with the AUR.
The packages I want aren’t in Solus. Is this distro even still around?
And for distros I won’t consider trying:
Gentoo is too much work.
Qubes is too much work and I can’t play games on it.
I don’t like any of the ZorinOS modifications and the packages are old.
The main package I was thinking of was the kernel. I saw the recent Linux Experiment video by Nick and they were using a kernel version (6.1?) that was no longer supported nor an LTS.
This is good to know. I’m more into rolling releases like Arch, Fedora, and openSUSE anyway, so the latest Ubuntu’s packages tend to be a bit old for me anyway.
Keep in mind that asahi cut out X11 support and went straight for wayland. It can support xwayland, just know that some things may or may not play nicely if the software doesn’t support wayland. As Wayland is the future of compositors, most popular Linux software should support it eventually.
Linux on arm is good, however as it is not nearly as popular in the desktop space as x86, common binaries for certain applications may not exist on arm if it closed source. You may or may not need those, you can make that judgement call.
Battery life is better than I expected but still not nearly as good as Macos. At least until they can come up with a proper solution for low power usage. Which currently a logistical problem of making something Linux kernel upstream compatible instead of applying a functional dirty solution now.
Linux on M1 is noticeably snappier than anything else I have ever used. It has a great future ahead of it. If your workloads don’t rely on heavy gpu usage and all your software can be found or compiled there. It is a pleasant experience. If you have any other questions, feel free to ask. I think some of the other users talked about the common things well enough.
Also yes, dual booting is currently the only supported option. They still need macos for firmware upgrades.
fwiw I’ve been on Wayland for a few years now and the amount of times I’ve had to think “oh, I’m on Wayland” are in the single digits. not to pretend it you don’t run into things you have to solve or alternatives you have to find, you definitely do, but I’ve been very happy especially over the last year or so.
I do not use asahi though so I can’t comment on that specifically.
I am new to Wayland, but on asahi it is mandatory. So I am having to get used to it. Which is more noticeable as I had to change from i3 to sway. They are functionally identical but different in how you configure it with the wayland compositor.
yes, I’m using sway as well. i was lucky that my old i3 config mostly worked without modification, although it took a while to find good replacements for many of the little apps I’d come to rely on. I settled on bemenu, waybar, and then a dozen little glue apps like clipboard managers eventually fell into place. the archlinux wiki pages on sway and wayland are a great resource.
I’m a bit surprised that no-one mentioned ALE. If you want to turn vim into an IDE it goes a long way.
Having the compiler warnings/errors inside the buffer is already really useful, but then you can also add LSPs and there isn’t really much missing. I’ve recently developed a Java program entirely in vim using Eclipse’s LSP.
I’m a bit surprised that no-one mentioned ALE. If you want to turn vim into an IDE it goes a long way.
That’s very useful! Thank you for mentioning that!
I’ve recently developed a Java program entirely in vim using Eclipse’s LSP.
Very interesting! I’d assume one would have to be relatively fluent in Vimscript to pull that off. Would you mind sharing your thoughts regarding Vimscript? I especially feel the need to ask as a lot of other users so far have been championing Neovim with some of them being particularly vocal regarding their dislike towards Vimscript. And would you also be so kind to share your thoughts regarding Neovim?
have to be relatively fluent in Vimscript to pull that off
I don’t think so, using ALE just requires to install the plugin and the external programs that it will interrogate. I know almost nothing about Vimscript.
thoughts regarding Vimscript
From what I’ve seen it’s a scripting language like any other, but one that is extremely specific to vim. The syntax is also quite different from anything else, so I never felt the need to learn it.
Neovim
As a general concept, it seems a good idea, I also know Lua so it would seem to be a logical switch for me.
However, during these years every time I tried it it had some slight differences from vim that made using it somewhat annoying. Moreover, it never seemed to provide such a better experience that made me switch permanently. I’d like to like it, but I never had a reason to.
Honestly, I don’t even remember. It was something to do with minor differences in the cursor movements of specific commands.
Anyway, it’s been years, anything may have changed in the meantime. I should probably give it another go, those were simple nitpicks that I was too impatient to tolerate.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.