Hacker News Reader

Comment by userbinator | Hacker News Reader

I've becoming increasingly convinced that this "update culture" is really about encouraging rather than preventing forced obolescence. If they would just make it work right the first time, the way software used to be developed, maybe we wouldn't have this continual update cycle of fixing-and-breaking things every time, but then they wouldn't be able to sell you anything new. Instead, by conditioning the population to accept and even demand continual updates, companies maintain more control over their products and can change them however they want --- which of course can include making them less functional and more user-hostile.

It's the same reason why anything "smart" or cloud-dependent is best avoided. For example, all my white goods are several decades old and most of them don't even have any electronics.

No, we don't "need software updates forever", despite how much the corporatocracy tries its best to persuade you onto the treadmill.

View on HN

I know of almost no software that's ever finished. This is not some conspiracy. It's just a fact of life. Examples, image editors need to load new formats. Old computers didn't have cameras, now they do, many softwares would suck without support for them. New input devices come out (mice, touch screens), software needs an update to support them. Old old computers didn't have networking. Once networking exists plenty of software will be effectively obsolete if not updated to take advantagae. Old software was ASCII only, then the net connected us to the world and not all that old software needs to support full unicode. Old software didn't support useful rich copy and paste, new use cases appear (copy and paste text, images, audio clips, video, URL links, rich text, structured graphics). Old software that can't handle this is obsolete. Old software didn't handle multiple resolutions. Try running some non-HD-DPI aware Windows software on an HD-DPI screen. Good luck reading the text. Old software thought it could own the machine. OSes realized they needed to put the user in control. Now the software needs to be updated to ask for permission instead of just crash when it fails to access something.

Most software has to be updated, period.

> Examples, image editors need to load new formats

Alternatively, they could be designed to support plugins.

Someone still needs to write those, and you'd need to be a psychic to succeed in making an immutable API that can handle all possible future requirements.

E.g., up until a while back, 32-bit ARGB as exchange format would've been sufficient, but is now insufficient to handle 10 bit channels and/or stuff like HDR. What if we get a standard for 3D images? It gets worse if you want to handle animated images as well, whatever exchange format you specify will break once a decade at least. And god forbid someone tries DRM for images again…

Amiga did it. We can do it again. Besides, such an API is a slow-moving target, so still better than status quo.

Are we thinking about the same thing? Amiga did not have a perfectly future-proof API. Such an invention would be the holy grail of API design.

Some future proofing is better than none, right?

The status quo is the continued existence of IrfanView, which is probably as close as it gets to the ideal. Hasn't changed much since the 1990s, and looks like it, but supports about everything via plugins.

IrfanView is updated constantly though.

Yes, but the idea is that even if the original author dies, people can still keep using the last release of the application, but independently write new plugins to interpret new image formats that come out in the future.

Winamp has a similar property. If in 2030 FLAC is replaced by some fancy neural-network based lossless encoder, it can still read the files and play them without touching the core of the application, because all that's needed is a single plugin.

Well IrfanView is open source, so if the original author dies I would expect someone else to pick it up.

Your description might help with one specific area (compression algorithms) but there are numerous other areas where you can't just use a plugin.

This works, until something about the image violate your expectation. To use the image example, say you have an image editor that uses the common assumption that a pixel is a 3-byte item, with 255 possible values. Lots of stuff worked this way, its sort of a base assumption around which you have to build all your other stuff. Violating it requires you to like change sizes everywhere, which may mean performance of your fancy vectorized algorithm plummets somewhere.

Anyway, lots of stuff follows this 8-bit-per-channel api. Until you use RAW images or any number of higher color depth . Then you need 12 or 16 or 24 or 32 (or more) bits per channel.

At the point your text processing utility that was ASCII capably gets a plugin to support UTF-8 or UTF-16 you've made so much of the core modular that it no longer serves the benefit your proposed them for. Replacing core plugins of a program that provide the actual usefulness of it is no better than just upgrading the program.

Modularity can be useful, but there's always a core, and sometimes the core needs a change.

And that's before we even get into security issues. Sometimes entirely new classes of security problems are discovered, and if they weren't known at the time of writing, how were the authors supposed to guard against them? How much can we fault browsers for not guarding against spectre/meltdown when they were first written and released?

Thats a update to.

agreed. your software isn’t finished when it passes final qa. it isn’t finished when you deploy it to production. it isn’t finished when it has no known bugs. it’s only finished when your last user is dead.

And not just software, _everything_ is updated quite regularly because of technological advances and changing preferences: cars, clothes, beverages, laws, ...

Tools generally don't, I know they have added some antivibration stuff to hammers but an old hammer still works.

As far as socket sets and crow bars go I can't think of a new feature that happened in my life time.

For screw drivers the biggest change is companies keep inventing new heads for security by obscurity reasons, not better performance.

For screw drivers that may be the case now, or it may not be. Screws became popularized in the 1700s, but it wasn't until the early 1900s we see evidence of people trying different heads (square head), and it wasn't until the Phillips head in the 1930s that we adopted a standard. Even then it was a while before it entered consumer goods; I encountered a 1940 Fibber Mcgee and Molly episode (which is what led me to looking up the history of the screw) where Fibber went to buy a screwdriver, and literally asked for "a screwdriver with a black handle", no other qualifier, and the shop keep didn't ask for clarification.

Screw drivers, who need them when you have a perfectly good hammer, amirit?

