<OriansJ>nothing we do has to be of practical value right now, only has to be something bootstrapped and we wanted to do; the practical value and application can be sorted out later when we need that thing for some reason. <OriansJ>because we have enough practical (non-fun) work to deal with anyway. <OriansJ>morale bootstrapping is an essential task to keep at such a long term project. <OriansJ>find joy, even if it is bootstrapping a game. <gef>as regards `date`, I think it might be useful if it begins with Unix epoch and increases by 1 in every invocation. Doing that, gives a chance to potentially spot interesting information (and observe where parallelism kicks in with possibly non-deterministic outcomes) <gef>1 I mean, 1 second or something pre-defined <gforce_d11977>gef: I like your idea of a faked date answer, raising with 1 sec steps <bauen1>in theory the entire bootstrap should make identical syscalls even, save for some race conditions, gettime and bugs <gforce_d11977>is it feasible to stderr out some selected syscalls via patching our libc? in theory these should be the same for all bootstraps... <stikonas>gforce_d11977: yes, it is definitely possible to intercept syscalls in libc <stikonas>you don't even need to patch it, you can intercept syscalls even with unpatched libc by LD_PRELOADING some other library that intercepts syscalls <xentrac>also it sort of sounds like maybe what you want is strace <xentrac>that uses ptrace() which is much slower than an LD_PRELOAD or a patched libc <gforce_d11977>xentrac: yes, but i want every program to be run with strace, so it would be cool to just 'export LD_PRELOAD=/foo/bar', and 'bar' is a syscall interceptor? <gforce_d11977>or i just run the initial 'kaem' with 'strace -e /sbin/init' ? <xentrac>maybe strace -e open,read,socket -ff /sbin/init <xentrac>you can write an LD_PRELOAD library for particular system calls pretty easily <bauen1>gforce_d11977: you could use linuxs audit system to log every syscall + some arguments <bauen1>xentrac: auditd + auditctl can be used to track some syscalls <bauen1>probably don't need auditd, linux could just log to dmesg <xentrac>interesting, I hadn't heard of that! <bauen1>xentrac: on debian "auditd" provides the auditctl command <OriansJ>xentrac: perl might be joyful but my experience with it dealt with IBM's CQ and there is no joy working even with perl around that flaming dumpster fire. Freaking 4 hour checkout times for a single file. <OriansJ>The sort of this one line change will take 6 hours so lets do a bunch of extra changes too and hopefully every line of code is 100% perfect and force us to redo it all again; throws in 2day build delays and week long test delays to the development cycle. <OriansJ>showing them git and 2 minute builds was like showing fire to a caveman. <OriansJ>took 6months just to extract the commit history form CQ and import it into git and ironically that was the easy part <bauen1>4 hour checkout times would be a few magnitudes too much for me ... <gforce_d11977>bauen1: linuxs audit system? that sounds great, will dig into it <OriansJ>xentrac: pain of working with large organizations which have too many contractors making too many decisions; <OriansJ>Those really are the only places where one can save $30M in 5 years on technical changes alone (and zero external impact) ***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr