Posts by dotstdy@mastodon.social
(DIR) Post #B46cY5eRPuUABTHPoO by dotstdy@mastodon.social
0 likes, 0 repeats
@azonenberg the install tool is called archinstall, you can run it from the live image https://wiki.archlinux.org/title/Archinstall (not sure how the output of said tool goes for a vm configuration really, but i'd guess it has profiles for that kind of thing)
(DIR) Post #B5Jjfnl36Ea7XWzOj2 by dotstdy@mastodon.social
0 likes, 0 repeats
@mntmn more than 8 chars if you use a restricted subset as well!
(DIR) Post #B5LH3ZOVe5wVaULcvY by dotstdy@mastodon.social
0 likes, 0 repeats
@azonenberg @whitequark in xcb it's a c api as well, so cannae do the dynamic_cast regardless. but yeah dynamic cast still *is* insanely expensive on msvc... :/ (not that the cost would really matter for something like handling xcb messages which isn't going to be fast enough to write home about however you slice it)
(DIR) Post #B5m4F8N3tI9j7BlxnU by dotstdy@mastodon.social
0 likes, 0 repeats
@azonenberg on windows, pix, and on Linux, gpuvis. Probably the best bets. Iirc RGP also has a system tracing mode? Not sure if I remember that right.
(DIR) Post #B6A96ZqJXp55H9ETqq by dotstdy@mastodon.social
0 likes, 2 repeats
https://cgit.freebsd.org/src/commit/sys/kern/kern_exec.c?id=8e8ddb05d07142e95cf84e32bf93b9ecb3f90283 get ur daily rust appreciation exploit. today it's a bsd!
(DIR) Post #B6A96aBEI3oMK11BS4 by dotstdy@mastodon.social
0 likes, 0 repeats
this vulnerability was i believe found by an llm (filtered by a human), then has a vibe coded root privilege exploit attached. it's mentioned as a "operator precedence bug" but I can't say I'd really categorize it that way. they messed up the write size calculation and it leads to a tremendous out-of-bounds write. you can fix it by changing precedence, but you can also fix it by changing a + to a -.
(DIR) Post #B6Oadp0VbORCq4W5qK by dotstdy@mastodon.social
0 likes, 0 repeats
@azonenberg i tried it the other day as an adult and i must say i did not care for it
(DIR) Post #B6clt0prj4dTZnQJbU by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark I feel like you've really made my point for me when you point out that *the most popular distro which exists* doesn't have the resources to seriously work on something as foundational as the libc. and like i said, libc is easy mode. a completely ossified library with a relatively small surface area. there's far larger and more complicated systems which applications depend on. (anything which touches a GPU, for example. + nightmares like xml libraries, dbus)
(DIR) Post #B6clt2iqi8DBQc9jwe by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark At any rate I think while it's possible to imagine a world where distros actively maintain their entire library surface area, I don't think we live in that world. I think in order to claim that it's already possible you need to do some pretty aggressive culling of what you consider to be software worth building and supporting, and what you consider a distro. I don't really vibe with that in either case.
(DIR) Post #B6cm4AyeMMpwDQr6My by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark Resilient systems are not built by relying on a magical layer which cannot fail. They're built by spreading the burden of correctness culturally across the entire system. The argument here that distro maintainers can or should be the final arbiters of who is right and good in some kind of tug of war between "platforms" and "software" really just feels like people wanting to roleplay software judge judy, rather than build things which are reliable.
(DIR) Post #B6cm4BEFQNJUzo9YgK by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark I like to rip on ubuntu as much as anyone, but if I'm making software for distribution it's gunna work on ubuntu... Likewise musl is a minor PITA but if I'm shipping software I'd make an effort to test that it actually works there. Would my world be simpler if I just decided that Intel GPUs are shit and I don't want to support them? Yes. Would a distro maintainer be qualified to patch that support back in? Extremely unlikely, and certainly not true across all.
(DIR) Post #B6cm4BTUVhVTl5HjRQ by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark I disagree that this even works for libc et al, but imagine a difficult case like shader compilers. Toolchain runs as part of the application, it needs to work across semi-arbitrary combinations of userspace driver, application version, kernel driver and hardware (including vendor, generation, and specific sku) + containers. If you think you can just "code against the spec" and have this actually function for non-trivial applications then I envy your optimism.
(DIR) Post #B6cm4BgxhcHYQraURE by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark Plus the spec is deliberately broad to deal with wildly different hardware capabilities (e.g. the "simd width" on AMD is 64 or 32, on Nvidia it's 32, on Intel it's 8, 16 or 32, on Adreno there's no guarantee but iirc 128 or 64 depending on hardware generation). All of which is sufficiently performance critical that you can't generally emulate or ignore. Plus every one has a different shader compiler (or multiple shader compilers, even within a single platform)
(DIR) Post #B6cm4BuQtX3d6dtFR2 by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark I come from a world where we have farms of hardware running automated tests (as in farms of different kinds of hardware running the same tests) as part of CI flows, so to me the idea that you shouldn't even be *compiling* code or have CI at all is truly baffling.
(DIR) Post #B6cxHyBJpUPS53YqoK by dotstdy@mastodon.social
0 likes, 0 repeats
@mirabilos @pinskia @whitequark @dalias @glyph This is very focused on minor issues like CPU architecture, which is *easy mode*. Like I said earlier, it's really a matter of scope. If you want to say that only a narrow sort of software matters, and if by portability you mean "rhel but on more than one cpu architecture", you can kind of imagine the process vaguely working. But I don't have any desire to be so proscriptive of what software is or should be, or what platforms people should use.