zzo38computer

CTRL+C will send a interrupt signal; in some programs (and some circumstances in some programs) that does not work, but then you might try CTRL+\ which will send a quit signal; sometimes that works even if interrupt does not work.

I do not care about much of it other than the git and API. I also sometimes use the Issues, although only with the API. But if it stops working sometimes, that is not too significantly a problem since the files can be sent after they start to work again; it does not have to be immediately.

I think it would be a bad idea to require an internet connection (for one thing, you might want to write your own app that does not require a internet connection); but, even if it doesn't, would not mean you can set the clock to avoid the delay, because it could be made to reset the delay if the clock is set.

What might help better is having permissions that you can set separate settings that can be read for different apps (including the possibility to return errors instead of the actual values), even if they can be read by default you can also change them per apps. (This has other benefits as well, including possibility of some settings not working properly due to a bug, you can then work around it.)

> People will still do financial transactions on an unencrypted web because the utility outweighs the risk. Removing encryption just guarantees the risk is high.

That does not necessarily require TLS to mitigate (although TLS does help, anyways). There are other issues with financial transactions, whether or not TLS is used. (I had idea, and wrote a draft specification of, "computer payment file", to try to improve security of financial transactions and avoid some kinds of dishonesty; it has its own security and does not require TLS (nor does it require any specific protocol), although using TLS with this is still helpful.) (There are potentially other ways to mitigate the problems as well, but this is one way that I think would be helpful.)

> If your microcontroller can't do TLS then it probably won't do GPG either.

It is not a problem if you are only serving static files.

> I think that the "small web" should reject encryption, which is the opposite direction that Gemini is taking.

I think it should allow but not require encryption.

> Removing encryption means that you can't reasonably do financial transactions, accounts and access restriction, exchange of private information, etc... You only share what you want to share publicly, with no restrictions. It seriously limits commercial potential which is the point.

Note that the article linked to says "the Gemini protocol is so limited that it’s almost incapable of commercial exploitation", even though Gemini does use TLS. (Also, accounts and access restriction can sometimes be used with noncommercial stuff as well; they are not only commercial.)

> It also helps technically. If you want to make a tiny web server, like on a microcontroller, encryption is the hardest part.

This is one of the reasons I think it should not be required. (Neither the client side nor server side should require it. Both should allow it if they can, but if one or both sides cannot (or does not want to) implement encryption for whatever reason, then it should not be required.)

> Anyone can man-in-the-middle and change the web page, TLS prevents that. But what I think is an even better solution is to do it at the content level: sign the content, like a GPG signature

Using TLS only prevents spies (except Cloudflare) from seeing or altering the data, and does not prevent the server operator from doing so (or from reassigned domain names, if you are using the standard certificate authorities for WWW; especially if you are using cookies for authentication rather than client certificates which would avoid that issue (but the other issues would not entirely be avoided)).

Cryptographic signatures of the files is helpful, especially for static files, and would help even if the files are mirrored, so it does have benefits. However, these are different benefits than those of using TLS.

In other cases, if you already know what the file is and it is not changing, then using a cryptographic hash will help, and a signature might not be needed (although you might have that too); the hash can also be used to identify the file so that you do not necessarily need to access it from one specific server if it is also available elsewhere.

> Well, if want to protect yourself, TLS won't save you, you will be given away by your IP address, they may not see exactly what you are looking at, but the simple fact you are connecting to a server containing sensitive data may be evidence enough.

There is also SNI. Depending on the specific server implementation, using false SNI might or might not work, but even if it does, the server might not provide a certificate with correct data in that case (my document of Scorpion protocol mentions this possibility, and suggestions of what to do about it).

I think a "force visible ASCII for files whose names match a specific pattern" mode would be a simple thing to help. (You might be able to use the "encoding" command in the .gitattributes file for this, although I don't know if this would cause errors or warnings to be reported, and it might depend on the implementation.)

I use non-Unicode mode in the terminal emulator (and text editors, etc), I use a non-Unicode locale, and will always use ASCII for most kind of source code files (mainly C) (in some cases, other character sets will be used such as PC character set, but usually it will be ASCII). Doing this will mitigate many of this when maintaining your own software. I am apparently not the only one; I have seen others suggest similar things. (If you need non-ASCII text (e.g. for documentation) you might store them in separate files instead. If you only need a small number of them in a few string literals, then you might use the \x escapes; add comments if necessary to explain it.)

The article is about in JavaScript, although it can apply to other programming languages as well. However, even in JavaScript, you can use \u escapes in place of the non-ASCII characters. (One of my ideas in a programming language design intended to be better instead of C, is that it forces visible ASCII (and a few control characters, with some restrictions on their use), unless you specify by a directive or switch that you want to allow non-ASCII bytes.)

JSON does have data types, although there are not very many and not very good. For example, there is no octet string type (so you will have to use hex or base64 instead), no non-string keys (so you have to use strings instead), no character sets other than Unicode, no proper integer type (you will either have to use the existing numeric type or use a string instead; I have seen both ways done), etc.

YAML is worse in many ways, though.

XML has no data types but does have data structures.

I prefer to use DER (which also has some problems, but they are much less bad in my opinion).

They mention those things, but they do not mention ASN.1.

I agree it makes sense to specify that it is not certain, by adding "it looks like" (or "it seems like", or other wording that would not be too long; as another comment mentions, "looks" can sometimes be wrong). The other stuff might be unnecessary, although it might depend if it is implied or expected according to the context (in many contexts I would expect it to be unnecessary; another comment mentions how it can even be wrong sometimes).

(Your message is better than the one with a lot of noise, though.)

I would want to use the license that does not ask for credit; the only requirement is that any further restrictions are not legally effective (except that, for practical reasons, it is allowed to be relicensed by GPL and AGPL (if you are able to follow all of the requirements of those licenses) in order to combine it with software having such licenses).

In my opinion, a separate software should be used for the end-to-end encryption than for the communication, although there are other things to do for security other than only programming the computer correctly (such as securely agreeing the keys and ciphers in person).

I mostly agree (although sometimes it is necessary to talk to someone about it); it would be better to actually have good documentation (so that you do not need to talk to someone about it).

A warning label like you mention is a possibility if that is considered to be necessary, although I think it might be better to have a file that you can download and read (or request by mail or telephone or fax, if this becomes necessary in some circumstances; do not assume the computer always works and is compatible with your file), instead of a searchable wiki.

> You could change the option to hide file extensions in the explorer settings windows; no registry tweak was needed.

The is a setting in Explorer, but it does not affect all file types; some (such as .lnk) are not affected by that setting and hide the extension anyways.

Status lights can be helpful, although they should be dim, and should be red or green (or possibly yellow) rather than blue or white (unless you have already used the other colours and now you need more colours).

> The issue with this type of design is that it completely tanks discoverability.

There are still ways to help, such as having a menu bar, and having good documentation. (Documentation is more important, in my opinion; but both are helpful.)

> After nearly 30 years of tech life myself, I've come to the realization that the best UIs are not graphical. They can have graphical elements mostly for visualization purposes, but all of them should be as minimal and unobtrusive as possible. Any interactivity should be primarily keyboard-driven, and mouse input should be optional.

I agree, that the interactivity should be primarily keyboard-driven. However, mouse input is useful for many things as well; if there are many things on the screen, the mouse can be a useful way to select one, even if the keyboard can also be used (if you already know what it is, you can type it in without having to know where on the screen it is; if you do not know what it is, you can see it on the screen and select it by mouse).

> Forcing users to click on graphical elements presents many challenges: what constitutes an "element"; what are its boundaries; when is it active, inactive, disabled, etc.; if it has icons, what do they mean; are interactive elements visually distinguishable from non-interactive elements; and so on.

At least older versions of Windows had a more consistent way of indicating some of these things, although sometimes they did not work very well, often they worked OK. (The conventions for doing so might have been improved, although at least they had some that, at least partially, worked.)

> A good example of bad UI that drives me mad today on Windows 11 is something as simple as resizing windows. ... it's not clear where the "grab" area for resizing a window exists anymore

I had just used ALT+SPACE to do stuff such as resize, move, etc. I have not used Windows 11 so I don't know if it works on Windows 11, but I would hope that it does if Microsoft wants to avoid confusing people. (On other older versions of Windows, even if they moved everything I was able to use it because most of the keyboard commands still work the same as older versions of Windows, so that is helpful (for example, you can still push ALT+TAB to switch between full-screen programs, ALT+F4 to close a full-screen program, etc; I don't know whether or not there is any other way to do such things like that). However, many of the changes will cause confusion despite this, or will cause other problems, that they removed stuff that is useful in favor of less useful or more worthless stuff.)

I have used both Windows 3.1 and Windows 95. Windows 95 does have some significant benefits (e.g. you can start Windows programs from the DOS prompt (I seem to remember that you cannot do this in Windows 3.1 and in Windows 95 you can, but I am not sure if I remember correctly), and the WIN+R shortcut, and some others), but also many problems (although some can be avoided by changing stuff in the registry; I had done that to force it to display the file name extensions for all file names, rather than hiding them even if you tell it to display them; I also dislike their decision to use spaces in file names).

> So where the old toolbar used to hint you the keyboard shortcut in a tooltip every time you rested your mouse over a button, the new one doesn't

Although it is bad that it does not display the keyboard shortcuts, you can push ALT and then it will tell you which letter to push next. (I just guessed that pushing ALT might do something (possibly display a menu?), and I was correct (it did not display another menu, but it did help).) This is not quite as good as using the other keys such as CTRL, or numbered function keys, but it is possible.

