zzo38computer

I agree that there should not be icons in menus (with the exception of those indicating the status, like is shown in the 2005 guidelines). (Arrangements, shapes, etc might also sometimes be useful to indicate, but these should be separate from status indicators if they are present, and should be a part of the text instead in the few cases where they are applicable; in most cases they should not be needed.)

Showing a check mark for if something is active can make sense, and other status indicators, but then it should also indicate if the status is currently absent. (On Windows, some menu items can have a check mark, but if there isn't, it does not tell you if it is one that could have a check mark or not. Indicating this could be useful.)

Another thing that the menus do have, and which they should have because it is good to have, is specifying which keys are used to operate those commands. Windows also has one underlined letter so that you can select it when the menu is displayed, which can also be useful (especially since not all commands have keys assigned normally, so using the keys to activate the menus can be used in this case).

My own programs with menus do not use icons (and do not usually use icons outside of menus either).

I might use audio cassettes if I want to record my own audio temporarily (and later copy it to a CD if I decide to keep it; I have done this before), especially if the higher quality of CDs is not needed. For most uses I would probably not use audio cassette tapes; I prefer to use CDs.

(One feature of audio cassettes is that it will stay where it was left off (even if it is removed and used in a different player), although this can be both an advantage and a disadvantage (for one thing, each cassette has only one position). At least, you can easily rewind it back to the beginning. There are other advantages and disadvantages as well)

The past is not perfect and there are some things that are improved in some ways these days (and in future), but other things are being worse these days (and in future) than they were. It is not so simple.

I also think that you should not rely on (or overuse) modern technology too much, even though it can sometimes be beneficial (so it is not the reason to avoid it unconditionally, nor necessarily to avoid it generally).

Many things now are excessively artificially, including (but not limited to): light, music, communication, food, transportation, and now even also creativity. (Some of these (such as food and music) are mentioned in that article but some are they do not seem to mention it) This is not the only problem (there are many other problems too), but it is one aspect of it.

> Time to ban all adverts everywhere.

I think that is too much, but it should be almost entirely banned, with only very limited exceptions. Advertisements which you are specificailly looking for, such as catalogs for those specific things, could be one of those exceptions.

However, even regardless of these exceptions, there will need to be limits, such as: do not be dishonest, do not emit light, do not waste power, do not spy on you, do not block the view of other things, do not try to prevent you from seeing them, they cannot pay you or give you discounts for seeing the ads, etc.

> The time to negotiate a "middle ground" is long past.

I think it will need to be a "nearly banned" ground rather than the "middle" ground, though.

> Ad companies need to be reined in. They cannot control themselves.

This part I agree with.

> The only solution is [...] to make sure that anyone who gets that idea will never get it again.

But, this part, I think that won't work. Even if it does work (which it won't), it is bad for freedom of speech and freedom of opinion.

The excessive advertising also results in waste of paper and waste of time, wasted computer power and disk space, lighted advertising making light pollution, etc. This is in addition to issues of happiness, dishonesty, etc.

Yes, that would be an example of an acceptable advertising, and is better than what they usually do too much instead.

I would agree, that I would rather not suffer imposed advertising I did not ask for even if missing out some products.

However, you can have e.g. a magazine that lists computer parts if you want to buy that (as mentioned by another comment), or in a restaurant that has a sign on the wall (or a printed menu) indicating new items, or a news paper might have a section relating to restaurants or movies or whatever else you might want to buy, or there might be publications that specialize in these things if you are deliberately trying to look for them. They should not need to put advertising anywhere, and they should not need to make it excessive or abusive or dishonest like they do, etc.

(Products that they advertise way too much often have some problems other than just the advertising, too.)

> You can totally have tooling that exposes a GeneralString's blob payload to the application and lets the app handle the codeset switching aspects of GeneralString.

You can do that for all types, and my own implementation does just expose the payloads for all types, although it also has functions to encode and decode many of them, they are functions that must be called separately (e.g. asn1_decode_number and asn1_decode_date).

