Hacker News Reader

Comment by TekMol | Hacker News Reader

    One of the things that's quite popular
    with people out in the world is being
    able to set up a Linux server and then
    leave it be for the better part of a
    decade without having to reinstall it
    or upgrade the distribution.

Why not the better part of the century?

I have never seen anybody who runs a business being happy about something new in the next version of the distro which powers their onlineshop or blog or whatever they run. But I constantly see how annoying it is for real world applications having to update the "outdated" stack every few years.

The stack is almost always already perfectly fine for what they are doing. All it needs is security updates. Which get less and less frequent as the system matures.

There should be an effort to offer 50 years of security updates for Debian 12. That would create more value for real businesses than all the work that will go into Debian 13, 14, 15 etc.

View on HN

Coincidentally, yesterday I was talking with a friend about which terminal we use, and how I went from the default gnome-terminal to the more capable konsole, moved by a silly bug: "Select all" doesn't select _all_ text, but only the text that is currently under view [1].

That's caused by a "temporary" fix in an underlying library, which seems was not so temporary, given that it got into the feature freeze and release of the Ubuntu LTS I use.

This means that for the whole support period of any distro that bundled the broken feature, users will find it and have to work around it, over and over.

Can you imagine if that was for a century?

I think distros should relax their policies and not only accept changes to fix security vulnerabilities (as is the case now), but also to fix promised features that shipped in a broken state. Otherwise, once some broken software ships, it stays broken for the whole lifecycle of the distro, which is bonkers.

[1]: In case anyone can provide further feedback, ideas for the author on how to fix it, or any help. https://gitlab.gnome.org/GNOME/vte/-/issues/2504

> Can you imagine if that was for a century?

If i had to keep a software stack for a century, i wouldn't pick GNOME. Generally you'd avoid any software project that has the faintest smell of "move fast and break things".

-- ex GNOME user

I wouldn't pick anything Linux in general if moving fast and breaking things is problematic.

I'm still looking, do you have recommendations?

The BSDs, OpenBSD in particular, are built for long-term. Any change is evaluated multiple times before being integrated. From the point of view of Linux they can seem outdated/old/lagging, but from their point of view they just work.

That's not true. Just because from the user perspective it seems not much is changing, there are tons of changes underneath. They don't guarantee user space stability like Linux does, so they can move faster (including upstreaming changes from ports). They only support the last 2 releases. Considering that there is a release every 6 months, that's 1 year of "LTS".

I love BSDs. I started my career with them. However, I don't think this long-term-sh view is actually conscious on their part. They simply have fewer people to work on new things so things lag a lot. It's more of a side effect.

This is a misconception. The "lag a lot" is very much debatable. For a lot of areas, specifically OpenBSD, is pushing the boundaries[1], not lagging behind. That's why they don't guarantee user space stability or even ABI stability inside the kernel, to move faster. Just check this recent case[2] about Linux is not enforcing IBT/BTI on its binaries and this being a known problem since 2001, while OpenBSD is solving this.

But again, people have different conceptions of lagging behind. Some people think not having a graphical installer is to "lag behind", when this is pretty much a design decision and not a problem of fewer people working on new things.

[1] https://www.openbsd.org/innovations.html [2] https://undeadly.org/cgi?action=article;sid=20230714121907

It's not about the installer (who even uses those anymore?), it's about features and power.

Linux has had a lot of work done to support complex features and scaling in a number of aspects, whereas OpenBSD has not. In fact, the insistence on security and keeping things conceptually simple, almost inevitably means they pass on some significant improvements. When you want pure power, OpenBSD is just not the best choice, for example; and the virtualization stack is very primitive.

OpenBSD rather notably and explicitly lacks any notion of "LTS" (all releases are unsupported after a year) and is perfectly happy to break things without much of a grace period (prime example being the switch to a 64-bit time_t for all platforms).

That said, the upgrade process (like most things) is thoroughly documented every release, and a given release will continue to chug along for years, so I can see where you're coming from there.

They guarantee even less stability than Linux, what are you talking about ?

Windows' legendary backward compatibility.

If we're talking Linux desktops, I've heard Xfce referred to as the Debian of DEs, and I have to agree.

Fairly slow incremental changes over time, and no real surprises on a new release.

It's incredibly boring, but in the right way.

Maybe the framing shouldn't be "move fast and break things" but more of a computing as pop culture roughly from Alan Kays saying.

