mananaysiempre

Guys that grew up with the 8-bit micros did write the spec—the first design drafts of the standard started circulating in 1988, version 1.0 came out in 1991. Given IBM’s primary role in the whole thing, even parents of such guys could’ve been involved.

The problem was, they had to sell their invention to other guys that had grown up with 8-bit micros and in the meantime had gotten very attached to their specific 8-bit encodings, so they had to make a lot of compromises: first 128 characters match ASCII; first 256 characters match Latin-1; alphabets encoded in order; codepoint-to-codepoint transcoding from any (reasonable) legacy encoding; throw out enough stuff to not need more than 2^16 characters. They were also racing against time, because in the meanwhile ISO was cooking up 10646, the Universal Character Set, built around ISO 2022’s teletype-inspired architecture of charset switching, and that only got killed because software vendors essentially declared a boycott and pointed to Unicode instead.

The result came out rather awkward as well as fairly expensive, and a lot of the promises needed to be broken afterwards anyway. But they’d have no users had they had done things differently. (Meanwhile, the UCS as initially conceived lacked such advanced operations as string equality.)

> TextEdit [...] was used as kind of a demo application of the text views IIRC. even came with source code, as did Chess by the way.

On the other side of the fence, WordPad initially came with source code as well, and was essentially a demo app for the rich edit control as well as the criminally underused text converters[1].

[1] https://www.malsmith.net/wincvt/

A popular refrain in gaming circles when Oblivion Remastered released was “it’s awesome if you have the hardware, but it’s Unreal so of course it runs like shit”. So it’s far from obvious that customer sentiment agrees with you. Having seen what Decima can do, I don’t think I agree that Unreal is the pinnacle of game tech either.

Live by the NDA, die (at least wrt education/mindshare) by the NDA. Seems fair.

Unladen Swallow died for lack of upstream interest.

PyPy lacks upstream interest, looked like it could have a shot after many years of development but recently NumPy removed support because they just couldn’t fathom how a non-dead project could be a couple of versions behind CPython.

Now the new JIT is dying because of what seems to be a lack of upstream interest. (The things TFA describes as being required are not unreasonable, but not realistic for a necessarily speculative long-running project without wild amounts of committed funding.)

I’m not optimistic.

“Draft International Standard”, but that doesn’t mean much unless you read how the ISO process works[1]. (It’s like writing “Advanced Encryption Standard” instead of “AES”—unhelpful beyond giving the broadest category to which the thing belongs, “a document” resp. “a cipher”.)

[1] https://www.iso.org/stages-and-resources-for-standards-devel...

Alternatively, let people cancel easily everywhere. If you think it’s worth the extra revenue to geofence easy cancellations, then—well, you do you, but you are making a business judgment that the additional development cost is justified. This is different from VAT/sales tax etc., where it is in fact impossible to comply everywhere without discriminating by jurisdiction.

No need for image gen to get this kind of problem; to me that skin look just reads as really aggressive denoising. And there is no escaping physics, a tiny high-res sensor will need a whole lot of denoising for this really challenging scene (meh lighting, strong backlight; the dark, shiny skin is probably also an issue but I’ve no experience there).

The only surprising part is how good the results are: there is no leftover color noise that I can see, the window doesn’t have any color fringing, the high-frequency detail of the table setting and the drapes hasn’t been destroyed, the small backlit hairs on the sides of the face of the girl in front haven’t been smeared over oil-painting style. It’s strange how one eyebrow (in the back) got completely obliterated while the other looks completely fine, and it’s even stranger how the texture of the collar (in front) is basically perfect on the left where it’s unobstructed but basically destroyed on the right where some hair escaping from the braids was in front of it, so perhaps there is some image-gen-adjacent stuff going on here.

The skin looks bad, don’t get me wrong. But the degree of badness seems fair for the situation, and as a whole the result has no business looking as good as it does to my 2016-camera-trained eye.

(Also, don’t photograph people with a wide-angle lens from up close, it’s always freaky at best—like here—and ugly at worst. Just don’t.)

