600+ entries in 0.001s
dorion: one positive
that occurs is
crisis is an opportunity
to find out who's what.
ossabot: Logged on 2020-03-10 21:26:33 mp_en_viaje:
this is of course my problem ; you can do it elsewhere cheaper / better / whatever, i'm
the last dood
to get in
the way of any such a
thing.
ossabot: (ossasepia) 2020-03-12 dorion: just gave
the
latest article a second read. seems like he's saying, "you all could be men, but for whatever reason you're not and I've had enough of
the retardation
to interact with it further. perhaps me walking away is what's needed
to wake you up."
dorion: trinque ftr I very much appreciate what you're conveying in your series which is why I want
to both
talk about and see it continue. I'm not ignoring it, but I'm also not ignoring
the mandate
to support
the implicit clients. how much are you
taking
the latter into consideration in what you're building ?
ossabot: Logged on 2020-03-12 00:19:33
trinque: but anyway. I wasn't describing an item I wish I had. I was describing an item I'm building.
ossabot: Logged on 2019-11-12 16:59:56 mircea_popescu: so it's basically a
training
tool, as far as
that goes, a didactic example
ossabot: Logged on 2020-03-12 00:37:25
trinque: I propose you delete
that list, and you write another. In
the new list, write down only
the items
that will get
the machine
to boot, and allow
the user
to edit and rebuild
the OS.
dorion: sorry for
the busted lines. mp_en_viaje, diana_coman, does eulora use python for anything ?
ossabot: Logged on 2020-03-12 00:13:55
trinque: what's python even doing
there?
dorion: he only genesis'd irc client, yrc is in python. jfw will be
the first
to
tell you he'd rather neither were in python, nevertheless
they
ossabot: Logged on 2020-03-12 00:13:46
trinque: ok, so what rankles my ass about your goodness list is you have items at wildly different levels of
the
tree all flattened
together like
they're of
the same importance and same level of
the ontology.
ossabot: Logged on 2020-03-11 23:58:52
trinque: it can be used
to build and improve itself.
the end.
ossabot: Logged on 2020-03-11 23:58:37
trinque: for
the record, my measure is "self-hosts"
ossabot: Logged on 2020-03-11 23:57:29
trinque: if you want "builds crystalspace"
to be
the purpose
towards which we're reaching, might as well install ubuntu.
dorion: trinque
thanks for
the feedback.
trinque: I propose you delete
that list, and you write another. In
the new list, write down only
the items
that will get
the machine
to boot, and allow
the user
to edit and rebuild
the OS.
trinque: this is a wall of hubris, my friend, and sorta flies in
the face of what I was
trying
to convey with
the series.
trinque: what's python even doing
there?
trinque: ok, so what rankles my ass about your goodness list is you have items at wildly different levels of
the
tree all flattened
together like
they're of
the same importance and same level of
the ontology.
trinque: it can be used
to build and improve itself.
the end.
trinque: for
the record, my measure is "self-hosts"
trinque: if you want "doesn't have batshit bashism"
to be
the measure of which shell
to use, idem
trinque: if you want "builds crystalspace"
to be
the purpose
towards which we're reaching, might as well install ubuntu.
trinque: dorion: so now we have something
to
talk about.
dorion: ^^ mp_en_viaje jfw bvt spyked diana_coman and any other parties interested in
tmsr os ^^
ossabot: Logged on 2020-03-11 02:03:07
trinque: because
the final post is little else
than gathering
the selected items into a source
tree, wrapping
them in a build process, and cutting a genesis.
dorion: if you've made progress on
the selecting and organizing into a source
tree, why not be satisfied with publishing
that and getting feedback ?
ossabot: Logged on 2020-03-11 02:03:07
trinque: because
the final post is little else
than gathering
the selected items into a source
tree, wrapping
them in a build process, and cutting a genesis.
ossabot: Logged on 2020-03-11 02:02:05
trinque: so where are we at with
that?
jfw: If we're adding runit
to
the mix on
the busybox side,
then it becomes fair
to compare
their 800+ LoC init.c
to my 30-line one.
jfw: I haven't actually
tried mdev so I'm not quite at "makedev can be dropped" but I'm certainly open
to it.
dorion: please correct me if I'm missing something, but how do you draw "pretty opposed" from
the above ?
dorion: jfw can correct me if I'm wrong but I don't
think he knew busybox includes
runit. since he was already used
to using daemontools and daemontools is
the predecessor
to runit anyways he went with
that.
ossabot: (trinque) 2020-01-24 jfw:
trinque: I was ignorant of mdev, looks like just
the
thing!
ossabot: Logged on 2020-03-11 02:01:59
trinque: dorion: yes, I haven't had
time
to complete
the final post, but last I checked y'all were pretty opposed
to using busybox-only for
the userland.
jfw: it's impossible
to keep
track"
to quote its init.c. One
thing I
take from
this is one's not likely
to get a good sense of
the code quality of a given part from a random sampling of
the overall
tree.
jfw: that's 1). 2) what do you mean by "busybox-only" - because far as I know you can't possibly mean exactly
that, it doesn't have an mkfs or make for example, let alone a compiler. Do you mean, "system which selects components outside busybox only if busybox $version does not contain
them"? I'll note
that busybox is an amalgam of code from a variety of sources and, ahem, "Adjusted by so many folks,
jfw: for what we're
talking about.
jfw: trinque: I'm also
tardy on jumping back into
the OS fray, for one
thing my wallet project has dragged out way longer
than I naively expected, but I look forward
to doing so shortly. But in hopes of advancing
the discussion a bit: is
there a particular merit
to busybox-1.31.1 ? For all I know it's an entirely different
thing from
the older one I've been looking at and we'll need some common basis
trinque: so it's not only
the smallest candidate, but it can be miles smaller still
trinque: it's
that we can cleave shit out of busybox source permanently
trivially by using
the config flags.
trinque: I'll point out again for
the logs
that my picking busybox wasn't just "whatever, it's small, and it's all
there"
trinque: because
the final post is little else
than gathering
the selected items into a source
tree, wrapping
them in a build process, and cutting a genesis.
trinque: so where are we at with
that?
trinque: dorion: yes, I haven't had
time
to complete
the final post, but last I checked y'all were pretty opposed
to using busybox-only for
the userland.
lobbes: mp_en_viaje, roger
that
ericbot: Logged on 2020-03-11 01:03:20 lobbes: I just incremented
the old one from
the stanlogger
lobbes: k. And I guess just let me know whenever / however you wanna
try
to get
that
t.com >
t.net update process going. I'll
try
to find
time where needed
lobbes: mp_en_viaje: okay, sounds like a plan
then. So, I guess for my part I'll go back and see what I can do about a sane history-backfill process.
mp_en_viaje: perhaps easier said
than done ; but we see
mp_en_viaje: honestly i
think what i'll go for will be : (using
trilema.com for current
trilema and
trilema.net for pizdi's box), hve a mysql server run on both, have
t.com update both rather
than just its own, and have it read
the day's logs at some point
tomorrow.
this way people can use
t.net for any purpose except write a comment.
lobbes: as for
the sync script, yeah
that would be interesting. As for
the frequency does mysql do
triggers on database changes?
lobbes: hm, I am not familiar with federated
tables myself. I'd need
to look into
them a bit.
mp_en_viaje: there could be a sync script, but
then how often does it run
mp_en_viaje: on
the other hand
there exists
the obvious "have logs category on
trilema.net, have
trilema.net use
trilema.com for everything (including comment post say). which is about as derpy as it sounds.
mp_en_viaje: technically
there exists mysql "federated"
tables ; but everyone seems
to hate
them. prolly for no reason.
mp_en_viaje: now
that said, i'm still
thinking about how
the fuck
to get mp-wp working on
two machines best.
lobbes: yeah, I was misunderstanding your process
there
ossabot: Logged on 2020-03-10 19:08:58 lobbes: Instead, I figure why don't I just cut out 2,3,4,5 and instead I just alter my 1)
to pull logs from my Postgres database in
the same format of your input into your backfill process (which has already been
proven to function to spec)?
lobbes: it seemed simple: instead of eating IRC lines live just eat lines from Postgres. But you know, looking back I used way
too many middleman steps
mp_en_viaje re-reads
the init of
this convo
to figure out wth
the problem was
lobbes: that's what I
tried
to do last
time; ended up faffing about. I'm a little hesitant
to
try again but I guess I'll need
to at some point
mp_en_viaje: honestly,
the stuff pizdi's dumping in
the
test blog is perfectly fine. why can't you just dump
the missing logs into her ?
lobbes: ah shit, I must've missed
that. Well easy enough
to remove in any case
mp_en_viaje: ----- 20:00 ----- << oh it's still doing
that
thing, iirc we wanted it out eventually.
lobbes: mp_en_viaje: I don't
think it'll record line changes.
Though I honestly did not
test if it would break it
lobbes: I just incremented
the old one from
the stanlogger
mp_en_viaje: lobbes, did you do a buncha
testing on
this
then ? all sorta lines, changes in say
topic, etc ?
lobbes: command is '!y' for
the
time-being
lobbes: I could bring it in now even, it just is logging
to my
test site
lobbes: mp_en_viaje, agreed (btw if I ever do make it
to CR real coffee will be one of
the first
things I
try)
mp_en_viaje: lobbes, it seems unavoidable, otherwise we'll just be doing
this chasing gaps forver, like achilles.