Gnome has adapted to changes in computing form factors, supporting more mobile setups (touch and tablet) that emerged over the past 15 years while other DEs may mature around a Desktop/Laptop setup.

- mostly happy Gnome user

Every time I update to a new GNOME version, the Power menu shifts around. I keep having to relearn where things like the Lock Screen button is. I don't understand who keeps remaking these decisions or why...

My theory is that MS pays deep cover moles to infiltrate GNOME and sabotage it from within.

It's less sad than thinking that they do it to themselves.

Software should be reliable, but I'm not fond of LTS. As a developer, I'm fine with 3 years of support, security or otherwise.

The decade of (security) fixes (free or otherwise) smells like neglect. This is probably fine with 80s or even 90s software. But for internet connected devices I think it's bonkers to expect others to maintain and support the foundation of your software.

That is, assuming the software is functionally done, finished and no longer maintained. If whatever you meant to build, is still maintained and actively supported, it should not be too much to expect the OS to evolve with it. Upgrade to the latest platform every now and then.

Yes, migrations can be painful, but grow up: test thoroughly and get your ducks in a row. If that's too much to ask, you're simply lifting beyond your weight.

> assuming the software is functionally done, finished and no longer maintained

This ties in very well with a discussion that happened a couple days ago about whether the concept of "finished software" even exists:

https://news.ycombinator.com/item?id=36877363

> As a developer, I'm fine with 3 years of support, security or otherwise.

There's the problem: developers primarily think of themselves, expecting end users to be power users not unlike developers.

That doesn't hold. Developers can handle change & a rapid upgrade cycle. End users... not so much. Or not at all.

The only updates end users care for are risk-free, invisible, hassle-free (as in: automatic) updates that plug security holes, correct broken functionality, or minor feature updates that don't interfere with anything already there. For example drivers that support new hardware which uses existing system bus w/ existing software infrastructure.

Update can't fit into this frame? Then put it in next, feature-breaking release. Not in currently-stable, supported one.

Imho, Linux currently has a pressing need for community maintained distro with 10y+ LTS cycle. Or existing distro that offers 10y+ support on selected releases. Such distro could easily send RHEL into obscurity.

I'll add that even for developers or power users, very few are in that category for more than a couple of areas. There are some things I know about but that leaves 99 percent of my box where I'm relying on others.

What you're basically saying is you want developers to volunteer to give up their ability to advance their own careers writing features, and only fix security bugs in old junk that isn't entirely broken instead. You'd have better luck getting them to volunteer to be maids. If you want long-term community-driven support, then you'll stand a better chance getting it from developers focusing on making new things that are backwards compatible, rather than asking maintainers to keep old stuff alive forever. For example, Cosmopolitan Libc uses modern GCC11 to build binaries that support running on every distro all the way back to RHEL5, and I think that's the thing you actually want, except it's something you'll never see happen from distros, because they operate by a different set of incentives.

Sure, and that's what most do. But they don't actually derive any value from it - it's just busy work because others want the new features. If we could have 50 years of secure Windows XP or Linux 3.something, lots of software teams would be freed from periodic migrations to just building more features.

Windows XP was essentially an LTS as it did get 12 years of support.

However there were plenty of severe flaws that couldn't be fixed without some fundamental changes.

What people appear to want is all the problems fixed, but none of the hassle of actually having anything change to accommodate these fixes.

> but also to fix promised features that shipped in a broken state

fixing bugs sucks. That's why rewrite the whole thing.

Eventually you run into issues with your stack being incompatible with the rest of the world.

Your 20 year old debian won't be able to provide a TLS stack that is compatible with any modern browsers. And you could argue that this is still a "security backport", but backporting a new TLS version isn't like your garden-variety buffer overflow backport patch.

The TLS treadmill + certificate authority lists are antithetical to stability.

HTTP + merkle-tree based integrity checking + having the merkle root in DNS could be way more stable. Even the the SHA1 deprecation would barely affect this, as long as you're not using the hash tree to vouch for content provided by 3rd parties collision attacks don't matter.

Ok but once you have integrity, how do you open a private channel with the website ? You do need TLS, or something akin to that, somewhere. And like all crypto stacks, holes are found and change still needs to happen.

> How do you open a private channel with the website ?

I wasn't assuming you would. That's one of the things that have to go on the chopping block if long-term stability is the goal.

You can make computers even more stable by casting them in concrete and dropping them in the sea.

Do you genuinely think people want computers that cannot be used to read email, do online banking, buy things with, watch Netflix, and so on?

