593 entries in 0.133s
bvt: asciilifeform: i think closing would necessary (not done right now, as i can see); re proggy - nothing complicated
http://paste.deedbot.org/?id=4XUj (merged two for convenience, so fd num will be different)
bvt: asciilifeform: re SO_REUSEADDR - i don't see how it is applicable: as i understand errno 106=EISCONN the kernel believes that the socket is still connected (perhaps socket.timeout case in send()?); so if you proceed to connect without closing it, you'd get double connect on the same socket; and SO_REUSEADDR does not protect against this:
http://paste.deedbot.org/?id=Zd3l bvt: ty; i wanted to download them via wget on remote machine, discovered bunch of .sig.1 files
bvt: i did not switch to the newer keccak code, as this would not solve underlying issue: vdiff would still crash with large files, just the limit would be 8x larger
bvt: asciilifeform's searcher matches 'many' when looking for 'man', produces too many results to filter through all of them (thought the line was there too)
bvt: i kind of remembered that it had something with to do with percentages, this surfaced out mod6's message; when you mentioned that the result is still ~wrong, remembered that it had something to do with "man who invests X% of time into empire...", used phf's log for a keyword search.
bvt: mircea_popescu: i don't think it will lead to any vulnerability or something of this sort, no; but still there is a question of what the early users are (i.e. something in net stack, that will stick for a long time?)
bvt: asciilifeform: actually it may be easy to find early users with ftrace=function ftrace_filter=*random* at kernel command line, and then get the users out of tracefs
bvt: the O ring needs to be initialized somehow, zero-filling it may be bad, and keeping the existing infrastructure for just boot-time entropy collection is not an option; should i look for something simple that would work for initialization?
bvt: one q though, per my reading of the formalization, stretching happens only on I overflow? i.e. if there is a consumer reading from I, preventing it from overfilling, bytes would never fall into O, and stretching is not triggered?
bvt: 2. by tty model of linux, you don't pull data using tty driver, the driver pushes the data though several abstraction layers. i would have grok this stuff as well. there is at least one other driver that needs this functionality (for connecting a screenreader to a tty), so i can figure out stuff by looking at what it does.
bvt:
http://btcbase.org/log/2019-08-22#1930162 << the plan makes sense, i will implement it. though i intend to start from the 'read data from fg' position, because 1. opening tty devices from kernel without very dirty tricks became possible only in 4.13;
☝︎ bvt: hi, sorry for delay on the linux rng post, it is in fact ~ready, but i need one more day for proofreading
bvt: asciilifeform: can you try curl -s logs.nosuchlabs.com/log | grep --perl-regexp '\x01'
bvt: so far i've been doing everything manually. for 10 vpatches, i would start automating the process. typicall i'd run full test set for each vpatch
bvt: the two things for comparison -- less total number of vpatches at cost of vpatch size, or more vpatches, but smaller ones?
bvt: but again, i think the first to points are more important; the third one has less priority (at least for me).
bvt: in my workflow, each vpatch individually receives full press-build-test cycle; more smaller vpatches can make this process a bit longer and tedious.
bvt: maybe that's too much testing for re-signing, i dunno.
bvt: and i know that when re-signing multiple vpatches, i would have done the same thing individually for each vpatch.
bvt: well when i was re-signing another vtools vpatch at phf's request (for keccak regrind), i did the full re-testing as when releasing it the first time, to make sure that everything is ok.
bvt: there is also an aspect of potential future re-signing work on regrinds, which forces bigger vpatches, but imo the first two are more important
bvt: mp_en_viaje: i think there are two aspects: 1. readability (whether readers would be able to understand what is going on; in that vpatch the changes are local enough); 2. atomicity (whether someone would ever want to have one fix without the other; here my position is much weaker -- perhaps someone would want to have a crash on empty vpatches?)
bvt: asciilifeform: there is another thing that i just noticed that different between phf's logger and yours: single quote (') is encoded as ' in phf's logger, and as &apos in yours -- and &apos happens to be totally broken in links graphical mode (links -g). i can fix this on the links side, but i wonder if this is intended/acceptable behavior
bvt: iirc it is buildable without xmlada and all the crazy deps with some tweaks; at least i did build it once and run one of the examples
bvt: lol vintage, from 2019?
bvt:
http://logs.nosuchlabs.com/log/trilema/2019-08-08#1926500 << i think get your point; though tbh, from my reading of linux it's not clear that urandom uses separate entropy pool, as i understood so far urandom uses the same pool as random, just ignores all 'entropy' measures (i still did not quite load that part in head, so this is not final info).
bvt: asciilifeform: until the day for tcp to die arrives, you'd still have to interact with tcp warts in that or other form
bvt: on posix, don't think there is way out of exposing fds and syscalls
bvt: re pg - yes, you'd have to implement the protocol; and serialization/deserialization is error prone and typically takes lots of code (i.e. too much), agreed
bvt: true, but i don't find '80% of cl argument' too convincing; if want comfort, sure, use cl/python; want hard memory limits and gcc performance, can use ada, it won't be fundamentally dirtier (due to tcp and db stuff), just more boilerplate code
bvt: i would actually expect that pg protocol does not use 0terminated strings. re 80% of CL -- inside of it's implementation you'd find same shit. dunno how it would be different from using heathen libs
bvt: i don't think there is a way out of treating utf8ism as raw bytes, other than finding a heathen library
bvt: i did some minor nginx plugin development -- the linked list approach was not bad, the only op i had to do with actual buffer was splitting it across chains links to insert data between.
bvt: re logotron with arbitrary number of messages - can't you send data in a loop? otherwise the problem touches all levels of net stack -- can't have arbitrary sized packets either
bvt: well, for most of format strings you know the number of formatted elements, right. re memory allocator -- an arena allocator is typically used, and file data can be mmaped
bvt: you still need to format the numbers, etc, but for this can always know upper bound
bvt: asciilifeform: you make a chain (linked list of buffers with content), pass it's head to kernel
bvt: tbh i would not mind attempting an irc bot in ada, but it seems more like leasure activity so far.
bvt: asciilifeform: did not try myself
bvt: hello. asciilifeform: i like the new logger, esp the multi-chan support
bvt: hi. i'm back from my travel (incidentally, also from ukraine, though not kyiv)
bvt: hello. i'll be traveling this week, the end result is supposed to be a working trb node; i don't expect that any other productive work will be done otherwise. bvt_away is the account that i may switch to during this time.
bvt: hello. I will try to finish the ffa work from the workplan over next two days. i had some meatspace interference that stole a few work hours.
bvt: mp_en_viaje: i will have a look if i can arrange it -- right now i have another travel scheduled around that time.
bvt: i see, when the last person who was there when the isp was set up retires... ; the internet situation in germany is outrageous -- dsl everywhere, highest prices for shittiest quality, providers (2 or 3 that are still there) making sure that no fiber gets to the customers, etc (iirc they invested heavily in copper 'cause "isdn is the future!" in 90ties).
bvt: well, i still have access to irc/inet at saltmine; and working offline is also possible, so i don't waste time in meantime.
bvt: hello. i have also prepared a work schedule document; however internet at my workplace died this week, will post the plan as soon as the internet goes back up; the plan for next two weeks is to get to ffa14b, update asm code to it; after that, i will have a look at some other work.
bvt: i have never worked with slip, so can't tell right now
☟︎ bvt: re rtc -- i can see that. re network - i guess at some point it may be easier to provide a (first, emulated, later hardwarized) pipe device and write a custom driver to it; basically a high-speed tty that also transfers information about message boundaries
bvt: well, building is actually trivial -- sed 's/aarch64 x86_64/x86_64 mipsel-sf/' build-ada-arm64.sh > build-ada-mipsel.sh ; i'll do a post about this, but this'd be all the technical meat in it
bvt: if you want, can share the tarballs as well. afaik mips also uses zcx by default -- i did not change anything there
bvt: in case only asm is used, plain comba may be fast enough as well
bvt: you mean, can use just karatsuba?
bvt: re ~2.5x speedup: for 8-indeces-threshold asm comba makes up only ~25% of runtime, rest is spent in karatsuba squaring
bvt: i agree. i played a bit with the code, arrived at slightly cleaner (and sub-1% faster) code for multiplication, seems that the performance is close to the hw limit (at least at 32 Indices Comba-Karatsuba threshold)
bvt: asciilifeform: myeah, i was too fast with sse -- simdifying such loops would be ~impossible.
bvt: now, sse could theoretically help, but there is a question of whether sse operations are constant time (in each generation of intel cpus)
bvt: asciilifeform: perhaps i could get a bit better performance after scrutinizing multiplication code a bit; however i don't think it'll get much faster with current code structure
bvt: the hard part is 'fiat overlord' and being able to dedicate stable amounts of time to republican work, for this i don't have an acceptable answer.
bvt: after ffa I will have a look at other things (like ripping out kernel rng, having another look at gnat-arm64 internals, as it seems there is no ongoing work on this front atm). i expect to get something useful as a result, and maintain it in long term.
bvt: mircea_popescu: i guess that there two components in your question. the easy is ffa: is agree that my ffa-related output is underwhelming for a lord, however 1) i don't expect that it will eat much more time (at ch.14 i'll see if there is really need for further asming, the anticipated answer is "not really") 2) i find speedup from asming generally useful, so i don't think the time i spent on it is wasted.
☟︎ bvt: i do expect that 'saltmine season' is over now -- i've been working on asming karatsuba squaring (ffa ch.12b) over this week, post expected tomorrow.
☟︎ bvt: hello. i am also sorry for my unacceptably low output over past ~2 months; and particularly sorry of not doing the right thing of notifying the forum (which i did before)
bvt: (talking about rk3399 here)
bvt: yes, but nevertheless the boards with these chips appear every day. perhaps need to show inca earplugs of some minimum size to get them?
bvt: to my understanding you design them yourself; devboards are just for testing the cpu/chipset
bvt: well, those are devboards, i don't think anyone sells them as a serious item. but amateurs - buy
bvt: (chinese messed with m.2 port wiring, need to buy strange adapter board to bring it to sanity)
bvt: i have an m.2 nvme ssd there, but the hw setup is convoluted enough to recommend bying *some other* board for these purposes