zzo38computer

I have gotten what looks like SSH, TLS, HTTP, and other things, on various ports.

Another possible way would be port knocking. (I had previously set up port knocking on my HTTP server, but there seems to be a bug in the kernel (or in some driver) that prevents it from working correctly, so now the HTTP is not available. Using port knocking to restrict access to HTTP is probably not common, and might prevent your solution from being used if the form uses HTTP.)

I always pay in cash, and I would want to know all of the prices (including tips, if any) ahead of time if I can (and also be able understand the prices).

(My draft specification of Computer Payment File is intended to avoid many kind of dishonesty when paying by computer (it is not needed or useful when paying in cash), including this kind; one of the things it requires is that the buyer calculates the payment amount from the information (such as the catalog) that the seller provides; they cannot charge you any other amount of money.)

I think that it can sometimes be helpful to have some protective functions, as long as it is not excessive. It should not be mandatory and should not be too difficult to avoid. I program in C, and I do not use most of the warnings since they are excessive (in my opinion), but the warning about implicitly using a integer as a pointer is sensible (and should be an error) since you can easily explicitly override it (with the specific pointer type that you need) if that is really what you meant.

Tests are good regardless of what the programming languages tries to do, since not all bugs can be avoided by the programming language, and not all bugs should be avoided by the programming language. It should let you to write the program, instead of to stop you.

However, there are situations where due to the working of the implementation, there is no reasonable way to compile it when it specifies something which is then violated, or there might be certain extra things that may be required in the compiled code (making it bigger and/or slower in certain circumstances) when certain things are open. For example, consider if a different calling convention is needed for functions that can throw an exception (although in this case it should not require a try block if the function that calls it is also says it can throw an exception), or if some things in functions in a open class will need to be compiled in a special way to consider the possibility that other parts of the class will be overridden (both of these examples are hypothetical, I do not know whether or not any of this is actually true). It is also possible that certain optimizations are possible or not possible depending on if a class is open or something is nullable etc. Due to such things like that, specifying such features in the program might sometimes be necessary in order for the compiler to work correctly.

> I think there's a different barrier to entry since users may want old chat history (bouncers), IRC-specific spam and client choices (GUI, CLI, no mobile??)

I expect there are mobile choices, but if not, someone can write one; however, there is also possibility of having web chat (which seems to be common), etc. (However, I dislike the web chats that do not display the information for using IRC clients. They should be made to display such information even if JavaScript is disabled.)

For history, it is possible to have public logs for public channels, which can be either recorded by a dedicated client, or recorded by the server (although using a client is probably more common, it can be done on the server as well).

> I'm pretty sure IRC networks used to be somewhat anti-Unicode? correct me if I'm wrong

You can use multiple character sets on IRC, including Unicode. (If necessary, you might use ISO 2022 to switch between them, although this does not seem to be common.) (Also, some older IRC servers might not be 8-bit clean, and so might some newer ones that require Unicode (which are only partially 8-bit clean), unfortunately; however, any proper IRC server should be really 8-bit clean in order to avoid these problems.)

In addition to the reasons described there (which are valid, and I agree that they are good reasons to avoid Discord), there are others, such as, you might not have a telephone number (or you do, but it cannot receive SMS), and you might not want to require everyone to register with someone else unrelated to your project. (Also, I have seen that apparently Discord will require face scan, so that is another reason to be avoided; if you do not have a camera (or if you do not want to send a face scan to them) then that will not work.) (And, you should also avoid needing Facebook, etc)

However, I think that IRC can be useful. IRC is not the same as Slack and Discord like they mention, but often the other things are not needed, and IRC also is not too complicated to use and does not require a large web app or other stuff like that, which is a significant advantage of IRC. Also, another thing they did not mention, which can be helpful, is NNTP, which can be used both for announcements and for discussion, like email can be. This way, no web apps are needed, and email subscriptions are not needed; however, it can also be bridged with email if needed.

I think it does not make sense even for general spreadsheet use; it would be better to specify the type explicitly. (I also think a "zoned spreadsheet" would be better, although sometimes compatibility might still be needed with existing spreadsheets so a zoned spreadsheet cannot be the only implementation.)

Can it be used with X window system? X windows has key codes 0xFD01 to 0xFD1E for the 3270 terminal keys. I don't know the meaning on the actual IBM terminals, but they seem to match the key codes that are defined in X windows.

