chakspak

Hopefully this isn't off-topic, but your setup sounds just like mine, Strix Halo and (I'm assuming) llama.cpp on ROCm, and I'm finding that the Qwen hybrid models don't handle prompt caching and instead re-process the context in full on every turn. I'm wondering if you were able to solve this and how?

I'm a software developer, so I type a lot. Typing is very practical for throughput and speed.

But I still make time for writing by hand. I find it to be very valuable, because it forces me to think differently about things and sit with ideas longer. I also find journaling almost impossible to do on a computer but very accessible in a notebook.

Writing by hand is also portable and adaptable. You can write on paper, surfaces, and signs. You can write when there's no power. No subscription is required, it doesn't require firmware updates, and it never has connectivity problems.

I can understand why some people would be willing to say goodbye to handwriting, but it's a skill that I'm extremely grateful for and I would be very sad to see it disappear from the world.

This name is perfect. I hope this gets traction.

Trump got a plurality of the popular vote, not a majority. There are lots of people who didn't vote for this. Many people are now doing whatever they can to limit the damage, but it's an uphill battle and plenty damage will be done in the meantime. It's been very hard to watch this unfold.

BSL is not an Open Source license, as it does not meet the requirements of the Open Source Definition. https://opensource.org/osd

Sphinx is powerful and hard to beat if you're looking to generate documentation from code in multiple languages or export to multiple document formats, but it's slow and creaky and hard to hack on.

MkDocs by itself is okay, but Material for MkDocs is life-changing:

https://squidfunk.github.io/mkdocs-material/

If it does everything you need it to do, it'll make creating and editing sites much faster and with fewer opportunities to break things.

Holy wow, it never occurred to me that there were enough organizations launching satellites to warrant creating a managed service to support it.

PDF rendering is the bane of my existence. I've found it stunningly difficult to generate an acceptable output from a source format like Markdown, and the process usually requires massive dependencies and fiddly configuration to get something close to what you want. Don't even try to produce numbered headings or a cover page unless you're willing to write the whole thing in LaTeX from start to finish, but who knows if you'll ever get the table to appear in the right spot on the page. :D

disclaimer: I have very little skin in this game. We use S3 for some static assets, and with layers of caching on top, I think we are rarely affected by outages. I'm still curious to observe major cloud outages and how they are handled, and the HN reaction from people on both side of the fence.

I'd like to share my experience here. This outage definitely impacted my company. We make heavy use of autoscaling, we use AWS CodeArtifact for Python packages, and we recently adopted AWS Single Sign-On and EC2 Instance Connect.

So, you can guess what happened:

- No one could access the AWS Console.

- No one could access services authenticated with SAML.

- Very few CI/CD, training or data pipelines ran successfully.

- No one could install Python packages.

- No one could access their development VMs.

As you might imagine, we didn't do a whole lot that day.

With that said, this experience is unlikely to change our cloud strategy very much. In an ideal world, outages wouldn't happen, but the reason we use AWS and the cloud in general is so that, when they do happen, we aren't stuck holding the bag.

As others have said, these giant, complex systems are hard, and AWS resolved it in only a few hours! Far better to sit idle for a day rather than spend a few days scrambling, VP breathing down my neck, discovering that we have no disaster recovery mechanism, and we never practiced this, and hardware lead time is 3-5 weeks, and someone introduced a cyclical bootstrapping process, and and and...

Instead, I just took the morning off, trusted the situation would resolve itself, and it did. Can't complain. =P

I might be more unhappy if we had customer SLAs that were now broken, but if that was a concern, we probably should have invested in multi-region or even multi-cloud already. These things happen.

Don't disagree. It's a problem. As the parent poster and others have mentioned, you can use something like pipx, or bare virtualenv. At least once I've deployed via dh-virtualenv and rpmvenv, pyinstaller, cx_freeze, or tested for compatibility with the system Python if I could control for the client machines.

It's never fun. It's never pleasant. But to be fair, if I have a CLI tool that needs a deployed SSH client, or Tensorflow, or SDL or Qt or something else, I'm not convinced packaging gets much easier no matter what language we're talking about. If your use case is simple, Python is easy enough to deploy, and Go is even easier. If you can't disable CGO or need a third party component, I imagine the fun is just getting started anyway.

As a counterpoint, awhile back, discovered that Golang had a minimum kernel version requirement. That pretty much eliminated it as a possibility for writing tools for legacy systems. Python was viable though, Bash moreso. :) Couldn't tell you if that was still a requirement for Go today.

One thing that I wish was mentioned in this article is that Kubernetes already provides a pretty good compatibility layer between cloud providers.

If you don't completely bake your app into AWS by using the AWS SDK all over the place or using a database that only exists in AWS or something, moving individual apps is just not that bad. You still gotta solve the cross-cutting things like logging and metrics, but you gotta do that anyway, and that shouldn't (!) require code changes to your app.

To be fair, that's all moot if you're not using Kubernetes in the first place. As well, things like EKS pod roles add great value that you'll have to sacrifice to truly call your app "portable".

I second having an internal PyPI. Not requiring your customers to build your platform wheels for you simplifies Python distribution quite a bit.

It'll never be as clean as a static binary build, but it saves us from having to build out two language ecosystems when the rest of the company uses Python for everything.

