Codes 0x00 to 0x1F are called control codes (and in some contexts (such as use of ASCII control codes with TRON character set) 0x20 is also considered to be a control code). The code 0x7F is also a control code. (The PC character set (which is a superset of ASCII) has graphics for those codes as well, although in plain ASCII there are no graphics for the control codes.)
First, you should consider if you even need case folding; for many uses it will be unnecessary, anyways.
Furthermore, the proper way to do case folding will depend on such things as the character set, the language, the specific context of the text being converted (e.g. in some cases specific letters are required, such as abbreviations of the names of SI units), etc. And then, it is not necessarily only "uppercase" and "lowercase", anyways.
There might even be different ways to do by the same language, with possibly disagreements about usage (e.g. the German Eszett did not have an official capital form until 2017, although apparently some type designers did it anyways (and it was in Unicode before then, despite that)).
If the character set is Unicode, then there is not actually the correct way to do it, despite what the Unicode Conspiracy insists otherwise.
Also, for some uses the way that it will need to be done, there will be a specific way that it is required (due to the way that a file format or a protocol or whatever is working), so in such a case if the character set is something other than ASCII then you cannot just assume that it will always work in the same way.
You also cannot necessarily depend on the locale for such a thing, since it might depend on the data, as well.
These things can be as bad as they are, but Unicode just makes these things worse than that. If a program requires a specific case folding and then it will not work because it is the wrong version of Unicode and it is possible to be a security issue and/or other problems.
(Another problem, which applies even if you do not use case folding, is that some people think that all text is or should be Unicode and that one character set is suitable for everything. Actually, one character set cannot be suitable for everything, regardless of what character set it is. Even if it was (which it isn't), it wouldn't be Unicode.)
I am not as concerned that a car has AM radio than I am that AM radio must continue to be available and that you must be allowed to replace the radio in the car with your own that can use AM radio and that the car will not interfere with your use of AM radio (whether by replacing the existing radio or by using a portable radio). It would be good for the car to include a radio that has AM, but that isn't as important as the other things that I had mentioned.
AM radio is good due to the simplicity, instead of forcing replacing them with excessively complicated and confusing stuff like many modern computers are doing.
I still use AM (and FM) radio. I do not have a car, but sometimes use in someone else's car, and I also use it at home; the radio is not only for the use in the car.
I can recount from memory nearly every minute in the last like 10 years I have spent listening to broadcast AM/FM radio outside of a car. Nearly all of them were spent testing new stereos. On one occasion I was circuit bending a Casio keyboard and randomly stuck an inductor coil somewhere and it accidentally made the keyboard an AM radio, Hi Fi Gilligan style [1]. I may have been using the tunable capacitor from a radio to mess with the clock speed as well.
I think there's some cases where the medium is part of the experience, Radio Caroline in the UK are a former offshore pirate who used AM by necessity in their heyday (they'd anchor the ship just outside of British territorial waters to circumvent the BBC monopoly). The revival station worked hard to convince Ofcom to let them operate on AM given their historic connection to the medium, but they were granted a licence and are probably one of the few AM stations in the UK not in terminal decline.
I'll miss Five Live on 693 kHz, I grew up coming back from Watford games with it on in the car crackling as we went under power lines. Test Match Special on 198 kHz longwave is already gone in preparation for Droitwich's closure.
The AM radio community is definitely small and kind of niche, but I always had more fun listening to Coast to Coast on a late night road trip than I ever did listening to FM.
There have however been many major disasters where congestion or service impaired or shut down cellular internet access, so I think we do still need that lifeline... although I'd rather the radios be in cell phones since they're more likely to be with you and powered on in a disaster!
> I'd rather the radios be in cell phones since they're more likely to be with you and powered on in a disaster!
It would have to be a very short disaster, because your cell battery is going to die before the day is out. I've only changed the batteries in my AM/FM shower radio once since I bought it a decade ago.
That's true but we also have a lot of simple solutions for charging cell phones: powerbanks, solar and hand winders, transfer power from a laptop, small generators, and on top of that is charging from vehicles. Electric cars might not even start in extreme weather events and gasoline usually faces immediate shortages.
A tarot deck has more than only trumps. It also has fourteen non-trumps in each of four suits (Latin-suited or French-suited depending on the deck), so the total number of cards (trumps and non-trumps) is 78.
Furthermore, if you can store bytes, then why should it need to be UTF-8? Not all data is text, and not all text is Unicode (and not all Unicode text is most efficient with UTF-8). As far as I can tell, the only part of the program that requires it to be UTF-8 is the "decode_array_to_string" function (although I think it will have to be a string without embedded null characters since that is how argv is working, and that could possibly allow you to store a few more bytes, if the data is required to not have null characters).
I originally had planned to store other data as well (that's why it's called "CardFS"): With the bytes, there is another multiplier 3 in there, which is unused. My plan was to do 0=UTF-8 text, 1=raw bytes, 2=bitmap graphic, but I stopped working on it after I got the UTF-8 text working.
Excluding NUL characters would only up the byte count to floor(log_255(52!)), which is still 28 bytes (though it increases the unused multiplier from 2.99 to 3.1, which makes it possible to use all bytes in all three file types), but how would you then store texts that use fewer than the maximum number of characters? Fill it with spaces?
> Only the Apple Laserwriter didn't really do this (I don't think) because it was an exclusively PostScript printer. Instead, you shoved PostScript down the wire.
It would be possible to write a PostScript program that emulates ESC/P (or PCL), although then you would have to send an entire page (or a page break) before the page would be printed, unlike the old dot-matrix line printers that you can print one line at a time, PostScript can only print one page at a time.
In my case there was a floating nav bar bouncing around at seemingly random vertical heights over top of the document as I scrolled, which I found very distracting. Additionally, the buttons that are meant to link to the subtopics did not work, the vertical line height and scroll-jacking necessitated excessive scrolling, and and no scroll bar was visible. I've since figured out that FF mobile's reader mode makes it workable.
Being a programmable environment is one of the good benefits of UNIX, and piping programs together is also a good benefit of UNIX.
"Write programs that do one thing and do it well" and "Write programs to work together" are good ideas, too (unfortunately many programs don't).
I think that using a text stream for everything is not the best idea though. In many cases binary formats will do better. I think XML and JSON are not that good either.
I think "cache your compiler output to disk so you wouldn't have to do a costly compile step each time you ran a program" is a good idea, although this should not be required; REPL and other stuff they mention there is also very helpful.
They say the file system is also old. My idea is a transactional hypertext file system. It doesn't have metadata (or even file names), but a file can contain multiple numbered forks and you can store extra data in there.
(Transactional file system is something that I think is useful and that UNIX doesn't do.)
They are also right about the terminal is old, although some of the newer things that some people had tried to do have different sets of problems.
They also say another unfortunate thing is layering, and I agree that this layering is excessive.
Interoperating without needing FFI is also helpful (and see below what I mention about typed initial messages, too).
About the stuff listed in "Text streams, evolved", my idea of the operating system design, involves the "Common Data Format" (which is a binary format, somewhat like ASN.1 BER but different), and most data, including the command shell and most files, would use it; this also allows for common operations.
I agree with "a program which displays all of the thumbnails of the files listed on stdin would be much more useful to me than a mouse-oriented file browser", and I do not have a GUI file browser anyways. I do use command-line programs for most things, even though I have X Windows to run some GUI programs and to be able to have multiple xterms at once (I often have many xterms at once). However, it could be improved as I describe above, too.
They mention the shell. I agree that it could be greatly improved, and I think that it would go with the other improvements above. My operating system design effectively requires "programs as pure functions over streams of data" (although it is functions over "capabilities", and not necessarily "streams of data") due to the way that the capability-based security is working, and the way the linking and capability passing is working also allows working like higher-order functions and transformations and all of that stuff. Even, my idea also involves message passing (all I/O is done by passing messages between capabilities), too.
I had also considered programs that require types. One of the forks (like I mentioned above) of a executable file can specify the expected type of the initial message, and the command shell can use this to effectively make them like functions that have types.
Something they don't mention is security. That can also be improved; the capability-based security that I mention above, if you have proxy capabilities too, will improve it. There is also the possibility that users can use the command shell and write other programs to make up your own proxy capabilities, and this allows programs to be used to do things that they were not necessarily designed to do, in addition to improving security. Instead of merely a user account, it might e.g. allow to write to only one file, or allow connecting to only one remote computer (without the program knowing which one it is, and perhaps even with data compression that the application program is unaware of), etc.
I still think that, even if you have powerful computers, you should still program it efficiently anyways.
The new one won't be UNIX; it will be something else.
Using text streams between piped-together processes is not a requirement though. I'm using binary streams for some of the stuff I do, as I write simulators for some hardware (and other things) which gets processed by something else through a pipe or two (and may end up being parsed into text at or near the final point).
> It's not only notifications, it's permissions (that the app won't work until you accept) to track your location, exfiltrate your contact list, and so forth.
My idea of an operating system design (it is intended for desktop and laptop computers, but a variant could also be possible for smartphones and stuff if wanted), that all I/O (including determining the current date and time) must use capabilities (and can be proxy capabilities). The built-in programming language allows users to define new proxy capabilities and configure existing ones, and the C programming language can also be used. This can avoid such invasion of privacy but also is useful for other purposes, e.g. for testing, or to allow programs that expect a camera to work even if you do not have a camera, or to filter or redirect notifications, etc. Therefore, permissions can be as fine and as faked as you intend it to be. And, furthermore, the standard package manager would exclude programs that are designed to be invasion of privacy and other antifeatures like that (users can still install them manually, and the security features of the system still ensure that it would protect against many kind of malware and misfeatures).
> It should not be required to, e.g., order food at a restaurant or configure your headphones.
You shouldn't need a app or a web browser to do either of those things anyways.
I am sorry if I am being unclear. I will try to answer your questions.
> Time and date are not I/O.
In my system, they are. Anything except deterministic operations on the program's own memory is considered I/O.
> What does capability mean to you?
"Capability" refers to capability-based security. For a program to do any I/O, it must be given an object called a "capability" (which is similar than, but different than, a "file descriptor" in UNIX). There is no ambient authority; to open a file you must already be given a capability to open a file, etc. Capabilities can also be used to give someone else an additional capability.
A "proxy capability" is a capability that a program makes up itself, which can be used to pass messages between itself and another program that the proxy capability is given to. Programs cannot distinguish between a proxy capability and any other capability, therefore ensuring that anything that an application program would know from outside of itself can be overridden by the user. So, if a program wants to track your location, a proxy capability can be used to give fake location data (this is useful for testing as well, and also for other purposes e.g. if your computer cannot determine your location but you want to specify it anyways).
> How exactly does the inclusion of C avoid invasion of privacy?
Avoiding invasion of privacy is independent of what programming language is used.
> What's worse is when you're forced to use the app.
Yes, especially if you do not have a compatible smartphone (or any smartphone, or any computer) or if it had run out of battery power. But also just in case you don't want to, or if the app is defective, etc.
(I had read on Usenet that there is a German word "Digitalzwang" if you are forced to use computers with specific software.)
> The fucking app doesn't even sort the rooms ... It also has a 30 second load time ...
Yes, also that, that they are badly written and badly designed.
> Or when you go to a restaurant and they make you use their app.
I had only been at one restaurant where this was required, although they provided a iPad for this purpose, to any customers who required it. Furthermore, the restaurant was mismanaged and not such a good quality anyways. I do not intend to go to that restaurant again.
reply