mikepavone

This is a small point, but calling the 33-byte unit a sector in CDDA is a bit misleading and probably incorrect for the quantity being labeled. This is a channel data frame and contains 24-bytes of audio data, 1 byte of subcode data (except for the channel data frames that have sync symbols instead) and the rest is error correction. This is the smallest grouping of data in CDDA, but it's not really an individually addressable unit.

98 of these channel data frames make up a timecode frame which represents 1/75th of a second of audio and has 2352 audio data bytes, 96 subcode bytes (2 frames have sync codes instead) with the remainder being sync and error correction. Timecode frames are addressable (via the timecodes embedded in the subcode data) and are the unit referred to in the TOC. This is probably what's being called a sector here. Notably, a CD-ROM sector corresponds 1:1 with a timecode frame.

Note: Red book actually just confusingly calls both of these things frames and does not use the terms "channel data frame" or "timecode frame"

> The Xbox 360 doubled down on this while the PS3 tried to do clever things with an innovative architecture.

I don't think this is really an accurate description of the 360 hardware. The CPU was much more conventional than the PS3, but still custom (derived from the PPE in the cell, but has an extended version of VMX extension). The GPU was the first to use a unified shader architecture. Unified memory was also fairly novel in the context of a high performance 3D game machine. The use of eDRAM for the framebuffer is not novel (the Gamecube's Flipper GPU had this previously), but also wasn't something you generally saw in off-the-shelf designs. Meanwhile the PS3 had an actual off the shelf GPU.

These days all the consoles have unified shaders and memory, but I think that just speaks to the success of what the 360 pioneered.

Since then, consoles have gotten a lot closer to commodity hardware of course. They're custom parts (well except the original Switch I guess), but the changes from the off the shelf stuff are a lot smaller.

> I think the problem in a nutshell is that it's not trivial(?) to build an executable on a modern Linux distro that links against an old glibc version number (and if it is trivial then it needs to be better communicated).