(I do not use those programs on my own computer, but on some other computers I sometimes have to, and this helps, although not as well as it would to use menus and other stuff instead. However, in some cases I was able to use it because of knowledge of older versions of Microsoft Office; many of the keyboard commands are the same.)

I think the menu bar is much better, and toolbars should not be needed for most things. With the menu bar it will underline the letters to push with ALT and also will tell you what other keys to use (if any) for that command. (One thing that a toolbar is helpful for is to display status of various functions that can change, such as the current font. Due to that, you might still have a toolbar, but you do not need to put everything in the toolbar. Perhaps combine the toolbar with the status bar to make it compact.)

(Something else that would improve these word processing software would be the "reveal codes" like Word Perfect. A good implementation of reveal codes would avoid some of the problems of WYSIWYG. For spreadsheet software, arranging the grid into zones, and assigning properties (including formatting and formulas) to zones, and making references work with zones, etc, would be helpful, but I don't know that any existing software does that.)

In my own software I do try to make the display compact so that there is more room for other stuff, instead of needing to put all of the commands and other stuff taking up too much space in the screen. Good documentation is helpful to make it understandable; this would work much better than trying to design the software to not need documentation, since then the lack of doumentation makes it difficult to understand.

I also thought of that too. It would allow what I mentioned and what you mentioned. If you want to hide messages from specific users (or other criteria), then that would also be possible.

I would prefer to do the opposite, where everything is displayed in chronological order (with an option to display by threads or not; even if not you can still find what each one is a reply to) regardless of voting and regardless of who wrote them.

Some people have said, use a unadorned staff for zero, and six being a triangle in the other direction instead; that is what I thought too, and some other people also do.

I also wrote a program in PostScript to draw Cistercian numbers (which uses the nonstandard sign for 6):

  % Specify a four-digit number as the command-line argument.
  /A ARGUMENTS 0 get def
  
  /Digit {
    get 48 sub {
      {} %0
      {24 0 rlineto} %1
      {0 -24 rmoveto 24 0 rlineto} %2
      {24 -24 rlineto} %3
      {0 -24 rmoveto 24 24 rlineto} %4
      {24 0 rlineto -24 -24 rlineto} %5
      {24 -24 rlineto -24 0 rlineto} %6 (nonstandard)
      {24 0 rlineto 0 -24 rlineto} %7
      {0 -24 rmoveto 24 0 rlineto 0 24 rlineto} %8
      {24 0 rlineto 0 -24 rlineto -24 0 rlineto} %9
    } exch get exec stroke
  } bind def
  
  4 setlinewidth
  6 6 moveto
  gsave
    36 0 rmoveto
    0 72 rlineto
    gsave
      -1 1 scale
      A 2 Digit
    grestore
    A 3 Digit
  grestore
  36 72 rmoveto
  1 -1 scale
  0 72 rlineto
  gsave
    -1 1 scale
    A 0 Digit
  grestore
  A 1 Digit
  
  showpage quit

I would agree that binary formats can be much better. Sometimes you can use fixed fields, but there are also structured formats such as DER (which is generally better than JSON in my opinion). JSON has many problems, including that it does not have a non-Unicode type (so you must use base64 encoding or hex encoding instead and that isn't very good), and other problems. Parsing it will also mean that you must handle escaping.

I agree, that I do not like automatic semicolon insertion (in my opinion it is one of the worst features of JavaScript, and possibly the really worst one), and I think it is a good idea that you should use semicolons or whatever to separate expressions and statements (except for a programming language where it is already unambiguous (e.g. because you are required to have brackets around them instead), in which case it is unnecessary).

However, spaces, line breaks, tabs, page breaks, etc are not normally tokens (and should not be tokens), but will separate tokens.

However, that is not the only issue with the syntax, although it is a significant one.

I like this idea, although I think that they should be only one code, which might program both the foreground and background (and font styles if applicable), rather than separate codes for foreground and for background.

If I make a terminal emulator, I would probably not support true colours in text but only in pictures (and it would be possible to disable pictures). I probably would not implement 256-colours either, because I agree with you; the user configures their own colours to use, and the terminal should use them. For text, only sixteen colours can be used.

Similarly, the user can also set their own fonts for the terminal, just as you can with colours and other functions. (However, some programs will have a reason to configure the fonts and palettes for the specific use, although most won't and even if they do the user might disable those features.)

A program can have an option (possibly by environment variable) to disable colours entirely; this might be necessary even if you can disable colours in the terminal emulator, because a program might want to use such things as reverse video, underlined text, etc to indicate some things when colours are disabled. (Disabled colours can also be useful if you do not have a colour display or if you want to print out a screenshot without a colour printer.)

One problem with it is that a good contribution might be used even if it cannot be merged directly for whatever reason (although they might be listed as a co-author in that case).

Not everyone uses AI-driven softawre development, so some people who do not use AI-driven software development might still continue to make new programming languages. (I am one who does not use AI-driven software development.)

However, some people do use AI-driven software development, so it is also possible that some changes will be made due to that as well.