thristian

See https://wiki.debian.org/Teams/RustPackaging/Policy

Yes, it's heavily automated.

Debian effectively does this. It doesn't actually implement the crates.io API, but when building a Rust package they tell cargo "look in this directory for dependencies, don't talk to the network".

As I understand it, the process goes something like this:

- Debian wants to package a Rust tool

- They examine the tool's Cargo.toml file to determine its immediate dependencies

- Those Rust dependencies are converted into Debian package names

- Generate a Debian package definition that lists those dependencies under "Build-Depends"

- When building the Debian package in an isolated environment, Build-Depends packages are installed, providing things like `rustc` and `cargo` as well as putting the dependencies' source into the "local dependencies" directory

- Cargo runs, configured to only look in the "local dependencies" directory for dependencies

- the resulting binary is scooped up and packaged

The page with the download¹ has a long essay about the benefits of WordStar. An example:

> WordPerfect requires that I decide whether I want to cut or copy a block, then immediately mark the beginning of the block, then immediately mark the end of the block, then immediately position the cursor at where I want the block to go, then immediately move the block, and then find my way back to the place where I was originally working. From the moment I decide I might, perhaps, want to do something with a block of text to the moment I actually finish that operation, WordPerfect is in control, dictating what I must do.

> WordStar, with its long-hand-page metaphor, says, hey, do whatever you want whenever you want to. This is a good spot to mark the beginning of a block? Fine. What would you like to do next? Deal with the block? Continue writing? Use the thesaurus?

> After another half hour of writing, I can say, ah hah!, this is where I want to end that block. And two hours later I can say, and this is where that block should go.

¹: https://sfwriter.com/wordstar.htm

Apparently WordStar has not been released for free by the owners (as Word 5.5 for DOS was), it's just been unilaterally packaged by a fan hoping not to get in trouble.

> That, I’m afraid, is because ASCII was based not on modern computer keyboards but on the shifted positions of a Remington No. 2 mechanical typewriter – whose shifted layout was the closest compromise we could find as a standard at the time, I imagine.

According to Wikipedia¹, American typewriters were pretty consistent with keyboard layout until the IBM Selectric electric typewriter. Apparently "small" characters (like apostrophe, double-quote, underscore, and hyphen) should be typed with less pressure to avoid damaging the platen, and IBM decided the Selectric could be simpler if those symbols were grouped on dedicated keys instead of sharing keys with "high pressure" symbols, so they shuffled the symbols around a bit, resulting in a layout that would look very familiar to a modern PC user.

Because IBM electric typewriters were so widely used (at least in English speaking countries), any computer company that wanted to sell to businesses wanted a Selectric-style layout, including the IBM PC.

Meanwhile, in other countries where typewriters in general weren't so popular or useful, the earliest computers had ASCII-style punctuation layout for simplicity, and later computers didn't have any pressing need to change, so they stuck with it. Japanese keyboards, for example, are still ASCII-style to this day.

¹: https://en.wikipedia.org/wiki/IBM_Selectric#Keyboard_layout

It's really difficult. Unlike floppy disks, where you tell the drive to seek and get back raw magnetic pulses (so you can produce raw flux images), or hard disks where you tell the drive to read an arbitrary sector and get a blob of data (so you can produce sector-level images), the protocol for talking to a CD ROM involves asking for track/sector addresses, which means you have to trust the drive to interpret all the track metadata and error-correction for you - you generally can't just dump the "raw" data and do the interpretation yourself.

That's why the most robust CD image format is the BIN/CUE format. The BIN file contains all the sectors the drive allows us to read, the CUE file contains the disc metadata as interpreted for us by the drive firmware.

There are some drives which support extra "raw read" commands, but they're incredibly rare and consequently in great demand by CD preservation projects like redump.org.

Some people have used the contents of BIN/CUE data to reconstruct what should actually be on the disk, but that's not quite the same thing. Here's a great explanation of the CD structure in all its complexity:

https://github.com/higan-emu/emulation-articles/tree/master/...

Someone's trying to reverse-engineer the IWM, but they have not yet quite succeeded: https://www.applefritter.com/content/iwm-reverse-engineering

Lots of people in artistic/creative domains are basically "AI vegan" these days - a "definitely not AI powered, definitely not powering AI" badge would be a minimum requirement there.

The 6809 is one of the architectures from the era of the 6502, 8051, and Z80. Specifically, it's Motorola's response to the 6502 eating the 6800's lunch, the same way the 8086 was Intel's response to the Z80 eating the 8080's lunch.

I'm guessing they picked the 6809 because it's a lot more friendly to C than those other architectures.

Ah,a classic dual-pane orthodox file manager for macOS!

Betteridge's law of headlines says "no".

Being used to the world of software, where only ignorant and amateurish systems don't handle the 400-year rule in the Gregorian calendar, it's eye-opening to find out that people are paying thousands of dollars for a time-keeping device that needs the date to be manually fixed five times a year.

The Super Game Boy cart is basically this. The cartridge contains actual Game Boy hardware, wired up to render to a frame buffer, and 60 times per second it's copied to the SNES VRAM.

The trick is that the Game Boy display is smaller than the SNES display, so it doesn't have to transfer a complete frame, and so it can be completed within the vertical blanking interval.