I also use C, for games and other stuff. However, for many games it can be useful to have a game engine, which is written in C (and I might write it by myself) but other parts will be written in the game engine. I also sometimes program games on DOS, and will use BASIC or Pascal. You will then not need to have too many dependencies; if it is a DOS program then the executable file should just work (with emulation if necessary) without the mess that is common on modern computers.

Even if it can sometimes help, I think it is not an excuse for writing bad documentation.

> That's by design. SaaS is a rent seeking business model.

Not all software now is SaaS, but unfortunately it is too common now.

> But I think it also applies to most code written in JS, Python, C#, Go, Rust, etc. There are too many dependencies.

Some people (including myself) prefer to write programs without too many dependencies, in order to avoid that problem. Other things also help, including some people write programs for older systems which can be emulated, or will use a more simpler portable C code, etc. There are things that can be done, to avoid too many dependencies.

There is uxn, which is a simple enough instruction set that people can probably implement it without too much difficulty. Although some programs might need some extensions, and some might use file names, etc, many programs will work, because it is designed in a simple way that it will work.

> The golden age for me is any period where you have the fully documented systems. Hardware that ships with documentation about what instructions it supports. With example code. Like my 8-bit micros did. And software that’s open and can be modified.

I agree, that it would be good. (It is one reason why I wanted to design a better computer, which would include full documentation about the hardware and the software (hopefully enough to make a compatible computer), as well as full source codes (which can help if some parts of the documentation are unclear, but also can be used to make your own modifications if needed).) (In some cases, we have some of this already, but not entirely. Not all hardware and software has the problems you list, although it is too common now. Making a better computer will not prevent such problematic things on other computers, and not entirely preventing such problems on the new computer design either, but it would help a bit, especially if it is actually designed good rather than badly.)

CP437 (the PC character set) has three blank spaces (although 0x00 is probably not going to be used), so 0xFF is displayed same as 0x20 so there is still a homoglyph.

Even though it can do some things atomically, it only does with one file at a time, and race conditions are still possible because it only does one operation at a time (even if you are only need one file). Some of these are helpful anyways, such as O_EXCL, but it is still only one thing at a time which can cause problems in some cases.

What else it does not do is a transaction with multiple objects. That is why, I would design a operating system, that you can do a transaction with multiple objects.

> If you read the script before you pipe it into your shell, it's safe.

If you download it first before executing it (instead of downloading it a second time when executing it), then that mitigates one problem, but still not all of them (like you mention). Other mitigations are also possible, such as hashing, certificate pinning, sandboxing, etc.

I use non-Unicode terminal mode (I might prefer to use a terminal emulator that does not support Unicode but you can add fonts for arbitrary character sets (of your choice, so that none are forced) instead) and program the browser to always display URLs as ASCII. So, when I copy the text to the terminal, I get "#" in place of the Cyrillic alphabets.

I think making IDN work the way it does was a mistake. I thought of making IDN with a character set specific for that use (I did think about how it would work) instead of using Unicode or any other existing character sets (none of them are suitable, as far as I am concerned; however, this new IDN character set would potentially be suitable for some other uses such as perhaps package names). Using one character set for everything is not very good, and Unicode is especially bad for this. (Although in my opinion, TRON code is generally better than Unicode, neither TRON code nor Unicode is the one to use for this)

However, there are other problems with paste in the terminal window, but bracketed paste mode can mitigate some of these problems in some cases, it is not entirely helpful.

