mikelabatt

Is there a specific temperature and exposure duration at which freezing would be effective? This approach has been used against certain other molds.

Was there a technical reason for not using corrugated ducts in the concrete, maybe because it's a shelter?

I guess that's why the two most important suppliers of OLED panels for PC monitors (LG and Samsung) are rearranging their subpixel to use LCD-like RGB stripes:

https://www.heise.de/en/news/OLED-with-true-RGB-LG-and-Samsu...

Any thoughts on how this might be different from existing products like GC Tooth Mousse (CPP-ACP-based, recommended by our children's dentist)?

A paper from 2011 on the topic:

https://pmc.ncbi.nlm.nih.gov/articles/PMC9374843/

Thanks for your insights. I did change my mind about the need for a BOM (though not about the need to be able to parse/skip it if present).

In a future where everything defaults to UTF-8 it makes sense. This is probably easier to envision in an English-only context where the jump from 7-bit ASCII to UTF-8 is cleaner.

Where I come from, UTF-8 is not always supported. Without a header (or "BOM", though we don't like the name) you don't know in what encoding a text file was meant to be (re-)saved as when it was created. My example of an empty file was meant to illustrate that. But leaning on the Utopian side, I too shall put more energy towards all apps supporting UTF-8 :)

Makes sense, thank you. The observation about false positives for UTF-8 tending to zero helps understand. So I will vote for UTF-8 without BOM from now on (while encouraging parsers to deal with it, if present).

In a pure UTF-8 world we would not need it, sure. I get that point. But what do you want to do with 40+ years worth of text files that came after 7-bit ASCII, where they may coexist with UTF-8? If we want to preserve our past, the practical solution is that the OS or app has a default character set for 8-bit text encoding, in addition to supporting (and using as a default) UTF-8.

I also agree that "BOM" is the wrong name for an UTF-8... BOM. Byte order is not the issue. But still, it's a header that says that the file, even if empty, is UTF-8. Detecting an 8-bit legacy character set is much more difficult that recognizing (skipping) a BOM.

Even the Amiga with its 8-bit text encoding was 40 years ago. Are you saying that for some radical reason modern apps on any platform should refuse to process a BOM? Parsing (skipping) a simple BOM header isn't the same as becoming fully Unicode-aware. I did not invent the BOM for UTF-8, it's there in the wild. We better be able to read it, or else we will have this religious debate (and technical issues porting and parsing texts across platforms) for the next 40 years.

I like your answer, and the others too, but I suspect I have an even worse problem than running Windows: I am an Amiga user :D

The Amiga always used all 8 bits (ISO-8859-1 by default), so detecting UTF-8 without a BOM is not so easy, especially when you start with an empty file, or in some scenario like the other one I mentioned.

And it's not that Macs and PCs don't have 8-bit legacy or coexistence needs. What you seem to be saying is that compatibility with 7-bit ASCII is sacred, whereas compatibility with 8-bit text encodings is not important.

Since we now have UTF-8 files with BOMs that need to be handled anyway, would it not be better if all the "Unicode-unaware" apps at least supported the BOM (stripping it, in the simplest case)?

Nice article, thank you. I love UTF-8, but I only advocate it when used with a BOM. Otherwise, an application may have no way of knowing that it is UTF-8, and that it needs to be saved as UTF-8.

Imagine selecting New/Text Document in an environment like File Explorer on Windows: if the initial (empty) file has a BOM, any app will know that it is supposed to be saved again as UTF-8 once you start working on it. But with no BOM, there is no such luck, and corruption may be just around the corner, even when the editor tries to auto-detect the encoding (auto-detection is never easy or 100% reliable, even for basic Latin text with "special" characters)

The same can happen to a plain ASCII file (without a BOM): once you edit it, and you add, say, some accented vowel, the chaos begins. You thought it was Italian, but your favorite text editor might conclude it's Vietnamese! I've even seen Notepad switch to a different default encoding after some Windows updates.

So, UTF-8 yes, but with a BOM. It should be the default in any app and operating system.

My oldest son is 5, and I am having some of the same thoughts.

What system did you do the demos on in the 1990s? Might a "classic" system like that not be the "contained" environment you are looking for as a learning environment? And you are even good at that! Systems like the C64, Amiga 500 and Amiga 1200 are still references for current demoscene competitions. They are timeless, you can find them on eBay or emulate them, and your son will be able to show his skills on those even 10 years from now.

If you are afraid that these are not cool enough for your son, fear not. At retro events like VCF, Pixel Heaven, or in the dedicated area at Gamescom, children line up to play on those systems, and for some it is an element of great pride to be experts in them.

My answer to your question looks like this at the moment: I will start with a CBM 8032, after showing him how arcade games of the 1980s were. Then I will add a bit of color, sound, and maybe sprites, via a VIC-20 or C64. And then, if things go well, we can add multitasking and more OS and chipset features by exploring one of the last cool systems where you could try to master every secret: the Amiga.

It doesn't have to be "retro for life". But I think that learning with a "simple" past like this, also makes you better appreciate the present and the future.

Thanks for the feedback. The page [1] has been updated to clarify this detail. The documentation is installed with the package (Help menu, or press F1 to open it), but if you would like to contact me @mikelabatt I can send you a copy.

Me and my colleague Nicola were the ones who asked for these permissions. Iconic demos like Roots 2.0 and World of Commodore could not be included in the historical context for the reasons you mentioned. If someone does not want their work to appear in a commercial book project or in an electronic curation, I respect that. We could do better, like featuring more recent works. Perhaps one day it will be done, like the website (OTOH, some say that it has a Craigslist-like appeal to it). This always was a niche project driven by passion, and resources are tight.

While PC floppy drives are mechanically the same as Amiga floppy drives, the controller that is attached to the drive is different. The controller used in PCs can't handle the stream coming from Amiga disks. The first thing I would do is preserve those disks by creating an image with a custom controller. I am positive that the music and art can be converted, but that can be done later. First, save (image) those disks!

Here are some tips to read Amiga floppy disks: https://www.amigaforever.com/kb/13-118

Every demoscene production featured in Amiga Forever was included with permission from their creators. Credits are in the documentation.

Please name one demo that you think should not be in Amiga Forever, and I will check that and report here.

A century ago engineer Luigi Stipa did experiments with several flying wing aircraft designs. Here is Stipa-Caproni's "intubed propeller" from the 1930s:

https://en.wikipedia.org/wiki/Stipa-Caproni

Even newer patents should cite this research:

https://en.wikipedia.org/wiki/Luigi_Stipa

It was good to read "Why not AsciiDoc?" in their FAQ: https://markdoc.io/docs/faq

"He explained to me with great insistence that every question possessed a power that did not lie in the answer." - Elie Wiesel, Night

Indeed WPA3 is required for "Wi-Fi CERTIFIED 6" only, but Ubiquiti already stated in a post that they are working on WPA3, even offering it as a software upgrade for many of their older models:

https://community.ui.com/questions/WPA3-for-existing-Unifi-f...

The patch was finalized already in February. I wonder why it took so long to release it?

https://twitter.com/mikelabatt/status/863356853576749056

I see it as a subtle difference of automation and scale, plus the fact that the Internet Archive is not just saving these copies, but also making them available.

Imagine standing on the public road and taking a picture of your neighbor's home (or face) for your own use. Is that the same as a large company taking pictures of all homes (or faces) of the world, and making them available to the entire world, forever?

Yes, but should your computer also be allowed to disseminate that content without the original author's permission?

It looks like these devices are indeed affected by a change which came into effect on July 1, 2016. However, this is going to be a stepwise reduction of 0.8% points rather than a complete elimination. So this month the duty changed from 4.9% to 4.1%.

Source: German customs, cited by http://www.heise.de/foto/meldung/Zollsatz-Senkung-bei-Kamera...

I could not find any source confirming this, but item 080 on the list is "Television cameras, digital cameras and video camera recorders".

If this indeed became effective July 1, 2016, wouldn't it mean that the 30-minute video recording limitation which is in place on some consumer devices to avoid a small duty (around 5%) can now be lifted?

The WTO document:

http://www.heise.de/downloads/18/1/8/4/2/5/4/3/25.pdf

Agreed. Normal non-technical people let friends have a look at their computer, and it is often a surprise for both that passwords can so easily be seen. Theory is one thing, but there is IMHO also a practical "don't make it too easy" factor that should be considered. As the saying goes, sometimes "opportunity makes a thief".