Hide Idle (>14 d.) Chans
← 2022-11-21 | 2022-11-23 → ↓
asciilifeform: crtdaydreams: nfi whether the approach is practical yet. (managed to, so far, wedge x; and then, separately, to create unkillable zombie window after process killed, grr)
asciilifeform: and otherwise gnarly
bitbot[busybot|asciilifeform]: Logged on 2022-11-14 15:27:26 asciilifeform[5]: and of course ^ reopens the 'write font renderer, scroller, etc. widgetry from 0' sisyphian labour
asciilifeform: ( how to wedge? make the graphic larger than the window... )
jonsykkel[asciilifeform|busybot]: frebsd xorg-server 1.20 also gives 'Connection reply indicated failure.'
jonsykkel[asciilifeform|busybot]: XAUTHORITY is setted correctly thouhg
jonsykkel[busybot]: 'Invalid MIT-MAGIC-COOKIE-1 key' is what the server replyds if u read the eror mesage
jonsykkel[busybot]: apers to be big indian, maybe that it
jonsykkel[asciilifeform|busybot]: wtf is this line fatal_write(state->socket_fd, xauth_cookie + xauth_len - 16, 16);
jonsykkel[asciilifeform|busybot]: it worx if i manualy put the offset of last field of first xauthroity entry, rather than last entry like the prog dose
jonsykkel[asciilifeform|busybot]: that file apers to just be an aray of these
bitbot[asciilifeform|busybot]: Logged on 2022-11-22 00:20:27 asciilifeform[5]: crtdaydreams: nfi whether the approach is practical yet. (managed to, so far, wedge x; and then, separately, to create unkillable zombie window after process killed, grr)
crtdaydreams[busybot]: http://logs.bitdash.io/pest/2022-11-14#1016213 << how far did you get with your attempts at iron gc from thin air?
bitbot[busybot]: Logged on 2022-11-14 15:27:26 asciilifeform[5]: and of course ^ reopens the 'write font renderer, scroller, etc. widgetry from 0' sisyphian labour
asciilifeform: http://logs.bitdash.io/pest/2022-11-22#1016738 << suspected this! (but not had time to try). ty jonsykkel !
bitbot[asciilifeform|busybot]: Logged on 2022-11-22 01:47:26 jonsykkel: it worx if i manualy put the offset of last field of first xauthroity entry, rather than last entry like the prog dose
asciilifeform: and ty to erryone who test-fired.
asciilifeform suspects that 'use last entry' aint gonna work, necessarily, if there's >1 session (e.g. there's an x proggy going over tcp)
bitbot[asciilifeform]: Logged on 2022-11-22 04:17:34 crtdaydreams[jonsykkel|awt|signpost]: http://logs.bitdash.io/pest/2022-11-14#1016213 << how far did you get with your attempts at iron gc from thin air?
bitbot[asciilifeform]: Logged on 2022-11-22 00:20:27 asciilifeform[5]: crtdaydreams: nfi whether the approach is practical yet. (managed to, so far, wedge x; and then, separately, to create unkillable zombie window after process killed, grr)
phf[asciilifeform]: in general x.org doesn't work well when you work within the spec, but outside established conventions. optimized for gtk™, but if you pick up even xlib level programming guide and start doing odd things, very easy to lock the server or do a hard crash
phf[busybot]: back when x was used as a network protocol, to tie together a heterogenous unix ecosystem, the server would be written defensively, with the idea that the client might be malicious, or compromised, or just badly written with a home baked x protocol implementation (e.g. clx)
phf[busybot]: but considering that xfree86 came into prominence along with the whole linux pc hobbyist market, through the 90s it was a miracle when it worked at all, while in the 2000s, when the x.org fork happened, the attention shifted to "renders movies and games" and "linux on desktop"
phf[busybot]: so while there exists some platonic idea of x window system protocol that one could first principles from, the reality of still surviving artifacts is mostly dismal
phf[asciilifeform]: that's also how succesful wayland propaganda works: same people who drove a questionable xorg/xfree86 architecture and codebase into the ground to the point of basically going "fuck this shit, we can't solve all these old standing problems, that we ourselves created" can then attack x as ecosystem with a strawman of their
phf[asciilifeform]: questionable implementation, that they themselves are then going to replace with own better™ solution
phf[asciilifeform]: but they are also right at the same time, because there's no x outside of xorg/xlib/xcb/gtk/kms/drm and the ungodly interaction of those components
asciilifeform: phf: asciilifeform (who normally quick on trigger to say 'it suxx') not even concluded 'x is broken!11'. rather, it simply has ~0 error handling (and none even promised in the manual, fwiw)
asciilifeform: so far found that in fact still worx entirely as described in the ancient deadtree.
asciilifeform fwiw not tried to use the direct-to-memory extensions, shm etc. cuz not writing a shooter, lol, but simply text proggy
asciilifeform: + would like it to work over tunnels like normal xisms
asciilifeform: http://logs.bitdash.io/pest/2022-11-22#1016759 << last asciilifeform knew, the wayland people managed to replicate the microshit graphics system faithfully, incl. crashes and 'want remote? here's a 1024x768 desktop' etc
bitbot[asciilifeform|busybot]: Logged on 2022-11-22 19:23:08 phf[awt]: that's also how succesful wayland propaganda works: same people who drove a questionable xorg/xfree86 architecture and codebase into the ground to the point of basically going "fuck this shit, we can't solve all these old standing problems, that we ourselves created" can then attack
asciilifeform: http://logs.bitdash.io/pest/2022-11-22#1016757 << btw any idea what crapple's variant of x was made out of ? (is it simply xfree86 on top of their graphics stack?)
bitbot[busybot]: Logged on 2022-11-22 19:16:42 phf[awt]: but considering that xfree86 came into prominence along with the whole linux pc hobbyist market, through the 90s it was a miracle when it worked at all, while in the 2000s, when the x.org fork happened, the attention shifted to "renders movies and games" and "linux on desktop"
phf[asciilifeform]: asciilifeform, my point is that xorg is designed for "linux on desktop", assumes well behaved clients in the form of essentially gtk apps. this is not how things used to be done. i've learned x programing with a sgi o2 machine that they sold at terrapin trader, and sgi wrote their own X implementation called Xsgi, which, w
phf[asciilifeform]: ritten as it was by grownups, didn't exhibit this kind of corner behaviors. was entirely bulletproof when it came to faulty x packets, weird states, etc.
phf[busybot]: as far as wayland, there aren't "wayland people", the system is being developed by the xorg people, in fact xorg itself has been in "maintenance mode" for a while now, where the bulk of xorg work goes into xwayland, an embeded wayland subsystem for running x programs
phf[asciilifeform]: xquartz, the apple thing, is also part of xorg
phf[asciilifeform]: that's my take and my sticking by it
asciilifeform had o2 in office, long ago, for yrs, but not programmed for it -- it ran 3d visualized thing with fantastically expensive visor helmet
asciilifeform: interesting re xsgi & corner cases, had nfi.
asciilifeform: phf: didja have to patch 'modern' x to connect with bolix ? (which asciilifeform would expect aint least bit 'gtk-like' in behaviour)
phf[asciilifeform]: asciilifeform, yes, there's a handful of ops in genera that'll hard lock x server. one during boot, which is documented in most "how to opengenera.tar.bz2 on linux". i believe the version i'm running has been pre-patched
phf[asciilifeform]: also the particular hard lock was introduced in the recent version of xorg, because for a longest time the instruction was to run redhat 6.x vintage to get opengenera working
phf[asciilifeform]: for a longest time, meaning since the regression got intorduced until recently when it was fixed on genera side
asciilifeform: a ha that'd explain wai the traditional recipe is to stuff it in vmware w/ old rathead
asciilifeform thinks he recalls being able to xtunnel to ye olde dec alpha genera, but may be imagining, been some yrs since booted that one
asciilifeform: and for that matter can't recall on ~what~ precisely was the other end of that tunnel
← 2022-11-21 | 2022-11-23 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code