257800+ entries in 0.167s
phf: sort of like
there was always
that one kid who'd eat bugs on a dare
phf: all
that analogy did for me is
that every
time i
think asciilifeform, i remember
the fucking spittoon
phf: well, main question is what you going
to plug isa into :p
phf: in
terms of what movitz offers of course (without bringing in pre-compiled C blobs)
phf: you're saying it's straight up impossible (or approaching
that)
to get, say, movitz doing networking on real hardware hardware, and i'm calling shenanigans
phf: why would i even entertain
that
thought, it should be quiet clear at
this point
that i've at no point suggested or plan
to use C in a lisp os
phf: ok, but nobody here
thinks
that,
the whole point i'm
trying
to make is
that
there are ways
to overcome
the ennui
to do what needs
to be done
phf: ok, you've convinced me
that all is hopeless and
there's no point in
trying
phf: if your nic can't accomodate for
those
things,
then your computer can't do
those
things, but it might not be a problem for
the first year
phf: you're just shifting
targets here
phf: i'm not convinced
that
this is not
the case of "mp's
t40 is
too old and slow"
phf: i've had on linux nic drivers before and in 2005 or so not all of
them were 20k+ lines
that's for sure
phf: until i can get ~that~
to work rather.
then i wouldn't be as pressed
to get r8168 working or bust
phf: why would i
think
that? i'd probably go
to a lesser N/s
target until i can get it
to work
phf: can you attempt a warm up multiple
times without power cycling?
phf: fwiw save-lisp of nic state and disk controller state is always a question of degree. either will have
to be re-initialized in general, same way as it's careless and possibly meaningless
to "save state of running lathe with a component"
phf: slightly less liquid shit
though :p
phf: if i were
to bootstrap a lisp os from nothingness, i'd just save-lisp over network (or
to a drive, depending on which one i figure out how
to do first) every once in a while, and yes it's eww and completely suboptimal, but it'll be enough for me for a "i can do practical shit with
this system"
phf: genera it up all
the way
phf: if bios driven 640x480 is good enough for
terry davis, it's good enough for me
phf is finally free
to go get breakfast
mircea_popescu: see, but
this isn't supposed
to be a comparison of fucking emotional states.
phf: fwiw i went
through
the same exercise, and on account of being less of a depressive came out with different attitude
mircea_popescu: just pointing out
that without
the exact formula described, knowledge's not
terribly useful, and deifnitely not well communciable.
mircea_popescu: learn
to document in
that format because else we're stuck redoing your work while you sadly cry on
the side.
phf: because linus wanted
to
telnet
to his university machine, he could do his jerking off on a remote system, while chipping away at his surrounded setup
mircea_popescu: asciilifeform i was looking for something stictly in
the following formula : as part of
trying
to execute subset X of
task Y part of recognizable-primitive Z because so-and so, i came
to
the method k for
theoretical reasons
t1
throiugh
tn ; attempting
to implement it i encountered situation Q even
through
this makes no sense ;
trying
to adapt it i encountered exception Q.e1 which is contrary
to design philosophy, and attempti
phf: in case of linux reasonable baseline was a dialup
telnet
phf: well,
the main question is "what's a reasonable baseline"
to keep you inside
the os long enough so
that you can keep hacking at it
mircea_popescu: you documented any of
these somewhere, so phf doesn't need
to do himself ?
mircea_popescu: d per se. except in
the benefit
that its checks will progress
this much faster.
mircea_popescu: in lisp as discussed here, and generally, a lot of checks are
to be performed.
this happens
to jive well with a matrix calling system for functions and
the muiticore design of cpu. because you as lisp will just a) maintain a matrix of all checks
to be perfromed as functions and b) keep
them permagoing on all processorss. so
this way,
the cpu count influences internal parallelism in
the os, and
thus os speed ; not program spee
mircea_popescu: in c, no checks are performed and you're welcome
to go fuck yourself. consequently, c exposes internals of cpu
to user, so as
to better hang himself. as seen eg in case of eulora client usage of one core and a
trillion other places.
mircea_popescu: yea,
this is a nutty point, so let me write it out in detail.
phf: mircea_popescu: i missed
the point
phf: mircea_popescu: well, from
that perspective "no
threads!!" is kind of irrelevant, because it's just less
things
to
try and get operational on raw hardware. pretty sure nyef had
to pull
threads from sbcl when
trying
to get it running on raw hardware..
mircea_popescu: in short, unwittingly perhaps,
the extant x86 architecture ACTUALLY FAVOURS running a lisp machine over running a c machine.