Forget the whole PKI infrastructure, the OpenSSL in your 20 year old Debian wouldn't have AES. You'd be using DES, 3DES or RC4.

What makes you think we'll still be using X25519 in 50 years? I'm pretty sure we'll have human level AGI by then and there's a decent chance that large orgs will have quantum computers too

I haven't mentioned X25519 anywhere.

What's the point of all that "merkle-tree based integrity checking + having the merkle root in DNS" without key exchange like X25519

The ancient server box doesn't need to do that. Publishing the hashes to DNS can happen somewhere else. And the clients would have to trust their local resolver if they don't want to do the validation themselves.

Heh the only thing I use HTTP for that's compatible with your model is browsing Wikipedia, but I've already got a local copy of Wikipedia on my phone so it's hard for me to imagine why anyone would want to use your model.

> trust their local resolver

No thanks. There was a time when software would trust devices on the LAN. I'm not going back to the dark ages

I don't think you understand the problem.

The protocol has the security bug. The protocol needs to be changed to fix the security bug. The old stuff stops being able to talk with new stuff.

That's the problem poster above was talking about.

Cert authorities are relatively much simpler problem to solve as it is just few files to update

Working in a Fortune 100 company, the upgrade cadence of our Linux plant is driven 100% by our info-sec organization. Left to their own devices, most of the developers would still happily be on RHEL 6. Or possibly 5. Or in some cases, Solaris 8.

Ditto for Java 8.

Seriously?

I'm a developer and if I would be left to my own devices I would upgrade to the newest beta software where possible and run Java 21 EA with enable-preview.

The only stopper is lazy people and infosec.

they call it bleeeeeding-edge for a reason ;)

Are you a developer for a Fortune 100?

The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS, because anything with shorter upgrade cycles takes too much time to get too many other people to buy in before a new version is released (and the old version is no longer supported).

There's a reason why you see a ton of stuff like VBA in the military, and it's not because VBA is usually the best tool for the job by any technical metric. It's because the people who chose it didn't need to align 100+ other stakeholders in order to pick a different tool; they were able to start implementing what they needed immediately.

> The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS

This is an archaic view and certainly not true for all Fortune 100 teams.

Plenty of them have digital platforms that bring in lots of money, and staying with legacy tech isn’t going to be good for business when faced with new, nimble challengers. Learning from the wider industry, FAANG included, is the smart thing to do.

> LTS

The key here is to save $$$ and stay secure. LTS is just deferred cost and pain.

For teams with good tests and CI for instance — if they’ve migrated to Java 11, upgrading the JVM is relatively easy after that.

Staying on LTS releases for ages is costly as you’re just deferring cost, as even Oracle JDK contributors have pointed out.

Ultimately it’s a cost/benefit equation, but often it’s economically sensible to bite the bullet and upgrade from Java 8 -> 11, and then upgrade more regularly.

Incidentally, Oracle’s recommendation is to perform Java LTS upgrades every 3 years. Sure you can defer further, but it’ll cost you. Oracle support ain’t free. But most well-run teams with tests and CI can move every 12-24 months. [1]

[1] https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i... , https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i...

> well-run teams with tests and CI

Well-run by what criteria? Pournelle's Iron Law of Bureaucracy points out that any large-enough organization (certainly F100's are large enough to count) will be run by people who take care of the organization, rather than people who pursue the organization's goals.

Most such teams are "well run" if they provide people with stability. No surprises, no forced upgrades, no rocking the boat, just an environment that let's people clock in and clock out with a feeling that they work in a supportive environment that appreciates them. Too many companies interpret CI as something that prevents them from delivering their work, or something that forces them to stop what they're doing to fix the main branch. In these companies, throwing something over the wall to someone else is a feature, not a bug. And if the person on the other end of that wall's only request is to still keep shipping Java 8? Well fine, so be it.

> Oracle’s recommendation is to perform Java LTS upgrades every 3 years.

I think now it is 2 years, because that's the span between LTS releases from Oracle.

I believe the 3 year period was recommended keeping the 2 year LTS release policy in mind, the idea was that teams don’t have to upgrade to the new LTS immediately, they can spend a year in testing before switching their production JVM.

because 51 years ago was the age of speaking to room sized computers with typewriters and punchcards.

Nothing about computing is anywhere close to settled enough for anyone to actually think about it on century-long time scales. Maybe we're at a point where we can talk about appliance style computers-single task, very limited I/O lasting that long.