Reminds me of a joke I made in passing by the pool this summer. All the ladies were drinking their hard seltzer cans, which is very trendy last couple years in US anyways. All of them using the Yeti/similar insulated can holders (coozies). My joke was something about how the entire beverage industry aligned on a new narrow and tall can size for seltzers just so they all had to buy new drink accessories

I agree with you that a lot of software needs open ended development, but I don't believe most of it does. I like the philosophy used in the development of the Gemini protocol: software should have a clearly defined scope, it should break not bend and it should eventually be done. I think the vast majority of software doesn't actually need continuous updates.

Look at the downsides, web browsers in particular are the biggest example of the downsides to this approach. They've become megalithic blobs of unmaintainable bloat. If they'd just stuck to delivering documents and let "web app" developers develop standalone clients we wouldn't be in the situation we are in with the web.

Some software can never be done, but most of it should be done.

If web browsers had stuck to just delivering documents, the Internet wouldn't have become what it is today. We'd end up with a bunch of AOL-like walled gardens, which benefits nobody.

Your "get off my lawn" ideal for web browsers would have never worked.

That's just ridiculous. It's not a dichotomy between news sites running megabytes of software on your machine and proprietary walled garden networks. There was a near decade long golden age where people used protocols and clients, browsers delivered documents and everyone used the same global network, and you're conveniently just ignoring that to make your invalid point.

Do you like what the web is today? I know almost nobody that does. "We wouldn't have the web we have today" isn't a selling point.

I have many issues with what the web is today, but removing all interactive features from web browsers would be a very negative change in my opinion.

Why?

Think about this scenario. You boot your machine, and it boots to a beautiful environment, with all the software you need to do the things you want to do. But most of it is useless because you have to start this other piece of software that's a blank rectangle, and in that software you must type the name of the application you want to run, and it will fetch the application over the network and render it. This blank rectangle must constantly be updated with new features in order to continue fetching software to run over the network properly. Whole teams need to be employed by non profits to keep this blank rectangle up to date. An operating system inside of an operating system. You don't think this is senseless?

Now imagine this scenario: you click a link to a video, the stream opens in VLC. You click subscribe, the link opens in thunderbird. If a company wants to have some interactive service they have to give you a client, they can't just externalize that workload on a browser maintainer. Isn't that the web we wanted?

That's not a problem on platforms like ChromeOS where web apps are treated like standard apps, from the user point of view they're indistinguishable.

A solution on other operating systems would be to use Electron, but I've seen many people on here also cry foul about that.

Electron is an even worse aspect of what I described, I thought about adding a line about it but decided to stay on point. You create an entire system designed for web apps, then you create basically a site specific browser to render just one web app because users need a dedicated client. It's another step in the senseless direction.

What is senseless about that? It's common for apps to bundle their dependencies, with Electron the bundle just happens to be a app platform for HTML, CSS and Javascript that we colloquially call a web browser. I'm not really a fan of Electron myself but some of the hatred it seems to get on this website is pretty irrational and unreasonable, in my opinion.

So electron is "great" in the sense that it is a workaround to this disaster that I have described above that is the web. You have to build a web app, but you want a client application, the resources to build both are a lot so you just wrap your web app in electron. It's a stopgap and it's an enabler. It is not good for the user. As much as I dislike complex web apps, I will sooner run one in a tab in my browser than download an electron app.

Did you know that electron apps basically bundle the entire chrome browser in with every application you use it to make? Have you ever tried running more than a couple of electron apps at once?

I'm fully aware of what Electron is, you don't have to explain it. But for these teams I don't see how Electron is practically any different from any other cross-platform framework like Java. It's the same purpose. The teams using it are going for a "write once run anywhere" approach. It's not a stopgap, they're never going to spend the money on building two or more applications if they don't have to. If you think that's not good for the user, you may want to try explaining to the users that having a native app is going to cost them several times as much. That's the situations I've been in, and the cheap and easy Javascript-based solution (Electron, React Native, Flutter, etc) usually seems to win.

That's only because web apps are the default.

You build a system, the web app is supposed to be a demo of what your system can do. But since the days of Facebook, YouTube, reddit, the web app is the product itself. This is why these companies always break third party apps that connect to their API.

So you're in one of a few situations. You have to build a web app because precedent, and you don't want cost overruns. Also use case comes second to business case. And we end up where we are. It's a mess for the user, and I don't think it's sustainable, which means this problem won't exist long term.

I think they break third party apps because it's a real pain to keep maintaining a bunch of incompatible old versions of an API forever.

Also your last paragraph doesn't follow to me because the whole reason these apps exist is because they are web apps. They wouldn't exist otherwise. That's the whole reason they are sustainable now in the first place. They're the default because it's the cheapest and easiest way to deliver a product for billions of users.

It is ridiculous and senseless, but not a popular view here since there are a lot of HN'ers whose salary depends on that rectangle being the OS instead of the user's actual OS. What's even more ridiculous is that we also now have software that you download and "install" onto the actual OS, but the software itself comes bundled with another copy of that rectangle plus all the machinery underneath it. Installing an OS on an OS for each application. We have gone mad.

OS vendors could have prevented this madness, but chose the path of deliberate incompatibility with each other, so we're left with the world as it is rather than as it should be.

I sometimes joke that I am going to build a VM that runs a docker container inside which there is only an electron wrapper around Facebook.com as an art project.

How about this scenario: I vote on a comment on HN, my email client opens up with an email pre-filled by the "mailto:" link, and then I have to send it to cast my vote. What a great experience!

I hate to throw the word "stramwan" around because it gets done plenty enough already, but you just made up the most ridiculous scenario you could and then attributed it to my point to refute it.

How about this: you try turning JS off and go to HN and realize it works just fine without the bloat.

I had no idea HN had a fallback like that, but it makes sense. I'll concede that point.

So you're fine with web pages that function as applications, you just want the user experience to be stuck in 1995.

I want the user experience to be stuck in 2095. I want the user experience to be better than it is now.

I'll give you an example of a web app that I like: github. It is built as a web app because it makes sense as a web app, it works really well, there's no cruft. It could be better if it were an API with user built clients, something git is designed for anyway, but it's not bad.

I would be fine theoretically with web apps, if there were some way to ensure actual web apps that need interactive functionality were the only ones that could use it. The situation we are in now every document is a web app, every piece of content you try to see online loads it's own application just to render. I have a video player on my machine, I shouldn't have to download and render a video player onto a one size fits all abstraction layer every time I want to play a video. I shouldn't have to download an entire rendering framework just to display a CNN article.

The right way to do the web is with APIs, client applications and protocols. If you're delivering a document, I should use a client applications to render documents, which is what browsers are supposed to be. If you're building an interactive service, give your community an API to build a client or build a client yourself. An instant messaging application should not be rendered in a document delivery program delivered over HTTP. If there's some use case that requires a standard, a standalone application that implements that standard is the way to go. Think XMPP and pidgin. How terrible would it have been if XMPP could only be used in a web app?

These design decisions are not about the user, they're deliberately designed badly because incentives are misaligned. Can't find what the user bought on the internet and sell that info to marketing companies if you just deliver content and let the user choose what software they execute.

The future is what I'm looking at, not the past. To deliver a truly useful web you have to determine it's shortcomings and rethink the architecture that led to those shortcomings. Saying "this was a bad design decision and look at where it led us" is not the same as saying "let's go back to 1995."

You could've omitted most of your description and just said, "If a company wants to have some interactive service they have to give you a client."

> Isn't that the web we wanted?

No, because you just described the world we're actually in, where everything from Starbucks to the laundromat exhorts you to install their app (going so far as to nag you about it e.g. when looking then up on a map and clicking through to their website). Despite your framing it in a positive light, we know this isn't the case.

Let me try the same reframing trick to make the Web sound like the best option:

If a company wants to offer you something, whether a physical item or informational content, then they have a way for you to fill out a form and get it. There's a way to deliver digital forms in a universally understood format, and you can use a software agent to deal with them for you and handle them in whatever way you think is best.

I don't think anyone is arguing against removal of things like HTML forms, which are arguably the only good interactivity that browsers have; and indeed, a lot of "web 2.0" sites worked very well that way, no JS required.

This includes all the web forums, blogs, and even sites like YouTube and Twitter which used to actually work without JS (and were much faster too).

"The Internet today" friggin' blows. Get off my lawn indeed, lol

> This is not some conspiracy. It's just a fact of life.

I disagree.

> Examples, image editors need to load new formats.

An image editor doesn't need to load new formats. An image editor just needs a library to convert to a format it can edit easier which almost always ends up being a bitmap of some sort.

That smells like a library. And that smells like not one library for _all_ image formats but instead one library for _each_ image format.

User wants to support the new copyright-compressed-image-video? Add a library. User doesn't want support for old-copyright-expired-and-is-now-public-domain-image-video? Don't update that library.

> Old computers didn't have cameras, now they do, many softwares would suck without support for them.

Nearly all softwares suck with support for them! Different features on the camera, different features in the software. What's needed is for software to just have a library to process an image stream and let the OS handle the camera...

> New input devices come out (mice, touch screens), software needs an update to support them.

What's new about mice that needs a software update? What's new about touch screens that needs a software update? These things haven't fundamentally changed in fifty years.

> Old old computers didn't have networking. Once networking exists plenty of software will be effectively obsolete if not updated to take advantagae

I disagree. Plenty of software shouldn't _need_ networking. That image editor? Yeah no it doesn't need networking. Your OS does though. Your OS should transparently provide any networking that you might need to edit an image on the network. Mount that network drive and your image editor should see it as if it's a local file. No update needed to the app.

> Old software was ASCII only, then the net connected us to the world and not all that old software needs to support full unicode.

Well yes but have you noticed how broken full unicode support often is? ASCII just worked.

> Old software didn't support useful rich copy and paste

And thank God for it. Rich copy and paste is a security nightmare and always ends up pasting junk and trash and vomit into something. I don't want rich copy and paste. How do I turn it off??!?!?!?!

> OSes realized they needed to put the user in control.

Hahahaha yeah... uhhh... no. Modern paid-for OSes (Windows, macOS, Android, et al) often take away more user control than they give. Dumb down the user interface so that they don't have to teach the user how things actually work and don't have to support that weird use case that the one power user used and most people wouldn't even understand. So take it away because it's just not worth the cost involved.

The problem with your suggestions is that the program would still need to be updated to support those new libraries. And new mice and touchscreens have gotten new hardware features, which require changes in the software to support them. Even something as simple as upping the resolution of the device can require an API break to widen the data type. Networking is also not something that can just be tacked on by the OS, if you want a decent experience then it needs to be built into the program.

Unicode is required if you want to have decent support for non-English text, for a really basic example you might want to try writing an ASCII document that includes multiple languages in it and see how it doesn't really work at all.

I'm not sure what you mean rich copy and paste is a security nightmare, programs that don't handle a complex data type will just ignore that type. A text editor will commonly just negotiate the type down to "text/plain" or equivalent.

> the program would still need to be updated to support those new libraries

Really? You think programs can't just load all of the libraries in a given directory?

> And new mice and touchscreens have gotten new hardware features

Yeah, like... more buttons and higher DPI

except they still boil down to the exact same interface. "Button X was pressed... button Y was released... moved +X+Y"

For real the biggest innovation I've seen in touchscreens is a sensor that tells how far away a stylus is or how hard it's been pressed. And that's really _not_ a big breaking change to require an update to every piece of software.

> Even something as simple as upping the resolution of the device can require an API break to widen the data type.

Yeah okay but that hasn't really happened any time recently. Or are you going to tell me that we should support a screen whose resolution is measured in _more than_ billions of pixels wide and tall? because I'm pretty sure your eye can't even _see_ that many pixels.

> Unicode is required if you want to have decent support for non-English text

Yes okay that's nice. That doesn't change the fact that unicode is broken in most apps.

> programs that don't handle a complex data type will just ignore that type

Programs that do handle that type are exactly what I want to stop. I absolutely never ever want to copy HTML from somewhere but there's often no way to disable it. Formatted text? Trash. Send me a file. Picture? Trash. Send me a file.

>Really? You think programs can't just load all of the libraries in a given directory?

They can't, a library implements a specific API.

>except they still boil down to the exact same interface. "Button X was pressed... button Y was released... moved +X+Y"

Well no, with multitouch the interface has changed from that to a series of events, and you have to handle gestures too. Some apps still don't support these. This isn't just for mobile devices, laptops all have these touchpads now too.

>Or are you going to tell me that we should support a screen whose resolution is measured in _more than_ billions of pixels wide and tall?

This would be for pointing devices, so yeah, with a high DPI mouse then you might want to make it 32-bit or 64-bit. This wouldn't be for billions of pixels but to subdivide into many fractions of a pixel. Example: the original Win32 API only uses 16 bits for mouse coordinates, so a new API is needed and the apps need to be changed if they want to take full advantage of that mouse.

>That doesn't change the fact that unicode is broken in most apps.

Please report those bugs to the developer, that should be fixed.

>Programs that do handle that type are exactly what I want to stop. I absolutely never ever want to copy HTML from somewhere but there's often no way to disable it. Formatted text? Trash. Send me a file. Picture? Trash. Send me a file.

I can't agree with this, I copy formatted text and pictures all the time. Your program should have the ability to remove the formatting.

> They can't, a library implements a specific API.

I'm sorry, what? That's the whole point of putting things into a library. Every library should be compatible with the common set of APIs. Any library that isn't compatible is defective.

> with multitouch the interface has changed from that to a series of events, and you have to handle gestures too. Some apps still don't support these. This isn't just for mobile devices, laptops all have these touchpads now too.

A series of events is exactly what a mouse has always reported.

Gestures? Apps don't need to support gestures. Even iOS often doesn't understand the gestures that it claims it supports. Why on earth do you think an app should support something that the OS itself can't support?

> subdivide into many fractions of a pixel

The whole point of a pixel is to be the smallest point that a program needs to understand.

> the original Win32 API only uses 16 bits for mouse coordinates

My screen resolution is 2560x1600. I have two monitors spanned, giving me 5120x1600. I can see someone having a couple dozen of them to get up beyond 65k width. But at that point the user is already reaching the limits of the hardware to render such a large number of pixels, the limits of physical space to even _have_ them.

Given that the Win32 API has been around for a few decades and I don't think we're actually reaching the hardware capabilities to need the upgrade... I'm going to simply say that you're being hyperbolic.

> Please report those bugs to the developer, that should be fixed.

No, fuck that. I have better things to do with my time than to be every developer's free QA.

If it was the case that you needed your image processing software to handle new formats, or your OS to handle a camera, you would go to the supplier and buy an upgrade.

If that case was any common, then upgrades would be hugely lucrative, and software distributors wouldn't be forcing people to move into a different model.

>> I know of almost no software that's ever finished.

All appliances including TVs until recently. 10s to 100s of modules on cars - until recently.

I knew someone who worked in over-the-air updates at <big car company> who said the software teams kept wanting to push updates after start of production. I said "no, updates are so you can avoid the cost of recalls, not so they can finish late" and we had complete agreement. Updates are potentially good by allowing critical fixes, but they are more commonly wanted by developers who can't wrap-up a solid release on schedule.

To be clear, suppliers to the auto companies have HARD deadlines - your customer has hundreds of suppliers delivering components for a particular model year SOP and they aren't going to disrupt everyone else because your software team is late. This leads to incremental (manageable) improvements rather than big new developments (which do happen but not tied to a particular program). Abusing OTA updates to allow more slop in this is probably going to lead to some issues.

> I know of almost no software that's ever finished.

I know of quite a lot of software that is "finished" as far as I'm concerned. Developers tend not to think it is, though.

A lot of Unix utilities have not been updated for years.

My thoughts on finishing software: https://gavinhoward.com/2019/11/finishing-software/ .

All software needs to be maintained much like food needs to be grown every year. The environment, need, situation, and security around the software is always changing so static software rots. Some rots quickly and some rots slowly but without maintenance it all rots.

I want a right to repair. Both for hardware and software. If the makers doesn't want to provide fixes forever, they should at least allow me to fix it if it breaks. I'm happy if they just provide the source code with a nice OSS licence.

Strictly speaking, for a pure right to repair, it doesn't even need to be OSS licensed.

