beltsazar

> The thing I hate about "advice" like this is that it assumes that everyone likes the same things and feels the same way

It's so ironic that at the end you gave an advice:

> I suggest that the next time you watch a shakey-cam action movie, you try turning it on too!

Are you assuming that everyone likes the same things you like? I guess not. The same for the article—it doesn't assume that.

No advice fits everyone, but good advice fits many people. And I'd argue that the article's advice fits many, if not most, people.

TV is probably the only screen many people have that has motion interpolation on by default. They watch movies on theaters, PC monitors, laptops, tablets, and phones probably more than on TVs.

Many people are already used to what movies "look like." Non-tech-savvy ones might not know what "FPS" means, but they would likely be able to notice that watching movies on their phone feels different from on a TV with the default setting. The article's suggestion to disable motion interpolation on TVs makes the watching experience more consistent across all screens.

I have a relatively minor tinnitus, which I thought was caused by my drum lessons in my early twenties.

But when I tried to remember it, I always heard something like a tinnitus sound (albeit quieter) whenever I closed my ears with my hands since my childhood, during which I was never exposed to any loud music or sound.

I don't know if I agree that it's an autocorrelation, but one way to explain The Dunning-Krugger Effect is by acknowledging this simple fact:

Most people think that they are an average person, but they can't be all average—there must be some people substantially below the median. Therefore, those people must overestimate their abilities.

This also applies to other aspects, such as attractiveness. Less attractive people would overestimate their attractiveness.

Ah yes, silly mistakes—I mixed up getenv and setenv. Those examples transitively use getenv, not setenv.

Having said that, my point still stands. You can only control what you directly use / don't use. Third-party libraries you use might use setenv at times other than "the very beginning of the program."

> This is silly, setenv() isn't reentrant for the same reason that getopt() isn't reentrant: there's no valid reason to use it except at the very beginning of the program.

It is not, unless you'd argue that "there's no valid reason to use [anything that transitively uses setenv()] except at the very beginning of the program." Did you even read the article? The author and the GitHub links mentioned provide some examples that use setenv() not directly, but transitively.

> When animation went digital, we graduated more storyboard artists and digital animators. When music notation software and sampling could replace musicians and orchestras, we graduated more musicians and composers trained on those tools.

What you explained is that tech has changed the tools used by artists.

It's substantially different with AI-based TTS, though. It's not a tool for artists, but it's a tool for movie/game/book publishers to replace human voice actors. The AI will be much much more scalable and cheaper.

If AI will render some jobs obsolete, I suppose the first one will be audio book narrators and voice actors.

I always prefer ffmpeg to HandBrake, except when working on HDR videos.

I couldn't find a proper ffmpeg command to copy the HDR metadata from input source to output. Last time I checked it was not possible. I needed to extract the metadata manually (e.g. using MediaInfo), then pass each metadatum as an argument for ffmpeg.

Does anyone know if it's still the case?

> But when a once in a blue moon issue crops up in prod and all other connections are dropped, the fact that a simple defer+recover couldn't have been preemptively placed on their goroutines is a huge nightmare

Yeah, this is one of the weird things, to say it mildly, that Go does that is hardly mentioned anywhere. Most people don't know about it until they themselves first encounter the nightmare bug similar to what you said.

> Sounds like you may be confused thinking that a panic in Go is like throw in other languages?

Not at all. I knew that panics in Go shouldn't be used for error handling in general.

> Third-party libraries should virtually never panic.

True, as true as 3rd-party libraries shouldn't have any security vulnerabilities. But we don't live in a perfect world. Bugs happen.

> This is a bit like worrying that your programming language won't prevent a third-party library from sending a SIGKILL to your program or that it doesn't prevent third-party libraries from delete your entire file system.

Very different. Your examples are intentional and malicious actions. What usually happens is due to bugs.

> No general purpose language protects against malicious or stupid code.

Are you implying that all bugs are caused by either malicious code or stupid code? Panic-related bugs are often due to the billion dollar mistake [1] that Go's team refused to solve.

---

[1] https://www.infoq.com/presentations/Null-References-The-Bill...

Yes, "usually", but not always. That's why Go has a mechanism to handle a panic with the `recover` function. The issue is more on the inability of handling a panic in a "foreign" goroutine.

> Rust made the same call.

Completely different. In Rust when you spawn a thread [1] or an async task [2], you'll get a handle from which you can check if a panic happens inside the thread/task. Even if you ignore the handle, a panic inside a thread/task won't crash the entire program.

---

[1] https://doc.rust-lang.org/std/thread/fn.spawn.html

[2] https://docs.rs/tokio/latest/tokio/task/fn.spawn.html

