IRC channel logs

<OriansJ>mihi: the instruction set on the gigatron is entirely encoded in the 32KBEPROM; so in theory it could be anything one wanted. (Assuming it could fit as microcode in 32KB) but then again don't put any value in my view on instruction sets (I am extremely biased)

<OriansJ>sorry, correction: 64Kx16 UV erasable EPROM https://gigatron.io/?page_id=482

<OriansJ>so 128KB

<OriansJ>heck with some creativity; someone could implement the knight ISA on it

<OriansJ>and light fuzzing on the stage0 vm has uncovered a few segfault conditions where a program could crash the vm. So I cleared those out (I'll have to do more fuzzing later)

<xentrac>the microcode encoding might not be very efficient

<xentrac>hooray fuzzing and bugfixing!

<OriansJ>xentrac: true; but I'm open to improvements in knight ISA encoding ^_^

<xentrac>heh

<xentrac>I mean the gigatron's way of decoding its EPROM

<OriansJ>xentrac: oh, I was thinking of what insanity would be required to shoe horn knight's ISA into that EPROM and thus provide another hardware root of trust.

<xentrac>yeah, I think that's a reasonable approach, I'm just saying the gigatron's way of decoding the EPROM might be too inefficient

<OriansJ>xentrac: quite possibly as I haven't looked at it in too much detail but oh well. Stage0 seems to be a never ending stream of false starts and dead-end projects that looked promising but never panned out.

<OriansJ>ironcially doing the things people say never to do; ends up working surprisingly well.

<xentrac>:)

<xentrac>it's probably best to spend some amount of effort on things that might shorten the path significantly

<OriansJ>like don't write a macro assembler in hex2; do a 4char forth (clearly the reverse appears far more true)

<xentrac>but of course most of them don't pan out or they would already be the path

<xentrac>Forth has a culture problem in that it attracts people who like puzzles

<OriansJ>or never write a C compiler in assembly (that one was way either than I would have thought possible)

<xentrac>for the last 25 years, almost *only* people who like puzzles

<xentrac>those people are unlikely to give good advice about the best way to structure a codebase to be the least effort either to write or to understand, particularly by non-puzzle-fans

<OriansJ>xentrac: well FORTH suffers from the same sin as Lisp; it enables brilliant people to write code that mortals can not understand.

<xentrac>nah, that's hubris and ego, not actual difficulty ;)

<xentrac>or actual brilliance

<xentrac>qmail is actual brilliance

<OriansJ>C seems to have a collective development property where it is much more difficult to write code that mortals can't simplify and understand.

<xentrac>note that this thing about advice would still be true even if Forth were actually the best possible way to solve the problem, because those people would still tell you the worst possible way to solve the problem in Forth :)

<OriansJ>well FORTH as just a language is fine; its ease of abuse however makes it trivial to lose people and fast

<xentrac>C is designed by humble people who wanted to get work done. this may originally have been true of Forth but it isn't true of modern Forth

<xentrac>or, I think, modern Chuck Moore

<xentrac>Forth is fun precisely because it enables clever hacks

<OriansJ>xentrac: I am not sure anyone who read K&R would agree on the humble part

<xentrac>I've read K&R more than once

<OriansJ>I don't get "I am just a humble developer" vibes from it

<xentrac>as well as the Golang docs, a bunch of papers from Bell Labs of that era, Ritchie's history of C for HOPL, etc.

<OriansJ>ego is one of the most common traits for language designers; I am not sure why

<xentrac>well, you have to be somewhat confident in your own ability to embark upon the enterprise ;)

<OriansJ>possibly because you have to have enough ego to look at all the other languages, declare them crap and show that you can make something better.

<xentrac>in 1984 clever Forth hacks involved getting your 8-bit microcomputer to do things it could barely do at all, like an IDE with virtual memory, or a new kind of user interface with transparent persistence. now instead it involves making your 64-bit microcomputer do things in less code or less memory than you would need to do them in C++ or Python

<xentrac>yeah. or maybe not "crap" necessarily but at least something you're confident you can improve on

<OriansJ>xentrac: I'd put GEOS against any FORTH GUI/IDE anyday

<xentrac>GEOS from 1984 or GEOS from 1994?

<OriansJ>both

<xentrac>interesting, I don't think GEOS in 1984 really holds a candle to F-83 (though that has no GUI)

<xentrac>for the PDP-11 in 1973 it wasn't too difficult to be confident you could improve on the state of the art

<xentrac>I mean, BLISS-11, MACRO-11, and I don't know fucking FORTRAN-66

<xentrac>I don't think there was even a PL/I implementation for the -11 at that time

<OriansJ>vs making use of every single byte on a C64 to do what everyone thought was impossible

<xentrac>right, yeah

<xentrac>the problem is that "what everyone thought was impossible" is a much higher bar; ever since about 1995, nothing you can display on the screen can clear it

<OriansJ>now some people might point out FORTH object code compactness; but sweet16 showed assembly can easily play such games too.

<xentrac>you need actual interaction, and even in terms of actual interaction it's... pretty hard to beat what you can put together in a day with Godot with any amount of bare-metal coding

<xentrac>yeah, I don't know if you saw my note comparing FORTH object code compactness to SWEET-16?

<OriansJ>xentrac: yes I did

<xentrac>have you read the Lions book? I think that's the thing that really brought home to me the humility of Thompson and Ritchie

<xentrac>I'll leave the link here in case other people are interested in the object code compactness question: https://dercuano.github.io/notes/tiny-interpreters-for-microcontrollers.html

<OriansJ>xentrac: well the Lions book wasn't written by Thompson or Ritchie

<OriansJ>sure the code was theirs but most of the comments were not

<xentrac>yeah, I mean the code :)

<OriansJ>oh, well straight forward C code is just a practical engineer's style

<OriansJ>They only got complicated when they had to (you are not expected to understand this code comes to mind) and usually when they could they stripped out the complexity (Plan 9 and all)

<OriansJ>but only for an engineer who's goal is simplicity above everything else (including portability, security and reliability)

<xentrac>Right. And it's also what you see in Forths from that era, or in F-83

<xentrac>But at some point around 1995, the last practical engineers abandoned Forth to the puzzle enthusiasts

<xentrac>(also, above performance)

<OriansJ>xentrac: well have you ever tried to cooperate on a project in FORTH with another human? It becomes trivial to get in each other's way

<xentrac>no. Honestly I don't understand how the humans ever cooperate on anything at all

<xentrac>I have no clue how organizations work

<xentrac>I mean, buying and selling things, I think I mostly understand

<OriansJ>It was frustrating within a couple of days

<xentrac>And sharing knowledge and learning from people

<xentrac>But I totally don't understand teamwork

<OriansJ>working on C code with another person, is surprisingly easy to compartmentialize

<xentrac>I'd like to, I think teamwork is cool, and it produces a lot of nice things

<xentrac>I just don't understand how to do it or how it works from the outside

<OriansJ>but it requires compromise and giving up some good things you might want

<xentrac>Sure, in theory I understand that

<OriansJ>it is harder when skill sets are not carefully matched.

<xentrac>I just don't know how to make it work in practice

<OriansJ>xentrac: you start with shared goals and then you compromise to approach the problem

<xentrac>are the shared goals necessary? I had the impression that a lot of employees work on things because they get paid to, not because they independently came to the conclusion that those things were valuable?

<OriansJ>the problem is when you have different goals or are unwilling to compromise on how to achieve that goal

<xentrac>and sometimes prisoners work on things in order to avoid punishment?

<xentrac>or maybe more directly in both cases because they're told to?

<OriansJ>xentrac: keep getting paid and avoiding punishment sound like shared goals to me

<OriansJ>there is a culture in the workplace which generally selects against those who might change how things are done.

<OriansJ>There is a good example of this in DEC is dead, long live DEC

<xentrac>hmm, is getting paid really a shared goal? Like, if Bob and Alice are working for Carol, then Bob's getting-paid goal is for Bob to get paid, not Alice or Carol

<xentrac>like, if Bob doesn't get paid but Alice does, typically Bob gets dissatisfied, in my experience

<OriansJ>xentrac: Bob realizes if he makes trouble for Alice; she might make it harder for Bob to keep getting paid.

<xentrac>of course Bob might want Alice to get paid so she doesn't quit or sabotage the project, but Alice getting paid isn't really the motivation that gets Bob out of bed in the morning, is it?

<xentrac>right, but of course she wouldn't do that if Bob getting paid were a goal she shared

<OriansJ>xentrac: most people get out of bed in the morning for their jobs because they exist in a society which on average has minimal savings and soul crushing poverty

<xentrac>right, see, that's what I mean about unshared goals

<OriansJ>they both desire not to starve to death in poverty if possible but they will act against each other if set up correctly.

<OriansJ>hence why it is easy to turn employees against each other (and unions become hard to form)

<xentrac>right

<OriansJ>collective action problems are effectively impossible for "minor" issues

<xentrac>so then on top of that basis you need to forge some kind of shared goals

<OriansJ>bootstrapping is a massive global issue; but the individual pain is generally small. Hence why help is never coming.

<OriansJ>Hence why I choose to play with my kid rather than work on it.

<OriansJ>Hence why janneke when choosing between mes-m2 and time with his family or doing work to get paid; skips mes-m2 work.

<OriansJ>It isn't wrong or evil but a natural product of human nature. We address what we feel are more important problems first.

<xentrac>I wish I were better at making choices like that. I wouldn't be borrowing rent money from my girlfriend

