Hide Idle (>14 d.) Chans
← 2019-04-05 | 2019-04-07 → ↓
a111: Logged on 2019-04-05 23:25 OriansJ: well, I guess a really important question to ask is at what level of lithography people here actually have trust? (1 transistor, AND Gate in TTL, 100 Gate ALU, 1000 Gate ULA, 10000 Gate Asic, .... FPGA, 1B+ gate CPU, etc)
spyked: http://btcbase.org/log/2019-04-05#1907021 <-- the problem with "portability" (in the sense of supporting/maintaining the same software interface across different hardware architectures/configurations) is that it's a convenient lie most of the times. the goal isn't to implement the same DOS for all architectures, but to have some sort of DOS that provides some functionality and otherwise stays out of the pr
a111: Logged on 2019-04-05 23:02 OriansJ: bvt: Actually DOS wouldn't be the correct direction as it is actually more complex to implement portably and it's abstraction layer isn't right for a good general bootstrap.
spyked: ogrammer's way most of the time
spyked: that is, for whatever architecture it's implemented on, it doesn't have to be the same DOS
spyked: the http://btcbase.org/log/2018-04-16#1799857 thread also perhaps relevant here
a111: Logged on 2018-04-16 15:20 mircea_popescu: the best example i can think of is the code on the old handheld calculators. THAT is a general purpose os : it makes no assumption about the downstream, merely fully, cleanly and directly exposes the hardware.
spyked is off into the mountains
diana_coman: BingoBoingo: is WU the only option for those wff?
diana_coman: it seems quite surprising to me there isn't more interest but tbf I haven't used local WU ever, would need to even look it up, lol.
OriansJ: Mocky: floating point support is part of being turing complete. We can either bitch about how bad it is (Like the old MIPS engineers) or accept the reality and figure out a why that costs us the least.
Mocky: bullshit, lol
Mocky: and in addition you suggested floating point as software addon. turing completeness can now be achieved after the fact!
OriansJ: spyked: well the iCE40 is a good starting point for now and I guess we can agree on that. You are right about not having to be portable but I prefer building a stack that can be used to defend against a Nexus Intruder program class attack.
Mocky: I've gotta run though, worn motorcycle tire needs wrangling
OriansJ: Mocky: yes that was my point; floating point will either exist in hardware or software because of Turing completeness.
OriansJ: So we can either make simulating more complex instructions in software easy or we can shoot ourselves in the foot trying to avoid the unavoidable (The ability to support floating point)
Mocky: "someone will certainly want X" therefore "we make X easy"; mno
OriansJ: and let us be honest here; making it easy to trap on undefined instructions, jumping to a software routine that performs the functional definition of that instruction and returning to right after the trapped instruction. Will allow us to ditch instructions in hardware without fear of breaking our bootstrap.
Mocky: whoever wants can write their own. why start with idiocy in mind
Mocky: im going for real now
OriansJ: Mocky: Don't get stuck on the idea of Floating point, it is just an example of classes of instructions that are complex to implement in hardware that a proper illegal instruction trap will allow us to move between hardware and software with no one else having to care what we are doing. As we want people programming to standards not to systems.
BingoBoingo: diana_coman: WU is not. Normal bank wires work. WU is offered as an option because it works for people inside the wire sending to LATAM. Unsure how smooth WU UK would be.
BingoBoingo: *not the only option
diana_coman: tbf unsure how smooth either wire or wu would be from UK given additional currency headache; hence my hesitation to add this one to the to do list but by the looks of it, if this continues with no real bids even on quite competitive prices, I guess I'll have to.
diana_coman: last time I used WU was ~10 years ago and it was from EU to USA so not much help for current use case
BingoBoingo: hanbot's Costa Rica to Uruguay via WU experiment ended up going through a channel other than WU, so the suspicion is Intra-LATAM WU is fucked
auctionbot: Buy order # 1046: 500 WFF, WU esta bien Heard: 140mn from jurov outbidding PeterL. Ending: 2019-04-07 12:12:39.925433 UTC (26 hours 26 mins)
asciilifeform: http://btcbase.org/log/2019-04-05#1907008 << asciilifeform is quite curious re what 'ideas in posix worth preserving', i can't think of even one
a111: Logged on 2019-04-05 22:53 OriansJ: BingoBoingo: I agree POSIX has a great many flaws but there are some ideas inside of it worth preserving; especially in regards to bootstrapping.
asciilifeform: ( mandatory reading re thread : 'unix hater's handbook' )
asciilifeform: http://btcbase.org/log/2019-04-05#1907021 << 'dos' as typically discussed here is simply shorthand for 'os that fits in coupla kB and gets the fuck out of the way and speaks only when spoken to' , roughly
a111: Logged on 2019-04-05 23:02 OriansJ: bvt: Actually DOS wouldn't be the correct direction as it is actually more complex to implement portably and it's abstraction layer isn't right for a good general bootstrap.
asciilifeform: http://btcbase.org/log/2019-04-05#1907023 << whytheFUCK wouldja want the nullterm-string warcrime to exist on a brand-new arch ?
a111: Logged on 2019-04-05 23:03 OriansJ: well the only extremely useful feature for bootstrapping hardware architectures have is clean encoding and a sane subset of operations that make working with strings and structs easy to do in assembly.
asciilifeform: burn it with fire.
asciilifeform: http://btcbase.org/log/2019-04-05#1907027 << why would 'compat with x86' be ANY kind of consideration ?
a111: Logged on 2019-04-05 23:06 OriansJ: although if one wanted good backwards compatability with x86 and the rest; simply add load/store instructions that work on little endian data
asciilifeform: http://btcbase.org/log/2019-04-05#1907037 << i recommend to read the logs re 'specificity' ( picture yourself baking a sabotaged fpga , for victim whose gate net you do not know in advance. what would you put in it ? )
a111: Logged on 2019-04-05 23:25 OriansJ: well, I guess a really important question to ask is at what level of lithography people here actually have trust? (1 transistor, AND Gate in TTL, 100 Gate ALU, 1000 Gate ULA, 10000 Gate Asic, .... FPGA, 1B+ gate CPU, etc)
a111: Logged on 2019-04-05 23:38 OriansJ: As for the operating system floor; there is a micro-posix subset that might be of interest as it would be enough for bootstrapping full operating systems but not complex enough to have anything non-deterministic.
a111: Logged on 2019-03-26 20:05 asciilifeform: bvt: the other thing, is the 3-ring circus aspect of elaborately dethompsonizing a box in order to... bring up 1M+line of linusolade
asciilifeform: i.e. whole problem of 'bootstrap', imho, is misformulated . why to fixate on thompsonism and then bring up multi-decamegabyte kernel fulla liquishit, on which to run overflowandcrashlang (aka 'c') compiler with which to then build moar of same, etc
asciilifeform: http://btcbase.org/log/2019-04-06#1907042 << all of these archs were missing essential piece for sanity -- type tagging and bounds checking. ( i.e. if running ada or lisp 'costs extra' on your iron vs. c , your arch is broken ! )
a111: Logged on 2019-04-06 00:52 OriansJ: The Branch Delay slot should never been allowed and it just adds complexity to any bootstrap. The Multiply and Divide instructions of MIPS were just a bad idea and the DEC Alpha solution was a much better combination to go. The Exception style overflow pattern in MIPS is pure complexity and waste; the 68K series was so much closer to the optimal (The split Integer register and BCD support was a bad mistake that I am glad Cold Fire
asciilifeform: and yes, 'branch delay slot' is retarded. as is the whole pipeline concept. ( why ? cuz http://www.loper-os.org/?p=300 . sane iron FIRST, and ~then~ can ~maybe~ think about speed. )
asciilifeform: http://btcbase.org/log/2019-04-06#1907058 << this is where i say 'wtf' . what am i missing here ? where and for what do you need the ieee erroneous-arithmetics liquishit ?!
a111: Logged on 2019-04-06 12:41 OriansJ: Mocky: floating point support is part of being turing complete. We can either bitch about how bad it is (Like the old MIPS engineers) or accept the reality and figure out a why that costs us the least.
asciilifeform: http://btcbase.org/log/2019-04-06#1907066 << people who demand oddball instructions, can simply write own fpga payload and go happily on own path -- what am i missing ?
a111: Logged on 2019-04-06 12:52 OriansJ: and let us be honest here; making it easy to trap on undefined instructions, jumping to a software routine that performs the functional definition of that instruction and returning to right after the trapped instruction. Will allow us to ditch instructions in hardware without fear of breaking our bootstrap.
asciilifeform ate frustrating log, goes to again lie down
feedbot: http://pizarroisp.net/2019/04/06/pizarro-march-2019-report/ << PizarroISP -- Pizarro March 2019 Report
OriansJ: asciilifeform: no where did I say null terminated strings; it could be length prefixed strings but support for strings needs to exist in a human readable bootstrap.
asciilifeform: OriansJ: imho the place for it ( just as for e.g. bignums, arrays, other basics ) is in the iron
OriansJ: asciilifeform: I disagree. String support should be in software not hardware
asciilifeform: OriansJ: why exactly should overrunning string, or array, etc bounds be electrically possible ?
asciilifeform: it aint even as if no one ever built sane iron, and it is being proposed for 1st time
OriansJ: asciilifeform: just use a generic block type for range checking
asciilifeform: why ? so idjits can typecase string into bignum and back ?
asciilifeform: *typecast
asciilifeform: and liters into metres
OriansJ: asciilifeform: those conversions should be software NOT hardware
asciilifeform: OriansJ: plz make the case re why ?
OriansJ: bootstrap hardware should not have any features that are not absolutely required.
OriansJ: We can always add complexity and provide mechanisms for supporting additional complexity but but typed memory isn't exactly easy to bootstrap in hex
asciilifeform: it goes into the iron, you dun need to bootstrap it as such, beyond applying mains current
OriansJ: There are very good reasons why typed memory systems appeared after high level languages did.
asciilifeform: transistor poverty.
OriansJ: asciilifeform: Your level of bootstrap is considerably higher level than mine. I assume I have to hand toggle in the root binary and hand assemble everything.
asciilifeform: OriansJ: possibly we are speaking at cross purposes. having eaten the log, i formed impression that OriansJ is interested in hypothetical sane iron, and not merely dethompsonization of x86 pc.
OriansJ: asciilifeform: both actually
asciilifeform: i'm not currently sure that there is in fact any overlap between these two problems
OriansJ: Sane Iron is a great goal that I believe needs to be done but I also believe that a chain of trust needs to be built to allow Sane Iron to be safe from some classes of attacks.
asciilifeform: re 'classes of attack', i'm particularly curious re what is OriansJ answ to http://btcbase.org/log/2019-04-06#1907086 puzzler
a111: Logged on 2019-04-06 21:51 asciilifeform: http://btcbase.org/log/2019-04-05#1907037 << i recommend to read the logs re 'specificity' ( picture yourself baking a sabotaged fpga , for victim whose gate net you do not know in advance. what would you put in it ? )
asciilifeform: http://btcbase.org/log/2017-02-24#1617495 << see also historical parallel for subj.
a111: Logged on 2017-02-24 02:36 asciilifeform: veen: let's try a historical angle. according to legend, emperor qin shi huangdi (same d00d as known for taking the 'immortality pill' and promptly croaking) had a palace with 1,500 rooms. and would not tell anyone in advance which one he plans to sleep in on a given night. and which ones he would put cutthroats in, ready to kill anyone who opens door. think 'minesweeper.'
OriansJ: a hardware rom and a remote trigger
asciilifeform: OriansJ: let's posit. what does this give you, if you do not know what is connected to the i/o pins ? beyond ability to short +v to - and smoke
asciilifeform: ( if this counts as a useful attack, why not answer instead 'coupla gram of thermite' ? )
OriansJ: well lets see, we can add a short wave radio but that might be blocked with tempest hardware layers
OriansJ: we can include a hardware block for network and leverage it if it is connected; while letting our customers know about it speeding up network loads
asciilifeform: leverage how ? if you have literally 0 info re what netlist will be loaded and what cells it will make use of, and to what end
OriansJ: asciilifeform: all FPGAs have hardware blocks specific to certain function to speed up common functionality
asciilifeform: observe that it is entirely trivial to permute given netlist so that 9000 manufactured boards will each have unique one, with same function
BingoBoingo: OriansJ: On possibly missing prior is that should the work take us there, in this channel the question of fabbing our own hardware (Maybe on saphire wafers) is largely one of "when?"... provided we live to see it.
asciilifeform: OriansJ: not all. matter of fact, the 1 used in http://nosuchlabs.com/hardware.html has no dedicated cells, aside from i/o
OriansJ: BingoBoingo: I am thinking libresilicon which we could do today
asciilifeform: OriansJ: i specifically picked the part for this attribute. ( ice40 was not 'solved' yet at the time , but it has quite similar topology )
OriansJ: asciilifeform: so the Fab knows those cells will be for I/O and we know some common patterns of I/O that we can eletrically detect
OriansJ: Ethernet frames need to look like this and Serial buffers need to behave like this
asciilifeform: this goes back to 'knowing something about intended use' , neh
asciilifeform: the puzzler concerns 'general purpose' sabotaged fpga, rather than case where you know what the victim intends to connect and what protocols etc
OriansJ: asciilifeform: that is absolutely correct; an attacker in Silicon can only put in attack hooks for things that they know about not all possible inputs.
OriansJ: However we know common patterns for networked devices, Operating systems and external storage systems
asciilifeform: the irons that speak these 'common patterns' -- already sabotaged decade+ ago, no need even to concern with fpga..
OriansJ: asciilifeform: well some of these patterns are universally useful and will exist even in Sane Iron systems
asciilifeform: OriansJ: incidentally, a pattern matcher on i/o pin will affect propagation delay
OriansJ: asciilifeform: but can you really spot a 1ns delay?
asciilifeform: OriansJ: if i'm baking e.g. dram refresher -- then quite easily (and very frustratingly, in actual practice did, it is why it is ~impossible to bake a decent dram controller from scratch using fpga that hasn't been 'solved' ice40-style )
OriansJ: asciilifeform: DRAM initialization has a very unique pattern which can be detected very early (long before the DRAM itself is ready)
OriansJ: but let us save some time
OriansJ: Let us just assume the FPGA was not compromised and leverage it for the bootstrap work at this stage (I'll be going to pure LibreSilicon before I am finished but hey to each their own)
asciilifeform: correct. so, proposing to put 64-state statemachine on each pin and look for it? and what, slip the timings so dram loses bits ? this is in the 'smoke' category, logic analyzer will find the peculiar defect, and victim buys another fpga.
asciilifeform: OriansJ: i am not proposing it as 'boostrap for pc', but as ~replacement~ for pc.
asciilifeform: *bootstrap
OriansJ: asciilifeform: I am good with that as well; provided we actually bootstrap it properly
asciilifeform: and specifically as illustration of the physical limits of thompsonism, in the abstract
OriansJ: So, perhaps the most important question what has been actually decided about Sane Iron and what still needs definition?
asciilifeform: 1st , i cannot resist to ask, what is/was 'libresilicon' ?
OriansJ: asciilifeform: it is a project for open source lithography, it currently is at the 1 micrometer process node and limited to around 1 million transistors at this time
asciilifeform: 1um actually is entirely enough . what's it cost ?
OriansJ: asciilifeform: sadly they haven't given that yet but let us just assume Industry costs (say $10K) per wafer
asciilifeform: looking at the 'process steps' docs in the linked page, it seems to be a straight wikipedization of ordinary schoolbook description of ic fab process
asciilifeform: i.e. there is nothing there to suggest that the author has discovered a peculiarly cheap method of fabbing ic
OriansJ: asciilifeform: It isn't about cost because a Custom IC can be done for under $10K today in a 45nm process
asciilifeform: OriansJ: the french already offer 8k (iirc) for 400nm . this is not the problem.
asciilifeform: right, the problem is specifically that it's happening somewhere other than my kitchen.
OriansJ: That is what the RISC-V people did with their 45nm chips
asciilifeform: and i do not see anything in the linked recipe to suggest a kitchenable process.
asciilifeform: it still demands hf, for instance
OriansJ: asciilifeform: It is a guide for groups of people to pool together resources and setup a 1 micrometer fab to generate trusted chips. Yes it is far from optimal but it is a step in the right direction.
asciilifeform: what asciilifeform is looking for, re ic fab breakthrough, is specifically a process that would be to ic what the cd recorder was to cd
asciilifeform: i.e. turn '4000 square metres and 400 mil. $' process into tabletop.
asciilifeform: OriansJ: what if my definition of 'trusted chip' is specifically where i own the gear and no other people are involved at any stage ?
OriansJ: asciilifeform: something tells me you would be more excited about Xerox's plastic transistor technology
asciilifeform: y'mean the 1 that was 'any day nao!' 20y ago ?
asciilifeform: i'll happily buy it. along with the promised tabletop fusion plant...
asciilifeform: also from same 20y.o. magazine..
OriansJ: asciilifeform: honestly, the chemicals and the patents are still a mess in that field plus the never could produce a chip that could exceed 100khz
asciilifeform: the only semiconductor i've so far baked with own hands is cu oxide diode.
asciilifeform: beyond that, afaik state of the art is 'ha, very funny, you wanted what?!'
asciilifeform: OriansJ: re patents, there's plenty of folx living in free world, who will piss on whatever patent simply for the pleasure of the piss
asciilifeform: so patents in no case are the problem
OriansJ: asciilifeform: well we can either wait for others to perform miracles or we can get off our asses and make them for the world to see.
asciilifeform: OriansJ: 'open source' folx have a professional disease, where they succumb to temptation of redefining a difficult problem into a non-equivalent but easier one
OriansJ: asciilifeform: back to my previous question. What actual really useful thing has been created in regards to Sane Iron so far?
asciilifeform: !#s bolix ivory
asciilifeform: ^ best-known example.
asciilifeform: full type-tagged memory, ecc, iron gc, etc. in 370k transistor.
OriansJ: and programming information is where?
asciilifeform: vendor supplied lisp, ada, fortran, even c, compilers , which interoperated to the point of safely calling proggy written in 1, from another
OriansJ: No results on DDG
asciilifeform: i have the orig. paper docs, they fill a bookcase, but they're actually all mirrored there.
asciilifeform: this was an actual commercial item, not laboratory prototype.
asciilifeform: vendor killed itself via 'enron'-level mismanagement, imploded , so not much known about today outside of specific circles of sane-iron enthusiasts.
OriansJ: ok; do we have software simulators such that people can start developing software for it while we solve the hardware side of the question?
asciilifeform: OriansJ: there's an emulator , though not a cycle-accurate one . asciilifeform is (slowly) gathering the seekrits needed for cycle-accurate reproduction of the orig.
OriansJ: asciilifeform: we don't need cycle-accurate; we just need good enough to be able to write the pieces that will run on it directly
asciilifeform: largely to experiment with the orig. os , it was an item quite far ahead of what today is taught as 'state of art'. but the iron also imho is good starting point for hypothetical sane iron.
OriansJ: Ok, so asciilifeform, you wish to improve upon it rather than use it?
asciilifeform: OriansJ: you wouldn't want to build a new comp that replicates it entirely. for one thing, iirc could only address 256M , with no possib of expansion
asciilifeform: OriansJ: correct.
asciilifeform: from pov of this thread, it is a practical example that sane (i.e. typechecking & boundschecking of ALL memory accesses) iron in fact existed, and even fit in 1980s vlsi (2um)
OriansJ: and have you put all the possible enhancements into a common place for reference?
asciilifeform: OriansJ: in fact did. this common place , is http://btcbase.org/log/
OriansJ: asciilifeform: that is not an effective mechanism of documentation reference
asciilifeform: i find it quite effective.
OriansJ: asciilifeform: which is fine if you expect to only work alone and have the work lost in the sands of time.
asciilifeform: OriansJ is under the impression that asciilifeform works alone ?
asciilifeform: i recommend to read the log. you will find that asciilifeform is not the only 1 who finds it effective reference.
OriansJ: asciilifeform: Having spent time reading the log; I am less than impressed
BingoBoingo: Some futher organization of the literature would probably help with initiations, but first asciilifeform needs to catch a transcription slave
asciilifeform: i cannot resist to ask OriansJ , what exactly then is he doing here ?
asciilifeform: there's, y'know, a whole net of elsewhere to be
OriansJ: asciilifeform: I seek out potential; and I heard there was potential here.
asciilifeform: potential of what , concretely ?
OriansJ: Creating anything I find interesting or useful. Be it through mutual cooperation or single sided self-interest.
asciilifeform: OriansJ: if you're interested in concrete approach of asciilifeform to design of iron, i invite to study http://nosuchlabs.com/hardware.html , item asciilifeform designed & sold ( two runs sold out 100% , possibly in near future we bake a 3rd, on ice40 and photoscintillator , as discussed in logs )
asciilifeform: the engine http://btcbase.org/patches/fg-genesis/tree/fg.v incidentally is 100% siliconizable as it stands.
asciilifeform: ( and deterministically testable for 'doing what's printed on the box' . you pump a coupla TB of known bits through it, and observe that the expected outs in fact came out )
asciilifeform: ( bits known -- that is -- to you only )
a111: Logged on 2018-10-24 16:55 asciilifeform: http://nosuchlabs.com/fg/photo/yoke.jpg << actual photo of procedure.
asciilifeform: ^ i.e. a unit suspected of containing hidden functionality vis-a-vis any other existing unit, can be 'slaved' to the latter , and the outputs compared.
asciilifeform: imho this is an absolute ~minimal~ requirement for hypothetical sane irons of any other type.
OriansJ: So classic multiprocessor lock-step computing common in space craft
asciilifeform: exactly these
asciilifeform: i do not claim to have invented the method.
asciilifeform: cribbed directly from classical sov-engineering, like just about all other asciilifeform methods.
OriansJ: asciilifeform: BESM-6 style engineering?
OriansJ: interesting
OriansJ: I would have expected more code-morph style engineering given that hardware style.
asciilifeform: 'мажоритарная логика' (majority-logic) in the general case, i do not recall what the english folx call it ( afaik they gave up on it errywhere other than orbit in recent yrs )
asciilifeform: OriansJ: what's 'code-morph' ?
asciilifeform: how would this apply in re the linked device ?
BingoBoingo: !!unrate OriansJ
asciilifeform: fg doesn't even contain a vonneumann cpu
asciilifeform: it's a straight single-purpose logic circuit, would fit in a hundred or so 74xxx discretes if you felt like it
BingoBoingo: !!v F06E043C1BCB91FB56B0AEA3D7A02B8F6074B5AB6455CFCC3D70684B0CF80687
deedbot: BingoBoingo unrated OriansJ.
asciilifeform: BingoBoingo: quick on the trigger finger today aintcha
asciilifeform: !!rate OriansJ 1 neophyte / temp. voice
asciilifeform: !!v 1905A8CAFC52E459F6524DA32B2709CD0894C1D627DD24BD83CA93FDFD3718A3
deedbot: asciilifeform rated OriansJ 1 << neophyte / temp. voice
BingoBoingo: asciilifeform: With the conversation going on I figured it's time to let someone else carry the voicing.
asciilifeform: BingoBoingo: aite. i'ma lie down again soon tho
BingoBoingo: Recover well
asciilifeform: ty BingoBoingo
asciilifeform: OriansJ: lotsa folx over the years landed in the logs, and thought 'these people sit and philosophize and what'. but plenty of examples of working mechanism , if yer interested to study. http://www.loper-os.org/?cat=49 for instance is a just-short-of-done constant-time 0-dependency cryptoarithmetizer.
asciilifeform: i.e. performs, e.g. rsa, with zero conditional-on-inputs branch instructions, anywhere.
asciilifeform: ( and likewise zero input-variant memory addressing )
BingoBoingo: Then there's the V
asciilifeform: BingoBoingo: let the fella eat at own pace, or will choke
asciilifeform: for all i know already choked
OriansJ: asciilifeform: not choked, looking for more
asciilifeform: ^ is what we use for a versionatron. exclusively.
asciilifeform: ( observe, earlier linked fg, ffa , distributed strictly as vpatches )
asciilifeform: other people have other projects, i was speaking strictly of own thus far.
BingoBoingo: Also http://btcbase.org/patches with projects living in the dropdown menu
asciilifeform: mircea_popescu & diana_coman for instance have a multiplayer game. lobbes has various useful automata (e.g. auction bot) . http://therealbitcoin.org exists. and plenty else.
asciilifeform: ave1 has a bare-iron gnat port.
asciilifeform: there's in fact moar than i can list from memory in coupla min.'s time and coupla log ln. of space.
OriansJ: the javascript requirement is a bit odd though for the patches page
asciilifeform: OriansJ: it displays sans js, you simply gotta manually throw in param after the '?' mark
asciilifeform: ( phf's www engine, btw. all q's to him. )
asciilifeform: 100% commonlisp.
asciilifeform: re older asciilifeform items , there is e.g. http://phuctor.nosuchlabs.com/stats .
OriansJ: asciilifeform: I've hit http://btcbase.org/patches?patchset=v and no it doesn't display without javascript enabled
asciilifeform: ^ bug report to phf ^
BingoBoingo: It uses SVG
asciilifeform: OriansJ: i gotta take off shortly. you will definitely want to speak to mp, whose chan this is. ( he is travelling but i expect will stop by some time in next coupla d )
BingoBoingo: Anytime from minutes to weeks is possible.
OriansJ: well; I guess we will have to see. Until then
asciilifeform will bbl
auctionbot: Buy order # 1046: 500 WFF, WU esta bien Heard: 130mn from lobbes outbidding jurov. Ending: 2019-04-07 12:12:39.925433 UTC (22 hours 12 mins)
PeterL: !Xbid 1046 125mn
auctionbot: Buy order # 1046: 500 WFF, WU esta bien Heard: 125mn from PeterL outbidding lobbes. Ending: 2019-04-07 12:12:39.925433 UTC (20 hours 46 mins)
← 2019-04-05 | 2019-04-07 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code