Nothing unsolvable, but it can be a pain when you want to run something not in nixpkgs. My solution is to have Ubuntu on a separate partition, and I was using docker to solve this problem for a while but have moved away from it.
I think this thread shows it’s very hardware/driver dependent?
I’m posting from Wayland running on Plasma 5, on 100% recent gen intel hardware, and as far as I’ve been able to tell I have zero deficiencies that matter in functionality. (aside from whatever little bugs surely exist that I’m not noticing - and big things no one really has yet like HDR)
I don’t have much sympathy for the haters who think we shouldn’t be moving to Wayland ever, but every recent thread seems to confirm that Nvidia and possibly other HW configs are still likely to be problematic.
A big aspect is fractional scaling needs. I have tried the current kde 5 wayland version everytime a new minor release is done and it’s very bad with inconsistencies in many places and weird font rendering and stuff like that. I’m very eager waiting for kde 6 where many of the bugs are supposedly fixed.
I’ve got a 3.5k 13" display and have only noticed scaling issues with xwayland apps (which Plasma warns you of) - but I’m not disputing your point, there are clearly rough edges some folks see that others don’t.
No, this kernel patch will be different to what’s in Windows code. It implements what’s necessary for wine to be more performant, not the actual Windows API itself.
Wine implements those Windows API/ABIs, which is legal because it’s done by reverse-engineering. I believe in some countries (US?) it’s also necessary for the devs to never have seen Windows code.
PS: Google v. Oracle is a US supreme court decision where Oracle lost at trying to patent Java API’s.
If anything, a firewall only seems to provide extra precautions against mistakes made by the user, rather than actively preventing bad actors from getting in.
You say that like that isn’t providing value. How many services are listening on a port on your system right now? Run ‘ss -ltpu’ and prepare to be surprised.
Security isn’t about “this will make you secure” it’s about layers of protection and probability. It’s a “good practice” because people make mistakes and having a second line of defense helps reduce the odds of a hack.
Security isn’t about “this will make you secure” it’s about layers of protection and probability. It’s a “good practice” because people make mistakes and having a second line of defense helps reduce the odds of a hack.
AKA Defense In Depth and should be considered for any type of security.
Because the nix package manager places all system packages under /nix/store/uniquehash-packagename-version/
Where the unique hash is obtained via a Merkel tree of all the inputs. So in particular, binaries and libraries exist underneath those directories, not in the places you would expect from FHS.
In order to make the system actually work, environment variables are set up and executables are patched to refer to specific paths within the Nix Store.
Nix installs derivations into separate folders. A derivation can be a package, but can also be other things like configuration files, scripts or sources for packages. Nix doesn’t distinguish between these derivations by a name but rather by a hash created from their build instructions.
For example two instances of the same package with a different version are two different derivations and thus nix can have both package versions installed without them interfering with each other. But this goes beyond just a package version. It is e.g. possible to have the same package with the same version but different patches applied, or relying on different versions of dependencies. Since their build instructions differ both can be installed simultaneously.
This approach grants a variety of advantages. For example upgrading your NixOS system just installs new derivations of packages and configuration files that have changed, while keeping previous derivations until they’re garbage collected at a later time. This allows you to switch freely between both iterations of your system, for example if an update causes issues you can just revert back to before an update easily. Another advantage is that an unprivileged user can install packages they need without interfering with the rest of the system, for example an older python version or a newer one, or some software they want but the system does not provide.
The price of having this kind of isolation between packages is that nixos cannot install binaries and libraries into common locations. Effectively /usr/bin only contains the env binary. If you’re familiar with shell scripting you might have run into lines such as #!/usr/bin/env bash. This env util will essentially search bash in your PATH variable and start it. Lines like #!/bin/bash however will not work, because there’s no bash installed in that location.
Another case where a missing fhs is a problem is when using pre-compiled binaries. In contrast to binaries built through nix, which have their required libraries hardcoded as absolute paths, pre-compiled binaries you download usually only contain the name of the library they need, which works in a conventional fhs environment, because these libraries tend to be found in /libor /usr/lib. On NixOS neither of those are present. There two solutions to this. Either you create an fhs environment by listing the set of derivations to be symlinked into a chroot environment which mimics an FHS. Or you can install github.com/Mic92/nix-ld which automatically finds the required libraries the nix way if you start such a binary. There’s also steam-run which installs an fhs with most of the dependencies necessary to start Linux games from Steam.
Now you’ll have a zillion users trying to install software in ways that violate all the assumptions that NixOS operates on, but which are still tightly coupled to your NixOS config. Now updates to your system, or even seemingly unrelated config changes (through some transitive dependency chain) can easily break that software.
So now we’ve basically removed half the advantages that motivate Nix/OS in the first place, and when stuff breaks it will look like it’s Nix’s fault, even if it isn’t.
On the other hand, nixpkgs is already the most comprehensive repository of system software out there, and for 99% of packages Nixifying it is pretty trivial. Hell, my NixOS config does that for 3 different GitHub repos right inline in my config.nix
If you put an FHS on the actual system you wouldn’t be able to install multiple versions of the same package, updates wouldn’t be atomic - you wouldn’t get the big selling points of Nix.
What this guy/gal said. Linux user for 25 years here, 10ish of which have been exclusive. And I run Mint on my main PC.
Because when I can finally wind down after the kids are in bed and I can hear myself think, I just want shit that works, without having to dick around with manual kernel modules and other custom stuff to get basic things working … I get paid to do the latter at work, and I get enough of it there.
Way back at the dawn of time, there was a regular issue with low quality applications that would run XGrabKeyboard() (or XGrabPointer()), and then get stuck without releasing it again. If you can, try to log in over the network from another machine and kill application processes one by one until it releases? It’s most likely the video game (or library used by it) that has gotten stuck.
Are you sure its a similar issue? Because usually closing the window actually doesn’t solve it, as then reopening another X11/XWayland window will still not register keyboard presses. I am adding some more info to the post right now.
I’m not sure, there can always be other issues. But note that closing the window is not the same as terminating the application. When you close the window, the application gets a signal that it usually handles as cleaning up and shutting down. But if it is hanging, that task is not performed and resources are still held.
Welcome to a larger world. IF you ever need dual boot working well on linux, I found the best robust method is install Windows first, leave space for more partitions. install Linux and make a separate boot efi partition. Many distros offer to probe for foreign OS. this will find windows and add a chainloader entry to grub. Set the Linux partition as the boot one in BIOS/EFI. Grub will start and if you choose Windows it handsover the boot to Windows boot ( and Windows doesn’t know it). Windows will leave your EFi linux boot alone. You can also share a ntfs partition between them if needed
Thats why you have two. windows efi and linux efi on separate partitions. Windows never knows the other one exists and ignores the rest of what it sees as unalloated space. it even lets you shut down a windows update, boot linux and come back to windows later which continues the update. I have been running this way for 7 years, Windows has not touched my other EFi partition.
Should still be fine if you set BIOS/EFI to only boot from the Linux EFI, and it has chainload entry to Windows. If you left it up to some Windows Dual boot thing it will wreck you for sure
Welcome, friend! Glad you decided to try out and stick with Mint. That’s the distro I used as my daily driver for at least 1.5 years. When you have a chance, do try out some of the other Linux distros, especially Arch!
+1 here for the arch recommendation as an ex ms sys op. Browsing their repos was outstanding for retooling, most of the config problems you hit are a great way into the ecosystem.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.