It's a pity that libraries have to license the ebooks and audiobooks at high rates and keep re-renting the same titles in order to lend them out instead of being able to just buy them once.

On the Other Hand....

Libraries and archives try to have it both ways. Most of them charge "copying" or licensing fees and require you to sign contracts that prohibit you from further or unapproved re-use of even public-domain materials in their special collections. Even for things they have already digitized and even for things they never owned copyright for. Because they want to control how the items in their collections are used as if they did own copyright (albeit under contract law since they own no copyright in those public domain materials) in order to make money for the library / archive.

"Wahhh wahhh wahhh," publishers do the same to them that they do to others.

High-level languages are also unnecessarily redundant. We *could* just code in 0s and 1s. But unnecessary does not mean less practical. Yes, I usually do indent between the curly braces for readability. But editors and IDEs really don't reinterpret curly braces as completely different characters (square brackets for example), or silently change curly braces to 4, 2, or 8 square brackets, or multiple square brackets to curly braces, or treat them as unimportant and interchangeable. And when I'm refactoring, the editor doesn't suddenly just remove a bunch of curly braces throughout my code so I can no longer tell what the logic flow should have been. That sort of stuff seems to happen on a regular basis with indentation on various editors and IDEs, especially when using code from multiple contributors who are using different setups. If there weren't so many different ways of treating tabs/spaces already in wide use when Python came along, the choice to use indentation for logic probably would have been ok. But given the pre-existing state of how tabs/spaces have mostly been treated as style/readability decorations that can be adjusted willy-nilly by the editor/IDE, the choice to define logical blocks only with indentation in Python was a poor choice that causes unnecessary headaches on a regular basis.

Literally. Now if they would also use curly braces instead of indentation for logical blocks, it would finally be a language worth using. Messed-up indentation is constantly screwing up logic when code is merged or refactored, and editors/IDEs that auto-"fix" indentation silently mess up program logic.

Never have I ever seen such nonsense in hiring processes as is happening right now in the tech industry.

All of my tech jobs in the past basically consisted of a screening interview, then a more in-depth interview on site (often with multiple people or teams throughout the visit/day), then get an offer (or not) and accept the offer (or not). Quick, straightforward, reasonable.

Now many of the companies complaining they can't get qualified workers have a "required skills" list a mile long with no understanding that equivalent/similar skills transfer from one language/framework/tool/domain to another. Often you can only apply through an automated system that mangles the data from your resume before dumping it into some hiring database. Some companies sit on your resume for weeks or months before even contacting you, then drag out the process to several interviews on different days, plus make you do "homework" or take an online coding test by a third-party company with a horrible interface. Some have you interview on camera instead of a real person, or judge and grade you via "AI." There are often rounds and rounds of interviews over an extended period of time, dragging on weeks or months.

The companies show a complete lack of respect for the candidates and their time, and often in the process squash any enthusiasm for the job/company that the candidate might have started out with. If they want to hire good people, many of them sure aren't acting like it.

Sorry for the horrible formatting. I guess my newlines/whitespaces weren't preserved.

"According to the agreements, the sites were supposed to open up their digitized archive to the public after an exclusivity period of 3 - 5 years." The contracts (see https://www.archives.gov/files... for example) do not say the sites have to open up their own archives after the exclusivity period. They just say that the National Archives and Records Administration (NARA) can release the contracted digital images (plus whatever other metadata the digitization partner gives to NARA) after that exclusivity period. The contracted data consists of images of the hand-written census forms, as scanned from microfilm. In most cases, NARA does not have indexes or transcripts of the records themselves that would allow searching by name. Ancestry, FamilySearch, MyHeritage, and others generated their own indexes, but those digitization partners were never required to give indexes of the records to NARA or to the public as part of the contract. Note, there are some existing projects for volunteers to help create publicly available indexes (opengendata.org is the only one I know of that would have no restrictions on the resulting volunteer-transcribed index, the others have restrictions like "no commercial use" and "no reposting in other places"). NARA already started releasing census images years ago. It is a slow process, but they already have images for the entire 1940 census online, and they have started with others (1930 for example has some of the images up last I checked a few months ago). I would expect it to take NARA a while to get it all online because they generate catalog entries in their system with varying levels of metadata in a format that works with their catalog system and I suspect there are some pretty human-limited steps in their workflow. The way I see it, NARA has not only shown willingness to release more and more data publicly on their website, they have already started doing it (see historyhub.history.gov and also the many digital collections that have already been released at archives.gov). So I think the only positive thing this lawsuit will accomplish is to (possibly) make the census records more of a priority (at the expense of other digitization projects). As soon as Reclaim the Records wins this lawsuit, they'll likely turn around and sue for another large dataset, and then another. And it's all data that NARA already wants to make more accessible and is working on doing so. I totally agree that the records need to be made available, but at some point manpower and budgets come into play and lawsuit after lawsuit will probably just make enemies of the very people at NARA who have been working so hard to make the vast collections of records more easily accessible to the public, right?