If you can disable Unicode in your terminal emulator, then it will be. (Unfortunately, that won't help if you want Unicode in your terminal emulator, though.)

There is unleaded airplane fuel, although leaded fuel is still used. What I have been told is that it would take some time for the unleaded airplane fuel (which is compatible with the existing airplanes that use leaded fuel) to be distributed to enough places to be commonly available enough, which it isn't yet.

I think dry run mode is sometimes useful for many programs (and, I sometimes do use them). In some cases, you can use standard I/O so that it is not needed because you can control what is done with the output. Sometimes you might miss something especially if the code is messy, although security systems might help a bit. However, you can sometimes make the code less messy if the I/O is handled in a different way that makes this possible (e.g. by making the functions that make changes (the I/O parts of your program) to handle them in a way that the number of times you need to check for dry run is reduced if only a few functions need to); my ideas of a system with capability-based security would allow this (as well as many other benefits; a capability-based system has a lot of benefits beyond only the security system). Even with the existing security it can be done (e.g. with file permissions), although not as well as capability-based security.

I program in C and I like many of the reasons they mention here, are things I like about C programming. They use C89 (and sometimes C99), although I do use some of the GNU extensions (which, as far as I know, both GCC and Clang support them).

I would want to use separate programs for displaying videos, whether or not the operating system includes them. Being able to play, pause, seek, set caption styles (including size, colour, and opacity), record it on a DVD, etc, would be helpful, but that can be whatever program you decide to use that has the features you wanted; whoever made the video or wants to send it to you should not need to care which of these features you are using (although they will need to include captions if you want them).

I wrote a program to record videos from HLS, including the option to avoid downloading commercial breaks. However, some things are still missing and/or might not work properly. (Some things, such as converting it to the DVD video format and then recording it onto a DVD, are done with separate programs and is out of scope of this one.)

I don't like AI images or stock images. If a picture is not needed (or helpful; sometimes it is not needed but can be helpful) to describe it which is specific to that article, add it, but stock images and AI images are not helpful, and can sometimes be deceptive in some contexts (although so can pictures specific for the article, if the pictures are badly made).

Often, the text will be good enough, or better (since then you do not need to download the picture, it does not take up space on the screen (or on a paper if printed out),e tc.)

There are also some things in C that do not work or work differently in C++, such as (void*), empty structures (which in C++ are not really empty), etc; and there is also such C++ stuff such as name mangling, the C++ standard library, etc, even if those things are not a part of your program, which is another reason why you might prefer C.

I do not agree that restricting it to UTF-8 (or to Unicode in general) is a fair and reasonable design decision (although UTF-8 may be reasonable if Unicode is somehow required anyways (you should avoid requiring Unicode if you can though), especially the program is also expected to deal with ASCII in addition to requiring Unicode), but regardless of that, the number of code points is not usually relevant (and substring operations indexed by code points is not usually necessary either), and the number of bytes will be more important, and some programs should not need to know about the character encoding at all (or only have a limited consideration of what they do with them).

(One reason you might care about the number of code points is because you are converting UTF-8 to UTF-32 (or Shift-JIS to TRON-32 or whatever else) and you want to allocate the memory ahead of time. The number of characters (which is not the same as the number of code points in the case of Unicode, although for other character sets it might be) is probably not important; if you want to display it, you will care about the display width according to the font, and if you are doing editing then where one character starts and ends is going to be more significant than how many characters they are. If you are using and indexing by the number of code points a lot (even though as I say that should not usually be necessary), then you might use UTF-32 instead of UTF-8.)

(It is also my opinion that Unicode is not a good character set.)

> data types won't matter (hence XML doesn't have them, but after that JSON got them back)

JSON does not have very much or very good data types either, but (unlike XML) at least JSON has data types. ASN.1 has more data types (although standard ASN.1 lacks one data type that JSON has (key/value list), ASN.1X includes it), and if DER or another BER-related format is used then all types use the same framing, unlike JSON. One thing JSON lacks is octet string type, so instead you must use hex or base64, and must be converted after it has been read rather than during reading because it is not a proper binary data type.

> The funny thing about namespaces is that the prefix, by the XML docs, should be meaningless -- instead you should look at the URL of the namespace. It's like if we read a doc with snake:front-left-paw, and ask how come does a snake have paws? -- Because it's actually a bear -- see the definition of snake in the URL!

This is true of any format that you can import with your own names though, and since the names might otherwise conflict, it can also be necessary. This issue is not only XML (and JSON does not have namespaces at all, although some application formats that use it try to add them in some ways).

The <article> command in HTML can be useful, even if most implementations do not do much with it. For example, a browser could offer the possibility to print or display only the contents of a single <article> block, or to display marks in the scrollbar for which positions in the scrollbar correspond to the contents of the <article> block. It would also be true of <time>; although many implementations do not do much with it, they could do stuff with it. And, also of <h1>, <h2>, etc; although browsers have built-in styles for them, allowing the end user to customize them is helpful, and so is the possibility of using them to automatically display the table of contents in a separate menu. None of these behaviours should need to be standardized; they can be by the implementation and by the end user configuration etc; only the meaning of the commands will be standardized, not their behaviour.