Germany's Left Party (inspired name, I know…) is lobbying for that constellation e.g.: License can be restrictive, as long as users are given source access and permission to fix bugs themselves.

This is a very simplistic view as the source code alone may not be enough to build/fix most complex closed source application. You have IDEs that may be costly and expensive components that you cannot release the development builds, etc.

I find it funny that a Left Party would not promote/defend copyleft tooth and nail. Sounds more like a "pro-social Right" party :)

Political left and right have very very different meaning depending on where you live in the world :)

As a French person, anything which defends environment and customer rights (vs corporate interests) sounds lefty enough.

> Political left and right have very very different meaning depending on where you live in the world :)

I'm curious if you have resources on that topic. It was my understanding that the left/right division used to designate the French national assembly, where royalists and other reactionaries would sit on the "right" and various stripes of progressives on the "left", that this model was imported to other newly-founded so-called "democracies", and that the words took new meaning when communism (whether authoritarian marxism or libertarian anarchism) began spreading in the mid-19th century.

> anything which defends environment and customer rights (vs corporate interests) sounds lefty enough

As a french person myself, i don't agree with this interpretation. Not so long ago, a "fair capitalism" system was a selling point of the centrist movement, and was advertised by a considerable segment of the "droite sociale". The left was defined by promoting the abolition of the capitalist system with further sub-classifications: socialists promoted reforms as a means of achieving communism (which arguably fails every time), communists promoted dictatorship of the proletariat to build communism (which arguably fails every time, and produces results very similar to industrial capitalism), anarchists and libertarian communists promoted decentralization of power and workers/citizens self-organization to build communism (which arguably succeeded every time, but was shortly crushed by authoritarian reaction [0]).

In the 80s, the Socialist party rose to power and abandoned all socialist ideals, until it adopted market economy as official policy some time in the 90s if i remember well. Likewise, the Communist party seems to have abandoned most campaigning around expropriation, instead focusing on the much diluted/vague "workers/citizens rights" concepts.

Today, apart from the NPA (Nouveau Parti Anticapitaliste), i don't see any mainstream (>1% votes) leftist party in the public discourse. I don't see an abundance of further-left initiatives from the bottom-up (not political parties) though, in the forms of ZADs, self-organized workers coops and unions, squats, and other collectives for social struggles against racism, patriarchy, etc.. Of course they're not the ones the media would tell you about, or as the old 68 saying goes, "the revolution will not be televized" :-)

[0] 1917 revolution in Russia started as a libertarian communist movement organized around local "soviets", before Lenin Trostky and other power-hungry tyrants moved in and killed everyone (see "Constadt" or "Makhnovtchina"). Likewise, 1936 revolution in Spain was mostly led by anarchist discourse and practice, until USSR-backed communist party (which had considerably more weapons despite having much less popular support) massacred everyone.

Yes the definition depends on where you are and when too indeed :)

I think the mainstream opinion is that the PS, LFI and EELV are left parties. Everyone is free to define left and right as they prefer (or any other word actually) but it's easier to use the same meaning as most other people to communicate ;) I do agree though that this is a bit subjective, and for example whether LREM is left, center or right if probably a matter of your political opinion :)

One important thing I realized a while ago with something called the "political compass" [1] is that there is actually 2 main axis. Depending on when/where you are, left and right can be associated to different side of the axis.

[1] https://www.politicalcompass.org

> I think the mainstream opinion is that the PS, LFI and EELV are left parties.

I think that's what the propaganda apparatus is trying to build for a picture, yes. But compare their programs to those of the PS, PCF, and Greens (ancestors of those modern parties) from 40 years ago and you may have a few surprises in how the entire political apparatus has moved to the right over the years.

> LREM is left, center or right if probably a matter of your political opinion

LREM is definitely right-wing. They have regularly attacked the poor and the oppressed, while removing taxes on the rich . It could be considered a centrist policy ("all taxes should be equal") if it were accompanied by a traditional centrist "civil rights" program for political freedom and dismantling of monopolies (separation of investment/savings banks, break up of media from other industry interests, defending the right to protest, etc). Which is was not.

In the political compass, LREM/Macron policy is no doubt categorized in the top-right corner, in the authoritarian capitalist quadrant.

> Depending on when/where you are, left and right can be associated to different side of the axis.

Agreed, but there is a common understanding that left means redistribution of wealth while right means private property. Moreover, i would personally argue that the political compass is good for evaluating political speeches/opinions, but fails to grasp the complexity of facts in practice. For example, the USSR is usually painted as "authoritarian left", while in practice many critiques have pointed out that "There is no communism in Russia" [0].

[0] https://theanarchistlibrary.org/library/emma-goldman-there-i... (1935)

could be interesting if there was a sort of tax on throwaway technology. something around a few principles:

a) any manufacturer who ships an electronic device that fails to be operational for 10 years will pay a short term e-waste tax every year for every device that failed to remain operational.

b) any device that talks to the internet will not be considered operational unless either it receives regular security updates and supporting backend services -or- if the manufacturer chooses to close the line of business all firmware and backend code must be released under an oss license so that end users may pick up the slack if they so choose.

some additional guarantees around media licenses in the same vein would be pretty cool as well (although it seems that all the media companies are moving away from buying the right to consume on their service to just a regular fixed licensing fee for access to everything).

> I'm happy if they just provide the source code

I agree with you, but I figure it's worth mentioning that—OSS license aside—it's often possible to get source code from the original programmers many years after EOL.

