IRC channel logs

2020-02-17.log

back to list of logs

<OriansJ>stupid question but looking at this picture: https://www.pc.gov.au/inquiries/completed/data-access/report/data-summary-large.png
<OriansJ>anyone else think, wouldn't it be cool to have sram with an LED for each bit; so by looking at the memory chips you can see their contents.
<theruran>OriansJ: there would be way too many LEDs, huh?
<OriansJ>256x256 for 64Kb
<theruran>it's an interesting idea. along with using translucent DIP carriers
<OriansJ>yep, it only works for low memory systems
<OriansJ>basically a tiny version of this: https://web.archive.org/web/20191230222252im_/http://www.megaprocessor.com/Images/second_birthday.jpg
<OriansJ>theruran: glass DIP casing
<theruran>even better :3
<OriansJ>300nm cmos on Glass process could look like a more advanced version of Star Trek's Isolinear Chips
<OriansJ>days like this make me wish I knew more people who make hardware.
<xentrac>yes, SRAM with an LED per bit would be super awesome
<xentrac>that could work even for relatively large memories if you don't mind needing a microscope to see the bits
<xentrac>a drawback is that exposing the LEDs would unavoidably lower the immunity of the system to optical attacks, both passive and active, from those who could see them, and also to optical interference
<OriansJ>xentrac: you mean like someone using a laser on the LED to induce the LED to act like a solar cell and thus change its attached sram's value to 1 instead of zero?
<OriansJ>as for increasing density, well one could use different colors for the leds such that a group of say 4 or 16 would represent a single visable pixel but the result would be various different colors depending on what values those 4 or 16 cells had inside of them.
<xentrac>right
<OriansJ>xentrac: couldn't one just use a diode to prevent that sort of reverse charging?
***Server sets mode: +cnt
<xentrac>not really, no
<OriansJ>xentrac: oh well; I guess physical access always wins when it comes to security
<bauen1>we're getting there with tpms that are integerated on the cpu die itself, but with enough time you can still circumvent them ...
<bauen1>btw is there a search-able version of this channels logs or do you need to download all of them ?
<fossy>no I think youd need to Download them
<fossy>theyre not super bog
<fossy>big*
<bauen1>this https://gitlab.com/toaruos/toaruos kernel could also be interesting, since it has already achieved self-hosting (and has a small libc) but i'm not sure on how much of the C standard it depends
<bauen1>and it only targets i686
<bauen1>and i'm pretty sure you could also strip the python stuff from the build process
<xentrac>yeah, I think that's reasonable, OriansJ
<OriansJ>bauen1: well we don't need a gui nor anything fancy
<OriansJ>heck, we don't even require a network stack
<OriansJ>just a filesystem (that supports directories), a handful of syscalls and basic virtual memory.
<OriansJ>As it only needs to function well enough to run a kaem.run script on power-on; which then does all the builds locally and generates the Linux bootstrap binary and grub; which is used from there
<OriansJ>maybe serial port support (optional keyboard and tty)
<OriansJ>It however needs to be very very portable
<OriansJ>(we can have seperate assembly files for each architecture but porting to new architectures should be rather straightforward)
<OriansJ>It only has to be be good enough to run mes-m2 to enable MesCC to compile TCC and bootstrap the rest from there (as GCC 4.7.4 should be able to compile Linux for us)
<xentrac>tty emulation is a few hundred bytes of code
<fossy>OriansJ I plan to go through GCC 2 series first, as 1. Guix is my point of reference and they do that and 2. Less headache. We can remove it later if we want
<fossy>OriansJ: but im sure we can compile a old linux kernel with gcc 2
<OriansJ>fossy: 4.7.4 can be currently be bootstrapped from TCC (which can be bootstrapped from MesCC)
<OriansJ>xentrac: we also are planning on having the kernel written in M2-Planet, so size isn't much of an issue
<janneke>fossy, that makes sense
<janneke>OriansJ: that's theoretically true, practically not so; at least not yet
<janneke>OriansJ: you may be overlooking the Mes C Library that does not support building gcc-4.x yet
<fossy>OriansJ: as janneke said
<fossy>We cannot build gcc 4.x as of yet, because we need a c library
<janneke>there is work underway for mes c library to support gcc-4.6 as well as support m2-planet
<fossy>Mes c library does not support 4, and so we build 2 to build glibc to build 4
<janneke>note that tcc does not have a c library at all
<fossy>Improvements to the system come second: i want to have a known working base
<fossy>But remember the first stage of my fork is to convert commencement.scm to bash
<fossy>huh
<fossy>reverse that, connection weird
<OriansJ>janneke: you don't have to worry about building M2-Planet; quite the reverse actually.
<janneke>M2-Planet should worry about building me :-)
<OriansJ>I guess included in those 57MB of bootstrap binaries is the cheat libc currently being used
<OriansJ>I could have M2-Planet build a much more advanced libc if needed
<janneke>OriansJ: actually not, currently "only" a staically built mescc-tools and mes; the bootstrap-mes will build the mes c library for itself and tcc; tcc builds the mes c library for gnu
*janneke needs to go afk for a bit
<OriansJ>janneke: So what is the problem? Can GCC not use the libc built from TCC?
<OriansJ>or is the mes libc not complete enough for GCC?
<OriansJ>as I would prefer to have accurate information in the current bootstrap map
<stikonas>we need a dependency graph for bootstrap chain which shows finished and unfinished parts :D
<OriansJ>stikonas: well that is what I thought I had, with the color scheme in my current bootstrap map. https://github.com/oriansj/talk-notes/blob/master/Current%20bootstrap%20map.pdf
<OriansJ>and why I made it from a text file to enable easy editing: https://github.com/oriansj/talk-notes/blob/master/Current%20bootstrap%20map.dot
<stikonas>well, yeah, dot files are the best for these types of graphs
<OriansJ>Such that anyone could update them and just do: cat Current\ bootstrap\ map.dot | dot -Tpdf >| Current\ bootstrap\ map.pdf && evince Current\ bootstrap\ map.pdf
<xentrac>I like graphviz a lot but I think sometimes TiKZ can produce better results. not sure whether TiKZ or graphviz is easier to install though
<OriansJ>fossy, janneke please notice that it includes the steps via 2.95.3 to bootstrap 4.7.4
<OriansJ>So perhaps I was clumsy with my words again;
<stikonas>isn't slow-utils optional? Since we already have mescc-utils?
<OriansJ>stikonas: entirely
<dddddd>wait, what?
<OriansJ>It was more to allow Guix to reduce down to just the Guile static binary