IRC channel logs

<oriansj>rickmasters: just noticed your pull requests will review and merge shortly (I rarely login to github and they seem not to send me notice of pull requests)

<matrix_bridge><Lance R. Vick> Oh my god. I have to bootstrap flex from 0 on x86_64 before I can build the kernel. I am so annoyed.

<matrix_bridge><Lance R. Vick> Thankfully live-bootstrap seems to have been down this road already. Thankful for the reference!

<oriansj>Googulator: well finally got around to muxzcat.c and it definitely (with work) is something that M2-Planet can compile and definitely clean up because that code is a mess.

<oriansj>so it'll take me a week or so but I should be able to add that to mescc-tools-extra and then you'll be able to include .xz files

<Googulator>That's great news, thanks!

<Googulator>Just switching the Linux kernel tarball from gz to xz will drop us below 256MiB, although that will grow again if we want to get rid of the HTTP-only stage

<deesix>Is there a procedure to pre-download everything so it can run in a non-networked environment?

<Googulator>--external-sources

<Googulator>but of course, that will never fit below 256MiB

<oriansj>god I wish the XDG standard included .login_env to cover the login shell edge case properly.

<oriansj>then we could get all shells to just read ${HOME}/.login_env and then use the configuration folder the users freaking want regardless of shell.

<matrix_bridge><Andrius Štikonas> Well, but different shells use different syntax...

<matrix_bridge><Andrius Štikonas> How would they a work with the same file?

<matrix_bridge><Andrius Štikonas> E.g. csh is quite different

<Googulator>csh isn't considered a POSIX-compliant shell AFAIK

<Googulator>but Bourne-compatible shells should indeed support a common env file

<oriansj>well we need only consider shells that might be updated to support XDG

<oriansj>and it doesn't matter if all shells support it as only XDG compliant shells would read that file

<Googulator>does anyone even use csh today?

<oriansj>and those that opt into will just need to be able to handle VARIABLE=VALUE\n and populate that VARIABLE into the env

<oriansj>Googulator: as someone dealing with legacy code bases: yes

<matrix_bridge><Andrius Štikonas> Googulator: yep, all the hw people use csh I think

<oriansj>and if we can keep the contents of .login_env to just VARIABLE=VALUE\n then display managers can support the spec too (as it only would take a dozen lines tops)

<oriansj>no need to support comments or anything else

<oriansj>but as it isn't part of any standard; odds are that it will likely never become a default -_-

<Googulator>oriansj: I mean as a login shell

<Googulator>(yale-haskell also requires csh as a scripting language to build, but that's different from using it as a login shell)

<oriansj>oh, in which case all of the people I know who uses csh as a login shell are either retired or dead.

<oriansj>(or intentionally working to make things completely unsupportable)

<Googulator>in that case, it's relatively safe to assume that people's login shells are Bourne-compatible

<Googulator>(unless someone uses PowerShell on Linux for whatever reason)

<deesix>FreeBSD < 14 (several supported versions) has csh as root's interactive shell, IIRC.

<matrix_bridge><Andrius Štikonas> Googulator: yes he silicon designers tend to use csh as login shell too

<matrix_bridge><Andrius Štikonas> s/he/hw/

<pder>oriansj: I was also looking at muxzcat.c and looked at reworking it so it be compiled by M2-Planet and included in mescc-tools-extra, however it could also be simply compiled with only minimal changes by tcc

<pder>The only changes needed would be to read and write files specified on the command line instead of using stdin and stdout

<oriansj>indeed

<oriansj>but if it can be built by M2-Planet, then even mes and tcc can be xz'd

<pder>that is true, I think your approach is ultimately better just more work upfront

<oriansj>I'd rather do more work now than more work later; because bad choices compound like interest on a shady credit card. And I have seen where a single missing column in a database cost millions.

<oriansj>it also appears they hand wrote their own replacement for struct FILE with custom flush functions???

<oriansj>I think my version will be a good bit smaller

<oriansj>so many macros

<oriansj>I am 203 insertions(+), 420 deletions(-) in and this is going to be interesting

<pder>oriansj: I'm a fan of the unifdef utility: https://dotat.at/prog/unifdef/ It allows you to easily strip out the preprocessor directives and the code they surround and leave the rest of the file alone

<pder>for example if you dont care about supporting __KERNEL32TINY__ just run unifdef -U__KERNEL32TINY__ muxzcat.c

<pder>its handy just to make code more readable when its sprinkled with so many #ifdefs

<matrix_bridge><cosinusoidally> huh, they use the C preprocessor to autogenerate a java version? https://github.com/pts/muxzcat/blob/master/genjava.sh#L6

<matrix_bridge><Andrius Štikonas> Well, it's not completely auto generation...

<matrix_bridge><Andrius Štikonas> It's Java code hidden in #ifdefs

<matrix_bridge><Andrius Štikonas> Or at least bits that are different from C...

IRC channel logs

2024-02-02.log