billymg: and by "spendable" i mean without kyc and with only fair tax from honest jurisdiction (which afaik isn't possible / doesn't exist)
billymg: so must be consistently spendable, so that it can last\
billymg: and made the same point, anything you "pre-cashout" inflates away
billymg: to mean*
billymg: asciilifeform: yeah, that's what i was saying. i misunderstood signpost's '30% for freedom' meaning 30% of stack
billymg: which required quite a bit of fussing even with the upstream gentoo at the time
billymg: signpost: yeah, i suppose i should try it again on this box. last time i tried had almost 0 experience with gentoo and on top of that was trying to install it on some exotic new x1 6th gen thinkpad
billymg: signpost: but it sounds like advantage of separate repo is eventually can jettison upstream completely, which means less work?
billymg: signpost: from my limited understanding of working with my own (growing) overlay at /usr/local/portage, having an overlay also allows you to pick versions/ebuilds between the main repo and overlay fairly easily
billymg: signpost: i'll look again. so yours was for an entire portage tree, not just designed to be an overlay?
billymg: maybe that number goes down over time, but still
billymg: signpost: i think would take 10 billymgs unfortunately
billymg: signpost: ah, i didn't understand that the '30% for freedom' meant renouncing citizenship
billymg: signpost: i think what happens then is the amount you cashed out to be sufficient for freedom inflates away to not enough for freedom in a few years
billymg: signpost: yeah, i believe around 20% as of today, but i keep hearing it'll be 50% soon (possibly in that 'infrastructure' bill?)
billymg: so to me it seems the real root of "why no sane gentoo fork" is "btc not spendable"
billymg: signpost: yeah, so maybe not thiel. and to answer my own hypothetical re: mega btc exchg rate, would not help in current order because it's mostly write only
billymg: and if yes, then is problem solved by 1e6 btc exchange rate (where sandwich stays the same price ofcourse)
billymg: does the problem boil down to money? if thiel wanted to pay 3-4 ft engineers to maintain a sane fork of gentoo, would that work (hypothetically)?
billymg: also had ft job at the time
billymg: signpost: i was around for cuntoo, even tried doing something with it, but at that point had too little experience to really know what i was doing
billymg: but i've seen more than 2 people, perhaps dozen, that want
billymg: asciilifeform: what do you suppose is the reason there isn't a project like this already?
billymg: seems if they knew how to talk to eachother and organize could work on maintaining ONE custom overlay that did what's needed
billymg: i've seen multiple custom overlays, people filing issues with popular programs requesting builds that don't require dbus, etc.
billymg: asciilifeform: it seems like there are enough people out there not wanting dbus/systemd
billymg: ok, i might try that NOP solution then
billymg: asciilifeform: interesting, so reason gtk+3 is banned is because it brings in dbus?
billymg: asciilifeform: http://paste.deedbot.org/?id=InD2
billymg: app-accessibility/at-spi2-atk already masked in your crapolade file
billymg: which?
billymg: chromium
billymg: asciilifeform: been --nodeps'ing and manually installing missing deps but finally may have hit a wall with 'atk-bridge-2.0' which is part of app-accessibility/at-spi2-atk
billymg: the warning, if curious, was "USER_NS is required for sandbox to work"
billymg: couldn't run sudo modprobe configs
billymg: not at /proc/config.gz, not in /boot
billymg: asciilifeform: btw i first tried looking at my rockchip's kernel config but couldn't find it anywhere
billymg: asciilifeform: thanks
billymg: asciilifeform: a warning came up in the build about kernel config USER_NS, which i do not have set. should i enable that?
billymg: i keep forgetting about the --nodeps strategy
billymg: then i'll try his custom ebuild
billymg: first with upstream latest
billymg: trying now
billymg: not yet
billymg: asciilifeform: so i found this overlay which has an ebuild for chromium that makes dbus optional, but this depends on the atk use flag, and if disabled, no dbus, but then wants to use gtk3
billymg: if there are none, then oh well, i don't mind having done this for my own knownledge
billymg: asciilifeform: less about hygiene and more about which one is most likely to not require pulling in these systemdisms i've been spending time to avoid
billymg: asciilifeform: which browser do you recommend i try in this environment?
billymg: asciilifeform: it's certainly maddening. this whole exercise has given me newfound hatred for these people
billymg: which prompted me to search for startx suid and then i found the news item about how in june 2020 they disabled it by default
billymg: asciilifeform: yeah, that guide on gentoo's official docs mentions 'suid' but does so in a "don't use this, it's legacy" warning box
billymg: alright, can report that i now have a working xorg with dwm while respecting asciilifeform's ban list
billymg: now back to figuring out non-root xorg...
billymg: ahh, it's some | like character being displayed as a 'aOA' (but with ^ accents over each letter), among other strangeness
billymg: also, i'm now trying to get startx actually working, and looking at the gentoo guide for non-root-x it seems like i need to have at least elogind (which i think i removed because the xorg-server ebuild on his github wanted to pull in dbus if either systemd or elogind were present)
billymg: i think something might've gotten fucked up with ncurses though, i'm seeing strange/stuck characters in weechat and links, e.g. │
billymg: i used that guy's guide to rebuild openrc from his custom ebuild, then used his xorg ebuild and was able to build that as well
billymg: well, some progress...
billymg: ty asciilifeform
billymg: ^ after a few rounds of manually installing missing deps
billymg: asciilifeform: configure: error: systemd-logind requested, but D-Bus is not installed.
billymg: asciilifeform: got it, i had already included a -dbus flag in USE and got the same error. will try with --nodeps
billymg: or does --newuse apply to something else
billymg: asciilifeform: thanks. qq re: USE flags in make.conf: after changing, `emerge --newuse` sufficient to load new values?
billymg: i'm trying to decide if it's worth it for this box (again, this is going to be for doing bitdash and mp-wp development, doesn't have to be military grade) or if i should just unmask dbus
billymg: it looks like at one point you had a recipe for configuring X without dbus but the referenced paste is dead now
billymg: asciilifeform: i've got a pretty clean new box now using upstream along with your ban list (typing from weechat on here currently) but it seems X requires dbus so i'm sort of stuck there at the moment
billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-28#1054314 << basically it from what i can see on their www
billymg: i figure they might be useful if i can find a bum to buy some sim cards for me, but also don't think i'm all that interesting at the moment to warrant the effort
billymg: signpost: i figured as much. i bought a couple of these from a local shop just in case, but yeah, i'm sure they still suffer from this only with less convenience
billymg: has anyone here ever looked into it or tried it out?
billymg: regarding operating systems, i searched in the logs for any mention of 'grapheneOS' and found none. my gut tells me it's not much better than off the shelf android, and perhaps worse because it gives you a false sense of security whereas with stock you're conscious of the fact it's already pwned
billymg: signpost, bingoboingo: thanks, i'm keeping this in mind. this machine in particular doesn't have to be military grade
billymg: asciilifeform: ok, good to know. if 5.x good enough for asciilifeform then certainly good enough for me
billymg: asciilifeform: i was searching the logs and it seems like most people here stick with 4.x, also saw your logline re 5.x here
billymg: latest 4.x?
billymg: asciilifeform: any particular 4.x kernel you'd recommend from the heathen upstream options?
billymg: asciilifeform: will try this approach, ty
billymg: unless asciilifeform thinks i should instead stick with the dulap that's currently on the box and try to find another way around this missing dep for xorg
billymg: maybe i'll try the hardened openrc stage3 from their downloads page and see where that gets me
billymg: asciilifeform: on a laptop of mine i started with a stock upstream gentoo (2018 i think) and retrofitted with gcc 4.9.x, afaict also still systemd free (i started with an openrc stage3 tarball)
billymg: asciilifeform: oh, i misinterpreted the 'circa-2021' packages part then
billymg: asciilifeform: i'm about to embark on a new gentoo build like this one. can i ask if you started with one of the stage tarballs from here and if so, which one?
billymg: asciilifeform: np
billymg: some people automate this by appending a file hash but i don't make enough updates to bother with that yet
billymg: e.g. my logotron mirror now on v10 <link rel="stylesheet" href="/static/bitdash.css?v=10" />
billymg: this forces the client to pull from the server rather than cache
billymg: asciilifeform: btw, another thing for css caching. whenever i make a change to a css file on one of my sites i update the <style> link tag as well, adding a ?v=$VERSION param to the url
billymg: asciilifeform: glad it worked, note also it's on top of 'archived_chans.kv.vpatch' rather than 'style_fixes.kv.vpatch' since it has more or less the same end result but also works with the crapples
billymg: was sort of an interesting exercise for me at least, formatting for both lynx and graphical browsers
billymg: that's actually the neat thing about lynx, since it ignores css, can put special lynx-only bits in your markup and simply `display: none;` in graphical browsers to hide
billymg: yeah
billymg: yeah, i saw it on your www, then `shift-refresh`
billymg: make sure to clear cache for css
billymg: it's lynx only
billymg: asciilifeform: updated in place, should be correct now
billymg did a test press before publishing
billymg: oddly enough it works with v.pl
billymg: one sec
billymg: my bad
billymg: lol d'oh
billymg: asciilifeform: i put together a patch that fixes the classic theme's chan wrapping bug in apple browsers and uses the list-based chan nav. sig is here too if you'd like to give it a quick test
billymg: asciilifeform: end result would be: 1, in lynx: what you see now on logs.bitdash.io, 2, in graphical: what you see now on logs.nosuchlabs.com. all clients (lynx, chromium, phones, etc.) would receive the same html, no server side tricks
billymg: asciilifeform: my alt variant that i recommend is what you can see currently on my logger (in lynx, in graphical would be identical to your current theme but with properly wrapping rows)
billymg: asciilifeform: and in lynx you probably never will, lynx table rendering appears to be meant strictly for tabular data, not for layout tweaking
billymg: i saw you added <br> tags, but lynx ignore those if used inside tables
billymg: which is what broke the lynx styling
billymg: asciilifeform: your latest patch, style_fixes, did away with the two-row chanlist (where, roughly: <tr> chans... </tr> <tr> timestamps... </tr>)
billymg: asciilifeform: the lynx/graphical differences are just a result of lynx completely ignoring any and all css
billymg: asciilifeform: no, same html, always
billymg: to keep that 100% 1:1 with your previous theme (in lynx), had to keep the table. in graphical browsers, can switch to <ul> based and render exactly how you had it (and even make the improvements you want, such as auto wrapping)
billymg: asciilifeform: it is. two separate considerations: graphical rendering and lynx rendering
billymg: asciilifeform: nope, in fact had a css ready to go that would render in graphical exactly the same as you had on your theme prior
billymg: this was because i assumed the vertical chan list in lynx was a hard req, and due to lynx's limitations could not get timestamps to sit under chan names without doing two rows (and having a weird tab order of chan, chan1, chan2, chan_ts, chan1_ts, etc...)
billymg: your theme works with the table-based, mine works with the list-based
billymg: asciilifeform: yes, was clear, but my patch had two html variants for the chanlist: 'chan-nav-table.html' vs 'chan-nav-list.html'
billymg: asciilifeform: it is, i had baked a classic.css theme that worked with this html
billymg: asciilifeform: wish you would've told me that months ago when i was working on it! lol
billymg: asciilifeform: yup, this is my personal preference for lynx. would you be opposed to that for your theme? (if so can nuke chan-list-table.html and users only need to switch css file to go between themes, not also the template file)
billymg: asciilifeform: i switched mine back to my theme, take a look in lynx and see if you still hate the vertical stacked chan list
billymg: asciilifeform: not disagreeing, but i do know (as a result of being paid to know) how to work around most of these issues
billymg: ok, gonna switch my logger back to its default theme
billymg: that makes it easy at least
billymg: ahhh
billymg: or based on width of client (if server can somehow know this)
billymg: is 3 arbitrary?
billymg: i was assuming your solution was a server side solution
billymg: asciilifeform: right, but does it send e.g. "viewport width" to the server so the server can calculate the right number of lines to send back
billymg: asciilifeform: not sure how that hardcoded approach would help with lynx though
billymg: asciilifeform: i'm happy to help with this
billymg fought with this for quite some time actually, until eventually gave up and provided two separate chanlist templates, one based on <table> to work with classic.css and to asciilifeform's specs in lynx, and one based on <ul> which renders as a stacked list in lynx (and however you want in graphical browsers, depending on the css)
billymg: where you keep the channel together with their last active timestamps together in respective table cells (which imo is semantically and ordinally the right approach)
billymg: looking at the patch though it looks like you tried a similar approach to what i attempted back when i was working on these themes
billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-23#1053516 << sorry, i meant a result of your latest html changes (CSS has absolutely 0 effect on lynx)
billymg: (i switched it to the classic theme with <table> chanlist layout temporarily to test this)
billymg: asciilifeform: i think that was a result of your latest css changes, see http://logs.bitdash.io in lynx
billymg: if so, that's good
billymg: iow works as you want out of the box?
billymg: so it's gonna render based off your <table> tag structure only
billymg: asciilifeform: going back to lynx, i can't think of how you'll ever achieve something different than what you have now, since all CSS is ignored
billymg: kind of an amusing result
billymg: ok, i see the problem in ios now lol
billymg: right
billymg: asciilifeform: right, but iirc it was also a requirement of yours that the channel links be displayed in a horizontal row in lynx
billymg: and what are the reqs for lynx rendering?
billymg: ahh
billymg: seems to sort of be working that way, at least in chromium
billymg: asciilifeform: regarding the css for your logger theme, what was the goal for the table? have it always stretch to full width rather than size of elements and centered?
billymg: asciilifeform: looking forward to it, i really like dulap for its ease of installation
billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-23#1053471 << also if the output of this effort is ~= to a "2021 dulap" i'd pay to have a copy
billymg: asciilifeform: https://g3ngr33n.github.io/systemd-openrc/index.html << this is for excising any remaining traces of systemd from "stock" 2021 gentoo?
billymg: i can't remember if dulap is meant strictly as a headless distro or can be configured with dwm
billymg: asciilifeform: unrelated, i'm trying to configure dulap with xorg and dwm but one of the deps for xorg isn't found on your repo, 'app-eselect/eselect-mesa-0.0.10-r1'
billymg: asciilifeform: right, but this concedes there's an advantage to the individual vs. the organization
billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-23#1053423 << this property of bitcoin seems like cause for optimism (if you can survive long enough). it would also undermine these kinds of schemes by the reich
billymg: weren't the "cryptokitties" in 2017 the same thing too? i think they just rehash it during each hype cycle to distract from btc and divert funds from btc into eth
billymg: asciilifeform: np, ok sounds good
billymg: asciilifeform: in the jungle since yesterday with spotty internet, will be back to relative civilization tomorrow and can take a look at the css
billymg: a brief delay so you have a chance to see that you received a redirect
billymg: i wonder if lynx does it intentionally
billymg: asciilifeform: ah, i see this now in lynx, where it briefly says "using http://logs.nosuchlabs.com/log/" then loads
billymg: asciilifeform: are you still seeing an issue with 301s?
billymg: missed adding*
billymg: apologies for that oversight. i even had the correct version in my local copy, but must've missed added it to my v workspace when creating the patch
billymg: yes, will patch
billymg: nice!
billymg: that line in the deedbot paste is the fix
billymg: this one: http://paste.deedbot.org/?id=6910
billymg: you haven't added that line yet
billymg: (yellow highlight on "therealbitcoin")
billymg: but should be there on http://logs.bitdash.io/therealbitcoin
billymg: if css is cached
billymg: asciilifeform: might have to shift-refresh
billymg: the markup is already being spit out correctly, e.g. <a class='chan-link chan-link-active' href='http://logs.nosuchlabs.com/log/asciilifeform/'><b>asciilifeform</b></a> (with "chan-link-active" on the current channel)
billymg: temporarily switched mine to the classic theme to show this working: http://logs.bitdash.io/therealbitcoin
billymg: asciilifeform: damn, it was a css change in 'classic.css' that i had in my local copy but somehow didn't make it to the patch. you can add this to your css as the fix. i checked the markup on your logger and it's correct, it was just that css that never made it in
billymg: it should be working there as well but perhaps i missed something
billymg: yes, i am about to double check
billymg: "highlight" in that theme is vertical bar to left of the name (if viewing in e.g. chromium)
billymg: asciilifeform: yeah, the highlight should be working, see http://logs.bitdash.io/therealbitcoin
billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-19#1053211 << back at terminal, i will of course fix any bugs that were the result of my changes. need to investigate first
billymg bbl
billymg: asciilifeform: this is my vhost config: http://paste.deedbot.org/?id=r4Id
billymg: asciilifeform: hmm, i've been running mine this whole time as a wsgi module
billymg: cgra: glad to hear, is your blog live anywhere yet? and definitely let me know if you run into issues or see things you'd like added
billymg: also requires escaping HTML characters locally before pasting your code in, see this footnote for sed script that does the trick
billymg: usage is roughly [plaintext[ ... ]] or [diff[ ... ]]
billymg: cgra: yes, in fact there's a built-in feature that handles code formatting (currently only to a limited extent: monospace font, linkable line numbers, and line highlighting for diff syntax)
billymg: ahhh
billymg: cgra: how do you mean? the hand-cranking of adding <p> and <a> tags?
billymg: cgra: spyked also wrote added a markdown plugin at some point
billymg: cgra: recommended way is just markup your post with html directly (i usually draft locally then paste into the box when i'm ready, or almost ready, to publish)
billymg: cgra: yup, the input box accepts just about any html (not sure off hand if anything is stripped, i don't believe so)
billymg: seems to me*
billymg: seems to be to be nearing point of exhaustion
billymg: asciilifeform: that's what i mean, is reich on par with earthquakes in its totality?
billymg: asciilifeform: but does a brave man also lament constantly how his enemy is all powerful and can never be defeated? i don't see the braveness in admitting defeat, even if "not scared to die"
billymg: asciilifeform: i gotta ask, if situation is so completely hopeless, what keeps you going?
billymg: and i suspect the types that are especially competent and able to do so talk the least about it online
billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-16#1052698 << i don't think all of them are reddit larpers, i think some are able to grow own food, build own houses, etc. without walmart credit card
billymg: asciilifeform: that was one of my first thoughts as well, aim 'em at the "domestic terrorists"
billymg: bingoboingo: better than not going i suppose
billymg: in that case sounds like the area just ran out of usefulness, in which case hard to chalk it up as a loss
billymg: hey bingoboingo, how's it going?
billymg: ah
billymg: ?
billymg: AQ
billymg: if usg had to compromise and didn't get exactly what they wanted ("rebuilding" afghanistan with the cooperation of pakistan, if i'm understanding correctly) then i would consider that a loss for them
billymg: that's what i meant by my original question, whether this was an actual defeat or just some shuffling to put in place a different, but still friendly, regime
billymg: demonstrates that an indigenous people can defend themselves against a much more technically advanced and well funded adversary
billymg: the people in red states who hate the feds and want to defend themselves with their rifles
billymg: in that case sounds rather encouraging for the patriots in idaho and surrounding terrain
billymg: speculation*
billymg: anyone in here have any spectulation on the afghanistan situation? an actual USG defeat or just another CIA op?
billymg: thimbronion: but sounds good, i'll probably start on producing some mockups for the theme soon
billymg: thimbronion: probably best to hire human editors to do the grunt work of fixing the typos
billymg: thimbronion: btw i'm at the point now where i'm ready to start on your alethepedia theme and features for mp-wp
billymg: asciilifeform: perfect, that's exactly it
billymg: ok, will look into it
billymg: asciilifeform: ah, already a feature? does it do it on the frontend or did it do it on import into the DB?
billymg: when i'm reading the logs i'm doing so on my logger, so have thought of adding feature that replaces other logger links with the corresponding links on mine, so that i'm not jumping between two loggers
billymg: btw, asciilifeform, jfw told me about an idea bvt had for logline ids derived from hashes of the payload, to allow for interoperability between various loggers
billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-11#1052069 << yeah it's shit like that that makes me think they don't really want to "win". what? already winning, look at book deal!
billymg: asciilifeform: i sometimes wonder if part of the grift. "friends, countrymen: i've been censored on blogger/twitter, follow me on substack!" *generates buzz* *6 months later* "friends, countrymen: i've been censored from substack, follow me on..."
billymg: yeah, i remember that
billymg: oh yeah, speaking of victims of the reich Vox seems to have followed closely behind BAP in being deplatformed
billymg: asciilifeform: actually, looking at logs it may have finally hit that same snag
billymg: until it falls down
billymg: it is
billymg: asciilifeform: noted
billymg: so can't say for sure
billymg: or perhaps a particular user agent string that ran off the page, though those should be contained
billymg: an older version
billymg: could've been cached css
billymg: dunno, didn't change anything lol
billymg: nice
billymg: asciilifeform: fixed
billymg: yeah i see
billymg: oh, hrm
billymg: asciilifeform: very cool, glad you're finding it useful so far