44300+ entries in 0.027s
mircea_popescu: then it was
too late, and
then it just became incomprehensible.
mircea_popescu: i was
trying a
tongue in cheek, "yes, now it has more code and less functionality, but it follows whatever
trend of insanity".
mircea_popescu: i mean, "<asciilifeform> nao it resembles minix, 100x
the mass of
the original, and ~less~ function" <mircea_popescu> yeah, but it's in ruby, or w/e
the fuck unity.
mircea_popescu: (note: "lists.gnu.org" moved
to "lists.nongnu.org"). and other keks.
mircea_popescu: sounds like he did a lot of
the same stuff here contemplated. shoot fellow an arrow maybe ? is he old ?
a111: Logged on 2017-03-23 16:39 asciilifeform:
trinque: fabrice bellard had an interesting experiment, where he stuffed
tinycc into kernel, and had it self-build on boot
a111: Logged on 2019-01-16 02:24 mod6:
This all started because we need a new door, it's old as shit, and all
the weather stripping is bad, etc. So of course,
this isn't std door size. So I paid some good money
to have a custom one made
to size. When
the carp came out
to install it,
the first
thing he did was pull off one piece of molding, and stuck his file down in
the bottom area where
that joist is located, and it pushed right
through.
mircea_popescu: moreover,
the recent exception handling discussions & digs exposed most eminently
the hole
the shit's in. you could improve on gcc right now, just by fixing its idiotic
tokenizers, "optimized" log n-onsense ans so forth.
mircea_popescu: this isn't
the q.
there's exactly one
thing
that shits bytecode. much like in 2011
there was exactly 1
thing
that extended
the blockchain.
mircea_popescu: ada-musl will have
to get its own backend, even if it's mpi-style confiscation.
mircea_popescu: anyway,
to land
this far going baloon : currently,
the large chunk of sanification work will likely still be
http://btcbase.org/log/2019-02-20#1898113 ;
there's no way
to have a world without a backend,
there's no way
to learn how
to build one without unpacking
the only one
that exists, and so on.
☝︎ mircea_popescu: though if memory serves intel mkt dept had internal proposal
to "usg pronounces pentium right, everyone changes bookeeping
to suit it"
mircea_popescu: it's independent of a, because if it
turns out all iron fails math we'll dump all iron, not re-write math.
mircea_popescu: and
that b) it is likely
to be easier
to start picking low hanging fruit from right rather
than left, simply because cheaper fruit lowerly hanging
there.
mircea_popescu: and i'm saying
that a) both approaches share a lot of overlap (you say no, but you agree next line
that conceptually, field is broken --
that is overlap!!! you just agreed!)
mircea_popescu: nevertheless,
the obvious alternative, factually
there as holes follow fills and so on, is "approach from code end". and
this approach'd be something like a ~proper~ standards lib. ie, both with proper access and proper primitives.
mircea_popescu: nothing wrong with
this. and will have
to be at least attempted.
mircea_popescu: but back
to it, let's
try and use different
terms : i deem your "whole
thing is an emu, in machine lang, bios boots into it"
to be a "approach from machine end".
mircea_popescu: very early 1500s medicino-chemistry-philosophical-barbershop flavour
to
the whole field.
mircea_popescu: fucking bs "science" where ALL
the notiuons are broken.
mircea_popescu: which is
the point, it's a waste of
time
to consider "how linus separated" or "how rms
thought should be separated". whoile
thing's built on magic musherooms, "sky quadrants" etc.
mircea_popescu: anyway, i
think i fully understand what you mean re "no compiler, no linker" : it is evidently a broken situation when you have
TWO patsh from "what master said"
to "what machine does".
mircea_popescu: asciilifeform i'm aware, evolved not designed. nevertheless,
the fundamental breakage here is
that glibc is proposed as a "library" rather
than a "kernel mod". not
that
these
terms make any fucking sense anyway, but what
the fuck am i gonna do.
mircea_popescu: asciilifeform
the large problem here is
that
the ast will have
to be ultimately a homomorphism of machine language. which is
the dubious part in
the "emulator" pov.
mircea_popescu: to follow
the logic :
the notion
that you'd have a kernel mod
to interface with peripherals, but not with code, is somewhat bizarre.
mircea_popescu: terminology fails, mostly because
terminology was made by morons and we're
trying
to discuss analysis in roman numerals here, but consider "glibc" would be a... well i guess a kernel mod
the program links against as a library ?
mircea_popescu: but srsly now,
the "standards lib" lets me print
to screen but not print
to ram ? wut.
mircea_popescu: or in other words,
the overlap is large even if
the barbarians cut it wrongly and on
the basis of
their cuts it seems
to not be\
mircea_popescu: ie,
the fact
that glibc doesn't come with sane memory allocator ~is a failure of glibc~.
mircea_popescu: certainly. but once you start
talking about unified abi, you're very much starting
there.
mircea_popescu: then again
this whiole discussion is moot, because step 1
towards
that magical bios asm blob is a
tmsr standards lib
to replace glibc anyway.
mircea_popescu: even so. as far as reading goes, you still read it
the same number of
times, whether it's linked or bios'd.
mircea_popescu: however, consider situation 1, where "it is in emulator" and situation 2, where "it is in
this one
tmsr standards library".
mircea_popescu: from
the pov of auditing it is certainly cheaper
to move it into
the "emulator"
mircea_popescu: asciilifeform large part of people's complaints re leverage are insane.
take
the recent naggum piece discussed, he complains, literally,
that "he wants
to lie once rather
than everywhere". duh, no sed where
this man lives ?
mircea_popescu: asciilifeform it's never cheaper
to have a coupling
than a straight link. nevertheless, couplings are used.
mircea_popescu: other
than
this,
the "we don't want
to fuck our brains with $bad-arch" is a dead end -- you will, whether
to write gcc for it or
to write bios for it.
a111: Logged on 2019-02-17 23:49 asciilifeform: re bolix back end, i suspect it aint very useful as starting point, because was far ~too easy~ item , in
that
the iron per se was sane (i.e. performed bounds and
type checks, so much of what gcc is stuck doing in soft, was unnecessary )
mircea_popescu: the obvious counter
there will be "but not cheaper
than baking ONE sane gcc". which is
true, but nevertheless not as useful -- sometimes having an interface, even if "spurious" is better
than not having it, which is why parents don't customarily discuss family finances with
their 12yos.
mircea_popescu: like all attempts
to date have, here or anywhere else.
mircea_popescu: understand
tho, it has a very visible facet of wishful
thinking. i mean yes, obviously, way
the fuck better
to have all
the needful stuff in one place
than added
to each binary.
this much is certain. nevertheless,
the notion
that you can stuff a converter from insanity
to sanity "in
the bios" requires just as much a magical stone as any other "universal sanity-insanity bridge".
mircea_popescu: asciilifeform re bios emu -- i am certainly not against
trying
this. it's not possible
to say much more
than
that as
things stand now.
a111: Logged on 2019-02-20 15:57 asciilifeform:
the Right
Thing will look roughly like a 256kB chunk of asm
that
the box boots straight into, and afterwards forgets
that it's an x86, arm, etc.