3200+ entries in 0.025s
Framedragger: 1. mind PATH_MAX (4096 chars); 2. maximum number of symlinks in single path: 40 (hard limit).
Framedragger: trinque: the naked truth of it is, i have little experience with lisp, of which "shipped to production" amounts to zero. wanted a bot. wrote modules for sopelbot which turns out to be reliable enough. :)
Framedragger: i, too, get confused re. demarcation lines of the two: on the one hand it's supposed to be battlefield against hitler, but on the other hand folks agree that it's also a good place to employ experimental stuff one always wanted to try, for doing things. and i agree with the latter. but then when that stuff stumbles on an issue (because it's fucking experimental), people get outraged.
Framedragger intends to set his mind to some p2p/gossipd stuff come summer, if moon phase aligns with karma etc.
Framedragger: << maybe useful for noobs looking for stuff to help with, but evidently they're not.
Framedragger: re. priorities and (natural) lack of 'global amazing konsensus priority list of shit to do', in my humble and very noob mind they are something like; 'p'; gossipd or partial iteration towards it; invoicing system; << these three'd useful for outside-tmsr interests fo sho; and nfi re. trb, as on the one hand it's supposed to be super important,
Framedragger: but not all. however, this is a shitty position to argue for. :(
Framedragger: phf: i agree with the latter. if nothing else - why not; sure. and sure, a *lot* of busy activity reduces to netflix in one way or another.
Framedragger: this only works in aggregate form though, i guess - difficult to assess at individual level. (but maybe that's the point.)
Framedragger: heh, this is close to entropy (and inequality as 1/entropy)
Framedragger: yeah, i suppose so - it's not a small thing to ask for at any rate...
Framedragger: is there a definition of usefulness that you'd agree to? (note, if it refers to tmsr, it's circular, of course)
Framedragger: you're right, ultimately i'm challenged to answer "what is the middle, then", if i claim the falseness. and i (again) do not have much recourse here. i only have individual anecdata of "intelligent folks doing their own thing", completely disjoint from tmsr.
Framedragger: not to bait or anything - i mean this charitably and honestly. it's just not the most productive approach, imho.
Framedragger: this works to strengthen the notion that tmsr is apex of importance/awesomeness/etc.; as otherwise one would be exposed to the possibility that "maybe we're not so important here anyway." :)
Framedragger:
http://btcbase.org/log/2017-03-09#1623585 << i humbly think there is a bit of a false dichotomy happening here (first approximation of what "here" is could be, "mircea_popescu's head.") either X is doing useful work for tmsr, or X is necessarily wasting time doing whatever-X-but-not-tmsr'y things (including "having dayjob(s)", "large side-project", etc.)
☝︎ Framedragger: i see - i'm behind on the internet of shit it seems
Framedragger: i thought huawei only made consumer shit? (not that that's reassuring...)
Framedragger: isn't internet backbone basically juniper + cisco still? :(
Framedragger: some kind of boys club with too much time on their hands lol.
Framedragger commits to writing at least one article in june (or maybe even before) #preplanninglikeachump
Framedragger: (not implying that there's much worth for any noob to start running a tor node *now*.)
Framedragger: sure. well, tor had been rather useful to me before, i took from it more than it's taken from me, so at least there's that. :)
Framedragger: (small virtual machine so wouldn't be too useful for traffic analysis, not much traffic)
Framedragger: reminds me, i think i'm still running one tor exit lol. mebbe time to redirect resources
Framedragger: phuctor is streamlined computer optimisation service.
Framedragger: i wonder how well a typical hashtable with 2**64 elements work in practice, tho. where would store its elements?
Framedragger: (also re. g'morning, just had bacon for late brunch, such satiation, but also sleepiness. more coffee it is...)
Framedragger: well, at least your user input is segregated into two 'containers': 1. GET requests for static files; and 2. user comments - processed by some specific script, separate from the rest. but yeah, this isn't exactly amazing innovation, i agree.
Framedragger: i mean, i have in mind an 'actually properly configured static site'. maybe it's a nonexistent spherical cow in vacuum, sure.
Framedragger: trinque: point taken. :) (i'll only repeat one thing here: in a 'proper static site' setup, one is *not* exposing vulns of a scripting language to the web. only those of the webserver.)
Framedragger: (just for posterity, other metrics say that consumer ssds seek average may be ~3ms.)
☟︎ Framedragger: btw, if you store 2**64 nodes in a (balanced) binary tree, wouldn't the "number of seeks" be ~64? i suppose that doesn't look too pretty, but considering that an ssd's seek time is ~0.1ms... not that these numbers are rigorous or anything.
Framedragger: right, basically i'm putting a lot of trust into fs, fundamentally. hence disagreement - fair enough. (to summarise.)
Framedragger: well, you'd like that "compute faster" line to be true, but it ain't.
Framedragger: ...that's why it's great to host this on a disk with great random access times.
Framedragger: first off, the former has a less clear attack surface, may depend on script in question, etc. second off, may scale not as well (no this is not the same as kiddie complaining that an rdbms is "not web scale").
Framedragger: no need to compress, what i meant by compression is that an index is sorta-doing that. storing flat files on fs is basically 'flattening' the process over space and time.
Framedragger: that being said, my point would work better if trilema had been having performance issues... which it ain't.
Framedragger: well, the compression-decompression process is so to speak serialised / offloaded to an fs. not a bad thing!
Framedragger: i can't see how i can be convinced that launching script-specific php processes is ~same as a webserver allocating a standardised additional unit of its resources (memory / thread etc.)
Framedragger: right, well-managed permissions ensure that any 'break-in' would only result in one being able to *read* some files. but i think your abstraction breaks quickly: i'm sure your php user is able to write files (file upload), even if to a single dir, and to write to db. so it's still not the same.
Framedragger: (though i'm sure mp-wp is on the whole ~decent in terms of holes/security.)
Framedragger: as regards language choice, yeah, i see your point, "just use the right tool". thing is, with an *actual* static site, you would not expose the language to the web, at all. the only attack surface would be that of the webserver. cf. a wordpress site which as folks say is a "web shell with blog functionality on the side" :)
Framedragger: mircea_popescu: that's not the only difference. a 'php' site launches and runs additional process(es) to serve user requests. now i guess you could say that "it's just a detail", on the grand picture it's the same (nginx requires additional resources to serve static files), but that would be stretching it.
Framedragger: mircea_popescu: i see what you mean, but you can't really call it 'static' by any metric. in point of fact i'm surprised you're not grossed out over the fact that the whole thing is a large stinking pile of dynamic php. i guess the counterargument is that it *gets the job done*, very well, over many years. :) so there's that. but i'd like to ditch the 'wp' from 'mp-wp' one day. but maybe baby steps.
Framedragger: what i _would_ like is to be able to have these kinds of comments in an otherwise static site (the comment box would be the dynamic component, so to speak - an autonomous backend module/script/whatever). not a part of a large ugly php blob.
Framedragger: yes, that's what i (finally) understood - i had assumed wrongly before!
Framedragger: i should keep that in mind lest i become unnecessarily overexcited here.
Framedragger: it sure would be nice to just be able to post simple comments on a blogpage, tho.
Framedragger: sure, but in that case one may as well just implement a gpggram-to-blog-comments interface (not that it's a wholly bad idea or anything)
Framedragger: ben_vulpes: yes, but it requires a dynamic component on the backend, right?
Framedragger: (your sqlite could do, or something even simpler). when comment is approved, static site generator gets triggered to re-render necessary pages including 'newest comments' box (if present.) etc.
Framedragger: my maybe-convoluted personal plan was to have a static site generator but to have the comment box be rendered by a dynamic component (hence loaded separately upon user clicking to comment, or sth.) that component does the 'fraud prevention without JS' magic (like with trilema's comments - IP address is sent to html form to be returned as hidden value / whatnot). when comment is submitted, it gets added to some queue
Framedragger: i guess they could include blog post number at least, but then not full proper quotation as you say. arbitrary selection within a DOM element only possible with some JS (trilema and archive.is at least have that JS piece tucked nicely in one place, not a total horror)
Framedragger: (i'd like a static site + comments-without-captcha-or-JS setup, too, yeah)
Framedragger: lobbes: selection as in on the website, to provide unique href to selection?
Framedragger:
http://btcbase.org/log/2017-03-05#1622326 << just checked and realised that your trilema comments don't seem to have any JS, so it seems like i was wrong. (i now realise i had a (rather arbitrary) additional constraint with the original comment long ago, "make it work with a static site", but that's another matter/project altogether.)
☝︎ Framedragger: ah, that's one way to do it, via a saner interface with much less cruft...
Framedragger: aha, point taken - but reproducible documented methodology / code is still something.
Framedragger: Reuel: just fyi, and it's only my humble opinion, but you don't need the context of the whole trb to do the symlink experiment. from what i took of it, it's a matter of testing how various filesystems (probably starting off with ext4) can manage with (very) large numbers of nodes and large numbers of links to nodes. how seek times increase with those numbers of links to links, etc. (as an fs overhead, on top of hdd/sdd).