It'd be nice, don't get me wrong, but OpenBSD should probably last a century before we start asking if we could let it run for another century.

This. The entire field of software is nowhere near mature or settled. My gut says that, in terms of software technology, the society today has progressed only %20 of the road and utilized the techology only that amount, compared to what it could be. Very few software I use I can call mature (i.e there's no meaningful room of improvement), they can be improved much more. The collective amount of work that has been put in to develop software by humanity so far not being enough means that the potential of the field is so great, maybe uncomparable to any other (e.g. think about carpentry).

>is anywhere close to settled enough

Some things are pretty well settled. 40 year old Unix software (K&R C,IPC/network sockets) would work on a modern linux with trivial or zero changes, and it doesn't look like it's gonna change soon. That was the age of not room sized, but half a fridge sized "minicomputers". Old software that people rely on doesn't necessarily need new features or improved capabilities that new standards and interfaces provide. Security, the constant change of the environment(network, protocols), and hardware and software changing in tandem are the only reasons people have to migrate or rewrite some pieces of well established software. Some of these changes in the environment feel as if these changes are for the changes' sake, to create programmer jobs.

> 40 year old Unix software (K&R C,IPC/network sockets) would work on a modern linux with trivial or zero changes, and it doesn't look like it's gonna change soon.

Is that true? Will K&R C (that is, C with old-style function declarations, not prototypes) compile on a modern compiler? I thought that gcc, for instance, no longer supported that declaration style. (And if you just have to add a flag to the makefile, I will agree that it's a trivial change.)

On the sockets, I agree with you.

>I thought that gcc, for instance, no longer supported that declaration style.

It's g++ that doesn't support this, gcc should.

> because 51 years ago was the age of speaking to room sized computers with typewriters and punchcards.

Code written in COBOL on mainframes 51 years ago still runs today.

> There should be an effort to offer 50 years of security updates for Debian 12.

That reminds me, SQLite is engineered to keep working until atleast 2050 (and beyond).

https://www.sqlite.org/lts.html

> which powers their onlineshop or blog or whatever they run

50 years of support doesn't make sense for these usecases, as the world keeps moving on around them. A blog that still looks like it's 2008 won't sell your business in 2023. A webshop from 2013 won't accept the popular payment methods of 2023 in large parts of the world. If these products will be updated anyway, at a certain point building on an old stack causes more work than it saves.

I maintain the infra for some over a decade old http applications.

They are not for selling or self-promotion using the newest shit. These sites are for getting a job done. And users actually enjoy it very much when the http form they use daily stays the same for over a decade.

The most requested feature: Put it back the way it was.

There's a big difference between "over a decade old" and "50 years" though. I'm not contending that there's a sizeable amount of 10+ year old applications that are still useful, but I'd wager that their number is inversely correlated with their age; and that 50 years is too long of a support term to be sensible. E.g. HTTP is less than 35 years old. And it's not just because the outside world is moving on, if you use a distro from 2000 for 50 years you'll run into problems in 2038 because it still uses 32-bit time_t.

A sizeable part of the web is not about selling stuff but providing a service, information, exchanges. Consumption and capitalism is incompatible with stability and longevity, so of course tending only to it will not work.

In 50 years, we'll still want a forum-like to discuss about the latest shenanigans of then-Elon Musk.

> . A blog that still looks like it's 2008 won't sell your business in 2023.

blogs can be personal, or something of historical interest

Just yesterday we had the 30th birthday of Windows NT and while I'm not suggesting that moving between versions would not have required effort, that it probably the platform you should have opted for if you want multi-decade stability for your application.

You would have need to adapt your code along the way but if you wrote a C++ application or service 30 years ago, there is a good chance of making that run on modern Windows as well.

I'm not a Windows, nor a C++ guy, but that seems like it would have been a pretty safe choice if you built an application back then with the expectation of having it running 50 years later.

Windows and Microsoft are worth respecting for ensuring ancient code will run so long as it follows either of two requirements: Code according to documented standards of the time, or become significant enough that Microsoft will write special patches for you (eg: SimCity).

Windows is a really interesting stark contrast to the rest of the computing world that prefers moving fast and breaking things, much to the chagrin of most users.

Not the rest of the industry, the mainframe and micro computer worlds are even more focused on that regard.

Probably many of Burroughs B5000 applications will still mostly run without any issues on a recent Unisys ClearPath MCP, just as one possible example.

For long term stuff, maybe mainframes or VMS is where it's at?

https://vmssoftware.com <-- seems to be the company doing VMS these days

> There should be an effort to offer 50 years of security updates for Debian 12. That would create more value for real businesses than...

Real businesses seem to prefer to spend time dealing with breakages than money to avoid them. It's not economically optimal.

Some buy their OS from IBM instead with mixed results but generally more focus on doing things businesses seem to want.

We know that something is going to break anyway because the world changes and it's impossible to cope with future unknown changes. So it's worth having some robustness but too much of it is not robustness anymore, it's money spent on wishful thinking.

> There should be an effort to offer 50 years of security updates for Debian 12. That would create more value for real businesses than all the work that will go into Debian 13, 14, 15 etc.

Well business is free to sponsor such effort, I'm sure Debian project will be happy with extra money. Just that cost will be steadily growing year by year because backporting new fixes to ancient code gets more and more expensive in general.

Also majority of security problems will not be "distro machine is running" but "app that is running on that distro". A container with app that can just run on modern distro is far more preferable method to support something for long time.

This is one of the costs of most free software. You either update to latest version, or you pay for support. Of course it is up to each project if they even want to offer such support.

You get the same cost with closed source software and it's as old as software is. Try getting support for older versions of windows. Or DOS. MS walked away from that at some point as well.

The benefit of open source software is that as long as the code is out there, somebody could take it upon themselves to fix things and share the results. You don't have that option with windows. And you only have that option with Dos because somebody created an OSS version of that; which is still being used by some to run stuff from last century. Windows is probably a bit more tricky.

An application that deployed 50 years ago and never updated would not run on 64-bit processors and would not be able to use the TCP/IP protocol suite. 50 years is longer than the average lifespan of any physical hardware component and it's not clear whatever drivers you had from back then would support any replacement part you could still find.

> An application that deployed 50 years ago and never updated would not run on 64-bit processors and would not be able to use the TCP/IP protocol suite.

You can run legacy 24-bit mainframe apps on modern 64-bit mainframes fine.

You can use legacy 3270 "green-screen" CICS mainframe apps over TCP/IP using CICS Transaction Gateway, with basically no changes to your CICS app.

It's just that mainframe customers pay a lot for this convenience and stability.

The problem is that shoving a full modern OS into an appliance means you'll need to deal with the many surfaces of attack on that OS somehow. Updating it from time to time might be better than getting hacked and recovery being difficult or impossible?

From the perspective of a distro, I am sure that fixing bugs in the current version takes way less work than building the next version of the distro.

So I suggest it is worth building the next version 5% slower and use the free 5% of resources to fix security issues in the last one.

And by this, extending security fixes for the last version to 50 years.

If we say "security updates only" for the kernel, does that mean we won't support new processors and graphics cards? When Intel and AMD say they have a patch that enables new processors and peripherals, do we decline it? Why?

People will expect the distribution to just work with newer hardware. Or maybe you're saying upgrade to debian 13 if/when you get new hardware but stay with 12 for fifty years on current hardware?

Intel and AMD should fire their marketing if a lot of people feel ok running the same hardware for fifty years, no?

>If we say "security updates only" for the kernel, does that mean we won't support new processors and graphics cards?

Why would you need support for new hardware if the use case is hardware that's going to sit for 50 years doing one thing and doing it well?

1. People are building a next version of the distro anyway. Even if you want stable, you don't want 80ies stable.

2. Is making a new release really more work? Most parts of a distro come from upstream, so their development too. I don't think most tools have stable branches, you're just expected to upgrade. Backporting security fixes is then actually more work than simply updating and solving breakage every now and then.

For any distro, “fixing bugs” that affect users will mean upstreaming patches to source in over 99% of cases. If you’re upstreaming patches, you’ll want to run the new version of upstream with those fixes included. Now you’re running new software and you’ve come full circle to a distro upgrade.

The alternative is to maintain your own patches, but that is not remotely sustainable for even the largest commercially supported distributions.

I sidestep all these concerns by running a rolling release distro on my workstation and deploying serverless code at work. I don’t miss the days of trying to get software downloaded off the web to work on a fixed debian or Ubuntu install.

Edit: nor having my production language runtime constrained by distro!

Backporting and maintaining patchsets is a huge portion of the work of distro maintainers, possibly more so than developing each new version. Why do you think Arch (which very much has a "least effort for maintainers" philosophy) avoids it as much as possible while happily keeping up with the bleeding edge?

Just judging by your karma you are not new to software development. So how do you imagine it? Your installation is a point in time, there are sometimes refactorings which need to be done, version of library which fixes the security hole depends on 3 other libraries in newer version than your current one and of it goes. It such a common pattern and it's really hard to avoid because you can't maintain 20 versions of product for people who installed at different points in time.

I wholeheartedly agree with the sentiment, but it sounds like a wishful thinking. If you maintain a simple library, do you backport a bugfix to every single previous released version? Because that's what would be required. From every single one of them.

> So I suggest it is worth building the next version 5% slower and use the free 5% of resources to fix security issues in the last one. And by this, extending security fixes for the last version to 50 years.

If we want to bring math into the conversation, then I don't think that would cut it, since supporting old releases is basically quadratic in terms of human effort. It's why distros ship LTS releases at a different cadence, which makes the problem less bad. But the costliness explodes if they do it for any longer than a few releases. It'd be fine if all the sticks in the mud could agree to use one specific old version, like RHEL5 and only RHEL5. But that's basically what projects like the BSDs are already doing, and they're awesome. I wish people who desire Linux to not change so rapidly were supporting the BSD folks instead, because they actually live up to preserving UNIX in a very authentic form.

> which powers their onlineshop or blog or whatever they run

Why are small businesses like that running their own servers? Pay for the most managed service you can - if it's an online shop, then something like Shopify; if it's a blog, then something like Ghost.

Running Internet servers isn't just about security updates, it's also DDoS protection, backups, and VM replacement when the underlying hardware fails, at the very least. Why would any business devote any headspace to that unless they're forced to in order to make a profit?

> Why are small businesses like that running their own servers?

Because the more managed a service, the less of a commodity it tends to be and leaves you at the mercy of the service provider wrt price changes, future availability, general quality.

I don't disagree that there are benefits to running your own servers, just that it's not worth the cost unless you need it.

When I buy a car, I may own the car, but I'm at the mercy of whoever for parts and service, which becomes more and more true over time as the OEMs shove more and more computerized parts into cars and stop publishing service manuals. Does that mean that I should build my own car from spare parts, so that I can be free of dependency on any one upstream manufacturer? Of course not - the costs of self-maintenance are too high. Now, if I run the New York Police Department vehicular fleet, and I'm responsible for thousands of cars that can't afford to be off the streets for too long, with the budget for a bunch of mechanic salaries and all the latest tools, then sure, maybe that's a serious argument. But not if I'm a small business and I have one server running a simple application.

Cars are commodities though. Your business won’t be disturbed when you change your car. There’s basically no difference from the point of view of your customers. But when you use a managed ecommerce service and you want to migrate to another provider, your old links will stop working, order histories will be lost etc.

And whether an online shop uses Shopify or WooCommerce also makes no difference from the point of view of that shop's customers ;)

> your old links will stop working

As long as your main website hostname is the same, you have 404s set up such that you land on a page that links you back to the main landing page... nobody really cares.

> order histories will be lost

For online shops, invoices anyway need to be exported to accounting software so that taxes can be filed correctly. I seriously doubt that a transition like this causes order history to truly be "lost".

Look, obviously switching managed providers is rarely a seamless experience... but neither is it impossible or even necessarily fundamentally difficult. Indeed, it's not unheard of for managed providers to help people make transitions by offering import options... https://www.shopify.com/migrate Shopify have guides to help with migrating, as does Ghost: https://ghost.org/docs/migration/

I can tell you that 9 times of 10 when I hit a 404 on an ecommerce website, I can’t find the product anymore through a website’s search function. Knowing this, sometimes I don’t even bother to search at this point anymore and go somewhere else. So there is at least one lost customer here in such a transition. And, observing how my less tech-literate relatives interact with websites, I suspect there are many more lost customers.

>> I don't disagree that there are benefits to running your own servers, just that it's not worth the cost unless you need it.

It depends on the size and funding of your organization.

For larger organizations with plenty of funding, it is easier and cheaper to just pay someone to run your servers for you. There will be monthly bills, but "it's operating costs, not capital costs" so no worries.

For smaller organizations with less funds, it is cheaper to buy a server, put a LTS OS on it, and self-manage it. If your IT budget is inconsistent, then monthly costs are too much and do not make sense.

50 years is simply not realistic in terms of technology lifecycle.

Reply on news.ycombinator.com