zzo38computer

SCTE-35 might be a better way to get rid of the commercials (normally SCTE-35 is intended for adding commercials rather than removing them), but only if that data is available (in my experience, sometimes it is, but not always). It might be even more better to just avoid recording the commercials (therefore saving disk space, and saing network bandwidth if using internet for downloading them), or to automatically skip past commercials when playing back a recording (instead of replacing them with something else). If using HLS, then you might use the #EXT-X-CUE-OUT command to detect commercial breaks, and avoid downloading them (although there is sometimes problems with audio/video desynchronization when converting to DVD format, and I don't know if that is because the commercial breaks are not recorded or for some other reason).

I also think that you should be able to do stuff without requiring internet access, and also should be able to do stuff without requiring electrical power, etc. You should not be overly reliance on technology. They can be useful (in many ways), but should not be mandatory to rely on, and furthermore should avoid damaging the natural environments for such technology, and also avoid damaging the possibility of working without them.

What character set does it use? For example, can "O" and "0" considered different characters or same character, and are some letters/numbers not used? If so, then how many they say are possible is not quite that simple, since some might match (so they cannot simply be added together) and some might not be possible.

I agree with you, I also prefer absolute date stamps, including because it might be printed out, etc. However, the <time> command would allow that to work, if it is implemented in a way that allows that to work.

I agree it should do something, which might be configurable by the end user and implementation dependent. For example, a browser might have an option to display the time converted into your preferred time format and time zone. If the operating system environment has some way to specify that some text refers to date/time and can be used with other software in this way, then it would be possible to do that, too.

(My own Scorpion document format is intended to include this capability, as well as the ability to specify other things (e.g. units of measurement, international telephone numbers, how a word is pronounced, languages, etc) to be handled in similar ways, but it is not currently fully defined.)

I use GitHub Actions for only one thing, which is to automatically assign any issues to myself (by using the "gh" program), and I am not paying anything for it. Furthermore, the repositories that use this are all public (I do not have any private repositories on GitHub, and due to various things I will not do that).

As far as I can tell from that article, these changes will not affect me; it says "Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free" and another section says "This will not impact Actions usage in public repositories". Hopefully, this information would behelpful for other people who use GitHub Actions. However, I don't know if I missed something else that is important, from the article.

I (partially) agree that it is a good change, but for a different reason. For security purposes, the certificates should include only the permissions that are required (although maybe they ought to allow you to have certificates that include both if you have a use for it (which as I have mentioned, you usually should not need because you will probably want to use different certificates instead), but unfortunately they do not allow that).

I had partially written a program (in C) to parse X.509 certificates, but the part that is missing is the cryptographic stuff (to validate signatures, and also should be able to extract the public key for use by a separate TLS implementation). (I intended also to make it to be able to make X.509 certificates; the cryptographic stuff will be needed for that too, to make private and public key pairs and signatures. A separate library for cryptographic functions should probably be used for this purpose, if I would have a suitable one. A separate library should also be used for TLS (OpenSSL is rather confusing, and I want to use my own handling of the certificates but OpenSSL makes it too confusing to do that).)

I think client certificates are a good idea, although it is usually more useful to use different certificates than those for the domain names, I think. (I still think CA/Browser Forum is not very good, despite that; however, I still want to mention my point.)

