Readit News logoReadit News
datenwolf commented on The future of 32-bit support in the kernel   lwn.net/SubscriberLink/10... · Posted by u/binarycrusader
datenwolf · 6 months ago
> There are still some people who need to run 32-bit applications that cannot be updated; the solution he has been pushing people toward is to run a 32-bit user space on a 64-bit kernel. This is a good solution for memory-constrained systems; switching to 32-bit halves the memory usage of the system. Since, on most systems, almost all memory is used by user space, running a 64-bit kernel has a relatively small cost. Please, he asked, do not run 32-bit kernels on 64-bit processors.

Ohhh yes!

So, a couple of weeks ago I came across a discussion where some distro (I don't remember which one) contemplated removing 32-bit user space support, suggesting to users to simply run a VM running a 32 bit Linux instead. It was a stupid suggestion then, and this statement is a nice authorative answer from the kernel side, where such suggestions can be shoved to.

datenwolf commented on Mesa3D Drivers for Windows   github.com/pal1000/mesa-d... · Posted by u/XzetaU8
sylware · 10 months ago
Yeah GL is really legacy. On elf/linux, I have it ONLY for the 32bits steam client which is still hardcoded for GL, x11 and 32bits (and probably a few small GL only games here and there, mistakes, which I would not mind _not_ buying if I had a clean drm/wayland/vulkan3D system).

I think I can run dota2 on clean wayland/vulkan3D stack (they are using libSDL3), and basically all roughly recent unity games (and probably UE5.x games which are carefull to build the wayland backend in their binaries). I am sure there is some hick-ups here and there though.

The work for "clean" legacy and dying apps is huge: Xwayland with a clean GLX/GL implementation on top of drm/wayland/vulkan3D. When you compare with the technical cost of wayland on drm/vulkan3D (well, there is a still some dependency on c++ abominations in vulkan mesa), motivation is a goner... and who is going to debug and maintain (actually make it work) that ultra-heavy and complex Xwayland/GLX/GL stack on top of drm/wayland/vulkan3D? It is hell.

I said all that but I am still running xorg... at least I am writing my own wayland compositor (something that suits me) to move away from native x11.

datenwolf · 10 months ago
First things first: It's just "Vulkan".

With respect to OpenGL with the current de-facto standard toolkits Qt and GTK you can't really get away from them for the time being, since at the moment they pull in some implementation of OpenGL as a runtime dependency; crossing fingers for that going away soon.

Also for that matter, although OpenGL is a legacy API, it's a well understood, well documented, and well tested environment. And as much as Vulkan makes certain things – well – not easier, but more straightforward, it isn't without issues. Heck, only recently Matías N. Goldberg found a long standing issue with swapchain reuse that got finally resolved with VK_EXT_swapchain_maintenance1

https://docs.vulkan.org/guide/latest/swapchain_semaphore_reu...

With respect to "technical costs" in the context of Wayland: IMHO it's mostly pushing around responsibilities and moving goalposts. Granted, setting up an on-screen frame buffer to draw on incurs a lot less moving parts in Wayland compared to X11. However, it comes at the cost of multiplying rather basic graphics machinery that's required for drawing the most simple things into each and every client. Of course shared libraries will somewhat ease the requirements on .text and .rodata segments, which can be shared; but all the dynamic state that's generated on initialization ending up in .bss and .data is redundantly kept around. And then there's the issue that Wayland also forgoes things like efficient use of screen frame buffer memory that cuts all windows from the same region of memory and managing pixel ownership. The "every window gets its own wholly sized framebuffer" only worked well for that small time window (pun intended) in which screen resolutions weren't as big as they now are becoming commonplace.

"4k", i.e. 3840×2160 @ 10R10G10B2A resolution takes up about 64MiB in a double buffered configuration (256MiB in an 8k format), if there's only a single window on screen. And every additional full screen application (even if minimized) will add another 32 MiB (128 MiB) to that. Those gigabytes of GPU VRAM don't look as plenty from that view.

The old and dusted (but not busted) way of using a single frame buffer and cutting windows from that doesn't look as outdated anymore.

datenwolf commented on Court filing: DOGE aide broke Treasury policy by emailing unencrypted database   theregister.com/2025/03/1... · Posted by u/rntn
sam_lowry_ · a year ago
I bet it was an Excel file and he failed to password-zip it )
datenwolf · a year ago
Yep
datenwolf commented on Court filing: DOGE aide broke Treasury policy by emailing unencrypted database   theregister.com/2025/03/1... · Posted by u/rntn
LinuxBender · a year ago
How does one email a database? With rare exceptions most mail servers have attachment limits of 16MB to 32MB. Just the schema alone could use up a chunk of the attachment limits. Is the title just oddly worded perhaps? Maybe they meant specific query results?

[Edit] Based on replies specific query results of two people names and dollar amounts into a spreadsheet. Poorly worded title on El Reg's part. Still a security privacy and compliance incident.

datenwolf · a year ago
From case witness testimony https://storage.courtlistener.com/recap/gov.uscourts.nysd.63...

    12. The forensic analysis also revealed that Elez sent an email with a
    spreadsheet containing PII to two United States General Services Administration
    officials. The PII detailed a name, a transaction type, and an amount of money.

datenwolf commented on NASA says Boeing Starliner astronauts may fly home on SpaceX in 2025   nytimes.com/2024/08/07/sc... · Posted by u/lode
GMoromisato · 2 years ago
I listened to the whole conference and here's my impression:

1. NASA manager Steve Stich said there's a relatively wide "band of uncertainty" in how risky a Starliner return is. Some (many?) NASA engineers are at the high end of the band and are advocating a return on Dragon instead. Boeing is obviously at the low end of the band and thinks it is a low risk.

The problem is, the data doesn't rule out either side of the band. So they are trying to get more data to narrow the uncertainty (in either or both directions). [Interestingly enough, the data from the White Sands testing made them more worried because it revealed the Teflon seal deformation.]

But my sense is that if they don't narrow the uncertainty (i.e., convince the NASA engineers) then they will very likely choose a Dragon return. That is, it sounds like if nothing changes, the astronauts are coming down on Dragon.

2. Stich said they need to decide by mid-August, in order to have time to prepare the Crew-9 launch for Sept 24th. So we'll know by then.

3. They emphasized that (a) the thruster problems are all fixable (given time), and (b) that even if Starliner returns without a crew, they will have learned enough from the test to potentially certify the capsule for regular service. This is probably the only way they'll be able to keep Boeing as a provider. A redo of this mission would cost Boeing half a billion dollars, easy. And since the contract is fixed-price, this would just add to Boeing's losses. So I expect they will certify Starliner even if it comes down without a crew.

4. In some ways, Starliner is being held to a higher standard than Dragon Crew-2. If Starliner were the only vehicle available, NASA and the astronauts would absolutely take the small risk and come down with a crew. But since Dragon is available, I think NASA is thinking, "why take the risk?"

5. There's a huge difference between how NASA engineers and lay people look at this issue. Many people (particularly on Twitter) have a binary safe/not-safe view of the situation. Either Starliner is safe or it is not. Either the astronauts are stranded or they are not. But the engineering perspective is all about dealing with uncertainty. What is the probability of a bad result? Is the risk worth the reward? Even worse, everything is a trade-off. Sometimes trying to mitigate a risk causes an unintended effect that increases risk (e.g., a bug fix that causes a bug).

I don't envy the engineers, either at NASA or at Boeing.

datenwolf · 2 years ago
> Some (many?) NASA engineers are at the high end of the band and are advocating a return on Dragon instead. Boeing is obviously at the low end of the band and thinks it is a low risk.

To me this gives a strong impression of history rhyming with itself. Back in the early 1980ies NASA engineers "close to the hardware" were raising warning, above warning about reliability issues of the shuttles, ultimately being overruled by management, leading to the Challenger disaster.

Then in 2003 again engineers were raising warnings about heat shield integrity being compromised from impacts with external tank insulation material. Again, management overruled them on the same bad reasoning, that if it did not cause problems in the past, it will not in the future. So instead of addressing the issue in a preventative action, the Columbia was lost on reentry.

Fool me once …, fool me twice …; I really hope the engineers will put their foot down on this and clearly and decisively overrule any mandate directed from management.

datenwolf commented on Backdoor in upstream xz/liblzma leading to SSH server compromise   openwall.com/lists/oss-se... · Posted by u/rkta
mbauman · 2 years ago
We know there's long-cons in action here, though. This PR needn't be the exploit. It needn't be anywhere _temporally_ close to the exploit. It could just be laying groundwork for later pull requests by potentially different accounts.
datenwolf · 2 years ago
Exactly. If we assume the backdoor via liblzma as a template, this could be a ploy to hook/detour both fprintf and strerror in a similar way. Get it to diffuse into systems that rely on libarchive in their package managers.

When the trap is in place deploy a crafted package file that appears invalid on the surface level triggers this trap. In that moment fetch the payload from the (already opened) archive file descriptor, execute it, but also patch the internal state of libarchive so that it will process the rest of the archive file as if nothing happened, and the desired outcome also appearing in the system.

datenwolf commented on Reddit: Return of the Junk Stock IPO   forbes.com/sites/greatspe... · Posted by u/belter
datenwolf · 2 years ago
What annoys me the most about Reddit is, that it's essentially just a rehash of Usenet with marginally more moderation features, up/down-voting and custom CSS for each group/subreddit. That's about it. If I were to attempt to implement a Reddit "clone", I'd merely spin up a couple of ISC InterNetNews NNTP servers and slap a web application in front of those.

The only thing that Reddit did – on the interaction level – was replacing the Usenet experience with a visually more appealing and easier to access web frontend. In that regard it's a continuation of Eternal September, with the side effect of draining the user pool from Usenet, leading to the shut down of many Usenet servers world wide because "nobody is using it anymore".

datenwolf commented on Facing reality about the EU is a core requirement for good management   baldurbjarnason.com/2024/... · Posted by u/M2Ys4U
paulsutter · 2 years ago
Yes each time we see these cookie warnings, we admire a system that does so much to our benefit
datenwolf · 2 years ago
Strictly speaking, those fat Cookie banners are unlawful under the regulation of the GDPR; the GDPR mandates that a site must not behave functionally different given consent or not, as long as the functionality is not related to a specific user.

Unfortunately there are only so many GDPR compliance officers around, and they have to focus on the bigger fish to fry.

datenwolf commented on An open-source browser engine written in Rust   github.com/servo/servo... · Posted by u/keepamovin
jasonjmcghee · 2 years ago
Always shade thrown at "in Rust" and I don't like how it's become buzz-wordy, but here it seems appropriate- not because "oh I might use this browser because it's written in rust" more like a great resource to understand how so many various features and functionality are implemented and fit together in a particular language that might be of interest.

If this were written in D or Zig or something other than C++, I think that's unique and worth mentioning.

What a cool project to be open source. Browsers do a lot of crazy stuff.

datenwolf · 2 years ago
Fun fact: Rust's development saw significant traction and support by Mozilla in the first place to be used for the development of Servo. Or in other words, the eventual development of Servo was, what motivated the development of of Rust from pet project into what it is today.
datenwolf commented on Bandcamp's Entire Union Bargaining Team Was Laid Off   404media.co/bandcamps-ent... · Posted by u/mstep
datenwolf · 2 years ago
Does anyone know the size of Bandcamp's catalogue. I'm just wondering about hardware costs (storage) would be for prospective competitors who intend to swoop up Bandcamp's customers (artists and listeners). Audio is a lot less demanding than video, and since there's no DRM it's basically just static files with some access control.

u/datenwolf

KarmaCake day1417September 8, 2011View Original