I'm currently polishing one of my packages for publication, and for that do a lot of testing in a vanilla Emacs. It's shocking how many of even (to me) absolute core functionality is actually customization I did a decade or two ago, and then forgot about.
And the yet again I got told over and over again that Bambu didn't really mean to, and if they did they learned their lesson, and after all you can still keep them offline. And spending more for a prusa obviously is silly.
I'm really getting too old dealing with morons who didn't learn anything after the same patterns repeating for decades now.
I'm honestly not getting the complaint here. Bamboo Lab forced competitors to step up and actually produce good products. Now that there are many Bamboo Labs competitors you are no longer dependent on Bamboo Labs anymore.
I'd love for this pattern to repeat for eternity.
If anything this is the good ending to the story. The rise and fall of a giant.
I've been in a similar situation - a surprising amount of companies really just click to create instances. Last time I've encountered that at a customer I improved things a bit by creating templates, and scripting instance creation based on those templates - but ideally we'd have had the templates themselves as well as the network side generated by ansible.
But that's the problem: The complexity of doing that properly is pretty much the same as just doing your own hardware (which is what I'm working with most of the time - handling stuff on physical servers). And at that point the question should be why you're paying AWS so much money and pay your people to automate AWS workflows when you could just pay them to automate workflows on physical hardware, which would be way cheaper to run than the AWS instances.
This is always the weird things in those rants. He's complaining that after 4 days his mails are offline.
Now I'm doing a mix of physical servers in rented rackspace, and rented servers - but even there I can have billing mixups where they deactivate servers for no good reason. And to get email working again the limiting factor would be the DNS TTL - new servers would be online somewhere else within hours of it going down. (And yes, I tested that just last year - one hoster threatened cutoff due to non-payment on a paid invoice, which prompted me to move the mail server just in case while getting this resolved).
The only way that email is down for days for a competent sysadmin is if their DNS is also with AWS, so I assumed that was the case. Assuming that is true, what is weird to me is that, after deciding he hated AWS and left it, that he still kept his business DNS (the most important service there is) with AWS.
If you would have read the article, you would know that the writer had DNS hosted at AWS, would have read why he made that choice and would know of his plans to migrate off.
I assumed he just had DNS at AWS, but after re-reading I guess he has DNS _and_ domain registrations at AWS, which would be a special kind of stupid. That's something we were advising customers against already back when cloud wasn't a thing yet to enable fast transfers when stuff goes south
(to clarify: DNS+domain at the same service can be OK, as long as you have nothing else there. As soon as you start having other stuff, keep the DNS there, but move the domain registration away. Depending on which domain make sure you have auth keys, access to the admin domain or whatever would enable moving the domain without registrar cooperation. In my hosting days I did my fair share of emergency transfers and infrastructure to help companies get their basics online again after a SNAFU - totally doable to have first mail coming in again within a working day)
It is pretty much unacceptable to have a domain bouncing emails, so I’d be out of the provider before the MX TTL even expires.
For outgoing emails, reputation is a huge issue, but at the same time it’s also fairly trivial to set up a (different) 3rd-party (gmail, outlook, sendgrid, whatever) with previous reputation so you can get back communicating.
I've found a lot of issues come through somewhat naive networking setup - which is encouraged by the "just yolo it" installation instruction in the documentation. If you want to start understanding what's going on you'll end up in very weird corners very quickly. Also, if you don't want the API endpoints available to the world the documentation is not much help.
I've found things more stable if you can give a dedicated interface just for internal k3s communication. It can be a bridge interface on top of a vlan interface - but not the vlan interface itself, or some things will break in very interesting ways. Also, even when using IPv6, just stick with internal IPs and nat everything - touching internal IP ranges is no fun. Plus, if there's a chance you'd ever want to use dual stack, set it up with internal v6 addresses, and just don't use the v6 addresses for now. There's also a lot of unintuitive behaviour around dual stack networking - and lots of areas where documentation is just plain wrong.
I'm scripting our stuff with ansible - one of the more useful things was the realisation that in some areas changes which shouldn't break anything can lead to cluster communication being interrupted, which is a very interesting thing to deal with, especially when you can't pin it to that change that didn't touch anything close to that, and therefore should not be responsible. I've learned, and sprinkled checks to make sure all members can still reach each other in there now, so that at least when I break it on changes I directly know why.
In enterprise setup when you are dpeloying on customer, airgapped, no access to internet and repositories, you generally dont have control over the infrastructure. It can be as hostile as you can think of.
Back in the early 90s I've discovered that there's not really any backchannel happening when printing to a dot matrix printer over the parallel port. And adding multiple ISA parallel port cards set to same IO address wouldn't cause any hardware issues, but just spit out the same data on all cards.
Which meant, as long as no paper was jamming, I could send data all three printers I had access to at the time could understand, and would save 1/3rd of printing time by having everything spit out in parallel.
My mother (parents bedroom adjacent to mine) did not think that'd qualify as ASMR at 2 in the morning.
I didn't read much of the page - just was scrolling a bit to see what the fuck that thing is doing, and that was more than enough to know that I'll never touch whatever those people are doing.
> On the one hand, moving from assembly language to C made programmers less effective in some ways and more effective in others. On the other hand, the transition from writing code by hand to using AI is arguably a bigger shift,
I think that's a bad comparison, mainly for two reasons:
We still have people dealing with assembly for building the compilers. We don't quite have that for AI - which became very clear with the claude code leak: We just have people trying to get the correct behaviour, but without understanding why.
The second reason has more practical implications: I generally rely on my compiler to be deterministic, and not introduce security issues (which they sometimes do, by optimising away safeguards placed by the programmer - but that is relatively rare, and we can trace and fix that). But generally as a developer I can rely on my compiler to produce machine or byte code I don't have to think about.
The same is not true for AI - the regularly produce insecure code. This can partially be mitigated by having another AI review it - but it's not a proper solution. Until we get proper AI which can actually understand things we need somebody in the loop who can understand the code.