It’s partly by design—the word senate shares its root with the word senex “old man” (whence also senile, etc.) because it’s literally a council of elders. That’s what the Roman one was and what the US constitution (among others) was attempting to emulate.

Partly, though, it’s a bit more interesting than that[1]. Wikipedia has an interesting chart[2] titled “Lifespan of each United States president”, which shows that in modern-ish times, the generation from which US presidents come is sticky: you get three presidents born ca. 1855, then one born ca. 1865, two ca. 1875, three from the late 1880s, four(!) from the 1910s (starting with “young” JFK), Carter/Reagan/Bush Sr. oscillate between the 1910s and 1920s, then again four from the 1940s (starting with “young” Clinton) only interrupted by “young” Obama (born 1961). (I could start my recounting earlier and it would still work.) Trump and Biden appear abnormal if you look at their ages, but if you look at their birth years instead they are simply a backslide, after Obama, to the generation of Clinton and Bush Jr.

What does appear true is that generations hold onto their power for longer and longer before the snap transition to the next eligible generation happens. Longer life expectancy due to better medical care seems like a perfectly satisfactory explanation for that.

[1] I first read about this idea a few years ago and I don’t remember where, so I’ll need to attempt my own explanation. Sorry.

[2] https://en.wikipedia.org/wiki/List_of_presidents_of_the_Unit...

An ASCII-friendly way to spell ℞, an R with a crossed right leg, shorthand for the Latin singular imperative recipe! “take (the following)!”, which is the conventional start of a prescription; by extension, something necessitating a prescription to buy.

Depending on the effort you’re willing to put in, you don’t have to: gzip has a specific provision for concatenated files and tar is a flat array of (file) records each followed by file data, terminated by a sentinel record, so what you need to do is to trim the sentinel off the first tar.gz and then append the second one as is. I don’t know of a ready-made tool that would be able to chop off a gzip file’s last 512 uncompressed bytes without recompressing it in full, but it ought to be possible.

> Rust's critical invention was "what if we modeled heap ownership and borrowing with linear types".

Rust did not invent this (and I don’t believe Rust’s creators claim it did), see e.g. “Linear regions are all you need”[1] (ESOP 2006) and in general the work around Cyclone[2] in the 2000s. There was also Mezzo[3], which did very similar things but described them in a different style (effects instead of affine types), and a fair bit of work that went beyond what Rust can currently express (e.g. fractional capabilities). What Rust did is succeed at bringing a conservative subset of this academic work to production—which is not a small deal, mind you; others (including the Cyclone team) tried and failed.

[1] https://link.springer.com/chapter/10.1007/11693024_2, https://www.cs.cornell.edu/people/fluet/research/substruct-r...

[2] https://gallium.inria.fr/~fpottier/slides/fpottier-2007-05-l...

[3] https://protz.github.io/mezzo/

None of the sequelae of that have really improved since then, at least as far as the first world is concerned. The foundations of universal surveillance were being laid down, but it wasn’t yet feasible. Police (transport security, border patrol, potato, pot-ah-to) ruffling through your belongings had not yet been normalized. You could transact with cash. People largely still sort of believed that talking to your political opponents would lead to better outcomes than making them comply under threat of government violence or unemployment.

(Plenty of things sucked, don’t get me wrong, it’s just that a lot of the fallout from the “war on terror” was still in the upper atmosphere.)

Here’s a larger stash: https://github.com/timvieira/justified-variables (via https://news.ycombinator.com/item?id=31138306).

Judging by the lowercase “m” it’s the 8x16 variation[1] and not the 9x16 one you linked, but otherwise yes, looks like the plain old VGA font? (Incorrectly displayed, as the site points out: the VGA didn’t have square pixels in either of those modes.) The site uses (AVIF) images in place of text, but it’s like 15 minutes to write a program that typesets an ASCII file in a given monospace bitmap font and writes out the result as say a PPM (and I’m sure ImageMagick can do it if you’d rather dig through docs than program), so this doesn’t seem to require any further explanation?

[1] https://int10h.org/oldschool-pc-fonts/fontlist/font?ibm_vga_...

