There's an episode of Friends a little bit like that: https://www.youtube.com/watch?v=9WYGdstEVJQ

Writing code on paper is frustrating to the point where, beyond small algorithms, it’s probably not an effective metric (to test performance on real-world tasks). I think even essays may not be as good a metric for writing quality when written vs typed, although the difference is probably smaller. Because e.g. being able to insert a line in the middle of the text, or find-and-replace, are much harder. Also, some people (like me) are especially bad at handwriting: my hand hurts after writing a couple paragraphs, and my handwriting is illegible to most people. While some people are especially bad at typing, they get accommodations like an alternative keyboard or dictation, whereas the accommodation for bad handwriting is…a computer (I was fortunate to get one for exams in the 2010s).

Universities make money not by teaching, but by testing and certifying. That's why AI is so disruptive in that space.

Granted, I’m 62, so I’m from the old world. I attended college, and taught a couple of college classes, before the AI revolution. There was definitely a connection between learning and evaluation for most students. In fact most students preferred more evaluation, not less, such as graded quizzes and homeworks rather than just one great big exam at the end. Among other things, the deadlines and feedback helped them budget their efforts. Also, the exercise of getting something right and hitting a deadline is not an overt purpose of education, but has a certain pragmatic value.

Again, showing my age, in the pre-AI era, the technology of choice was cheating. But there were vanishingly few students who used cheating to circumvent the evaluations while actually learning anything from their courses.

If teaching and certifying could be separated, they would be. In fact, it has happened to some extent for computer programming, hence the “coding interview” and so forth. But computer programming is also an unusual occupation in that it’s easy to be self taught, and questionable whether it needs to be taught at the college level.

There should be a class that teaches you how to use AI to get things done, especially judging on how many even on HN admit they aren’t good at it.

Until you factor in the salaries of the new employees you have to hire now, the cost of that hiring process, the compliance and security implications of operating servers on your premises, the ongoing maintenance of the software and operating systems, the new infrastructure to maintain, including but not limited to backup power supply and overall redundancy, the need to manage the lifecycle of the new hard- and software, the documentation for all of this… I could go on for a while.

It's not like these cloud solutions are just solving laziness.

Compliance and security testing does not go away just because you use cloud. The steps and questions will be different, but regulations like NIS and GDPR have extensive requirements regardless if you implement it yourself or buy it from an external supplier.

I would also not recommend to go with a single cloud solution with no backup solution and overall redundancy, unless a $5 voucher is good enough compensation for the service being down a whole day. The general recommendation after the latest waves of outages was for cloud users to use multiple cloud providers and multiple backup solution. It is just like how on-premise solutions need off-premise backups.

That’s a bit disingenuous. If I don’t operate a physical server rack, I also do not need to take care of physical access control, fire suppression policies, camera monitoring, key handling, and a wide range of other measures I would be otherwise obliged to take care of under GDPR. You can absolutely outsource classes of problems. What’s true is that that doesn’t lift the responsibility from you to check your cloud provider fulfils these obligations, but that’s very different from having to fulfil them yourself.

This would be part of the responsibility of the cloud managers, which need to be hired, paid and trained, on top of the cost of paying the cloud providers. There is no free lunch.

What can we definitive say about the difference be in salaries, training, and team size? Can we say anything specific about legal and operational perspective?

I get what you are saying, that responsibility is still yours for making the correct choices, and to know what the cloud providers are doing. In the real world though hardly anybody cares, even though we have threats like the CLOUD act in place. So, yeah, people should care but ultimately they often don't.

However in the same way, it doesn't then matter much if you are using the cloud or not. The work needing to copy the output of an AI to fill in the forms takes similar amount of time.

I'm not sure it will convince the "haters" nor they'll get it, but I'll keep it close to share with some people that are confused but open enough to understand the nuance.

For example micro services. You do not need infrastructure heavy software paradigms for large majority of use cases but it was just blindly accepted as new standart which we are now, again, moving away.

These used to be the skills of a generalist sysadmin for a small-site with on-prem services.

Those skills are no longer available on the market. Students in the local apprenticeship program have one class about hardware, and they don't even touch it, just talk about it.

In what way are they not a "cloud" provider? Because their managed services portfolio isn't as wide as AWS or Azure? What about Scaleway's services then?

Hetzner has an S3 compatible offering, a VPS offering and that's it. Their core business is renting physical servers. And I see lately they offer a load balancing service.

I'm talking about IBM mainframes.

Eventually, as the Internet (networking) and open source technologies (like Git and Linux) become more and more widespread, people realized they could build their services by combining products from different vendors (not to mention FOSS). I'm talking about the 1990s-2000s.

Now, after 20-30 years, we're thinking that the same company must provide the entire tech stack or lose relevancy as a provider.

To be clear, AWS and mainframes are pretty different from a technical standpoint, but I do wonder if we're kinda repeating the same cycle over and over. Asking the same company to provide everything and then build stuff with different products, to then find a new company which can provide everything and so on.

