zzo38computer

I think that it should not need to be mutually exclusive. You can make it you can enter the programs yourself (if you prefer to do for whatever reason, including, it does not work well (like you mention), or because of Dijkstra objection or other objections to the use of AI for programming the computer or AI in general), but that AI can also be possible.

> At home, I use software that is well-crafted to do some thing. Or I write a series of scripts to do narrow things that for some reason aren't in Aptitude or Snap, for example "copy all the photos off my iPhone and rename them and sort them by date in my filesystem".

> Perhaps I have no imagination, but I don't feel like having an LLM make applications on my phone. I want good software that someone that I trust wrote.

I do not use LLM either, and do not intend to do. I can write my own programs. Even if someone does want to use LLM, it should neither be required nor expected nor the default (and there are also reasons why I think that it should be discouraged to use LLM too much); you should be able to write the scripts and programs by yourself if you want to do it that way (and the computer made to make this possible to do without LLM), even if some people can make LLM to do it at their option, but it should not to require LLM and AI.

I also think that the computer that can start with a programming language such as BASIC or Forth (without first needing menus and GUI to access all of the programs) is useful, and that it is not as good that many modern computers do not do like that.

I think that 2D graphics and games is not bad. For some things, 3D graphics might be helpful, especially if there is also 3D physics, but many games should not need 3D.

I have different ideas about the UI. We don't need the AI and fancy graphics (animations can be limited to showing where an object is moving to, and a setting can be added to control the animation speed including to disable it entirely). Being able to use programs and data together is helpful (something mentioned in the article), and then to be able to use Command, Automation, and Query Language to do queries and batch operations with them as well. You could put multiple data in one file, and include one kind of data in the other one, etc; it is not plain text but is many types of data. I made a repository with some of my ideas about computer and operating system design (this would be a part of improving it, since the existing systems have limits) and would write more in future. UI and UX is not the only issue, but also security and many other things.

If the interface is documented and can also be used without AI, and you can write your own software instead if wanted, then that will be more helpful, I think. (Someone who does want to use it with the AI can still do so, without forcing everyone else to also do.)

You shouldn't need LLM and AI to do such things. Even if such things might be useful to some people, I might want to use the API without LLM/AI and just to read the API documentation and then to make my own, and some other people might want to do similarly. In the specific case of e-commerce, I had been making my own specification of a file format for e-commerce (which is independent of the protocol), which is not intended to use with LLM/AI, but instead is intended to avoid many kind of dishonest business while also being flexible and that you could make and use your own software or some other implementaiton instead of being forced to use their UI/UX.

> namely both "private" and "public" key are the same thing; the labeling "public" vs. "private" reflects your arbitrary choice of which of one you give away, and which one you keep for yourself.

It is not quite arbitrary. With RSA, you could potentially store only the modulus and the exponents, publishing one exponent and keeping the other one private (or making each privately known to different people, with both having the modulus). However, the way it is commonly stored is with the private key file includes both exponents and several other numbers, and the public exponent is usually 65537 which makes it easy to guess so you cannot effectively keep it secret. With some other kinds of cryptography (other than RSA), you can figure out the public key from the private key even without doing things like this.

In some programming languages with RPN you can avoid this problem, because it makes sense to put it in the stack as the initial value, and then you can as easily have multiple initial values; and then the callback function can read that from the stack that you had put there, like anything else you will push into the stack to read it back later. For example, in PostScript you can write something like:

  0 exch {add} forall

However, this is not as good if you want to use the first element as the initial value instead, but still it can be done but it is then not as simple (unlike in programming languages that do not use RPN but instead with function call with arguments, in which case it might be simpler).

I guess names as SELECT and WHERE are like SQL (although SQL works differently than other programming langauges).

Something that bothers me (even though I do not drive a car and do not intend to, but sometimes am a passenger) is windows that require electric controls to operate and cannot be operated manually.

It doesn't load for me, but I have read the other comments.

There is the problem of TLS and X.509 being used with centralized authorities like this, even though it is not inherent to TLS nor to X.509 (although they were designed to be used in this way). In some circumstances, you can get a copy of the certificate (which might be self-signed) from somewhere else and then check that it matches in this circumstances. In other circumstances there are other things that can be done (e.g. TOFU, which has a different set of problems, but also has advantages in a different set of circumstances). What the security requirements are will depend on the circumstances, which can also depend on the user's intentions; they should not have to depend on a centralized authority.

