datenwolf

GDPR covers more than just PII.

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.

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.

Yep

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.

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.

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.

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".

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.

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.

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.

memory-safe language does not imply the use of a VM.

It can just as well mean, that the compiler will attempt to execute a proof, that memory is never accessed out of bounds, without well defined ownership and within the lifetime of the underlying object. Which is what Rust does, for example.

Of course it can also mean, that the compiler will then additionally add internal failure checks and safeguards at critical places (Rust does not do this, but it would be nice to have in systems where one might worry about in-register bit-flips (high radiation environments, like X-ray scanners), i.e. stuff not caught by – say – e.g. ECC memory).

If you really, really want to ruin an X11 session, I got you covered:

https://git.datenwolf.net/codesamples/tree/samples/X11/x11at...

If I define a function that always returns 1…

then it's Kolmogorov complexity is also extremely low.

Look if you have a well enough hash function, it output should be near the Shannon limit and hardly compressible, and ideally contain as much entropy as it has bits. But you can feed in just a single bit or the entire knowledge of humanity, in the end you're going to get a fixed amount of bits, and entropy near of that, and if you throw any form of lossless compression at it, it will hardly compress.

But quantum mechanics tells us, that information cannot be destroyed. So when you feed it more bits, than it emits, then its mostly the entropy of the information you feed in, that you get out of the hash. But if you feed it just a single bit, the additional entropy comes from the computational process.

I know, this is now getting really philosophical, but here's something to ponder on: How would you implement a hash function for a reversible computing architecture?

Boltzmann. But it doesn't really matter, it's the same thing. Yes, I know that looking at a sequence of, say 1000 identical bits looks like it's got just 10 bits of entropy after simple RLE compression. But you must not forget the entropy that also generated in the computation itself, and subsequently dissipated into the universe.

That only works, if you know exactly, that the low bits are constant. Otherwise you may run into the issue that due to unsteady rate of RDTSC between two processes/threads that may be preemptively unscheduled between reading the HPTC and the RDTSC you might again end up with colliding time stamps. And if you took the derivative between timestamps taken in succession, you might even find is to be non-monotonic in places.

The combination of multiple counters incremented by individual unsteady clocks used to be a source for pseudo random scrambler sequences; these days we prefer LFSRs, but overall this is something that can be weird.

Hence my recommendation: Just throw xxHash32 on concatenation of the HPTC's low bits and the CPU clock cycle counter, and forgo any pretense of monotony in the low bits (because very likely you don't have it anyway).

You don't know precisely at which frequency the cycle counter runs. Depending on the system load it might either run faster or slower than the lowest bits the HPTC. For what it's worth this part is more or less nondeterministic, so the sane thing to do, is spread out the information as much as possible (maximize entropy), in order to minimize the probability of collisions.

60 bits. Yes, I know, you can compress it down very well. But consider that entropy in computation involves not just the bits you store, but also the bits that the processor touches and eventually dissipates as heat into the universe.

I did update my program, now it measures the ratio.

Actually hashes do create entropy (every computation creates entropy in some form or another). What's the entropy of a 4 bit number? What's the entropy of a 4 bit number hashed by a 64 bit hash function? The act of computation does in fact create entropy, as per the 2nd law of thermodynamics, a part of which shows up in the hash.

Ah crud, you're right. What'd really be interesting to see is the ratio between d/dt rdtsc and d/dt clock_monotonic.

Because the raw value from the timestamp will be very low entropy and have the short scale variation concentrated in just a few bits. A hash not just destroys information, it also creates entropy by mixing that information over all the bits that come out of it. And using 64 bit hash replacing a 64 bit nanosecond counter that has short term entropy of less than 16 bits, you're in fact reducing the likelihood of a collision by a factor of 2^48.

It's 64 bit on 64 systems. In the world of hard realtime applications there's still a huge armada of systems out there in the field running on 32 bit (think motion control, CNC machines, industrial robotics). If you're developing software that's concerned with this kind of precision, you might find yourself confronted with such "outdated" systems more often, than not.

Also see https://news.ycombinator.com/item?id=36814762

RDTSC is directly influenced by frequency scaling. So while monotonic, its clock interval is neither constant, nor deterministic on modern systems.

Here's a small online visualization of RDTSC average and standard deviation I just hacked together: https://gist.github.com/datenwolf/151486f6d73c9b25ac701bdbde...

On a system with frequency scaling you can see that under higher load the difference between RDTSC in subsequent iterations of a tight loop that does nothing else than reading that register will drop. Here's how it looks on the system I'm currently using: https://www.youtube.com/watch?v=FKKjSJ1JZ78

Well, you can always attempt to catch the CPU cycle counter overflow (happens at roughly 10Hz on current machines), adding up the carries and add it to a nanosecond counter shifted up by a few bits. Problem with the CPU cycle counter is, that it's not in lockstep with the HPTC, due to dynamic frequency scaling.

If you really, really, really need system wide, nanosecond precision timestamps, you'll have to resort to dedicated hardware incrementing a counter at the desired rate, and with a well known latency for each read access. On the hardware and driver level you'd have some MMIO port mapped into user space with an identity transform between bus address and process address space.

However this still doesn't solve the problem, of the scheduler being able to throw in several milliseconds between reading the high precision timer value into a register and writing it back into the memory holding the timestamp variable. Seriously, on your typical computer system software derived timestamps at more than 100µs resolution are kind of bogus.

What is this "accuracy" you're talking about? Between the scheduler hanging over a process's head, ready to yank away its compute time for milliseconds between the syscall to read out the HPTC or the CPU cycle counter, and the process actually writing the timestamp into a variable/in-memory struct, reading the HPTC from the underlying hardware also not being super accurate, and the CPU cycle counter being influence by frequency scaling, on a bog-standard machine the highest precision you can reasonable expect is on the order of 100µs or so.

In other news: Water is wet.

The high resolution precision time counters are derived from the system base clock, usually operating at ~33MHz, which translates exactly into that 30ns granularity observed.

If you really want robust time derived timestamp identifiers, truncate the high resolution timer to at best 10µs resolution replace the low bits with the hash of them, concatenated with the value of the CPU cycle counter (`RDTSC` on x86).

All of it in the relativistic kinetic energy of the beam. The energy in the superconductor magnets is a whole chapter of its own; their energy dissipating into heat is what makes the Helium boil off during a quench.

Also static magnetic fields don't "do" work, by that I mean, that you can not extract energy from a magnetic field by sending particles through it: The Lorentz force is perpendicular to both the movement of the particle through the field, and perpendicular to the field itself. Hence taking the inner=scalar=dot product of the force vectors and trajectories they come out as 0, i.e. no work is done.

You need dynamic magnetic fields to do work.

Or run your own authorative DNS for example.com (or a subdomain used for this) and track queries on those UUID.

A lot of people confuse the passport (Pass) with the national identity card (Personalausweis). There's no place of residence stated on the German passport, but it is part of the Personalausweis. Since German citizens by law are required to own a Personalausweis (there's no mandate to carry it around, just having it somewhere in a drawer suffices), practically all businesses in Germany do rely on the Personalausweis to validate identities. And of course if the place of residence stated on the Personalausweis doesn't match the actual place of residence this is going to trigger some red flags.