--- Log opened Wed May 01 00:00:42 2024
00:56 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has joined #hplusroadmap
01:14 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has quit [Remote host closed the connection]
01:15 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has joined #hplusroadmap
02:18 -!- emg13 [~emg13@80.233.71.104] has joined #hplusroadmap
02:18 -!- emg13 [~emg13@80.233.71.104] has quit [Remote host closed the connection]
02:18 -!- emg13 [~emg13@80.233.71.232] has joined #hplusroadmap
02:58 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has left #hplusroadmap []
03:04 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has joined #hplusroadmap
03:34 -!- TMM_ [hp@amanda.tmm.cx] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
03:34 -!- TMM_ [hp@amanda.tmm.cx] has joined #hplusroadmap
04:21 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has quit [Remote host closed the connection]
04:23 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has joined #hplusroadmap
05:01 < kanzure> https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/
06:56 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has quit [Remote host closed the connection]
06:56 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has joined #hplusroadmap
07:51 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has quit [Read error: Connection timed out]
08:10 -!- TMM_ [hp@amanda.tmm.cx] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
08:10 -!- TMM_ [hp@amanda.tmm.cx] has joined #hplusroadmap
08:14 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has joined #hplusroadmap
11:12 < hprmbridge> kanzure> removal of refusals from llama https://twitter.com/teortaxesTex/status/1785711164132889051
11:13 < hprmbridge> kanzure> https://www.parrhesia.co/p/cognitive-enhancement-in-a-world
11:34 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has quit [Remote host closed the connection]
11:34 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has joined #hplusroadmap
13:43 < kanzure> https://group47.com/what-is-dots/
13:45 < hprmbridge> Lev> ... is this storage write-once?
13:45 < hprmbridge> Lev> or am I missing read/write lifetimes
14:13 < hprmbridge> Lev> ah ok https://cdn.discordapp.com/attachments/1064664282450628710/1235338248973324308/Screenshot_20240501_171300_Brave.jpg?ex=663401e6&is=6632b066&hm=7682892f3d94860e617c4411767f767859e250abbe0f7ac9ccba9791e4cb01ad&
14:13 < hprmbridge> Lev> noice
14:57 -!- emg13 [~emg13@80.233.71.232] has quit [Quit: WeeChat 4.1.1]
14:59 -!- flyback [~flyback@2601:540:8203:8a20:85b9:e582:a9c6:64a] has quit [Quit: Leaving]
14:59 -!- flyback [~flyback@2601:540:8203:8a20::3ec9] has joined #hplusroadmap
17:47 -!- yorick [~yorick@user/yorick] has quit [Ping timeout: 245 seconds]
17:48 -!- yorick [~yorick@user/yorick] has joined #hplusroadmap
17:57 < fenn> why is DOTS better than microfiche film?
17:57 < hprmbridge> Lev> microfilm deteriorates within 50-100 yrs iirc
17:58 < hprmbridge> Lev> Might be thinking of older film types tho
17:58 < hprmbridge> bootstrap3141> The better question is will the tech to read their system exist in 50-100 years…
17:58 < hprmbridge> Lev> idk what modern is like for them
17:59 < hprmbridge> bootstrap3141> If they don’t get enough traction, it’s going to be the same techrot story as every other historical storage medium
17:59 < fenn> i couldn't find any specs about data storage density, but if we assume the "1 micron dot size" is correct, a standard LTO tape should hold about in/2*960m*1bit/micron^2 = 1.5 GB
18:00 < hprmbridge> bootstrap3141> As someone who used to be an archivist for a major motion picture studio, I’d not even remotely consider this until the company has demonstrated success.
18:00 < fenn> which does not compare favorably to the inorganic carbon DVDs
18:00 < hprmbridge> Lev> Apparently every tape begins with a human readable section containing instructions for building a dots reader
18:00 < hprmbridge> Lev> which
18:00 < hprmbridge> Lev> ig
18:00 < fenn> seems fine
18:01 < hprmbridge> bootstrap3141> That’s cool
18:01 < fenn> i want to stamp wikipedia on sputtered polymer ribbons in a similar way
18:01 < fenn> start by bootstrapping a better microscope
18:01 < hprmbridge> bootstrap3141> LTO7 holds 15TB with compression…
18:02 < hprmbridge> bootstrap3141> Anyways.. imagine me as an archivist explaining that the tech I adopted that’s unproven had the company go under, “but hey we can build our own reader”….
18:03 < hprmbridge> bootstrap3141> That’s not gonna fly in the enterprise world
18:03 < hprmbridge> bootstrap3141> Tech seems super cool though
18:03 < fenn> that's not the use case for the "how to build a reader"
18:03 < hprmbridge> bootstrap3141> What is?
18:03 < fenn> it's more like, post apocalyptic rebuilding civilization from the ashes
18:03 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has quit [Ping timeout: 245 seconds]
18:03 < fenn> or really far future archaeology
18:04 < hprmbridge> bootstrap3141> To an F100 company those are sort of the same thing
18:04 < fenn> you have to understand that not everybody in the world is a businessman
18:05 < hprmbridge> Lev> If I did my math right and the wikipedia stats are accurate 1.4 megabytes per square millimeter seems to be LTO9
18:05 < hprmbridge> bootstrap3141> Oh I get that, it’s just foolish to be an early adopter for archive tech is all, biz person or not.
18:05 < hprmbridge> Lev> going off the native size, not compression
18:05 < fenn> frankly i don't see any business use for 100 year archival
18:05 < hprmbridge> bootstrap3141> Movie studios do this
18:05 < hprmbridge> Lev> any time I see "2.5:1" or any hard compression numbers like that I just say "sus"
18:05 < hprmbridge> bootstrap3141> They even have a physical film vault to store original reels for 100 years
18:05 < hprmbridge> bootstrap3141> Those were the biz requirements
18:06 < hprmbridge> Lev> sure but those require active management
18:06 < hprmbridge> bootstrap3141> This studio also has a deal with library of conares
18:06 < hprmbridge> bootstrap3141> Absolutely, archiving is not a set it and forget it practice
18:06 < hprmbridge> Lev> the point of this is you can write it, toss it in a landfill, smack it with a rocket-propelled baseball bat, and launch it into LEO and it's probably gonna be fine
18:06 < hprmbridge> Lev> ofc my main gripe is the write-once and that's why I'd never use it, but
18:07 < fenn> in practice i write once to an archival hard drive and forget it
18:07 < hprmbridge> bootstrap3141> Yeah it sounds super cool, I just don’t see the use case.. most archival data is  WORM
18:07 < hprmbridge> Lev> If I did that I'd run out of space in days lol
18:07 < hprmbridge> bootstrap3141> Not to say you can’t reuse it,  it typically with tape backup it’s used in a WORM pattern
18:07 < hprmbridge> Lev> I mean if I understood them correctly it's basically laser engraving
18:08 < hprmbridge> Lev> ig you could do it multiple times
18:08 < hprmbridge> bootstrap3141> I backup to a NAS, then sync to S3 Glacier tier.  About as good as you’re going to get without running a data center
18:10 < hprmbridge> bootstrap3141> Yeah probably they’re just mentioning it makes the most sense for WORM access pattern
18:14 < hprmbridge> Lev> well like
18:15 < hprmbridge> Lev> most laser engravers cut off around half a mm in thickness give or take, right?
18:15 < hprmbridge> Lev> idk if they have to increase that at all to have good contrast/if the need for that increases as one does more writes
18:15 < hprmbridge> Lev> I could see it degrading very quickly
18:15 < hprmbridge> bootstrap3141> “Laser engravers” sure, but lasers are used photolithography and with the correct optics can become very very very small
18:16 < hprmbridge> Lev> point but they want something that's fast
18:16 < hprmbridge> Lev> not something that requires photomasks to be loaded in and out
18:16 < hprmbridge> bootstrap3141> Doesn’t affect speed, that’s controlled by galvos
18:16 < hprmbridge> bootstrap3141> Didn’t mean use the litho process just that it’s possible to focus lasers to incredibly small pponts
18:16 < hprmbridge> Lev> point
18:16 < hprmbridge> bootstrap3141> Yes thank you
18:17 < hprmbridge> Lev> would you look at that: https://cdn.discordapp.com/attachments/1064664282450628710/1235399789521145926/Screenshot_from_2024-05-01_21-17-32.png?ex=66343b36&is=6632e9b6&hm=b1c14085349d6c0973aacb3ff61a6acda9a0e949fafaf2f5e6ce0090772da8fb&
18:17 < hprmbridge> Lev> lol
18:19 < fenn> in the DOTS video it says it's a phase change system that changes the index of refraction
18:19 < fenn> if they still don't have a product after 16 years, it's not gonna happen
18:21 < hprmbridge> Lev> bring back fan-fold punched tape \s
18:21 < fenn> that's basically what DNA is
18:22 < hprmbridge> Lev> sure but that i need a 20K$ printer for, punched tape i need a camera and a roller
18:23 < fenn> i still think microfiche is the sweet spot
18:23 < fenn> light sensitive film
18:25 < hprmbridge> Lev> speaking of https://blog.mattbierner.com/dna-print/
18:27  * fenn twirls a finger in the air
18:28 < fenn> oh apparently "microfiche" means a single flat sheet of film. i want something like an LTO form factor roll of film
18:49 < fenn> "Vesicular films use an inexpensive process to create use copies of film and fiche. These films take advantage of the fact that diazonium salts produce nitrogen as they decompose when exposed to UV radiation. In vesicular films, diazonium salt coating is sandwiched between two base layers. The film is placed in direct contact with a master film, exposed, and developed by heating the film. As a
18:49 < fenn> result, the image will always exhibit slightly raised areas made of small bubbles.
18:50 < fenn> seems like that wouldn't be good for super high data density
18:51 < hprmbridge> bootstrap3141> Agreed.  So at the studio I worked for, I owned the archival vault, but that wasn’t considered the TRUE backup.  Even for digitally filmed movies film negatives would be generated and sent to library of congress.
18:51 < fenn> silver gelatin / silver halide "is the only microform medium appropriate for archival purposes"
18:52 < fenn> there's this inherent tradeoff between long term media stability and the energy required to flip a bit during the writing process
18:53 < fenn> a developing step is a way to leverage the writing process for extra bit flipping resistance, i.e. it would take more energy to flip a bit after developing
18:54 < fenn> ideally the developing step doesn't involve liquid handling
18:56 < fenn> etch resist and plasma etching would make a high quality product but it's expensive and complex and there are waste products
18:57 < fenn> i'm kinda horrified that the standard practice in microfilm scanners is just two panes of glass and an exposed length of bare film 
18:57 < fenn> like it's not an air bearing? there's nothing to protect the film from stray dust or particles like hair from the operator
18:58 < hprmbridge> bootstrap3141> That does seem insane
18:58 < hprmbridge> bootstrap3141> Or what if someone touches it with bare fingers…
19:00 < fenn> "Grime accumulates on the edges of glass flats, creating a source of film abrasion. Because of this, glass flats and carriers should be cleaned regularly."
19:02 < fenn> this software is probably what i would use for microfilm digital data storage https://github.com/za3k/qr-backup/
19:03 < fenn> it might be too slow with large chunks of data. ideally your parity bits would be over the entire tape, not just one segment at a time
19:04 < hprmbridge> geraldmahony> Thought this was synthesizing + blotting literal DNA onto meters long paper, got excited
19:04 < hprmbridge> Lev> sorry to disappoint lol
19:04 < hprmbridge> Lev> fountain code that shit
19:05 < hprmbridge> Lev> luby transform is a bit eh but its really not that difficult to implement
19:08 < fenn> yeah i guess you could encode copies of the fountain decoder in the first and last few pages worth of the microfilm
19:09 < fenn> one of the goals of qr-backup was not depending on any special software
19:09 < hprmbridge> Lev> i mean fwiw luby transform is simple enough i doubt it'll be forgotten anytime soon unless we completely forget about coding theory as a whole
19:10 < fenn> right now i have no idea how to actually generate fountain codes, on the computer i am using right now
19:10 < hprmbridge> alonzoc> Also redundantly coded data has enough structure that someone will pick up on it if they're able to run analysis via a computer. Reverse engineering error correction schemes is a lot less involved than cryptanalysis
19:10 < hprmbridge> Lev> Luby transform is take some data, split it into blocks of size K, and then xor together random sets of blocks to generate new blocks
19:11 < fenn> it does sound easy, but i still can't just type 'fountainify foo.txt'
19:11 < hprmbridge> Lev> You can then peel out the original blocks as you xor the combinations together, since x ^ x = 0 and y^ 0 = y
19:11 < hprmbridge> Lev> the peeling routine is the only really complex portion
19:12 < hprmbridge> Lev> and it's just glorified gaussian elimination reallp
19:13 < hprmbridge> Lev> ...
19:13 < hprmbridge> Lev> do i need to remind you of the time you were convinced you broke LPN
19:14 < hprmbridge> alonzoc> Well I did for sufficiently high sample rate which is the case I was interested in
19:14 < hprmbridge> Lev> fair
19:14 < hprmbridge> Lev> compressed sensing?
19:16 < hprmbridge> alonzoc> I was using it to mine long-range linear correlations in ciphers remember? I've also got some more tricks I want to leverage to exploit replica breaking etc.
19:17 < hprmbridge> Lev> oh yeah
19:17 < fenn> raptor codes are used in dvb digital tv transmission, so maybe that code is commonly available
19:17 < hprmbridge> Lev> patents have probably expired on em by now
19:17 < hprmbridge> Lev> maybe
19:17 < hprmbridge> Lev> i should check
19:17 < hprmbridge> Lev> They're a bit more involved, but same general idea as luby transform
19:18 < hprmbridge> Lev> mostly just making more intelligent choices about which blocks to xor together and integrating some in-block ECC on top of the fountain code, iirc
19:19 < hprmbridge> Lev> hmmm apparently some of the patents will expire this yr but others are still active
19:20 < hprmbridge> Lev>  https://cdn.discordapp.com/attachments/1064664282450628710/1235415521617248326/Screenshot_20240501_221959_Brave.jpg?ex=663449dd&is=6632f85d&hm=a0da2de35f85191418249459d77acb0b628a1fc99ab6c0a6710e02ff36bcfb6e&
19:21 < hprmbridge> Lev> <https://patents.google.com/patent/US7139960>
19:22 < hprmbridge> alonzoc> But regardless a standard coding scheme can be reverse engineered especially if like erasure coding it has some blocks which are standard plaintext and the rest are redundancy
19:24 < fenn> i am assuming that whoever is recovering the data is a total moron and can barely run a computer
19:24 < hprmbridge> Lev> eh at that point just give the computer an arm to whack em with a 2x4
19:25 < hprmbridge> alonzoc> So in the far future I wouldn't worry about lack of being able to read the data from the coding scheme. If they have computers they can work it out especially if we're storing a nontrivial amount of data.
19:25 < hprmbridge> alonzoc>
19:25 < hprmbridge> alonzoc> Okay under an assumption of moron you have an issue. But there's a difference between moron and hasn't got access to technology
19:25 < fenn> i'd rather there not even have to be a computer involved, but it's required for any kind of error correction and data types beyond text and 2d images
19:26 < fenn> if part 1 is literally pixel font images of text and low resolution thumbnails, they shouldn't need a computer to read it
19:26 < hprmbridge> Lev> I mean you can do luby transform by hand you'd just want to kill yourself after the carpal tunnel sets in
19:27 < hprmbridge> Lev> it's how I wrote out my test vectors for when I wrote my first impl of it
19:29 < fenn> say we etch pixels in a barber pole helix on a cylinder made of hard material, then use it to indent a gold sputtered ribbon, or some other durable soft metal
19:30 < fenn> the expensive part will probably be making the cylinder, and also a marginal cost of running the indenting process on each ribbon. the actual pixels themselves don't matter
19:31 < fenn> pixels that could potentially be used to store compressed text or images is effectively wasted as uncompressed text and images, so we want to minimize that to the essential steps required to build a decompressor
19:32 < fenn> but then you don't know which parts are going to survive the archival process. it could have nanoscale abrasion, be burned in a fire, cut into hundreds of tiny pieces for use as decoration
19:33 < fenn> so ideally the "how to build a decompressor" instructions would be covering 100% of the tape, and also redundant in a stupid way that a human can understand. the compressed data would have to be encoded as the background of the letters or as the letters themselves (or both)
19:34 < fenn> if the letters were 30% gray and 70% gray instead of black and white, you could encode a lot of data in the dithering
19:35 < fenn> or maybe diffraction patterns so the letters and backgrounds look like different colors
19:36 < fenn> or maybe the letters themselves could be white light holograms seen in sunlight
19:36 < fenn> but i don't know how to do that and also encode data at the same time
19:52 < fenn> and some versions of them should NOT have crazy holographic colors that will get them cut up into decorative pieces
20:39 -!- mxz__ [~mxz@user/mxz] has joined #hplusroadmap
20:39 -!- mxz [~mxz@user/mxz] has quit [Ping timeout: 268 seconds]
20:40 -!- mxz__ is now known as mxz
20:41 -!- mxz_ [~mxz@user/mxz] has quit [Ping timeout: 268 seconds]
22:46 -!- mxz_ [~mxz@user/mxz] has joined #hplusroadmap
23:09 -!- TMM_ [hp@amanda.tmm.cx] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
23:09 -!- TMM_ [hp@amanda.tmm.cx] has joined #hplusroadmap
23:40 < hprmbridge> kanzure> "learnable activation functions on weights"
23:42 < hprmbridge> kanzure> or people could just read https://gershmanlab.com/pubs/memory_synthesis.pdf
23:49 < hprmbridge> kanzure> "Kolmogorov-Arnold Networks (KANs)" https://arxiv.org/abs/2404.19756
23:50 < hprmbridge> kanzure> "Inspired by the Kolmogorov-Arnold representation theorem, we propose Kolmogorov-Arnold Networks (KANs) as promising alternatives to Multi-Layer Perceptrons (MLPs). While MLPs have fixed activation functions on nodes ("neurons"), KANs have learnable activation functions on edges ("weights"). KANs have no linear weights at all -- every weight parameter is replaced by a univariate function
23:50 < hprmbridge> kanzure> parametrized as a spline"
--- Log closed Thu May 02 00:00:43 2024