29800+ entries in 0.018s
mircea_popescu: to do
the "ifdef vax" in a magically acceptable manner ?
mircea_popescu: and your solution seems
to me a bit of smoke and magic, because what will you use
to manage "which v
tree, dec or pc" ? a vortage ?
a111: Logged on 2019-06-02 03:43 mircea_popescu: all joking aside :
the best answer i could produce for
the
http://btcbase.org/log/2019-06-01#1916471 question stands as "choose between steamos and ubuntu", which in plain
terms is "do you wish
to make your computer a supernintendo and buy
virtual cartridges for it ? or would you rather make your computer a mobile phone ?"
mircea_popescu: now what's
the idea, we'll keep it under glass and... not use it ?
mircea_popescu: well yes, but look here : at some point we decided
to save
the state of computing, specifically
to avoid
this "nobody has built since 2011, here have a
virtual machine"
trinque: it's a bunch of portlanders all saying "oh no *you* go" at
the 4 way stop
mircea_popescu: they built
this magical workaround
their own idiocy. what
the hell could it possibly consist of besides
the devil himself ?
trinque: there's a mountain of environment variables
that affects how portage behaves
trinque: last dive I
took into
the portage code, it appeared
to be filled with steps around either bugs in linux or packages
a111: Logged on 2019-06-22 21:34
trinque: asciilifeform's mips-vm
thing could be one candidate for
the hard break
trinque: ebuilds are on
their 6th or 7th format revision;
they're as much imperative code as
they're declarative metadata
mircea_popescu: kinda what we're
trying
to figure out -- what we want and why we want it.
trinque: eh,
there's a long... LONG
tail
there
mircea_popescu: i personally doubt such a
thing as a lisp portage can be made. but
then again i have no coding experience.
trinque: asciilifeform's mips-vm
thing could be one candidate for
the hard break
☟︎ mircea_popescu: diana_coman, nor will anything else made by idiots, which is
to say 70% of
the kernel and 95% of
the userspace.
trinque: my intent here has been
to stablize
the workbench and
then make a *hard* break with
the whole stack
☟︎ diana_coman: fwiw re gprbuild and legacy c/cpp-ism: cal3d lib builds with gprbuild absolutely fine; CS however not at all and it's not a
trivial
thing
to port it either as far as I could
tell at a quick look.
mircea_popescu: if gotta-have-python anyway, why am i wasting spyked's
time with hutch&hoot, might as well use python for scripting.
trinque: mircea_popescu: we currently stand on a pile of hellish complexity
that costs more man-lives
than we have
to
transition
to a form we'd find acceptable.
mircea_popescu: trinque, do me a favour an' state
the problem in yoru own words so as
to see how synced we're here
mircea_popescu: he has a point
there, in
that at least portage will emerge a complete world, for whatever any other complaints one might harbor
trinque: or is
this "in six years
time we'll have systems
that work"
☟︎ trinque: and it'll go build e.g. ncurses if your
thing needed it?
mircea_popescu: and yes indeedy, i'd much rather mandate a "your project must buuld on gprbuild"
than a "your project must include ebuild", if
there's mandatin'.
mircea_popescu: asciilifeform,
the main problem here seems
to be "what allowances
to build system do we make in
the fundamental"
mircea_popescu: all
this said, i don't believe if someone wrote an ebuilds for say ffa
they'd
thereby degrade ffa.
mircea_popescu: the fundamental problem remains, however,
that a sufficiently large c/cpp code snippet will not build on any machine.
mircea_popescu: much, i suspect, like why and wherefore
trinque 's stuck with ebuilds. "wtf do you want me
to do, make sense of gentoo in my spare
time !?!?!"
mircea_popescu: i am not even disputing
that. i
think large projects (ie, again, eulora) used it as a ... well, default evil. "gotta use something, wtf can do".
mircea_popescu: and
the reasons we wanted v were very much specifically and centrally "so such a
thing as portage is can NOT be had, and such problems as it solves can not be solved"
mircea_popescu: if we wanted fucking portage we could have just imported portage. but i
think we just as deliberately did NOT want it ; we wanted v.
mircea_popescu: nothing wrong with it, it was so by agreement and deliberately not accidentally. now
the problem of digestion, however...
trinque: I can see
the continuous symbolic space mircea_popescu wants, but
the cuntoo
thing was exactly "capture
these packages before
they can't even be built anymore" plus a snapshot of a working build
toolchain
to do so.
mircea_popescu: i don't
think it permits
the notion of "package". but it will press
to your intended destination, all leaves up
to it.
trinque: I don't see how v denotes "build A,
then B,
then C package"
mod6: There will be a blog post I make about how I want
through
the ebuild process, but probably closer
to month-end.
mod6: I still consider
them "in-progress", but will forward what I have along
to you here by Monday. (I wanted
to get
these ones built before
the
trb one - which I'm just starting on now.)
mod6: trinque: Speaking of an ebuild for ave1's musltronic
tools, I've got one
that works. I've also got one for diana_coman's keccak V
tools package.
trinque: would be entirely sensible
to have
the source v-trees grafted into
the same
tree.
trinque: build process automation, recall what I wrote produces a v-tree of ebuilds sufficient
to have a booting linux
trinque: yep, I
think I need
to demonstrate
this a few
times before it
takes with others
mircea_popescu: bvt i don't
think it's wasted either ; and for
that matter came off
too strong on
the side of whatever my point was
there.
trinque: speaking of which, if ave1 is not going
to produce an ebuild for his gcc, I imagine
that's next priority on my end.
trinque: Mocky: can I encourage you
to produce an ebuild for your gns item when done?
a111: Logged on 2019-06-22 15:18 Mocky: my work on gns is at
the stage where I'm loading v fully into my head and making sure I know
the questions I need
to ask before I start implementing. I'll blog about it
mircea_popescu: like it's nobody's child or something, always lastest at
the
trough
a111: Logged on 2019-06-22 15:08 Mocky: mircea_popescu: I've failed at managing myself for
the last few months. I let myself get overwhelmed with dumb shit. I
thought I could do it all despite
the evidence
to
the contrary. Republican work got dropped along with a bunch of other. But republican work is what I care about and not
the dumb shit. So I'm changing
this now. Head in
the sand is no way
to live and putting others in
the position
to say, 'hey, wtf
Mocky: whole world stops whenever input data syncing
trips over a network slow down
Mocky: in practice it's 2 players only and considered a feature of
the physics engine, even so often laggy as hell
a111: Logged on 2019-06-22 18:59 asciilifeform:
the 'secret' of
this is
that you only gotta propagate
the ~inputs~ .
trinque supposes a gradient where one's computewot grows in
trust over
time
trinque: I don't know of any minorityreportronic extension
to
the
thing
trinque: not
to compliment
that stack of chairs, but yes,
they do
this