• 2 Posts
  • 181 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle
  • I’m primarily talking about Win32 API when I talk about Windows, and for Mac primarily Foundation/AppKit (Cocoa) and other system frameworks. What third-party libraries do or don’t do is their own thing.

    There’s also nothing wrong with bundling specialized dependencies in principle if you provide precompiled binaries. If it’s shipped via the system package manager, that can manage the library versions and in fact it should do that as far as possible. Where this does become a problem is when you start shipping stuff like entire GUI toolkits (hello bundled Qt which breaks Plasma’s style plugins every time because those are not ABI-compatible either).

    The amount of time that I had to get out of .dll-hell on Windows on the other hand. The Linux way is better and way more stable.

    Try running an old precompiled Linux game (say Unreal Tournament 2004 for example). They can be a pain to get working. This is not just some “ooooh gotcha” case, this is an important thing that’s missing for software preservation and cross-compatibility, because not everything can be compiled from source by distro packagers, and not every unmaintained open-source software can be compiled on modern systems (and porting it might not be easy because of the same problem).

    I suppose what Linux is severely lacking is a comprehensive upwards-compatible system API (such as Win32 or Cocoa) which reduces the churn between distros and between version releases. Something that is more than just libc.

    We could maybe have had this with GNUstep, for example (and it would have solved a bunch of other stuff too). But it looks like nobody cares about GNUstep and instead it seems like people are more interested in sidestepping the problem with questionably designed systems like Flatpak.



  • Distributions are not the problem. Most just package upstream libraries as-is (plus/minus some security patches). Hence why programs built for another distro will a lot of the time just run as is on a contemporary distro given the necessary dependencies are installed, perhaps with some patching of the library paths (plenty of packages in nixpkgs which just use precompiled deb packages as a source, as an extreme example because nixpkgs has a very different file layout).

    Try a binary built for an old enough Ubuntu version on a new Ubuntu version however…







  • I use LLVM because it’s good, but I would like it even more if it was GPL and I agree with OP’s comment as well.

    However, you’re literally the guy that replies “oh, so you hate oranges” to people that say “I like apples” or however that meme goes. How about you don’t completely twist people’s justifications into something they never said.

    edit: It comes down to that I have no say in whether other people want to allow their code to be exploited by corporations nor does it make a practical difference to me in what I can do with it, all I can do is say “you’re an idiot” to them.


  • Is there really nothing in /run/user/1000/gvfs? Try gio mount -l. Maybe unmount and remount.

    It’s unlikely that it doesn’t actually mount, from the man page:

    Mounting refers to the traditional concept of arranging multiple file systems and devices in a single tree, rooted at /.

    The first error is because you have a separate argument at the end which is a local path. gio mount takes a list of locations to mount and not a mount point.








  • Right, you need to first restart the rebase, then git reset --hard to whatever commit from the reflog, then edit the todo list. Might need git rebase --skip too to make it read the next entry. I haven’t done this myself yet fwiw.

    It says it can use Git as backend, so that means I could do these kinds of operations easily without stringing several commands together on the repositories I’m already working on without changing them?

    You can either clone a repo fresh or have it take over an existing git repo that you already have cloned locally. Normally you can only use its own commands, but you can create a repo in colocated mode where you can use both git and jj commands in the same repository, if that’s something you or a tool you’re using needs.

    But in general jj will work with remote git repositories regardless of whether your local checkout is colocated or not, and there’s no problem using it side-by-side on the same repo with other people who use git.

    I posted an article (not mine) about it here a while ago. https://discuss.tchncs.de/post/26573114