Recent submissions

Comment · 4 days ago
Comment · 20 days ago
Afaik it's habit to give system paths precedence so a malicious script can't shadow e.g. sudo and steal your password, escalating a local file write into root
Comment · 2 months ago
I also dislike the choices the product team of Firefox is doing. However, it is the only (afaik) major browser distro that has support for a proper adblocker, so I grind my teeth and remove homepage widgets and tab suggestions and weather forecasts.
Comment · 2 months ago
I thought they were expensive compared to fetches from established repos. TIL they're also expensive compared to full clones.
Comment · 2 months ago
Semi-related, I redid just the other day the Flying Toasters in-browser with the full logic from the original, toast-juggler and everything.

https://news.ycombinator.com/item?id=49432857

Thought about doing it as a Linux screensaver, but I didn't have the patience to actually wait for the idle time, and that way I can share it with my non-Linux-using family.

Comment · 2 months ago
When I was a kid I really liked this After Dark screensaver, and I recently had a burst of nostalgia. Because I'm pedantic, I was missing the specific 1996 version, not "Flying Toasters" (1990) or "Flying Toasters Pro" (1994), because kid-me had the version with conga lines, future toaster-satellites, and a toaster with a bagel for eyes.

I saw Bryan's CSS version (https://www.bryanbraun.com/after-dark-css/all/flying-toaster...), and tried reproducing it with manually-extracted sprites (windows virtualbox -> ffmpeg -> gimp) about 2 years ago, resulting in https://backslasher.github.io/flying-toasters-legacy/

They both didn't scratch my itch fully, and I had some Fable credits available so I decided to put it to good use.

This reproduction is fully based on the sprites, music, sfx, engine logic of the original screensaver. It has the "gags" (toasters doing something silly), baby mode (which I'm not a fan of, but to each their own), and karaoke.

Claude Fable did a lot of good work, including some basic validation (spinning up a headless Chromium and grabbing console output and screenshots), but I was still needed in the loop. It was really big on magic-number-ing, patching, and "assuming" things and most of my comments that weren't bug reports were pushbacks on it inventing stuff rather than going deeper.

As per usual when doing old-things-disassembly, I marveled at how much rich logic this tiny binary has, e.g. the "gags" that involve multiple toasters (airshow squadron split-off) initialize regular toasters, grab them for the gag, then release them into individual units when done. On the other hand, they didn't have weighted random, and I kept wondering why 10 entries in the flight-act table were identical (loop-de-loop) until I realized it's the same act, and they wanted it 10x more likely to be picked.

New code is AGPL (https://github.com/BackSlasher/flying-toasters-reverse-engin...). Extracted art, behavior, audio remain the property of whoever holds After Dark's IP, and are held for archival purposes (see NOTICE).

If you have questions or other AD screensavers you miss, let me know!

Comment · 2 months ago
I hate the expert for not cleaning up the url before sending it over
Comment · 3 months ago
I think these are discussions about workplace / team policy that get extended into a post.

I recognize these from different dev teams where it was agreed that a "how much AI" policy is needed, but the actual policy was very hard to settle on.

Comment · 3 months ago
I wanted to help so I took a look at the issue and the code. I was unable to reproduce the issue from your description.

Firstly, issue #153175 refers to the "time of day" sensor, which is not what you're using - you're using the "time" trigger. The TOD code does a bunch of timezone acrobatics that can be fixed, but I don't think it'll affect your problem.

Secondly, I built a tiny regression test on dev (on top of 333a3421) to reproduce your problem, and it didn't repro. I created a "trigger: time, at: 06:00:00, Europe/Paris", attached it before the DST transitions, and checked when it fires before, during, after the DST actual. The trigger fires perfectly on 06:00 walltime, and adjusts utc to match.

Thirdly, the HASS UI has a small bug where it shows "Paris/+1" even if it's currently DST. It's a UI bug only, but it can lead to someone thinking that the entire HASS core doesn't respect DST.

Silly tech support questions - are you on latest? Did you try playing around with {{now()}} in developer templates? Maybe open a new issue?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton