381–390 of 422 posts
Earlier quoted context omitted.
Which libc? There's glibc, musl libc, etc. Also consider you may be using the functions incorrectly.
Seriously? “You're holding it wrong”? Read the comment at the crash site (line 584) yourself: https://elixir.bootlin.com/glibc/glibc-2.38/source/libio/gen...
Is such a thing possible with the Linux market? Can I sell my software through stores? Is IAP a thing?
Earlier quoted context omitted.
Linux can do this; binaries from the 90s work today. Something like xv (last release: 1994, although the binaries were built against Red Hat 5.2 from 1998) still work today, and the source still builds with one very minor patch last time I tried it. The problem running the binaries is: % ldd ./usr/X11R6/bin/xv linux-gate.so.1 (0xf7f82000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7e22000) libjpeg.so.62 => not found l…
Much of the Windows compatibility is "just" stable API for Windows controls, GUI event handling loops, 3D graphics and sound (DirectX). Linux has stable API for files and sockets (POSIX), but that's all.
I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…
If I could have that spread of frameworks that macOS offers on Linux, I’d be targeting Linux with my side projects yesterday. Having such a wide selection of tools to readily reach for with zero consideration about how long it’ll be supported, which fork is best, how well it meshes with a pile of other third party libraries, etc is amazing. It reduces friction massively and you just build stuff. The KDE Qt ecosystem…
I doubt it. More likely, you would be complaining that you need to spend effort rewring your code to use Linux frameworks for a tiny userbase.
That's why most cross-platform software ends up using OS frameworks only where neccessary and ships its own version for most stuff. Coincidentally, that approach matches which stable ABIs are available on Linux.
I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…
And on a lower level, `fgetwc()` gets crashed deliberately in `libc` when applied to a stream created with `fopencookie()`. It should be incredible, but Linux `libc` is not Unicode-capable in 2023.
I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…
Ensuring an app looks and feels the same across various distributions seems quite challenging when it’s not only different flavours of the OS but also different desktop environments. At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.
I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…
Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their bin…
Or ... just build against the oldest glibc they want to support.
Earlier quoted context omitted.
If only GNOME and KDE were backed by one of the largest companies in the world, with tens of billions of dollars at its disposal.
NeXT under Steve Jobs had a maximum of 500 people working with him in . There has been much more efforts than that in desktop linux. Yet NeXT delivered a mostly coherent programming platform, back in the 1990s. One thing NeXT didn't do is to introduce shitloads of useless complexity with fragmentation for the sake of it and half assed solutions on top of that.
Earlier quoted context omitted.
You're living in the past. Applets and Flash lost against the HTML/JS/CSS stack and Oracle owned up to it. Applets are terminally deprecated now. Edit: admittedly, one of the reasons for that was that the sandbox was indeed prone to security holes. Also, the developer ergonomy of the SecurityManager was unsatisfying for both JDK and app developers. Good riddance.
I'm living in the future. We have golang and rust now. Java is a pile of junk and should be relegated to the past.
Rust in turn is not competing with Java.
Earlier quoted context omitted.
Seriously? “You're holding it wrong”? Read the comment at the crash site (line 584) yourself: https://elixir.bootlin.com/glibc/glibc-2.38/source/libio/gen...
I wrote "consider", not "you are without a doubt at fault here". Learn how to read.