(There is the issue that a single X.509 certificate cannot have multiple issuers, though. There is also the issue that X.509 certificates cannot contain unsigned extensions (they could be added after the signature, but an implementation might check for additional fields after the signature and reject a certificate that has any). Although an alternative schema can be made (I have done so), it would not work with the existing protocols.)

I think it would be a good idea. TLS and X.509 would work better that way. Actually, both sides should have a certificate (the bank might issue a certificate to the customer).

It won't do for all circumstances (as some other comments mention), but when it is possible, it would be a good idea.

One possible alternative might be to add the ability for user configuration to substitute one certificate for another one (both will need the same public key and subject name, but the substitute will not be self-signed (since you do not have the private key)), and to use the data in the substitute certificate instead of the original. If the name constraints extension is implemented, then it would make this and other things possible. Since the substitute certificate will be considered trusted, it is not necessary for the substitute certificate to have a signature (if it does (e.g. because you got it from somewhere else instead of making it yourself), then the signature can be ignored), nor is it necessary for the substitute certificate to be issued by anyone (this applies even if it is the end certificate being substituted).

I think some servers do not send a copy of the root certificate to the client. In this case, what I described above might already be possible even if that feature has not already been added to existing implementations, as long as it does not require the installed certificate to be self-signed.

I also don't like the idea of putting cameras all over my house and having ad companies surveil my intimate space, and I also don't like to add further things that require electrical power, and/or that make noise, etc. This is in addition to the security ramifications that you describe and that you don't describe, and other issues.

If you disable JavaScripts then you will get a non-interactive version (with a note that says you can enable JavaScripts for the interactive version), so you might try that.

I mostly agree, although if the manufacturer has a catalog of software (which they have managed to check for quality, classification, etc) that you can optionally use for installing software (which others can also choose to do, e.g. in the case of Android there is also F-Droid), but that you can also install anything that you want to do by yourself (including software that you wrote by yourself) without needing to be able (or willing) to contact (or have anything further to do with) the manufacturer (for any reason), then it can be helpful.

Also, if someone provides a service (e.g. Netflix) that some might want to use and some might not, then you have the option to use that service might be helpful but even that should not require any relationship with the manufacturer unless they are also providing the service. If the manufacturer is separate then they should not have anything to do with it (e.g. they should not add a button on the remote control specific for Netflix; if they have user programmable buttons that you can add your own labels, then it would be possible to use such a thing like that if the end user decides to install Netflix). (There are other problems with Netflix too but I am ignoring them for now because that would be a separate discussion.)

(If the message is not displayed, try appending ".json"; in my experience, this works on some Mastodon servers (and some others too) but not others, and works on this one. However, I will repeat it here because it is short enough.)

> Copyright does far more harm than good and should be abolished. It doesn't protect the livelihood of individuals and small businesses in practice. Instead, it's a weapon wielded by large corporations to protect their monopolies. It's abused to take down content that's not in violation of copyright and to restrict people being able to use/repair/modify/backup their property. Large corporations getting special exceptions from it didn't start with LLMs.

I agree that copyright should be abolished, and have said such thing in the past, and other people have said such things too. These are some of the significant problems with it, but not necessarily the only problems. Even if there are some cases where it is beneficial, I think that they would generally work better if copyright were abolished and then such cases would become unnecessary.

Patents should also be abolished.

Neither authentication nor authorization is solved very well in general, although in some specific cases they are partially solved.

For working on a single computer, I think capability-based security with proxy capabilities is helpful for both. This won't do alone; however, you can add a user account database and you can handle permissions made out of such a capability-based security, which can be flexible because each process can have different permissions, and with proxy capabilities it is possible for the permissions to do things other than the fixed set of permissions.

For working on multiple computers, I think X.509 certificate chains is helpful for both. You can check that the user can authenticate with the key in the end certificate, and can look in the certificate chain for a recognized authority and know what permissions it has, and then check if the required permissions are granted either by all certificates leading to and including the end certificate, or only the end certificate, depending on the type of permissions (e.g. extended key usage might only be needed by the end certificate, while such things as what files it is allowed to access and how it can access them must be permitted by the entire chain in order to be granted). Extensions can be added to specify any additional details required by the authorization and/or authentication needed by your application. (The use of X.509 certificate chains also means that you would not need API keys, nor passwords (the private key can be passworded if you want to, but the server never sees the password, and therefore cannot steal it).)

I think that the fines should be the amount per crime that is being fined, plus the total amount of all revenue from whatever the fines are related to (including indirect, but only counted once).

