log☇︎
9700+ entries in 0.076s
mp_en_viaje: always a nice discovery to make.
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?
diana_coman: http://btcbase.org/log/2019-06-23#1919625 - s.mg test is running proto-cuntoo (non-musltronic) so not latest, no; there was this http://btcbase.org/log/2018-11-27#1875228 and http://btcbase.org/log/2019-03-09#1901069 ; as long as there is the CS dependency still on server, a move to static & musltronic only is also likely to be a lot of work. ☝︎☝︎☝︎
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)
mircea_popescu: now admire what i can do : http://trilema.com/2013/internet-story/#selection-13.14-37.22 << this part is boring ; http://trilema.com/2013/internet-story/#selection-41.0-57.15 << this part is a quote ; http://trilema.com/2013/internet-story/#selection-61.0-65.37 << this part is about bitcoin ; http://trilema.com/2013/internet-story/#selection-65.37-89.175 << i have no fucking idea wtf this is.
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: this is always a crapshoot.
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". ☝︎
lobbes: however on second run-through I indeed went back to read the scripts in tandem with the gentoo handbook (so as to actually understand what was going on) and produced a bootable genesis that verified >> http://blog.lobbesblog.com/2019/02/a-bridge-to-cuntoo-for-the-lenovo-x61-x86_64/ ☟︎
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: http://btcbase.org/log/2019-06-22#1919303 << this may work. my takeaway was that item could benefit from a little polish, a few choice one-liners added to documentation/comments, that sorta thing ☝︎
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.
mircea_popescu: there's on one hand the http://btcbase.org/log/2018-07-23#1837434 / http://btcbase.org/log/2018-11-27#1875247 / http://btcbase.org/log/2019-06-04#1917021 story arch, spanning a year. there's also the http://thewhet.net/2019/02/hanbots-cuntoo-bake-test-notes-part-i/ http://thewhet.net/2019/02/hanbots-cuntoo-bake-test-notes-part-ii/ http://thewhet.net/2019/03/hanbots-cuntoo-bake-test-notes-part-iii-with-prep-script/ http://t ☝︎☝︎☝︎
a111: Logged on 2019-06-22 18:07 trinque: I noticed that not a soul read the scripts that bootstrap cuntoo
mircea_popescu: trinque, do me a favour and also encrypt to http://wot.deedbot.org/208FE107E970F53262C4951232992F13CFA6CD06.asc so i don't have to wake up the girls to do ahlf hour of typing for me again
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 back in a few
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: understanding's not a mechanical task.
mircea_popescu: this seems a fundamentally bad deal to me.
mircea_popescu: ious a consideration.
asciilifeform must go to a lengthy meat chore ; bbl
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
asciilifeform: corollary to this q : how would a 'trb ebuild' differ from the trb vtree as it stands ?
mircea_popescu: trinque, let's go at this a different path. what would you even do with a trb ebuild ?
asciilifeform: what can i say, i cannot speak for mircea_popescu , but i have never bought a 'mystery pc' where i have nfi apriori what os to even attempt on it
asciilifeform: mircea_popescu: if pc were a small arm, i'd say would be 'zip gun' made from old brass pipe and paperclip, at this pt in time
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.
asciilifeform: and this is when we learned that mircea_popescu dun have a scale in his toilet lol
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: no, because who gives a flying fuck already.
mircea_popescu: but it's a mitigation, if i wanna know i gotta look.
asciilifeform: mircea_popescu: do you personally own a box where you do not know which cpu is installed ?
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.
asciilifeform: the problem of 'ifdef' is the clusterfuck where i am given to sign a patch that includes '#ifdef vax' but i dun have a vax. and dun intend to.
mircea_popescu: if tomorrow we have a ffa-for-pc and a ffa-for-mips alternative, there WILL BE AN IFDEF.
asciilifeform: mircea_popescu: yer card runs on closed vendorblob, neh. how would that even make it into a cuntoo-portage or vtree at all.
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 ?"
asciilifeform: just like you already know that you aint building on a dec vax
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
mircea_popescu: i've not looked in a long time, myself.
asciilifeform: the heathens ftr took up this fallacy ( 'who needs reproducible builds, we have vmware' ) and have written themselves into some pretty amazing corners ('what did you say, you wanted to BUILD 'rails' from src? no one has done this since 2011... here have a vm' etc)
trinque: there's a mountain of environment variables that affects how portage behaves
asciilifeform: http://btcbase.org/log/2019-06-22#1919415 << i must point out, this item imho is orthogonal to the problem of this thrd, a standard 'machine' does not remove the need for proper 'systemwide vtron'-aka-portage-replacement ☝︎
trinque: eh, there's a long... LONG tail there
asciilifeform: pretty much 95% of a 'portage' right there
asciilifeform: there is even a (sad, disused, esthlos went to bottom of sea) but last i saw -- working -- cl vtron
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.
asciilifeform: 'emerge' itself is a quite gnarly ball o'python
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'.
asciilifeform: (sorta like a 'make' not written by tards)
asciilifeform: it'd be a very trivial ebuild, lol. given as uses gprbuild, which actually worx correctly.
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.
mircea_popescu: what's a package, even ?
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