I'd expect storage/batteries can help smooth this out by providing shiftable demand/production (with the right local control software running on/near the inverter)
I don't think the author has seen k8s done well. They imply that serverless is necessary to achieve a "you build it you run it" setup, but that's false.
We operate in a self-serve fashion predominantly on kubernetes, and the product teams are perfectly capable of standing up new services and associated infrastructure.
This is enabled through a collection of opinionated terraform modules and helm charts that pave a golden path for our typical use cases (http server, queue processor, etc). If they want to try something different/new they're free to, and if successful we'll incorporate it back into the golden path.
As the author somewhat acknowledges, the answer isn't k8s or serverless, but both. Each has their place, but as general rule of thumb if it's going to run more than about 30% of the time it's probably more suitable for k8s, assuming your org has that capability.
I think it's also worth noting that k8s isn't the esoteric beast it was ~5-8 years ago - the managed offerings from GCP/AWS and projects like ArgoCD make it trivial to operate and maintain reliable, secure clusters.
I'm probably missing something, so would be great to get a ELI5 for this.
How does storing passkeys in a password manager materially differ from the very long/strong passwords I'm already storing in my password manager? (and it's matching against the domain around autofill etc)
Passwords are a shared secret. You know it, and the website you are logging into knows it. If the website leaks it, someone else can log in as you.
Passkeys are a private key/public key pair. You give the public key to a website, but you don't share the private key with anyone. To log into the website, you encrypt a short message with the private key, and they can use the public key to decrypt it. If they leak the public key, it doesn't matter. Nobody can use it to log into the website. Only the private key can do that.
Also, there is a standard way of logging into a website with a passkey. The password manager can easily do it on every website. With passwords, every website is a little different. Your password manager can log in easily on some websites, and on others it can't and you need to copy and paste your password from the password manager to the website.
Besides being inconvenient, people have been able to write code that tricks password managers into thinking they are sending your password to the correct website when they are actually sending it to bad guys. Similarly, humans can be tricked into copying and pasting the password to the wrong place, giving it to bad guys. That leaks the important shared secret!
If someone tricks your password manager in a similar manner with passkeys (which is much more difficult because of the standard way password managers and websites communicate), all they get is a message encrypted with your private key. Maybe this could be used to log onto a website one time if they are very clever, but they do not get your private key which could be used to impersonate you many many times like a leaked password would.
Can't be phished. With a normal password manager, user error could lead to copying credentials and pasting out to a phishing page which is irrelevant with passkeys
Autofill is a good point but it doesn't help your parent who thinks the thing is broken so they have to do it manually, rather than realising it's a phish
A passkey never exposes a secret to the website, so neither malicious scripts (e.g. via ad networks or analytics “partners”) nor malicious browser extensions can scrape the password.
Plus passkeys are inherently phishing resistant, and don’t rely on the end user being wary when autofill don’t work. Autofill doesn’t work a lot, due to broken sites blocking paste as well as stupid sites that have you enter your creds to into multiple domains. (Yes, I’m looking at you, United Airlines…)
I often submit minor bug fixes or features to fairly popular projects, and as an outside contributor the communication can be very async. It's typically limited to GitHub PR/issue discussions, and sometimes the latency is measured in weeks/months.
I think it's probably quite different if you're a "core contributor" and likely using additional channels like slack and scheduled meetings, more akin to a company operating.
I'm no expert, but I'd imagine privacy plays (or should play) a big role in this. I'd expect that compute costs mean any learning would have to be in aggregate rather than specific to the user which would then risk leaking information across sessions very likely.
I completely agree that figuring out a safe way to continually train feels like the biggest blocker to AGI
My understanding of it is that it's just a bunch of well known HTTP endpoints that a server will call as things happen (eg: user is disabled).
I think the general intention is that these can/should be retried until the caller receives a successful response indicating the other system has updated its records.
(I'm not an expert in SCIM but I've played around with it, so could be wrong)
Something I found odd / unnecessary whilst building a SCIM client was that fields are supposed to be case-insensitive:
> Attribute names are case insensitive and > are often "camel-cased" (e.g., "camelCase")
Whilst it's not a huge deal to support this, to me this feels like complexity/flexibility for the sake of it - I'd prefer more rigidity and one correct way.
One thing I haven't completed for my SCIM client implementation is a decent grammar for parsing the filter parameters. Does anyone know of a comprehensive one, preferably peggy/pegjs?
When it comes to security, you are probably better off comparing things case insensitive. Like email providers also tend to do. It would be too easy to send a message to Joe@acme.org when you meant joe@acme.org otherwise, which ca be very problematic.
About filters, yeah that’s one of the bigger problems implementing SCIM. I implemented it myself but am not aware of any open source implementation. Look out for literal strings as they must be valid JSON strings which means they may use JSON escaping rules.
Agree on the emails (even just from mobile devices having a habit of putting capital letters in unintentional places), but I was more meaning the attribute keys, eg "username", "familyName" being case-insensitive. I'd be happy enough with any casing convention here, but would prefer one case sensitive one.
I suspect in practice most systems just use camelCase, but they could use TitleCase / ALL CAPS / etc which bugs me as it feels like a committee couldn't agree and decided "why not all of them".
There's a good chance there's historical context I'm missing, though I'd like to imagine any SCIM V3 might have stricter rules on that kinda of thing to reduce implementation complexity
In case anyone else is interested, I managed to get chatgpt to spit out an almost complete grammar https://github.com/mnahkies/node-scim/pull/7 - it's not perfect, but it did significantly better than when I asked it the same thing 9 months ago and got garbage/had to attempt writing my own from scratch (it's new attempt is more complete than my previous hand written attempt, I'm a bit of a skeptic, but credit where it's due)
I've been a bit of a skeptic around that, but recently had an amazing experience with a small motorcycle rental company where we arranged everything over Whatsapp.
They had a basic website that outlined their general terms and bikes on offer etc, but then actually arranging the booking dropped into WhatsApp which allowed me to outline my specific needs and get a useful steer. Throughout the trip I was able to continue messaging as things came up and it felt more like I was borrowing a bike from a mate than renting one from a business.
You'd be surprised but in SEA for 1-4 persons small businesses, that's how you do business. There is no website, offers are sent as pictures. Whatsapp is also used for everything else. I had one rental take a photo of the deposit and sending me the picture.
I'm Indian and see simple websites can get complicated quickly and nobody can edit a phone number without renewing the contract. So Whatsapp and pictures are the internet enabled stack of choice. Also there is so much lying and repudiation of lies that pics over Whatsapp are the "written statement". Traffic police take photos of haphazardly parked cars, makers share photos of in-progress works etc.
A text record of what happened isn't just useful for new hires, not just useful for async comms, but for people like me who want to be sure we followed along.
Spur-of-the-moment phone calls and meetings (especially camera-on ones with some uncaptured visual elements that the blind can't follow) tend to foul that up. And trigger the autistics who are likely hiding amongst the rest of you. We are legion. Treat us gently and we will likely do all manner of scutwork, refactoring old nasty untouchable code, and pager duty. i love debugging!
[Edit to add: Never trust a manager who likes to give directions in impromptu, unrecorded/unrecordable sessions. That means for some reason they want to be off-record. Or don't understand management. Either one of those is trouble.]
> [Edit to add: Never trust a manager who likes to give directions in impromptu, unrecorded/unrecordable sessions. That means for some reason they want to be off-record. Or don't understand management. Either one of those is trouble.]
I'll add "they're functionally illiterate" to the list of reasons managers and other awful-to-work-with people default to "a quick huddle". I have no data but I suspect this is a big reason and will be getting bigger as we start seeing more employees who went to school in the AI era.
This is also the real reason managers are so enamored of AI: reading and writing are, to them, the biggest obstacles in a typical day at work. Any machine that can help with this is welcome, and they don't have any experience what precise communication is actually like to understand how poor a replacement it is.
Phone call was available, but I choose chat in this instance. It wasn't a particularly complex conversation - I outlined my experience, and my doubts from my research and he came back with availability and some direction. I was on holiday with family in a different part of the country whilst arranging it, a few weeks out so there was no real time pressure. Tbh I'm also somewhat adverse to phone calls for no good reason.
At a higher level, this small business offered multiple channels and was able to meet me where I wanted to communicate. This is an advantage small business have because the volume is manageable. At larger scale it becomes more tricky to do economically and so you need to focus on self serve journeys (which may include chat bots, etc)
I'm not sure if you're implying that very small language models would be run in your raspberry pi example, but for use cases like the time series one, wouldn't something like an LSTM or TiDE architecture make more sense than a language model?
These are typically small and performant both in compute and accuracy/utility from what I've seen.
I think with all the hype at the moment sometimes AI/ML has become too synonymous with LLM
Sure if you have a specific need you can specialize some NN with the right architecture, collecting the data, doing the training several times, testing the performances, ... Or: you can download an already built LLM and write a prompt.
So one of the use cases we're serving in production is predicting energy consumption for a home. Whilst I've not tried, I'm very confident that providing an LLM the historical consumption and asking it to predict future consumption will under perform compared to our forecasting model. The compute required is also several orders of magnitude lower compared to an LLM
Nope, gemma3 and qwen3 exist of many sizes, including very small ones, that 4-bit quantized can run on very small systems. Qwen3-0.6B, 1.7B, ... imagine if you quantize those to 4 bit. But there is the space for the KV cache, if we don't want to limit the runs to very small prompts.
I guess you mean stuff like this https://gravitricity.com/ - I believe there's a few old coals mines in Scotland that have (/in progress) been retrofitted as gravity batteries to store renewables which is pretty cool (https://www.bbc.co.uk/news/articles/c5yd18q248jo)