Most TV sets should not normally need microphones, and if they have that in some models (as long as there are models without), then there should be a hardware switch to disable them. However, "continuously sweep home networks, map secondary devices, and log microphone audio while appearing to be turned off" is also stealing and wasting your power.

> I have gone and ticked the “stop hiding file extensions” since they were introduced in ~98 (or was it Windows 95?)

I think Windows 95, although even selecting that option still hides some file name extensions (such as ".lnk"). However, I have found that it is possible to use the registry editor to force all file name extensions to be displayed.

People have managed (and sometimes do manage) to do without golf courses and refrigerators and dishwashers and cars (and roads for cars) etc, and should learn to be able to manage to do without such things, for multiple reasons.

> for UTF-16 you've already got UTF-8 and given that even Microsoft have abandoned BMP strings I doubt any attempt to reintroduce it will get much traction

This is not reintroducing anything; the BMP type is already there, although its meaning is expanded (the existing BMP type is effectively a constrained subtype of UTF-16). Although most applications probably will not use UTF-16, it might sometimes be useful in some applications where it is more useful to store UTF-16 instead of converting to/from UTF-8.

> relative OIDs already exist

Yes, although I have given a standardized name and semantics to something that is allegedly already a common use (and is one that I often use in my own projects), which the official specification from ITU admits. It uses the existing OID and relative OID types (and the same type numbers as them), and is like a CHOICE between them (implementations may treat it as such).

> BCD strings are just constrained PrintableStrings

The abstract meaning matches that of constrained Visible (not Printable) strings, but the encoding is more compact.

> UTF-8 won for all of the string types