There are a few surprises of Go, but one thing that surprised me the most is the fact that an unrecovered panic in any goroutine will crash the whole program. To make things worse, you can only recover a panic in a goroutine that you spawn. So, you can't do anything to prevent a panic in a goroutine spawned by a third-party library crashing your whole program. The best you can do is to set up a supervisor to restart your program after crash.

What you said is probably similar to what they said at the early invention of shoes.

Professional runners today already use an "external device," aka running shoes. If they ran barefoot or even wore mediocre shoes, they would perform worse. As long there's no external energy powering the device, I'd still consider it running.

Maths in other planets or universes can be different only if they have different sets of axioms and/or different logical inference rules.

I'm using uBlock similarly! I've accumulated hundreds of custom filters for the past eight years. My newest entries on uBlock's "My Filters" tab are for hiding spoilers on IMDb:

  ! 2023-09-05 Hide episode's description and image (+ watchlist for not breaking the layout) [new experimental IMDb layout]
  imdb.com##article.episode-item-wrapper .ipc-slate
  imdb.com##article.episode-item-wrapper .ipc-html-content
  imdb.com##article.episode-item-wrapper .ipc-watchlist-ribbon

  ! 2023-09-05 Hide top rated episode's description both on a TV page and an episode page
  imdb.com##[data-testid="episodes-top-rated-card"] ul + div

Yes, the loopvar change will break some programs, and hence the compatibility promise. But the Go team argues that the change will fix much more programs than it will break [1].

This makes me wonder, though, what guarantees that a similar breaking change won't ever happen again in the future? If any change with #(programs fixed) >> #(programs broken) is accepted, we might as well remove the compatibility promise page [2].

---

[1] https://github.com/golang/go/issues/60078

[2] https://go.dev/doc/go1compat

If no one could do bad things in the world, then there would be no free will. No free will, no genuine love. You'd love God and other people because you were programmed to do so.

What's the average FPS?

Speaking of the expansion of the universe, in a very distant future when the expansion speed is so high that most of the galaxies won't be visible from earth, their astronomers will be thinking the whole universe contains only a few galaxies. But wait, what if the universe we observe today also misses some parts that can't be observed anymore?

Neil deGrasse Tyson explained it more clearly: https://www.youtube.com/watch?t=436&v=TgA2y-Bgi3c

That's probably why it's called the observable universe.

>> Solving problems is the only way to understand physics. There's no way around it.

The reason is that you think you understand what you read, but as Richard Feynman said:

> The first principle is that you must not fool yourself, and you are the easiest person to fool.

You think you understand 90% of what you read, but in reality it's probably only 20-30%. By doing the exercises, at the very least you'll know that you don't know that much. And if you then reread the materials a few pages before, you'll realize that you have skimmed (or worse, skipped) some parts because you mistakenly thought you already understood it.

Another tips from my personal experience: When you're reading a textbook, keep asking in your mind questions with the types of "what if" and "how about," which are sometimes not yet explained in the section you're reading. Also, keep associating what you've recently learned with what you've already known (days ago, years ago).

Be curious and validate that you really understand what you think you understand.

> If you search for white/brown etc. noise on spotify for songs you won't find longer tracks.

I noticed it too recently, but it's not always this way. A few years ago I could find white noise songs with hours of duration.

> To some extent, all languages do this: there is almost always a tradeoff between performance and slower, safer implementations.

Well, probably except Rust, from which you get both performance and safety. Sometimes it's with a cost of ergonomics, though. Some people, including the Rust's creator himself, would trade performance for better ergonomics in the case of asynchronous programming. They prefer having a non-zero-cost green threads to the current state of async prog in Rust.

As much as I like the functional paradigm, I don't think it will work well on Go due to two simple reasons:

1) Go doesn't have a concise lambda expression. This makes the functional approach in Go will be more verbose and less readable than the traditional imperative approach.

2) Go's type inference is not sophisticated enough. Most of the time you will still need to explicitly annotate the types, which, again, makes it more verbose and less readable.

> When historian Charles Weiner looked over a pile of Richard Feynman’s notebooks, he called them a wonderful ‘record of his day-to-day work’.

> “No, no!”, Feynman objected strongly.

> “They aren’t a record of my thinking process. They are my thinking process. I actually did the work on the paper.”

> “Well,” Weiner said, “The work was done in your head, but the record of it is still here.”

> “No, it’s not a record, not really. It’s working. You have to work on paper and this is the paper. Okay?”, Feynman explained.

What? This is beyond the inconvenience of 3rd party launchers that PC gamers often whine about. I'm glad I play on PS5.

Can I migrate from TST to Sidebery without losing all my tabs with their tree structures?

No, I was genuinely asking because I had found many HN posts were editorialized.

I wonder if HN should have a rule that prohibits editorializing.

What makes Sidebery better than TST? I'm consider trying it, but I don't want to lose all of my TST tabs.