I never see anyone announcing a 10-20% executives cut. Seems like it would be simpler to let go a handful of people that receive the highest compensation and do the least work, especially after a merger where upper management is extremely redundant.

Why not a PNG or PDF in an email that I can access offline?

It's almost like Ryanair intentionally harasses their customers.

It's just a different way of looking at primary storage. Object memory is an even finer grain version of the old idea, and it offers some security advantages that linear memory cannot.

You probably have an intuitive sense for scams and cons.

I think we'll skip straight to 256-bit words if we re-visit Processing-In-Memory (PIM) and computational RAM. PIM is basically when you have a handful of SIMD/vector operations you can trigger with every memory access. That means you could do 2x2 64-bit float or 4x4 16-bit half float vector operations in one go. With the full 4x4 matrix of half-float/FP16 being very useful for inference, image processing, and maybe training. Even smaller formats like FP8 and FP4 are of course already used on GPUs, so maybe a 128-bit 4x4 FP8 or some of the more complicated shared exponent formats are good enough for special cases.

If we used segmented protected mode we'd have more like 64 TB* of virtual address space between GDT and LDT entries, half that if we assume the Global Descriptor Table is mostly fixed and only the Local Descriptor Table would have arbitrary entries added at run-time for a program's use.

Having potentially thousands of 4GiB WASM subroutine/overlays in a single process seems sufficient to me. If only the toolchain and kernels handled segmented mode. We kind of left that technology to the mainframe and stuck with linear addressing, far simpler for the architectures that Unix was designed for. (but somewhat more aligned with VMS, NT, and OS/2 architecture)

* selector's 13-bit index to descriptor table + 1 bit for Local/Global = 14-bit; add 32-bit for the full 4GB offset possible on each selector/segment you get 46-bits of virtual address space.

A third of the US stock market is in AI related business. The AI bubble pop will be more like an envelope collapse in a hot air balloon, ascending so quickly that you can't close the parachute and then you drop like a stone. The end point is at the bottom, there will be no soft landing. The middle class will be wiped out, and angry as hell that politicians and financial sectors allowed a massive depression to destroy our 401K retirement.

The ripple in the world economy will be staggering. The defaults on mortgages will wipe out the gains in residential real estate, the primary source of wealth for middle class Americans. Potentially a one-two punch with US bond and credit rating collapse, leading to unfavorable exchange rates making imports very expensive. But simultaneously with the US being out of the manufacturing business for decades, little infrastructure or expertise in modern efficient manufacturing techniques.

It's going to be very painful to watch my nation's decline, once an empire. And it's also going to be very frustrating to see my fellow Americans make excuses and live in denial about what is happening. We're going to be standing in a bread line together, joking about how at least we're not communists.

The x86-64 instruction set has some rather nice improvements to the encoding and flexibility with registers. The larger address space can be useful in some applications, but most applications are already bloated and having bigger pointers hasn't improved matters for this bloat problem. For systems that want to access more than 2GB-4GB of physical RAM, there has long been PAE/PSE-36 that permit mapping 64GB physical address space to a 32-bit virtual space. This makes for a pretty decent compromise for a desktop system that might want a relatively small amount of memory per application but have plenty of room for addressing physical RAM and mapping graphics memory.

The pros outweigh the cons with x86-64, and we're going to see OS vendors, application developers, and CPU OEMs trim the 32-bit support back in order to reduce testing and compatibility effort. Even if it seems easy to support 32-bit because the compilers already work, it's an extra build and test pass for a team's automated testing. Those extra passes might be better spent on an ARM64 or RV64 build instead of a x86-32, as those architectures are growing rather than rapidly shrinking.

The bugs in the JBIG2 decoder is the biggest security hole in common PDF implementations that I'm aware of, or at least the most notorious.

WebP 2 is almost certainly a dead-end.

WebP is almost always worse quality than JPEG for large lossy encoding, in part due to the limits of WebP's chroma subsampling options. It's a format designed for sending little icons over a mobile carrier network, and it's pretty terrible at doing what PNG or JPEG already do. WebP exists because animated GIFs can be massive and playback of embedded H.264/H.265/VP8/VP9 loops is a terrible user experience.

Actually deprecated? the industry isn't anywhere near the point where they will drop this shit format. But I predict that the format is not going to evolve any further and something will eventually need to replace it. WebP is going to end up being GIF's less attractive and less popular little sister, possibly locked away in Google's basement one day.

Hopefully anyone with GNU info installed knows what it does.

There are two things it does, one of which helps parse those pesky Windows headers when using C++. Of course that doesn't apply at all to Linux as it is not Windows and doesn't use C++ in the kernel. The other is unnamed struct/union members, which is standard in modern C but the Linux kernel isn't quite willing to accept everything in C11, so picking up some extensions that are accepted is the compromise.

Democracy is dead anywhere people aren't willing to put in the work to keep it. We all can think of one glaring example right now.

It's a GNU-flavored version of those MS extensions, originally they added a subset of what MS does in order to let gcc use data structures in MS's headers and have somewhat source compatible builds (I think this was roughly around the time Cygwin popped up, but I'm not sure).

A fair number of professional teams enabled those extensions for non-Windows code because they like some of the tricks available with the extensions and use it in their proprietary or open source code. It's a trend that has finally spread to the Linux kernel. I think this was really only possible as some of the kernel grognards retired or were otherwise not around to put up a fight and generally maintain the inertia force on LKML. Torvalds himself isn't quite as grumpy as people think and is generally pretty pragmatic and can be influenced by consensus and reasonable arguments.

I never suggested a proportional pay system. But the upper limit is paying someone based on what they produce, anything less than that makes it possible to operate a business, paying anything more and it's not likely the role can be justified.

The labor market is not a free market. There is significant manipulation on three sides of it; from unions, from business, and from government regulation. For the most part, whatever mechanism you imagine creates a "market value" for your labor is just that, mostly just your imagination. There is practically no economic incentive to drive wages up or down by a $1 when labor itself is not a real commodity. Exchanging one worker for another is certainly the dream for some, but it's a dream that even the most aggressive capitalists don't practice. They will pay one person more than another for the same advertised role. For example, it happens to such a degree that government regulations were created to deal with fair employment practices and discrimination. Other discretion and prejudice that is not protected by law is fair game of course. And the only reason for this is that labor is not treated as a commodity by either labor or management.

Life as a service is kind of what some people have as a plan for you. But I get your point, and I would again point that you have the concept of a market value confused as a zero-sum system of exchanges. The very benefits that capitalism espouse is that production and consumption do not have to balance out and shouldn't for some very important macroeconomic reasons.

Holistically, the cab company produces a service of a value. The most important aspect of that service is the labor the cab driver performs, but the labor is not the entirety of a cab company. Setting that quibble aside, let's assume you mean paying the cab company a percentage of your salary.

You as a customer are willing to pay some amount for the cab service. Traditionally we'd have a fixed price that everyone pays for cab fare, typically regulated by cities but almost always a formulaic charge of an initial fare + distance charge. Everyone pays the same amount because it would normally have been too difficult to work out each patron's income at the point of service.

If you were using a "surge pricing" ride-share app, that is attempting to seek a real-time demand pricing, then individuals get to decide on a price and each person can be presented different prices at different times. Through relatively straight forward statistical analysis on the backend, the supply-demand curve can be optimized in the businesses favor. And you will be paying near the maximum you are willing to pay, which is somewhat correlated to your own personal financial situation.

Echoes of Earth by Sean Williams and Shane Dix (first book of the Orphans Trilogy) explains a similar scenario to the Bobiverse books, but it is darker and perhaps a little more cynical on the hard scifi parts.