Although it is common (and some other formats don't support other string types), I disagree, and I think that one character set cannot be useful for all purposes, and furthermore that Unicode is not that good and has many problems.

> Reference sounds like an EXTERNAL, OOB sounds like an ANY DEFINED BY

I don't think so. It seem like different to me.

I might have misremembered then, or maybe it was someone else.

I do not use the ASN.1 schema format, and have not written a specification for how the new ASN.1X features would be used in the ASN.1 schema format, although someone who is interested to do so might be able to help to write such a thing. (An alternative might be to make up a different schema format for use with ASN.1X.)

ASN.1X is mostly just a list of additional types, although there is also another serialization format called SDER which is between BER and DER (any valid DER is also valid SDER and any valid SDER is also valid BER), and is intended for when you do not quite need a canonical form but still want the simplicity of DER; one of the things that it allows is overlong length encodings (which is useful when the encoder wants to encode items to a file individually but then go back to encode the length afterward).

The additional types include:

- UTF-16 string: Same as BMP string but non-BMP characters are also allowed (as surrogate pairs). The type number is the same as BMP string.

- OBJECT IDENTIFIER RELATIVE TO: Either a absolute or a relative object identifier; what it is relative to might be either fixed or given elsewhere in the data, depending on the schema. This is equivalent to a type given in the appendix of the official specification of ASN.1, except that it is now a standardized type, and the canonical form (even in SDER, so that a reader does not need to check for both cases) is required to use the relative format if possible.

- BCD string (64): A string of 4-bit characters, with the high nybble first in each byte. The characters come from the character set 0 1 2 3 4 5 6 7 8 9 * # + - . space and it should be padded with a space on the end if necessary.

- PC string (65): A string of characters in the PC character set (or a related character set in some cases). Note that control characters can also be used as graphic characters.

- TRON string (66): A string of TRON characters, encoded as TRON-8.

- Key/value list (67): A set of keys (without duplicates) with associated values. The keys and values can be any type allowed by the schema. In canonical form, they must be sorted by keys in the same order that a SET is sorted (but the values are kept with the corresponding keys). (This is the only one of these nonstandard types which is used for representing JSON data; all of the other JSON types correspond to standard ASN.1 types.)

- Out of band (72): The format and usage of this type depends on the communication channel being used, and is intended for including things inside of the ASN.1X data which is separate from the ASN.1X data, such as file descriptors. This type is not intended for storage in files, and some programs that relay messages may need special handling of this type if it is used (for this reason, it should not be IMPLICIT).

- Reference (74): A reference to another node within the same file (schemas may restrict which nodes can be referenced). The encoding is like a relative OID but the first number is how many times to go to the parent node (0 means the reference itself), and then the rest of the numbers are the zero-based index into the node referenced by the previous number.

- Identified data (75): Contains a set, followed by the payload (of any type), followed by an optional key/value list where the keys are OIDs. The set is used to identify the format, and it can contain OIDs, object descriptors (only expected to be used in error messages and stuff like that), and sequences who first element is a OID; and should not have duplicates. This type may be used as the top-level type in a file in order to identify the file format, but can also be used inside of the file in case the existing types are considered to be insufficient for this purpose.

- Rational number (76): Contains two integers, being the numerator and denominator. The denominator must be greater than zero. If it is canonical form, then it must be lowest terms.

- Translation list (77): A key/value list where the keys specify the languages (null means the default), and is expected to be used where it could be replaced by the appropriate value according to the l10n.

- Scientific number (78): Same as a real number except that the number of digits (or bits) is considered to be significant. Decimal numbers must be NR3, and if it is canonical form then there must be exactly one digit before the dot.

There are also additional situations where the standard ASN.1 schema format does not seem to specify (although as I mentioned above, there is currently no standardized schema format for these things), such as: regular expressions for octet strings (and bit strings), constraining types as though it is another type (e.g. limiting a UTF-8 string to a number of bytes instead of (or in addition to) code points), constraints about what control characters are allowed in a General string (I think it is rarely useful to allow all control characters), etc. (Also, I disagree with the standard recommendation to use automatic tags; I think that manual tags are better and make both the schema and the data files clearer and easier to understand.)

I seem to remember reading somewhere that Marilyn vos Savant had said that it is acceptable to use a calculator when learing arithmetic (I do not remember the reason given) but that clocks should not be used to learn time. (I might be mistaken, since I do not remember for sure.)

In my opinion, JSON is not the best format and has some problems. Lack of comments is one of the reasons, as they mention in there. Another is the lack of trailing commas (optional trailing commas would be useful for manually written files). However, these are problems with the syntax, and there are also problems with the data, such as a lack of a proper integer type, lack of Infinity and NaN, lack of support for character sets other than Unicode (and ASCII), lack of proper octet string type, etc.

That is not quite true, because you have to define "numbers" and "strings" more specifically; JSON uses Unicode strings, and how numbers work depends on the implementation (but are generally finite 64-bit IEEE floating point; JSON does not have Infinity and NaN).

ASN.1 is almost a superset, but lacks a key/value list type; I had made some nonstadard extensions called ASN.1X and one of my new types is a key/value list type, so that makes the data types of ASN.1X a superset of JSON (although the format is different, it makes that all JSON data can be represented using DER if the nonstandard key/value list type of ASN.1X is used).

I don't like JSON that much because of its many problems (some are problems with syntax, others are problems with the data), so I use ASN.1X instead (with the DER format), for my own stuff (but I also deal with JSON because it is common enough).

I do not (and never had) a smart phone, either.

I have been at one restaurant that had a QR code to view the menu, although they did provide a iPad to any customer who needed it. (At the time, I was with someone else who had their own iPad.) It was not very good food (and badly managed) so I do not intend to return there in future.

If you do not want to print the menu in multiple paper copies, then you might consider a single epaper display somewhere that the customers can easily see (anyone with a camera or a camera phone can take a picture; someone with pencil and paper might copy it out by hand).

Line Mode Browser has some features that have not been found anywhere else. (In some cases, old version of Firefox can be hacked to support a few of them, such as that URLs entered by the user are treated as relative to the current document; Lynx doesn't do that. But, there are also such things as the ability to pipe the output to another program, directly invoking HTTP methods, display a numbered list of links in the current document (also should be easy to do in most web browsers by adding an extension), direct cache management, etc.) I would rather avoid many of the features that Firefox and Chrome have, including CSS, JavaScripts (although JavaScript codes entered by the end user can be useful for the purpose of querying JSON data returned by the server, because such a situation is common enough to be worth), favicons, HSTS, etc, but include some features such as TLS 1.3. Some features that would be useful, I don't see anywhere, such as displaying a table of contents menu based on the <h1> etc in the HTML, commands to sort tables, saving form data to the local disk and later recalling it, calling external programs to edit text, etc. However, they just put too much stuff and make it more complicated than it should be, and many of the actual useful features are omitted. I don't want inline pictures, videos, etc either. However, some of the web developer tools can be useful, because e.g. you can display a list of the network requests.

I think not quite, although many planets have the names of the gods. They called them planets due to their motion, so it is still called that. The use of the same word in different contexts can have different usages and different (but sometimes related) meanings. "Planet" is used differently in astrology than it is in science (astronomy); this isn't a contradiction (although, like any words, can sometimes result in confusion if you do not make the meaning clearly).