windlep

I've looked over the code, and some things seem a little odd to me.

The article starts by mentioning how insecure the browser is, apparently even cookies aren't secure. But then the API to talk to the BFF uses.... a server-side session tracked via a client cookie. If the BFF is holding the oauth credentials, then someone could steal the client cookie to make requests to the BFF to do whatever it can do.

It's not impossible to secure the browser from having credentials stolen from inside it, but it can be tricky to ensure that when the browser sends the credential in the request it doesn't leak somehow.

There's some irony as OAuth has DPoP now which can reduce the usefulness of stolen in-flight credentials but that can't be used in this BFF setup because the browser client needs the private key to sign the requests.

Properly securing the browser content on a login page, or the subdomain handling authentication credentials is definitely a challenge, and many don't like having to eliminate/audit any 3rd party JS they include on the page. I can see the appeal of a solution like this, but the trade-off isn't great.

Self-hosted FreshRSS, NetNewsWire on Mac, Fluent reader on linux/windows/ios. Any reader compatible with Google Reader API works with FreshRSS, and Fluent was the nicest UI I've seen (hasn't been updated recently, but I don't need new features).

I was able to make a uWebsockets adapter for NestJS pretty easily. It's a bit sensitive of a library to integrate though, a single write when the connection is gone and you get a segfault, which means a lot of checking before writing if you've yielded since you last checked. This was a few years ago, perhaps they fixed that.

I was under the impression that the underlying net/http library uses a new goroutine for every connection, so each websocket gets its own goroutine. Or is there somewhere else you were expecting goroutines in addition to the one per connection?

That's just an arms race. The kid will find a new favorite website to play games on, there seems no end to them. There's endless websites out there that are more appealing than doing homework. I have a very locked down network, there's always some new website that has games of some sort to play.

If schools are going to provide these things, they should have the sites the kids might need to access white-listed and block everything else. Telling parents to try and block things is not realistic.

Yes, that was kind of my point. Self-hosted negates the need, but most can't self host.... so that leaves end-to-end encryption the best intermediate step.

I self-host Immich and its definitely my favorite web photo system. One thing with Ente that aligns more with Mozilla's approach to data however is end-to-end encryption, which Ente has, but Immich doesn't. So I can see why Mozilla funded this option instead.

I personally wish that self-hosting was a more reliable and simplified process for the average person such that simpler and more powerful software like Immich was the best choice for all.

Yep, some of the nicest docs for a language I've seen.

The mix package manger for Elixir has a release option which compiles and bundles everything to a single binary. It appears possible to use Gleam libraries/code with mix, which should allow one to compile it all down to a single binary as well (though I haven't attempted this myself).

Definitely, while I have volsync backing it up, and the PV is replicated for local availability.... still annoying.

I've been self-hosting a lot of things on a home kubernetes cluster lately, though via gitops using flux (apparently this genre is now home-ops?). I was kind of expecting this article to be along those lines, using the fairly popular gitops starting template cluster-template: https://github.com/onedr0p/cluster-template

I set one of these up on a few cheap odroid-h4's, and have quite enjoyed having a fairly automated (though quite complex of course) setup, that has centralized logging, metrics, dashboards, backup, etc. by copying/adapting other people's setups.

Instead of weechat, I went with a nice web based irc client (the lounge) to replace my irccloud subscription. kubesearch makes it easy to find other people's configs to learn from (https://kubesearch.dev/hr/ghcr.io-bjw-s-helm-app-template-th...).

The patents page (https://www.google.com/patents/opnpledge/patents/) does not include the macaroon patent. Maybe they forgot to update it?

That was what the authors claimed when I asked them about the macaroon patent. It'd be nice if Google had a legal document associated with patents they never plan to enforce, or the constraints around when they might enforce them (e.g. only against patent trolls) that a company could rely on.

I remember when I saw a presentation by the macaroon authors a few years back, there were pending patents that Google filed around them. While the authors claimed Google wouldn't sue anyone, I'm always a bit skeptical about such claims. I thought macaroons would be helpful for some of my use-cases, but since I now knew there were patents that'd be wilful infringement so I didn't bother.

I can't find the patents now, so perhaps they were rejected or withdrawn. I had assumed that was why macaroons hadn't caught on more widely.

Edit: Found the patent: https://patents.google.com/patent/US9397990B1/

This is how I use the tool the author created, Structurizr. I auto-generate the initial diagrams, then manually fix it to make it more readable. We then check-in the JSON workspace export into our git repo. The first two levels of the C4 model don't change regularly, so this isn't a frequent process to repeat.

Not sure, it depends on what the numbers look like going back to the founding of the company. Tesla probably wouldn't have survived in the past without the credits, but as others in the comments noted the point of the credits is to enable companies selling EV's to survive and grow during their difficulties in the switch to EV's. So I definitely wouldn't consider this a mark against Tesla, the credits are doing what they're supposed to, to an extent.

He added some context specifically about that note:

https://twitter.com/stealthygeek/status/1596605162294218753

It would be interesting to see the % of profit over time from regulatory credits, which appears to be what the author is focusing on.

That's a once type thing, the website is supposed to prompt you after that QR login whether you'd like to enroll your local authenticator (Chrome, Edge, Firefox,etc) after you login so you don't need to keep using the QR code.

The concept is that many people will frequently have multiple passkeys, thus not be 'locked in' to any one sync ecosystem.

From https://github.com/w3c/webauthn/wiki/Explainer:-broadening-t...

When signing in on a different computer, either the credential will already be locally present (if the computer is using the same sync fabric as the phone) and suggested by autocomplete, or else the user’s phone can be used to transmit the assertion to the computer. In the latter case, the service may invite the user to enroll a local platform authenticator for easier sign-in in the future. (Now the newly registered credential may be part of a different sync fabric, and thus enable local sign-in on other devices.)

Disclaimer: I've done some development on Home-Assistant (HASS), and work on the Nabu-Casa cloud service for Home-Assistant. I was contacted by a NixOS core contributor to see if there was a better solution for HASS in NixOS.

This is a bit misleading, a single HASS developer requested their packages not get repackaged because they didn't want the support burden of users who think the software is broken when its actually due to packaging.

Originally on HN here: https://news.ycombinator.com/item?id=27505277

Both the GitHub issues have since been closed and settled.

It's useful and important to note that Home-Assistant's turnkey ease-of-use is partly because its acting as a package manager of sorts. When integrations and components are added by the user, their package requirements are downloaded immediately from the Internet and installed. This is quite contrary to the intended operation of NixOS and its immutable and reproducible package installation concept.

This is where the concerns of Frank came in, as a user of HASS on NixOS will likely have a sub-par experience and the documentation on the Internet for HASS will not work correctly for them in many cases. On the other-hand, I'm sure a decent amount NixOS users are probably aware of this (as I was when I was using NixOS daily).

My suggestion (and supported by the HASS founder) was that NixOS repackage HASS and call it something else, like how the code behind Firefox is repackaged without the Firefox name. This way at least NixOS users of it will get more appropriate Google results when searching for an issue related to their install, and are unlikely to burden HASS developers with support issues that are likely related to the install approach and not a HASS issue.

This was back in July of 2021, and I haven't followed up on it since, so I don't know if NixOS is doing this yet, or what the current state is there. But if you're running NixOS and want that turnkey experience, you're not going to get it.

If you want a full turnkey setup I'd highly suggest using HASS OS, whether on a small dedicated device, or in a KVM (https://www.home-assistant.io/installation/).

Maybe not a surprise that they also have trouble getting employee's right now?

Not sure a pig farmer has the best perspective on this. I've been on farms in my area, that have land that is not usable for farming, too many rocks, too hilly, etc. The land has enough natural rain-fall and grasses that grow on it to sustain sheep/cattle where there would otherwise be nothing but a fire hazard come the dry season (California).

In this one and perhaps not common scenario, I think eating meat from these sources, slaughtered humanely, is reasonable. This obviously is not enough meat even for locals in my area to be having burgers daily, so a huge reduction in meat consumption is needed even if one wants to continue eating meat 'responsibly'.

This article unfortunately does not mention that grass-fed meat has different omega-3/omega-6 ratios than factory farmed, and eating smaller quantities of grass-fed meat is healthier than larger quantities of factory farmed. Not sure any meat industry person, even sustainable, is going to mention that cutting back from typical American consumption is a good thing.

My biggest two issues:

1) Stripe docs are inaccurate. They frequently don't work exactly as they describe for given subscription workflows. Sometimes an API call is entirely wrong, sometimes it doesn't return the data the docs indicate, and sometimes the arguments it describes just doesn't exist. (Yes, I've ensured I'm using the latest API version in use).

2) The docs have no changelog. There's an API changelog that indicates when API's change, there's nothing indicating when entire chunks of the documentation change on the website, along with the recommended way to integrate. The most obvious example of this is that the subscription workflow docs got a huge makeover in the past year (sometime), with some really great flowchart diagrams. But back to point #1, some of the API calls listed here are not actually valid. If I've just missed the changelog for the website docs, please point me in the right direction. :)