<OriansJ>xentrac: not everyone agree on what is important.

<xentrac>instead I end up writing things like https://gitlab.com/kragen/derctuo/blob/master/minimal-cost-computer.md

<xentrac>I think most smokers agree that quitting is important

<xentrac>and I agree getting work done for clients and employers is important, and that washing the dishes is important

<xentrac>but I'm having a terrible time getting any of that done

<xentrac>playing with your kid is awesome, keep it up, you won't regret it

<OriansJ>xentrac: I don't have an answer for how to manufacture motivation to work on things that I feel are unimportant

<OriansJ>there is a reason I still am a P11-E (E stands for Entry level employee) despite saving the State of Michigan over $30Million dollars in 5 years

<OriansJ>I am stubborn; I solve problems in ways that despite being right are not compatible with the culture (Like Replacing IBM ClearCase with Git)

<OriansJ>I stick to my guns and push hard on things I know are right (took 4 years to get the git transistion to happen)

<OriansJ>even when it looks really bad to keep doing it (Pointing out that Windows 10 violating HIPPA)

<OriansJ>If I played the game and did things in the way of the culture; I'd be a P14 by now making $130/hr rather than the $39/hr I am making now

<OriansJ>but I don't fit in the culture; I never could (I just can't recognize people by face)

<OriansJ>The State of Michigan has a culture were security is a checkbox and rub some commercial products on it.

<OriansJ>I've worked on projects that had 140+ outages a day and won an industry award for being the model of "project excellence" because it cost $6M/year and was able to support 20 users.

<OriansJ>so xentrac to answer your question. I only know how to work with people who care about measurable results with a common set of goals. Getting other people to give a shit about my work; clearly isn't a skill I have.

<fossy>Ugh

<OriansJ>fossy: ?

<fossy>Your work is a real shitshow by the sounds of it

<fossy>Your employment work I mean

<fossy>Not bootstrappable of course

<OriansJ>fossy: it is government work as a Computer Security and Reliablity Engineer

<OriansJ>The culture is about minimizing public shame and admitting you wasted millions on crap makes you look bad

<OriansJ>If the government wanted to be efficient, it should be actively trying to make failure cheaper and faster. Rather than "no project is ever allowed to fail"

<OriansJ>Blame shifting is a natural conclusion.

<fossy>agreed

<OriansJ>We pay the vendors so that if something goes wrong it isn't our fault but theirs.

<fossy>"make failure cheaper and faster" I like this

<OriansJ>So me making a system they spent $110M on; look like a piece of crap with code I wrote in 2 days. Is a big "no-no"

<OriansJ>Some days I think they only keep me because they need me not because they want me there.

<OriansJ>and having facial aphasia makes job interviewing quite difficult for me.

<OriansJ>nothing like meeting someone, introducing yourself and then introducing yourself again in 5 minutes because I don't recognize the person I was introduced to.

<OriansJ>It makes me look incredibly stupid

<OriansJ>But I make enough to survive and meet my retirement goals; while enabling my wife to be a stay at home mom and have "Good Insurance".

<OriansJ>A happy normal person doesn't spend 20hours straight programming in assembly for free

<OriansJ>or spend 4+years dealing in hex-encoded files to enable a bootstrap to a C compiler and a scheme.

<OriansJ>But I guess being the first person to ever write a C compiler in ARM assembly; is a nice perk of starting with a manufactoring defect right out the gate. Even if no one else seems to care that I did it.

<OriansJ>The only suggestion is habit and discipline; set a schedule to spend time on shit you don't want to deal with but must and stick to it out of habit. As one must choose between the pain of discipline and the pain of regret. Discipline hurts less in the long run.

<OriansJ>I really rant too much, don't I?

<xentrac>I wonder if facial recognition software is good enough to serve as a disability accommodation for faceblindness now

<xentrac>I appreciate your ranting, I just had to call my ex-girlfriend with borderline personality disorder

<xentrac>I think writing a C compiler in ARM assembly is awesome

<xentrac>being a happy normal person is overrated. happiness is important; normality is counterproductive

<OriansJ>xentrac: sadly not yet (in the FLOSS space); also it forces one to actively collect facial data on the people you interact with.

<OriansJ>ouch that has got to suck.

<OriansJ>I wonder if instead of dumping M1 output, I dumped gas standard assembly it would be more interesting.

<OriansJ>I probably should name it something other than cc_* to avoid confusion. Any recommendations?

<OriansJ>I was thinking of Gas-C (as a pun on gassy)

<OriansJ>since it'll be a quick fart of a project

<xentrac>well, I'm actively collecting facial data on the people I interact with (in person) anyway; normally I'm just doing it inside my private brain

<xentrac>using gas standard assembly is surely a good idea

IRC channel logs

2020-10-24.log