| landley | Does devuan have a x86-64-v2 vs v3 policy yet? | 08:48 |
|---|---|---|
| landley | My current laptop is v2, and I bought 4 of them cheap and have only worn out one so far (on the second). | 08:48 |
| landley | Trying to close enough terminal tabs to update from beowulf to daedalus without losing too much state, and wondering if that's the last one I can keep with this hardware... | 08:50 |
| landley | (I remember abandoning fedora when the new boot CD wouldn't boot on the processor I had. That's generally what gets me to switch distros, hardware still works but their new software doesn't.) | 08:51 |
| debdog | landley: how do I figure out whether my CPU is v2 or v3? | 09:25 |
| gnarface | landley: devuan x86* kernels are identical to debian's; as in, they're not even rebuilt or repackaged. they're the same actual kernel packages that debian serves (delivered transparently by http-redirect using the magic of a piece of software called "amprolla") so whatever the policy is, it's the same as debian | 09:25 |
| gnarface | .... and yea, as for that v2 vs v3 thing, that's utterly meaningless terminology to me. i might be able to give you more specifics if you can come up with the actual relevant CPU model number, though as far as i know debian still supports all the 64-bit "amd64" type processors (and it's shocking to hear that fedora would have already obsoleted any of them) | 09:27 |
| gnarface | as far as i know, in fact everything after pentium2 should still work | 09:28 |
| gnarface | *including pentium2 | 09:28 |
| gnarface | and landley one other note: don't upgrade directly from beowulf to daedalus. if you had problems that's most likely why. upgrade beowulf->chimaera->daedalus, in that order. (and this is the same advice debian official gives; don't skip releases during upgrades) | 09:29 |
| gnarface | now what seems more likely is you might have run into a uefi/secure boot compatibility problem, but often you can reconfigure it to make it work (not that i can tell you exactly how from first-hand experience, but if you stick around for a while someone here surely can) | 09:30 |
| gnarface | anyway, happy friday... back to my video games. i'll check in on you a bit later | 09:32 |
| landley | gnarface: pentium2 is 32 bit, this is x86-64 architecture levels. | 09:34 |
| landley | I haven't yet had problems, I'm worried about future issues ala https://youtu.be/TnCkYthXUAc | 09:35 |
| landley | And I do a fresh install when I upgrade distro versions. Full backup and reinstall of /home partition, then check my old docs about what packages to install from a fresh system and update them for current as I hit stuff. | 09:35 |
| landley | (A backup you've never installed from isn't a backup, and an install you can't reproduce is a magic build system.) | 09:36 |
| gnarface | landley: yea, i know, but it was also released a long time ago and i meant chronologically after... anyway i can tell you for sure the 6.1 kernel in daeadlus right now will still boot AMD FX processors, which i suspect is also still earlier than what you're targeting, and like i said, i still think you're more likely to run into a secureboot/uefi configuration issue than a cpu compatibility problem (especially with a | 10:26 |
| gnarface | fresh install) | 10:26 |
| gnarface | ... maybe you know that already, i just mention it to make sure you don't misdiagnose then give up prematurely | 10:26 |
| gnarface | even if i'm wrong about that, the kernel still has source code for it and i can walk you through a comparatively simple rebuild process from the kernel source package | 10:31 |
| gnarface | (i really don't think it'll come to that though) | 10:31 |
| landley | I haven't done the update yet, and don't expect major problems with that, my concern was for the future. | 10:40 |
| landley | Red Hat and Ubuntu and such are doing a thing, others have announced a schedule for doing that thing (2027 etc), I wanted to check if devuan or debian had plans to do that thing. | 10:41 |
| landley | Ala https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-hat-enterprise-linux-10 and https://ubuntu.com/blog/optimising-ubuntu-performance-on-amd64-architecture and so on. | 10:44 |
| landley | Meanwhile suse is doing https://www.theregister.com/2023/03/09/opensuse_finds_x86_64_solution/ instead. | 10:45 |
| gnarface | yuck, well i don't know what's going to happen there, but it hasn't happened as of daedalus so you're still ok for now | 11:27 |
| gnarface | i'm pretty sure that worst case scenario you can still just download the kernel source package, flip a couple config options, and rebuild it | 11:27 |
| DelTomix | unbelievable | 11:28 |
| gnarface | the actual kernel will probably contain support for older cpus for a much longer time regardless of these jokers | 11:28 |
| gnarface | (and it's probably worth mentioning that you can often get away with running a kernel from a prior release with most software) | 11:29 |
| gnarface | s/often/usually/ | 11:30 |
| gnarface | heh, i'd recommend you keep 2 backups of your old beowulf install just for emergencies though | 11:30 |
| gnarface | i have a feeling right after that is about where the whole scene jumped the shark | 11:31 |
| cousin_luigi | A few weeks ago I was talking about radicale with someone in here: who was he? | 15:16 |
| ecxod | I need your help, can you please tell me: what are systemd-standalone-tmpfiles ? | 15:48 |
| n4dir | ecxod: not sure if that helps you https://www.man7.org/linux/man-pages/man8/systemd-tmpfiles.8.html | 16:27 |
| ecxod | I have read this, but I did not understand what it does. | 16:41 |
| gnarface | ecxod: the short version is, someone didn't understand how to use /tmp and reinvented the wheel in a super overcomplicated fashion | 17:38 |
| ecxod | so you think I should purge it? | 17:40 |
| gnarface | i'm surprised it's in devuan to begin with, i can't imagine what would need it... | 17:41 |
| gnarface | maybe they were hoping to get people to use it so they'd get addicted to it or something, but i would recommend learning how to use filesystem permissions in detail instead | 17:43 |
| gnarface | (and if you want it in ram, just mount your /tmp directory as tmpfs) | 17:44 |
| DPA | I think most programs use /tmp/ wrongly. Programs should open temporary files with O_TMPFILE. That way, they won't have any hard links (a name) in the file system. They still use memory from the file system, thought. | 17:46 |
| DPA | The thing that annoys me the most is shells. They don't have most of those nice options for opening files. | 17:46 |
| rwp | ecxod, gnarface, Various packages now have a dependency on systemd-tmpfiles which of course is definitely not available in Devuan so systemd-standalone-tmpfiles was created as a non-systemd implementation of the interface. On Devuan we want to have systemd-standalone-tmpfiles installed to fill the dependency. | 19:50 |
| rwp | Perhaps the implementer should have named it entirely without the systemd part to avoid the inevitable immune response reaction. But regardless of the name it by itself is not systemd and does not pull in more systemd stuff. That's the "standalone" part of the naming. | 19:51 |
| rwp | But I agree completely with gnarface that "someone didn't understand how to use /tmp and reinvented the wheel in a super overcomplicated fashion" which is exactly correct and true. And so they have this alternative interface for using tmpfiles. | 19:52 |
| rwp | It's just an alternative to using mktemp(1) and there is nothing particularly evil about it other than it being a completely different interface. Since it is not worth forking those packages the best thing for everyone is to install systemd-standalone-tmpfiles and allow those packages to use that interface instead of mktemp(1). | 19:54 |
| rwp | And similarly to the above there is systemd-standalone-sysusers for which everything I just said is similarly applicable for installing users. So probably everyone will want to have systemd-standalone-sysusers installed too for the same reason. | 19:55 |
| rwp | systemd-standalone-sysusers is an alternative process to adduser(8) for packages to install users. And so in Devuan systemd-standalone-sysusers can be installed as a standalone non-systemd interface for thsoe packages without us needing to fork those packages. | 19:56 |
| ecxod | rwp, thanks, I just got scared because it say it deletes things :) | 20:09 |
| rwp | ecxod, It was named poorly and should not have had systemd in the name. It's just a standalone implementation. I have dug through it and it is not evil itself though. | 20:17 |
| inky | hello. i am running maemo-leste, it is based on devuan. | 20:20 |
| inky | i was thinking of updating my dino-im from backports, and added bullseye-backports to sources.list. | 20:21 |
| inky | since my system is based on devuan chimaera. | 20:21 |
| inky | am i right to do that? | 20:21 |
| inky | or should i add bookworm-backports? i guess bookworm-backports update bookworm with sid packages? | 20:22 |
| inky | is there devuan specific backports project? | 20:22 |
| ecxod | I right now have some trouble with a selfhosted gitlab-ce, that requires some docker packages (like docker-ce*, docker-compose-plugin and docker-buildx-plugin) and those are not in the devuan repository, and seem to require systemd | 20:22 |
| inky | i guess i cannot update dino from bookworm-backports: https://bpa.st/TIEA | 20:23 |
| debdog | inky: no, I'd go for devuan-backports (although I have no clue about maemo-leste). see https://www.devuan.org/os/packages | 20:23 |
| gnarface | inky: it's daedalus-backports | 20:25 |
| gnarface | inky: in devuan, daedalus is bookworm | 20:25 |
| gnarface | i don't know anything about dino-im so i don't know if it'll work, but confidence is high | 20:26 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!