2024-12-06 08:24:31 <lilo_booter > huh? how come this does not work with gforth 0.7.9? s" /tmp/out.ppm" w/o create-file throw ... no error is thrown, but file is created - if i use a directory other than /tmp it's fine
2024-12-06 08:25:12 <lilo_booter > gah - that should read "but no file is created"
2024-12-06 08:30:57 <lilo_booter > the /tmp dir has normal 777 permissions - and even if it was a permissions error, that should be reflected by the error code/throw
2024-12-06 08:58:52 <lilo_booter > jeez - and when i spawn python3 from the snap provided gforth on ubuntu 24.04, i end up with another python3 build which lacks the tkinter stuff - utter nonsense - guess i will write a gforth wrapper around sdl2 then
2024-12-06 09:02:27 <lilo_booter > or maybe just giving up on gforth altogether is an even better option :)
2024-12-06 09:53:47 <veltas      > lilo_booter: Are you closing the file?
2024-12-06 09:54:24 <veltas      > I'm not sure whether the file appears until it's been closed/written
2024-12-06 09:55:14 <veltas      > And that might have something to do with it being a shared directory rather than owned by current user (?)
2024-12-06 09:55:21 <veltas      > No idea
2024-12-06 10:02:51 <veltas      > Hmm on 0.7.3 it just creates a file in /tmp so might be a bug in your snapshot
2024-12-06 10:03:46 <veltas      > I would personally just read the code, i.e. LOCATE CREATE-FILE
2024-12-06 10:06:20 <lilo_booter > veltas: yeah - it definitely should create the file immediately - it does everywhere else (where i have permissions anyway) - writing and closing make no difference anyway -
2024-12-06 10:10:53 <lilo_booter > seems somewhat opaque - does some handling/conversion of the string, then calls wfileid = opencreate_file(string, wfam, O_CREAT|O_TRUNC, &wior);
2024-12-06 10:12:02 <lilo_booter > nothing specific about /tmp in what's shown and i guess i'd need to dig into the gforth source to see more
2024-12-06 10:15:56 <lilo_booter > checked gforth mailing list - doesn't seem to have been reported
2024-12-06 10:18:12 <lilo_booter > cloning the git repo to take a look
2024-12-06 10:22:56 <lilo_booter > fd = open(s, flags|ufileattr[wfam & 0x0F], (wfam >> 4) ^ 0666);
2024-12-06 10:29:25 <lilo_booter > flags comes out as O_CREAT|O_TRUNC|O_WRONLY|O_BINARY - which looks reasonable - perms are 0 ^ 0666
2024-12-06 10:33:16 <lilo_booter > hmm - no - wait - was is O_BINARY?
2024-12-06 10:35:25 <lilo_booter > 0 - defined in engine/main.c - fine
2024-12-06 10:36:54 <lilo_booter > int fd = open( "/tmp/out.ppm", O_CREAT|O_TRUNC|O_WRONLY, 0 ^ 0666 ); <- one liner is sufficient to create the file
2024-12-06 10:39:04 <lilo_booter > guess i'll have to build locally and drop the snap
2024-12-06 10:39:30 <veltas      > I don't know how snaps work, is it possible the snap is interfering?
2024-12-06 10:39:46 <veltas      > They're not running in some special environment or anything?
2024-12-06 10:40:06 <GeDaMo      > I have Firefox in a Snap, it's not allowed to access /tmp
2024-12-06 10:40:11 <lilo_booter > possible - i know that when i tried to force it to load the /usr/bin/python3 version, i still ended up with their crap
2024-12-06 10:40:18 <lilo_booter > ah :)
2024-12-06 10:40:51 <veltas      > I said this thinking it was a dumb comment, but apparently it's true lol
2024-12-06 10:41:04 <lilo_booter > certainly clarifies things :)
2024-12-06 10:41:08 <veltas      > I feel vindicated for all my dumb uneducated comments
2024-12-06 10:41:14 <lilo_booter > :D
2024-12-06 10:41:21 <lilo_booter > they're always welcome :)
2024-12-06 10:41:23 <GeDaMo      > I hit it occasionally when trying to view downloaded PDFs in Firefox
2024-12-06 10:41:54 <lilo_booter > cool - thanks - i guess that explains both issues then
2024-12-06 10:42:00 <GeDaMo      > "snaps use a per-app  /tmp, there is no way to access the hosts /tmp directory easily to  prevent snaps from stealing data of other running applications" https://forum.snapcraft.io/t/accessing-tmp-from-snaps/22384
2024-12-06 10:42:22 <veltas      > But further down it says they 'see' their own /tmp
2024-12-06 10:42:40 <GeDaMo      > Oh, I know, it's when it's PDFs exported from email
2024-12-06 10:42:42 <veltas      > So it is created somewhere per-snap, but where I dont' know
2024-12-06 10:42:55 <GeDaMo      > So the email program stores inthe global /tmp but Firefox can't access it
2024-12-06 10:43:09 <veltas      > Ah
2024-12-06 10:43:34 <veltas      > And so the snap team have recreated a horrific problem I thought only existed on Windows
2024-12-06 10:43:51 <lilo_booter > well, writing files to /tmp was only a stop gap anyway - ultimately, i just want to write a ppm or png stream to a socket and have a client pick em up/display them
2024-12-06 10:43:55 <veltas      > Of silently redirecting paths for security reasons
2024-12-06 10:44:01 <GeDaMo      > But don't you see? It's more secure! :P
2024-12-06 10:44:06 <lilo_booter > :)
2024-12-06 10:44:27 <veltas      > I used to take pride in saying this was something that "wouldn't happen" in Linux
2024-12-06 10:45:07 <veltas      > The Halcyon days
2024-12-06 10:45:43 <veltas      > So lilo_booter it's not gforth, it's snap
2024-12-06 10:45:51 <lilo_booter > indeed
2024-12-06 10:46:37 <lilo_booter > good to know - and good to know why snap should be avoided in situations like this
2024-12-06 10:49:26 <veltas      > You and me
2024-12-06 10:52:10 <GeDaMo      > I'm moving to a distro that doesn't use Snaps :|
2024-12-06 10:57:30 <lilo_booter > hmm - when it says "per-app" does it mean "per process" or do multiple instances of the gforth snap share the same dir?
2024-12-06 11:02:11 <lilo_booter > shared between all processes - hmm - ok - that at least is somewhat acceptable for scripting-type languages
2024-12-06 11:04:02 <lilo_booter > oh - but i guess it also means that i probably won't be able to access the system installed sdl2 lib in the snap either :)
2024-12-06 11:04:07 <veltas      > GeDaMo: What are you on and moving to?  Ubuntu to Debian or something?
2024-12-06 11:06:08 <veltas      > I'm pretty much settled on Debian, I am not too familiar with many distros but Debian has just been what's worked best for me
2024-12-06 11:10:53 <GeDaMo      > I've been using Lubuntu for a long time, I'm going to give Devuan a try
2024-12-06 11:11:05 <GeDaMo      > It's a Debian without snaps or systemd
2024-12-06 11:39:24 <veltas      > I didn't think a normal Debian install had snaps
2024-12-06 11:39:29 <veltas      > Or at least I hadn't noticed
2024-12-06 11:39:44 <veltas      > Let me know how it goes
2024-12-06 11:40:06 <GeDaMo      > No, I don't think Debian has snaps
2024-12-06 11:47:43 <veltas      > I think you can install snaps, I just think none of the normal packages are being replaced by them
2024-12-06 14:14:33 <MrMobius    > systemd was already a thing when I got into Linux. why do so many people hate it?
2024-12-06 14:16:04 <identity    > because they think it's bloated and not-unix-philosophy and whatnot (only one of those things is true, and only partially)
2024-12-06 14:16:34 <GeDaMo      > For me it's more about the way it keeps expanding
2024-12-06 14:16:43 <identity    > it also kind of sucked all the air from the room in regards to linux init systems
2024-12-06 14:35:22 <veltas      > My issue with it is it seems to be related to a lot of non-reasons for stuff like my shutdown stalling or taking a long time
2024-12-06 14:35:40 <veltas      > But on other hand boot/shutdown is a lot faster with systemd when done right
2024-12-06 14:36:25 <veltas      > But on every distro I've tried there are still occasional timeouts that seem more ideological than fundamental
2024-12-06 14:57:57 <zelgomer    > identity: it's because it takes over everything for no good reason, and it was forced down everyone's throats by marketting rather than by merit
2024-12-06 15:00:03 <identity    > zelgomer: i seriously doubt that it was forced on everybody with no merit attached and no good reason, because there are in fact good reasons, but what do i know, i'm currently writing this on a system with no systemd
2024-12-06 15:00:07 <zelgomer    > why the fuck is my init system also a filesystem mounter, an xinetd replacement, a container manager, a network manager, a syslog, and somehow in a way i still don't fully understand involved with efivars?
2024-12-06 15:01:20 <zelgomer    > identity: you twisted what i said. i didn't say it was forced on everybody with no good reason, i said it takes over things with no good reason.
2024-12-06 15:02:24 <identity    > zelgomer: i don't see how that changes the general message
2024-12-06 15:03:08 <lilo_booter > i've never had an issue with systemd - never really noticed it tbh - machine boots - i have browser and a terminal with the normal bash and compiler tools - don't really need much else
2024-12-06 15:04:34 <identity    > "it takes over everything for no good reason, was forced on everybody" and "it takes over everything, was forced on everybody for no good reason" seem like mostly identical ideas, at least to me
2024-12-06 15:05:15 <zelgomer    > that's because you truncated my quote
2024-12-06 15:05:59 <identity    > i don't think i understand the difference, please explain
2024-12-06 15:07:54 <zelgomer    > as for the "it doesn't bother me, i only use my pc for browsing the web" types: respectfully, you have no opinion. you're basically a soccer mom saying you don't get the big deal with the new transmissions, as long as you can pick up your kids after school you're happy. like, yeah, this conversation isn't for you, then
2024-12-06 15:11:27 <zelgomer    > poettering, and systemd by extension, have a horrific track record of dealing with feedback or support. i could dig up the now infamous issue where systemd would mount efivarsfs read-write, leaving it open to errant rm -rf bricking the motherboard, and he actually fought against the issue being his problem. basically adopted a "well just don't do that" position.
2024-12-06 15:14:02 <identity    > if you run rm -rf on efivars and complain that it bricked the motherboard, then that's on you, i wouldn't complain to somebody that my system stopped working after running rm -rf /
2024-12-06 15:16:51 <identity    > while i understand that poettering can be bad at this whole "dealing with feedback" thing, this example is probably not the best one (at least in my opinion), and poettering also received his unfair-share of death threats over systemd
2024-12-06 15:17:10 <zelgomer    > now you're just coming off as contrarian.  do you understand that bugs exist?  do you understand that it's incredibly difficult to /brick hardware/ with a shell bug, and there's a reason for that?
2024-12-06 15:18:12 <zelgomer    > do you understand that this behavior is measurably worse than what we had before?
2024-12-06 15:18:28 <identity    > what did we have before?
2024-12-06 15:19:19 <zelgomer    > usually some sysvinit clone
2024-12-06 15:19:51 <identity    > did sysvinit not mount filesystems in the time before?
2024-12-06 15:20:07 <zelgomer    > no
2024-12-06 15:20:23 <zelgomer    > that wasn't its job, /because it's init/
2024-12-06 15:21:20 <veltas      > Got to agree that removing mounted files in a normal system shouldn't brick your board
2024-12-06 15:21:27 <veltas      > No automatically mounted anyway
2024-12-06 15:22:19 <veltas      > Not just poettering though, whole industry is a lot more carefree about messing up firmware now
2024-12-06 15:22:28 <veltas      > UEFI seems to encourage a lot of this
2024-12-06 15:24:35 <identity    > i think in the 'anti-systemd' camp there is a lot of confusion about what systemd is, and what init is, and the differences between the two
2024-12-06 15:25:27 <identity    > systemd's init doesn't mount filesystems, precisely because it is not init's job!  there is systemd-mount, or whatever it's called, that does that
2024-12-06 15:27:20 <identity    > systemd is a collection of system management daemons, including an init system, and not, in and of itself, merely an init system
2024-12-06 15:29:57 <identity    > iirc the init executable is called 'systemd', so i should have said 'the systemd project' in my previous message
2024-12-06 15:37:11 <veltas      > How could anyone be confused by that
2024-12-06 15:38:03 <identity    > don't ask me, i see a lot of people implying and outright stating that, for some reason
2024-12-06 15:41:54 <zelgomer    > have you ever seen a systemd init deployed without systemd-mount?
2024-12-06 15:42:22 <lilo_booter > zelgomer: lol - i do a lot more with my pc than surf the web :) - funny though :D - most of my stuff is software development, not sysadmin (and i could get equally sniffy about sysadmin types .. but that's not really the kinda thing i do :))
2024-12-06 15:43:37 <identity    > zelgomer: no, i haven't, because that's the whole point of systemd, and that's what i was referring to when i previously said that systemd had sucked the air out of the room in regards to Linux init systems
2024-12-06 15:43:49 <zelgomer    > i'm not a sysadmin either, but i take some interest in how my os works, and my $dayjob has me building small linuxes for embedded devices, so i guess that's adjacent to sysadmin
2024-12-06 15:47:27 <lilo_booter > as long as the os allows me to plugin the hardware i need to use and boots up with it in a usable state, the os is doing its job
2024-12-06 15:47:45 <veltas      > I think if you will accept a qualitative argument, the systemd friction is partly because everything systemd is idiosyncratic
2024-12-06 15:48:30 <veltas      > A big early question was "what's the point"
2024-12-06 15:53:37 <identity    > i'm not sure if 'idiosyncratic' is the word, from where i stand 'opinionated' fits better, but that's kind of besides the point
2024-12-06 15:56:52 <veltas      > I said because I don't want to say "anti-UNIX", or "defying every expectation constantly"
2024-12-06 15:57:26 <veltas      > I mostly pretend it doesn't exist and roll my eyes when it breaks something els
2024-12-06 15:57:41 <veltas      > Faster boot times are nice at least
2024-12-06 16:16:40 <zelgomer    > are boot times really faster though? everybody says this but i haven't noticed it.
2024-12-06 16:17:21 <zelgomer    > in fact i have one laptop that stalls during boot while it's trying to connect to wifi, and i still haven't figured out how to make it quit doing that
2024-12-06 16:17:40 <identity    > they *should* be faster, but there are many factors at play
2024-12-06 16:19:10 <identity    > systemd may be waiting for a connection establishment for some reason, it may be that some service requires it before it can be launched
2024-12-06 16:19:37 <identity    > (and, in turn, something else requires *that* service before the boot process can finish)
2024-12-06 16:22:40 <zelgomer    > and in the end it's probably some geolocation bullshit i never wanted in the first place
2024-12-06 16:25:04 <identity    > i doubt that's geolocation, as far as i know systemd doesn't include that, and it would be weird for a distro to enable that by default anyways
2024-12-06 16:25:24 <veltas      > Pretty sure shutdown is faster too... except when it's not!
2024-12-06 16:25:46 <identity    > everything is fast except when it isn't...
2024-12-06 16:27:03 <zelgomer    > debian installs and enables geoclue by default
2024-12-06 16:27:20 <identity    > huh, i didn't know that
2024-12-06 16:52:04 <veltas      > Only with gnome I think(?)
2024-12-06 16:52:08 <veltas      > Because it's used by gnome
2024-12-06 16:52:34 <veltas      > I would recommend against GNOME
2024-12-06 16:53:08 <zelgomer    > i don't know, somehow it made it onto my systems during a dist-upgrade and i've never installed gnome
2024-12-06 16:53:50 <zelgomer    > i don't even have a display manager installed. i login at the terminal have a .profile that execs startx when it detects i'm logging in on tty1
2024-12-06 17:04:46 <zelgomer    > if i follow apt-cache rdepends --installed, it looks like the reverse dependency chain on my system is: geoclue-2.0 -> libqt5positioning5 -> libqt5webkit5 -> phantomjs -> youtube-dl -> mpv
2024-12-06 17:04:57 <zelgomer    > so not by default, i guess. disregard me, i'm full of shit
2024-12-06 17:08:23 <lilo_booter > i thought youtube-dl was dead - aren't all the cool kids using yt-dlp these days?
2024-12-06 17:09:04 <zelgomer    > yes, i don't know why that's there. i just debootstrapped a fresh chroot and when i install mpv it doesn't pick up youtube-dl
2024-12-06 17:10:02 <GeDaMo      > I installed yt-dlp off of Github, the version in the repositories doesn't get updated often enough
2024-12-06 17:10:02 <zelgomer    > dependencies carried forward from past versions i guess
2024-12-06 17:11:21 <lilo_booter > yeah - me too GeDaMo - nice that always seems to work even if you need to kick it with an --update first
2024-12-06 17:12:19 <GeDaMo      > I tend to only update when it stops working :P
2024-12-06 17:13:17 <lilo_booter > i've downloaded a couple of things which seemed to work at the point of download... only to find out, way, way later, that they're broken for playout
2024-12-06 17:13:46 <GeDaMo      > I haven't seen that
2024-12-06 17:14:42 <GeDaMo      > At least ... not that I know of :|
2024-12-06 17:15:00 <lilo_booter > :) - i could have just been unlucky of course
2024-12-06 17:16:42 <lilo_booter > i'm messing with some software which is all about video editing/playout - and it's very stack oriented... i'll probably push a demo of it here soon (with links to open source repos)
2024-12-06 17:17:29 <lilo_booter > (it will probably be met with zero interest, but umm, it's really fricking cool :D)
2024-12-06 17:34:22 <Zarutian_iPad> AfterEffects forth style?
2024-12-06 17:34:57 <lilo_booter > that seems like a fair description (minus some functionality of course :)) - for background, i developed the library https://www.shotcut.org/ is based on - the library is found here https://www.mltframework.org/ (it uses rpn logic internally) - the new library/toolkit doesn't hide the rpn at all :D
2024-12-06 17:37:13 <lilo_booter > (and it's not really new tbh - been in development/production for the past 20 years... users are like bbc, cnn, fox, etc)
2024-12-06 17:38:14 <lilo_booter > just think it's time to stick to that original lgpl license :D
2024-12-06 17:39:11 <Zarutian_iPad> ya got a loicense but do ya got a permit?
2024-12-06 17:39:38 <lilo_booter > i guess i'll find out
2024-12-06 17:43:21 <veltas      > Sounds interesting to me
2024-12-06 17:44:56 <Zarutian_iPad> just my reflexive response regarding copyrite license discussions
2024-12-06 17:51:09 <lilo_booter > i think your comment is spot on tbh - and i'm kinda hedging my bets a little - the software i'll release was originally publicly released some 15 years back (by my customer) - it has been under heavy development since, but they haven't dropped a release and i'm not forcing it (perfectly fine unless a customer demands it) - i'm kinda giving my customer a 15 year head start iyswim
2024-12-06 17:52:40 <Zarutian_iPad> nifty!
2024-12-06 17:52:48 <lilo_booter > the original 5 year period provides enough for me to play with