frankfurt_schoolgirl [she/her]

Maybe you could just try a different Transmission docker image or build your own? Sounds like some weird instability in that particular version.

What do you mean by a file being displaced? Like do you want it to be unreadable, or unmodified, or just not deleted?

It’s not really possible to have a level of protection that would require more than sudo because with root access you bypass anything else.

You could put the files on an encrypted volume that uses a special password when it is mounted. Or you could use the chattr command to set special ext4 attributes that would make it unmodifiable (but could be removed with sudo). Or just record the file’s hash, and that way you know it hasn’t been modified later.

It seems like that port needs to be accessible from the public Internet. Your local computer probably has at least one more firewall between it and the Internet, running on your router. You need to also forward the port on your router, which is what it says in the second half of the guide.

Also wondering about this. No one has package Godot 4 with dotnet support for my distribution yet and I’m wondering if that’s a sign of the overall state of C# support or just bad luck.

I’ve been using Wayland for 5 years. There were a few bugs in the beggining, but now it works great. These threads are such a waste of time.

I have over 100 confirms X11 developments

That’s great dude. Why don’t you go maintain it then, apparently nobody else wants to: https://www.phoronix.com/news/RHEL10-Removing-X.Org

Wayland took too long

Look up how long btrfs has been in development, or at audio subsystem churn. These things take time, because it’s mostly volunteers working on them.

Systemic complexity has doubled in the last two years

What does this even mean?

Mir was better

It turns out the Canonical dumping random stuff over the wall is not the same as creating a legitimate open source community around a project.

Unfixable amount of race conditions

As if there’s never been a synchronization bug in X… But also System76 and others are writing Wayland compositors on Rust anyway.

I mean xwayland is the best supported X implementation today, and will only get better. You’re not ditching everything when you maintain backwards compatibility.

I think that it’s a great project, and I hope it succeeds. My sense is that there is more momentum around Nix, so for a lot of uses it just makes more sense.

Guix and Nix both have the same issue imo, which is using a loosely typed language with an odd syntax. I feel like something both strongly typed and with a more common syntax would be easier to edit and faster to evaluate.

yeah if you’re using unstable than it’s rolling release and you just need to update regularly. the point releases shouldn’t matter too much

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.

I miss the days when Linux was always distributed via torrent. This may be a blessing in disguise though, because the Cubans will get to use a nicer distro.

Very few people do, you probably don’t need to worry about it

there a way to know what your systems current shortcuts are

Not really, besides just reading the manual. I think this is a problem for the Linux desktop actually. I would love a standard way (dbus API?) for the DE and various apps to declare their key shortcuts, and then I could view them in a pop up when I’m using the app.

As long as there’s a neovim extension

About Ansible, it’s not declarative in the same way Nix is. The way it actually works is it executes little Python programs based on your config. But if you stick to the high level modules, it has a declarative feel. Also, the Python aspect is useful because you can include bits of Python to manage things like generating complicated config files.

I haven’t checked out guix home, but it looks interesting. I have been doing some Lisp recently, so maybe the time is coming.

rootless containers

Are you managing dotfiles in rootless containers? IMO you shouldn’t install nix in a container. If you want to customize your container, run nix outside of the container and tell home manager to apply itself to the container’s file system (home-manager build will put the result into a result directory, which you can copy). Or, you could just mount your host ~/.config on the container maybe.

Ansible

Ansible is a big project, but at the end of the day it’s just a Python package. If you already have Python installed, it’s not really adding that much.

Also obligatory advice for anyone new to Nix: use flakes. Flakes are good and right. It sucks that Nix is in a confusing transition process to flakes, but if you just adopt them completely from the start it makes everything easier. Your home manager config can live in a single flake somewhere that you find convenient, and you can apply it from there.

I would use nix home manager for this. Home manager has basically three separate layers. The ability to install nix packages for a user, the ability to generate config files, and special modules that combine these things things as an easy way to manage popular programs (like vim or tmux or something). You could probably just stick to the config file generation (see the xdg.configFile module).

A big downside is that you will have to install the basic nix package manager to get home manager working. You don’t have to use it to install all of your software, but it will still need a /nix and a system daemon for home manager as far as I know.

nix doesn’t play well with container environments

I’m not sure what this means. What specific things are you trying to do with containers and nix?

If you don’t want to install a bug, complicated piece of software just to manage dotfiles, maybe you could consider Ansible? I know some sysadmin types who keep their local machine configs in Ansible. It has some nice bonus features, like deployment over ssh (nix can do this too btw).

I totally agree. The real problem for Linux gaming tho is that games are almost always distributed as compuled binaries, but Linux is built around open source. It you had a model where you paid for the source code of a game, and then it got compiled for your machine right when you downloaded, Linux gaming would probably work great. You’d have better fps too. (I actually really like this idea, somebody like GOG should make a client that does this).

As a big Linux fan, it makes me said that Wine needs to exist. But, maybe it’s not such a bad thing. Linux is just a kernel, with no associated libraries for app developers. App devs don’t want to manually write system calls, so it’s always been the case thar they lick and choose which set of libraries to target for their Linux apps. A popular low level choice is the GNU standard C library, and a popular high level choice is the GTK/GDK/Gnome stack. But these aren’t the only choices. I mean you can use the MUSL standard C library if you want. You can choose between OpenGL, Vulkan, and WGPU for graphics already.

I see Wine and Proton as just being another set of standard apis to target. Maybe they don’t have the best design, but is traditional Unix really the best design either? Now the Valve and company are supporting Wine, it’s one of the Linux targets with the most actual developers. And of course it has a huge advantage over the glibc + Vulkan stuff: it retains binary compatibility forever.

you’ll need a special Xorg implementation

Ok it’s true that op would need XWayland for some things, but that will be installed alongside the rest of the Wayland packages, and will run seamlessly.

Most applications are specific to your Wayland implementation

This isn’t true. Some applications will use features that aren’t available in all Wayland compositors, but they are rare. The main offenders are apps that interact with other apps, apps that take screenshots or record, or apps that draw outside of a window (like docks).

This is not possible. A socks proxy forwards tcp connections over another TCP connection. A wireguard vpn sends encrypted generic IP packets over udp. A socks proxy can’t understand the types of things wireguard sends.

However, you could just install wireguard on both your vps and your phone, and you probably wouldn’t even need the proxy. If your VPS is hosted by a big public cloud provider, be aware that many sites restrict incoming traffic from known up ranges because public cloud vms often used by spammers.