barosl

> To keep things simple, the current parser accepts duplicate options without complaining, but that might change in future releases, so applications should not rely on it.

I love this level of attention to detail and kindness in the SQLite documentation. Very few projects do this.

I was in the same boat as you. I'm mostly a backend person and I had avoided frontend frameworks and used vanilla JavaScript directly because I did't like the complexity of modern JavaScript frameworks.

Recently, I tried Next.js and it changed my mind a bit. It prefers convention over configuration, requiring tremendously less configuration compared to other frontend frameworks. It is still a bit complex, but hides the fact nicely under a well-defined abstraction. I might try another project with Next.js in the near future.

I still remember the day I learned how to animate text in the status bar. I felt like being a wizard!

This is such a great idea, but what's even more useful would be to make arrow keys only traverse the commands ran in the current directory. Would there be any prior art?

I think "script as an instructor" might work, as I view this approach as that.

That's very impressive, it almost feels like a legit useful hack. Why was it not fixed in zsh? Did they decide it was working as intended?

> Subshells are, as the name suggests, running in a subshell. They don't strictly have to be OS subprocesses

Are there really cases where subshells are invoked within the same process? In my experience, it has never been the case. That's why I've been trying to minimize the use of subshells because spawning a new process is a bit slow.

The UTF-8 BOM still has some uses, unfortunately. I had to convince Excel to parse a CSV file as UTF-8 and inserting a BOM at the beginning of the file was the easiest solution.

GitHub identifies commits only by their associated email addresses, and it is easy to manipulate them. This has a consequence that anyone can masquerade as any others.[1]

[1] https://news.ycombinator.com/item?id=10005577

I once made a music player similar to this. It converted music files into image files, and saved them to Flickr. One trick that I employed was that the output image files were also visually recognizable, featuring album covers and lyrics.[1][2] The way I used to hide information was pretty barbaric, but it was still a fun experiment.

[1] https://www.flickr.com/photos/barosl/albums/7215763383971356...

[2] https://github.com/barosl/flickr-music-player

What a marvelous project! The amount of efforts that the author put into this project makes my jaw drop.

This project reminds me of a question I've had in my mind, though. If this world is a simulation, would that be an accurate simulation of the elementary particles and their interactions (like this project), or an appropriated one (like normal Game Boy emulators)?

This issue is what makes me paranoid when putting a lot of files into a directory. Having directories whose sizes cannot be shrunk makes me really uncomfortable, so I try to avoid such a situation as much as possible. What's unfortunate is that you cannot predict at what point a directory will grow above its initial size, because the size of a directory is affected by not only the number of files, but also the varying lengths of their filenames. It's a complete mess.

I wondered if NTFS on Windows is also not capable of shrinking already-grown directories but could not find information about it. As Windows doesn't report the size of a directory itself, it is hard to test the situation.

It makes me feel strange to think that all these industries, all these jobs, and all these companies didn't exist just 30 years ago. Nowadays everyone says the web. It seems very hard to predict what technology will be dominant in another 30 years. It is fortunate that I will probably still live by then to witness the future.

Anyway, congratulations to the web.

When I used C for a serious project, I always used `snprintf(dst, sizeof(dst), "%s", src);` to copy a string. It might be a little bit slow, but it freed me from all the headaches of identifying different string functions of C and remembering their subtle differences. It also is useful for other purposes, e.g. prefixing a string.

I think it was a mistake to put hashCode (and to an extent, equals) to all objects by default. It makes Objects bloated, and because of that, those who will never be put to a hash table also need to provide their own hashCode implementations, causing problems like the one mentioned in the article. There should have been a separate, dedicated "Hashable" interface. Strangely, C# shares the same caveat. Is there any benefit to making objects hashable by default?

I'm also amazed by the fact that that John Nagle from the popular Nagle's algorithm is still active on HN!

A compiler doesn't have to emit machine code. It just needs to translate one language into another, which the author's program does.

Also, a parser implies having an internal, structured representation. As the C language is neither internal nor structured, I'd say the program is more likely a compiler.

It absolutely can be used maliciously, but if an attacker can add an alias to the environment, they might also be able to manipulate PATH, making a malicious cp take precedence over the original cp. So the point is moot.

I expected this program would move the chess pieces by itself using a robotic arm or something. But, still great!

`go run` is also build+run, with a dependency scan. But it executes instantaneously. So there is already an evidence that the status quo can be improved. Even Rust's `cargo run` is much faster than `dotnet run`.

This is very interesting. I like C# as a language, and I like Go by its tooling. If this project goes well, it would be the best of both worlds.

The official `dotnet` command is not to my taste for a few reasons. It uses XML, and it is quite slow, e.g. a simple "Hello, world" project takes 2 seconds to launch every time. I mean, it always takes 2 seconds even after compiling everything prior to that. It might be acceptable for an interactive development environment that employes an auto-compiling workflow, but for a CLI tool, it is too much of a burden. I know Microsoft are trying to improve it, but at least up until now it hasn't been very successful.[1]

[1] https://github.com/dotnet/sdk/issues/8697

That's unfortunate. I have a few videos which seems to have been forgotten even by their uploaders. Those videos would probably not be updated. I guess I need to back them up manually.

With a domain having "node" in it, that idea sounds lovely.

It is a bit sad to see the place where I had a lot of memory destroy itself. But then again, I'm glad that they are showing their intention to monetize so bluntly, which may give the audience enough reasons to avoid the service.

I didn't know so many sites were depending on Fastly. Stack Overflow, GitHub, reddit, .... Even pip is unavailable. My development workflow is completely janked up. It is a bit scary that we are putting too many eggs in one basket.

I didn't know so many sites were depending on Fastly. Stack Overflow, GitHub, reddit, ..., even pip is unavailable. My development workflow is completely janked up. It is a bit scary that we are putting so many eggs in one basket.

Thanks for your service. Now it will get even more traffic as I realized the existence of the site!

I didn't know about SSHFP, thanks for informing me. DNSSEC has always felt cumbersome to set up, so I've stayed away from it. Might give it another try.

I don't think ssh provides the same level of confidence as https, unfortunately. There are no root CAs that are agreed upon, so the users are too used to blindly accepting whatever server keys they are given. This makes MITM attacks too easy.

Actually, there are certain cases where visiting a site under an expired certificate is strictly more vulnerable than visiting a normal http site. Certain web features only work in a secure context[1], which an http site does not expose. Therefore, a hacker who can convince the user to accept their invalid certificate can extract more information from the user.

Whether it was a good idea to limit those functionalities to a secure context or not, I don't know. I'm also a bit opposed to this forced HTTPS everywhere mentality.

[1] https://developer.mozilla.org/en-US/docs/Web/Security/Secure...