For some applications, there is no need to decode the payload anyways, and you can just treat it as opaque data if you do not need to display them (the same is true for many other types).

> I want to object that anyone who really has to handle multi-codeset GeneralString values would want a better library

I did start to try to write such a thing (it is not published yet), and the library for ISO 2022 is separate than the library for ASN.1, although they can be used together. It is intended to be usable for multiple uses. (I might also add support for character codes other than ISO 2022 (such as the encodings of Unicode and TRON code), although it is mainly intended to support ISO 2022.)

> ...what would that be if not a converter to/from Unicode?

For one thing, not all of the codes can be correctly converted to/from Unicode (especially control characters), and even if they can be, this is does not preserve some of the details, because the way the character set works is different from Unicode (e.g. some things might be considered to match in Unicode but not other character sets and vice-versa; this would also be true of case-folding, missing details, character properties, etc). For example, some information may be lost when converting to Unicode.

(This does not necessarily mean that converting to/from Unicode is never useful, although you should consider if you can do it in a better way; for example, if your program accepts input that is meant to be added to a General string (or Graphic string) in a DER file then it would be better to accept ISO 2022 input directly if possible. Converting to TRON code (especially for CJK text) might be better, but even that depends on what you are using it for; some uses do not require conversion at all.)

If you really want to store Unicode text anyways, you should consider if UTF-8 is a valid type according to the schema you are using (and use that type instead if so; note that some schemas might not care so much about the type in some cases); if not, consider prepending the three bytes <1B 25 47> when encoding it as a ISO 2022 string. (As far as I can tell, this is not really supposed to be allowed in ASN.1, but I suppose it is possible if you really need to. You might also check if it is only ASCII and avoid adding this prefix if so.)

> But what if one really wants an array/list of {codeset, string} pairs? At that point open-coding support for those escapes is probably just as well since that one might have the only application in the world that wants that!!

I think that what you will want will depend on the specific application. Some will want that, some will want something else, and also different ways that you might want handling control characters, etc.

Yes, it is open source, and I do have a link: https://github.com/zzo38/superzz0 (it is a game creation system similar to ZZT and MegaZeux)

> ASN1_BCD_STRING can be just IA5String with a constraint attached...

The abstract meaning matches, but the format is differently.

> ASN1_OUT_OF_BAND can just be a NULL with an APPLICATION tag or whatever

There are some uses of having a dedicated "out of band" type, such as being able to find them regardless of the schema (e.g. it might be used by a protocol that can use data with any schemas, but allows out of band data with any schema for some reason, and might want to modify the representations of out of band data when sending it to someone else).

> ASN1_IDENTIFIED_DATA... ASN.1 has EMBEDDED-PDV, open types, and the TYPE-IDENTIFIER class -- there are many ways to do this in ASN.1

EMBEDDED-PDV and those other things are different situations than I am doing, although it is similar, the use is not quite the same. ASN1_IDENTIFIED_DATA is simpler in some ways but also allows some things that EMBEDDED-PDV does not do.

Programs can also use ASN1_IDENTIFIED_DATA to identify the schema of a file that uses this type (and potentially be able to e.g. uncompress or decrypt it; this is the reason why the identifiers are allowed to be sequences and not only plain OIDs), or a part of another file.

> ASN1_REFERENCE is... interesting. I've not needed it, but some RPC protocols support intra-payload and even circular references, so if you have a need for that (hopefully you don't), then your ASN1_REFERENCE would be useful indeed.

Yes, it is what I thought too. So far I have not needed it either, but it might sometimes be useful.

> ASN1_RATIONAL is just a tagged sequence of numerator and denominator, with a constraint...

It can be defined as such in standard ASN.1, and the format is the same as that, but the abstract meaning is different. There is also a further constraint for the canonical form.

(Currently, the only place I have used this type is the tempo ratio in the .BGM lumps in Super ZZ Zero, but it would have other uses too, such as when converting data from other formats that have a rational number type.)

