HN user

andrew_eu

414 karma
Posts6
Comments58
View on HN

I like the definition of social rules [0]. I also wonder whether the roof rule was written preemptively or retrospectively -- I hope the former.

I have my own thanks to give to HN. It's connected me to interesting people, online and IRL. It's led to some very strong friendships. It's led me to multiple job opportunities, and usually the better ones. It's changing of course, but I've had a great time in this community so far, and that deserves thanks.

0: https://www.recurse.com/social-rules

I love it. For years with my old dog I would give him a binary choice between two treats and intuitively got a sense of his favorites as well. More satisfying to me was giving him the choice, which (maybe I'm over personifying him) I think he liked to pick his favorite. He had stomach issues which limited him to really only a few types of treats, and it was obvious which were his favorites, but it was fun anyway. I miss that dog.

Disappointing. I built a lovely little Nanoclaw bot that's been surprisingly helpful at raising a puppy. I haven't gotten this email, so I wonder if my usage is too low to catch their first pass. If they shut it down though, the fix is straightforward -- some API based backend with zero stickiness to Anthropic.

It is a pity though. For less than an hour of setup the Nanoclaw bot proved enormously useful at tracking meal times, training progress, etc and the interface was easy enough for the family to get involved. The ease of setup was really remarkable, and Anthropic creating artificial barriers just seems user hostile.

I set one up to have a shared chat with my partner about our dog. E.g. schedule reminders, tracking food in a spreadsheet, etc.

I share this worry.

You can configure the storage template for the photos and include an "album" part, so if a photo is in some album it'll get sorted into that folder. Then the file tree on disk is as you wish.

I haven't tested what it does when a photo is in multiple albums, but it does handle the no album case fine as well.

Ente looks interesting and worth looking into, thanks for mentioning it.

In the context of having a phone stolen, it's possible to at least limit the damage and revoke accesses via the Tailscale control server. Then the files on device are still vulnerable, but not everything in Immich (or whatever other service is running).

Very nice the author uses tailscale serve! It's an underrated, and unfortunately under documented, way to host a web service directly to Tailscale. With that you can run a docker compose stack with one extra tailscale container, and then it's immediately a self contained and reasonably portable web server in your tailnet.

Immich really is fantastic software, and their roadmap is promising. I hope they have enough funding to keep going.

Also it has a very rich ACL system. The Immich node can be locked out from accessing any other node in the network, but other nodes can be allowed to access it.

The sync really is quite good. On wifi it's basically seamless. If I had 30k new images though it would be much faster to use the immich-go tool mentioned in the blog post.

Offline support is alright, though I haven't worried about this much. I think it doesn't do any local deletion, so whatever stays in your DCIM folder is still on device.

I have the main volume for images in a zpool with two SSDs in a raid-1 configuration. I also have a daily cronjob that makes an encrypted off-site backup with Borg. I've also got healthchecks.io jobs setup so that if the zpool becomes unhealthy, the backups fail, or anything stops, then both me and my partner get alerted.

My partner isn't very technical, but having an Immich server we are both invested in has gotten her much more interested in self hosting and the skills to do it.

I think it's of course not so simple, and the abstract of the paper they refer to [0] seems to contradict the Business Insider article. Sure, inflation adjusted median income is up slightly. In addition to this educational costs have exploded, and to earn a median salary it has become necessary to buy in. People under 30 have greater inflation adjusted income, but this is because they rely more on their (boomer) parents. The overall wealth in society has increased dramatically, but the vast majority of gains are going to the outliers.

That is to say, the real conflict isn't between boomers and millennials, it's between billionaires and everyone else. But generational friction is not new, a more common experience, and easy to exploit in media.

0: https://www.federalreserve.gov/econres/feds/files/2024007pap...

I've used probably 15 or 20 web browsers in my lifetime and all of them had the same barely searchable table of URLs as their only history view. Why couldn't we have full text search of the pages, or a view that reflects tab histories as some kind of graph, or UIs that support any kind of sorting? Instead it's 2025 and the solution is to attach an LLM slot machine to the front and drive engagement.

I'd be very open to any Firefox extension suggestions (or standalone applications that can consume a Firefox history) that makes it more searchable. I don't often need to search my browser history, but when I do the answer is rarely easy to find.

All of the other features look like a high potential for abuse, but with lots of glitz to make it seem essential to laymen.

I think it's about improving the turnaround on planes. When a plane lands, the crew has to get everyone out, clean the cabin, then get the next flight's passengers in -- all as quickly as possible. The shorter this turnaround, the more flights the plane can fly, and the more money the airline can make.

Flexible seat back pockets are easy for people to stuff all kinds of trash in, so that's just one more task for the crew. Inflexible slots are harder to put trash in, and harder for passengers to notice there's trash in.

A valid HTML zip bomb 12 months ago

I can imagine the large scale web scrapers just avoid processing comments entirely, so while they may unzip the bomb it could be they just discard the chunks that are inside of a comment. The same trick could be applied to other elements in the HTML though: semicolons in the style tag, some gigantic constant in inline JS, etc. If the HTML itself contained a gigantic tree of links to other zip bombs that could also have an amplifying effect on the bad scraper.

I have a memorable reverse geocoding story.

I was working with a team that was wrapping up a period of many different projects (including a reverse geocoding service) and adopting one major system to design and maintain. The handover was set to be after the new year holidays and the receiving teams had their own exciting rewrites planned. I was on call the last week of the year and got an alert that sales were halted in Taiwan due to some country code issue and our system seemed at fault. The customer facing application used an address to determine all sorts of personalization stuff: what products they're shown, regulatory links, etc. Our system was essentially a wrapper around Google Maps' reverse geocoding API, building in some business logic on top of the results.

That morning, at 3am, the API stopped serving the country code for queries of Kinmen County. It would keep the rest of the address the same, but just omit the country code, totally botching assumptions downstream. Google Maps seemingly realized all of a sudden what strait the island was in, and silently removed what some people dispute.

Everyone else on the team was on holiday and I couldn't feasibly get a review for any major mitigations (e.g. switching to OSM or some other provider). So I drew a simple polygon around the island, wrote a small function to check if the given coordinates were in the polygon, and shipped the hotfix. Happily, the whole reverse geocoding system was scrapped with a replacement by February.

Depressing politics aside, I'm curious about how this affects the long term usability of the telescope. I guess as long as the orbit is sustained and it doesn't suffer physical damage, it would still be basically operable for it's design life.

If major cuts essentially leave a skeleton crew, or no crew, for an extended period of time would later reinvestment be able to put the observatories back to use with only lost time? Or do these things need constant remote maintenance to stay operational?

I did hundreds of interviews for a former employer (10k+ employees) and developed a fondness for in-person coding interviews. In particular I would tell the candidate up front that the goal of the exercise is to see how they collaborate on a problem, how they communicate about their thinking, etc. The problem itself was considered too easy by many of my colleagues, but I still found it an extremely useful for the seniority and capability of engineers.

A later employer was in the hiring tech space, enabling this kind of take home exercises. Lots of time was invested into getting signals as the developer was doing it because everyone knew that's just as valuable, if not more, than the final solution. But many companies using these take-home exercises do it just to filter out candidates. To them, it's a proof-of-work system that helps regulate the intake of their hiring funnels.

Years ago my tax return was flagged as a possible fraud case -- I believe a direct consequence of a big data breach. I had to go into my "local" IRS office and present my passport to prove indeed it was me. Decidedly not nice.

True to form, with an appointment I waited 3 hours at the office and watched the guard staff turn away countless people. Finally saw a person, gave then my passport, and finished in a minute.

Entirely possible. I did not try to test systematically or quantitatively, but it's been a recurring easy "demo" case I've used with releases since 3.5-turbo.

The super verbose chain-of-reasoning that o1 does seems very well suited to logic puzzles as well, so I expected it to do reasonably well. As with many other LLM topics, though, the framing of the evaluation (or the templating of the prompt) can impact the results enormously.

I thought with this chain-of-thought approach the model might be better suited to solve a logic puzzle, e.g. ZebraPuzzles [0]. It produced a ton of "reasoning" tokens but hallucinated more than half of the solution with names/fields that weren't available. Not a systematic evaluation, but it seems like a degradation from 4o-mini. Perhaps it does better with code reasoning problems though -- these logic puzzles are essentially contrived to require deductive reasoning.

[0] https://zebrapuzzles.com

It's an excellent book and I agree with many of the comments -- while it's written for Rust, the vast majority of it is applicable to many languages. It's amazing to see the book published on their website for free (though I am still happy in having bought the book).

One thing I found lacking in the book were the examples. It has tons, but all of them are extremely focused on the topic they are illustrating and most feel very contrived. Would anyone here have a suggestion for a small/medium-sized project (weekend sized) which would actually use the patterns discussed in the book?

I can't really disagree with the points the article makes in favor of Go, and it's not selling it over some other language/framework/tool but just celebrating how great of an ecosystem Go has. And it's true -- Go's ecosystem has matured into something very pleasant to work with.

By the same token I know professors who still write their simulation scripts in QBASIC because that's what they are familiar with and they can solve their problems quickly. You can use all sorts of tools to drive a nail.

On Go, it's almost a footnote in the context of the post, but I think a seriously underrated feature is its C-interoperability. Here [0] is an example. It's not unique of course -- tons of languages have some FFI solution for C libraries -- but Go's is I believe one of the most straightforward to use if you're already familiar with the language. And while there are portability/stability sacrifices you make when you call a native library, it does also expand the available dependencies even beyond "basically infinite."

[0] https://go.dev/blog/cgo

After a family member died I took on the task of digitizing several laundry baskets of photo prints.

I bought an Epson ES-580 automated document feed scanner, and still am pleased whenever I use it. The workflow for digitizing them was: USB stick directly in the scanner, put ~200 same-size photos at a time in the feeder, press "Go" and it'd scan about 3 seconds per photo (at 600 DPI, closer to 1 at 300 DPI). While scanning I'd set up the next stack, and periodically copy everything from the USB stick to a NAS.

Incidentally I used to work in a film darkroom and have a bit of experience with negative and slide scanners. Even in the best cases, they're tedious and finicky. If you want to digitize a perfectly clean 35 mm and scale it up to poster size then perhaps it's worth the effort. If you want to just preserve memories, even a bad photo of a damaged 4x6 print can still mean a lot.

I can't speak for their developer/support team, but that kind of feedback indeed feels strange. Even more so because this kind of intervention is possible without touching any of Jellyfin's code.

In particular you can create an NFO file (same stem, next to the media, with a .info extension) that contains this data. With stuff like the IMDB ID given, Jellyfin is pretty good at extracting metadata from there; without it, false matches aren't uncommon. It's even documented. [1]

[1] https://jellyfin.org/docs/general/server/metadata/nfo/