IRC channel logs
2022-07-10.log
back to list of logs
<oriansj>muurkha: well in Accelerando, it was the robot cat that did the bootstrapping so It wouldn't be our sort of bootstrap <oriansj>also if we really wanted to rule out hardware attacks, we could just make CPUs like the Monster6502 <oriansj>10khz is fast enough to validate up to M2-Planet <muurkha>oriansj: the objective was specifically to defeat Karger–Thompson attacks though <oriansj>muurkha: Oh I am going way past that ^_^ <oriansj>I plan on knowing how to grow silicon crystals and make my own lithography fab <muurkha>there may be other semiconductors that are more accessible to hydrothermal methods <muurkha>also, though Zeloof has shown that photolithography is a viable approach, there may be other approaches that are easier when mass production isn't part of the objective <muurkha>(maybe when it is, too, but especially when it isn't) <oriansj>got push *ALL* the bootstrapping limits <muurkha>it'd be nice to not have to push materials fabrication limits, sigh <oriansj>muurkha: you'll never get matter compilers with that attitude ;-p <muurkha>on the contrary, I want to find the easiest, lowest-risk way to get matter compilers <muurkha>every materials fabrication limit I have to push is a risk of having to fail, abandon an approach completely, and find a different way <oriansj>muurkha: I think pushing of the cutting edge in technology is much like pushing the cutting edge in body shaping. Those who would be satisfied by having 6pack abs never will have them because they usually stop after abs start to become visible. Those who would be satisfied to no longer be obese might never see their toes again... <oriansj>If your goal isn't far past your goal, you'll never hit it <mihi>muurkha, re offlineos: I appreciate links about data preservation and archival projects, but I prefer projects who also track licensing information and let me e.g. only download publications that are licensed to be freely reproduced (unlike libgen which also contains lots of copyrighted works, without explicitly tagging them, and considering this a feature rather than a defect) <muurkha>oriansj: it's an interesting perspective <muurkha>mihi: yes, clearly legal data preservation projects have important advantages over illegal ones <oriansj>muurkha: well it has to do with psychological bias people have when expressing satisfaction when progressing on the satisfaction curve which has a geometricly increasing curve climbing cost. <oriansj>in financial terms, those who would be happy retiring in 60 years are those least likely to actually save up enough to actually retire after 60 years. <muurkha>yeah. also though if your plan for retiring in 60 years involves five things nobody has ever been able to do, you're less likely to be able to carry out those plans than if it only involves one thing nobody has ever been able to do <muurkha>it's more likely still if it only involves things that are already known to be possible :) <oriansj>as we tend to future discount when we should to add interested to the future cost instead. So if you set the goal of $100K/year when you should be setting the goal of 328.1K/year to compensate for a 2% rate of inflation; you would be off the mark by a factor of 3 <muurkha>more generally, though, because plans are uncertain, you won't achieve everything you attempt <muurkha>of the things you plan, you will achieve less than you attempt to achieve, because some of your attempts will fail <muurkha>and we are exploring two consequences of that fact <oriansj>well I've noted 2/3rds of all potential paths explored in bootstrapping resulted in failure (it could even potentially be much higher than that) <muurkha>first, that if a single plan relies on the conjunction of achieving a number of difficult things, then that plan is extremely likely to fail, so it is better to reduce the number of difficult things on the path to success <muurkha>second, that if a single plan relies on the *disjunction* of achieving a number of difficult things, then that plan is more likely to succeed, so it is better to attempt a wide variety of difficult things so that some of them will succeed <oriansj>well I can't reduce the number of difficult problems on the path; I can only encourage more paths to be created <muurkha>when you're making a plan you are choosing which problems to attempt to tackle, aren't you? <oriansj>no grand plan, just a willingness to let other people present options to explore and move the needle in as many directions as possible <muurkha>well, when you're not making a plan, sometimes you aren't :) <muurkha>there's a whole interesting continuum between exploration and planning <oriansj>every grand plan in bootstrapping thus far has failed badly but the paths that looked fun always tended to produce more useful results <muurkha>there are a number of problems on the way to matter compilers that seems straightforwardly solvable <muurkha>but there are a number of other problems that seem potentially very tricky to solve <oriansj>and sometimes the solution to a hard to solve problem is just not solve it at all <muurkha>which of those other problems turns out to be solvable has a strong effect on which of the straightforward ones is useful to solve <oriansj>making a robust and optimizing Compiler in assembly is a nearly impossible task, so we don't do that at all. <muurkha>it's been done, the first Fortran compiler was an example <muurkha>but that was five people working for two years <muurkha>for a long time a number of people have been working on the "diamondoid nanomachine" approach to matter compilers, for exapmle <muurkha>but I think we can avoid solving that problem <oriansj>I hope so but I don't know what unavoidable problem solving must be addressed. <muurkha>yeah, I don't know if, for example, zone refining of silicon is on the shortest path <muurkha>but at least we know zone refining of silicon is a thing that can be done <muurkha>to the extent that you can do things at a small scale you will have a proportionally better result <muurkha>a matter compiler that can compile a copy of itself in six months would be a curiosity, rapidly crippled by laws to prevent its use for "ghost guns", counterfeit money, etc. <muurkha>by contrast, a matter compiler that can compile a copy of itself in six minutes would end material poverty <oriansj>well a matter compiler that can compile a copy of itself in 4 years might flight low enough below the radar <muurkha>no, because after 40 years you still only have 1024 of them <muurkha>or 32 if you used them to create other things half the time <muurkha>in 40 years someone else will have delivered a better design <oriansj>I'd rather just invest for the future generations <oriansj>and use the 1024 to just build the better design <muurkha>the future generations will be using matter compilers that allow them to have one per household or one per family member rather than one per international consortium <oriansj>or more accurately ensure that 1024 of my friends have one too <muurkha>there's another advantage of speed of replication other than exponentially higher productivity <muurkha>which is that it allows quadratically higher learning <muurkha>if you find out about a bug in your design in a week rather than a month, you can try three more new buggy designs during the month, and you'll remember more of what you were doing when you wrote the bug at the time that you discover it <oriansj>if learning is in proportion to the number of matter compilers you have <muurkha>shortening feedback time is absolutely essential <muurkha>you mean, because more people can have one? <oriansj>indeed, more human minds working together <muurkha>I don't think it's closely proportional — MIT in the 01970s had a lot less computers than IBM did <muurkha>it's easy to waste enormous learning opportunities <oriansj>but a great deal more progress as more of the mind capacity was dedicated to learning <muurkha>and certainly having more machines in the hands of more people creates the possibility of more learning <oriansj>and I'd rather have 10 matter compilers in the hands of 10 friends than 100K matter compilers in my own <muurkha>a shorter replication time means exponentially more matter compilers in people's hands at any given date <oriansj>but the number of minds willing to work together is a much harder problem <muurkha>for example, if you can shorten the replication time from 4 years to 3 years, then after 40 years you have 10321 matter compilers instead of 1024 <muurkha>yeah, it's hard for the humans to work together <oriansj>and the odds of the idea needed to generate that improvement increases with the number of minds with access to matter compilers <muurkha>more realistically, if you can shorten the replication time from 7 days to 6, then after a year you have 2 quintillion matter compilers rather than 5 quadrillion <muurkha>yeah, it's important for the people involved to be using the matter compilers to work together rather than against one another <muurkha>I think that was a big part of IBM's problem: their customers were not very good at sharing information <oriansj>well, one of their customers was the State of Michigan; which is aggressive with training up partners <oriansj>If we know better, we tell the vendors we are paying. <muurkha>yeah, but Michigan wasn't competing against GM; Ford was <muurkha>most of IBM's customers were businesses <muurkha>and businesses maybe tend to err too far on the side of not attempting things that are not known to be possible <oriansj>and they didn't yet have the good idea of open sourcing their complement <oriansj>So a million incompatible inventory tracking programs were developed and debugged instead of a single standard one which would have worked so much better <oriansj>well the copyleft trick hadn't been developed yet <oriansj>and SHARE didn't exactly support the idea of portability to suit the needs of business <muurkha>but that still made them major pioneers of portability <muurkha>remember that they predated the 360 by 10 years <muurkha>so even IBM itself had lots of incompatible lines of computers at the time <oriansj>well I guess you could consider being able to run on different products made by the same company as portability; then yeah, I guess I'd have to give you that <muurkha>also they pushed the development of high-level languages like PL/1 <muurkha>because writing portable assembly between unrelated architectures is pretty difficult <oriansj>PL/1 isn't a high-level language so much as an abortion bundled up and sold as is <muurkha>it's a lot more portable than 709 assembly <muurkha>even if the fetus meat isn't to your taste <muurkha>back to matter compilers, I think the closest existing human analogue is maybe bread starter cultures or houseplants <oriansj>granted but by then Lisp, COBOL, Fortran and ALGOL 60 were all valid (and honestly better options) <muurkha>there were a lot of things you could do in PL/1 that you couldn't do in each of those languages <muurkha>for example, you could do COBOL things in PL/1 but not in Fortran, and you could do Fortran things in PL/1 but not in COBOL <muurkha>and LISP was hopeless for any kind of systems thing (it got better!) <oriansj>and people back then were smart enough to compile COBOL into an object file and Fortran into an object file and then just link them together. <oriansj>compile to assembly and use the same assembler wasn't an option? <muurkha>I mean they used the same linker, yes, but different calling conventions and incompatible data types <muurkha>at least when they ran on the same machine, which they often didn't <muurkha>I like ALGOL 60 better than PL/1 but the other three are not really in the same league <muurkha>and ALGOL 60 left a lot of things outside the scope of the standard <oriansj>well the different calling conventions can be worked around with translator functions in assembly <muurkha>yeah, but at that point you might as well just use PL/1 <oriansj>the incompatible data types requires a bit more work but is workable <unmatched-paren>the fortran code would fight back :P "ew you're trying to link me with cobol code?! gross!" <muurkha>so the thing about houseplants and bread starter cultures is that they're not scarce <oriansj>NEVER, pl/m is the only member of the PL/family that shouldn't have been shot and burned with fire <stikonas>bread started is not scarce because it's easy to create even without starter <muurkha>wild yeast doesn't taste the same as Herman <oriansj>Just grow tomatoes and put your dough next to the plants for 24 hours to get the yeasts you want <muurkha>but yeah yeast self-replicates so much that you can even use wild-caught yeast. this is probably a situation we rather want to avoid with matter compilers <oriansj>Then split into batches with isolated culture groups; within 10 generations you should have a solid starter <oriansj>well yeah, wild-caugh matter compilers are so hard to contain <muurkha>because material scarcity still causes enormous human misery, unmatched-paren <oriansj>unmatched-paren: we don't but it'll help with building what we need later <oriansj>as I know I'm not that great on a lathe and probably shouldn't be building a car engine by hand <unmatched-paren>I see. I suppose you're not hoping to just conjure matter up from nothing, right? <oriansj>unmatched-paren: not until we get something like zero-point energy working <oriansj>then we would have more energy than exists in this universe <stikonas>it might not be possible to harness zero-point energy <muurkha>unmatched-paren: no, a matter compiler just rearranges existing matter, in the same way that a software compiler just changes the state of bits that were already part of your hard drive <stikonas>hence there is more of this dark energy (which we think might be zero-point energy) <oriansj>(and ideally assembly the printed parts into a working copy of itself) <stikonas>anyway, back to current bootstrapping topics. oriansj: did you manage to figure out anything about PE header? <muurkha>yeah, hand assembly is not acceptable <stikonas>but first I'll probably start writing hex0.S for UEFI <oriansj>stikonas: not as much progress as I would have hoped but yeah, I should really get a proper hex2 PE header ready for you <stikonas>for building assembly, I guess I'll just use same C compiler (clang) that I used for building C prototype, since it natively supports UEFI target <oriansj>I guess I really need to crack the whip on getting you better starting bits <stikonas>well, next step would be .M0 file which I guess will need those header bits <oriansj>yep, and you'll need it for when we have M2-Planet + cc_* building C code <muurkha>it's missing the Pineapple ONE unfortunately <stikonas>oriansj: yes, but that's quite a bit later... We'll have to do a lot of form on M2libc... <stikonas>still with C prototypes for kaem and hex0 we basically have most of the information that we need on how UEFI works <stikonas>oriansj: do you know if there is a nicer assembler directive for something like hello: .asciz "H\0e\0l\0l\0o\0 \0w\0o\0r\0l\0d\0!\0\n\0\r\0\0" <oriansj>well du 'Hello World',13,10 in fasm would be the cleaner one I saw <oriansj>few that actually have to be seen by the shell