Personally I never understood why file managers in linux refuse to do operations that require privileges. Guess what, if I have Nautilus open and want to move files into, let’s say, /usr/local, I don’t want to have to switch to the terminal to do so if I already have the stuff copied within nautilus. On Windows, I just get an admin password prompt if I try to do naughty stuff. On Linux, we have the whole polkit system, but no file manager seems to ever use it. Tbf, this is not a nautilus problem, as no file manager seems to do this.
Oh wow you can? I just switched to Nemo on Arch after using Thunar for a long time but I got annoyed at it for crashing a lot when I copy files to my FTP server. Very good to know!
I’m aware of nautilus-admin, but not only is it not maintained, imho it should be part of nautilus by default, and it has to open a new nautilus window when you use it. What I want is to drag and drop files to /usr/local and then get a password prompt to do the move. With nautilus-admin, I need to have the foresight to use “Open as admin” when going into /usr/local, but if I had that foresight then I might as well just start nautilus as root to begin with. Usually I just want to look into the folder, and only then realize I need to change something, which means a good old “go back up one folder, then search the local folder again, then right click, search for ‘Open as admin’, then get thrown into a new window, completely disorienting myself in the process”.
Honestly I don’t get why Gnome is standard for so many distros, if that’s your thing sure but I feel like KDE makes more sense as a default (unless you’re going for more of an apple feel)
KDE feels like an unpolished Windows desktop to me. I find it difficult to do things the KDE way when everything feels like Windows on first glance, but doesn’t 1:1 behave like Windows. It’s a disjarring experience for me, and probably others who migrate from Windows to Linux. I also think that Gnome has better touchpad gesture support than KDE, which makes Gnome the logical choice for companies that sell Linux laptops.
My recollection mostly had to do with the old way Qt was licensed, which affected how people wanted to include KDE in distros. Gnome managed to step into the void by leapfrogging other choices like CDE (way back!) and it managed to get wired into a few fast growing distros. Most notably, it was pulled into Ubuntu due to the Qt licensing on commercial distros, then many things based on Ubuntu, and here we are.
I’m sure there were other considerations about features, where Gnome had a good set of tools, but used to be lighter duty than KDE. There was also a window of time where Gnome was designed to be more touchscreen/tablet friendly while KDE stayed away from that style (good!).
Different licenses, different styles, different release times. A bit of “right place, right time, now the default” for Gnome.
I like KDE, but I’m mostly a Mint/Cinnamon user, and have been around since SunOS CDE systems, so it’s all better than that! I’ve got a couple of kids on Ubuntu/Gnome, mostly due to driver issues.
Some of this is correct, and some of it is myth. Source: I was there ;)
Qt way back in version 1 was merely “free for non-commercial use” and shipped with the source code. KDE was founded on that version. This was in like 1996, before KDE even had a stable release. Gnome was founded immediately in response, choosing GTK (the Gimp Toolkit) which wasn’t really ready for use as a full fledged desktop toolkit, but existed and the license was friendly. KDE and Trolltech formed a few agreements – the first was the creation of the QPL, an attempt to create an open-source compatible license for Qt, and the second was the creation of the KDE Free Qt Foundation (it said, effectively, if Qt were to become closed, the most recent version prior to that would be released under the BSD license).
However, the damage was done. Stallman and others would never forgive KDE for choosing a not-free-enough toolkit, and the Gnome devs were associated with redhat. That meant Redhat and Debian, the two biggest distros, defaulted to Gnome. Ubuntu just adopted Debian, ergo Gnome.
Qt would shortly thereafter be released under GPL, GPL3, and LGPL. There’s still a commercial license option, and that pisses a lot of people off for some reason. But it was never a risk to KDE or the community – not since before KDE 1.0.
The interoperability of Fediverse platforms is so cool!!! Don't even have to leave the site you're on to contact someone in a completely different style of site. I love to see it.
As far as I’ve seen, they don’t provide any advantage over a string with spaces, which doesn’t work well either when you’ve got values with spaces:
<span style="color:#323232;">not_what_you_think=( "a b" "c" "d" )
</span><span style="color:#323232;">for sneaky in ${not_what_you_think[@]}; do
</span><span style="color:#323232;"> echo "This is sneaky: ${sneaky}"
</span><span style="color:#323232;">done
</span>
<span style="color:#323232;">This is sneaky: a
</span><span style="color:#323232;">This is sneaky: b
</span><span style="color:#323232;">This is sneaky: c
</span><span style="color:#323232;">This is sneaky: d
</span>
I remember a gamedev complaining about this on Twitter but the outcome he came to was that he hated that Linux users submitted bug reports, stating the OS itself was broken and he refused to help any of them.
Interesting take. I wonder if the amount of platform dependent bugs is generally that low for games. I’m a developer, but not a game developer. I would assume that platform dependent stuff comes into play a lot more, when using shiny new tech like direct storage, which is probably used more by AAA titles and less by indie games?
I made games primarily for Windows which we also compiled for Linux. It is mostly input/output stuff, aka hardware issues. That is, audio issues, input issues, storage issues, dependency issues. Modern game engine mostly handle the rest. It wasn’t such a big deal to fix, but most gamedev lacked experience with Linux, and most projects are already over budget and late, so fixing Linux for an extra 2-5% of sales didn’t make much sense at small scale. Proton kind off fixed all of this tho.
In my somewhat limited but relevant experience, the amount of platform specific bugs is indeed that low. I mean, there’s of course a layer of platform-specific low level stuff which is highly subject to platform specific issues, but once you go above that layer and into game code proper, most bugs are just bugs.
I didn’t fix 400 “Linux-only” bugs, but I did fix dozens of “seems Linux specific” and “only happened when at least one Linux client was connected” bugs, and a grand total of 2 were caused by platform differences. And of those two, zero were Linux specific. The platform difference in this case was about how different compilers optimise non-crashy types of UB.
Of course, we don’t want UB at all so the fix is to remove it.
The difference is money. Vulkan is an incredibly terse spec compared to dx12. You’d think that would make it much more consistent to work with, but really, it’s all it can do to keep up with msft and IHVs who pour money into coaxing AAA devs to use dx12. Then, even when the app gets something wrong and causes issues for end users, the IHV just makes a special case in the driver to correct it, because having a big important dx12 title run correctly on their hw is important to sell units.
Meanwhile, the same IHVs barely bother to support anything beyond the basic vulkan requirements, because it doesn’t gain them anything to do more. If a vulkan game experiences issues, IHVs don’t care because it won’t sell well anyway.
Yes, and the primary reason any of gaming on Linux is viable (steam deck, proton, etc) is due to Valve dumping money into it. AMD probably didn’t care about the miniscule number of chips they sold to Valve for the deck, valve just wanted a vendor who had the performance, and had decent Linux support.
But Valve is the one eating all the vulkan costs that msft normally eats on the dx side. To be clear, it’s never out of the kindness of their hearts, it’s purely because a msft dominated gaming ecosystem on PC is steam’s biggest weakness. They don’t want steam on windows to reach the point of EGS on the apple store.
From what I understand it’s basically like a “thin client” type of thing where the client loads the Kernel from local storage up to a certain point and then boots into a rootfs that is somewhere else on a remote server.
Basically, your system, if asked to, will boot into a limited mode where it exposes its drives over NVMe-TCP. It’s like taking the hard drive out and putting it into a different PC, but over the network.
Similar but in this case the Linux Kernel/Init System act as the PXE firmware so you don’t need a TFTP Server to load initramfs and a Kernel image. And you don’t need a NFS or Samba server because the Server has the drive with the rootfs already exposed to the network.
“target disk mode”, which this claims to be taking a lot of inspiration from, pretty much turns your computer into an external harddrive - so you can connect another machine to it for direct access. This appears to be trying to accomplish the same, but over the network.
If you’ve ever stuffed up a machine so badly that the best idea you could come up with, was to take the harddrive out and work on it from another machine - this pretty much allows you to do that. But instead of taking the drive out and putting it an external drive enclosure, you just ask the stuffed up machine to act as the external drive enclosure.
So this is a service aimed at exposing disks as nvme-tcp boot targets on boot of the system? I mean I love it, I wonder if this could be used to help with a chicken and egg problem I’ve had with building clustered systems easier. So far I either need a running service to host a network file system (like NFS or CEPH), or I need local disks that bootstrap the clustered storage environment.
Do you mount the drives using their /dev/sdX entries or via UUID? Because it sounds like you're using /dev/sdX entries (which you really shouldn't, because their names can randomly change, by design). Use /dev/disk/by-id/... directly for mounting or, alternatively, fill /etc/zfs/vdev_id.conf (see example below) and define the pool using their aliases.
alias Bay1 /dev/disk/by-id/ata-XXXXXXXXXXX1-YYYYY1_ZZZZZZZ4
alias Bay2 /dev/disk/by-id/ata-XXXXXXXXXXX2-YYYYY2_ZZZZZZZ4
alias Bay3 /dev/disk/by-id/ata-XXXXXXXXXXX3-YYYYY3_ZZZZZZZ4
alias Bay4 /dev/disk/by-id/ata-XXXXXXXXXXX4-YYYYY3_ZZZZZZZ4
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.