It's one thing to say that a lot of AWS/Azure/Google users take advantage of many managed services.

But saying something is not a cloud provider because they don't provide a specific SaaS is kinda weird, especially if you read the NIST definition of cloud computing or when you consider that not every AWS user is using more than a handful of services (does that make AWS a cloud provider only for more "advanced" users?).

Sure, smaller cloud providers don't usually have all those services, but this doesn't mean they are not cloud providers. They cannot attract users who are more familiar with specific managed services, but they can probably satisfy the needs of other users who are more than happy with a smaller feature set.

Also, limiting yourself to a smaller portion of AWS/Azure/GCP services can facilitate migrations to other cloud platforms (think AWS -> Azure or viceversa), because you're less tied to specific proprietary tooling.

I think for most business stakeholders it's not about the number of services but rather the coverage of business-critical needs. When you have access to Azure Entra, you know that you can cover 90%+ of your auth needs with that service. If you have access to AWS S3, you know that your various storage needs would be possible to cover with that. If a managed Postgres is available, you know that most of the IT systems you run would be able to take advantage of that. You look at Azure their IAM/audit/observability offerings and it's the same.

When you look at Hetzner as a business stakeholder, all you see are bare servers and and one object storage service that you are not sure of how battle-tested it is. And then you start thinking: "okay, I will need to run k8s or some other workload orchestration approach, my IT systems need Postgres/MySQL/SQL Server etc, I need auth, I need audit, I will need to build, operate, maintain all of that in-house". I am not saying that this is a wrong path for everyone, but Hetzner essentially leaves you no choice. And many business stakeholders who have been operating their own own-prem infra or colocated or rented IaaS plus a large dev team for decades and have since switched to one of the hyperscalers and reduced their dev/IT headcount - may not want to go back to the old model.

> limiting yourself to a smaller portion of AWS/Azure/GCP services can facilitate migrations to other cloud platforms.

Yes, which is why you insist (where possible/reasonable) on Postgres-compatible DBMS offerings, IdP solutions based on OIDC, observability on OpenTelemetry.

> Sure, smaller cloud providers don't usually have all those services, but this doesn't mean they are not cloud providers

Yes, it could mean that they are not cloud providers.

> but they can probably satisfy the needs of other users who are more than happy with a smaller feature set

Please see the linked article. This is essentially "users who are happy to build some of the furniture themselves".

I agree that there is a difference between "wood" and "furniture".

Although maybe a more apt comparison is IKEA vs another furniture store.

With IKEA you have a relatively basic "style". You'd be hard to pressed a 1800 style table, for example, but if you are a student or someone who just wants to live in a new place, it's a pretty solid store to go. However, they give you the pieces (not just basic wood, already pre-made pieces) and you have to put them together.

Other furnitures have a lot more choices in terms of styles and they allow you to just buy stuff without any DIY needed.

Different offerings in the same space (no one in IKEA is asking you to cut wood and make your own chair legs or whatever), both valid.

Furniture metaphores aside, what I'm saying is that there is a subset of users which is completely fine with those services, which are still provided in a self-service, pay-per-use way without the need to have admin rights over the entire platform. That's a cloud provider. A more limited one, sure, but it can still be a cloud provider.