I would expect that using the same certificate authorities for servers is probably not useful for client authentication, although maybe it might be if the only thing you care about is the domain name (although, it shouldn't be; anyways, many clients might not even have a domain name).

But, if you really need to use certificates from the CAs anyways, you might ignore some of the fields of the certificate.

I agree that Carney should use Canadian English. However, this does not seem like a major enough issue to me, to worry about much, nor is it important enough to fine or sue anyone or anything else like that.

> Ah, yes, XDG "portals". The reason file selection and screencasting is broken on every new Linux/Wayland installation I do, forcing me to try to understand the insane matrix of supported, half-supported, broken, and unsupported features by the dozen+ different implementations, and come up with the magic configuration incantation that makes it work on my system. Brilliant stuff. But it's secure!

Is there some way to avoid such a mess (and other problems with XDG portals and other XDG stuff) by substituting a .so file, somehow? I don't really know enough about how it works to know whether or not such a thing would work. (Maybe it might work for some programs, depending on which libraries they use for this purpose.)

I think the way to do should be capability-based security. However, that is suitable for a new operating system design (and computer design, too, for some reasons).

For Linux, we can do something else, although something similar may be possible. However, it seems that seccomp does not allow the function to send and receive file descriptors, nor to wait for one of any file descriptors in a set (like the "select" function), etc, so it is rather limited, and will require another process to proxy all of these functions. (Wikipedia says seccomp also disables RDTSC; my own system design would not even have such a thing, because I would want to restrict all I/O including high-precision timing; but I would also want to restrict CPUID and stuff like that too.) Capsicum might be better, at least for BSD (although I don't know if it disables RDTSC or CPUID).

I had thought of making a sandbox library tha should not require many changes to the program (although some changes will be needed); this can be used to specify the permissions needed involving files, popen, command-line arguments, network functions, timing, etc, and functions to request input in various character sets, and to request other things as well such as file names, and the host name and port number when connecting to internet, etc.

I do not like D-Bus either, and I do not like JSON either. Some of the problems are the ones mentioned there, and it has many other problems as well (one of these is that its use of Unicode can cause problems, but there is a lot more problems than just that). I do not agree with the solutions mentioned there either, although they do make some improvements, there are also some problems.

A better way would be a different operating system design, although without that, you can still improve it on Linux. I think putting secrets in the message bus is not really the way to do sandboxing properly, and I think there should not be a global message bus (it should be specific to a program; if the program is properly sandboxed it can be limited what it can access, and possibly they can be declared by the use of environment variables, although).

There are also problems with the existing sandboxing systems; e.g. some do not work properly with character sets and might not support such things as: popen, command-line arguments of the program to restrict which files can be read/written, etc.

For security for programs running on the same computer communicating with each other while they are running, cryptographic algorithms are probaly not the way to do it; the operating system should handle the security to prevent programs from seeing and/or tampering with something that it is not supposed to do, so that the communication between programs is prevented unless it is configured to allow it.

For the data format, I might use DER (or SDER for the fields that are not required to be in canonical form, since canonical form does not matter for all fields but for some it might matter).

(The implementation would prevent messages from being sent to or received from whoever it is not supposed to be allowed to do, by checking the permissions and/or by just blocking access, forwarding the messages to proxies that might modify and/or log them, etc; such things can potentially make the system more versatile.)

You can do better than "only ASCII works in this device", and making the default string type to be Unicode is the wrong way to do that. For some applications, you might not need to interpret text at all, or you might need to only interpret ASCII text even if the text is not necessarily purely ASCII; other times you will want to do other things, but Unicode is not a very good character set (there are others but what is appropriate will depend much on the specific application in use; sometimes none are appropriate), and even if you are using Unicode you still don't need a Unicode string type, and you do not need it to check for valid UTF-8 for every string operation by default, because that will result in inefficiency.

In Swift (and in other programming languages) it does use Unicode, but I think it probably would be better not to be. But, even when there is a Unicode String type, I still think that it probably should not be grapheme clusters, in my opinion; I explained some of the reasons for this.

I disagree. I think it should be indexed by bytes. One reason is what the other comment explains about not being constant-time (which is a significant reason), although the other is that this restricts it to Unicode (which has its own problems) and to specific versions of Unicode, and can potentially cause problems when using a different version of Unicode. A separate library can be used to deal with code points and/or EGC if this is important for a specific application; these features should not be inherent to the string type.

I think there are benefits of interpreters as well as compilers, possibly for the same programming language in some cases (although some programming languages are better for use with interpreter and some are better for use with compilers).

I think JSON is not the best format for the persistence though (despite their claim that it is better than binary formats, it has many problems); it has many problems, such as not a proper integer type and not non-Unicode text types or binary types, etc; and different format would better, such as DER. If you use DER, then you can use better types, better character sets, binary data, and not limits to how big numbers can be, etc. (JSON might work for JavaScript, but even then only for some types; JavaScript has more types than JSON has, including JavaScript does actually have a integer type even though JSON does not.) (With using JSON, it will just mean that you will then have to wrap other data in JSON anyways (e.g. encoding DER as base64) and the meaning will have to be converted.) (Also, you can work around not being a text format, because you can have a program to display them, like a program can be used to display any other kind of data in other ways (e.g. syntax highlighting, pictures, auto formatting, etc).)

Microsoft QuickBasic does too, which I sometimes still use when programming on DOS (one of the reasons for this being what efaref mentioned about performance and usability and being regressed); and also has a "immediate mode" that you can enter BASIC commands and execute them; I think this is helpful.

Something I had thought of (which does not fully solve the problems mentioned there, but would allow GNU nested functions to work in a way that can be implemented without trampolines and executable stacks, so that it can work in standard C and with the standard ABI), is to allow a nested function to optionally be defined with the "static" and/or "register" keywords.

With "static", it is implemented as an ordinary function, but the name is local to the function that contains it; it cannot access stuff within the function containing it unless those things are also declared as "static".

With "register", the address of the function cannot be taken, and if the function accesses other stuff within the function that contains it then the compiler will add additional arguments to the function so that its type does not necessarily match the type which is specified in the program.

This is not good enough for many uses though, so having the other extensions would also be helpful (possibly including implementing Apple Blocks in GCC).

I disabled fonts on the web browser on my computer, in order to avoid that and other problems. I also disabled the display of non-ASCII characters in URLs (which required adding some codes to make it do that; the built-in settings will only work for the domain name and not the rest of the URL), and changed the font used for URLs, which also helps.

What I had done sometimes when writing slashed zero by a pencil and needed the disambiguation (which is not that common in my writing but it does happen sometimes that it will be important), is for the slash the other way for zero, to avoid being confused with slashed O or the symbol for empty sets. Atkinson Hyperlegible font (mentioned in another comment) also works that way, too; the slash for zero is the other way than the slashed O in languages that use that.

Maybe whoever told me that was wrong, or that was an older version that could not switch them separately, or I was confused and it is different for Android vs iPhone, etc.

I use GitHub Actions to affect issues and pull requests also, but to assign them to myself (so that they are visible in searches), not to close them. However, for some reason it does not seem to work properly for pull requests, even though it works for issues.

I hardly get any contributions, questions, etc even though I have published them on GitHub (although some people do watch and/or star them, but I don't really care much how many stars it has).

I think you can disable issues but not pull requests, as far as I know.

It might be helpful to allow to disable pull requests too, and possibly to hide how many stars/watchers there are and hide the list of forks (people could still star, watch, and/or fork the repository, but they would not be listed on that repository if the display of those features are disabled).

Whether or not GitHub accepts these ideas, it can be an idea that other services (e.g. Codeberg) can consider adding such options if they want to do (as well as other things).

Although I do not use it myself, I had seen that some other people do, and that apparently you cannot disable autocorrect while still having prediction enabled (at least, that is what they told me); I think it might be useful to enable prediction without autocorrect.

This does not always work for specific programs which do not do that, and even then, there are updates that you might want other than security updates without updating other parts of the same program. Separate programs can usually be updated individually, but if they are all in one program then it can make it more difficult (sometimes configuration can be done but not always; sometimes they change things that make this not work either).

Calibri font has "I" and "l" the same, according to Wikipedia. A better font should avoid characters being too similar (such as "I" and "l" and "1").

Another issue is due to the font size and font metrics, how much space it will take up on the page, to be small enough to avoid wasting paper and ink but also not too small to read.

So, there are multiple issues in choosing the fonts; however, Times New Roman and Calibri are not the only two possible choices.

Maybe the government should make up their own (hopefully public domain) font, which would be suitable for their purposes (and avoiding needing proprietary fonts), and use that instead.

> Or hell, why not do it in x86 assembly?

It is not portable to computers other than x86. It is one of the reasons I do not use x86 assembly much even though I have a x86 computer; I prefer C. It is not about vibe coding.

> I suppose what I’m getting at, here, is that if vibe coding is the future of software development (and it is), then why bother with languages that were designed for people who are not vibe coding? Shouldn’t there be such a thing as a “vibe-oriented programming language?” VOP. You read it here first.

Someone told me that two companies (one of which is Google) were working on such a thing, although I do not know the details (or if they were correct about that), and I do not know whether or not it resembles what is described in that article.

I do not use LLM myself, although I have seen a few examples of it. I have not seen very many so the sample size is too small, but what I have seen (from simple example programs), the program works although it is not written very well.

There is another kind, which is X.509 client certificates, which is more secure and more versatile than other kinds. However, it does mean that if you want to login from more than one computer, you need the certificate and private key on all of them (but this can be an advantage as well as being a disadvantage). It is capable of handling authorization as well as authentication, if you add extensions for this use. The private key may be passworded, which can provide additional security; storing one certificate on a computer not connected to the internet and then issuing another certificate to yourself which will be the one you will actually use, can also provide additional security; in both cases, the service provider does not need to worry about these things and the client can do how they intend to do.

Another method which may be suitable for some uses (although the working of web browsers means that it will not work securely in a web browser, unless you have an extension, but it can work easily in other programs) is HMAC, although this is not suitable for all uses. For idempotent write operations which are not intended to be secret, it might work.