Different formats are good for different purposes. XML does have some benefits (like described in there), as well as some problems; the same is true of JSON. They do not mention ASN.1, although it also has many benefits. Also, the different formats have different data types, different kind of structures, etc, as well.

XML only has text data (although other kinds can be represented, it isn't very good at doing so), and the structure is named blocks which can have named attributes and plain text inside; and is limited to a single character set (and many uses require this character set to be Unicode).

XML does not require a schema, although it can use one, which is a benefit, and like they say does work better than JSON schema. Some ASN.1 formats (such as DER) can also be used without a schema, although it can also use a schema.

My own nonstandard TER format (for ASN.1 data) does have comments, although the comments are discarded when being converted to DER.

Namespaces are another benefit in XML, that JSON does not have. ASN.1 has OIDs, which have some of this capability, although not as much as XML (although some of my enhancements to ASN.1 improve this a bit). However, there is a problem with using URIs as namespaces which is that the domain name might later be assigned to someone else (ASN.1 uses OIDs which avoids this problem).

My nonstandard ASN1_IDENTIFIED_DATA type allows a ASN.1X data file to declare its own schema, and also has other benefits in some circumstances. (Unlike XML and unlike standard ASN.1, you can declare that it conforms with multiple formats at once, you can declare conformance with something that requires parameters for this declaration, and you can add key/value pairs (identified by OIDs) which are independent of the data according to the format it is declared as.)

(I have other nonstandard types as well, such as a key/value list type (called ASN1_KEY_VALUE_LIST in my implmentation in C).)

XSLT is a benefit with XML as well, although it would also be possible to make a similar thing with other formats (for databases, there is SQL (and Tutorial D); there is not one for ASN.1 as far as I know but I had wanted such a thing, and I have some ideas about it).

The format XML is also messy and complicated (and so is YAML), compared with JSON or DER (although there are many types in DER (and I added several more), the framing is consistent for all of them, and you do not have to use all of the types, and DER is a canonical form which avoids much of the messiness of BER; these things make it simpler than what it might seem to some people).

Any text format (XML, JSON, TER, YAML, etc) will need escaping to properly represent text; binary formats don't, although they have their own advantages and disadvantages as well. As mentioned in the article, there are some binary XML formats as well; it seems to say that EXI requires a schema (which is helpful if you have a schema, although there are sometimes reasons to use the format without a schema; this is also possible with ASN.1, e.g. PER requires a schema but DER does not).

Data of any format is not necessarily fully self-descriptive, because although some parts may be self-described, it cannot describe everything without the documentation. The schema also cannot describe everything (although different schema formats might have different capabilities, they never describe everything).

> When we discarded XML, we lost: ...

As I had mentioned, other formats are capable of this too

> What we gained: Native parsing in JavaScript

If they mean JSON, then, JSON was made from the syntax of JavaScript, although before JSON.parse was added into standard JavaScript they might have used eval and caused many kind of problems with that. Also, if you are using JavaScript then the data model is what JavaScript does, although that is a bit messy. Although JavaScript now has a integer type, it did not have at the time that JSON was made up, so JSON cannot use the integer type.

> I am tired of lobotomized formats like JSON being treated as the default, as the modern choice, as the obviously correct solution. They are none of these things.

I agree and I do not like JSON either, but usually XML is not good either. I would use ASN.1 (although some things do not need structured data at all, in which case ASN.1 is not necessary either).

(Also, XML, JSON, and ASN.1 are all often badly used; even if a format is better does not mean that the schema for the specific application will be good; it can also be badly designed, and in my experience it often is.)

That is what I thought too, when I read it. (I was going to mention it if I did not find someone else already did.)

I do not agree. It should not be opt-out. If you want funding, make it opt-in. I do not want to be paid for it, and I also do not want to pay for it (and I also do not want to have too many dependencies, even if I do not have to pay for it).

Also, not all programs use package.json and requirements.txt, so that won't work anyways.

I had seen GitHub node IDs, although I had not used them or tried to decode them (although I could see they seem to be base64), since I only used the REST API, which reports node IDs but does not use them as input.

It looks like a good explanation of the node IDs, though. However, like another comment says, you should not rely on the format of node IDs.