And when it comes to business stakeholders, coverage is important, but so are other concerns, including the ability to move out when needed (which still requires some sensible technical choice, because if you go "all in" you're complicating your exit strategy), or even concerns like the ones mentioned in the OP.

Obviously, each company has its own risk aversion and its own decision making process, and so far market share heavily favors the Big Three even outside of the US, but this doesn't mean alternative options should be dismissed as "not cloud providers" just because they don't provide all those services.

But what if I have a secondary wifi network in my home that says "BigCorpSuperSecureWifi", wouldn't that work? What if that's the name of my phone's hotspot?

Yes and no. Code is not art, but software is art.

What is art, then? Not something that's "beautiful", as beauty is of course mostly subjective. Not even something that works well.

I think art is a thing that was made with great care.

It doesn't matter if some piece of software was vibe-coded in part or in full, if it was edited, tested, retried enough times for its maker to consider it "perfect". Trash is something that's done in a careless way.

If you truly love and use what you made, it's likely someone else will. If not, well... why would anyone?

1. To maintain it (to refactor or extend it).

2. To test it.

3. To debug it (to detect and fix flaws in it).

4. To learn (to get better by absorbing how the pros do it).

5. To verify and improve it (code review, pair programming).

6. To grade it (because a student wrote it).

7. To enjoy its beauty.

These are all I can think of right now, and they are ordered from most common to most rare case.

Personally, I have certainly read and re-read SICP code to enjoy its beauty (7), perhaps mixed in with a desire to learn (4) how to write equally beautiful code.

Tolstoy argued that art is essentially the transmission of feeling from the artist to the audience. He claimed that when an artist experiences an emotion and then, through their work, evokes that same emotion in others, that is art.

Often when you don't understand something you feel stupid; but sometimes the reason you don't understand is because somebody's trying to sell something to you, and it's that thing that's supid, or pointless, or a scam, or all three.

I only skimmed the OpenClaw post, but unless I completely misunderstood the README in their GitHub repo, to me the benefits are stupidly obvious, and I was actually planning to look at it closer over the weekend.

The value proposition I saw is: hooking up one or more LLMs via API (BYOK) to one or more popular chat apps, via self-hostable control plane. Plus some bells and whistles.

The part about chat integration is something that I wanted to have even before LLMs were a thing, because I hate modern communication apps with burning fashion. All popular IM apps in particular[0] are just user-hostile prisons whose vendors go out of their way to make interoperability and end-user automation impossible. There's too much of that, and for a decade or more I dreamed of centralizing all these independent networks for myself in a single app. I considered working on the problem a few times, but the barriers vendors put up were always too much for my patience.

So here I thought, maybe someone solved this problem. That alone would be valuable.

Having an LLM, especially BYOK, in your main IM app? That's a no-brainer to me too; I think it's a travesty this is not a default feature already. Especially these days, as a parent, I find a good chunk of my IM use involves manually copy-pasting messages and photos to some LLM to turn them into reminders and calendar invites. And that's one of many use cases I have for tight IM/LLM integration.

So here I thought maybe this project will be a quick and easy way to finally get a sane, end-user-programmable chat experience. Shame to see it might be vaporware and/or a scam.

--

[0] - Excepting Telegram, which has a host of other problems - but I'd be fine living with them; unfortunately, everyone I need to communicate with uses either WhatsApp or Facebook Messenger these days.

I had high hopes for the OpenClaw approach too, but the 'security sirens' you mentioned are real—self-hosting a control plane that bridges to WhatsApp/Messenger is a maintenance nightmare if you actually value your privacy.

I’ve been tracking a project called PAIO (Personal AI Operator) that seems to be attacking this from the exact angle you’re looking for. It’s essentially a privacy-first integration layer that uses a BYOK (Bring Your Own Key) architecture. The goal is to provide that 'one-click' connectivity to the walled gardens (WhatsApp, etc.) without you having to sacrifice your data or build the bridge yourself from scratch.

It’s the first tool I’ve seen that treats AI as a personal 'operator' rather than just another chatbot. Might be worth a look if you’re tired of the manual slog but don't want to risk the security 'fire sirens' of unproven scripts. Have you found any other bridges that actually handle the WhatsApp/FB Messenger side reliably, or is everything still just a 'beta' promise at this point?

My mother's mother would physically drop in unannounced to the people she wanted to talk to, and they'd have tea and chat a while to coordinate events. This was reciprocal. You are probably already wealthy, and your time can be spent however you like, consider not optimizing it anymore.

Genuinely, why are you using your limited time on this earth doing everything in your power to poison serendipity? If texting identical things bores you, you have free time and free will, make it actually personal so neither of you will be bored. Break the social taboo and call! Or share a calendar like a normal parent or neighborhood group.

If one of my friends with school age kids coordinated with me via clearly prompted text I would assume that we were not as close as I thought we were. That I'm a 'target for personal PR' rather than, you know, a person. It would diminish us both.

- Automating the boring part of creating calendar invites and such from messages people send, which half of the time are photos of some announcements. LLMs are already a godsend here.

- Getting up to speed quickly on what's going on in various kindergarten groups I'm in, whenever a bunch of parents who don't work on traditional schedule decide to have a spontaneous conference in late morning, and generate a 100 messages on the group by early afternoon.

Etc.

I'm not trying to avoid communicating with people - on the contrary, I want to eliminate the various inconveniences (more and less trivial) that usually prevent me from keeping up.

I can just imagine that many people won't be using stuff like this to automate copy-pasting etc. but literally let LLM's handle conversations for them (which will in turn be read by other LLMs).

"You free to chat?" "Always. I'm a bot." "…Same."

This post has been written by a human :)

Having a delegate to deal with communications is something people embrace when they can afford it. "My people will talk to your people" isn't an unusual concept. LLMs could be an alternative to human secretaries, that's affordable to the middle class and below.

Why in human males is the prostate such a troublesome thing? Because by the time the prostate becomes a problem, males have generally done any breeding they're going to do, so there is no advantage to natural selection to improving it further. Is it optimal? Definitely not.

Presumably it is (taking the wide view) probably a good thing that evolution doesn't find global optima or there would be far less ecological diversity.

It's not really that it doesn't matter, just that there are several different options to allow good enough fertility.

If sperm has to be stored/generated at a temperature lower than 36°C, then external testes are a solution to that, but a lower body temperature works as well. Developing enzymes that work good enough at a higher temperature also works (apparently what birds have done). And maybe just accepting a lower fitness of sperm cells works if the animal produces more of them.

Hippopotamuses have a low body temperature of about 35°C, so internal testes work for them.

A hippo doesn't care much about looks ;)

Also, Koren may have been a "celebrated researcher" at some point but he's now disgraced.