I think that's already started to happen. I had to buy the Essentials kit this week because a standalone Pi was not available from any distributor, with lead times of up to a year.

This. I have a friend with 1Gbps up/down at his house. I've been waiting for fiber for like 10 years but it's never been available at any place I've lived. This is despite the fact that we live in the same (relatively small) county. This situation could only be possible if they just didn't care about making fiber available to everyone.

I was thinking the same. I hear this company name all the time at my work, so when I saw the title, I did a double-take and thought there was a typo. They even have AI voice command, so I briefly thought it was the same company.

I had to stop driving for four months after I had a sudden major seizure episode. Changes to medication also meant not driving for a similar amount of time.

I have not had an event in years, and no longer take medication, but anxiety about driving and being independent is still something I carry with me.

This article didn't add anything to the conversation.

"Secret management" (i.e. having a non-ClickOps way to deploy secrets and a layer of security so that they're more than just not-configmaps) has been a black hole that has eluded our team for some time.

Should I use SOPS? Sealed Secrets? Vault? KMS? How does this integrate with our GitOps engine? Kustomize has no sensible way to pass secrets built in. ArgoCD actually has to be rebuilt from source to even try any of these options out.

Our current "best" practice is using Helm + Terraform, bootstrapping secrets with Terraform Cloud, and ensuring all services run in their own isolated namespace and service account. This feels inadequate.

At this point, I really have no idea how people are using secrets in the wild.

You can also quit the CLI editor, e.g. vim.

I thought that was a peculiar choice of words as well. I would understand these things under the banner of "Build Engineering", or even just "Tooling". I couldn't figure out the distinction they wanted to make by calling it "Metaprogramming".

Wow, all day? That's a lot!

My team and others have been having "office hours" meetings where everyone is just working, but often the cameras are off, mics are muted most of the time, and we only do it for a few hours a week.

I definitely agree that there is a lot of value in being able to jump in and ask questions in the moment. That's a big benefit of having these calls for us.

Maybe we should try having them more often. :)

This tutorial looks amazing. I know what I'm going to be doing the next few weekends.

There is a real use case for a tool like this.

I once had to manage a large, locked-down installation of extremely custom Linux distros running on extremely custom legacy hardware.

Python was not available, and definitely not Ruby, so that eliminates a bunch of CM tools. Not sure if it'd even fit on the ROMs of some of them. The hardware was a mix of ancient MIPS and PowerPC and ARM and x86 in the same stack, so compiling anything for the targets would have been painful. Nevermind kernel/libc versions so old that lots of commonly available tools wouldn't even compile on them. Golang has a minimum kernel version, you know. :P

Guess what all these systems could run though. Good old sh and sshd. I could send/receive files with cat and tar. I could collect system info from /proc. I could do pretty much whatever I needed. I ended up writing a tool very similar to this one in spirit, though not nearly as polished, and I didn't get to take it with me when I left the company.

Shell syntax can be obscure and confusing, but when you have nothing else, a shell gets the job done. I'm happy to see someone had a similar problem and solved it, and then made it a thing. :)

I generally agree with you, though I want to comment on this line:

Code that you don't touch doesn't suddenly change its behaviour one day.

This can and does happen all the time, when the platforms and abstractions your code builds on change underneath you. This is why a compelling environment / dependency management story is so important. "Code rot" is real. =P

I've got a couple of these:

- Stretch of freeway by my old house that looks and feels like any freeway you've ever been on, except they limit the speed to 45mph. Try to go 45 at your own peril as car and semi alike go 65 past you. Then the cop camps there. I avoid that freeway now.

- Shopping center exit onto a small side street had a "no left turn" sign, but trying to obey this meant a massive detour around if you needed to go left. The side street was empty most of the time (and low speed!), so people tended to just go for it. Cop camped out there. They removed the sign a year later.

Yeah, there are quite a few applications that actively discourage the use of anything other than their CLI, which I find profoundly bizarre. Istio had a big warning in their docs that their Helm charts were deprecated, even though istioctl uses them under the hood. Funny that Kubeflow has its own Istio deployment, and they make you use kfctl to deploy it, haha.

It's not strictly required, but might be for you, since A/B deployment actually is a thing Istio does. We only use Kubeflow Pipelines currently; looking into Katib.

My feeling about Kubeflow is that it's a package of a lot of things that exist, with nice things on top, and an easy way to deploy those things. Only, it ends up not being that easy, and not easy at all to configure, and various features of the underlying tools are hard to get to or completely unavailable.

If you deployed your own Istio, you'd understand it end-to-end and could solve problems with it when it goes south, and you'd even understand what exactly you're using it for and why. The biggest problem I have with kfctl is that it basically asks for system:masters privilege to install everything and then you get to figure out what it did on your own. I don't want Istio, Cert-Manager, Knative, Argo, etc. deployments that I don't understand and can't easily configure because they're buried 5 levels deep in Kustomize overlays. These are all things I can install from elsewhere and with more documentation.

Kubeflow Pipelines is still a little mysterious, but the footprint is much smaller and not as invasive.

Never used Polyaxon. Gonna be Googling that!

My company has deployed Kubeflow for production model training. Early on, we used their big deployment, but we got frustrated trying to manage it with kfctl, so we started using kustomize directly and deploying only what we need, like KFP. So no istio for us! YMMV with your use case.