|
uh that’s p much proving the point
|
#
?
May 16, 2022 10:13
|
|
|
|
| # ? May 18, 2024 19:23 |
|
|
Wouldn't flatpak and the like solve this issue, if something really needs v.5.7.3 of a dependency for example, couldn't it just say, download 5.7.3 and don't even try to run my software with anything else. I don't know if this is how flatpak works to be fair but that's the impression I've gotten.
|
|
#
?
May 16, 2022 10:36
|
|
|
Kamrat posted:Wouldn't flatpak and the like solve this issue, if something really needs v.5.7.3 of a dependency for example, couldn't it just say, download 5.7.3 and don't even try to run my software with anything else. yes, flatpak lets you package up a userland including libc and run it under an arbitrary modern kernel. it's more or less a container (utilizes namespaces, etc) like docker. the major caveat is that you can't run a new glibc on an old kernel that way, but other way around is just fine. even before the spiffy kernel features that enable flatpak and friends, you could accomplish the same goal (old glibc on a new kernel) via chroot.
|
|
#
?
May 16, 2022 10:54
|
|
|
nudgenudgetilt posted:yes, flatpak lets you package up a userland including libc and run it under an arbitrary modern kernel. it's more or less a container (utilizes namespaces, etc) like docker. the major caveat is that you can't run a new glibc on an old kernel that way, but other way around is just fine. Couldn't you in theory then create a flatpak-installer for the old Loki-games and other old software that hasn't been updated? If this is the case then backwards compatibility is finally a thing and all software released today using flatpak will forever work?
|
|
#
?
May 16, 2022 11:31
|
|
|
you can pretty much cozpop a full userland anywhere you want so long as the binaries know where to look for it but that's not exactly a great solution
|
|
#
?
May 16, 2022 11:58
|
|
|
yeah steam for linux uses containerized runtimes now, because the previous solution was to support a fork of ubuntu from 2012 forever. they use a fork of flatpak for this although idk maybe they're going to reintegrate it with upstream flatpak later. then again it kinda sorta seems to pull in the nvidia or mesa runtime from the host os which makes things complicated.
|
|
#
?
May 16, 2022 12:29
|
|
|
Best Bi Geek Squid posted:“only tux could go to china” gematria: "nixon" is surely the american president with the shortest levenshtein distance from "linux" and if the CCP decides to adopt nix-os specifically it'll be even more blatant that we live in a vm
|
|
#
?
May 16, 2022 12:33
|
|
|
Sapozhnik posted:yeah steam for linux uses containerized runtimes now, because the previous solution was to support a fork of ubuntu from 2012 forever. they use a fork of flatpak for this although idk maybe they're going to reintegrate it with upstream flatpak later. i mean flatpak or no, it's gonna still be linked against a specific library and god help you if the version number changes
|
|
#
?
May 16, 2022 12:42
|
|
|
being a fan of the general idea of software durability is indeed what won me over to container solutions despite them being kind of icky on a technical level. electron clients and big container lump software distribution is hardly sexy, but it is certainly *extremely* good for linux as it solves a lot of longstanging issues while not particularly ruining anything other than nerd peace of mind.
|
|
#
?
May 16, 2022 12:50
|
|
|
Cybernetic Vermin posted:being a fan of the general idea of software durability is indeed what won me over to container solutions despite them being kind of icky on a technical level. electron clients and big container lump software distribution is hardly sexy, but it is certainly *extremely* good for linux as it solves a lot of longstanging issues while not particularly ruining anything other than nerd peace of mind. yeah that's very true. i've gone on about the stupidity of containers within containers being containers all the way down on here before, but i can't deny they're useful af
|
|
#
?
May 16, 2022 12:54
|
|
|
i still want to see the best of both worlds where fedora has its own flatpak repository that repackages upstream apps. those can still be built on top of the freedesktop or gnome flatpak runtimes aka i-can't-believe-it's-not-a-distributions but there needs to be a maintainer. isvs being able to deliver software directly to users without having to go through a distro maintainer first is in fact not a good thing, and nor is flathub by extension.
|
|
#
?
May 16, 2022 15:31
|
|
|
I still find it kind of funny that Flatpak is named so because of Ikea furniture and the original developer's Swedish.
|
|
#
?
May 16, 2022 15:47
|
|
|
yeah i mentioned before that i deployed homebridge on my home server via docker and a systemd unit file running docker-compose (yes i should switch to podman but  )its fantastic, gently caress no am i installing node.js on my actual system, keep that garbage encapsulated and invisible
|
|
#
?
May 16, 2022 16:54
|
|
|
Lysidas posted:(yes i should switch to podman but lol, probably 70% of us still use sysv cron and init because agreed the only good use for node is in a quarantine zone though
|
|
#
?
May 16, 2022 18:20
|
|
|
sysv cron is fine and there's no reason to discard decades of experience and documentation for something shiny if sysv cron does the job well
|
|
#
?
May 16, 2022 19:29
|
|
|
sb hermit posted:sysv cron is fine and there's no reason to discard decades of experience and documentation for something shiny if sysv cron does the job well for real, when people go "wtf why are you using that old poo poo" i never get a satisfactory answer to "well it might be old but why not?"
|
|
#
?
May 16, 2022 19:32
|
|
|
why ship anything on outdated trains when you can air freight everything now?
|
|
#
?
May 16, 2022 19:33
|
|
|
yeah lemme just discard this thing that works perfectly fine and replace it with something that has a billion man pages spread across like ten aliases for the same base binary
|
|
#
?
May 16, 2022 19:34
|
|
|
idk maybe because you want to spawn a systemd unit and all of the process supervision machinery that entails instead of having crond doing a basic-rear end fork/exec maybe you want a retry policy maybe you want to blur the startup time so that you don't have a thundering herd of too many jobs starting up at once maybe you want timezone awareness on some tasks and utc scheduling for others lots of things systemd timers can do that crond can't
|
|
#
?
May 16, 2022 19:54
|
|
|
Sapozhnik posted:isvs being able to deliver software directly to users without having to go through a distro maintainer first is in fact not a good thing, this sure is a take
|
|
#
?
May 16, 2022 20:00
|
|
|
Sapozhnik posted:idk maybe because you want to spawn a systemd unit and all of the process supervision machinery that entails instead of having crond doing a basic-rear end fork/exec there are a lot of different ways to do (almost, process supervision w/o fork/exec being the exception) all of that with cron anyway though? also why would you be using separate time formatting anyway? 
|
|
#
?
May 16, 2022 20:00
|
|
|
no one is saying that systemd timer functionality can be entirely supplanted by cron. But if one line in a crontab will do you good, then there's no need to write a unit file and timer file for systemd there's no need to replace all shell scripts with python files, when the bulk of the work is just chaining pipes and fork/exec
|
|
#
?
May 16, 2022 20:00
|
|
|
cron is hosed up and anybody defending it ityool 2022 is extremely sus
|
|
#
?
May 16, 2022 20:02
|
|
|
sb hermit posted:no one is saying that systemd timer functionality can be entirely supplanted by cron. exactly, i mean in the end we're just basically talking about shell scripts
|
|
#
?
May 16, 2022 20:02
|
|
|
Beeftweeter posted:there are a lot of different ways to do (almost, fork/exec being the exception) all of that with cron anyway though? I think the idea is to execute tasks relative to when the system starts up, rather than on boot itself like a virus scanner or an indexer or whatever
|
|
#
?
May 16, 2022 20:02
|
|
|
sb hermit posted:I think the idea is to execute tasks relative to when the system starts up, rather than on boot itself while i can see that being a use case, not only can you query uptime but the system clock is most likely also utc (unless you're dual booting an old version of windows or something, i guess). so idk, maybe i'm missing something here
|
|
#
?
May 16, 2022 20:06
|
|
|
eschaton posted:this sure is a take your favorite company in the whole wide world agrees with me
|
|
#
?
May 16, 2022 20:07
|
|
|
Beeftweeter posted:while i can see that being a use case, not only can you query uptime but the system clock is most likely also utc (unless you're dual booting an old version of windows or something, i guess). so idk, maybe i'm missing something here I'm not arguing there. But as the script gets complex, the argument starts to form around using systemd timers. I'm content with leaving crontab stuff where they are now, but I'm still open to using systemd timers when it could be beneficial.
|
|
#
?
May 16, 2022 20:12
|
|
|
sb hermit posted:I'm not arguing there. But as the script gets complex, the argument starts to form around using systemd timers. i mean same, it's not like i'm some graybeard that absolutely refuses change lol. i just don't see a reason to change things needlessly
|
|
#
?
May 16, 2022 20:18
|
|
|
Beeftweeter posted:lol, probably 70% of us still use sysv cron and init because
|
|
#
?
May 16, 2022 22:34
|
|
|
if you have to gently caress around with your system's init often enough that you have strong opinions on your system's init you've done something wrong
|
|
#
?
May 16, 2022 22:47
|
|
|
Kazinsal posted:if you have to gently caress around with your system's init often enough that you have strong opinions on your system's init you've done something wrong yeah, exactly. just use gnu screen to run all your production applications!
|
|
#
?
May 16, 2022 22:58
|
|
|
Its almost like there's a middle ground level-handed approach, as in all things  If you got old poo poo that works in cron why update it, run it into dust with the silicon. If you're writing something new and can leverage a lot of the niceties systemd does for free, go hog wild. Who loving cares as long as you don't have to janitor it
|
|
#
?
May 18, 2022 03:02
|
|
|
I guess I need to change a setting so linux will just kill firefox when I run out of memory so I don't have to run to hit alt+sysrq+f as fast as possible when it starts swapping
|
|
#
?
May 18, 2022 04:00
|
|
|
mystes posted:I guess I need to change a setting so linux will just kill firefox when I run out of memory so I don't have to run to hit alt+sysrq+f as fast as possible when it starts swapping or buy some loving ram?
|
|
#
?
May 18, 2022 04:12
|
|
|
how many tabs do you have open? it's ok, this is a safe space.
|
|
#
?
May 18, 2022 04:24
|
|
|
Buck Turgidson posted:how many tabs do you have open? it's ok, this is a safe space.
|
|
#
?
May 18, 2022 04:35
|
|
|
ideally firefox would support dbus activation, that way it could run as a user unit under systemd and have resource limits and io and vm prioritization applied to it. gnome on fedora does have some "cgroupify" thing that makes it run inside a unit anyway but it's not quite as discoverable as having a /usr/lib/systemd/user/org.mozilla.Firefox.service the distribution really ought to set a reasonable resource policy for firefox though, that way whenever firefox has a Little Moment and decides to start dirtying as many pages as it can allocate as quickly as possible it doesn't bring the entire user session down with it.
|
|
#
?
May 18, 2022 10:09
|
|
|
i'm not sure if it's the same thing you guys are talking about, but one of the few things i miss from win10 is being able to instantly and reliably kill apps never had a problem with firefox, but i'm gaming on linux  so i do sometimes have games with so-so proton/wine compatibility that choose to freeze or screw up in some other ways, and it feels like kill -9 is more of a gentle suggestion than anythingon windows even the basic task manager is usually enough to get rid of a misbehaving app, and i've literally never had a program not instantly die to superf4
|
|
#
?
May 18, 2022 10:28
|
|
|
|
| # ? May 18, 2024 19:23 |
|
|
i definitely remember sometimes being unable to kill steam on windows without restarting the whole computer i've never really understood why this is a thing that can happen
|
|
#
?
May 18, 2022 12:55
|
|
