zzo38computer

This kind of proxy capabilities has other benefits as well, e.g. you can implement a disk quota, or transparent compression, or logging, or ask the user (if you have a capability which can do that), or provide access to a part of the file as though it is the entire file, etc.

Or, if a program requests access to a camera, you can provide a capability with a still picture, a video file, a filter (e.g. that resizes the picture or modifies the colour) from some source (including, but not limited to, a camera), etc; this can be helpful in case e.g. you do not have a camera on your computer, or for testing.

(Other people have similar ideas, sometimes independently than I do.)

There is also a way to transmit capabilities across a network; I had thought of how a protocol would be made to do such a thing.

How I had idea of a computer and operating system design, measuring time also requires a capability. Creating files (including temporary files) also requires capabilities. Shared memory is read-only by everyone; to be able to write to memory you must have exclusive access. All of these capabilities are not necessarily what the program using them intended them to be; they may also be proxies, or capabilities of the wrong type (the kernel does not know anything about the types of capabilities except those it created itself), etc. A proxy may limit communication from one program to a service. Using these as well as other things (including, but not limited to, the CPU design), there are things that can be done to mitigate these problems (including things necessary to mitigate other kind of timing attacks based on other capabilities, e.g. slowing down network access for purpose of testing its working on slow networks).

I think many people have had similar ideas, including I also had ideas about how to design computer and operating system, which can use proxy capabilities. (There are different kind of capability systems, and I think that proxy capabilities has more benefits than only security.)

There are still considerations when designing parts of the system to be secure, while also making them have the functions that are desired (although a proxy capability system can be used to add arbitrary further restrictions if needed), but the core system can use proxy capabilities as the core security system.

Hashes would still be useful, but that is if you want to check that the package is the one that you intended; it does not prevent you from installing or writing whatever program you want to do, nor to make the program secure, which would be done by separate mechanisms; however, knowing that the package is the one that you intended can be one of the steps of the security, but not the main one.

However, security is not the only issue in a computer and operating system design, although it is a significant issue.

Is there a proper full list without needing to download the very big ZIP archive file?

I don't know if it includes "every operating system I can think of". I can think of some things: TempleOS, BTRON (there might be more than one implementation; I know of an (apparently) abandoned FOSS implementation), Serenity OS, and some others that I do not remember what they are called.

Also, what might be useful for preservation is, in addition to the files and emulation, also the documentation for programming those operating systems. There would also be such a thing of consideration as documentation of old computers (including their instruction sets), which might be a separate project but potentially might be useful in combination with this.

Another thing would be somehow you can download individual systems together with information about the emulation, in case you want to use your own emulators for it instead of installing an existing collection with its own installers and launchers etc.

Some people mention uncommon features (and features that work in an unusual way). I think that would be worth making a article about too, and just because a feature is common does not necessarily make it good.

Even just disabling CSS makes it readable. For HTTPS, I think that (like someone else mentioned) it should be made optional (at least for read-only access to public files) rather than mandatory.