I got my hands on the DEC VTStar source code a few years ago just by doing some digging on LinkedIn and messaging the right people.

You can’t create perfect software no matter how hard you try. Security updates especially need to be a forever thing, lest some major RCE comes along and is used on tech support scam sites to cause actual harm to the user.

Read OP's point again: You don't need security upgrades in many cases. Neither my dishwasher nor my fridge are, or should be, connected. I could imagine them having some kind of protocol for remote maintenance (showing power consumption, warning about damage), but that's it.

Software for utility devices should not be a selling point. It should just be there and do its job and maybe get an update every five years or so.

Why does my TV need updates nowadays? My car? Do I have to download updates for my clothes or my bed soon? How about the toilet?

These updates are indeed just a way to turn products you once used to buy into leased stuff. Every business loves to lease: There's much more profit in it and the customer has no say about how long they use a particular device. But as a customer I hate it.

Here's just one instance: I had an old kindle paperwhite. I loved that thing for piling all the stupid, cheap scifi on it that I would otherwise have bought as cheap paperback and that would then clutter my apartment. Literally two weeks after the device went out of the warranty, amazon decided to push an over-the-air upgrade. And it bricked the device. Now customer care was nice enough to send me a new one, but what if they didn't? Who is legally to blame? I would have to explain the concept of over-the-air upgrades and how software can sometimes destroy hardware to a judge and that judge would have to apply law from a hundred years ago to that situation. In a court case over maybe $100 - good luck with that.

> Why does my TV need updates nowadays? My car? Do I have to download updates for my clothes or my bed soon? How about the toilet?

Those things don't all need software to exist. But good luck buying a new TV or car these days that isn't 100% reliant on software to keep doing what you bought it to do. (And I'm sure there are clothes/furniture/toilet manufacturers looking very closely at John Deere's current business model to try and see if they can turn "buyers" into "recurring licensees" of their products.)

But I think that's missing the article's point. It talks about "some old gadgets" and "each booted up successfully" and "Two perfectly good pieces of electronic gear have become useless, simply for want of software updates." - it's clearly not talking about clothes or beds, probably not cars (although arguably they count), and probably is talking about modern TVs (many of which het thrown away when the ancient Android version they run can no longer update to new versions of that apps the TV came with).

I'm not sure whether "We should mandate that device manufacturers set aside a portion of the purchase price of a gadget to support ongoing software maintenance, forcing them to budget for a future they'd rather ignore." is the only/right answer. but the article certainly eraises an important question.

> "Two perfectly good pieces of electronic gear have become useless, simply for want of software updates"

isn't even true. The PSP is "useless" (in his book) for want of hardware updates and the same is probably true of the tablet to be honest.

(Personally, my PSP isn't useless; I even have a secondary wifi running 802.11b and WEP for it and other old hardware.)

  > How about the toilet?

So long as you flush the cache manually after each use, no, the toilet does not need software. Cache invalidation is classically a very difficult problem in software.

> Why does my TV need updates nowadays? My car?

Because they're connected to the internet or to internet-connected networks.

Anything that's connected to the internet needs to be receiving at least security updates. If it's not connected to the internet, it's your call whether the update is worthwhile

If you don't want to update it, don't connect it to the internet. Easy.

If you want to connect it to the internet, you need to accept the rules of society and one of those is don't leave vulnerable systems online where they can become part of a botnet and mess things up for the rest of us.

I could not care less about your data, but we've seen with hacked security cameras and such that insecure crap left on the internet causes problems for everyone, not just their owners.

This is a really reasonable counter point, but maybe we need to live in a world where that becomes a problem for some third party (or if right-to-repair really takes off).

You buy a device, the manufacturer finds out there are flaws -- if it's under their promised timeframe (there's an incentive for them to offer ) they offer you updates. If you're outside of their time frame, you hope for a third party or you determine if you must upgrade. As the number of devices outside support range grows a market is made.

This isn't a new problem -- software can copy off of the robust recipe that automobiles have left, hopefully making fewer mistakes this time and letting a little less corruption in.

Sure you can, make liability a thing like in other industries, and make introducing development practices that make RCE avoidable a legal requirement.

Most RCE come to to happen, because the industry largely considers security best practices an afterthought and keeps pushing for the use of unsafe languages.

Don't complain about death tools, when people keep driving without helmets and seat belts.

Extremely few software updates I'm presented with seem to be focused on security. Including those specifically saying they are. It's all adding/removing/tweaking features.

We need to encourage a culture of maintenance releases at companies where we work. As a user, I want the software I use to look and behave the same, and have the same feature set forever, with only under-the-hood security updates and bug fixes. I don't want the constant UX churn, constant feature cram/bloat, constant regressions and increased CPU/memory usage.

But with most companies' development process, you're stuck having to take the bad with the good. Their release tree is one long trunk, and to get the security updates you must also take the latest PM's pet features and the disruptive results of their latest UX designer's art project. Companies need to learn how to branch at major versions and offer minor maintenance releases on each of those branches, while offering the next version.

EDIT: If 'grep' was developed like most commercial/startup software, its command-line switches would all change with every release, it would require an internet connection, it would be able to grep through Tweets, and it would phone home to its developer with logs of every file you grep through.

I guess the underlying issue is that maintenance is afforded as few resources as necessary and is hence not somewhere most want to end up. So there is a lot of incentive to keep products from ending up in maintenance mode even if they really should. I find it quite sad. So many offerings seem to be made worse when people can't leave well enough alone.

This hits on one of the ways that I think the software industry has gone very wrong -- no longer separating security updates from feature updates.

