IRC channel logs
2024-11-30.log
back to list of logs
<Googulator>oriansj: there's also the issue of applications only being certified (by the government, etc.) on one specific platform - this was largely what kept Itanium alive in the banking industry. <oriansj>Googulator: if you are referring to FFIEC, that didn't require certification of the software (let alone the platform the software was running on) but certification of processes (which could have been done as part of the annual audit). But poorly thought out support contracts that the banking industry agreed to which locked them into a single vendor for over a decade for "reduced costs" which ended up costing them much more. <oriansj>Now there are manufactoring environments where multi-million dollar machines are attached to a nonstop server that can't be replaced <oriansj>and the FDA didn't certify any nonstop systems (oddly a bunch of windows 95 systems did though) <oriansj>hmmm, odd that no one picked up that all of the ecx/ebx/ebp instructions could be just converted to cx/bx/bp and you could save a good few bytes <oriansj>(hint E5 04 vs C1E5 04 sort of thing) <oriansj>(although admittedly hex0 is kind of running out of instructions to possibly optimize) <oriansj>If only there was a COM like executable format for Linux/BSD/etc <oriansj>and as hex0 in the seeds is only expected to get exactly 2 arguments (input file and output file) it is ok if it breaks if one passes more arguments <oriansj>(although it might just me seeing a RASM bug) <aggi>seems rebasing the redhat nptl patchset for linux-2.4.21 onto linux-2.4.37.11 isn't too easy <aggi>i'll give it a weekend, in worst case i may rollback kernel to some linux-2.4.2x that may have nptl support cleanly applied easier <stikonas>oriansj: I thought we want to keep it working with more arguments... <stikonas>it is possible that something might be optimized if assume argc = 3... <stikonas>i.e. by not having to write 3 to some register and instead doing xchg <oriansj>and I do have concerns about if Linux gets more strict about ELF again and breaking hex0 again. <oriansj>if we wanted to get crazy with optimization, we could assume only one use of hex0-seed (which is to build a more proper hex0) <stikonas>well, so far I think we should be standard compliant <stikonas>there are some attemts long time ago at really small binaries (far smaller than hex) that print something <stikonas>but I think those assumed some implementation specific details on Linux 2.2 or so <stikonas>oriansj: by the way, where is that ecx->cx thing that you mentioned? <stikonas>I think we only use full register where we have to <stikonas>though probably there are cases in kaem... <lilyp>unmush: would you like doing this with `git send-email'? <aggi>the linux-2.x is confusing <aggi>and it is relevant since bootstrappable relies upon it with fiwix, with the efforts that one was re-implemented from scratch <aggi>yet, looking at the kernel version history and branches of linux-2.4 itself <aggi>redhat9 and fedora, and too centos all of them abandoned the linux-2.4 series before it reached EOL <aggi>important patches were not mainlined back to linux-2.4.37.11 <aggi>bellard too quit at linux-2.4.2x <aggi>then, in parallel, for ~10years, 2.6.x and 2.4.x were maintained, and reached EOL at about the same time <aggi>but redhat/fedora/ibm did not bother to rebase important(!) patches for nptl back onto 2.4.x <aggi>and no other distribution did to my knowledge <aggi>however, 2.4 series was the last known which could be supported by tcc/tccboot too <aggi>that's one incentive, to pick up maintenance of it again, 10 years later <aggi>another one is, 2.6 series increased lines of code excessively <aggi>then back to fiwix, considered linux-2.x ABI that relevant, it was re-implemented from scratch, without nptl again <aggi>centos which i tried first, did not ship nptl/o1 scheduler patchset inside their SRPM, although their kernel could not have compiled without those at least <aggi>legacy.redhat.com kept those, gladly, and too fedora got some srpm archive which contain them <aggi>and it is two big changsets to rebase onto 2.4.37, the one for o1 scheduler, and nptl <aggi>nptl support from kernel seems preferrable <aggi>i think it is feasible, although it takes a little while longer than expected, to re-unite a tcc-compiled kernel-2.4 with a musl-libc userspace <aggi>i am not sure yet, if i'll stick to some 2.4.2x or 2.4.3x series, since redhat terminated at 2.4.2x <matrix_bridge><cosinusoidally> I suppose it depends what your aims are. I've been playing around with some old 2.4 (and earlier) bases slackware VMs and they are surprisingly usable, and complete, desktop systems. <aggi>at first glance, linux-2.4 kernel is far less lines of code, fiwix is even less with some absent usb/smp/hardware support <aggi>linux-2.4 is hitting the sweet spot in between this <aggi>next, it can be fully supported with tcc compiler <aggi>it is missing nptl only for compatibility with musl-libc, however, nptl is available <aggi>then, it is possible, i think, to spawn most recent software versions atop linux-2.4 kernel <aggi>furthermore, linux-2.4 can be hooked into the "kernel bootstrapping" dependency chain <aggi>and, there is interesting extensions for linux-2.4 which later kernels haven't got, such as systrace from nils provos <aggi>as far as security/forensics were concerned <aggi>since this is x86/32bit, i may have to backport nilfs2 filesystem too <aggi>another problem is, Intel began phasing out UEFI/CSM that is needed, otherwise the idea is a long-term stable system could be booted almost everywhere <aggi>without updates necessary <aggi>i've wasted a whole night with rebasing centos patchsets onto linux-2.4.37.11 just to find out their linux srpm was incomplete <aggi>the redhat9/fedora-1.0 srpm seem complete, so i'll use that <aggi>since bootstrappable had picked some LTS linux-kernel from the 4.x series, i suspect a 2.x wasn't a bad choice either <aggi>otherwise, i am not interested in desktop stuff <aggi>that's all what i consider optional <aggi>i think i can finish rebasing the nptl patchset this weekend, to see how many of those ~500ebuilds that i got for support with tcc might work <aggi>*nilfs2 got 64bit timestamps which are needed for year2038, and linux-2.4 hasn't got any filesystem ready on board for 32bit POSIX <aggi>64bit time_t itself is another breakage inside linux, which got addressed rather late <aggi>i think the kernel version that bootstrappable had chosen wasn't year2038 ready with 32bit <aggi>officially, linux was advertizing removal of their BKL, but i think it was absent nptl support which was a hindrance to scalability with linux-2.4 <aggi>so, well, that's another incentive, if it was scalable <unmush>lilyp: AFAIK I can't with protonmail unless I first set up some bridge thing <lilyp>weird… it's unencrypted mail anyway, so you should just be able to use whatever smtp client you have <unmush>AFAIK protonmail is webmail-only for free accounts