2xsaiko

joined 2 years ago
[–] 2xsaiko@discuss.tchncs.de 17 points 1 week ago (1 children)

Ugh, not again. I know which forum this is talking about. I wish morons would stop bothering and trying to destroy about the only place where chroically suicidal people have found some sense of community they can relate to, while telling themselves they are doing good. These people already have it bad enough. For some that community is about the only thing that keeps them going.

[–] 2xsaiko@discuss.tchncs.de 25 points 1 week ago (4 children)

What would you consider "done right"? The main problem with it was that they used it on a desktop computer operating system. I'm sure it was just fine on Windows Phone.

[–] 2xsaiko@discuss.tchncs.de 1 points 2 weeks ago

8 points! 8, 9, 12, 13, 14, 17, 19, 20

[–] 2xsaiko@discuss.tchncs.de 1 points 2 weeks ago (1 children)

Ugh, that would complicate things. If that’s the case, all I can say is that’s really negligent (and goes into what I originally said about lack of stable ABI really ruining Rust for me — technically I said static linking but that’s really the core issue)

[–] 2xsaiko@discuss.tchncs.de 4 points 2 weeks ago (2 children)

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.

[–] 2xsaiko@discuss.tchncs.de 5 points 2 weeks ago

Yeah, that's what I mean.

[–] 2xsaiko@discuss.tchncs.de 2 points 2 weeks ago

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...

[–] 2xsaiko@discuss.tchncs.de 29 points 2 weeks ago (8 children)

And yet, ancient Windows binaries will still (mostly) run and macOS allows you to compile for older system version compatibility level to some extent (something glibc alone desperately needs!). This is definitely a solvable problem.

Linus keeps saying “you never break userspace” wrt the kernel, but userspace breaks userspace all the time and all people say is that there’s no other way.

[–] 2xsaiko@discuss.tchncs.de 1 points 3 weeks ago

Is this after it becomes unresponsive? I'm not seeing anything suspicious except maybe some D-Bus activation errors but those shouldn't do anything like that. Does the mouse cursor still move? Anything in dmesg after it starts doing that? What about CPU or memory usage? Can you switch to another TTY?

view more: ‹ prev next ›