log
487 entries in 0.685s
asciilifeform: mircea_popescu: i can think of a few riotously braindamaged proggies atm (e.g. 'sshd', where author somehow thought it acceptable to generate host key at boot ; and tcp stack, where seq #'s )
snsabot: Logged on 2019-08-22 21:48:34 trinque: the thing's literally built atop tcp which supposedly has "connections" and it wants this ping/pong mechanism atop. ask me how many more hours of my life I wish to dedicate to this duck cunt that just wants a bit more.
trinque: the thing's literally built atop tcp which supposedly has "connections" and it wants this ping/pong mechanism atop. ask me how many more hours of my life I wish to dedicate to this duck cunt that just wants a bit more.
asciilifeform: spyked: mine disconnects strictly when a send() or recv() actually return eggog (i.e. indicating dead tcp pipe)
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930066 << ftr i've yet to observe this 'silent wedge' effect in my bot (i.e. where the tcp pipe is 'alive' but not doing anyffin useful). tbf it is, what, only 3rd week of this bot.
snsabot: Logged on 2019-08-20 15:01:22 asciilifeform: atm i vaguely suspect that tcp on piz is slowed by an inept wiretap somewhere.
asciilifeform: ( and, interestingly, specifically fucked re tcp. )
snsabot: Logged on 2019-08-20 07:47:16 mp_en_viaje: would like to take the time to point this out re ye olde discussion of "is something to learn / is nothing to learn", coming up oft re gosspid but generally always there. "to learn" is insanely vague an operator. just because you don't learn anything useful [about programming] while doing, say, python, it still dun mean you don't learn anything useful about your girflriend, or the tcp infrastructure, or router har
mp_en_viaje would like to take the time to point this out re ye olde discussion of "is something to learn / is nothing to learn", coming up oft re gosspid but generally always there. "to learn" is insanely vague an operator. just because you don't learn anything useful [about programming] while doing, say, python, it still dun mean you don't learn anything useful about your girflriend, or the tcp infrastructure, or router hardware, or the difference be
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-19#1929694 << this is worth expanding on. asciilifeform also gets very fast pings ( never moar than 200msec, to date ) and fast udp. what i suspect is, usg's snoop gear that sits as parasitic toad on south amer's pipe, specifically slows down tcp.
asciilifeform: pipe delay ( piz <-> asciilifeform's chair , cannot be generalized to entire planet ) varies from 0.2-0.4s (for revvup of tcp pipe, that is)
asciilifeform: mp_en_viaje: thinking about it, it's outgrowth of tcp retardation, where having the client alive costs the server at all times
asciilifeform: in trad irc, server periodically asks 'PING blah' and client expected to 'PONG blah' back (why? if it's a tcp pipe? what's the whole point of tcp, orig, if not to avoid this? dun ask me)
bvt: asciilifeform: until the day for tcp to die arrives, you'd still have to interact with tcp warts in that or other form
asciilifeform: my 'udp' lib was orig. gonna be a 'udp and tcp' lib. but very quickly realized...
asciilifeform: could try to use ada's 'streams' model. but then must decide, how to represent ~all~ of the possible tcp hiccups.
asciilifeform: aand that's just pg. now consider how to deal with tcp.
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
asciilifeform: ( tcp?! )
asciilifeform: bvt: how do i throw into a tcp socket a formatted fetch of log, consisting of unknown length of "<a ... " + blah + "</a>" etc, w/out string munging ?
asciilifeform: currently there aint a 'tmsr lang' in which can readily write wwwisms. (i dun even have a tcp end for gnat atm)
asciilifeform: what does, is to prevent eternal hang on silent (ask the tcp committee why this is physically possible, not me) deaths
asciilifeform: reason why 3 decade of 'apache' is same as why erryone (incl. microshit) is using that SAME tcp stack from berkeley '80s. cuz protocol was deliberately made so braindamaged, with literally 10,000+ moving parts, that ~impossible to correctly reimplement if demanding compat with 'everyone'
asciilifeform: point is , tho, that it is barfalicious ~because tcp~, not because author as such was tard
asciilifeform: 'Now, as if this wasn't enough, TCP also has a (transport layer) segment size, which must fit into a so-called "Maximum Segment Size" (MSS), which must be smaller than the MTU, because we also need to fit lower-layer headers and all that. Otherwise TCP isn't concerned too much with this, but misconfiguration can cause problems with congestion windows and whatnot, and we sure as hell don't want this shit to blow up. Finally, as if the
asciilifeform: as if the ludicrous cpu & bw waste of tcp weren't enuff, it also conveniently groups (with said grouping being entirely plaintext) 'sessions' for hitler to moar conveniently store & read.
asciilifeform: tcp was a 'gift' of profound retardation that 'keeps on giving', even to moar obvious extent than e.g. unix. it is single-handedly responsible for ~100% of the backbreaking complexicrud of apache, ssh, ftp, etc
asciilifeform: not to mention, gotta establish process re tcp ddosen. tomorrow could be e.g. qntra instead.
asciilifeform: re upstack >> anyone using one of asciilifeform's kernels can use simple cure : echo 0 > /proc/sys/net/ipv4/tcp_sack ☝︎
a111: Logged on 2018-08-21 17:36 phf: http://btcbase.org/log/2018-08-20#1843300 << little known fact: slime's architecture was originally implemented in a similar project for erlang called distel, by the same author luke gorrie. lukego also wrote an emacs clone in erlang and tcp/ip stack in cmucl.
a111: Logged on 2019-05-29 08:51 spyked: http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at the tcp stack implementation in linus' kernel. it is truly a fungus, macguyvered with duct tape and rubber bands, such that changing one line almost anywhere breaks shit all over the place.
a111: Logged on 2019-05-29 15:27 asciilifeform: tcp shows erry possible sign of having been designed, from the start, to extend the ease of snoopage from traditional circuit-switched telco grid, to the packet world. consider e.g. the 'helpfully' plaintext sequence numbers.
a111: Logged on 2019-05-29 08:51 spyked: http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at the tcp stack implementation in linus' kernel. it is truly a fungus, macguyvered with duct tape and rubber bands, such that changing one line almost anywhere breaks shit all over the place.
asciilifeform: tcp shows erry possible sign of having been designed, from the start, to extend the ease of snoopage from traditional circuit-switched telco grid, to the packet world. consider e.g. the 'helpfully' plaintext sequence numbers. ☟︎
a111: Logged on 2017-03-14 14:31 asciilifeform: Framedragger: the problem with tcp isn't simply that enemy can insert an RST packet and make you blame your peer. (and whitelists do 0 against this.) but that it is very expensive , computationally, long before you have any idea who you're talking to.
a111: Logged on 2016-08-26 13:34 asciilifeform: tcp is evil, fundamentally because it violates the 'NEVER something-for-nothing-to-all-comers-FUCKOFFRANDOS' principle.
asciilifeform: spyked: not only is the implementation what it is, but tcp per se is massive pile o'shit, where it aint even possible to implement it w/out 9000 tonnes of state machine gnarl
a111: Logged on 2019-05-29 09:06 spyked: the weird part is that the linux tcp stack ~works~ for the most part. I imagine the maintainer of that particular subsystem must be a neckbeard with 20+y experience in tcp (because sure, it's not only the implementation, the protocol itself is a mountain of complexity)
spyked: and then looking at e.g. https://elixir.bootlin.com/linux/v3.10/source/Documentation/CodingStyle , one can readily notice that half or maybe more of the tcp code doesn't meet that minimum set of criteria. and yet... it's there. so, I guess re. http://btcbase.org/log/2019-03-15#1902966 he was prolly dumb from the very beginning ☝︎
spyked: the weird part is that the linux tcp stack ~works~ for the most part. I imagine the maintainer of that particular subsystem must be a neckbeard with 20+y experience in tcp (because sure, it's not only the implementation, the protocol itself is a mountain of complexity) ☟︎
spyked: http://btcbase.org/log/2019-05-22#1915245 <-- in other c coad, /me spent his last 2-3 weeks looking at the tcp stack implementation in linus' kernel. it is truly a fungus, macguyvered with duct tape and rubber bands, such that changing one line almost anywhere breaks shit all over the place. ☝︎☟︎☟︎
Mocky: and i can also expand later on what's with the 'connecting', tcp? and what's with the directories, protocol on top of tcp? I'm hoping that its figurative and you don't literally want to build gns on tcp and http
asciilifeform: tcp over slightly bent rudder.
mp_en_viaje: but the point here was, that as long as what you're implemeting is, say, tcp, or dram, what you will get is not in fact a safely auditable object.
mp_en_viaje: now imagine a fpga, surrounded by 725 islands, leveraging each one thing, this is net-a that is tcp-ip-b, that'
mp_en_viaje: so : suppose a) tcp/ip is intrinsically, by its very [deliberate, and previously uknown-ly so] design vulnerable to "blowhammer", which is a class of yet undescribed attacks ; suppose your fpga includes an electrically-isolated leverage for a.
mp_en_viaje: http://btcbase.org/log/2019-04-06#1907145 << this is a more doubtful claim. what patterns, tcp/ip ? ☝︎
a111: Logged on 2019-03-26 21:31 asciilifeform: i'll add that even a tcp skin wouldn't be entirely useless ( right nao the only way to write a wwwistic proggy in ada is to use adacorpse's 'gnatsockets' crock of shit )
asciilifeform: asciilifeform sees tcp as a legacy tech, really
mircea_popescu: might tbe a better route, esp if it delivers a cheap way to a tcp-based republican web, to replace the www.
asciilifeform: i'll add that even a tcp skin wouldn't be entirely useless ( right nao the only way to write a wwwistic proggy in ada is to use adacorpse's 'gnatsockets' crock of shit ) ☟︎
asciilifeform: or , say, take tcp. mircea_popescu aint even a programmer, and is just about as 'clean' as a fella can get in re programming radiation damage and still have worked with comp. but it took asciilifeform 3+yrs to get him to see that tcp is -- by design -- garbage
BingoBoingo: There's likely logistics lessons to be learned. Timings necessary to keep conenctions open and other tcp weird.
asciilifeform: ( e.g. the problems of mitigating tcp ddos are irrelevant to proper udpistic gossipd. and ditto authentication of handles. )
asciilifeform: diana_coman: i'll admit that it isn't clear to me how effort put into baking glue for oddball nonstandard ircisms helps in re gossipd . irc as i see it is an entirely dead-end tech ( rides on tcp, and 0 notion of crypto , and cannot be retrofitted really )
a111: Logged on 2018-08-04 22:05 asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1 tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd.
mircea_popescu: tcp, prospect of "wtf, mysql, postgres", prospect of wtf we do with xml, prospect of cl-php-replacement, prospects galore.
asciilifeform: defo premature, esp. in light of prospect of e.g. ditching tcp
a111: Logged on 2019-01-22 07:16 mircea_popescu: and yes, obviously, the problem is tcp connection is stateful, which means memory allocation, and SUCH THINGS (if not necessarily just that thing).
mircea_popescu: and yes, obviously, the problem is tcp connection is stateful, which means memory allocation, and SUCH THINGS (if not necessarily just that thing). ☟︎
asciilifeform: fwiw simply rejecting tcp won't do the trick, you also gotta not allocate state for udp ( all extant routers, afaik, do.. but e.g. s.mg protocol and similar, will operate entirely correctly without this, as i understand it )
asciilifeform: ( and also happen to know why : they 'give to allcomers' in the sense of allocating memory for state of tcp connection. therefore it stands to reason that if one built router that doesn't tcp at all -- it will not fall. )
asciilifeform: mircea_popescu: i have plain old tcp with 'pehbot' ( via trinque's cl proggy )
mircea_popescu: no, what i'm saying is that with udp it is ~never worth "Retrying" in the tcp sense.
asciilifeform: ( unlike e.g. tcp, where pipe can die )
asciilifeform: the mechanics of use is actually 'easy part' -- they take x11 pipe over tcp, and are pretty light on graphics (1bit raster)
asciilifeform: i for instance am sitting here and tryin', not always successfully, to cure folx of delusions that linux instilled in'em, e.g. 'tcp gives cheap an' reliable pipes' ( cured mircea_popescu after , what, 3y ) and nao 'udp packets can be anyffing, not merely 1472' (not cured yet..)
mircea_popescu: 6. if you pertmit this 16kb item be chunked, you basically rebuild the tcp ddos bs long discussed here. if it has to be in 1 piece, you can always use or discard on sight.
mircea_popescu: but, yes, alf has a point : meanwhile read up ~on tcp~. despaired.
BingoBoingo: End then we'd have to strip down tcp over carrier pigeon to get UDP over carrier pigeon
mircea_popescu: i'm currently connected through the internet through sheer force of will, and there's a tcp thing trying to rape this.
asciilifeform: wouldn't go this far; dunno about mircea_popescu , but i'm presently connected to fleanode, trb, etc via tcp
mircea_popescu: im not fucking writing that. i don't like tcp enough.
asciilifeform: mircea_popescu: 'catalogue of tcp braindamage' is prolly ripe for an article. ( sadly asciilifeform is mired in liquishit and prolly will not write it this wk )
a111: 158 results for "from:asciilifeform tcp", http://btcbase.org/log-search?q=from%3Aasciilifeform%20tcp
asciilifeform: !#s from:asciilifeform tcp
asciilifeform: mircea_popescu: the braindamage of tcp, iirc, is elaborated in buncha old threads
mircea_popescu: http://btcbase.org/log/2018-09-25#1854293 << tcp is truly a worthless piece of crap. the more one looks at it, the more one doesn't want anyone involved with it anywhere near his shit. ☝︎
asciilifeform: i picture the end product as something like tcp but without the retardations.
asciilifeform: ftr i never grasped why irc is a tcp item to begin with. it aint as if the messages outweigh the available bucket.
asciilifeform: imho tcp , if preserved anywhere, oughta live as a lowered-into-pederasty item-only-carried-over-better-protocols or strictly-on-lan, like telnet.
asciilifeform: tcp imho is fundamentally sad, not the least reason for which is that 'anybody' can break yer pipe
asciilifeform: 'g' , the tunnel-tcp-through-ciphered-udp thing
a111: Logged on 2018-09-18 18:03 ave1: I was working towards having different modules on top of a common base to support tcp / unix sockets etc. but I think your idea is way better, asciilifeform http://btcbase.org/log/2018-09-18#1851315
mircea_popescu: http://btcbase.org/log/2018-09-18#1851334 << i also can't think of a thing that would legitimately need/want to use both tcp and udp as a toplevel thing. ☝︎
a111: Logged on 2018-09-18 16:06 asciilifeform: as for tcp, unixsockets, etc. imho if we ever need these, they oughta live in own separate lib, given as they force somewhat different and gnarlier semantics, they do not belong in 1 gigantic 'kitchen sink' imho
ave1: I was working towards having different modules on top of a common base to support tcp / unix sockets etc. but I think your idea is way better, asciilifeform http://btcbase.org/log/2018-09-18#1851315 ☝︎☟︎
asciilifeform: as for tcp, unixsockets, etc. imho if we ever need these, they oughta live in own separate lib, given as they force somewhat different and gnarlier semantics, they do not belong in 1 gigantic 'kitchen sink' imho ☟︎
asciilifeform: incidentally, my lib can be asmed just as readily as ave1 asmed the classical 'all of tcp stack' glue. ( sadly i dun currently have the free hands to do this )
a111: Logged on 2018-09-17 08:00 ave1: I'm aiming at a small library with support for UDP, TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done.
diana_coman: ave1> I'm aiming at a small library with support for UDP, TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done. -> mind publishing somewhere this part then?
ave1: I'm aiming at a small library with support for UDP, TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done. ☟︎
asciilifeform: ( a reply here, in turn, is not the idjit tcp 'ack', but a packet containing hash(currentsecretsalt + prevpacket) + cipherola-to-current-key , i.e. can only have been generated by the box on the other end, and can only be authenticated by yours
diana_coman: hm, so basically there might be something to "only tcp on gnat.sockets" after all since they baked this assumption in the...implementation of gnat.sockets themselves??
asciilifeform: tcp is very difficult to sanely work with without a stream abstraction, but udp -- trivial.
diana_coman: tcp good, udp bad!!
asciilifeform: diana_coman: that's pretty odd, i could not get it to tcp on 22
a111: Logged on 2013-03-11 07:17 mircea_popescu: actually the plan was to have tcp/ip reimpremented over pigeons
mircea_popescu: you don't really gain so much by having your special packets encapsulated in tcp
asciilifeform: and moreover, they are a problem with the basic design of (for the most part) tcp.