If the computer boots but you can’t access a GUI, use Ctrl+Alt+F3 to open a console. From there you can use nano to edit the login manager configuration. If you had GNOME installed, your login manager is probably GDM, and its config should be at /etc/gdm/daemon.conf, according to the manual. If that is the case, it looks like you should erase the username under the entry “AutomaticLogin=”.
You are probably gonna want to chroot into your laptop using a livecd for linux. This will allow you to basically access your terminal without being able to login or boot, and then you can uninstall Nimdow, or turn off auto-login.
FYI, the options at boot have nothing to do with this. At boot you might have different options for different OS’s. When you pick linux, it will start up. Only after login will a DE/WM like Gnome/Nimdow start. If you install multiple WM’s, they will not show up in your boot menu. Some login managers allow you to switch between them at login.
This is why I love having luks covering my entire system disk. If I want to upgrade the system with a new drive or move the drive to a different pc or sell it or dispose of it I just dd the first couple of gigs to obliterate the luks header.
It’s obviously essential to have a backup strategy, of course, but full disk encryption is the only way to go for me.
Maybe you can set up a KWin window rule to force Latte to be where you want it to be?
Not that Plasma panels work that much better than Latte in that regard, they still sometimes shift monitors just because something is plugged in (not even enabled, just plugged in!)
I really wish we could pin things to the exact monitor via its physical port location or serial number or something from EDID.
Thanks for the suggestion. This does work. You can force the dock to a specific screen, but then it doesn’t autohide (dodge) as it still thinks the other random screen is the primary and only triggers off that. Still, this may be the answer if nobody can suggest an alternative.
Yeah, it’s a terrible thing that you have to do this to get your city into the weather app, but I simply love the fact that you can do that, whereas on some proprietary system, you might wait months for the fix.
KDE is very receptive to community help! I can only think of one specific example in KDE history where a developer dragged their feet in the mud about a change the community wanted/submitted pull requests for, and thats the vertical HTML indicator bar in kmail.
Personally I’m not a fan of dual booting. Admittedly it’s been many years since I have evn tried (now that virtualization is what it is), but when I did, grub would always break on me. It just wasn’t worth the hassle. Now to think of having to reboot to switch just makes me cringe. Lol
Early 2000’s I took a class in highschool called “What’s in the box”. A buddy of mine and I would hangout after school just talking and building computers. He showed me Lindows. I specifically remember looking at the clock in the dock, and thinking… “Wow!!! Look how you can customize the clock so much!”
It stuck with me. Shortly there after I dabbled with Suse. Then moved to Ubuntu. By 2005 I was almost exclusively using Linux on all my machine. Had one machine running windows for gaming, but the other machines I had were all Linux.
I’m rocking two dailys right now. Tumbleweed and Nixos. I jabe tumbleweed on my work laptop as well as one laptop at home. Rock solid go to that I trust for all the things. I started using nix on a number of other machines at home a few months back, and I’m really really enjoying it!!
I’m new to NixOS. Do I have to do anything extra to update NixOS? Or do I just update my flake and run nixos-rebuild switch --flake like I normally do to update packages?
If using flakes you could just for instance add another input. You can also set the input URLs to specific states of the nixpkgs repository by eg referencing specific commits. Then, you should be able to just, e.g., pick Firefox from unstable, another package from the current stable channel, and maybe a broken package from a pull request fixing said package.
If you are not using flakes you can also add system wide channels. IIRC you can then import these channels into your configuration.nix and select packages from the corresponding channels. But here the channels/inputs are not part of configuration itself in contrast to when using flakes.
When not using flakes, nixos-rebuild switch --upgrade is equivalent to apt update; apt upgrade. The equivalent to dist-upgrade is nix-channel add $NEW-CHANNEL-URL nixos and then performing a regular update.
I’m a bit confused about what you actually want? Do you just want to update your packages, but stay on the same NixOS version? Just continue like before. Do you want to stay on your current version, but use some packages from the next version? That should also be possible if you somehow include that channel in your configuration.nix (though I don’t know how this would work in practice).
Personally, I just run with unstable though, then the releases aren’t that important.
I think unstable and the fixed versions use the same Firefox package, so you wouldn’t gain anything. The difference is rather in libraries that get used and how the distribution does things. For example, the changes listed in nixos.org/manual/nixos/stable/release-notes#sec-r… just appeared mostly one by one for me; one day, I wanted to update my system and got the error that the fonts option got renamed, so I had to change my configuration.
The fonts.fonts and fonts.enableDefaultFonts options have been renamed to fonts.packages and fonts.enableDefaultPackages respectively.
While when using a fixed point release, these changes won’t happen. Only when you switch releases. That’s what “unstable” refers to.
You need to update your inputs so that you’re using the 23.11 branch of nixpkgs instead of the old one. In my experience, a couple of things will break, but there’s usually warnings about it.
If you are using flakes you should check your flakes’ inputs (probably the one called nixpkgs) and then change the URL to match the channel for 23.11. Finally, you should of course rebuild your system.
First, it is generally a bad idea to manually install software in package based distro. It can break something in your system (providing install.sh script is quite uncommon, it means that developers can do something uncommon and unexpected). Even if everything will go fine, once after system update the program you installed will get broken dependencies and stop working. Better search for prebuilt RPM package.
Then, answering your question: to build against libraries you need to install corresponding -devel packages. In Fedora their names can differ from the library name (e. g. not libglvnd-devel, but glvnd-devel, you need to search them yourself). For wayland-scanner you need wayland-devel as you can find here or with command dnf provides ‘*/wayland-scanner’.
As far as I’m aware the only options to install GSR as a package are AUR/yay (not available on fedora as far as I understand) or flatpak (unable to resolve permission issue), so I do think a manual install is the best option. This is a gaming system so GSR breaking is no huge deal.
Thanks for the tips regarding manual installation! I did not know about -devel packages or about the dnf provides command. They will probably prove to be very useful!
If you’re going to install from source at least change the compile config options so the prefix defaults to /opt/program-name.
You can further integrate with the system by adding the /opt/program/bin/ and sbin/ dirs to the PATH variable, and add lib/ to /etc/ld.so.conf but it should not be needed normally — only if other programs need to compile against this one.
You can also simplify integration by making common dirs for example /opt/.bin and /opt/.lib, adding only those to PATH and ld, and symlinking binaries and libraries from all /opt programs to them.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.