I wouldn't say it's trivial, but it's not rocket science either. Basically there are two main approaches. One is to just build inside a chroot or container with a sufficiently old distro inside. This is generally the path of least resistance because your build system doesn't really have to have any awareness of what's going on. You just build normally inside the chroot/container. The main downsides with this approach are that it's kind of wasteful (you have a whole distro's filesystem) and if you want to use a newer compiler than what the old distro in question shipped with you generally have to build it yourself inside said chroot/container.

The other main approach is to use a sysroot. gcc and clang both take an optional --sysroot parameter which is an alternative root for header and library lookups. This lets you use a compiler on the normal host, but old headers and libs. You can also bake this parameter in when compiling gcc (and also I assume clang, but less sure there) if you want a dedicated cross-toolchain.

> It's the exception which is why it's talked about the most.

It's definitely not the only exception. libgl is another obvious example since different GPUs need different userland code. I would be surprised if there there had never been compat regressions in those.

The PEP-600 [0] Rationale section touches on this a bit. The basic problem is that there are things beyond glibc that would be nice to use from the environment for a number of reasons (security updates, avoiding clashes between multiple wheels that depend on the same lib, etc.), but since most libs outside of glibc and libstdc++ don't really have an ABI policy and the distros don't necessarily have a policy on what libraries are guaranteed to be present you sort of have to guess and hope for the best. While the initial list in PEP-513 [1] was a pretty good guess, one of the libraries chosen (libcrypt.so.1) got dropped in Fedora 30 and replaced with an ABI incompatible version. Crypto libraries are an example of something that's actually important to keep up to date so I find this rather unfortunate.

[0] https://peps.python.org/pep-0600/

[1] https://peps.python.org/pep-0513/

So of the 3 glibc issues they link

- one is about the format of symbol information in the actual ELF binaries which is only an issue if you are not using the standard libc functions for looking up symbols for some strange reason

- one is an issue that impacts targeting a lower version of glibc from a higher one which is a configuration that was never supported (though usually fails more loudly)

- the last one is a security policy change which is legitimately an ABI break, but mostly impacts programs that have their execstack flags set incorrectly

glibc actually goes to a fair bit of effort to be compatible with old binaries unlike most of the rest of the Linux userspace. The binaries I built for my side project back in 2015 (BlastEm 0.3.0) still work fine on modern Linux and they dynamically link against glibc. This is just a hobby project, not a piece of professional software, and a build from before this JangaFX company even existed works fine.

I find it really bizarre when people talk about Linux binary compat and then complain entirely about glibc rather than the sort of problems that the manylinux project has had to deal with. glibc is one of the few parts of userspace you can depend on. Yes, setting up your toolchain to build against an old glibc on a modern distro is a bit annoying. Sure, if you do something sufficiently weird you might find yourself outside what glibc considers part of their stable ABI. But from where I sit, it works pretty well.

My general feeling is that folks tend to have somewhat unreliable memories about how early certain things got cheap. Catalogs are not perfect, but they don't change over time. That said, I managed to find a Computer Shopper from August 1992 on the Internet Archive [0]. There definitely are some systems in there advertised at the $1K price point with HD and monitor (though generally no sound card), but also a lot of sellers with nothing that cheap for a complete system.

Not sure what the proper conclusion is about how competitive the pricing of the 600 was from that, but I think the catalog does reinforce how much further in the hole they were a bit higher up the price chart. If you wanted to spend a bit more, the only 1st party offering from Commodore until the fall of 1992 was the Amiga 3000. Not sure what they were charging for one of those at the time, but apart from the builtin SCSI I don't think it compares very favorably with a 386DX with SVGA and those weren't all that expensive by then. The 4000 did launch a little after this catalog, but it was priced much higher than the 486 systems that were already on the market.

[0] https://archive.org/details/computer-shopper-august-1992/

> By the time you added a monitor and a hard drive to get the system you really wanted, it cost closer to $1,000. At that price, you could get an off-brand PC with a VGA monitor.

So I decided to check some prices in 1992 computer catalogs and I'm not sure this is really true. Looking at the Tandy catalog[0], you could get a Tandy 1000 RLX with a 10 MHz 286, 512k of RAM, VGA and a monitor for $1K, but it didn't come with a hard drive at that price. The same catalog also lists a Tandy 1000 RL with a 9.5 MHz 8086, 512k of RAM and CGA/Tandy graphics for $500 without monitor. I think the 600 actually fairs pretty well against that machine.

Looking at a Sears catalog from 1992, they have a Packard Bell 386SX with 1MB of RAM and a 40MB HD for $1100, but without a monitor. The cheapest monitor option on that page was another $290.

Obviously two random catalogs doesn't give you comprehensive pricing data, but at least from this quick look it does seem like the 600 was reasonably competitive at the $500 price point it was sold at.

Seems to me the bigger problems were higher up the product line. Not having a real response to the rise of VGA (first introduced 1987) until October 1992 was a huge miss.

[0] https://www.radioshackcatalogs.com/flipbook/c1992_rsc-23.htm...

[1] https://christmas.musetechnical.com/ShowCatalogPage/1992-Sea...

> is this actually useful without a cartridge slot?

It has 2 of them actually. One standard one on the back and an internal one that I think doesn't use the standard connector that is intended for hardware expansion. Despite what the product page says, the internal slot is mapped to slot 2 and not slot 1 in the MSX mapping system, so it doesn't conflict with the external cartridge slot.

That said, most computers of this era including the MSX had a fair bit of software released on cassette tape as well. There were also disk drives and software released on disk as well.

Looking at some of the more famous games for the system: Metal Gear was released on cartridge, but Snatcher was released on floppy disk with an expansion cartridge that contained extra RAM and a sound chip. It seems this system has support for that expansion builtin though.

If you like the PDP11 instruction set, then you'll probably enjoy 68000 as well. It drew a lot of inspiration from the former. You lose the "deferred" addressing modes (though the 68020 adds something similar), but gain access to a few other useful ones. Conveniently it was used in a lot of consumer devices (Mac, Amiga, Sega Genesis, etc.)

Yeah. If you want to teach someone to implement a CPU, then the sort of simplicity the 6502 brings to the table is useful, but it's definitely not the most straightforward CPU to write code for.

The 68000 instruction set is very C-like (probably because it draws a lot of inspiration from the PDP-11 which was C's first target). Implementing it sucks (I know from experience) because the ISA is on the large side and all the little pragmatic exceptions add up. But because these exceptions are fairly pragmatic, they're not really a big issue when writing code.

For those unaware, this was probably posted today because the origin of Lyme disease came up in RFK, Jr.'s Senate confirmation hearings today. He was asked if he had indeed claimed that "Lyme disease is a highly likely militarily engineered bioweapon" and he responded that he "probably did say that".

In particular, it has reporting on the chain back to Exxon and that the FBI is investigating the PR firm involved. The original CitizenLab article is more thorough, but only identifies the hack-for-hire group and the Indian company it operates out of.

For what it's worth, the existing Genesis/Mega Drive titles here generally contain the actual ROM. It's generally the cheapest way to get a legitimate copy of these games for use in an emulator. I realize a lot of folks probably don't care about that, but it's a good option for those that do.

If you mean in the literal sense that we will still have elections, then sure. But Hungary is a great example of why getting rid of elections is not necessary. You just need to stack the deck so it's almost impossible for your opponents to win.

Now I certainly don't know what's going to happen in the next 4 years with any certainty, but Trump was not exactly a champion of democratic norms the last time and there will be far less to restrain him now. Those who opposed him in the GOP have been pushed out and the judiciary is far more friendly. Many of those that own or control platforms and news publications were either eagerly cheering Trump on or signaling they would be more deferential now.

We have a much longer history as a democracy than democratic backsliders like Hungary so I don't think it's a given we're destined for the same fate, but I think the risk is a lot more than zero.

I am very unfamiliar with the protocol, but my impression from a little reading is that the sharing computer broadcasts and the receiver listens. This appears to be for some CUPS specific browsing/discovery protocol rather than mDNS/DNS-SD (cups-browsed supports adding printers discovered that way but depends on avahi to handle the mDNS part).

EDIT: Here's a description of the protocol in question: https://opensource.apple.com/source/cups/cups-327/cups/doc/h...

cupsd is configured to listen locally, but cups-browsed has to listen on the network to do its job (network printer auto-discovery)

I believe it's implementing DNS-SD for network printer auto-discovery. I'm not terribly familiar with DNS-SD, but given that normal DNS is UDP based it would be unsurprising for DNS-SD to also use UDP.

On my Ubuntu 22.04 machine, cupsd itself is only listening on localhost, but cups-browsed (which is what has the vulnerability here) is listening on 0.0.0.0

> An important non-obvious detail for AMD is that they (at least in the past, I assume for this as well) have kept the instruction timings similar from generation to generation of consoles.

What? The Jaguar-based CPU in the PS4 has both a much lower clock and substantially lower IPC than the Zen 2 based one in the PS5. The timings are not remotely the same and the micro-architectures are quite different. Jaguar was an evolution of the Bobcat core which was AMD's answer to the Intel Atom at the time (i.e. low cost and low-power, though it was at least an out-of-order core unlike contemporary Atoms).

Going from GCN to RDNA on the GPU side is also a pretty significant architectural change, though definitely much less than the going from AMD to Intel would be.

There's also this open source design: https://gitlab.com/doragasu/sms-sl2map

It doesn't handle all the features of the standard mapper so not compatible with all games, but it's designed to be cheap to manufacture. Unfortunately I don't think anyone is selling these so you'll need to take the files to a PCBA house (or get bare PCBs manufactured and do assembly yourself)

While the Panthor kernel driver itself is open source, it seems to require this firmware [0] which doesn't look very open source to me.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

> Your only option there is to destroy a Monopoly or After Burner.

Not sure what you mean. krikzz sells a Master Everdrive if you want something suitable for multiple games. If you want a single game cartridge for a homebrew release, raphnet has you covered.

The one exception is if you have a Japanese Master System (or Mark III). These have a different cartridge connector that's shared with the SG-1000 and SC-3000 and flash carts are harder to find. You may be able to use a western SMS flash cart with a passive adapter though

> Meet and Zoom–my understanding is video bitrates for those services are lower than for e.g. Netflix

For a given quality, bitrate will generally be higher in RTC apps (though quality may be lower in general depending on the context and network conditions obviously) because of tradeoffs between encoding latency and efficiency. However, RTC apps generally already try to underutilize links because queuing is bad for latency and latency matters a lot for the RTC case.

An audio CD is mostly arranged like a single continuous recording. Tracks are added on top of this via the Q subcode channel that gives information about the current location and the ToC stored in the lead-in area (also using the Q subcode channel). In the ToC, each track will have one more indexes that points at a specific location on the disc by minute, second and "frame" (represents 1/75 of a second, basically a sector).

If a CD is properly following the Red Book standard, index 0 will point to a 2 second pre-gap of silentce and index 1 will point to the actual start of audio of the track (additional indices are allowed, but not common). The purpose of the pregap is to make life easier for less sophisticated players that aren't able to seek to a precise frame on the disc. They just have to be able to hit a 150 frame region. However, just because the standard says the pregap is supposed to be 2 seconds and silent doesn't mean it actually has to be. Players generally don't care and by the time the format was popular, even inexpensive players could seek precisely. This allows you to stick audio data before a track that will be skipped by the player when it's trying to seek to that track. If you stick it before track 01, it will be skipped even when just playing the disc through unless you rewind.

That's about 160 ms of audio per packet. That's a lot of latency to add before you even hit the network

Only the T34C is a turboprop. It appears Anders had a T34A which is equipped with a piston engine.

They turned on native IPv6 end of last year, at least in some areas (including Berkeley where I live). You wouldn't know it from their help pages, but there are some post in the forum to that effect.

I love my Bolt, but it's not a sedan. That said, it's not terribly surprising GM is not interested in making an electric sedan given that it's been declining in popularity over time. Ford isn't even making any sedans at all apart from the Mustang.

> INSTALL.md [0] recommends passing -DWITH_XC_ALL in the Build Steps section.

You're right, I missed it there. Silly me for assuming that all of the recommended CMake flags would be specified in the section titled "Recommended CMake Build Parameters"