Apparently the timing is so close that it's not possible to transfer palette information alongside the video, just black-and-white, which is why there was never a Super Game Boy Color.

Hold down Alt and type 3 on the numeric keypad, I think.

In Windows, you can type characters in the Latin1 character set by holding down Alt, then typing a zero on the numeric keypad, then the code you want, such as Alt+0233 for "é". The leading zero disambiguates Latin1 characters from the traditional DOS character set, so you'd have to type Alt+130 to get the same character that way.

As far as I know, most information about the 6502 instruction set comes in two forms:

- emulators/simulators/FPGA code

- books, data sheets, OCR'd PDFs of books and data sheets, text files copy/pasted from PDFs or retyped from books and data sheets

Code is likely to be heavily tested, but it makes extracting high-level information about the instruction set very difficult.

Data is easy to analyse and synthesise, but since it's described in prose there's no easy way to test or validate it - if somebody in 1984 made a typo that a particular instruction took 3 cycles instead of 2, and that error was copy/pasted and made its way into half the "6502 instruction set" websites online, how would you know? How would you detect it?

Using SQL to enforce constraints and validation gives me confidence that there aren't a bunch of typos and copy/paste errors in this data. In addition, being able to express special cases like "read-modify-write instructions applying to the accumulator do not pay the three cycle penalty" in code rather than in prose makes it more likely they will be applied correctly. Lastly, since the result is an SQL database, it can be pretty easily formatted to resemble any book or data sheet you like for simplified visual verification against book/data sheet sources.

The original 6502 had exactly 151 opcodes, the same as the number of pokémon in the original Pokémon games.

bsnes' creator collected all the NTSC cartridges, I believe (USA and Japan, even the rare ones that were Japan-only special editions) but I don't think they managed to get a full PAL set.

All the enhancement chips used in officially licensed games were collected, decapped, and dumped via an electron microscope. Yes, even the ones only used by a single Shougi game each. :)

Only in bash and possibly other shells that extend the POSIX syntax, not in the basic POSIX standard.

I have pushed an update which should fix this issue.

Huh. The syntax diagram in the documentation[1] suggests this is possible, but the documentation on foreign keys[2] does not mention that syntax, or how it's interpreted.

I think I can fix this.

[1]: https://sqlite.org/syntax/foreign-key-clause.html

[2]: https://sqlite.org/foreignkeys.html

Thanks for looking into it!

It turns out that 3.37.0 is the version that added the `table_list` pragma. I've added that requirement to the README.

So far as I can tell, GraphViz does not allow you to specify a paper size. However, if you render to SVG, you can open the result in Inkscape and rearrange things fairly easily. That's not quite as convenient as having it done automatically, but GraphViz can struggle with laying out a complex schema even when assuming infinite space - some amount of hand-tweaking is going to be necessary regardless.

I have not considered outputting to MermaidJS, but (from a quick glance at that documentation) it looks like the same "SQL template" technique should work. Actually doing it is left as an exercise for the reader. :)

Somebody upthread[1] also made a GitHub mirror. I appreciate that different people have different comfort-levels with the centralisation of services like GitHub, but luckily it's really easy for people to copy a Git repo to a host they're more comfortable with, like GitHub or SourceHut or even making a local clone.

[1]: https://news.ycombinator.com/item?id=39800533

It's such a small script, most of the repository is documentation, so I expected (hoped) it would get copied to a lot of places. It's fine. :)

I have not seen that, and that's very puzzling.

What output do you get when you run these commands?

    $ sqlite3 --version
    -- Loading resources from /home/st/.sqliterc
    3.45.1 2024-01-30 16:01:20 e876e51a0ed5c5b3126f52e532044363a014bc594cfefa87ffb5b82257ccalt1 (64-bit)
    $ sqlite3 :memory: -init /dev/null "select * from pragma_table_list();"
    -- Loading resources from /dev/null
    main|sqlite_schema|table|5|0|0
    temp|sqlite_temp_schema|table|5|0|0

EDIT: The ability to use pragmas as table-valued functions was added in version 3.16.0[1], but the table_list pragma was first added in 3.37.0[2], which is newer than your sqlite3 version.

[1]: https://sqlite.org/changes.html#version_3_16_0

[2]: https://sqlite.org/changes.html#version_3_37_0

Years ago I wrote something similar for PostgreSQL. Unlike SQLite, it supports[1] the much richer "information_schema" database schema that's defined by the SQL standard. As long as you can figure out how it represents tables, columns, and primary and foreign keys, it shouldn't be too difficult to adapt this SQL query to fit. After all, reshaping relational data to extract the information you need is what SQL is for.

[1]: https://www.postgresql.org/docs/current/information-schema.h...

If this were commonly-used code at the core of a project, I would definitely agree. However, this is the kind of thing that gets stuck into a CI pipeline and not looked at for months or years, and it's written in two languages (GraphViz and very SQLite-specific SQL) that probably most people don't use regularly. I gave it the comments I'll wish it had the next time I come back to it, to figure out how it works.

Author here, I didn't bother submitting this to HN because I figured it would be too niche and trivial to get much attention. Evidently I was wrong!