finaard

> As for the second part (separate authentication methods), sure, would be rather problematic if they require you to have a phone, but that's a completely separate and different issue.

It's getting somewhat annoying nowadays with banks pushing that crap, but fortunately legislation for access of people with disabilites forces them to provide tokens still.

A lot of them now switched to banking apps on the phone acting as token without a chance to opt out, though, so as a result I've stopped doing anything bank related on phones nowadays.

It heavily depends on "what kind of DC". A lot of current DCs are not really well protected against a lot of known threats - and that's just a design tradeoff.

High value data is already protected a bit better (or at least should be - the usual trend, management gets lazy when nothing blows up). I'm old enough to have sat in the meetings for "so, apparently a plane crashing into one or more of our locations is a viable risk now" - and a DC hardened for "somebody tries to land a 747 on that thing" should also survive a small drone with a bit of explosives.

While for the younger ones the "we lose several availability zones within days" is a new thing now - it really isn't. We were planning for that back then as well, just that we didn't call it "availability zone" or "cloud" yet.

Well, that's why you had /usr/xpg4/bin, /usr/ucb/bin, .. so you'd have all the variants of all the tools readily available.

I'm still searching if somebody else made something for tiny tooling before I start throwing something together. Getting something just working is easy nowadays, and makes things that we considered not worth the effort before viable, but making sure it actually is good, doesn't have unintended side effects, and has good documentation (which I'm still typically writing by hand) adds quite a bit of extra effort on top, which still makes sharing the better option than just doing everything yourself for a lot of things.

Both. My standard phone defacto already is a burner phone, so I'd just either wipe it or pick something new up when travelling to that kind of countries.

Similar for a notebook - I'd travel with an empty one, restore it after arriving, and wipe it again before leaving. I have infrastructure in place to make that easy and secure for me to do.

I went for a slightly different approach, described in this thread: https://bsky.app/profile/bernd.wachter.fi/post/3mvv2g4zxp22v

No code published currently, but if somebody is interested I can clean that up next weekend and throw it on github.

I find modern smartphones more and more unusable, both OS becoming more hostile towards the user, and applications widely moving to dropping logins in regular intervals. That has been happening for years already, so I slowly moved more and more stuff back to a computer.

By now I'm at a point where I no longer even backup my phone - there are a bunch of apps, but I can just install them and log in again on a different device as needed.

The final step to make it truly throwaway was me doing a custom matrix bridge for SMS earlier this year - I had voice routing setup for a while already. So now my old SIM cards are in a 4G modem at home, and the phone I carry around with me just has a data SIM. Huge quality of life improvement, as I can terminate as many numbers as I want there, and have access to both voice and SMS data from my computer as well.

That's not the problem for me - I carry a bunch of tokens with me anyway (all my banking stuff is on hardware tokens, for example). My problem is more: My browsers run in containers or VMs, intentionally without hardware access. Getting passkeys to work there would be quite a bit of effort.

Verbosity can be fine, but you'd want a simple enough text, with the verbosity separated. I still write emails with footnotes, and thanks to UTF-8 I now have all the numbers available.

Amusingly enough the advent of HTML-emails didn't produce any better formatted mails, despite the extra formatting options, than what you can do with a plain text email supported by a proper text editor.

Depends - if parallel decompression of any bzip3 archive is possible I'd consider it fair, if it requires special flags on archive creation I'd consider it unfair. I didn't see any description about that on that page.

pbzip2 only can do parallel decompression on archives created with pbzip2, otherwise it'll fall back to single thread. There nowadays seems to be lbzip2, though, which claims to be able to add SMP support for standard bzip2 archives.

I'll need to try that next time I'm working with large archives - I learned about the pbzip2 limitations the hard way last time I was shuffling around a few multi-10GB archives, and was trying to speed things up fully utilising my 32 core threadripper.

One of my customers now added a policy that junior developers may use AI assistance, but are expected to write code by hand. Only proven developers can use AI to generate code, and are then expected to understand the generated code, and take ownership.

I've worked at places very popular with candidates before, and was involved in hiring. For the first screening a CV/cover letter would get roughly one minute of our time. If it took longer than that to get an overview of what you claim your skills are you were out. Same if anything made reading it harder, which includes lots of spelling mistakes.

The main power advantage of the apple chips is when the system is mostly idle - under mid to high load power to watt has been comparable for a few years already (at least AMD and Apple, intel was way behind - but I guess they caught up recently). The main reason behind my M3 MBP back then wasn't so much power efficiency - but that I can get it with 96GB of RAM.

It's nice that I can go a full office day without charging - the previous x86 notebook couldn't, but a decent one from the M3 generation probably could as well. But also if I put proper load an that thing the Macbook battery is done in less than 2 hours.

There are various "air mouse" variants that properly work with MacOS as well. I have one with some media/navigation keys on the front, and a tiny keyboard on the back - kodi I can navigate just with the navigation keys, and if I want to do a bit more (but not get out the proper keyboard) I just flip it around, and can do that as well.

Funnily enough, I recently started on a series of demos and documentation to explain to my 10 year old daughter how LLMs work - in this case in the context of "don't use LLMs for looking stuff up if you figure out how to circumvent the school blocks yet again, or if you do, at least verify its output", but also figured it can be useful in general. Plus, if I get a 10 year old to understand that there's a slim chance I can get customers to understand that as well.

Same here - I was using one mail address only for linkedin, which wasn't listed on the page. One day I started receiving 3rd party spam on that address - which means linkedin sold the address, despite them claiming not to do that, or they had a data leak, which they also claimed they didn't have.

I guess that somewhat describes me - and guess what, that also transfers to "should we even throw AI at that specific problem, or are there other solutions?". Early curiousity in figuring out the limits of LLMs now is turning into revenue by customers with problems that didn't exist a few years ago at all - which currently is quite an exciting field to work in as a lot of things just don't have pre-established solutions yet.

It's a similar level of excitement as when we started doing devops stuff before devops even was a thing (which has been one of our main things for a very long time now).

Interesting - when Kimi K2.6 came out I switched over from Anthropic models, with at that time comparable to better results for me. I was using Anthropic via API, heavier months were roughly $400 worth of Anthropic tokens - I can get the same thing done via a $100 ollama subscription.

Same here, I was very confused for a bit.

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 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)

I'm not running a spam business. I've been operating my own mailservers (and related infrastructure) for more than 25 years now, without issues.

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.

> My business email system still does not work.

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).

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.

The last time (that I remember) people wanted to talk in a game, but could not teamspeak showed up.

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.