Hacker Timesnew | past | comments | ask | show | jobs | submit | MintPaw's commentslogin

In cursor:

You can copy/paste or drag code snippets the chat window and they automatically become context like. (@myFile.cpp:300-310)

You can click any of the generated diffs in the assistant chat window to instantly jump to the code.

Generated code just appears as diffs till you manually approve each snippet or file. (which is fairly easy to do with "jump to next snippet/file" buttons)

These are all features I use constantly as someone who doesn't vibe but wants to just say "pack/unpack this struct into json", "add this new property to the struct, add it to the serialization, and the UI", and other true busywork tasks.


This all happens in VSCode now too and it's half the price for way more usage compared to Cursor. That Microsoft money sure does subsidize things.

I've never heard about "Home Assistant Green". Seems like another step down the slippery slope of "work on my machine". First docker, than a dedicated OS, now dedicated hardware. I wonder why is Home Assistant so complex as to require all this.

I have no problem with them offering a ready-to-run hardware solution for Home Assistant, but I am annoyed that it's probably a motivating factor for why there isn't a self-installing image for HA on BYO hardware...

https://www.home-assistant.io/installation/generic-x86-64/

you mean an image like this?

This is what I've been running on my generic x86-64 system for a couple of years now, 0 issues. Even migrated to a newer system recently because I wanted something that was slightly faster for ESPHome compilations.


"self-installing" being the key point. Those instructions require you to use some other piece of software to write the image onto your boot disk. In my case I used an Ubuntu livecd to download and write the image to the machine. It's obviously not a showstopper but it is slightly annoying.

> hose instructions require you to use some other piece of software to write the image onto your boot disk.

I mean... That is how a lot of OSes are distributed: by giving you an ISO that you burn onto a USB dongle to install.

> In my case I used an Ubuntu livecd to download and write the image to the machine.

So... Same thing?


I'm worried that my writing is unclear and is being misinterpreted here.

The HAOS ISO cannot install itself onto a machine. That is my minor complaint.


It's not that it's that complex to need all of this. It's about ease of use. Home Assistant OS makes life simpler for users (such as myself), it makes it easy to use adding that run as additional docker containers, it makes plugging in USB z-wave/zigbee devices a breeze.

While it is technically no longer supported, you can still install the whole kit and caboodle using pip in a Python virtual environment, but why would you?


> You can still install the whole kit and caboodle using pip in a Python virtual environment, but why would you?

This is how I did it, instead of the container or HA OS in a VM.

If you want the simplicity of everything preconfigured, managed, and hands-off, go with HA OS, whether in a VM on a beefier machine, standalone, or the HA Green/Yellow dedicated hardware.

But if you already have a home server and want to add HA, I found just pip installing to be easier than dealing with the container.

Maybe I'm just the silly type that enjoys fiddling with Linux, but I'd argue that it actually makes more sense to install HA bare metal over a container. HA doesn't actually have any major dependencies outside of what pip installs, so setup wasn't any more annoying than via container. And then you never have to deal with container annoyances like passing hardware through to it or weird failures and misconfigurations.

Contrast this with https://frigate.video/, which has so many fragile native dependencies and a super complex stack that trying to install manually is an exercise in futility. I gave up and used the container.


Docker would be the primary other dependency for Apps support.

There's nothing wrong with running it on bare metal but this is easier with the VM image.


I think you're talking past each other. You're talking of capabilities, GP is talking about complexity.

Because it's not at all obvious. The vast majority of people posting on Hacker News in 2026 probably had extreme exposure to the internet early in life and turned out alright. So they're probably not as concerned about children being exposed to adult content.

But clearly people in other cultures have a huge problem with it. Don't fall victim to survivorship bias + echo chamber.

There's not another obvious solution to the problem, it's debated in every thread. (no laptop + homeschool is not a real option for 99% of people)


> There's not another obvious solution to the problem

The problem with this solution is it's far too overly broad while also not working well. It leaves out the most important parts from the legislation while specifying universal compliance.

What the law should have been is "Operating systems intended to be used by minors should have this age verification specification implemented" with a nice documentation of that specification and how it should work. As written, you'll basically end up with the potential that every single OS ends up with it's own age verification system, which defeats the entire point of these laws in the first place.

Saying "all operating systems" puts us in this complicated and dumb position where now an embedded OS needs to worry about age verification of it's user.


I did this too, I have pi that downloads and combined a bunch of rss feeds every 30min (cron) and downloads the vids, I browse them with Thunderbird on my desktop, I inject a special link to the mp4 on my pi. So I can just watch vids at 192.168.1.106/videos/X.mp4 using the Firefox mp4 player.

Did it in ~300 lines of node.js, was trying to learn how to use JS for server stuff, seemed like a good idea at the time. It still works 5 years later, but it stands as a reminder to me to never use async/await.


> a reminder to me to never use async/await

What issues did you face with async/await?


Not using async/await is worse: you get sucked into then/catch, or worse, callback hell or shudder streams, which are known to be full of footguns and typically only approximate working correctly.

Of course you can go full sync if your app wouldn’t do anything useful during the time it’s blocked waiting for network or I/O.


This kind of thought is popular in the web world where browsers get an update every 3 days and you don't control the hosting services, so constant maintenance is unavoidable.

But in the world of desktop development it's possible for a library to be "done", having a 100% stable codebase going forward and requiring no maintenance. And it's not bad, it's actually good.

Requiring every dependency to be constantly maintained is a massive drain on productivity.


Once Zig hits 1.0 it will essentially be done. They don't plan on making further changes to the language, so they want to get it right while they can.

Looks like all the 2 users of C3 came here to complain about Zig. Why should we listen to you?

I've never even heard of C3, I use C++ and Jai.

I've never used Zig either, I just disagree that requiring constant maintenance is a good.


An interesting concept that stood out to me. Committing the prompts instead of the resulting code only.

It it really true the LLM's are non-deterministic? I thought if you used the exact input and seed with the temperature set to 0 you would get the same output. It would actually be interesting to probe the commit prompts to see how slight variants preformed.


> I thought if you used the exact input and seed with the temperature set to 0 you would get the same output.

I think they can also be differences on different hardware, and also usually temperature is set higher than zero because it produces more "useful/interesting" outputs


The LWN comments say that you are correct for local AIs (but not LLM services), modulo some caveats about compiler flags and hardware used.

I think the point is that it's not enforceable.


Correct. I think that's the purpose of DoH, but it's not helping me with my little game.


Not much apparently, although I didn't know about changing symlinks, that could be very useful.


Hm, I know that Safari doesn't support 64bit wasm, which is a very important feature that Chrome and Firefox both have, but this seems to say they have "100% webassembly support".

https://webassembly.org/features/


interop is a subset of tests chosen beforehand (nowadays, mostly by devs voting in the github issues). This says Safari has reached 100% on the subset of tests agreed upon for interop-25. Those specific tests can be expanded by clicking it in the menu. It'll take you here:

https://wpt.fyi/results/wasm/jsapi?label=experimental&label=...

The full test-suite of wasm tests are here:

https://wpt.fyi/results/wasm


Everyone discusses better parenting all the time. But some people forget what it's like being a kid, circumventing blocking systems is trivial if you're motivated, and even if they weren't, a cheap phone costs $80 and kids are very willing to share their old devices.


I had a second phone line installed at my parents house so I could have dialup Internet of my own, so I grew up on the Internet through the twilight of the 'golden years'. My parents had no idea what was going on, I was the only one in the household that knew anything much about computers and the Internet.

rotten.com was an interesting education.

I had a good upbringing and generally attentive parents on the whole, though, so I was already a well balanced young human.


Kids can also choose to disobey parents and play on train tracks or jump off cliffs or a million other dangerous things. Either you leave it to the parents or you end up spying on every single action they take.


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

Search: