joshfee

I've been using NodeRED + zigbee2mqtt/zwavejs for my locally controlled home automation to great effect. I expose all my devices to Google Home as a convenient frontend, but all the actual devices are mine and locally controlled so I can replace Google at any point. I tried home assistant years ago, but aside from the wealth of plugins I didn't find its approach particularly convincing. I have on occasion used it simply as a bridge between node red and HA plugins before though which is nice for niche devices or integrations

I see both sides of this argument and am really not sure which side I land on. But I wonder if this fits into things like driving, where hey - done recklessly this is dangerous to yourself and others around you, so we require some level of targeted education (e.g. a license). Then if you choose to be reckless anyway its a bit easier to say "it was your own fault".

I bet you credit providers would even front the cost of such a course, since at the end of the day they're still likely to make that money back no matter what.

I think the part that I struggle with is the hard reality that we are largely _not_ teaching people these practical skills in our education system and then expecting them to not get screwed.

For those interested in leveraging AI to build circuit boards, check out https://tscircuit.com/

I have no affiliation to the project, just someone that's done some hobby PCB design in the past and a couple weeks ago was exploring what's available in age of AI. Flux looked expensive and unimpressive. While it definitely burned through some tokens, I was able to get a seemingly functional PCB meeting my design requirements and was able to iterate on it using my existing Claude code subscription. I did use Gemini for some of the initial design research and parts selection since I find its search a bit better, but was overall impressed. I think with some tuning of the Claude skills to have it do a bit less guess-and-check it could be a nice workflow. Definitely better than the either really dated or really expensive PCB design tools in the market.

Isn't that true for any scenario previously unencountered, whether it is a digital simulation or a human? We can't optimize for the best possible outcome in reality (since we can't predict the future), but we can optimize for making the best decisions given our knowledge of the world (even if it is imperfect).

In other words it is a gradient from "my current prediction" to "best prediction given my imperfect knowledge" to "best prediction with perfect knowledge", and you can improve the outcome by shrinking the gap between 1&2 or shrinking the gap between 2&3 (or both)

It is great being able to generate a much larger universe of possibilities than what they can gather from real world data collection, but I'd be curious to learn how they check that the generated data is a superset of the possibility-space seen in the real world (e.g. confirm that their models closely match what is seen in the real world too)

It is actually one of the few cases where I don't actually really care about independent upgradability. In my experience I find that I pretty much always upgrade my CPU and my RAM in tandem. New CPU architectures sometimes force it (e.g. need DDR5 instead of DDR4), and as long as you don't severely undersize your initial RAM choice I find that I run out of CPU headroom before I run out of RAM headroom.

So if there's performance gains to be had by co-locating RAM with the CPU in a single package, it makes sense to me to do so

But you are also only a camera without LIDAR or RADAR, and you apparently navigated that situation successfully...

You can use a string union to discriminate when it makes sense, but that's not the only way to discriminate and in this case you'd instead use the presence of the items themselves (essentially duck-typing with strong type guarantees)

Typescript playground: https://www.typescriptlang.org/play/?#code/C4TwDgpgBACg9gZ2F...

How you define "external stuff" matters though. As soon as your function is calling another function, your test can be argued to be an "integration test", as you're now implicitly also testing the logic of the other function.

Alternatively you mock _everything_ and then your "unit test" ends up just being a tautological test asserting that "the code I wrote executes in the way I wrote it". (Not to mention that every time you mock something you are also implicitly asserting what the expected behavior of that thing is).

The only truly reliable tests are E2E tests, but they are too expensive to cover all possible permutations as there are just too many.

This is the catch 22 with testing, and we're always forced to make pragmatic choices about where to draw our boundaries to maximize the value (i.e. actual bugs caught) of them.

The problem with enforcing "freedom of speech" on private parties is that it essentially the same as infringing the speech of that private party.

The only issue I have is when companies can play both sides and in one breath claim they're neutral for the purpose of section 230 protection, and then in the next breath take part in censorship because it's better for business.

Pick a lane, either lane, but you shouldn't get it both ways

Forget about reading articles even... the supreme court decision itself is not long, is written in understandable language, and breaks down point by point the things that they had to consider, why they had to consider them, and the outcome of that consideration.

I think the easiest answer to follow for "why is this not prevented by free speech protection" is "the fact that petitioners “cannot avoid or mitigate” the effects of the Act by altering their speech." (page 10 of this ruling, but is a reference to https://en.wikipedia.org/wiki/Turner_Broadcasting_System,_In...)

The case law around editorial control is at odds with most platforms' section 230 protection, which makes the fact that TikTok argued that its algorithm _is_ speech pretty different from how most platforms have argued to date (in order to preserve their section 230 protections)

The whole premise of this article is non-performance reasons to love rust

Returning control to the caller only really needs to be explicit if you're doing it in an arbitrary spot in the middle of the function because if you're at the end there's nothing to do _other than_ return control. For instance in other languages you don't need to explicitly say "go to the next iteration" at the end of a for loop, and if you want to do it before the end of the loop body you can `continue`. If "flow control should always be explicit", then should we be writing `continue` at the end of our loop blocks?

I think the other part of it is that it is just part of a cohesive language design where everything is an expression, including things like if's, matches, etc that would be control flow statements in other languages.. It would be a little weird to say that functions are the only thing that have different semantics.

I think the idea is that there are many factors that might motivate somebody's decision that their life is not worth living any longer. Each individual will have a different threshold for that, but if there are institutions that can alleviate the reasons for the people on the fringe, then there will be net fewer people that choose death when they otherwise may have.

Someone with advanced dementia may be too far from that threshold to change the decision for them, but that doesn't mean that better institutions wouldn't move the needle.

Like others are saying, this just looks like a rebrand. Hopefully this competes in performance with the 2019 Nvidia Shield TV Pro which is to date still the only streamer that performs well enough for high quality audio and video, but is starting to age (and no longer works with things like google home audio groups). If anyone knows of a comparable plex streamer let me know :)

The mistake here is thinking that cost and price are related beyond determining what the final margin is.

The consumer decides the price that is acceptable for the good - the cost of that good being higher or lower just changes the viability of the product and the bottom line from selling it. So it makes tons of sense that given two similar products that consumers will pay a similar price for that companies would prefer to sell the one that costs them less.

After a recent mention on HN I gave Kagi a try and subscribed for a few months. But after using it I'm really not sure why it get so much for the core "search", I found it so underwhelming that I would instinctively use the !g bang to just go right to Google.

It turns out that even though I can't stand the number of ads, Google is still much better at getting me an answer quickly (usually with the quick answer modules).

I was also surprised at the number of times Kagi came up with 0 search results, and while one of the draws for me was to have higher quality results instead of quantity, I still found a _ton_ of results for AI generated crappy top-10-list sites trying to sell me something.

Love the idea, and will probably check back in from time to time, but so far the execution just isn't there for me.

Really depends on "how many people". Also if its roughly the same group of people they're making angry over and over, and they don't see an impact to the bottom line, then I'd say the answer is "pretty small", at least relative to Google's size (at which its all about volume)

Google is basically split into "build things that make users happy" teams and "build things that make Google money" teams, so I think that on an individual product level you may be correct, but in aggregate at the high level Google believes there is a ton of value in revenue-less products.

Now for Podcasts (or any given product) there's always going to be some calculus of "is it enough value to justify the cost", and clearly Google believes the answer here is no.

As fast as the terrible wifi on the switch will let you

The most unexpected 2048 clone

I think a company taking things seriously would view it as a gift from the heavens, but the fact that Boeing is seeking an exemption for certification doesn't really seem like they're putting safety ahead of profits.

I just spun up a self hosted instance this past weekend, and while its fairly decent it doesn't seem to hit the mark compared to Notion (which I use at my day job). There's just a bit too much friction in creating pages (you need to click "publish" on every page you create), no /page command to quickly jump into a nested page, and.

I'm more excited by Affine (https://affine.pro/), though their self hosting support seems to be neglected, and it has the same "not actually open source" issue as Outline.

I use B2 as the backend for my personal backups using restic (which I would highly recommend https://github.com/restic/restic). I don't have a ton of data to backup, so even with hourly backups (restic only backs up when there are changes) I have ~100GB and it runs me a whopping $0.60/month. I almost feel guilty when I get the bill. But the minute I need to pick a storage platform in a professional context I know what my first choice will be.

(I am _not_ affiliated with Backblaze in anyway. Just a happy user)

Surprisingly I think this usage of clickbait is totally reasonable because it matches the author's initial thoughts/experiences of "what?! this can't be right..."

This was a flaw in the original AlphaGo, but the subsequent AlphaZero (https://en.wikipedia.org/wiki/AlphaZero) trained entirely from self play with no prior information. So essentially it _does_ build fundamental understanding.

I think the ability to learn by self play (essentially in a closed room without external training data) is where the line between "fundamental understanding" and "regurgitating information" from these AIs lie.

krita.org is a similarly polished and professional open source project, but I agree these types of projects are the exception rather than the rule (though I suppose the same could be said about most products).

I think the problem works both ways too, because for an in progress (but long-running) workflow, you may not want to retroactively apply your new business logic for the part that's already run because that would be unexpected. But for the logic that hasn't run yet, you would certainly want the latest and greatest.

I wonder if there could be an approach where you have both versions live simultaneously, and introduce some sort of "checkpoint" into the old version that would act similar to a DB migration. When re-computing a workflow you could then start from the latest checkpoint, but any workflows that were created with the old version that haven't reached a checkpoint would continue to run the old code until it does.