Muratori et al. like comparing speeds to (single-core) memory bandwidth (dozens of GB/s) and that’s a reasonable upper bound, but generally it seems to me that, unless you operate on huge elements and don’t do very much with them, you won’t get within an order of magnitude of it. Even if you think about RAM exclusively, the headline numbers are for sequential reads and things will slow down dramatically if you actually perform random accesses (IIRC, DDR5 is about as slow as DDR4 there in terms of physical time units, so much slower in terms of bus cycles). Meanwhile, in a real situation, you’re going to be bound by compute long before that.

And I think you’re being unfair labelling my couple of examples “some arbitrary algorithm[s]”: my choice was indeed arbitrary, but it’s also immaterial. The general setup would be that you’re processing elements in a loop and that your iterations are serialized (as they usually more or less are before you get around to optimization). A loop body of even three lines of C is likely to have a latency of 5–10 cycles or so, and you’re running on a core clocked somewhere from 5 GHz (desktop) to half that (server). So the best you should expect is ~500 MB/s if your elements are bytes, ~2 GB/s if they’re 32-bit integers, etc. For very simple tasks (that are also somehow not susceptible to vectorization), it is possible to not lose this order of magnitude and get down to almost 1 cycle/element in scalar code, but that requires heroic effort[1].

[1] https://github.com/powturbo/Turbo-Histogram

> I/O is inherently very slow compared to computation.

Not anymore, no. Your SSD, before any caching, does gigabytes per second of sequential reads. For any bytewise processing, except the most trivial of tasks, you’ll struggle to get above a few hundred megabytes per second with scalar (native) code. To actually keep up with a modern SSD, you’ll virtually always have to hand-write SIMD loops, minimize the number of syscalls with tools like io_uring, or possibly be smart about distributing tasks across cores without ruining the access pattern.

For instance, simdjson is famously fast but I don’t believe it can keep up with say a high-end PCIe Gen 4 SSD like a Samsung 990 PRO, let alone the latest-and-greatest (and, literally, hottest) Gen 5 stuff. And I know of no Unicode normalizer that would be able to do a gigabyte per second on general inputs (not ASCII, not Latin-1) simply because the latency for dependent lookup table accesses is absolute murder.

> Don’t think TeX ever did that, that was a “simple” Pascal program.

Not exactly the entire process image, no, but essentially all of its data in a single chunk. It’s a peculiar Pascal program because it bypasses basically all of Pascal’s typing, records, etc., and instead builds its own from a set of (WEB) macros on top of a giant untyped array. Quoth Knuth in TeX: The Program §115:

> The dynamic storage requirements of TeX are handled by providing a large array mem in which consecutive blocks of words are used as nodes by the TeX routines. Pointer variables are indices into this array [...].

There are a few more areas designated for specific purposes, but at the end of the day (§1302) it works out about the way you’d expect:

  procedure store_fmt_file;
  [...] begin ⟨ If dumping is not allowed, abort 1304 ⟩
  ⟨ Create the format ident, open the format file, and inform the user that dumping has begun 1328 ⟩;
  ⟨ Dump constants for consistency check 1307 ⟩;
  ⟨ Dump the string pool 1309 ⟩;
  ⟨ Dump the dynamic memory 1311 ⟩;
  ⟨ Dump the table of equivalents 1313 ⟩;
  ⟨ Dump the font information 1320 ⟩;
  ⟨ Dump the hyphenation tables 1324 ⟩;
  ⟨ Dump a couple more things and the closing check word 1326 ⟩;
  ⟨ Close the format file 1329 ⟩;
  end;

Related: previous article in the series, https://news.ycombinator.com/item?id=49308685 (103 points, 47 comments)

Some time ago, I’ve come across an Asahi patch to I think Pipewire that tied system volume to a Macbook-specific loudness compensation filter, but I couldn’t figure out how to actually make use of it outside of their environment.

Not Black Mirror, 2013 vintage 4chan.

Kinda. There are also the 32-bit bits on top, not (AFAIU) that different from their NT4 counterparts, such as the shell, COM/OLE2, TrueType, OpenGL, etc.; the core Win16 stuff (KERNEL/USER), which the Win32 layer thunks down to and which in turn invokes DOS routines; and the VxDs that intercept various pieces of DOS/BIOS and replace them with 32-bit code (“32-bit disk access”, “32-bit file access”, etc.). Only the first of those is new to Win95.

I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.

Likely 32-bit file access[1] and the caching it included? The arrangement where Windows calls 16-bit MS-DOS entry points to do I/O (including from 32-bit programs) to respect preexisting DOS drivers, network redirectors, etc., but then in 3.11+ intercepts those 16-bit entry points (including when used from 16-bit DOS programs) to use a different 32-bit I/O stack when possible... it wasn’t intuitive back then and I don’t think it any more intuitive now.

[1] https://en.wikipedia.org/wiki/Microsoft_32-bit_file_access

It’s not correct to say it was “really 16-bit”, no, but as Unauthorized Windows 95[1] eloquently demonstrates, neither was Windows 3.1 or 3.11, especially with Win32s, and Windows 95 was much more of a direct descendant of that environment that the marketing implied.

And on a more personal note, reading the descriptions of the mixed 16/32-bit architecture always makes me feel conflicted.

On one hand, the technical achievement is somewhere between genius and madness and I’m not sure on which side—not only did they ship a hypervisor in a consumer OS in 1987 (as “Windows/386”), they also flipped a live MS-DOS with an unknown complement of drivers and binary patches from running on live hardware to running inside a(n admittedly unsafe) VM, then proceeded to use those drivers and respect the patches including in applications written for Windows and not MS-DOS. I don’t think I have the sort of arrogance it takes to even think of attempting such acrobatics.

On the other hand, I was there, I grew up on computers that ran Windows 95 and 98, and I remember just how much better Windows 2000 was, how much more comfortable it was to not worry about the system crashing on you every half an hour. Perhaps 95 was a magnificent technical achievement, but it certainly didn’t feel like one to the user. And thus I continue to feel conflicted.

There’s also the question of why, exactly, was NT too heavy to run on contemporary consumer machines. You could say it was bloated, but so was Windows 95: the multiple 16/32-bit mode transitions it took to write to a file certainly weren’t free; and don’t get me started[2] about shipping a COM-based shell, realizing it was too heavy for the minimum RAM requirement, and solving that by shipping a second, stripped-down copy of COM then live-swapping the real one in its place as soon as the fake one became insufficient.

[1] https://www.os2museum.com/wp/book-review-unauthorized-window...

[2] https://devblogs.microsoft.com/oldnewthing/20040705-00/?p=38...

> [JPEG XL can] display much larger images than AVIF can

Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.

Nixpkgs has 11k open PRs at the moment (a lot of them routine version bumps and such), so no. But then Nixpkgs isn’t a piece of software in the conventional sense: the monorepo does contain a few of those, but most of it is a giant collection of basically-independent build scripts.

Less of a commodity at this point than a few years ago, what with Minio immolating itself to be reborn as, excuse my French, AIStor.

Which is not to say that TFA’s approach is invalid or uninteresting, but the mechanics of how “an S3” works are really obscure to those of us not in the know.

“Software forge” is an established[1] term by this point: a piece of software providing a full set of features for collaborative development, usually at least code hosting with a web interface, tickets, and webpage hosting, and these days often also code review and integrated CI or at least the possibility of integrating CI. It’s admittedly squishy but in the same way “IDE” is squishy, which is to say it’s still well-defined enough to be useful.

[1] https://en.wikipedia.org/wiki/Forge_(software)

For me (not GP), this lives in the recreational-mathematics part of my brain rather than the useful-things part of my brain: John Conway called this invention of his the “Doomsday rule”[1] and I suppose the memorable name helps. But I admit having opened Calendrical Calculations[2] once or twice as well, so perhaps my idea of fun is skewed.

[1] https://en.wikipedia.org/wiki/Doomsday_rule

[2] https://en.wikipedia.org/wiki/Calendrical_Calculations