log☇︎
23600+ entries in 0.135s
mircea_popescu: the one thing i really don't like is that wtf block devices of two block sizes.
asciilifeform: and the q of 'would serpent fit in ice40' is imho also worth answering. i'ma put it in the pipe.
asciilifeform: vhdl is prolly worth a 2nd look, tho i currently suspect that it vs verilog aint a 'ada vs c' win, simply longer text that does same thing ( the only unit of data in fpgaism is really the bit, so 'types' dun exist )
asciilifeform: ( i was initially testing rk pilot plant to run off sd, discarded on acct of meh speed vs usb3 )
asciilifeform: i even have some here.
asciilifeform: there actually exists an ada-flavoured variant, 'vdhl', but i never saw any win from it, loox rather like simply a moar verbose verilog. but! to be fair, that was 10y ago when i last dug, it was prior to asciilifeform's getting into adaism.
mircea_popescu: no dood i understand the differences.
asciilifeform: and yes i am moar willing to bet on rsa.
mircea_popescu: asciilifeform i looked at the both of them things, what can i tell you.
mircea_popescu: nobody's walking anywhere with any rsa pills. now that i'm willing to die with.
mircea_popescu: "hey guise ? i have a mathematical definition of blockchipher, and guess what comes for free with it."
mircea_popescu: in short, because this winding discussion risks overwhelming buffers, the salient points are a) that i'm not ready to go to war over serpent, it's a meh-maybe item ; b) that building our spearheads around items we're not willing to die for may be how the converse of http://btcbase.org/log-search?q=bitcoin+corrupts altogether. ☟︎
asciilifeform: dunno, i threw out my serial mouse, and didn't have to rewire entire house on acct of having discarded it
mircea_popescu: it seriously never fucking was meant to be gone over with a microscope, "oh satoshi how could you". fuck you i should wear a caliper attached to my pants in case i doodle in the restaurant also ?
mircea_popescu: so yes, i fully expect they'll buy, and then admire the hole we've dug ourselves in : five years down the road, say, as a mental experiment, we've sold 100k of these units, they're 90% of all we've sold, and well... they're still blockshiters. and what's next ? say i utter a fatah against block "ciphering", for good technical reasons or just because i'm insane -- IT DOESNT MATTER, and lo there'll be a lordship schism because
asciilifeform: they didn't line up to buy FG.. ( it dun scratch any heathen itches ) whereas this item potentially does scratch, as i understand
mircea_popescu: i don't expect it'd be a bad thing to have. it's certainly way the fuck more than the whole "market" of the whole "security industry" slash barn.
asciilifeform: i was thinking moar along the lines of 'pistol that fires erry other round backwards is worse than a good knife'
asciilifeform: if mircea_popescu's pov was 'symmetric iron disk is worse than nuffin cuz symmetric ciphers are hokum' -- i'll buy
mircea_popescu: i want serpent to take me out to dinner first! what!
mircea_popescu: that's what i mean, "a picture of its possible strength emerges from ample discussion of its possible weaknesses"
asciilifeform: (and i strongly suspect that nobody will)
mircea_popescu: now, maybe after eulora's run for a half decade, and there's ACTUAL ~publshed~ research by ACTUAL humans re its strength, THEN i can revisit this discussion from a different hand
mircea_popescu: i mean, sure, it's something.
mircea_popescu: i agree with that, but im not sure symmetric cipher hdd wins that much.
asciilifeform: mircea_popescu: i suspect that there will not be a 'civilized' symmetric cipher, i.e. item with less voodoo flavour to it than 'serpent'
mircea_popescu: i am experimenting with serpent, and yes it's borne of that ancient discussion of ours, but i'm nowhere near-ready to bake it into "this is tmsr secure disk" ☟︎
mircea_popescu: so you don't see my point when i say "well... disk and everytihng else line-crypto really needs tmsr-cryptochip first" ?
asciilifeform: funnily enuff i dun know of a single commercial/heathendom fpga that could house something of this size.
asciilifeform: mircea_popescu: i see plenty of merit in iron bignumtron, sure
asciilifeform: in this case it's simple madoff fraud, imho, rather than any sort of peculiar freudism. i.e. simple 'we lied for moneys and dun wanna to jail'
asciilifeform: i expect academitards-with-seekric-sauce are 98% 'if i published, errybody will know that it never worked', 1% 'if i published, errybody will know that it consists of ripped off old open sores' ( personally met one of these ! ) , and 1% 'it worx and we're gonna patent!111 and getrichquick' , bolix-whisperer style ( i have no direct evidence that these exist, but some indirect clues )
a111: Logged on 2018-10-04 00:14 asciilifeform: i.e. unreplicable crapola where one'd have to catch the authors and connect'em to 220v to get the orig data, supposing it existed
asciilifeform: ( trivial, but sadly needed. i have nfi why the standard one has the retarded block against pragma Pure )
asciilifeform: relatedly, i've written a working replacement for Bounded_String .
a111: Logged on 2018-01-05 01:03 asciilifeform: mircea_popescu: the secondary stack thing worx correctly in modern-day gnat. but i banned it. ( because it makes reading disasmed binariolade harder; reasoning about the semantics of the latter -- also harder; and consumes very scarce, on small embedded chips, memory , imho needlessly )
a111: Logged on 2018-07-18 14:13 asciilifeform: btw did i ever discuss why i forbid the secondary stack ?
asciilifeform: diana_coman: i happen to know that i'm not the only one who swore off secondarystack -- the 1990s space probes folx did also. but unsurprisingly they never published anyffing re how they filled the resulting cavity in functionality. ( at least they did not have to deal with linux kernel, afaik, ran on bare iron , so no To_C etc horrors )
a111: Logged on 2018-10-26 02:26 asciilifeform: i suspect that String Must-Die(tm)
diana_coman: http://btcbase.org/log/2018-10-26#1866278 -> ~every time I used String for anything more than constant value I regretted it somewhere down the line so I tend to converge on the same idea - it's just broken ☝︎
asciilifeform: so apparently i gotta reimplement bounded strings nao..
asciilifeform: to continue in these lulz : ada std has a 'bounded string' type, that superficially is defined as exactly how i wanted to do 'path' type earlier. but! but! if actually invoked, it -- for no logical reason afaik -- prevents the invoking package from being declared stateless ( i.e. pragma Pure ), and this propagates ad infinitum , to caller.
asciilifeform: ( bvt's point re inet_addr applies here -- the actual syscall in fact demands a tardstring, i.e. nulltermed )
asciilifeform: i'd almost go so far as to specifically disrecommend study of the stock standardlib, it is actively bad for health
asciilifeform: i actually started in '16 with attempt to terraform it; promptly barfed
asciilifeform: on top of this, i'm thinking all of this spackle, oughta be unified, the paths, open(), udpism, tempism, etc. and eventually rolled into tmsr.gnat .
a111: Logged on 2018-10-26 02:26 asciilifeform: my only remaining notion here is that possibly gotta implement a 'paths' lib ! i.e. would represent paths as arrays of permanently fixed length , 255 octets, iirc this is the max permitted on unixlikes.
mircea_popescu: http://btcbase.org/log/2018-10-26#1866276 << more like a wrapper on paths, i guess. though pretty sure you can have longer than 255 chars. ☝︎
a111: Logged on 2018-10-26 02:18 asciilifeform: my current hypothesis is that we're literally the only folx ever to bake static libs (i.e. in .gpr, for Library_Kind use "static"; ) .
asciilifeform: aanyway i'ma stop here for nao, lest head expload.
asciilifeform: and errything else i've written worked a++ as them.
asciilifeform: 1 obvious solution, that iirc diana_coman at one point resorted to somewhere, is to discard the 'librariness' and make the thing a 'put this in your src' type of lib, rather than linkable one. but i ~like~ linkable/separately-compilable static libs.
asciilifeform: (i.e. does not properly plug the abstraction leak of unix idjicy, which is the whole point of the proggy)
asciilifeform: tho even if it existed, and i had memmap package eat a FD that it shat out on instantiation, this would be stupefyingly ugly still, because then memmap cannot be a troo finalized type (i.e. one that cleans up entirely after itself on death, incl. closing its fd)
asciilifeform: the real enigma is, why the fuck gnat does not include an interface to ordinary unix open(), why is it that i gotta write it.
asciilifeform: i suspect that String Must-Die(tm) ☟︎
asciilifeform: my only remaining notion here is that possibly gotta implement a 'paths' lib ! i.e. would represent paths as arrays of permanently fixed length , 255 octets, iirc this is the max permitted on unixlikes. ☟︎
asciilifeform: currently i'm in a zugzwang in re the mmap lib : the http://p.bvulpes.com/pastes/extOl/?raw=true invocation form is The Right Thing, but it requires passing in a String for Path, which dun work without secondarystackism;
asciilifeform: my current hypothesis is that we're literally the only folx ever to bake static libs (i.e. in .gpr, for Library_Kind use "static"; ) . ☟︎
asciilifeform: meanwhile, in gnat bugs : apparently ( and this is documented or mentioned nowhere ) : it is impossible to have a Ada.Finalization.Limited_Controlled type ANYWHERE inside a static library, unless it is generic all the way down (i.e. if the lib package is generic, any sub-packages must also be instantiated as generics ) ☟︎☟︎☟︎☟︎☟︎☟︎☟︎
trinque: indeed, I have all the tars necessary to build, will provide 'em
asciilifeform: ( and at some point i'd like to set up a tarball mirror myself )
asciilifeform: i'd much prefer, yes, to have the proper cuntoo, with 0 heathen pulls
trinque: I could possibly have you a newer thing to try this weekend; that's the goal
asciilifeform: nao this, i do not know, i have since taken the thing apart again ( was plugged into lappy )
asciilifeform: disk, in so far as i can tell, is alive ( no eggogs in dmesg )
asciilifeform: trinque: the odd thing is that it's what i used to bake the s.mg cuntoo; worked, then
trinque: I'm going to need to get my teeth into cuntoo this weekend before I can help you with lappy. what was in that tarball is very out of date.
lobbesbot: trinque: Sent 3 days, 0 hours, and 36 minutes ago: <asciilifeform> http://p.bvulpes.com/pastes/dI29G/?raw=true << very peculiar barfology from existing ( same tarball i successfully used for s.mg box ) cuntoo. sat for 4 hrs, built both gcc's, etc., then ended with this.
lobbesbot: trinque: Sent 3 days, 9 hours, and 25 minutes ago: <asciilifeform> is http://trinque.org/2018/07/06/cuntoo-bootstrapper-preview/ still most recent cuntoo ? i got errything ready to bake cuntoo lappy ( the oddball lcd box; old ssd from zoolag ) ; should proceed or wait for update ? ty
asciilifeform: ( not much , i suspect, chance of this sort of pull-out, while it remains usg colony )
a111: Logged on 2018-10-25 20:45 Mocky: apparently kuwait computers are shit and one chick knows another chick who runs "cyber security" for a kuwaiti / iraqi company, has been in there for 30 years, knows everyone in the biz. promised me a kuwaiti business sponsor if I actually know anything about computer security, put her number in my phone for me, and texted her to expect contact from me
asciilifeform: http://btcbase.org/log/2018-10-25#1866203 << on a good day, i pump away moar than produce... ☝︎
Mocky: apparently kuwait computers are shit and one chick knows another chick who runs "cyber security" for a kuwaiti / iraqi company, has been in there for 30 years, knows everyone in the biz. promised me a kuwaiti business sponsor if I actually know anything about computer security, put her number in my phone for me, and texted her to expect contact from me ☟︎
Mocky: oh my god BingoBoingo I'm so fucking tired
a111: Logged on 2018-10-25 19:17 asciilifeform: anyway i'ma leave it at this, will bbl:meat.
a111: Logged on 2018-10-08 16:20 mircea_popescu: because no, the "i know ~exactly~ what the computer is doing" declaration is not optional. exactly like socrates' observation, "the man claiming no political system has political system", exactly so, whatever the claim, to run code on machine equals the declaration of having fully read and thoroughly understood. there's no wiggle room.
a111: Logged on 2018-10-25 18:59 bvt: well, i did not suggest learning/utilizing C api, on the contrary, a subset of kernel stuff in ada is the interesting thing. it just happens to be currently defined/documented as C code.
asciilifeform: anyway i'ma leave it at this, will bbl:meat. ☟︎
asciilifeform: but i aint particularly interested in 'improvement' that turns the 146 into 1460.
asciilifeform: if somebody can show how to do same in 100, or 10, i'ma read and sign the patch and take off my hat.
asciilifeform: for so long as we're stuck on a linux box, i'd rather spackle over the c-ism with 600 ln, than with 6000 .
bvt: well, i did not suggest learning/utilizing C api, on the contrary, a subset of kernel stuff in ada is the interesting thing. it just happens to be currently defined/documented as C code. ☟︎
a111: Logged on 2018-10-25 18:25 asciilifeform: my udp lib is ~600 line, and not 6000, because i went in this direction.
asciilifeform: bvt: i do not know for a fact whether it eats same struct as the userland call, or different
asciilifeform: i'd luvv to see a syscall-tronic version of the udp transceiver thing, for instance.
mircea_popescu: i suspect noboduy's getting out of cataloguing the shit that easily, but we see.
asciilifeform: i'ma genesisate it as soon as i figure out a workaround
asciilifeform: i do not see how it would be improved by being 6000, if i were to try to adaize erry possible idjit unix's struct sockaddr_in .
asciilifeform: my udp lib is ~600 line, and not 6000, because i went in this direction. ☟︎
asciilifeform: sorta why i went ahead and stuck ALL of the os-dependent crud in udp lib into 1 .c
bvt: everything system-dependent that i've seen in gnat runtime goes into C code.
bvt: re syscalls -- fair enough. but imo this shows extreme brokeness of linux portability -- i can't think about a sane reason for syscall numbers to differ across arches.
mircea_popescu: i dunno, but this is brewing into a kettle of fish.
bvt: asciilifeform: re exotic flags -- sure. but i don't expect different results with syscall numbers as well. some subset will match, later in the table -- complete mess
a111: Logged on 2018-10-24 15:25 asciilifeform: incidentally, https://www.adacore.com/gems/gem-59 apparently exists, tho i confess that i really dislike the idea of automatic converters for coad
asciilifeform: O_DIRECTORY might be a bitch in the fyootoor , i suppose
asciilifeform: ( i.e. none of these flags appear in my proggies, aside from the open() one )
asciilifeform: bvt: i'm not surprised; but these dun affect anyffing i considered to be essential posix knob
bvt: http://btcbase.org/log/2018-10-25#1866029 << asciilifeform, it seems that i accidentally made you believe that only mips is wrecked. Well, check this out http://p.bvulpes.com/pastes/sWrur/?raw=true ☝︎