|
If you're wanting to make the location available immediately after your graphical login, I think you could write a systemd user service or startup application that runs "gio mount URL" where URL is something like sftp://example.com. But I don't have a graphical Linux install to test.
|
#
?
Nov 10, 2023 02:11
|
|
|
|
| # ? May 24, 2024 02:08 |
|
|
busalover posted:I recently discovered ripgrep, and now I want something like that to search through folders of PDFs. Does that exist? https://github.com/phiresky/ripgrep-all
|
|
#
?
Nov 10, 2023 05:00
|
|
|
Subjunctive posted:How much do you like rebooting? code:Thanks for the reply. Step "try it out in a VM?" has been added to the to-do list. I have the impression that it's not great for gaming, which is one reason among many that I use Arch (well, Endeavour). (I'd been using Arch (not Endeavour) since before the Steam Deck was announced. I'm not really sure how true it is, but I always feel like using an adjacent distro means that whatever work Valve does for compatibility and general gaming performance will either apply directly, or have some positive spillover, to my experience.) But I don't always play video games on my desktop and was no stranger to rebooting to Windows when the game I was playing didn't run as well. Might end up doing something like that with NixOS. Who knows!
|
|
#
?
Nov 10, 2023 08:27
|
|
|
If you don't like rebooting, don't work with computers today. Given the frequency of kernel updates, and the effort involved in backporting patches to maintain KBI to the point of being able to do live patching, it's much easier to architect things such that bringing down one system for scheduled maintenance doesn't affect production.
|
|
#
?
Nov 10, 2023 12:15
|
|
|
poo poo, even some of our big iron boxes need occasional reboots. The era of 2000 day uptimes has passed (even with live updates and patches).
|
|
#
?
Nov 10, 2023 12:46
|
|
|
Curiously enough, the topic of live patching came up in one of the FreeBSD channels, and Poul-Henning Kamp pointed out that every single implementation that he knows of (which is definitely more than me, and probably more than most) are built after the "everybody out!" principle whereby no single thread can be in a syscall state at the moment the livepatching happens and that gets into all sorts of fun scenarios with ordering of threads to avoid broken pipes from errno 32 assuming the live patching doesn't fail. It also has the fun side-effect that blocking syscalls suddenly aren't, and to me that sounds like the kind of Fun you can have in Dwarf Fortress, which probably isn't what most people want in production? Then again, people put k8s into production, so maybe they have a fetish...
|
|
#
?
Nov 10, 2023 14:27
|
|
|
I architected my on-prem cloud to just assume anything can reboot at any time. Actually, I set it up so that any machine might spontaneously rebuild itself from scratch at any time. Then I wrote a little script to pick a random machine or two every morning and force rebuild it, so we would notice if something couldn't handle that. I assumed this sort of architecture was standard practice these days. It took months to get into place, but now when the electrician accidentally turns off power to a whole rack, we just tell users "might be a bit slower than usual until they turn power back on". I used to marvel at these Linux admins boasting about 600 day uptimes. Like, buddy, everyone knows Linux is stable now. Maybe let's talk about security updates and resiliency.
|
|
#
?
Nov 10, 2023 16:14
|
|
|
Vavrek posted:Uh, You only have to reboot to fully set the rebuilt os into the system. most packages and such will appear after the rebuild in the live system. I game on it too. proton and Nvidia proprietary drivers work and I get great performance
|
|
#
?
Nov 10, 2023 16:44
|
|
|
BlankSystemDaemon posted:Then again, people put k8s into production, so maybe they have a fetish... They were tricked and deserve our pity.
|
|
#
?
Nov 10, 2023 20:00
|
|
|
BlankSystemDaemon posted:Curiously enough, the topic of live patching came up in one of the FreeBSD channels, and Poul-Henning Kamp pointed out that every single implementation that he knows of (which is definitely more than me, and probably more than most) are built after the "everybody out!" principle whereby no single thread can be in a syscall state at the moment the livepatching happens and that gets into all sorts of fun scenarios with ordering of threads to avoid broken pipes from errno 32 assuming the live patching doesn't fail. And that only covers the kernel. How do I livepatch Systemd, OpenSSL or Nginx? ziasquinn posted:You only have to reboot to fully set the rebuilt os into the system. most packages and such will appear after the rebuild in the live system. I'm sure you can update everything, but how do you actually activate the updated software without rebooting? SUSE has a command 'zypper ps' that you can run after update and it will list all the processes that need to be restarted because some library received an update. Every time I had used that command it has produced such a long list I've concluded that a reboot is the only practical option.
|
|
#
?
Nov 10, 2023 21:20
|
|
|
ziasquinn posted:I game on it too. proton and Nvidia proprietary drivers work and I get great performance Good lord. I'm moving "toy around with it in a VM" up a few ranks on the list. ("Actually clean out my closet, ever" is still the top of the list. This is part of a weeks-long deep cleaning I've been doing. So much dust. So close to completing phase one. So many true crime podcast episodes ...) Anyway, that's promising. I'm always a little unsure ... you know, behind the set of "KDE, Wayland, Pipewire, Mesa" I'm using, what the characteristic traits of one distro versus another are. This is part of what I like about Arch, the minimalism of "what is the distro itself?". The rolling release structure is what drew me to it, and when I read up on why partial upgrades were unsupported, it got me thinking: "I know this would be some kind of nightmare of constantly tracking compatibility, but has anybody just made a distro or package manager that always specified exact package versions for everything and just kept every one of them installed as long as they were required, instead of saying "well foo_v1 requires bar_v2.(>1) and if you upgrade to bar_v3 it breaks that dependency ..."?" And the answer was: yeah, actually, it's called NixOS.
|
|
#
?
Nov 11, 2023 01:17
|
|
|
(At least for nginx on Linux it wouldn’t be that hard to let nginx start up and take control of the already-bound listening socket, and then let the previous instance gracefully terminate when the requests finish.)
|
|
#
?
Nov 11, 2023 04:13
|
|
|
Saukkis posted:And that only covers the kernel. How do I livepatch Systemd, OpenSSL or Nginx? Yeah I just mean like, if you want Krita you can rebuild and it'll appear in your app list but usually I just reboot after fully updating anything else
|
|
#
?
Nov 11, 2023 04:27
|
|
|
Vavrek posted:Good lord. I'm moving "toy around with it in a VM" up a few ranks on the list. I know this isn't really what you mean but you can also use unstable nixos that let's you get a rolling release
|
|
#
?
Nov 11, 2023 04:28
|
|
|
ziasquinn posted:I know this isn't really what you mean but you can also use unstable nixos that let's you get a rolling release What I'm getting at about a rolling release is that at some point (2018?) I was considering switching from Windows to Linux and was comparing distros, investigating what I might want to try out, and was checking what the upgrade instructions were for ... Mint, maybe? Like, if I'm going from Mint N to Mint N+1, how well does the system handle an in-place update/upgrade/upwhatever. And the instructions which I found were just "Here's how to copy all your personal files to a backup, then reformat and install Mint N+1 fresh!" What this told me is that the distro (I don't remember if it was actually Mint) didn't support the kind of in-place upgrade that I was thinking of at all. Poking around looking for alternatives, I found Netrunner Rolling in early 2019, basically just before it was discontinued. I continued on using Windows until I started bouncing back and forth between Windows 10 and purestrain Arch sometime in ... mid-2020? It's hazy. You know, it was sometime in March 2020. Diving into "so wait, how does this thing work?" is part of the "toy with it in a VM" process. Thanks for the heads up about the unstable channel.
|
|
#
?
Nov 11, 2023 07:57
|
|
|
I ran PCLinuxOS for years, which is a rolling release that originally was forked off Mandrake  .Currently I have one desktop running OpenSUSE 15.4, and the other running OpenSUSE Tumbleweed, and I've honestly been thinking of switching the 15.4 to Tumbleweed, too. I've done in-place upgrades with OpenSUSE point releases in the past, and at this point they are pretty painless (aside from having to tidy up repositories afterward), but Tumbleweed has been running like a champ for a long time now for me. The sheer number of updates can get annoying, which I think is going to be true of any rolling release, they have made it way more stable and predictable than it used to be.
|
|
#
?
Nov 11, 2023 12:34
|
|
|
These days, a +1 or LTS to LTS update is usually uneventful on the big distros, so as long as you stay on top of that it should be fine. Longer jumps can be a huge mess, though.
|
|
#
?
Nov 11, 2023 13:13
|
|
|
Subjunctive posted:(At least for nginx on Linux it wouldn’t be that hard to let nginx start up and take control of the already-bound listening socket, and then let the previous instance gracefully terminate when the requests finish.) nginx already does that now, you send it USR2 then WINCH http://nginx.org/en/docs/control.html. it'll start a new master process and workers while not killing old workers so they can finish current requests before they exit pretty sure distro package managers have been doing it for a while now, i'm only really familiar with debian servers but it's been the case there at least Truga fucked around with this message at 13:40 on Nov 11, 2023 |
|
#
?
Nov 11, 2023 13:38
|
|
|
Saukkis posted:And that only covers the kernel. How do I livepatch Systemd, OpenSSL or Nginx? Updating the rest of the system isn't an issue, at least for FreeBSD - because we have reboot -r which lets you reroot the filesystem to a new place by adjusting vfs.root.mountfrom (the kernel environment variable OID that gets set in /boot/loader.conf to indicate the root filesystem during boot). Rebooting daemons shouldn't take a long time, and System500 should be capable of what daemon(8) can do. But again, it's not really an issue - because a good infrastructure architect will have active-active or active-backup failover for the services that need uptimes high enough to justify live-patching, without risking all the issues I mentioned above. EDIT: If memory serves, rerooting was added for doing readonly-netboot to NFS, but can be repurposed if FreeBSD ever gets live-patching. BlankSystemDaemon fucked around with this message at 19:45 on Nov 11, 2023 |
|
#
?
Nov 11, 2023 19:40
|
|
|
BlankSystemDaemon posted:Updating the rest of the system isn't an issue, at least for FreeBSD - because we have reboot -r which lets you reroot the filesystem to a new place by adjusting vfs.root.mountfrom (the kernel environment variable OID that gets set in /boot/loader.conf to indicate the root filesystem during boot). Linux has a pivot_root system call that I think does something similar? In early userspace, / is mounted from a (typically) compressed CPIO archive in RAM. This loads a bunch of drivers, mounts things, and (all the ones I've seen) in the final steps, pivot_root to /target or wherever the actual root is mounted, and exec /sbin/init. Is that similar to the FreeBSD mechanism? This sort of stuff is interesting to me 
|
|
#
?
Nov 11, 2023 19:54
|
|
|
Yeah, Linux can pivot root too, and most systems I think do so during boot to pivot from the ramfs to the actual root fs.
|
|
#
?
Nov 11, 2023 19:54
|
|
|
Subjunctive posted:Yeah, Linux can pivot root too, and most systems I think do so during boot to pivot from the ramfs to the actual root fs. I don't suppose there's anything preventing from pivoting more than once. Is this how live-patching kernels work, typically? Seems like a good idea to kill everything, unmount everything, pivot back to the initrd (ramfs), then patch the kernel and re-run the ramfs init. But at that point, you may as well just load the new kernel into a different RAM segment, pass control to it, and not bother with "live-patching" anything. This would just be a less-expensive soft reboot.
|
|
#
?
Nov 11, 2023 19:57
|
|
|
I’ve never believed in live-patching of kernels enough to find out what the operational mechanics are, but I’m pretty sure you can pivot multiple times. Possibly some configurations or overlays or mounts would need to be unrolled first? E: there was a great site with lots of detail about the Linux boot process but I can’t find it on my phone at the moment, hmm
|
|
#
?
Nov 11, 2023 20:03
|
|
|
Subjunctive posted:E: there was a great site with lots of detail about the Linux boot process but I can’t find it on my phone at the moment, hmm Maybe this. https://0xax.gitbooks.io/linux-insides/content/
|
|
#
?
Nov 11, 2023 20:10
|
|
|
Subjunctive posted:there was a great site with lots of detail about the Linux boot process but I can’t find it on my phone at the moment, hmm I learned everything I needed to roll my own initrd and distro from the early userspace doc in the kernel source, maybe it was that? e: no, that's not what I read. Can't find it now, LOL. ee: maybe https://docs.kernel.org/admin-guide/initrd.html cruft fucked around with this message at 20:19 on Nov 11, 2023 |
|
#
?
Nov 11, 2023 20:17
|
|
|
BlankSystemDaemon posted:The use-case for live-patching is that POSTing most systems with an absolute fuckload of memory takes a long time, as memory context restore is usually turned off because it gets better system stability and re-training the memory takes forever. AIX skirts a lot of this since Power5 through making everything under control of the hypervisor, even a single partition system is still an LPAR. The upshot of this is that a reboot of the OS skips all the memory and hardware checks, and you only need to do that kind of stuff now for system firmware updates, and even then only when you jump releases. Sure beats the hell out of a Power4 reboot which took a minimum of 25 minutes before the handoff to the OS even with the bare minimum of RAM, etc.
|
|
#
?
Nov 11, 2023 21:13
|
|
|
I feel like live patching is probably not very useful for a high availability service anyway. You're going to want duplication of services so it can handle one becoming unresponsive and to allow load balancing anyway. And that gets you the ability to restart for safe updates for free.
|
|
#
?
Nov 11, 2023 21:30
|
|
|
Truga posted:nginx already does that now, you send it USR2 then WINCH http://nginx.org/en/docs/control.html. it'll start a new master process and workers while not killing old workers so they can finish current requests before they exit See also Apache's graceful restart, which has also done this since 1998.
|
|
#
?
Nov 11, 2023 21:44
|
|
|
Yes exactly that, thank you!
|
|
#
?
Nov 11, 2023 22:45
|
|
|
cruft posted:Linux has a pivot_root system call that I think does something similar? In early userspace, / is mounted from a (typically) compressed CPIO archive in RAM. This loads a bunch of drivers, mounts things, and (all the ones I've seen) in the final steps, pivot_root to /target or wherever the actual root is mounted, and exec /sbin/init. If you're interested, reroot was added in 0d3d0cc3588 and 3f5ac575ea12 and NFS support was added in 0d1654c39b0. Subjunctive posted:Yeah, Linux can pivot root too, and most systems I think do so during boot to pivot from the ramfs to the actual root fs. Linux, and therefore EXT4 and other filesystems, is not KBI stable from the point of view of loaders that support Linux - because all Linus cares about is not breaking userspace. cruft posted:I don't suppose there's anything preventing from pivoting more than once. Is this how live-patching kernels work, typically? Seems like a good idea to kill everything, unmount everything, pivot back to the initrd (ramfs), then patch the kernel and re-run the ramfs init. But at that point, you may as well just load the new kernel into a different RAM segment, pass control to it, and not bother with "live-patching" anything. This would just be a less-expensive soft reboot. Subjunctive posted:I’ve never believed in live-patching of kernels enough to find out what the operational mechanics are, but I’m pretty sure you can pivot multiple times. Possibly some configurations or overlays or mounts would need to be unrolled first? AlexDeGruven posted:AIX skirts a lot of this since Power5 through making everything under control of the hypervisor, even a single partition system is still an LPAR. The upshot of this is that a reboot of the OS skips all the memory and hardware checks, and you only need to do that kind of stuff now for system firmware updates, and even then only when you jump releases. It also requires you to have hardware-accelerated virtualization, and x86 and derivatives didn't have that for a long time.
|
|
#
?
Nov 11, 2023 23:21
|
|
|
BlankSystemDaemon posted:No, Linux is kinda unique in that its initrd exists in the first place - most bootloaders are included as part of the whole OS development, so they can read the filesystem. Sorry, yeah, I meant that most Linux systems pivot root as part of boot. It’s the Linux thread! I’m allowed to do that!
|
|
#
?
Nov 11, 2023 23:45
|
|
|
Subjunctive posted:Sorry, yeah, I meant that most Linux systems pivot root as part of boot. It’s the Linux thread! I’m allowed to do that! I'm sorry, but I'm still going to have to dock 20 points from your FreeBSD score.
|
|
#
?
Nov 11, 2023 23:48
|
|
|
cruft posted:I'm sorry, but I'm still going to have to dock 20 points from your FreeBSD score.
|
|
#
?
Nov 12, 2023 00:02
|
|
|
cruft posted:But at that point, you may as well just load the new kernel into a different RAM segment, pass control to it, and not bother with "live-patching" anything. BlankSystemDaemon posted:No, Linux is kinda unique in that its initrd exists in the first place - most bootloaders are included as part of the whole OS development, so they can read the filesystem.
|
|
#
?
Nov 12, 2023 06:27
|
|
|
ExcessBLarg! posted:That's exactly what kexec does.
|
|
#
?
Nov 12, 2023 09:29
|
|
|
quote:The currently supported filesystem types are Amiga Fast FileSystem (AFFS), AtheOS fs, BeFS, BtrFS (including raid0, raid1, raid10, gzip and lzo), cpio (little- and big-endian bin, odc and newc variants), Linux ext2/ext3/ext4, DOS FAT12/FAT16/FAT32, exFAT, F2FS, HFS, HFS+, ISO9660 (including Joliet, Rock-ridge and multi-chunk files), JFS, Minix fs (versions 1, 2 and 3), nilfs2, NTFS (including compression), ReiserFS, ROMFS, Amiga Smart FileSystem (SFS), Squash4, tar, UDF, BSD UFS/UFS2, XFS, and ZFS (including lzjb, gzip, zle, mirror, stripe, raidz1/2/3 and encryption in AES-CCM and AES-GCM). I mean of course grub supports filesystems, it has to get the initrd image from somewhere right?
|
|
#
?
Nov 12, 2023 11:01
|
|
|
BlankSystemDaemon posted:How’s NTFS, XFS, BTRFS, BcacheFS, and possibly ZFS support? If you're on a UEFi system and don't like GRUB (or Shim+GRUB) and you don't need to use Microsoft's secure boot keys, then you can just put the kernel and initrd in the ESP (which is required anyways) and boot using EFISTUB.
|
|
#
?
Nov 12, 2023 12:25
|
|
|
ofc the week I'm evangelizing Nixos I end up back on arch, my mother-distro
|
|
#
?
Nov 13, 2023 02:50
|
|
|
ziasquinn posted:ofc the week I'm evangelizing Nixos I end up back on arch, my mother-distro So.. thanks!
|
|
#
?
Nov 13, 2023 14:23
|
|
|
|
| # ? May 24, 2024 02:08 |
|
|
Speaking of arch, is anyone using arch (or endeavour) having issues with system updates / package management related to the KDE 5->6 changeover? Like needing manual intervention when updating because Kdoodad got renamed to Kdoodad5, and some other K-package still wants the old name as a dependency. So instead of just pacman -Syu and walk away, you gotta look at things and force some changes. Trying to figure out if this is a general Arch problem, or something that Manjaro in particular is bungling. I just hit a separate thing where I need to do some system surgery*, and while I'm not exactly eager to switch distros it might be a good time to do so. *(My /boot partition is only 300mb, which is now too tight to do kernel changes without rebooting to LTS, removing 6.5, installing 6.6, and rebooting again. Manjaro takes no blame for this one, I did that myself by manually setting up partitions and looking at old info that said 300mb was standard.)
|
|
#
?
Nov 13, 2023 15:12
|
|
