lazyneet

joined 9 months ago
[–] lazyneet@programming.dev 51 points 5 months ago

The sad reality is that when you look at the files being requested, it's usually scrapers looking for exploits.

[–] lazyneet@programming.dev 1 points 5 months ago

When you bring threads into it, these exotic features make more sense. I have been doing single-threaded stuff for the most part.

[–] lazyneet@programming.dev 2 points 5 months ago (1 children)

I just never learned smart pointers and write C++ code like it's C for aesthetic reasons.

[–] lazyneet@programming.dev 16 points 5 months ago (15 children)

I've been using C++ almost daily for the past 7 years and I haven't found a use for shared_ptr, unique_ptr, etc. At what point does one stop being a noob?

[–] lazyneet@programming.dev 1 points 5 months ago (3 children)

Thanks. In my experience, Wine and Proton don't work as well as native for one of the apps I'm building, so I will need to either build in a container or say "use X Ubuntu version".

[–] lazyneet@programming.dev 1 points 5 months ago (5 children)

I do, but Linux should be a first-class platform alongside Windows.

[–] lazyneet@programming.dev 3 points 5 months ago (7 children)

Mainly getting builds onto platforms catering to Windows users and gamers. The consensus here seems to be using containerized build environments.

[–] lazyneet@programming.dev 2 points 5 months ago

Thanks for the info! If I'm doing container builds anyways, this looks tasty.

[–] lazyneet@programming.dev 1 points 5 months ago

I don't use dependencies that don't have a history of backwards compatibility, and when I do, I ship them. It's SOP to assume basic things like a GUI "just work", and it's also SOP for Ubuntu to ship non-functional programs that were broken by GTK and Qt updates. I'd rather have buggy/broken software with undefined behavior than software that just doesn't run.

[–] lazyneet@programming.dev 1 points 5 months ago

I'll probably have to use chroot or docker. I tried with glibc force link but when I objdump -T I see symbols that slip through with newer glibc, even when they're .symver'd in the header. That project hasn't been updated in a long time.

[–] lazyneet@programming.dev 1 points 5 months ago (2 children)

Containers aren't too bad for storage from a developer's perspective. I'm talking about the dependency versioning bullshit of flatpak and snap specifically for end users. I don't know if AppImage technically counts as a container, but the whole point of it is to ship libraries the end user doesn't have, which implies a fundamental flaw in the hierarchical dependency tree or distribution model - the end user should already have everything they need to run software.

 

It's been a long day and I'm probably not in the best state of mind to be asking this question, but have you guys solved packaging yet?

I want to ship an executable with supporting files in a compressed archive, much like the Windows exe-in-a-zip pattern. I can cross-compile a Win32 C program using MinGW that will always use baseline Win32 functionality, but if I try to build for Linux I run into the whole dependency versioning situation, specifically glibc fixing its symbol version to whichever Linux I happen to be building from at the time. But if I try to static link with musl, the expectation is that everything is static linked, including system libraries that really shouldn't be.

AppImage is in the ballpark of what I'm looking for, and I've heard that Zig works as a compatibility-enhancing frontend if you're compiling C. I'd just like something simple that runs 99% of the time for non-technical end users and isn't bloated with dependencies I can't keep track of. (No containers.) Is this easily achievable?

view more: next ›