Hacker News new | past | comments | ask | show | jobs | submit | Mogzol's comments login

The first line on the page says

> Click the disk that's a different color. Use your eyes only!

Inspecting the color is cheating.


And even if you are using a "regular" video format like mp4, browsers will still use range requests [1] to fetch chunks of the file in separate requests, assuming the server supports it (which most do).

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Ran...


I used winaero tweaker [1] to disable web search, the search is infinitely better now.

You can do the same tweak by editing the registry [2] if you don't want to download an app for it (though the app includes a lot of additional useful tweaks).

[1] https://winaerotweaker.com/

[2] https://www.tomshardware.com/how-to/disable-windows-web-sear...


No generation was raised like the previous one ever in history


This is only true recently! Through most of history people lived and died with technology and culture nearly identical to that of their parents / grandparents. In terms of tech and cultural evolution, we are on the uptick of a hockey-stick growth.

It's absolutely accurate that `kids these days` have grown up in a different environment than `grownups these days` than the same demographics from 50, 100, 200, or 1000 years ago.


the kids of 10000 BC are totally unlike the kids of 10020 BC


The link in the "Error variable naming" section seems to directly contradict what the section says.

The link (https://go.dev/talks/2014/names.slide#14) says:

  Error values should be of the form ErrFoo:
  
  var ErrFormat = errors.New("image: unknown format")
But the page says:

  // But if you want to give it a longer name, use "somethingError".
  var specificError error
  result, specificError = doSpecificThing()
And also says:

  Don't do this:
  [...]
  var errSpecific error
  result, errSpecific = doSpecificThing()
So should error variables written like `errSpecific` or `specificError`? The go wiki says they should be written starting with `err`: https://go.dev/wiki/Errors#naming


The advice in the 2014 talk applies to exporting specific types of errors as part of a package’s public API surface.

The article, on the other hand, advocates for local variables storing errors not to have distinct names.


So a public variable error should follow different naming conventions then a local variable? That doesn't seem right, the go wiki says you should use the 'err' prefix for both (capitalized for public variables though, obviously)

And I'm only asking about when you are giving an error a distinct name, not just naming it 'err'.


It blows my mind that somebody would get an answer from ChatGPT and post it here as a fact without doing the bare minimum to verify that it is actually true. It's insane, thanks for correcting them.


Gaming history is already filled with half-truths and straight up misunderstood things turned into lies because no one cares to write about anything but the players' perspective. Of fucking course the useless LLMs are going to start hallucinating bullshit when they try to navigate that.


I think it would have been interesting to send two down, one oil-filled and one not and see at what depths they break (or don't). The watches are cheap enough that destroying one isn't much of a loss.



I use an esim.me card in my phone and once you program the card with the esim.me app, it shows up as a normal physical sim card on the phone with whatever plan the esim was for. I believe you can even move it to another device and it will still show up with the same plan, though I haven't tried that.

The only issue I've had with it is that some esim provider apps refuse to work on a phone that doesn't have esim capabilities, and since the phone sees the card as a normal sim card, the apps don't work. I assume that will be an issue for any of these cards. Not a huge issue though, most esim apps/websites will still let you get the QR code or download the profile even if your phone doesn't natively support esim, and you just enter that into the esim.me app to program the card.


That's great to know, thanks!


It's just an example async call, it could be anything. It's not the important part of that code example, it's only purpose is to show that an async call is happening. It could be written as a try/catch, or it could be written how they wrote it. I guess they chose that way because it's short and to the point.


Good example code is otherwise uninteresting apart from the concept that is meant to be shown.


I think it is meant to be a generic phone, the edges and front camera are wrong for an iphone, but then the home button is very distinctly an iphone. It is weird.


it's either an iphone 4 or iphone 5 in a case. the home button is an iconic giveaway.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: