<pauldoo>
Hello! Jumping over from email to chat about static linking.
<pauldoo>
As per email update. I don't think I _need_ static linking. I can run from inside the container just fine and have the GUI exposed.
<pauldoo>
It would be only be handy if I could statically link the non core-platform dependencies.
<pauldoo>
It would let me run the app outside the container if I ever need to.
<teepee>
oh, hi, that was quick :)
<teepee>
it might even help AppImages a little bit, reducing outside dependencies
<teepee>
but it probably is a huge can of worms
<teepee>
build topics a usually very slow, very annoying
<teepee>
(I'm maintaining most of the official builds for years)
L29Ah has joined #openscad
<pauldoo>
I primarily use the Flatpak on my host. I'm not familiar with the build process for a flatpak, so maybe another option is to run the flatpak build process inside the container and export the self-contained flatpak bundle somehow.
<pauldoo>
I'm probably overcomplicating things. I can get by just fine I think running the app inside the container. At least for development this is fine.
<pauldoo>
The background to this is that I've been exploring devcontainers. Would you be interested in a PR to add the necessary configuration to the openscad git repo for this?
<pauldoo>
I intend to attempt one of the "good first issue" items from the github tracker as a way to prove that it's a reasonable experience and that I've got the necessary tools in there (debugger, etc, etc).
teepee_ has joined #openscad
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
<teepee>
pauldoo: dev container as in the ones defined by github to run on their platform?
<teepee>
sure, that would be useful, remains to be seen how we can make sure that does not bitrot, but having a working start is always good
<teepee>
kintel already uses some container setup, I believe, but I'm not sure how exactly
Smeef has quit [Read error: Connection reset by peer]
<teepee>
pauldoo: ah, thanks, I'll have a look. I do most of my development locally, but always eyed container based solutions for things like npm/web-apps
peepsalot has quit [Remote host closed the connection]
peepsalot has joined #openscad
<hramrach>
appimage seems to be statically linked
<guso78>
I dont think so. IT Just contains all libs ever required.
<guso78>
I created appages without statically
<guso78>
Compiling all deps
<teepee>
appimages are more like a CD image with an autostart
<teepee>
the appimage *itself* ist statically linked, the contained application is not (usually)
<hramrach>
it's a self-extracting binary, the wrapper is statically linked bu the content is not
<teepee>
yes, it's a squash-fs read-only filesystem with a wrapper+starter binary
<hramrach>
unless writing in go or rust it's unlikely that all dependencies can be linked statically without problems, it's unusual for most other languages
<teepee>
it would be nice to easily have the option to switch between the two
<teepee>
but unfortunately that's not a reality for any non-trivial application
<pauldoo>
I thought AppImage was a dead-end, no? It uses an EOL version of libfuse and isn't being actively updated. Or am I wrong?
<pauldoo>
I've always preferred Flatpak+Flathub.
<teepee>
it's a very useful and simple to use option in-between all the other solutions
<teepee>
I'm not sure about the fuse2 / fuse3 issue but right now it's all working fine as far as I can tell
<teepee>
we also do have one of the main developers here in the channel, so if I have issues I know who to poke :-)
<teepee>
flathub has some benefits but also makes some things impossible
<teepee>
or at least difficult to discover by the casual user
<teepee>
try running PrusaSlicer (flatpak) from the OpenSCAD (also flatpak) print button
<teepee>
on the plus side, it's possible, where I don't think there is a way doing that with the Snap
kintel has joined #openscad
Smeef has joined #openscad
<kintel>
I haven't done any container stuff in a long time; I end up mostly doing macOS-related testing and end up doing VMs
<teepee>
right, macos and containers don't mix too well I suppose
mmu_man has quit [Ping timeout: 260 seconds]
<pauldoo>
teepee: indeed, with flatpaks the functionality (and permissions) are starting from zero. Folks are adding portals as required, but there's a way to go. I don't think it was ever correct and good for any application to have the full power of the running user (at least not as a default).
<pauldoo>
So yes there's missing functionality compared to the old model in the short-medium term. But longer term moving to an isolated application model _has_ to be the future. Android and iOS have proven the superior reliability of this I think.
<teepee>
agreed, although I'm not sure having the separately maintained platform packages are the best option
<teepee>
but it's a huge topic to be solved
<pauldoo>
"macos and containers don't mix too well I suppose" <- they do and they don't. Containers are often the _only_ choice for development on macOS (since so much software targets Linux platforms), so macOS tools often expect you to be using containers for development.
<pauldoo>
teepee: agreed.
<teepee>
I mostly meant for 'native' dev, for linux targets it might be a good option
mmu_man has joined #openscad
<pauldoo>
though what do you mean by "separately maintained platform packages"? I much prefer the idea of a shared set of these maintained by flathub across distro, than having every one of 1000 different distros having to maintain their own set.
<teepee>
after many cases of getting kneecapped by apple, I decided to stop caring too much
<teepee>
well, maybe the actual core packages are well maintained
<teepee>
but all the other dependencies are put on the application devs
<teepee>
good if those can do a good job
<teepee>
very bad in many many cases for small one developer apps
<pauldoo>
I'm betting on a future where the OS is well separated from apps. Apps are in containers and don't mingle with OS packages at all. That's how we get to a reliable Linux desktop.
<pauldoo>
Modern tools help manage dependencies on the language side (e.g Cargo for Rust). I'm less familiar with modern tools for the C++ ecosystem.
<teepee>
yeah, I too suspect that's a reasonable and maybe needed distinction
<teepee>
manage on dev side
<teepee>
it's about security fixes on an installed distro
<teepee>
debian releases security fixes - those are not covering Snap, AppImage (mostly) or Flatpak
<pauldoo>
Two parts to that:
<pauldoo>
1) security is improved with containerisation and limited permissions. It doesn't scale trying to make sure every dependency of every app is up to date. That would never work for legacy software you might want to run (an old game, emulator, etc).
<pauldoo>
Far better to use containers, which are effectively like bulkheads in the hull of a ship. Assume something will be vulnerable, so limit the blast radius. don't let apps read your entire home directory and have network access by default, for example.
<pauldoo>
2) Most apps if containerised will be pulling some recent-ish debian or ubuntu, and getting the same security updates you speak of via their CI/CD that rebuilds the app container.
<pauldoo>
At least the app maintainer can control special cases of pinning compatible versions of libraries, chosing when to update their base image, and so on.
<teepee>
*if* they are rebuilt
<teepee>
Snap notifies to do that
<teepee>
Flatpak does not
<teepee>
hmm, where is my openscad-nightly package on raspberry :(
<pauldoo>
If they are not rebuilt, and it's abandoned and unmaintained software, users can continue to run the app and at least still get some protection from the container restrictions.
<teepee>
depending on the app, it would be indeed a relatively safe option (e.g. no network access)
<pauldoo>
There's plenty of not-actively-maintained packages in debian and the ubuntu universe repositories. I would much rather those got deleted and those distros focused on an actively maintained core set.
<pauldoo>
I cringe when I see distros brag on their homepage about the number of packages they have.
<teepee>
I assume they would be directly removed in case a security issue is found and not fixed. debian has a separate security team for those cases
<pauldoo>
I just don't believe there are enough people looking at all those old (and sometimes disto patched) packages, checking for vulnerabilities. Many of them are maintained by volunteers who repackaged the upstream thing, and are no longer actively maintaining the distro package.
<pauldoo>
It just doesn't scale either: to have every distro repackage every piece of software, and to expect all software that needs to run on a specific distro to make use of the same exact versions of libraries (within a major version at least). It should be decoupled.
<pauldoo>
Let developers use build tools and package repositories (pypi, cargo, npm) to pull in what they know they need, slap it into a container independent of the OS and other apps. Shrink the OS to make it actually robust and maintainble.
<pauldoo>
See again iOS and Android proving this works, and is reliable.
<pauldoo>
sorry for ranting
<pauldoo>
:) - I'm just "all in" on this idea of the modern linux desktop.
<teepee>
I was considering mailing the note that no communication makes acceptance pretty unlikely
<InPhase>
Did the gsoc program emphasize to applicants that they should attempt engagement?
<InPhase>
Some years this was clearly emphasized.
<kintel>
I think very much so, at least the BRL-CAD org does.
<InPhase>
It is a different mindset from, say, job applications.
<InPhase>
So it does take explicit pointing out.
<kintel>
With the rise of LLMs, I think applications themselves should bear even less weight than earlier.
<InPhase>
kintel: Without dumping too much detail on channel, let me say I've seen normal job position applicants at work, who have no underlying skills corresponding to their prior projects or resume contents, due to LLM usage. So we certainly need to interact with candidates now more than previously.
<InPhase>
A well phrased application can no longer be interpreted as clear ability to do work.
<InPhase>
I don't want a GSoC applicant who intends to just be an LLM operator for us.
<kintel>
yeah, resumes kind of need to contain links to testable artifacts, or references
<InPhase>
I've personally gotten some merit out of getting LLMs to generate examples, but if people are just flat out making code that way, quality will be way off, and ability to communicate competently about what needs fixed will not even be there.
<InPhase>
So, we'll need to monitor for the "everything else" skills being present or absent in candidates. Even working artifacts are not necessarily the indicator that they once were.
<InPhase>
I assume you both agree on the why, so I'm only talking about the need for us to check carefully somehow. :)
<kintel>
In the future I believe there will be some merit to being an LLM operator, as an entry level engineer, but we're not quite there yet, as we first need to figure out how to avoid generating tons of extra work on the people reviewing and maintaining junior engineer's output first.
<InPhase>
Yeah. That review process gets much worse if it doesn't lead to learning.
mmu_man has quit [Ping timeout: 252 seconds]
<InPhase>
I typically envision the first submissions as mentoring opportunities. You can't mentor an LLM operator who doesn't even know how to create the first submission without the LLM.
<kintel>
yeah, people using LLMs need to assume an extra role which is mentoring and reviewing the LLM according to best practices, which takes a _lot_ of discipline
<InPhase>
And background knowledge.
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mmu_man has joined #openscad
kintel has joined #openscad
guso78k has joined #openscad
<guso78k>
Today I tried to try the WASM build with emcmake but i even failed on the dependencies. Is there some instructions/tutorial available ?