IRC channel logs

2022-06-26.log

back to list of logs

<muurkha>she is :)
<muurkha>it's true, we are!
<oriansj>So let us know how we can help
<stikonas>fossy, oriansj: I've now added PR to use replace command to create mescc.scm
<stikonas> https://github.com/fosslinux/live-bootstrap/pull/185
<Hagfish>looks good
<Hagfish>the only line that catches my (uninformed) eye is:
<Hagfish>for (count = 0; count < attempts; value += 7777, ++count)
<Hagfish>it's in the original lib/tempname.c so it's not a problem with your PR, it's just curious
<Hagfish>i don't know if there is some deeper meaning to "7777" but it's probably no worse than any other choice
<stikonas>well, read coreutils sourcecode if you want to understand that, I didn't read it, so I cna't answer
<stikonas>might be just "random" large number
<Hagfish>yup, fair enough
<stikonas>if many attempts to construct a valid temp name fails, then I guess give up
<stikonas>it's old coreutils anyway, probably not even present in the latest version
<Hagfish>that's a reassuring thought :)
<muurkha>oriansj: she says thank you very much, you (we?) are very nice!
<oriansj>stikonas: looks good, the only thing I might change would be separate temp files for the replacments but that is just a style detail and not one I would expect you to confirm to (as clearly I make so many unique artifact files for auditing purposes)
<oriansj>muurkha: well I (we?) hope to earn that reputation. be sure to let me know what I can do to help
<muurkha>:)
<GNU\Andrew>oriansj: i do think that assemblers should be made first
<oriansj>GNU\Andrew: reasonable, so what do you mean when you talk about those first assemblers? For me, I start with hex because everyone can agree on what that means and will work on all sane computing architectures (post IBM/360 [which made the 8bit byte standard]) and that it will involve extra complexity for less sane architectures (if your instructions are 11bits long I'm gonna have to share the nibble between instructions)
<oriansj>a further reason why I choose that is because "good ideas don't go stale" and when one has to distribute software with no assumptions of what the recieving party has available to them; even back in the 1980s printed hex for programs of only a few hundred bytes in size was the preferred solution (excluding the very special case of knowing that those systems had a higher language available baked in like basic or FORTH or even a simple
<oriansj>assembler)
<oriansj>it is one of the reasons why magazines which enforced that universal survived better than those with: using the software from last issue do X
<GNU\Andrew>modern architectures are pretty much all insane though
<oriansj>GNU\Andrew: 8bit bytes, byte aligned words, instructions that are expressed with a finite and known set of bytes and turing complete subset sets of instructions. Are actually quite sane and reasonable. Now you certainly are right that most architectures are perhaps not as pretty or clean as one would like but even x86's Turing Core is actually fine.
<oriansj>granted some things like RISC-V's immediate encoding format are not clean for human processing but it isn't completely imposible to work with.
<oriansj>if an architecture is sane enough to work with to do useful work, then it is quite possible to do the stage0 steps on it, even if there is no kernel, bootloader or any software for it at all.
<GNU\Andrew>MMIX is the sanest I've seen
<GNU\Andrew>But yeah, modern ones aren't *so* bad
<GNU\Andrew>just not as clean as I might like
<oriansj>well MMIX was designed mostly from the perspective of a software engineer and it makes a few early RISC mistakes but yes it is quite sane to work with.
<oriansj>for example the optimial number of registers given the current level of compiler technology was found to be 88.5 with only minor advantage to having just 64 and even less advantage to having 128 registers
<oriansj>and most of the special purpose registers would be best replaced by more general purpose instructions. For example rD and rR could be replaced by just special purpose division instructions that return that part. with modern macro-op fusion in hardware it'll be the same performance wise but much cleaner architecturally. same for rH
<oriansj>and there is some evidence that the optimal for integer registers is considerably smaller than for floating point and would benefit more from having a cheaper context switch cost.
<oriansj>So despite my preference for mixed integer/floating point registers like the Motorola 88000, unfortunately there are real world advantages for shifting a little bit of complexity into user space.
<oriansj>although I am of the camp that believes one should expose a unified and simple architecture to the programmer and do the extra work required to be separate and performant behind the ISA. Such as the 1 clock cycle sync that the DEC Alpha 21264 did with its Ebox
<oriansj>GNU\Andrew: if MMIX is the sanest you have seen: you have seen Knight yet?
<GNU\Andrew>No, I haven't found that yet
<GNU\Andrew>oriansj: Can you link it to me? A simple WWW search for "Knight architecture" yields no relevant results
<oriansj> https://github.com/oriansj/knight-vm/blob/master/ISA_HEX_Map.org
<GNU\Andrew>Thanks
<GNU\Andrew>git clone https://github.com/oriansj/knight-vm/
<GNU\Andrew>uh, wrong fb
<oriansj>no worries
<muurkha>at least it wasn't your password
<GNU\Andrew>Fun fact, I was tired one day (too much homework), and I needed to reconfigure my IRCd
<GNU\Andrew>I had an issue configuring server linkage and pasted my link password into the support channel and got one 'invalid link: host mismatch' warning
<oriansj>GNU\Andrew: at least it isn't as bad as selling servers with a hard-coded administrative account with the unchangable password of badgers
<oriansj>and yes the username of that account was HP
<muurkha>heh
<muurkha>it can always be worse. the unchangeable password could have been "pinkypieyiff69"
<oriansj>Well the worst unchangable password I have seen was the user account admin with the password ibm
<oriansj>and yes that was for online banking software
<oriansj>which resulted in a security patch from IBM which just changed the password to summeroflove69!
<GNU\Andrew>At that point, I'd either just not use that software, or have a serious look at its source code
<oriansj>which upon reporting that to IBM resulted in another security patch which changed the default passwrd to dick but finally enabled us to set the password.
<oriansj>GNU\Andrew: well ideally yes but unfortunately most people are stuck in environments where they are not able to make good decisions nor empower themselves
<GNU\Andrew>oriansj: Yup
<oriansj>hence why stage0 and live-bootstrap start with the assumption that the user might not have any freedom respecting software and build everything up from a minimal seed that could always be created
<oriansj>oh minor hint: with stage0-posix when you clone you'll want to add --recursive
<oriansj>If you have already cloned it run `git submodule update --init` or after a pull be sure to do: 'git submodule update --recursive'
<GNU\Andrew>I've dealt with submodules before, their origin URLs are a pain
<GNU\Andrew>I always forget to use the public origin URL for them, lol
<oriansj>oh, I only use public urls because the most important thing for me is for other people to be able to use my software without issues
<oriansj>I'd much rather look like a fool than for someone to miss out on getting freedom because of a mistake of mine.
<oriansj>Alan Kay said: "Living organisms can't survive in their own waste products", so perhaps a meaningful and important question is what are the waste products of the bootstrappable community?
<oriansj>I'll start: software that is good enough to call done, collective coordination as an expectation for development and skilled programmers as a population side effect.
<oriansj>or if it is easier: what oriansj has done wrong and could do differently to improve the long term health of the bootstrappable community.
<oriansj>and yes stop reflecting/overthinking so much is a valid response
<oriansj>oh and I still need volunteers to administrate the server I'll be renting for the bootstrappable wiki
<stikonas>oriansj: have you thought about creating a repo with config? Then administration can be distributed a bit (i.e. anybody can do git pull request)
<stikonas>I know KDE has something like this (https://invent.kde.org/sysadmin/kde-ansible), so anybody can contribute, spin up VM to test changes and submit PR
<oriansj>stikonas: no I haven't, but I guess I should. I've been mostly looking at renting a 1U rack space and putting a couple TB of storage in it
<oriansj>but that is a good idea
<stikonas>well, I'm somewhat familiar with ansible too, we use it at work
<stikonas>but it's mostly self-descriptive and fairly easy to pick up anyway
<unmatched-paren>I think a `guix shell` should be able to achieve something similar to ansible, if I understand what you're trying to do correctly?
<stikonas>well, I don't think we know exactly what we are trying to do yet
<unmatched-paren>I see.
<oriansj>the problem set is as follows: Have a server securely configured to host the bootstrappable wiki (and possibly artifacts such as source tarballs)
<stikonas>but it's probably something like install required packages, configure web server, including its configuration files, configure letsencrypt, install wiki software
<unmatched-paren>stikonas: that is exactly why `guix system` exists
<oriansj>I can buy the domain and pay for the server but I don't have free time to properly administrate it
<unmatched-paren>you can configure nginx through guix system
<unmatched-paren>and probably certificates too
<stikonas>well, feel free to try it
<unmatched-paren>I'm not sure guix has a mediawiki-service-type yet though
<unmatched-paren>stikonas: I don't have a server :P
<oriansj>unmatched-paren: did doesn't have to be mediawiki
<oriansj>^did^it^
<unmatched-paren>oriansj: Fair :)
<stikonas>ideally it should run in VM, not just on physical server
<unmatched-paren>stikonas: `guix system vm`
<unmatched-paren>also `guix deploy` does some things that are probably useful here
<oriansj>and I am willing to let the people doing the administration to make those decisions
<stikonas>exactly
<stikonas>there are a few different options
<unmatched-paren>What other good wiki backends are there?
<stikonas>oriansj mentioned docuwiki
<stikonas>or something like that
<unmatched-paren>It does seem like mediawiki would be one of those creaky old ancient things that are annoyingly difficult to package and configure
<unmatched-paren>Especially because PHP.
<oriansj>and because the wiki is low edit anyway, it can even be generated html pages
<stikonas> https://github.com/jmoiron/gowiki ?
<stikonas>(no idea if it's good, just found it)
<unmatched-paren>oriansj: we could use haunt or that other Guile static site generator
<GNU\Andrew>oriansj: Yeah, I just forget to do so a lot and use SSH urls
<stikonas>gowiki doesn't seem to be maintained though
<stikonas>unmatched-paren: here is some comparison https://en.wikipedia.org/wiki/Comparison_of_wiki_software
<unmatched-paren>stikonas: That seems like the one wiki page that is most likely to violate NPOV on Wikipedia :)
<oriansj>yep, haunt is also another valid option *IF* that is what the administrator wants to support
<oriansj>also as I'll be renting a 1U rack, multiple VMs are also an option if one wishes
<stikonas>unmatched-paren: yes, but it seems to be mostly list of facts
<unmatched-paren>oriansj: Or we could go old-school and use The One True Wiki <https://en.wikipedia.org/wiki/WikiWikiWeb> :P
<oriansj>unmatched-paren: hey, I'm game
<oriansj>the only thing I would add as a requirement for the server is port knocking as a requirement prior to being able to connect on administrative interfaces (sftp, ssh)
<oriansj>and no one being able to be able to su to root
***genr8eofl__ is now known as genr8eofl
<Hagfish> https://hackaday.io/project/185991-the-8bit-keyboard
<muurkha>I thought that was interesting
<Hagfish>i hadn't thought about wanting to input key combinations (alt, ctrl etc.)
<Hagfish>if you just want single key presses, i think the implementation could be much simpler, and the "typing" much quicker
<stikonas>interesting but certainly not very practical (unless you actually use binary and not hex)
<Hagfish>yeah, a keyboard for typing hex would make more sense in most circumstances
<Hagfish>i'm imagining two sets of 4 push buttons, and whenever two of the buttons are held down together, it sends the resulting nybble
<Hagfish>(that does mean that whatever is receiving this input has to accept half-bytes at a time)
<stikonas>for inputting initial hex0, yes
<stikonas>after that just use normal bytes 0-9 A-F and use hex0 to combine nybbles