There is a lot more than only what they explain in that article (I don't know of any full implementation of Pokemon in Prolog, although there is an implementation in TypeScript).

For example, you can also switch out (to activate a different pokemon) instead of attacking (switching has priority over attacking, so if you switch out then the opponent's attack will hit your newly active pokemon).

There are also many calculations involved, and it can be helpful to know how most of them work.

I am guessing that service returns the XML file as a directory listing; the file called winbridge.html does exist in that directory (and contains a JavaScript code to redirect to a different URL). (Another comment said they shortened the URL to remove PII (which I am guessing was in the fragment part of the original URL; the JavaScript code makes a new URL from randomly selecting a domain name (even though the list has only one) and appending the fragment part as the path), so I suppose the file name was removed and then this directory listing is the result.)

At least in my opinion, it might depend what kind of game. For example, there can be: card game, certain kind of puzzle games, Pokemon game, etc. There might also be consideration of such things like what portability you want, what sandboxing you will want, etc.

(There are game engines that have their own programming language for those kind of game (and some of them are the ones I had made up too).)

Query strings do have uses (such as for searching files and some other kind of dynamic files), but you shouldn't add them to URLs that should not expect them. So, I agree that they would be right to refuse requests with UTM and other stuff added like that.

I think 404 probably makes the most sense as the response if a query string is not expected but is present anyways, although 400 might also be suitable.

It might be reasonable to have a separate key for "tab" vs "next field", as well as separate key for "line break" vs "send". (But, tab and line break are not applicable for all contexts.)

However, it might also be reasonable to have a key or key combination (some programs use ^V) to enter control characters as data rather than as commands.

It might also be a consideration when designing a new computer (which does not have to be the same as existing ones); I had thought about such things and may make such a consideration.

> To have it silently just start adding marketing copy to git commit messages is pretty bad. To have that added text not be visible to the user in the UI so they can remove it before commit is just much worse.

This is one of the problems, but it is not only one. To be better, should be:

1. It should be visible in the UI for entering the commit message, to make it clear what it is doing.

2. It should not add such a thing if the Copilot is disabled. (It is mentioned by dmitriv and would hopefully be fixed soon enough)

I do not use Copilot nor any other LLMs nor VS Code, but if the problems are corrected then I think the feature would probably be reasonable.

I would think that the thing to do about it (if you want to use VS Code at all; some people (such as myself) don't), should be to send a patch to prevent adding the Co-authored-by line if Copilot is disabled, so that it will only add that line if the Copilot is enabled.

There is another case, which is that the code is approved but not merged (in which case the maintainer may apply it manually (with changes), and might list the author of the PR as a co-author of the commit that applies those changes).

Yes, I know that (I was aware of both of these cases, as well as others). In those cases, there are characters that do not correspond to any Unicode characters.

Nevertheless, what I was saying is that many programs seem to be designed as though other character sets do encode subsets of Unicode, but actually they are different character sets and are not Unicode.

However, what I meant was, in addition to things like the examples that you have, other less obvious cases. Even if characters do correspond to Unicode (and sometimes there is more than one way to do it, which is the case for several PC characters), they are not necessarily supposed to work in the same way.

At best, Unicode could be used as an approximation if the other character sets cannot be used, although sometimes there are other ways to do it.

I think a open-source exemption would be acceptable (if done properly; another comment mentions a possible problem), even though I would think it would be preferable to not have such age-verification bills at all. At least, adding the exemption would be second best, which would be better than having the age-verification bills without a open-source exemption.

(As another comment says, it is still not good, but at least it is something.)

If they are misinterpreted, it is because the character encoding is not declared properly.

I still sometimes see mojibake in Japanese web pages, but sometimes it works; if it works, it is because the character encoding is declared properly.

In my opinion, EUC-JP is a generally better encoding of JIS (especially in e.g. C source code, which should not use Shift-JIS but EUC-JP is OK), but Shift-JIS does have some benefits in some circumstances (such as making a character grid with one byte per character cell; if using Shift-JIS for a Pascal source code then you should use (* *) instead of { } for comments please).

> Unfortunately no, Unicode is not simply a mapping of bytes to characters. It is a mapping of numbers to code points, and in some cases you can even get the same characters with multiple code point sequences (not a very good mapping!).

It is worse than that; you can also get different characters with the same code points, and also same code points and characters that should be different according to some uses, and also different code points and characters that should be same according to some uses, etc.

> A file isn't meaningful unless you know how to interpret it; that will always be true.

There are multiple levels of meaning, though; character encoding is just one part of it. For example, a text file might be plain text, or HTML, or JSON, or a C source code, etc; a binary file might be DER, or IFF, or ZIP, etc; and then there will be e.g. what kind of data a JSON or DER or IFF contains and how that level of the data is interpreted, etc.

> Cyrillic and Greek characters get two bytes, even when they are by definition identical to ASCII characters.

Whether or not they are identical to ASCII characters depends on the character set and on other things, such as what they are being used for; the definition of "identical" is not so simple as you make it seem. Unicode defines them as not identical, which is appropriate for some uses but is wrong for other uses. (Unicode also defines some characters as identical even though in some uses it would be more appropriate to treat them as not identical, too. So, Unicode is both ways bad.)

> This bloat is actually worse than the bloat you get by using UTF-8 for Japanese; Cyrillic and Greek will easily fit into one byte.

I agree with that (although I think UTF-8 should not be used for Japanese either), but it isn't because of which characters are considered "identical" or not. There are problems with Unicode in general regardless of which encoding you use.

Another way that the character encoding could be declared is ISO 2022. When using ISO 2022, the declaration of UTF-8 is <1B 25 47>, rather than the <EF BB BF> that XML and some other formats use.

However, whether you do it that way or another way, I think that the encoding declaration should not be omitted unless it is purely ASCII in which case the encoding declaration should be omitted.

Yes, I thought of what you mentioned too, and in my opinion, DER is a better format, and it is a binary format rather than text.

(In my ideas of an operating system design, there is a structured binary format (similar to DER but different) used for most files and data, so that the tools (and the command shell) would be usable consistently with most of them; and if some need special handling, you can use other programs and functions to convert them and/or handle them in a way that can be interoperable.)

I agree with you that Unicode is too complicated and messy, although it also shows that whether or not something is considered "plain" is itself too difficult.

Unicode has caused many problems (although it was common for m17n and i18n to be not working well before Unicode either). One problem is making some programs no longer 8-bit clean.

Unicode might be considered in two ways: (1) Unicode is an approximation of multiple other character sets, (2) All character sets are an encoding of a subset of Unicode. At best, if Unicode is used at all, it should be used as (1) (as a last resort), but it is too common for Unicode to be used as (2) (as a first resort), which is not good in my opinion.

(I mostly avoid Unicode in my software, although it is also often the case (and, in many (but not all) programs, should be the case) that it only cares about ASCII but does not prevent you from using any other character encodings that are compatible with ASCII.)

> ASCII is still the only text system that will really work well everywhere, which I consider a must for calling something plain text.

Yes, it does work well (almost) everywhere.

Supersets of ASCII are also common, including UTF-8, and PC character set, ISO 2022 (if ASCII is the initially selected G0 set, which it is in the ASN.1 Graphic string and General string types, as well in most terminal emulators), EUC-JP, etc. In these cases, ASCII will also usually work well.

However, as another comment mentions, and I agree with them, that if you mean "ASCII" then it is what you should say, rather than "plain text" which does not tell you what the character encoding is. That other comment says:

> Plain text is text intended to be interpreted as bytes that map simply to characters.

However, it is not always so clear and simple what "characters" is, depending on the character sets and what language you are writing. And then, there are also control characters, to be considered, so it is again not quite so "plain".

> And yes, ASCII means mostly limiting things to English but for many environments that's almost expected. I would even defend this not being a native English speaker myself.

In my opinion, it depends on the context and usage. One character set (regardless of which one it is) cannot be suitable for all purposes. However, for many purposes, ASCII is suitable (including C source code; you might put l10n in a separate file).

You should have proper m17n (in the contexts where it is appropriate, which is not necessarily all files), but Unicode is not a good way to do it.

There are several reasons. One possible reason is, if you do not need the functions of other operating systems, then DOS will be much simpler.

The computer is not very usable without an operating system. I think it would be reasonable for the computer to have Forth or BASIC or something like that in ROM, like many older computers do, so that the computer is usable without an operating system (but that you could also install an operating system if you wanted it).

I have been told that ITU specifications are deliberately confusing so that they can sell consulting services.

However, I think DER is good (and is better than BER, PER, etc in my opinion). (I did make up a variant with a few additional types, though.)

OID is also a good idea, although I had thought they should add another arc for being based on various kind of other identifiers (telephone numbers, domain names, etc) together with a date for which that identifier is valid (to avoid issues with reassigned identifiers) as well as possibility of automatic delegation for some types (so that e.g. if you register an account on another system then you can get a free OID from it too; there is a bit of difficulty in some cases but it might be possible). (I have written a file about how to do this, although I did not publish it yet.)

Some users disable favicons; I am one of them (although that is main because I do not use them, rather than due to that).

Some disassembly listings will also include the actual bytes (there are multiple reasons why you will want this).

I do use a command-line program as the only way to interact with GitHub (using the GitHub API), but I do not use GH CLI; I have my own implementation (which is much smaller than theirs). (They can see that I use my own, because of the User-Agent header, and they can also see what APIs are accessed.) (Git can also be used, but only for the functions of Git rather than the functions of GitHub.)

- Being easily able to tell the difference between characters that are otherwise similar (such as O vs 0 and l vs 1 vs I)

- No ligatures and no kerning (a monospace font should not have these features)

(The two above are perhaps the most important (and I think are probably already common enough); the below are less important but still might be good to have)

- Bitmap font for on screen, and also scalable fonts suitable for printing

- Versions of fonts for different character sets (such as ASCII and APL and PC), without using Unicode or other unified character sets

- Possibly, glyphs for control characters (if it is PC character set then it already does, since they are graphic characters with the same codes as the ASCII control characters; another alternative if not the PC character set, is to use ISO 2047)

- Visible: tabs, trailing spaces, spaces that are mixed with tabs, line continuation, page breaks (this is more of a feature of the editor or display rather than of the font, although a font might include glyphs specific for this purpose with special character codes)

To me, the role playing, and the crunchy bits, as well as tactics, combat, and other stuff, are all significant and important part of TTRPG; it should not be only one of those things.

You are not only one trying to do it. There are others, and in other programming languages (Pokemon Showdown is one already implemented, but uses TypeScript with dependencies and I wanted to avoid those issues). What programming language did you intend to use?

I intended to do as a C library (which would then be available for other programs in C to call). I know many of the rules of Pokemon but not all of the cases, and then, knowing the data structures to make, etc. I also wanted to make the rules customizable (and to implement all generations, although perhaps only some of them will be implemented the first time and others later) and I have some ideas about that.

I would hope that some people can work on something together.