For reference, I'm using Node at the moment, but I've also integrated with Python, and there were breaker bugs in those docs as well. I eventually end up reading the HTTP API docs, then going through the SDK's to see where they went wrong, or the docs went wrong.

Yup, that hasn't changed in our experience. If you're looking at bursty traffic beyond what AWS will pre-warm for you, then this likely won't work. We have fairly consistent loads throughout the day.

Yes, if you terminate TLS its drastically cheaper. Without TLS, each NLB unit lets you have 100,000 concurrent connections. With TLS, a single unit is 3,000 connections. Similar pricing occurs with ALB's.

Terminating TLS yourself incurs some CPU cost and a bit more memory cost. How much CPU/memory is eaten depends on the efficiency of your code. Our Rust implementation roughly matches C code efficiency, so we could handle terminating TLS ourselves if ELB stops being feasible at some point.

Same issue as NLB, they charge for units based on concurrent connections and it gets very expensive very quickly.

We did not use an NLB because it is expensive in its pricing model for TLS connections (and we prefer to let AWS terminate TLS). For 20 million connections, an NLB would cost $28,800/month. It's drastically cheaper to use an ELB, provided you can talk to AWS to have them scale it for you.

I don't believe the "worker bee" trait you mention has much correlation with executive functioning.

The way I've heard/seen it described in ADHD research is more that without executive functioning, putting together events in the past, applying them to the present, with a thought to the future outcome is the main issue. When your executive functioning is poor, your decision making is severely impacted because the ability to chain together past experiences with the current situation to chart a good outcome fails to come together.

So if you wanted to make up a situation in the past that isn't a 'school or workplace', imagine someone on the hunt, failing to correctly interpret signs of a dangerous animal nearby and take appropriate precautions, and therefore dies. That would be a failure of good executive function.

The traits identified in ADHD materials like these (below) are effectively a different way of phrasing the same outcome but those with ADHD may be lacking more in one of these distinct areas: https://www.understood.org/en/learning-attention-issues/chil...

To be more specific, lots of idiomatic Go patterns typically involve using channels. Working at this level means you can't do that per 'client' since that would imply at least one goroutine per client.

There's plenty of libraries that involve channels (and assume you have goroutines per connection/client), do those play well with the use of epoll in this manner? I would assume I can't use the stdlib time package to do a timeout for example, since that provides a channel to wait on, while in this setup I need objects that work with epoll. Obviously in that case I could use evio which abstracts over epoll/kqueue and provides a Tick...

So my comment was more that "dropping to this level" means dropping the use of the majority of standard Go concurrency idioms which revolve around goroutines and channels. It's not about the raw lines of code involved. Writing code in this style of async doesn't feel very Go-like and when you look at an example of some code using this style its exactly the thing Go was trying to avoid with goroutines (https://github.com/tidwall/evio/blob/master/examples/http-se...).

You end up with async event-based code, not the clean synchronous-appearing Go code that goroutines and channels provide.

Noticed they had to down to epoll: https://github.com/eranyanay/1m-go-websockets/blob/master/3_.... that seems a bit too low level.

Agreed, I'd be quite curious how many libraries in the Go ecosystem they can't use as a result. Either because the library spawns a goroutine, uses one under the hood, etc.

Having to drop to this level makes me wonder if it'd be better to just use a language better suited to this type of asynchronous networking (C/C++/Rust).

Does anyone know what it costs?