Let's back up to the start. When you switch on a computer, the power rails on a bunch of the chips come up. As this happens, the chips enter a "reset" state with initial data that is baked into the circuitry. This is the power-on reset (PoR) circuitry. When the power is up and stable, the "reset" is over and the processor starts executing. The initial value of program counter / instruction pointer is called the reset vector, and this is where software execution begins. On an x86 PC, this is something like 0xFFFFFFF0. The memory controller on the system is configured for reads from this address to go NOT to the main RAM, but to a flash memory chip on the board that holds the firmware software. From there the firmware will find your bootable disks, load the bootloader, and pass control to it.

In practice, systems vary wildly.

Integrated into a single color sample indeed. After all the integration, mosaicking, and filtering, a single sample is calculated. That’s the pixel. I think that’s where the confusion is coming from. To Smith, the “pixel” is the sample that lives in the computer.

The actual realization of the image sensors and their filters are not encoded in a typical image format, nor used in a typical high level image processing pipelines. For abstract representations of images, the “pixel” abstraction is used.

The initial reply to this chain focused on how camera sensors capture information about light, and yes, those sensors take up space and operate over time. But the pixel, the piece of data in the computer, is just a point among many.

Perhaps I should have chosen a higher resolution. AIUI, in many modern systems, such as your OS, it’s usually bilinear or Lanczos resampling.

You say that the resize should be faithful to the “100x100 display”, but we don’t know whether it was used from such a display, or coming from a camera, or generated by software.

> I'm almost certain this process didn't preserve sharp pixels

Sure, but modern image processing pipelines work the same way. They are working to capture the original signal, with a hopeful representation of the continuous signal, not just a grid of squares.

I suppose this is different for a “pixel art” situation, where resampling has to be explicitly set to nearest neighbor. Even so, images like that have problems in modern video codecs, which model samples of a continuous signal.

And yes, I am aware that the “pixel” in “pixel art” means a little square :). The terminology being overloaded is what makes these discussions so confusing.

This is where I was trying to go. The pixel, the result at the end of all that, is the single value (which may be a color with multiple components, sure). The physical reality of the sensor having an area and generating a charge is not relevant to the signal processing that happens after that. For Smith, he's saying that this sample is best understood as a point, rather than a rectangle. This makes more sense for Smith, who was working in image processing within software, unrelated to displays and sensors.

This signal processing applies to images as well. Resampling is used very often for upscaling, for example. Here's an example: https://en.wikipedia.org/wiki/Lanczos_resampling

> It was already wrong in 1995 when monitors where CRTs, and it's way wrong in 2025 in the LCD/OLED era where pixels are truly discrete.

I don't think it has anything to do with display technologies though. Imagine this: there is a computer that is dedicated to image processing. It has no display, no CRT, no LCD, nothing. The computer is running a service that is resizing images from 100x100 pixels to 200x200 pixels. Would the programmer of this server be better off thinking in terms of samples or rectangular subdivisions of a display?

Alvy Ray Smith, the author of this paper, was coming from the background of developing Renderman for Pixar. In that case, there were render farms doing all sorts of graphics processing before the final image was displayed anywhere.

Integrates this information into what? :)

> A modern display does not reconstruct an image the way a DAC reconstructs sounds

Sure, but some software may apply resampling over the original signal for the purposes of upscaling, for example. "Pixels as samples" makes more sense in that context.

> It is pretty reasonable in the modern day to say that an idealized pixel is a little square.

I do agree with this actually. A "pixel" in popular terminology is a rectangular subdivision of an image, leading us right back to TFA. The term "pixel art" makes sense with this definition.

Perhaps we need better names for these things. Is the "pixel" the name for the sample, or is it the name of the square-ish thing that you reconstruct from image data when you're ready to send to a display?

> This is an issue that strikes right at the root of correct image (sprite) computing and the ability to correctly integrate (converge) the discrete and the continuous. The little square model is simply incorrect. It harms. It gets in the way. If you find yourself thinking that a pixel is a little square, please read this paper.

> A pixel is a point sample. It exists only at a point. For a color picture, a pixel might actually contain three samples, one for each primary color contributing to the picture at the sampling point. We can still think of this as a point sample of a color. But we cannot think of a pixel as a square—or anything other than a point.

Alvy Ray Smith, 1995 http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf

Comments URL: https://news.ycombinator.com/item?id=43769959

Points: 30

# Comments: 29

    The "email is authentication" pattern
    https://news.ycombinator.com/item?id=41475218

The bug can pop up in any C program using stdio that assumes it's fine to do `fread` followed immediately by `fwrite`. The spec forbids this. To make matters more confusing, this behavior does _not_ seem to be in modern libc implementations. Or at least, it works on my machine. I bet modern implementations are able to be more sane about managing different buffers for reading and writing.

The original COMMAND.COM from MS-DOS probably did not have this problem, since at least in some versions it was written in assembly[2]. Even for a shell written in C, the fix is pretty easy: seek the file before switching between reading/writing.

The title of this post is confusing, since it clearly _is_ a bug somewhere. But I think the author was excited about possibly finding a bug in libc:

> Sitting down with a debugger, I could just see how the C run-time library (Open Watcom) could be fixed to avoid this problem.

[1] Here's DOSBox, for example: https://github.com/dosbox-staging/dosbox-staging/blob/main/s...

[2] MS-DOS 4.0: https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/CMD/C...

https://bellard.org/jslinux/vm.html?url=alpine-x86-xwin.cfg&...

(Warning: this will download 30+ MB)

After it starts up, right click, and then choose Browser - Dillo. There's no HTTPS support, but Google and httpbin.org work at least.

Contrary to this, since at least 2008[0], the POSIX standard (which is just paper not necessarily how real systems worked at that time) has said that "every day shall be accounted for by exactly 86400 seconds." That means that in modern systems using NTP, your Unix timestamps will be off from the expected number of TAI seconds. And yes, it means that a Unix timestamp _can repeat_ on a leap second day.

There's really no perfect way of doing things though. Should Unix time - an integer - represent the number of physical seconds since some epoch moment, or a packed encoding of a "date time" that can be quickly mapped to a calendar day? "The answer is obvious" say both sides simultaneously :^)

EDIT: I know DJB is calling out POSIX's choices in this article, but it seems like his "definition" does diverge from what the count actually meant to a lot of people.

[0] Also: "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...

I think the main issue with Monotone was the performance. Linus also hates databases and C++.

--

Hoare didn't come up with this idea either, but he did apply it to version control. He had potentially been influenced by his earlier work on distributed file systems and object systems. Here's his 1999 project making use of hashes: https://web.archive.org/web/20010420023937/venge.net/graydon...

He was in contact with Ian Clarke of Freenet fame (also 1999). There seems to have been a rise in distributed and encrypted communications around the time, as kragen mentions in his other post.

BitTorrent would also come to use hashes for identifying torrents in a tracker, and would come out in 2001, created by Bram Cohen, the author of the post here :)

In the linked thread, the users have a “working” device with software already installed, but the activation fails with a cryptic “Activation Error” without any reference to the fact that they must update.

Typically, Apple continues to allow activation on older OSes, as long as they were installed previously. I’ve intentionally kept some devices on older versions, and personally have never had a problem activating after a reset. But I suppose that’s only possible because Apple allowed it.

EDIT: I was wrong about the "Activation Error" not mentioning a software upgrade. It does mention it. But my point about Apple controlling access to the software still stands. It's something weird that Apple did specifically for iOS 9 and the iPhone 6s. Naturally, who really cares about one random version combination? I don't in this particular case, but the fact that Apple can control it is weird to me.

Even more concerning is that some users report that the device locked them out _even during normal use of the phone_: https://www.reddit.com/r/iphone/comments/acmytg/iphone_6s_pl...

Apple has already stopped supporting activation of certain versions of iOS[0]. Also, just as a user can request locking down a phone at any time, Apple could technically lock down your device when they see fit. They're not going to do that, but the fact that it's possible is a bit freaky.

Someday, far in the future, their activation servers will go down, and no unactivated Apple device will be usable. Already, it is not possible to set up a new device without an Internet connection. Hopefully the jailbreak community figures something out by then, or maybe Apple would release a tool...

[0] https://forums.macrumors.com/threads/apple-no-longer-activat...

https://web.archive.org/web/20021003235610/http://osdev.berl...

This "virtual 8086" mode is what was used for the VMM kernel of Windows 9x, and later the NTVDM system on 32-bit versions of Windows NT. I remember being able to run some DOS software on Windows XP (but it wasn't perfect).

But I also think the interest in things like io_uring in Linux reflect that people are open to asynchronous file IO, since the kernel is doing asynchronous work internally. To be honest, I don't know much about io_uring though - I haven't used it for anything serious.

There's no perfect choice (as always) -- After all, for extremely high-performance scenarios, people avoid the async nature of IO entirely, and dedicate a thread to busy-looping and polling for readiness. That's what DPDK does for networking. And I think for io_uring and other Linux disk interfaces have options to use polling internally.

As for threading vs. explicit yielding (e.g. coroutines), I’d say it’s a matter of taste. I generally prefer to see where code is going to yield. Something like gevent can make control flow confusing, since it’s unclear what will yield, and you need to implement explicit yielding for CPU-bound tasks anyway. Its green threads are based on greenlet, which are cooperative coroutines.

Cooperative multitasking was a big problem in operating systems, where you can’t tell whether other processes are looking for CPU time or not. But within your own code, you can control it however you want!

Is there a performance benefit to be had by managing the memory and paging yourself? Yes. But eventually you will also consider running processes next to your database, for logging, auditing, ingesting data, running backups, etc. Virtual memory across the whole system helps with that, especially if other people will be using your database in ways you can't predict. As for the efficiency of MMUs and the OS, seems like for almost all cases it's "satisfactory" enough[1].

[0] http://denninginstitute.com/pjd/PUBS/bvm.pdf

[1] From 1969! https://dl.acm.org/doi/pdf/10.1145/363626.363629