9700+ entries in 0.076s
mp_en_viaje: diana_coman, but basically, it's running the same thing from 2018 ; and the reason it doesnt move is that
a) we couldn't give less of
a shit about ebuilds while b) we can't easily change the pile of dependencies to live with musl and so yet haven't.
a111: Logged on 2018-11-27 18:11 diana_coman: trinque, that looks great; if I understand correctly, the archive there contains the means to
a. install cuntoo b. make the genesis of cuntoo/portage that could in principle be used to move an existing gentoo to cuntoo; is this correct?
mircea_popescu: or alternatively, there's all sorta greatness, phf has
a perfectly workable code metadiscussion system on btcbase, jurov had
a ver yworkable one for earlier trb work and so fucking on.
mircea_popescu: because it occurs to me that ~if~ you publish your codebase you're working on, and if your blog works correctly in the mp-wp sense, then therefore you get all this for free, just make
a metapost.
mircea_popescu: and so some other guy can go "that nfi part is just
a discussion of so and so, like this" and so on ?
mircea_popescu: can you do this in some manner ? so people can follow your work if they can be arsed to import the same ide / cms ? (here, it's
a bit of js, and
a browser, that entire stack)
spyked: line-per-line annotation sounds like
a neat idea, but I don't have anything like that going
spyked: for the moment all my notes are in
a text file that's going to grow into
a blogpost as soon as it has
a head and
a tail
spyked: but more specifically: the code I've stolen works so far, I have it serving an instance of thetarpit plus
a somewhat-working experiment doing dynamic stuff PHP-style. but there's
a lotta complexity in the work distribution code that has me going "wtf". perhaps one good task would be to implement
a worker-pool thing, similarly to what apache has.
mircea_popescu: responsibility is
a fine and great thing indeed ; but it's not mechanizable, as part and parcel of why we have
a wot as it is rather than as the lulzentreprise everyone else imagines it to be.
mircea_popescu: there's this lengthy list of examples of people coming to grief through the process of "that mp so dumb, dun even know how to horseride
a shirt" or w/e such.
mircea_popescu: this pov is even voiced, but always in
a chiding tone in training environments. it has its place there, but i dunno how practicable it is in the general.
mircea_popescu: diana_coman, i suppose in
a very theoretical, idealized sense. in practice however... what are we to conclude on the basis of
http://btcbase.org/log/2019-01-04#1884426 ? that neither i (nor anyone else here for that matter) had diffraction loaded in head ? the wave model of energy ? what exactly ?
☝︎ mircea_popescu: in any case the "i am of the republic, i will now base my self worth on the qty and amt of loading-in-head my works get" is, as of yet,
a recipe for eternal sadness. this is
a new rather than old republic.
mircea_popescu: but... what can you do. it's
a crapshoot, you know this going in.
mircea_popescu: what worries me is this approach whereby
a) things tend to be discussed in response to some kind of prodding, and b) while that feeling lasts, only to c) fall back into an eerie silence within
a few hours or maybe days, for WEEKS AND WEEKS AND MONTHS AND YEARS AT
A TIME!!!
☟︎ a111: Logged on 2019-06-22 18:07 trinque: I noticed that not
a soul read the scripts that bootstrap cuntoo
mircea_popescu: because the republic's
a practice, not
a "narrative" aka daydream. fundamentally, what distinguishes us from the github hipster / foss moron / entire collected pile of avortons looking for their abortion from "the bay area" & portland to
eudemocracia and beyond is that we don't read on the first pass, BUT ON THE SEC
mircea_popescu: this is exactly cosubstantial with the
http://btcbase.org/log/2019-06-22#1919401 inquiry : "reading everything aforehand" as
a strategy is just as dysfunctional as any other idealism aka premature optimization. there's
a fucking reason republican doctrine is "do it by hand first, automate later, and those parts that actually need it and benefit from it, rather than randomly and abstractly like the pantsuit do".
☝︎ a111: Logged on 2019-06-22 19:03 trinque: these communicating over gossipd makes
a pretty clear picture
a111: Logged on 2019-06-22 18:22 asciilifeform: cuz imho an envir where you can build yer os/proggies at home, then upload whole thing to piz (or even yer own box wherever) an' run, and then snapshot, download state, run again at home, or (exotica) sync 2 running instances -- would be
a win
a111: Logged on 2019-06-22 18:17 trinque: perhaps all that's needed there is
a cut ISO.
mircea_popescu: this isn't because "we're building housing for the sort of braindead morons who literally can not avoid walking into fire", but because "holy shit, spending life avoiding spurious pitfalls is such
a sad way to go about things".
a111: Logged on 2019-06-22 18:09 trinque: and perhaps this is what's wanted, but the ubuntu-like installer that supports all hardware without anyone needing to learn to spin
a linux kernel is
a different kind of item
mircea_popescu: hewhet.net/2019/03/hanbots-cuntoo-bake-test-notes-part-iv/ spanning
a coupla months.
a111: Logged on 2019-06-04 12:12 diana_coman:
http://btcbase.org/log/2019-06-04#1917013 -> until we change OS basically; the test one was step towards Cuntoo and that's pretty much the only real reason for having 2 since playing around with the OS on
a production server is rather iffy.
a111: Logged on 2019-06-22 18:07 trinque: I noticed that not
a soul read the scripts that bootstrap cuntoo
mircea_popescu: whereas if we decide we dislike the "packages" abstraction (and not merely dislike it
a little bit, but quite
a lot, enough to justify
a lot of rewriting) then the available solution's to just make one big v tree. coming with the obvious problem that if indeed the whole world's just one tree, then trying to play BOTH duke nukem AND warcraft 2 will result in two copies of the kernel compiled, like if we were idiots.
mircea_popescu: in this context then, if we decide we like the "packages" abstraction, for whatever reason, the obvious solution would be to maintain ebuilds of various vtrees as packages, and emerge them into
a desired pile together.
mircea_popescu: i suppose the one true break here, is that portage system actually excepts to build and link by bits. "out of the codemass intended to be used, arbitrarily selected portion
A is built and linked first, producing object files, then B is built and linked against those binaries"
trinque: this is
a "forward-looking statement" eh? I don't disagree with it
trinque: what orchestrates building
A first, then B, and finally C that links
A and B, is portage
trinque: yep, if it had
a sensible build system, and the work was done to port needed items to that build system, portage would be obviated
mircea_popescu: so is rather the problem that v-tron doesn't come with the right toolkit ? should get
a tar and an interface for make ?
trinque: the deal of portage is it does what'd otherwise be days of pointless labor untarring and making programs to stand up
a new system
mircea_popescu: i mean, maybe all local wot failed to sign
a patch portage deemed essential so it downloaded it from power-rangers.net. yes ?
mircea_popescu: that also wouldn't be
a trb server, practically speaking.\
trinque: mircea_popescu: end up with
a working trb-running server more quickly than I do today
mircea_popescu: trinque, let's go at this
a different path. what would you even do with
a trb ebuild ?
a111: Logged on 2019-06-22 22:01 mircea_popescu: trinque, if everyone includes ebuilds of everything and in
a few years' time everyone's just doing portage because "it's easier, man" ima be very damn sad.
mircea_popescu: you understand this, yes ? there's no definite utility to computers. for all the promises of grandeur and wunderbarness,
a gun's
a gun's
a gun, and
a computer's
a smartphone's
a tivo.
mircea_popescu: asciilifeform, there's nothing to do between
a gun and
a computer.
a gun is
a tool.
a c omputer is
a piece of shit.
mircea_popescu: trinque, if everyone includes ebuilds of everything and in
a few years' time everyone's just doing portage because "it's easier, man" ima be very damn sad.
☟︎ mircea_popescu: the fundamental problem here is the implicit dwim-ism involved in "i don't have
a vax/dec/cuisinart, i have
a COMPUTER, as in the abstract"
trinque: possibly tangent, but imho there needs to be
a distinction between the language of the gods (and the rules thereof) and handbook of suitable places to take
a shit.
mircea_popescu: if tomorrow we have
a ffa-for-pc and
a ffa-for-mips alternative, there WILL BE AN IFDEF.
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 ?"
trinque: this principle does not reveal
a path
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
trinque: there's
a mountain of environment variables that affects how portage behaves
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: 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.
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
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: the fundamental problem remains, however, that
a sufficiently large c/cpp code snippet will not build on any machine.
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"
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.
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.
trinque: build process automation, recall what I wrote produces
a v-tree of ebuilds sufficient to have
a booting linux