I shouldn't have to accept whatever feature/UI madness developers have cooked up in order to have security issues fixed.

That isn't just a problem of misaligned incentives, it's more fundamental than that. It's also a problem with how software "construction" tools work at a very basic level. Look around at open source projects, they don't have this perverse incentive, and which of them ship security updates separate from the feature updates?

Nobody does because it causes a combinatorial explosion in code branches, and in testing. This isn't just a problem with the higher level convenience tools like compilers and package managers, its a problem with the actual source code as formulated as it is today. We'd need an entirely different way of writing code in order to do that without a massive increase in programmer/testing hours. Personally I don't think it will ever realistically happen, but I'd love to be proven wrong.

As a user, it doesn't matter to me why software updates have degraded like this. All that matters is that they have.

As a developer, I don't really understand. I've been working on large, complex software that targets multiple operating systems for years, and we don't have any such issues.

It sounds to me like a lot of companies are using development methodologies that are a bit broken...

I've long thought that the reason for this is rather different -- the industry really wants to go to continuous-release models (which I don't think is a good thing, but that's a separate issue), which make security-only releases a bit nonsensical.

I made a blog post under the humorous title of "Never update anything" which does sound a bit like what you're suggesting: https://blog.kronis.dev/articles/never-update-anything

It's probably a bit chaotic, but some of the arguments that i made were that "updates" is too broad a term to be meaningful, since you might be interested in security updates without any other sorts of breaking changes being forced upon you:

  Types of updates are the problem
  
  The problem here is that we never differentiate between the types of updates properly:
   - major leaps in the development of the software which add new features
   - security updates that don't change any actual functionality apart from the security fix
   - bug fixes that should not alter any functionality in significant ways
   - small backwards compatible feature updates that are essentially opt in

Essentially, you might want stable and secure software and not much more, since if it was enough for you at a certain point in time, then it might be the same way in 10 years, instead of needing new features that break your logic numerous times over that period.

But perhaps the current situation that we're in is simply a reflection of the current industry and market conditions, where companies try to have their products remain competitive.

You can't sell stable software (or hardware) that has a new feature once every 10 years, when there are products out there that release new stuff monthly - at least when it comes to the layperson, otherwise we wouldn't have enterprises like Google or Facebook make significant UI/UX changes, since none of those make sense from a purely engineering oriented point of view.

Of course, that's just my interpretation after applying Occam's razor - for some reason we don't hear much about extremely stable products as success stories.

some functionality might only be possible by being insecure, thus a security update may have to remove functionality.

In that case, we're probably (hopefully) talking about air gapped environments, like medical devices that aren't networked or internal corporate networks with very particular host access rules.