> OBJECT IDENTIFIER RELATIVE TO is just a CHOICE of OBJECT IDENTIFIER and RELATIVE IDENTIFIER.

It can be implemented that way in standard ASN.1 and has the same DER representation as your described type, although the abstract meaning is essentially the same as OBJECT IDENTIFIER and there is an additional constraint in the canonical form (as far as I know, this additional constraint cannot be written in standard ASN.1, but Super ZZ Zero cares about it being in canonical form (except for sound card identifiers in .BGM lumps, but this is an implementation detail for that specific part of the program)).

> I had kind of expected a subset of x.680.

Currently I am not using the schema format for ASN.1X (nor do I use the schema format of standard ASN.1); if someone else does then they might implement a variant of X.680 for use with ASN.1X. I probably would remove some stuff (and add some stuff) if I did make a variant, though.

(The use of ASN.1X is also not defined for JER, XER, OER, etc; if someone needs to, then they might do that.)

If the CA is somehow able to control the communication (I think usually they don't, but if they are being run by intelligence operatives then maybe they have that capability, although they probably do not use it a lot if so (in order to reduce the chance of being detected)), they could substitute a certificate with their own keys (and then communicate with the original server using the original keys in order to obtain the information required). However, this does not apply if both sides verify by an independent method that the key is correct (and if not, would allow to detect it).

Adding multiple signatures to a certificate would be difficult because the extensions must be a part of the certificate which will be signed. (However, there are ways to do such thing as web of trust, and I had thought of ways to do this with X.509, although it does not normally do that. Another way would be an extension which is filled with null bytes when calculating the extra signatures and then being filled in with the extra signatures when calculating the normal signature.)

(Other X.509 extensions would also be helpful for various reasons, although the CAs might not allow that, due to various requirements (some of which are unnecessary).)

Another thing that helps is using X.509 client certificates for authentication in addition to server certificates. If you do this, then any MITM will not be able to authenticate (unless at least one side allows them to do so). X.509 client authentication has many other advantages as well.

In addition, it might be helpful to allow you to use those certificates to issue additional certificates (e.g. to subdomains); but, whoever verifies the certificate (usually the client, but it can also be the server in case of a client certificate) would then need to check the entire certificate chain to check the permissions allowed by the certificate.

There is also the possibility that certificate authorities will refuse to issue certificates to you for whatever reasons.

ASN.1 does not necessarily need to get involved in parsing the values; for some applications doing so is unnecessary anyways (this is true for many fields of many types and not only this one, though). ASN.1 will need to be involved in parsing the framing; whether or not it is involved in parsing the values depends on whether the application requires it for that specific value (for example, it is commonly not necessary to parse OIDs (you can usually just treat them as opaque data which can be compared for equality (or looked up in a table), although sometimes it is useful to display them), although some implementations insist on doing so anyways).

I agree (and we should not need patents either), but I think it might be better to prevent you from saying that someone else wrote something if they did not write it, or to say someone else wrote it if you modified it unless you also mention that it has been modified from the original version.

> Have you written up anything about ASN.1X anywhere? I'd love to take a look.

ASN1_BCD_STRING (64): Represents a string with the following characters: "0123456789*#+-. " (excluding the quotation marks). Each octet encodes two characters, where the high nybble corresponds to the first character and the low nybble corresponds to the second character.

ASN1_PC_STRING (65): Represents a string of characters in the PC character set. Note that the control characters can also be used as graphic characters.

ASN1_TRON_STRING (66): Represents a string of characters in the TRON character set, encoded as TRON-8.

ASN1_KEY_VALUE_LIST (67): Represents a set of keys (with no duplicate keys) and with a value associated with each key. The encoding is the same as for a SET of the keys, but with the corresponding value immediately after each key (when they are sorted, only the keys are sorted and the values are kept with the corresponding keys).

ASN1_UTC_TIMESTAMP (68): Represents a number of UTC seconds (and optionally fractions of seconds), excluding leap seconds, relative to epoch.

ASN1_SI_TIMESTAMP (69): Represents a number of SI seconds (and optionally fractions of seconds), including leap seconds, relative to epoch.

ASN1_UTC_TIME_INTERVAL (70): Represents a time interval as a number of UTC seconds. The number of seconds does not include leap seconds.

ASN1_SI_TIME_INTERVAL (71): Represents a time interval as a number of SI seconds (which may include fractions).

ASN1_OUT_OF_BAND (72): This type is not for use for general-purpose data. It represents something which is transmitted out of band (e.g. a file descriptor) with whatever transport mechanism is being used. The transport mechanism defines how a value of this type is supposed to be encoded with whatever ASN.1 encoding is being used.

ASN1_MORSE_STRING (73): Represents a string of characters in the Morse character set. The encoding is like a relative object identifier, where 0 means an empty space, and others is like bijective base 2 with 1 for dots and 2 for dashes, with the high bit for the first dot/dash, e.g. 4 means A and 8 means U.

ASN1_REFERENCE (74): A reference to another node within the same file. (Not all implementations will support this feature.) The encoding is like a Relative Object Identifier; the first number is how many times to go to the parent node (where 0 means the reference itself), and then the rest of the numbers specify which child node of the current node to go to where 0 means the first child, 1 means the second child, etc. It can reference a primitive or constructed node of a BER file, but you cannot specify a child index for a child of a primitive node, since primitive nodes cannot have child nodes. At least one number (how many levels of parents) is required, but any number of numbers is potentially possible.

ASN1_IDENTIFIED_DATA (75): Data which has a format and/or meaning which is identified within the data. The encoding is always constructed and consists of two or three items. The first item is a set of object identifiers, object descriptors (used only for display), and/or sequences where the first item of the sequence is a object identifier. The receiver ignores any items in this set that it does not understand. The second item in a ASN1_IDENTIFIED_DATA can be any single item of any type; it is interpreted according to the object identifiers in the first set that the receiver understands. The third item is optional, and if it is present it is a key/value list of extensions; the keys are object identifiers and the values are of any type according to the object identifiers. The default value of this key/value list is an empty key/value list.

ASN1_RATIONAL (76): Stored as constructed, containing two integers, being the numerator and the denominator. The denominator must be greater than zero. If it is canonical form, then it must be lowest terms.

ASN1_TRANSLATION_LIST (77): A key/value list where the keys identify languages. If the key is null then it means the default in case no language present in this list is applicable. The types of the values depends on the application (usually they will be some kind of character strings).

In addition, the same number for the BMP string type can also be used for a UTF-16 string type, and there is a "OBJECT IDENTIFIER RELATIVE TO" type which encodes a OID as either relative or absolute (in canonical form, it is always relative when possible) in order to save space; the schema will specify what it is relative to. ANY and ANY DEFINED BY are allowed despite being removed from the most recent versions of standard ASN.1. (The schema format for these extensions is not defined, since I am not using the ASN.1 schema format; however, someone who does use it might do so if they need it.)

There is also SDER, which is a superset of DER but a subset of BER, in case you do not want the mess of BER but do not want to require strictly canonical form either; and also SDSER which uses the same encoding for types and values than SDER but but length works differently in order to support streaming better.

As is usual, you do not have to use any or all of these types, but someone might find them useful for some uses. I have used some of them in my own stuff.

> I'm still confused how these ISO 2022 strings even work

There is C0, G0, C1, and G1 sets (C0 and C1 are control characters and G0 and G1 are graphic characters), and escape sequences are used to select the C or G set for bytes with or without the high bit set. Graphic string does not allow control characters and General string does allow control characters.

You probably do not need all control characters; your schema should probably restrict which control characters are allowed in each context (although the ASN.1 schema format does not seem to have any way to do this). This way, you will only handle the control characters which are appropriate for your use.

This is messy, although canonical form simplifies it by adding some restrictions (this is one of the reasons why DER is better than BER, in my opinion). TRON code is better and is much simpler than the working of ISO 2022. (Unicode has a different kind of mess; although decoding is simpler, actually handling the decoded characters in text is its own big mess for many reasons. Unicode is a stateful character set, even though the encoding is stateless; TRON code is the other way around (and with a significantly simpler stateful encoding than ISO 2022).)

> the ASN1 docs discourage using the UniversalString and GraphicString types

UniversalString is UTF-32BE and GraphicString is ISO 2022 without control characters. By knowing what they are, you should know in which circumstances they should be considered useful or not useful; I think that they should not be discouraged in general (although usually if you want Unicode, you would use UTF-8 rather than UTF-32, there are some circumstances where you might want to use UTF-32, such as if the data or program is already UTF-32 for other reasons).

(The data type which probably should be avoided is the UTC time type, which is not Y2K compliant.)

> All these different string types are intimidating if I just want unicode/ascii

If you only want ASCII, use the IA5 type (or Visible if you do not want control characters); if you only want Unicode, use the UTF-8 string type (or Universal if you want UTF-32 instead for some reason). ("IA5" is another name for ASCII that as far as I can tell hardly anyone other than ITU uses.)

However, Unicode is not a very good character set, and they should not force or expect you to use it.

As I had mentioned before, you do not need to use or implement all of the ASN.1 data types; only use the ones appropriate for your application (so, if you do not like most of the types, then don't use those types). I also made up some additional nonstandard ASN.1 types (called ASN.1X), which also might be useful for some applications; you are not required to use or implement these either.

> but try to consider these groups: older people who will not learn precise right hand movement anymore, people with temporary or permanent right hand injury, people with no right hand, people with missing right hand fingers, etc.

Perhaps, but that does not seem to be a software issue, at least, not a software issue with the X window system itself. If you want to consider such things, it is probably more important if someone who is concerned about such things wants to design hardware specifically for such people.

Allowing you as long as you want to type something instead of adding a time limit can be helpful for such people (since having less fingers or only one hand might make it take longer to type) but it can also be helpful for any other people for whatever reason (e.g. you have to answer the telephone before continuing to type on the computer, etc).

Accessibility features are for everyone.

I am not sure that it matters; you can already remap the keyboard and mouse in X windows, and if it helps to design input devices differently for left-handed people, then that would be managed by someone else.

However, if they add the possibility to use touch-screens (although I don't like touch-screens, some people might want to use it), then considering being left-handed vs right-handed might potentially be significant when designing a GUI library or a GUI program, although even then it is not certain that it will.

Still, if something does affect the users in this way (with accessibility, which involves other things too; and accessibility is not only for people with the relevant disabilities, but is for everyone (including people with those disabilities)), then it is true that having people who use those accessibility features (and whatever other features you might add or change, even if they are not accessibility features) in the testing team is helpful, so yes, that is a case. However, it is FOSS and does not necessarily need a dedicated team for testing. They do say anyone who wants to and is able to work on it is allowed to do so, so if someone is concerned with this then hopefully they can help, too.

Not all of the functions can be controlled by the flags, though.

It isn't DEI. The problem with modern politics is that one side is DEI and other side is racist and they are both bad. Xlibre specifically says they are neither, and therefore it is better.

I think it is good that they are free from DEI, as long as they are not racist instead (and the next paragraph after the one mentioning DEI says they are not racist, so that is good). Avoiding one does not mean you need to have the other one, even though some people seem to think that it does.

> If the dev was hoping to keep their project "apolitical," they should probably leave out the two paragraphs of politics...

That might have been a good idea, to avoid mentioning such things if they are unnecessary to do so, but now it is done. It can be changed (and maybe it should be changed), but I do not really care much if they change it or not.

You might want some of the new features (such as TLS 1.3, WebP, some security fixes, etc), but avoid some others (such as HSTS, many new web APIs, secure contexts, AI, some CSS commands, etc), and want to keep some features that are removed in later versions (such as several settings, and many other things).

ASN.1 has support for ISO 2022 as well as ASCII and Unicode (ASCII is a subset of Unicode as well as a subset of ISO 2022). (My own nonstandard extensions add a few more (such as TRON character code and packed BCD), and the standard unrestricted character string type can be used if you really need arbitrary character sets.) (Unicode is not a very good character set, anyways.)

Also, DER allows to indicate the type of data within the file (unless you are using implicit types). Protobuf has only a limited case of this (you cannot always identify the types), and it requires different framing for different types. However, DER uses the same framing for all types, and strings are not inherently limited to 2GB by the file format.

Furthermore, there are other non-scalar types as well.

In any of these cases, you do not have to use all of the types (nor do you need to implement all of the types); you only need to use the types that are applicable for your use.

I will continue to use ASN.1; Protobuf is not good enough in my opinion.

Numbers bigger than 64-bits, character sets other than Unicode (and ASCII), OIDs, etc.

I do not agree. Which parts are necessary depends on the application; there is not one good way to do for everyone (and Protobuf is too limited). You will need to implement the parts specific to your schema/application on each end, and if the format does not have the data types that you want then you must add them in a more messy way (especially when using JSON).

In my opinion, Free Hero Mesh is better, although each has its own advantages and disadvantages compared with the other(s).

(There are also some variants of PuzzleScript, which add a few extra functions.)

it is not necessary to use or to implement all of the data types and other features of ASN.1; you can implement only the features that you are using. Since DER uses the same framing for all data types, it is possible to skip past any fields that you do not care about (although in some cases you will still need to check its type, to determine whether or not an optional field is present; fortunately the type can be checked easily, even if it is not a type you implement).

I also think ASN.1 DER is better (there are other formats, but in my opinion, DER is the only good one, because BER is too messy). I use it in some of my stuff, and when I can, my new designs also use ASN.1 DER rather than using JSON and Protobuf etc. (Some types are missing from standard ASN.1 but I made up a variant called "ASN.1X" which adds some additional types such as key/value list and some others. With the key/value list type added, it is now a superset of the data model of JSON, so you can convert JSON to ASN.1X DER.)

(I wrote a implementation of DER encoding/decoding in C, which is public domain and FOSS.)

There are many that are specialized for different uses in games, such as:

- ZZT-OOP

- MegaZeux Robotic

- ZIL

- MESH:Hero

- Free Hero Mesh

- Super ZZ Zero

- OHRRPGCE HamsterSpeak

(There are probably a lot more that I had missed)

All of these are specific to the specific kind of games being made with them, though; different kind of games will require a different kind of logic.

MESH:Hero is specific to a specific kind of puzzle games, and Free Hero Mesh is a FOSS clone of MESH:Hero with a different syntax and more features.

There are ways around some of the issues there, such as using the GitHub API (I almost exclusively use the API), and/or using a user script (see below). Furthermore, on GitHub and on some other version control hosting services (such as GitLab), you can change "blob" to "raw" in the URL to access the raw files. However, as they say, it can be mirrored on multiple services (including self-hosting), and this would be a good idea, whether or not you use GitHub, so if you do not like GitHub then you do not have to use it.

Note that for some of the web pages on GitHub, the data is included as JSON data within the HTML file, although this schema is undocumented and sometimes changes. User scripts (which you might have to maintain due to these changes) can be used to display the data without any additional downloads from the server, and they can be much shorter and faster than GitHub's proprietary scripts.

Using a GPG key to sign the web page and releases is helpful (for the reasons they explain there), although there are some other things that might additionally help (if the conspiracy was not making it difficult to do these things with X.509 certificates in many ways).

I am not a lawyer and do not know all of the other things, but I will write what my idea is.

Some possibilities (while still being FOSS) might be:

- Use AGPL3 license, and do not make exceptions. (Alternatively, make an exception but make it possible to revoke the exception.)

- Design the program for uses that are not bad so that bad uses might be more difficult.

- Sue them, if this becomes necessary.

These combination might make it difficult for bad guys to use it for bad purposes, although some organizations might ignore the license and use it anyways, but you cannot really prevent that.