<SiFuh_> Quick vote. Who uses fdisk, cfdisk or parted when installing CRUX?
<farkuhar> cfdisk here (after hdparm security-erasing the spare SSD that contained an installation of OpenBSD 7.4)
<SiFuh_> farkuhar: I am thinking of that old OpenBSD style installer that was made for CRUX that no one used as the installer for Outlaw Linux.
<SiFuh_> I was thinking of fdisk but better to see what everyone else usually uses
<farkuhar> I should reach out to therealfun and ask whether he's interested in joining the effort to return CRUX to its roots. It wasn't too long ago that he made valiant attempts to mitigate the shortcomings in pkgutils, even going so far as to write his own replacements (in bash) for the distro admin tools: https://gitlab.com/therealfun/oprt
<farkuhar> And as long as we're taking votes, I prefer the BSD-style initscripts myself. Whatever advantages runit might offer, we can't honestly claim to be returning CRUX to its roots if we abandon Per's explicit endorsement of BSD-style initscripts.
<farkuhar> As I wrote yesterday, the BSD-style initscripts offer greater transparency for new users who want to learn how their system starts up. runit, in contrast, hides so many implementation details behind a layer of abstraction, possibly violating the CRUX mantra "easy to understand and extend".
<farkuhar> The weakest point of the BSD-style initscripts is their reliance on start-stop-daemon, which hasn't been receiving as much attention ever since stenur was ejected from the dev team. If none of us here is willing to take on maintainership of start-stop-daemon, maybe we could reach out to stenur again and invite him to participate in "Outlaw Linux" development.
<dlcusa> I hardly ever use anything other than parted.
<farkuhar> There's also the subtle downside of "easy to understand and extend", namely that a rogue developer might misinterpret a list of feature requests (like those that appeared on the TODO38 wiki page) as a license to go wild with the startup scripts, injecting new "features" that nobody requested. An init system with tighter constraints (harder to understand and extend) could act as a safeguard against rogue devs.
<SiFuh_> dlcusa: Well I could make an option for fdisk or skip or a choice between fdisk, cfdisk and parted. That way cfdisk or parted users could do it outside of the installer.
<farkuhar> Ideally we don't want to rely on software to provide the safeguards against rogue devs. But it won't be easy to set up a formal voting mechanism that can protect against hostile takeovers, as dlcusa pointed out. Votes don't matter if the users have no power to enforce the outcome of the vote.
<SiFuh_> Or inside. Hmm, I should see if I can find that old OpenBSD style CRUX installer that someone built. Maybe farkuhar knows where it is
<dlcusa> And I vote Per CRUX defaults to sysvinit while supporting user choice for non-systemd inits.
<SiFuh_> farkuhar: Yes but to have a functioning vote system, there needs to be a set of unbreakable laws as the foundation of the distro so that it cannot be changed at a devs whim.
<SiFuh_> farkuhar: For example. Per had his rules and laws. But he never carved them into stone. So today, those rules and laws are overlooked
<SiFuh_> His ideas and concepts are dissapearing and eroding away like sand in the wind. Only seems to be me left that was around in the early days and was told these rules.
<dlcusa> I agree with SiFuh on a set of documented distro principles in order of importance with allowance for multiple principles at the same level; e.g., 1, 2A, 2B, 3.
* SiFuh_ calls the lawyers
<dlcusa> Lawyers that will use Per CRUX.
<SiFuh_> There is nothing wrong with new additions but the problem CRUX has is shit like linux-pam and sudo and nftables (Which I like) and dumb_runtime_dir being inserted into core. For what? They are not neccessary for a running CRUX. So put it in opt!
<dlcusa> Absolutely they are not core (we hold these truths to be self-evident).
<farkuhar> And the python3 in core, which jaeger explained is necessary for building ports with meson, has an unnecessarily-large footprint that beerman initially regarded as a non-issue: https://git.crux.nu/ports/core/issues/17
<dlcusa> Do we also agree there is a need for a collection between core and opt that provides the current CRUX' core system?
<dlcusa> If so, I vote it be called imPer.
<farkuhar> dlcusa: I think the idea is to maintain our own collections (independent of whatever is hosted at crux.nu), so there won't be any confusion to be mitigated by an overlay or an in-between repo.
<dlcusa> Time for me to get about getting to today's Shabbat service--later.
<SiFuh_> farkuhar: And I am also thinking to take all the build shit out and make another repo for that. So python3 will not be in core but under comp or something
<SiFuh_> I find it interesting that python3 is in core, but the port/package utillities are in opt.
<farkuhar> Hmm, you mean like how the OpenBSD "installsets" have a separate set for compilers? For a source-based distro like CRUX, it makes sense to keep the compilers all in core. Otherwise, you'll be relying on binary packages compiled elsewhere (and installed via pkg-get?)
<SiFuh_> I understand your point, but why should they be in core? You are just creating a new repo for it. And you don't need it to boot into CRUX. You need it to build ports.
<farkuhar> The core collection was never meant to be limited to *booting* only. I think it was envisioned as the minimal set of ports for *everyday use* including updates and installation of new ports.
<SiFuh_> I think core should be purely, 100% just a bootable CRUX system. How many of us use pkgmk and prt-get? They are needed to build CRUX ports, but that is in opt? We move that into comp as well.
<farkuhar> Umm, no, prt-get and pkgutils are both in core, not opt.
<SiFuh_> farkuhar: Yes, and I was there when Per was having the discussion. We had two repos. core and opt. That was all. Now we have core opt contrib compat-32 xorg
<SiFuh_> farkuhar: Hmm, since when. I was looking at the a few months back thinking, that's weird
<SiFuh_> Maybe I was dreaming or something. Haha
<farkuhar> SiFuh_: You've just been running OpenBSD as your daily driver for too long. It's easy to forget how CRUX was put together, when OpenBSD is all you experience on an everyday basis.
<SiFuh_> I think I am the only one left who knows what Per wanted since I have been in CRUX since before it was released to the wild.
<SiFuh_> farkuhar: Would be nice to drag him out of his world and ask him
<farkuhar> It is easy to imagine that on the resource-constrained machines of the early 2000s, deploying binary packages was more the norm than building from source. But soon enough, people acquired hardware of sufficient power to build all their ports locally, and then it was natural to move prt-get and pkgutils into core (if they weren't there already).
<SiFuh_> Probably were.
<SiFuh_> I do have dreams that tend to give me real life memories so sometimes when I think I have done something and realise I haven't I realise I was actually dreaming I had done it.
<SiFuh_> So again. What do you think. We take all the build stuff and pkg and prt utils and move them into a separate repo. Or you all still think they should stick to core?
<farkuhar> Taking us back to "what Per wanted" doesn't have to be accompanied by imposing on ourselves the hardware restrictions of two decades ago (too underpowered to even consider building xorg/mesa from source). I vote for keeping all the compilers in core.
<SiFuh_> I vote against but It doesn't bother me either way. I just think it is to distinguish real core ports from compilation ports.
<farkuhar> Again, it's too narrow to conceive of the core collection as merely what is needed for a bootable system. You also want the tools that will be needed for everyday use.
<SiFuh_> farkuhar: Still going to install them anyway. But what if the user doesn't want those tools and use their own?
<farkuhar> The comparison with OpenBSD "comp" installset is misleading, because OpenBSD publishes binary packages, not just the recipes for building their ports. If we also hosted a repo with pre-built binary packages, then maybe a separate repo for compilers would make sense.
<SiFuh_> Why can't we host binary builds in the future?
<farkuhar> SiFuh_: The "dialog" menu in the current CRUX installer already gives users the chance to deselect any core ports they don't want installed. I've taken advantage of this freedom in many a previous CRUX installation, deselecting those core ports that I know won't break the system if they aren't present.
<SiFuh_> Well I could continue debating this bit it seems to be going in circles. Not every user knows what are the complete build tools. Having it as a separate selection would let them know. Or at-the-least a much clearer idea of what it is for.
<SiFuh_> Anyway, it is on the table. Let others discuss more on the idea as well. Shouldn't just be between us
<farkuhar> Two things that Per explicitly endorsed (or at least tolerated): BSD-style initscripts, and binary packages as opposed to building from source. The latter because of hardware limitations in the early 2000s, the former because of their transparency and simplicity ("easy to understand and extend"). While the simplicity of BSD-style initscripts remains valid these days, the hardware constraints do not.
<SiFuh_> farkuhar: next question. SHould compilation tools NOT required for building the Linux Kernel exist on the ISO. The reason I ask this is because the CRUX ISO is getting larger and larger and now you need more than 2GB of RAM to install CRUX. Just loading it into memory on ISO boot is enough for many people to realise they can't run it on their machine of choice because they don't have enough RAM. Yes, it
<SiFuh_> happens a lot in #crux. New users complaining about errors in boot up because of this.
<SiFuh_> the hardware constraints do
<farkuhar> Heh, you'd think I'd be aware of that, typing from my CRUX-MUSL Chromebook.
<SiFuh_> I have machines here with 1GB of RAM that can run CRUX fine. I just can't install it on that machine because of the ISO chewing through the RAM. So I end up removing the drives and installing it via USB then putting it back in the machine.
<farkuhar> Okay, I concede your point about hardware constraints continuing to matter. But the upstream projects have to share some of the blame, allowing their code to get so bloated because the capabilities of the average machine keep going up over time.
<SiFuh_> farkuhar: Show you something. https://i.snipboard.io/amWQ43.jpg
<SiFuh_> That's my CRUX ports building machine and repo server
<farkuhar> If you want to go back to hosting binary packages, with all the builds happening on someone's personal server, there needs to be a discussion on which variant(s) to package, whenever a port has optional dependencies or different ways to be configured. Pretty soon the combinations become unwieldy. It's better to delegate those build-time choices to the end user.
<SiFuh_> 1GB of RAM CRUX 3.7
<SiFuh_> farkuhar: Yeah, but that is for future thought. I am not bothered with it
<farkuhar> My housemate just yesterday took to electronics recycling a perfectly good Mac Mini (manufactured mid-2010s). I asked why, even if a fresh install of Mac OS X felt sluggish to use, he never considered repurposing that hardware for a more resource-efficient OS.
<farkuhar> The possibility never crossed his mind, since he's coming from a normie computing background.
<SiFuh_> farkuhar: 1 year after getting my driver's licence, I built my first car. 5 years of learners for motorcycles. I built my first motorcycle.
<SiFuh_> I think if you own a computer or a phone. Go freaking build it and fsck with until you figure out at-the-least the basics of how it functions.
<ukky> SiFuh_: fdisk in most cases. Never used cfdisk, though it could be useful for auto-partitioning. Sometimes I use parted to double check partition layout.
<SiFuh_> Thanks ukky
<ukky> If crux-musl keeps sysvinit, it has to install /sbin/init as /sbin/sysvinit-init. And a new port core/sbin-init-sysvinit introduced and installed by default.
<ukky> The above would allow a non-sysvinit user to install an alternative init package and keep both init systems installed.
<ukky> Installing core/sbin-init-<your_init_packagename> would setup a link /sbin/init to point to actual init file (PID1)
<SiFuh_> ukky: Interesting
<ukky> SiFuh_: that's how it is implemented on my crux-glibc-3.7 systems, without patching core/sysvinit as sysvinit is not installed
<SiFuh_> ukky: noted. Will look into it later. I have another question though for everyone.
<SiFuh_> Same crux install as in extract packages, or just dump the entire thing on the disk?
<SiFuh_> Take note, this will only be if we move all this shit core doesn't need into opt and all the compilers into comp repo
ukky has quit [Quit: HW mods]
<farkuhar> Okay, email to therealfun has been sent. Let's see if he's not too busy to drop in and share his insights with us.
<SiFuh_> farkuhar: Awesome!
<farkuhar> On that note, it was Flyspray #1410 where therealfun "was trying to understand why do people leave CRUX (once they like it) and find ways to prevent this." Ironically, one of the few replies to FS#1410 came from beerman, whose second point (not enough people caring about our core tools) was hardly improved by his actions in subsequent years.
<SiFuh_> I don't think beerman cares to be honest. I think he is doing a full take over. Like a communist spy
<farkuhar> beerman's third point in FS#1410 (new users not getting helped properly, getting told to use wrapper scripts or patch prt-get themselves) reminds me of the Void wankers who wouldn't acknowledge the helpfulness of SiFuh's replies to a newbie's questions.
ukky has joined #crux-musl
<remiliascarlet> How to prevent people from leaving CRUX is simple: keep CRUX CRUX.
<remiliascarlet> farkuhar: As I said in #crux-social already, Void wankers act as if they have the worst day in the entire life, but every single day.
<remiliascarlet> I once asked why a package was so heavily outdated, and commanded me to just fix it. I asked how, and they told me something along the lines of "figure it out".
<remiliascarlet> Eventually I figured out, committed it, and then they looked at my Microsoft Github page (which I had at the time), and figured I'm against wokeness, and so they insulted me, and immediately after that they banned me.
<remiliascarlet> It was really weird.
<remiliascarlet> And only because of my profile, they rejected my merge request, and then one of them did the exact same commit, and that one got approved.
<SiFuh_> remiliascarlet: Imagine my perspective. CRUX since before official release. Knowing Per Liden myself. Fixed the broken rc and init scripts. Then suddenly I am a nobody useless mouth that does nothing.
<SiFuh_> remiliascarlet: Imagine how stenur feels. Dev for a long time. Beerman steps in and has him revoked over a complaint.
<farkuhar> The memory is pretty vague for me after so many years, but I seem to recall stenur complained about switching the libarchive build system from autotools to cmake, which led to a different linking than before. Insulting the CRUX devs in another forum was the last straw for jue and beerman.
<farkuhar> Now we have zorz posting his nonsense about the neovim linking (also with cmake), but he's not on the dev team so he doesn't have to worry about getting ejected.
<SiFuh_> farkuhar: Actually I have many choice words to say. I bet if I did unleash, I'd be the first banned in #crux and #crux-devel
farkuhar has quit [Quit: nyaa~]