In those cases, you might truly want no updates of any kind, with which i agree - updates should always be compatible with the "opt out" approach, or even do "opt in" (like Debian has an unattended upgrades package, for example: https://wiki.debian.org/UnattendedUpgrades).

That said, due to the world that we live in, it's risky to forgo any sorts of security updates, especially in the context of networked devices and systems!

I mean I was thinking more about the thing were WMF files used to allow you to run scripts inside the files which created security issues https://www.computerworld.com/article/2826084/what-you-need-... - lots of functionality that is enabled to make things easier for applications to do stuff is fundamentally insecure, so pushing a solution to fix the security issue will sometimes lead to remove functionality from the application that the user has to accept.

So the premise that we could remove security issues but not touch functionality seems utopian.

Nope. A security update that removes a feature should add a checkbox to a control panel that's pre-checked to disable functionality. The system administrator is prominently notified that they must take a look at whether this breaks their use case, and make the right call following risk assessment.

Extremely stable products do exist. The Z80 wouldn't still be made (after almost 50 years) unless software needs that CPU, and at this point that has to mean stable software, right?

But in this case, the software works as it did, provided that you give it the surroundings for which it was made. The change needed isn't one of the four classes you point out, but rather a fifth:

- support for new networking technology

For the N95, a new web stack, presumably including xhr, webrtc and the other goodies so many apps use nowadays. For the Playstation, the ability to connect to new WLANs.

I suspect that new hardware would be needed in both of these cases. Running webrtc on a CPU from 2007 sounds dubious, and didn't 802.11foo change something extremely low-level wrt. hardware?

I was asked about 5 years ago to help to keep an application alive that was running on NT, it was doing an extremely important function and could not be replaced easily. Nobody knew how long it had been running and the developers obv had long gone

I suggested we immediatly isolate all the servers, clients and the network. Create snapshots of the hards disks (on isolated disks) - and try and virtualise the images so they're not tied in to the hardware.

as far as I know that thing will keep going forever to the point the tech will be (or already is?) so old not many people could hack it

> as far as I know that thing will keep going forever to the point the tech will be (or already is?) so old not many people could hack it

You're underestimating young people's ability to grasp and enjoy obsolete technologies. I am personally fascinated with DOS and Palm OS despite definitely not being around to witness their heydays. Give me a few years and the binaries/manuals people had back in the day, and I will hack it one way or another.

you're right, I personally think the more people who have this way of thinking the better. but the number of people who can be motivated to do this stuff along with the time required is a much smaller group

I've done my fair share of reverse engineering machinecode in the past - I do see it as a puzzle to be solved

You're overestimating anyone's ability to spend years trying to hack a single target with documentation that likely no longer exists when there are likely both easier and more profitable targets out there.

The documentation and software is still extant if you know where to look, including in archives created specifically for this purpose. If I didn't have either of those, then obviously I couldn't get very far.

> If they would just make it work right the first time, the way software used to be developed

Back in my day kids were respectful of their elders, politicians didnt lie and the sun shone gloriously every day.

Exactly. Remember Windows95?

There always has been stuff that was made to work and last, and there always has been tons more stuff that was a bug ridden "worse is better" kind of deal with great marketing.

I remember windows 3.1.

Back in those days, the way they shipped - mmm it was a thing of beauty. I had to reinstall it every 2-3 months it was that good.

OTOH, if it wasn't that good we would be using something else, good and better that win3.1 and the history would erase Windows.

The big lie started when they conned people into calling the next version, 3.11 three point one one. Its pretty obvious now with the benefit of hindsight that is an eleven and big tech had to hide the fact they were transitioning from completed code to incomplete code in the unreleased versions 2 through 10.

> It's the same reason why anything "smart" or cloud-dependent is best avoided. For example, all my white goods are several decades old and most of them don't even have any electronics.

I would definitely welcome regulations dis-incentivizing IoT crapware like connected fridges and toasters and whatnot. However, for devices that are intended to run software (general-purpose computers) shouldn't it be a requirement that all data sheets and source code be released under a copyleft license?

Can't we have the best of both worlds?

I agree that better technology shouldn't need continuous updates, but I do think there are two more likely drivers than planned obsolescence, differing from early technology.

Firstly, security. Older devices weren't connected to the entire world with bad actors attempting to exploit anything they can. Until people start writing software that have zero security exploits, anything connected to the internet needs an update path.

Secondly, most apps in use today have a server component. Maintaining a perfect backwards compatible server for all clients ever released is a very tall order.

Also, I think it's a strong indictment of current OS technology that updates are in question at all. If everything was as modular as it really should be, you'd have the core components of the kernal, the drivers for the hardware bits, (both of which really should be secure and not rely on servers) and then everything else should be in the user's complete control, to update or not as they please.

People could just not connect some devices to the wider world. Make them offline, or support airgapped usage patterns, or support a 1:1 connection only with a management interface (like a KVM), or support fully online use but with as simple a protocol as you can to reduce surface area.

>If they would just make it work right the first time, the way software used to be developed

Was this ever true? Was there really some golden age where everything worked or were we just blissfully ignorant to the problems?

Generally most of my electronics that contain a microcontroller but no internet have been bug free.

I think part of this comes from the much smaller testing surface - my old vacuum cleaner has one button for power and one dial for suction power, so it's quite simple to write a bug-free implementation. Same for my dishwasher, laundry machine, etc. They generally come with a very limited number of inputs, and a microcontroller that runs through a state machine based on the inputs.

I don't know how old you are but things pre-internet electronics just worked, because there it was assumed that there was probably connection. Before everything was internet connected. Yes everything did just work until component failure.

* Games consoles and games were plug and play. Until the PS3 (late 2000s), none of the game consoles required any sort of updates. Yes there was hardware revisions but what you bought in the box was what you got.

* Most computers before the PC was dominate in the UK, just switched on and you operated them.

* Mobile phones didn't require updates, the only thing I need to do once was restart the phone because the sim needed to update a setting because I wasn't receiving SMS. These old nokia phones still work btw and my newer smart phones many don't work or can't be updated now.

* Almost all my media was on VHS and/or Cassette. As long as the player worked, my media would play.

I tend to do a lot of retro-gaming / retro computing now and all this stuff that is pre-internet and doesn't assume an internet connection just works (even on modern operating systems) without much interference.

There was of course bad products, but they didn't require an internet connection either so it was just a bad product that you replaced with something better if you cared to.

Playstation 2 games were generally bug free. Same goes for Nintendo cartridges.

Probably not bug free, but the bugs that remained were subtle enough to be difficult to notice, or they happened in rare circumstances, or they actually worked to the benefit of the game.

Video games have never been produced in an environment where bugs can be completely stamped out.

Those games had a ton of bugs. Look into speed run tech. Super Mario World even has an arbitrary code execution bug you can trigger from controller input.

https://www.youtube.com/watch?v=v_KsonqcMv0

This is completely not true, all those old games had tons of bugs.

I think we don't think of them as having a ton of bugs for a few reasons; one, we didn't have the social media forums to post bugs and read about them, so unless you personally encountered a bug, you wouldn't know about it. Since most bugs only trigger under rare circumstances, most people aren't going to know about them. Secondly, since we knew there were never going to be updates, we didn't think about things not working as being 'bugs' that can be fixed... they became just part of the game.

> Since most bugs only trigger under rare circumstances

That's true of old games (when updates couldn't be delivered), but certainly not any newer AAA game at release that I can think of.

Sort of. Some things were - and still are a lot better. I've been in companies where all software is assumed to spend 6 months in test after it is finished - the customers would then do 3 months of extensive lab testing and only if it passed would they buy it so perfection was needed.

>"update culture" is really about encouraging forced obolescence >If they would just make it work right the first time

What makes contant updates unavoidable is the ever-connectedness of the current world. If you miss out on security updates, then your sensitive data is at higher risk to be harvested, or the device can be joined into a botnet. This is why we can't return to the old world of doing software.

Also it's not like software was written to be perfect, like, ever. Product versioning is not new to the current era.

Security updates alone pretty much refute your entire premise. Not to mention that if you don't have software updates all your options for repair are costly and leave you without a device for a while. Scaled to everyone that's mountains of electronic and time wasted. The problem is not software updates.

Reply on news.ycombinator.com