Just some Internet guy

He/him/them 🏳️‍🌈

  • 3 Posts
  • 1.12K Comments
Joined 11 months ago
cake
Cake day: June 25th, 2023

help-circle
  • I think it can also get weird when you call other makefiles, like if you go make -j64 at the top level and that thing goes on to call make on subprojects, that can be a looooot of threads of that -j gets passed down. So even on that 64 core machine, now you have possibly 4096 jobs going, and it surfaces bugs that might not have been a problem when we had 2-4 cores (oh no, make is running 16 jobs at once, the horror).


  • I have none of that on my phone, just plain old keyboard.

    But the reason it’s everywhere is it’s the new hot thing and every company in the world feels like they have to get on board now or they’ll be potentially left behind, can’t let anyone have a headstart. It’s incredibly dumb and shortsighted but since actually innovating in features is hard and AI is cheap to implement, that’s what every company goes for.


  • That file looks like it’s barely playable in general.

    FFmpeg and MPV can’t play it at all:

    max-p@desktop ~ [123]>  mpv https://lemmynsfw.com/pictrs/image/f482b4d7-957a-4ed7-a9ec-0493907a8cb3.mp4
     (+) Video --vid=1 (*) (h264 576x1024 30.000fps)
     (+) Audio --aid=1 (*) (aac 1ch 44100Hz)
    File tags:
     Comment: vid:v12044gd0000cp23h1vog65ukmo9lhkg
    Cannot load libcuda.so.1
    [ffmpeg] Cannot seek backward in linear streams!
    [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 1, offset 0x30: partial file
    [lavf] error reading packet: Invalid data found when processing input.
    [ffmpeg] Cannot seek backward in linear streams!
    [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 1, offset 0x30: partial file
    [lavf] error reading packet: Invalid data found when processing input.
    [ffmpeg] Cannot seek backward in linear streams!
    [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 1, offset 0x30: partial file
    [lavf] error reading packet: Invalid data found when processing input.
    [ffmpeg] Cannot seek backward in linear streams!
    [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 1, offset 0x30: partial file
    [lavf] error reading packet: Invalid data found when processing input.
    [ffmpeg] Cannot seek backward in linear streams!
    [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 1, offset 0x30: partial file
    [lavf] error reading packet: Invalid data found when processing input.
    [ffmpeg] Cannot seek backward in linear streams!
    [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 1, offset 0x30: partial file
    [lavf] error reading packet: Invalid data found when processing input.
    [ffmpeg] Cannot seek backward in linear streams!
    [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: stream 1, offset 0x30: partial file
    [lavf] error reading packet: Invalid data found when processing input.
    

    VLC seems to be able to, but it complains that it’s not proper:

    max-p@desktop ~>  vlc https://lemmynsfw.com/pictrs/image/f482b4d7-957a-4ed7-a9ec-0493907a8cb3.mp4
    VLC media player 3.0.20 Vetinari (revision 3.0.20-0-g6f0d0ab126b)
    [00005ca01d39d550] main libvlc: Lancement de vlc avec l’interface par défaut. Utiliser « cvlc » pour démarrer VLC sans interface.
    [00007ea2f413f5c0] mp4 stream error: no moov before mdat and the stream is not seekable
    

    Some players are more generous in what they tolerate but the file is undoubtedly mildly corrupted.

    Lemmy should not let people upload corrupted files in the first place.



  • I’d say mostly because the client is fairly good and works about the way people expect it to work.

    It sounds very much like a DropBox/Google Drive kind of use case and from a user perspective it does exactly that, and it’s not Linux-specific either. I use mine to share my KeePass database among other things. The app is available on just about any platform as well.

    Yeah NextCloud is a joke in how complex it is, but you can hide it all away using their all in one Docker/Podman container. Still much easier than getting into bcachefs over usbip and other things I’ve seen in this thread.

    Ultimately I don’t think there are many tools that can handle caching, downloads, going offline, reconcile differences when back online, in a friendly package. I looked and there’s a page on Oracle’s website about a CacheFS but that might be enterprise only, there’s catfs in Rust but it’s alpha, and can’t work without the backing filesystem for metadata.


  • The problem is that you can’t just convert a deb to rpm or whatever. Well you can and it usually does work, but not always. Tools for that have existed for a long time, and there’s plenty of packages in the AUR that just repacks a deb, usually proprietary software, sometimes with bundled hacks to make it run.

    There’s no guarantee that the libraries of a given distro are at all compatible with the ones of another. For example, Alpine and Void use musl while most others use glibc. These are not binary compatible at all. That deb will never run on Alpine, you need to recompile the whole thing against musl.

    What makes a distro a distro is their choice of package manager, the way of handling dependencies, compile flags, package splitting, enabled feature sets, and so on. If everyone used the same binaries for compatibility we wouldn’t have distros, we would have a single distro like Windows but open-source but heaven forbid anyone dares switching the compiler flags so it runs 0.5% faster on their brand new CPU.

    The Flatpak approach is really more like “fine we’ll just ship a whole Fedora-lite base system with the apps”. Snaps are similar but they use Ubuntu bases instead (obviously). It’s solving a UX problem, using a particular solution, but it’s not the solution. It’s a nice tool to have so developers can ship a reference environment in which the software is known to run well into and users that just want it to work can use those. But the demand for native packages will never go away, and people will still do it for fun. That’s the nature of open-source. It’s what makes distros like NixOS, Void, Alpine, Gentoo possible: everyone can try a different way of doing things, for different usecases.

    If we can even call it a “problem”. It’s my distro’s job to package the software, not the developer’s. That’s how distros work, that’s what they signed up for by making a distro. To take Alpine again for example, they compile all their packages against musl instead of glibc, and it works great for them. That shouldn’t become the developer’s problem to care what kind of libc their software is compiled against. Using a Flatpak in this case just bypasses Alpine and musl entirely because it’s gonna use glibc from the Fedora base system layer. Are you really running Alpine and musl at that point?

    And this is without even touching the different architectures. Some distros were faster to adopt ARM than others for example. Some people run desktop apps on PowerPC like old Macs. Fine you add those to the builds and now someone wants a RISC-V build, and a MIPS build.

    There are just way too many possibilities to ever end up with an universal platform that fits everyone’s needs. And that’s fine, that’s precisely why developers ship source code not binaries.