<zorz>
It's almost like polishing a toilet bowl.... Almost????
<zorz>
ukky: not might a lot!!!!
<ukky>
zorz: but my point is why Crux has to use big guns (bash) to execute tiny boot script?
<ukky>
but this is not really a question. Developers use whatever they see fit.
<farkuhar>
Is there a smaller gun than bash that still has support for arrays like SERVICES?
<farkuhar>
oksh can handle arrays, but it's still a "big gun" compared to dash. And there's no conceivable way that oksh will displace bash from core, in light of what most CRUX users are familiar with.
<ukky>
farkuhar: I don't think so. But script can be adjusted to handle multi-token string instead of '()' array.
<farkuhar>
So if you want to eradicate the bash dependency in rc scripts, you have to propose an alternative to the SERVICES array. Multi-token string is a good start, but will everyone agree with using whitespace as the field separator?
<ukky>
btw, any non-/etc/rc* script that wants to source/include/process /etc/rc.conf must also be interpreted by bash.
<zorz>
ukky: this reminds me everybody switching in systemd and debian with init at the time was faster to boot
<zorz>
because of dash
<zorz>
hahaha
<ukky>
zorz: SystemD is not fastest to boot. runit can beat SystemD easily.
<zorz>
ooo yes
<zorz>
from the time i used runit cannot go elsewhere ukky
<ukky>
SystemD is Microsoft-style operating system
<ukky>
zorz: me too. runit since I switched to it. I cannot use anything else.
<ukky>
I checked out 's6' too, but then dropped it after I saw it uses some pre-compiled binary database to handle services.
<zorz>
ukky let me give you a nice script... you will appreciate it
<ukky>
I don't like dhcpcd, it also becomes an OS, takes too much under the hood. I prefer dhclient, but still use dhcpcd on many systems.
<zorz>
dhclient is good.... but where to find...
<zorz>
its old
<zorz>
i am sure you like tcc
<ukky>
runit is old too
<zorz>
tcc is good compiler.
<zorz>
runit is different.
<ukky>
never tried tcc. I have too much things in my list to switch to...
<zorz>
he stoped developement, but c99 is c99
<ukky>
I run dhclient on my router for many many years (Gentoo)
<zorz>
never used gentoo... lazy to read the manual :P
<ukky>
And my iptables script has 12K lines
<zorz>
i sticked with void, because xbps-src uses namespases. build there and install in the system. plus this hybrid model with binaries and source is very handy.
<zorz>
what!!!!!!!!!!!!!!!!!!!!!!!!!
<zorz>
6k ipv4 6k ipv6
<zorz>
hahahahaha
<ukky>
It is very complex, bacause VPN and stuff
<zorz>
6k you have :)
<ukky>
no, I do not enable IPv6 on my systems.
<zorz>
dont change to nftables.... go directly to eBPF
<zorz>
compile the firewall
<ukky>
iptables is good enough for me.
<zorz>
the only advantage that i see in nftables is that you dont have to write seperate rulles ipv4-6
<zorz>
ukky i really liked in the new kernels the: make hardening.config
<zorz>
you set up a .config for kernel in no time.
<zorz>
okay is not openbsd, but is good.
<ukky>
zorz: Gentoo on my router has hardened kernel and SELinux. But SELinux is in permissive mode now, it is painful to maintain private rules.
<ukky>
All my systems, except for one Debian have customized kernels (.config)
<zorz>
my laptop now in void is kernel is compiled, ALL in unless iwlwifi and amdgpu
zorz has quit [Quit: leaving]
<ukky>
farkuhar: it would be just: for SERVICE in ${SERVICES}; do /bin/echo 'Starting service '\""$SERVICE"\"; ... ; done
<farkuhar>
ukky: yes it would be that simple, if nobody is populating /etc/rc.d with scripts that have spaces in the filename.
<ukky>
only Microsoft Windows user would put space in a file name
<farkuhar>
I'm starting to doubt that all the cosmetic changes in rc 2.32 -> 2.33 were prompted by a session with shellcheck. beerman's new functions BOLD, GREEN, RED are generating numerous shellcheck warnings about incorrect printf usage.
<farkuhar>
Try inlining the new functions in something like printf "$(BOLD "$(RED "[ERROR]")")", and you can see why shellcheck would complain.
<farkuhar>
"It works on my machine" is a pretty low bar to clear. But at least beerman's new functions will be given a predictable set of inputs. The SERVICES array, in contrast, might be populated by a Microsoft Windows convert who thinks it's just fine to create "/etc/rc.d/My Recurring Task" and expect to be able to put it in the SERVICES array.
<farkuhar>
Too bad SiFuh isn't here to notice that IRSSI is not having the intended effect of truncating my posts to a more digestible length.
<ukky>
There should be an error that specified service, /etc/rc.d/My, does not exist. It could be a hint to a new wannabeahacker
<farkuhar>
Heh, `shellcheck -x rc.multi` stopped complaining, after I edited the new function invocations to remove the redundant leading printf: /etc/rc.d/$SYSLOG start &>/dev/null || BOLD "$(RED "[ERROR]")"
<farkuhar>
As I suspected, these cosmetic changes didn't get the benefit of a session with shellcheck.
<ukky>
I cannot see current /etc/rc.multi. Mine is dated 2023-04-09, there is no coloring functions yet in that version.
<ukky>
runit directory in my ports is created on 2023-09-30, that's probably the date I switched to runit.
<farkuhar>
Another way to eliminate the dependency on a shell that supports arrays is to resurrect the old practice of symlinking the startup scripts to a separate directory. Each symlink begins with two digits, and the ordering of the startup/shutdown sequence is inferred from the ordering of these two-digit numbers.
<farkuhar>
I think Debian did something like that, back in the days before systemd.
<farkuhar>
So instead of editing rc.conf to indicate which services are desired at startup, the user would be responsible for maintaining a directory of symlinks. You could argue that the maintenance burden is higher than editing a single text file, but it's an easy way to make rc.multi and friends compatible both with dash *and* with filenames that contain whitespace.
<ukky>
Debian still uses this type of symlinks when you switch to sysvinit or runit
<ukky>
Processing multi-token string in dash/bash would be simpler though and potentially less help requests if things go sideways for the user.
serpente has quit [Remote host closed the connection]
zorz has joined #crux-social
ppetrov^ has joined #crux-social
<farkuhar>
ukky: OpenBSD also resorted to arrays for the /etc/rc.conf pkg_scripts variable (same role as SERVICES in CRUX). They aren't aiming to use the lightest possible shell, as you can see by the early exit messages when ksh is not the interpreter.
<ppetrov^>
my problem with "SERVICES=" is that I should know the right order... which i not always do
<ppetrov^>
but, well...
<farkuhar>
If you really want to avoid arrays (and use dash as the interpreter), you could list the desired startup scripts in a (newline-separated) text file, running them inside a `while read -r $SERVICE_LIST; do ...` loop.OC
<farkuhar>
ppetrov^: I wonder if the scripts themselves could impose conditions on the order in which they're started. Sort of like a dependency list (which Per already demonstrated could be handled in (ba)sh).
<ppetrov^>
no idea... Slackware has a master script where pat put them in the proper order, all you need to do is make the service executable
<farkuhar>
You could also use tsort(1), if each startup script were endowed with an easily-extractable line indicating the other startup scripts, if any, that need to be launched first: https://rosettacode.org/wiki/Topological_sort#UNIX_Shell
<ppetrov^>
too complicated for me, man
<ppetrov^>
but thanks, interesting info
<farkuhar>
The tools/rc repo has been using bash arrays since the very first commit (20 years ago, by jw). That's too long a legacy to abandon so readily, if you want to eliminate the bash dependency in favor of something lighter.
<farkuhar>
Per's March 2004 code also relies on bash arrays. It seems like nobody back then had any hesitation about using the "big guns" for something as simple as a startup script.
<ppetrov^>
farkuhar, have you read the whole history of CRUX development? mailing lists, etc? :)
<farkuhar>
ppetrov^: no. The "whole history" is not a matter of public record, to the extent that individual developers communicated amongst themselves privately, or kept their thoughts and early prototypes out of public view.
<farkuhar>
I think shellcheck and related tools are pushing us away from ukky's "multi-token strings" in favor of arrays, because the splitting of multi-token strings might be broken if a user redefines IFS. Arrays do not suffer from such a disadvantage, and they're easy to embed in a flat-text config file (unlike newline-separated lists, which have to be in their own files).
<farkuhar>
This deprecation of multi-token strings in favor of arrays must have had its proponents as early as 2004, considering that jw and Per went with arrays, thereby restricting the set of valid interpreters to "big guns" like bash.
<farkuhar>
Interestingly, in the August 2006 proposal to support USE flags in pkgmk, heidi's demonstration code employed multi-token strings, even though she obviously must have been aware of the precedent for using arrays. Anton's reply did not criticize her implicit assumption that splitting of multi-token strings at whitespace would create the correct items in the for loop. He already had enough grounds to
<farkuhar>
criticize heidi for violating KISS Pkgfiles.
* farkuhar
finally got IRSSI to demonstate its truncation of long messages
<farkuhar>
s/demonstate/demonstrate/ ... must have been a Freudian slip
<ukky>
farkuhar: I am not trying to force the switch from bash to dash for Crux startup scripts. This is just a discussion what I would do if I develop a new Linux distro, i.e. I would not use bash features. All system scripts should use /bin/sh and it should be up to the user to define whether sh points to dash or bash.
<farkuhar>
ukky: as you noted, the only "bash feature" in the rc scripts is the SERVICES array. But this feature is not unique to bash, and in fact it's also employed in the OpenBSD startup scripts (which have a dependency on ksh).
<farkuhar>
The specific syntax for initializing an array variable is of course different between bash and ksh, so our /etc/rc.conf in its present form can only be sourced by bash or a bash-compatible shell. Meanwhile, if you sequestered the list of startup services in its own (newline-separated) file, then it could be read line-by-line in any POSIX shell.
<farkuhar>
And of course we have the `tac` utility for reading such a newline-separated file in reverse, when it comes time to shut down the services.
<ukky>
farkuhar: I see that OpenBSD uses arrays. Also, OpenBSD uses ksh as default for '/bin/sh'. I.e. ksh, rksh and sh are all hardlinked and point to the same data in filesystem.
<farkuhar>
I'm intrigued by the idea of letting each startup script declare its own dependencies, and generating a topologically-sorted list of scripts based on these dependencies and what the user decides to enable. That way a user like ppetrov^ doesn't have to curate manually a bash array, a newline-separated file, or a directory of symlinks.
<ppetrov^>
users like ppetrov^ are are minority here, most are tech-savvy
<farkuhar>
The footgun here is that a user might not explicitly enable one of the declared dependencies. Then we'd have to decide whether our topological sort would insert them into the startup sequence automatically, or naively trust the user's selection (opening up the possibility of unsatisfied dependencies).
<farkuhar>
There might be only a handful of essential ordering relationships among the startup scripts, i.e., most of them will launch successfully regardless of what other daemons have yet been started. In that case, running tsort(1) at every boot is an example of overdesign.
<zorz>
ppetrov... use rcctl with rcctl completions
<ppetrov^>
rcctl no idea what it is
<zorz>
i wrote it when used crux... wait
<ppetrov^>
zorz, i made a mark of my load orger and i will just stick to this
<farkuhar>
Perhaps the most KISS solution would be a list of services in its own (newline-separated) file. We still reap the advantages of flat-text for configuration, at the expense of distributing the startup configuration among more than one file (rc.conf and the list of services).
<zorz>
this fucking googletrans is a fucking library not posible to use it with pipx
ivandi has quit [Quit: WeeChat 4.5.1]
ivandi has joined #crux-social
<farkuhar>
ukky: in other news, we got the desired rebuild of asciidoctor 12 hours after the issue was opened. That was fast.
SiFuh_Japan has joined #crux-social
SiFuh_Japan has quit [Client Quit]
SiFuh_Japan has joined #crux-social
<SiFuh_Japan>
Hmm not liking here
<SiFuh_Japan>
But still too early to tell
<SiFuh_Japan>
remiliascarlet no phone. SIM not working here
<ppetrov^>
SiFuh_Japan, you're in Japan now?
<SiFuh_Japan>
Yes
<SiFuh_Japan>
The hotel provides 1 coupon per person for beer or non alcoholic drink. My wife shocked when he gave me 4:-P and said don't tell anyone
<zorz>
asahi
<SiFuh_Japan>
Oh and I emptied the Saporo stock on the plane hahaha
<zorz>
hahaha
<zorz>
Saporo+Sifuh+Asahi
<ppetrov^>
SiFuh_Japan, goint to meet with remi?
SiFuh_Japan has quit [Quit: Client closed]
<ukky>
farkuhar: asciidoctor was fixed fast. I had it installed because fvwm3 required it at build time, but now no need for both asciidoctor nor fvwm3.
<farkuhar>
ukky: good to hear that somebody is still playing around with fvwm. Competition in the window manager space leads to a better user experience for all.
<farkuhar>
Window manager is an easy component to swap out. Giving the user a choice among different init-script systems is harder to support.
<farkuhar>
Replacing the SERVICES array with a shell function gets you the best of both worlds: compatibility with dash, and flat-text configuration that isn't distributed among multiple files.
<farkuhar>
Plus you get support for the Microsoft Windows converts who want to populate /etc/rc.d with filenames containing whitespace.
<ppetrov^>
dows anyone know of w WM, where if I have two computer screens, I can set separate virtual desktops for each?
<zorz>
ppetrov^: no
<ppetrov^>
how about awesome wm?
SiFuh_Japan has joined #crux-social
<SiFuh_Japan>
ppetrov^ not sure. Seems she has gone quiet
<ppetrov^>
that lavaguy scared her
<SiFuh_Japan>
I son't think she scares that easily
<ppetrov^>
it was a joke
ppetrov^ has quit [Quit: Leaving]
ppetrov^ has joined #crux-social
ivandi has quit [Quit: WeeChat 4.5.1]
ivandi has joined #crux-social
<farkuhar>
You get dash compatibility by replacing the SERVICES array with a shell function, but at the cost of mixing data and code. The tidy, declarative appearance of rc.conf in its current form owes a lot to the CRUX founders' insistence on using bash as the interpreter. In a way it's similar to how OpenBSD insists on ksh as the interpreter; the scripts throw an early error if $KSH_VERSION is unset.
<ppetrov^>
farkuhar, which linux distro would be most similar to openbsd
<SiFuh_Japan>
None
<ppetrov^>
:(
<SiFuh_Japan>
CRUX is the closest to any BSD
<farkuhar>
To keep rc.conf in its current declarative form, it's enough to stop being opinionated about the interpreter (bash versus dash), and transfer the strong opinions to IFS. Inform the user that the rc-scripts will expect multi-token strings separated by whitespace, and then the "RTFM" reply is warranted when somebody tries putting a whitespace-containing filename under /etc/rc.d
<ppetrov^>
SiFuh_Japan, how about Void?
<ppetrov^>
ah and farkuhar is on fire :)
<SiFuh_Japan>
No chance
<farkuhar>
ppetrov^: It would be irresponsible to immolate myself, when the firefighting forces already have their hands full in Los Angeles.
<ppetrov^>
heh, well sorry if inappropriate use of the phrasal ver
<ppetrov^>
verb
<SiFuh_Japan>
Yeah woth no water
<ukky>
farkuhar: that's my opinion, i.e. RTFM, multi-token string separated by space or tab. /etc/rc.shutdown can recreate list in reverse order.
<ukky>
ppetrov^: Do you want two independent monitors, or just virtual with single video device?
<ukky>
Kiss Linux and Alpine Linux are the closest to *BSD. Crux is in-between *BSD and most Linux distros.
<SiFuh_Japan>
Alpine is not
<ukky>
SiFuh_Japan: could you elaborate?
<SiFuh_Japan>
Alpine is _really_not
<ppetrov^>
ukky, two indepndent monitors, one major with 5 virtual desktops and the second, secondary with just 1 VD
<ppetrov^>
so, i use my main screen as before and have the small one to just hold some stuff always there
<ppetrov^>
but i don't want it to be influenced when I change the VD on the major screen
<ukky>
SiFuh_Japan: 'it is not' is not an argument. Can you point out what feature exactly?
<ppetrov^>
i gave up on that long ago
<SiFuh_Japan>
Alpine feature and I can't rype so much on this ahit phone
<SiFuh_Japan>
As you can see
<ukky>
SiFuh_Japan: Let's postpone this discussion until you get back home.
<SiFuh_Japan>
Sure
<ukky>
SiFuh_Japan: I would be really interested in your feedback.
<ukky>
ppetrov^: Do you have single GPU device with two outputs, or two GPU's?
<farkuhar>
SiFuh_Japan: invite stenur back here for the Alpine discussion. I seem to recall he's an avid user of that distro.
<ppetrov^>
ukky, I have a GPU with 4 outputs AMD RX580
<SiFuh_Japan>
Sure
<SiFuh_Japan>
ukky I have 5 beers
<ppetrov^>
5 virtual desktops, 5 beers...
<farkuhar>
stenur is another user who was dissatisfied with the default behaviour of "prt-get sysup". He wrote his own sysup implementation as a shell script (port_up.sh), rather than patching prt-get as ukky did.
<ukky>
ppetrov^: In one of my setups I have 1 GPU with 3 outputs. I use 3 monitors, all screens are independent. WM is Fluxbox. Each independent monitor has 4 virtual displays.
<ppetrov^>
oh, that sounds about right
<ppetrov^>
so, probably same can be done with openbox that ships with CRUX? I have no idea about xfwm4
<ppetrov^>
how did you configure fluxbox?
<ukky>
ppetrov^: Two of my monitors have the same resolution (HDMI), but one monitor has 1600x1200 resolution. And each monitor has unique DISPLAY variable set, like ":73.2"
<ppetrov^>
ukky, when you change VD on one monitor, do the others change?
<ukky>
ppetrov^: All monitors are independent. You _cannot_ even move a window from one monitor to the other.
<ppetrov^>
ah, well that's incovnenient
<ppetrov^>
how do you move the mouse cursor?
<ukky>
ppetrov^: But you can move windows between virtual desktops on the same screen.
<ppetrov^>
yes, of course
zorz has quit [Quit: leaving]
<ppetrov^>
hmm.... i may check Enlightenment
<ukky>
ppetrov^: I use X, so X moves mouse according your screen's layout.
<farkuhar>
zorz left in embarrassment after being proven wrong about virtual displays on multiple monitors.
<ppetrov^>
what did zorz say?
<farkuhar>
zorz was the first to chime in with an opinion. "Nope, can't be done" is the essence of what he said.
<ppetrov^>
heh
<ukky>
ppetrov^: I prefer independent screens, as each monitor has independent taskbar.
<ppetrov^>
yep
<ppetrov^>
so what do you have in /etc/X11/xorg.conf.d/
<ppetrov^>
or can you point me to some online tutorial
<ppetrov^>
of course I can check Arch wiki
<ukky>
ppetrov^: That system is shutdown (does not boot), will fix it on Monday. I will check what I have available.
<ukky>
I have 26 ports patched in core, 12 ports patched in opt, and 7 ports patched in xorg.
ppetrov^ has quit [Quit: Leaving]
<farkuhar>
ukky: How many of those patches actually change the code or the configuration of the port? I imagine that some of the patches are only there to prevent footprint mismatch errors.
<ukky>
farkuhar: Very little code change. Most changes are related to enable/disable port fetaures, like disable PAM/udev, remove PAM/udev dependencies. New footprints are generated for those ports.
<ukky>
Some Pkgfiles changes are just R&D to create toolchain for i386/x86_64/musl
<farkuhar>
Applying a local patchset after syncing with the upstream ports collection, that's the strategy promoted by deep42thought on an old mailing list post. Nearly everyone else who desires a custom configuration will take the simpler approach of masking the official port with an overlay repository (placed earlier in prt-get.conf).
<ukky>
Yes, I originally just made a copy of a port in overlay, but then tried deep42thought SVN approarch and like it more. But this is not a fully automatic task.
<farkuhar>
Creating an overlay repository involves the extra maintenance task of manual updates, whereas the majority of a local patchset will carry over seamlessly when the official ports get updated. Fixing the handful of patches that fail to carry over is still less work than maintaining an entire overlay of portdups.
<ukky>
farkuhar: You helped me writing shell version of port sync driver. I just changed it for two-stage update process via proxy git repo, used as an intermediate port source.
<ukky>
farkuhar: This is what I experimented with, as an example of core/gcc/Pkgfile: https://0x0.st/8HXq.txt
<farkuhar>
Now I'm curious to see if I still have stenur's port_up.sh script saved somewhere. I think there was something else besides "exit on first failure" that he wanted to add to the sysup algorithm.
<ukky>
Sometimes fixing a single failure requires 'revdep' and rebuilding specific ports (cmake for example)
<SiFuh_Japan>
Oe format ans reinstall :-p
SiFuh_Japan has quit [Quit: Ping timeout (120 seconds)]
SiFuh_Japan has joined #crux-social
ppetrov^ has joined #crux-social
ppetrov^ has quit [Client Quit]
zorz has joined #crux-social
<farkuhar>
Here's the script that stenur wrote as a "prt-get sysup" replacement: https://0x0.st/8HKY.sh
<farkuhar>
It looks like stenur was trying to add some further compartmentalization to the sysup process, such as a clearer boundary between the online processes (downloading sources) and the offline processes (building packages).
<farkuhar>
There's also some logic for restoring from snapshots, and for forcing a rebuild of packages that can be expected to break when llvm is updated.
<farkuhar>
The ease of committing such typos (which shellcheck lets through without any warning) is another reason to avoid bash arrays. Just insist on no support for redefining IFS, and split on whitespace a multi-token string when you need to loop over the list of services.
zorz has quit [Quit: leaving]
<farkuhar>
Note that beerman only introduced the typo into rc.single; he uses correct quoting in rc.shutdown. Given how rare it is to switch to the single-user runlevel, it might have taken a while for the typo to be discovered on a running installation of CRUX 3.8.
<farkuhar>
ukky's CRUX work computer became unbootable after the removal of sysvinit. I wonder why ukky was trying to uninstall sysvinit on that machine, anyway.
<farkuhar>
Hopefully bringing this discussion to some kind of closure ... here are two of the alternatives to bash arrays proposed so far: a list of services split on newlines, https://d.uguu.se/bRGocTXC.sh , or split on whitespace, https://f.uguu.se/HPuOteVc.sh
<farkuhar>
Neither of these proposed alternatives has SiFuh's fixes to the vgchange commands yet; we'll have to wait another week before he can resurrect them from backups. I hope he's enjoying his Japan vacation in the meantime, even if the phone he's using makes it difficult to type English text.
SiFuh_Japan has quit [Quit: Client closed]
ppetrov^ has joined #crux-social
<ukky>
farkuhar: I removed sysvinit because patches were not applied and sysvinit update tried to overwrite /sbin/init. But at the time of file collision I didn't know yet the patches were not applied.
<ukky>
/sbin/init does not belong to runit port either. I have sbin-init-runit port that just creates link /sbin/init -> runit-init
<ukky>
Both sysvinit and runit can co-exist in a single installation. Default can be any of them. Providing, for example, init=/sbin/runit-init as kernel command line in boot loader can select a specific service manager.
<ukky>
Multi-token vs array SERVICES is kinda related as I was trying to source /etc/rc.conf from runit at startup to select system-wide settings and it failed because of bash requirement and I wanted runit scripts dash-compatible.
<ukky>
It's time for me to shut up. No more rant for the next 3 hours.
<farkuhar>
So if I understand ukky's description correctly, /sbin/init on the work computer is a symlink owned by port sbin-init-runit, and `pkgadd -u sysvinit#$version-$release.tar.gz` happily proceeded to overwrite a file owned by another port, without issuing any warning?
<farkuhar>
There were bug reports about pkgadd and pkginfo getting confused regarding symlinks, so this example might be another manifestation of a design flaw in pkgutils. Not anticipating every possible eventuality, as SiFuh might put it.
<farkuhar>
For now the safest measure might be to write a pkgadd INSTALL rule that says UPGRADE ^sbin/init$ NO