matja

Depends on what proportion of Samsung's output is current HBM4 and HBM4E DRAM.

Everything in their statement can be true and it be a bad thing for consumers of non-HBM RAM.

"HBM capacity to expand to 250,000 wafers a month"

So let's say their current HBM capacity is 100k wafers/month (pure speculation/random number for illustration), and their total RAM capacity (including HBM( is 300k wafers/month, then non-HBM capacity reduces from 200k to 50k.

I'm surprised that in no reviews of the iPhone 18 camera there is mention of the bad quality bokeh, it has heavy ring shapes that looks like what you'd get from a cheap catadioptric lens.

Edit: e.g. the tree in one of the images in the page: https://www.dxomark.com/wp-content/uploads/2026/09/PoleHDR_D...

.len doesn't work on a list (because it might mislead you about the efficiency of the operation if it did exist), so it's better to use iterators - so then you can change the underlying type without changing your code.

But then, saying while "let Some(item) = iter.next()" everytime is tedious, so they give you .iter() - for any type that is efficiently iterable.

Nothing stopping you using a manual loop that you need to update if you change the container type.

> I'm not sure that nuking 2G of the underlying block device is a recoverable error on any filesystem that I'm aware of?

ZFS and btrfs were designed from the start to handle this, by using checksums on every piece of (meta)data and redundancy to return the same data as was stored to the kernel, and rewrite the bad data.

I've tested my own machines running ZFS by random writes out of band from the filesystem/kernel and it has always found and fixed them.

Add:

    "call_back_day": {
      "criteria": {
        "none": "The user does not want a call back.",
        "today": "The user wants a call back today.",
        "tomorrow": "The user wants a call back tomorrow."
      },
      "instructions": "When does the user want a call back?",
      "type": "choice"
    }

And you get: "tomorrow": confidence 1

I wouldn't say so, because it was a co-processor: e.g., it depended on the 8086 to even generate addresses for memory operations.

I think the IBM 7030 Stretch CPU (from 1964) would be a likely contender for being one of the first 64-bit CPUs.

> Also, the arbitrary "Oh, and the registers are 80 bits wide" is also just one of those weird "Where did that number come from?".

One of the features that was advertised (mentioned in the iAPX 86, 88, 186 Microprocessors Part II book (July 1984)) was the ability to do exact arithmetic on integers up to 2^64, which is possible due to the 64-bit mantissa used in the 80-bit format.

> I wish the stars would align for QEMU to gain support for sunlight/moonlight streaming directly in the hypervisor.

I didn't know I wanted it until you said it.

I have a few QEMU VMs where I use PCI-passthrough of a whole GPU and a USB controller, and wire the display and USB outputs physically into a KVM switch - works great, but not having to fiddle with the KVM (and run out of physical ports) would be - indeed, killer app.

The levels tool maps a subset of the channel range to the full range, effectively changing the brightness and contrast in one step.

The center point controls the gamma correction, so you can map a biased distribution (mostly bright or dark for example) to be more evenly distributed.

That was the purpose of that step - move the midpoint slider to about where the peak in the histogram is, to get an evenly distributed range.

The low/high slider can be moved towards that to increase the contrast.

"Contrast" here will only apply to the A/B channels, which is the color information, so it's increasing the color contrast and unbiasing it, while keeping the luminance information.

Photoshop also can do the same transform, and interactively in the LAB colorspace (no need to combine/uncombine the channels first).

You can do something similar in GIMP:

1) Colors > Components > Decompose > LAB

2) For the layers of the A/B (chroma) channels, Colors > Levels > "Auto Input Levels" (maximize the contrast), and move the mid point to the median.

3) Colors > Components > Compose > LAB

You're rejecting information solely based on the aesthetic quality of the delivery medium?

> every department is fighting for their lives against the others

https://bonkersworld.net/img/2011-06-27_organizational_chart...

Looks like it messed-up and they're just for padding, remove them and it makes sense.

I never noticed that before.

As such, I propose a replacement :) :

    To accomplish this, append the following warnings to the software. It is
    safest to place them at the beginning of each source document to clearly
    declare the exclusion of guarantees; plus every single file must include
    a minimum of the "copyright" text and a link detailing the full warning.

Obligatory mention, the GNU JUSTIFIED PUBLIC LICENSE: https://tom7.org/bovex/JCOPYING

(for the rabbit hole: https://tom7.org/bovex/)

The more popular your software is, the more likely you'll get bug reports from people with just bad hardware. I know a few applications now that perform a simple memory/CPU test when sending a bug report and reject those that are basically impossible.

E.g.: 10% of Firefox crashes are caused by bitflips : https://news.ycombinator.com/item?id=47252971

I meant that it's a difficult comparison between platforms without having all the details like memory latency, how the memory controller load increases latency (can increase by 4x on some platforms), cache latency, TLB entries, etc.

Extremely high bandwidth is great for copying data, but not as relevant for walking chains of pointers, where latency/cache/TLB entries are more important.

So just saying "high bandwidth == better" is true when other variables are the same, but they rarely are, especially in comparison to x86-64 offerings.

All of these are independent that it is a SoC with on-package DRAM.

Thanks for this, really interesting parent project too, I went down a rabbit hole on that one :)

It's higher bandwidth than any dual-channel DDR5 desktop machine, but Apple never quote the memory latency, so hard to compare otherwise.

It installed and runs perfectly on my VM with an RTX 4080 passed-though using VFIO. It uses the nvidia module rather than nouveau (at least on my GPU).

For those not on macOS, is there a video?

Same, having worked on firmware that controlled relays (and NAND chips) and managed to burn them both out surprisingly quickly due to software bugs :p

That's not very efficient

Encode every 0 as 10 - then decode every 10 back to 0. Or more efficiently, the first 0 as 10, then decode the the first 10 as 0.

OAuth is designed so that an end-user never needs to see an API key (OAuth refresh/access token) or even know what one is. When it is implemented to the spec, that happens well.

I think that most of the "just give me an API key" comments are from a <1% of end-users (developers) that know what an API key is, and are facing a broken OAuth implementation.

Amazon Route 53 is $0.40 per million DNS queries - which would terrify me if I used it, considering a typical 10Gbit server connection hosted at a unscrupulous ASN with no egress IP filtering is capable of sending a million DNS requests per second from random spoofed IP addresses.

> I feel like IPv6 is overengineered

In what metrics? IPv6 is more simple to implement than IPv4. In Linux 7.1.1 IPv4 is 84kLOC, IPv6 is 59kLOC.

I can think of a few reasons:

There wasn't any such features for x86 when the patch was created, other than AES-NI.

Many hardware platforms that have TPM, have it connected via a low-bandwidth LPC bus which would have nowhere near enough bandwidth for demand decryption/encryption of memory pages.

Hardware vendors can apparently turn these security features off as they wish, even if the hardware supports and was shipped with it :)

There was a patch called Tresor that did this, but I don't think it was updated for a long time.

You have to store the encryption key in CPU registers and ensure it's not saved to RAM during task switching or power suspend operations. Tresor used x86-specific debug registers for it, but you could potentially use unused SIMD registers if you masked-off the CPUID bits for them and disabled them for access by user-space.

But securing against attacks from a hostile hypervisor or a server provider needs more than just memory encryption, because they can intercept any part of the boot process and control the hardware/firmware that can lie to your kernel.

To counter that you'd need something like AMD SEV(ES/SNP) with measured boot and remote attestation to switch the only thing you trust to the CPU manufacturer (best you can do IMO).

Apt comic: https://www.workchronicles.com/p/comic-prevention-vs-cure

> well that is fortunate

I think that was one of the arguments of the Anthropic principle [1], that there doesn't appear to be any reason why there are 3 spatial dimensions and 1 time dimension, or why the fundamental constants are what they are - but if they weren't then there wouldn't be anyone to exist to say "well that is fortunate".

[1] https://en.wikipedia.org/wiki/Anthropic_principle#Dimensions...