Hacker News Reader

Comment by hsn915 | Hacker News Reader

People think if a project on github hasn't been updated since 3 months then it has been abandoned!!

Like, why don't we just let projects be "done"? Things don't need to be maintained and updated for eternity.

In my mind, the best software engineering is where you solve a problem once and your solution just works and needs no configuration or maintenance or updates.

This of course has a very low chance of happening if your system has to exist as a part of "ecosystem" where you expect/assume the presence of some external service that can change its API on a whim (or just disappear).

Yes, to a certain degree it's impossible to design software that does not exist as a part of an ecosystem, which is why I put it in quotes.

Some APIs are stable and are guaranteed to continue to exist for a very long time: CPU instruction sets, networking protocols (IP/UDP/TCP), operating systems (AFAICT: Linux (the kernel) works hard to not break user programs, and Windows is kind of known for bending over backwards to maintain compatibility with old programs), file systems, etc.

What I'm advocating for here requires that your program be compiled into a native executable binary file, and it must embed all its library dependencies (aka static linking).

View on HN

Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic ideal of the thing, you're going to need to update.

Protocols change, programming languages change, human languages change, boarders change, definitions of time change, laws change, sensors change, and on and on.

It's like asking why a person can't be just done learning so they can live their life. Well, they can, but pretty soon the world is inaccessible to them. They can't use a computer or a phone because they stopped learning in 1995 and they're utterly dependant on others to do things for them.

But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time. Fixing security bugs and supporting new emojis, fine. We have to do stuff like that. But everything else is just as frozen as can be. It would be useful for super long term software. If we have buildings still around from 100 years ago we should be able to build for 100 years from now without a team around for constant maintenance. Though I do not think it can ever be maintenance free.

At the risk of this being interpreted as trolling; don't we have this, for crucial OS interfaces at least? Linux is famous for "we do not break user space" (yes, I know it's not 100% true, but it's closer than anything else I've seen), and afaik the posix standards are pretty stable too.

The C language also has a stable ABI, which is basically the ffi for most languages, and most static libraries that were developed decades ago can link just fine.

In my mind, the problem is caused by at least two things:

- Languages that are not compiled to machine code have no incentive to have a stable API or ABI. This has the effect that code reuse now necessitates replicating the state of the machine it was developed on (Which might be using a different language version, runtime, etc).

- Programming culture has progressed to a "get it done quickly, just grab a library" culture. This is not to say you should develop everything in-house, but on a spectrum, I have the hunch that this easy accumulation of dependencies induces a culture that does not vet the stability of the dependencies. Once one of your dependencies is unstable, the project on which it depends cannot be stable.

> At the risk of this being interpreted as trolling; don't we have this, for crucial OS interfaces at least?

For crucial OS interfaces, yes. For the ecosystem of libraries and packages, no. But ultimately Linux is more than just crucial interfaces. The ecosystem of applications and libraries that we need to get anything really useful done does constantly change, and it would be nice if there was a OS + programming language + culture for "forever apps" that are designed to work for centuries without a material risk of an auto-update breaking anything.

Sort of how Rust is designed around safety, that's what would be nice. I know it wouldn't be perfect, for the reasons I listed above, but for the areas where we are at least trying to have things work for good I think it would materially help.

> The ecosystem of applications and libraries that we need to get anything really useful done

I'd argue that you can get lot of useful things done with plain POSIX/C

> a OS + programming language + culture for "forever apps"

Isn't POSIX + C exactly that? Sure, not many people stick within those bounds, but those who do tend to care a lot about not breaking stuff.

yeah, except POSIX and C also aren't set in stone, also evolve, deprecate stuff, remove features, just like everything else.

Yeah, C and Java have had non-breaking changes for years. Java code from 1995 can still compile and execute in Java 17 (2021).

I imagine COBOL is similarly stable but I have no experience there.

> I imagine COBOL is similarly stable but I have no experience there.

I haven't programmed in COBOL, but it is quite stable. One of the really nice things in COBOL is the "Environment Division", which has a Configuration Section, which provides information about the system on which the program is written and executed. It consists of two paragraphs − – Source computer: System used to compile the program. – Object computer: System used to execute the program.

Another remarkably stable language is Ada, I have used it to compile non-trivial programs from 30+ years ago, on a different architecture than it was originally written for (granted, without system dependency) using a modern compiler without anything more than (1) renaming identifiers which had been made keywords, (2) splitting files due to GNAT's implementation limitation regarding compilation-units.

Ya I was thinking java is closer to the mark as well, even coming from someone who has never programmed in java... But I have long thought that it would be nice if there was some sort of universal standard for pseudo code that could be compiled into other languages.

Meanwhile Python: "Yeah if you could rewrite your entire codebase every few years because of some changes nobody fuckin asked for, yeah that would be great. Oh and by the way, we're dropping support for non-latest versions of the language lmao."

Except they have, just not to the same extent as some other languages.

K&R C won't compile in modern compilers, not is allowed as per ISO C2X upcoming standard.

gets was removed.

And if you are using optional Annexes, they might not even exist in ISO C compliant compilers.

Similarly, that Java code will die if it uses internals made private in Java 9, inherits from JDBC and has methods with names that were later added to more recent versions, uses deprecated methods that were finally removed around Java 10 time,...

But Java 8 -> 16 doesn’t work without changes.

Completely depends. You can write Java in 2021 that works with both old and new Java, especially if you don’t use any dependencies.

Sure and you can write code that is valid C and valid shell- but there have been major breaking changes to Java (iirc Minecraft barely started working with Java 16 this year).

You have to distinguish Java the language and the JVM: Class files generated by any (?) version of the Java compiler before the JVM version you’re using will usually work on the newer JVM. Java 9+ started removing classes, breaking API compatibility: but, generally, there are additional jars/command-line options that can be used to restore the older behavior.

Minecraft, in particular, has always worked fine with Java 9+, ime: if you know the flags to apply (and delete the jar that checks the Java version), it more or less just worked. I’ve been running it for a year+ on new JVMs so I could use the Shenandoah GC and take advantage of more of the 128GB RAM in my desktop.

Not any longer, as per Java 17, people have had enough time to port their code, and those switches now "do nothing".

This is the last step before they get fully removed.

None of those changes are required for use, and more importantly, nothing has been DROPPED to make old code obsolete.

This isn’t exactly true: javax.xml.bind-related ClassNotFound errors are a fairly common problem when running old Java applications on new JVMs. Thankfully, the solution is just to include the relevant jar that implements the classes that have been removed.

Depends, some libraries work, some need special parameters, some don't work at all

Good luck running a binary from 2005 on a modern Linux distro.

GitHub was built to host source code though.

> a programming language and OS that does its best to not change

you've heard of this thing called Windows?

Yes. Windows is extremely backwards compatible. This could be, ironically, one of the reasons some people don't like it too much. See Raymond Chen's The Old New Thing [1] for some technical details.

[1] http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...

The latest Windows update won't install for me. It pops up an error saying "Uninstall this app now. It is not compatible with Windows 10."

Yes, it says "now," in command form. And the app, VirtualBox, works just fine in Windows 10.

Doesn't seem very backwards compatible these days.

If the program manifest doesn't advertize compatibility with the current version of the system, its window will be scaled.

Since when do windows break most programs every few months? Having to write a patch every few years when Microsoft releases a new OS is pretty low maintenance. And most of the time windows is backwards compatible nowadays, so usually you don't even need to do that.

Most 10 year old games still runs on modern windows even without patches etc.

> The C language also has a stable ABI, which is basically the ffi for most languages,

C is honestly terrible to target/use as FFI, doing so precludes doing things correctly, or more advanced things like... say arrays that "know their own length" or numeric-types that are range-constrained.

>say arrays that "know their own length"

There's a fair amount of C code that does just that and does it for a long time.

>or numeric-types that are range-constrained.

Those don't need astral and can be passed through C ABI just fine.

>>say arrays that "know their own length"

> There's a fair amount of C code that does just that and does it for a long time.

No, there isn't.

There can't be because of how arrays in C degenerate into pointers/addresses; see Walter Bright's "C's Biggest Mistake" -- here: https://www.digitalmars.com/articles/C-biggest-mistake.html

>> or numeric-types that are range-constrained.

> Those don't need astral and can be passed through C ABI just fine.

No, they can't.

If you're passing a "Positive" through C's ABI you lose the fact that the value can be neither negative, nor zero. (Unless you mean "passed through" as in, "not mangled", but this is setting the bar so low as to be laughable.)

No building stands for 100 years without maintenance. 100 years ago heating and light by coal or gas were still common, so every single old building has had upgrades to electricity (or first gas, then electric). The roof leaked, the wood rotted, a bunch of people died in a fire and now all buildings in a similar style need to add a fire escape...

There are hundreds of churches in Europe who have stood for centuries without the "maintenance" you are talking about. You are talking about upgrades, not maintenance. Adding gas and electricity are modern (< 150 years ago) things, as are earthquake codes, fire escapes, etc. I'm not suggesting people go live in cathedrals, but there's a huge hole in your reasoning.

Every old church I've ever been in has had some kind of donation drive on the notice board asking for help replacing missing tiles, rotting roof beams etc.

I don't know if the British were just exceptionally bad church builders and contemporary European churches are doing just fine but I would hazard a guess that no, they also require spectacularly large amounts of maintenance to keep the weather out too.

True, but this is preventing a kind of decay that software is, by its digital nature, immune to. Information doesn't weather or rot. There's no software equivalent to "missing tiles" or "rotting roof beams".

“Link rot” and “bit rot” are terms that have entered our common vocabulary. I think information gets weathered down by contact with humans, who are an incredible source of entropy.

Then consider NASA Voyager. It's been floating around the galaxy for 44 years. If all goes well, its onboard computer won't run out of power until October 10, 2166.

Yes, this kind of upkeep is definitely required. Replacing little things as they break and keeping an eye out for issues. Old things require this upkeep, which is a different thing from rebuilding, replacing, or upgrading. But the goal of upkeep is to keep the thing in good shape, and usually without any visible change at all, rather than transforming it into something different (assumedly better, but not really). Upkeep is preservation, conservation. We've somehow forgotten how to do that for the vast majority of things.

Hell, here in Sweden there lots of old houses that are in dire shape BECAUSE they received “maintenance” to keep them modern, resulting in problems with mold and insects.

The parallel to breaking working code while updating it to follows modern standards isn’t too far fetched.

Both here and in code, upgrading to keep up with progress of technology is good. Upgrading to keep up with progress of business - aka. ways to provide less value for more money - is bad. Old technology was often immune to value engineering simply because people didn't knew how to cut corners with it.

Ime, “upgrading to keep up with the progress of technology” is often code for “I haven’t learned the paradigm behind this legacy code base, but I know it’s bad”. I’ve spent so much time arguing against fad-driven development where people insist on rewriting year-old redux apps to use hooks because “hooks are the future”. At this point, I more or less reflexively oppose anyone who argues for a new technology just because it’s new.

>"Protocols change, programming languages change, human languages change, boarders change, definitions of time change, laws change, sensors change, and on and on."

I have 17 years old Windows desktop product that I've long abandoned. But it is exactly this: single exe with everything compiled in. It uses DirectX 9 and Directshow. It still runs fine without any tweaking. It even compiles fine from source code. So from a practical standpoint it is maintenance free.

> But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change.

Believe it or not this is a core design goal of the Urbit ecosystem. The core bytecode should be simple (and stable) enough that some future archaeologist can implement an interpreter in a weekend and run programs. They take it so far that their version numbers run _backwards_, with the idea that once they reach version 0 nothing will ever change again: https://urbit.org/blog/toward-a-frozen-operating-system

> But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time. Fixing security bugs and supporting new emojis, fine. We have to do stuff like that. But everything else is just as frozen as can be. It would be useful for super long term software. If we have buildings still around from 100 years ago we should be able to build for 100 years from now without a team around for constant maintenance. Though I do not think it can ever be maintenance free.

you can fire up QBasic on dosbox just fine

The last update to MS-Dos was over twenty years ago. I'm longing for something more than mere backwards compatibility.

So you want "there should at least be a programming language and OS that does its best to not change", and you also want updates for it?

FreeDOS is regularly updated

> Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic ideal of the thing, you're going to need to update.

You only need to update dependencies that interact with things that change autonomously.

For the types of programs I write, that describes very few, sometimes none, of my dependencies.

Continuous updating of dependencies is valuable in some circumstances. Not all.

> there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time

A passable implementation of Lorie's UVC concept[1] is sitting right in our lap, it's just hardly ever put to use in this way, and it's considered by some not to be very sexy—or rather, it's popular to dump on it for various reasons. But you're probably using it right now to read this comment, and the reason is that its availability and reliability is a foregone conclusion by every stakeholder in this conversation—whether that be me, you, or our hosts involving Y Combinator &co. And with respect to the article, it's a foregone conclusion that it will also be involved in the tech tree of the example projects given. Jeff even mentions its longevity explicitly—in a comparison to Python, where Python is considered the worse of the two. How about just not depending on Python at all?

If you click through to Jeff's "makerss.py" script and look at the kinds of machinations that it does, consider whether this stuff could instead be taken care of directly in a "README.html" in the repo root. No implicit[2] assumptions about what software is installed on the machine in question—since it's using the UVC after all—and none of the Python 2/Python 3 fuss. (It'd have to forego the symlinking that makerss.py does near the end (currently line 1717 and 1719), but that should arguably already be handled elsewhere, anyway.)

1. https://news.ycombinator.com/item?id=11512892

2. https://news.ycombinator.com/item?id=22991033

> consider whether this stuff could instead be taken care of directly in a "README.html" in the repo root

I'm not sure what you mean?

From <https://news.ycombinator.com/item?id=28407936>:

> If folks were really committed to improving the developer experience, then instead of what we do now [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html

If this is still unclear, please let me know. (Please also let me know if it is clear. I'm very interested getting this explanation "right", so it's easy to understand.)

Software would be incredibly "low upkeep" to last as long as HTTP. You don't have to use a new programming language just because it exists. Time zone info is a data file managed by the OS and has no business being baked into specific programs. Translations are likewise data files and should be modular so that you can add or replace them without invalidating the program. Sensors change much slower than software; the oldest and crustiest operating system image you'll ever meet is the one coupled to a multi-million-dollar sensor in a lab or a hospital.

We perhaps need a LongNow Smartphone.

> Like, why don't we just let projects be "done"? Things don't need to be maintained and updated for eternity.

This is generally why I opt for "single-file" libraries that do one simple task well. The smaller the library, the more likely it is "done". For example, do I want some insanely complex image library that handles every file format under the sun, or do I just want some basic one that allows me to output a simple JPEG?

I often find myself referring to "single_file_libs" repository: https://github.com/nothings/single_file_libs

Looking at the open issues, it doesn't appear to be actively maintained but it's still an incredibly good resource for "completed" projects.

> Looking at the open issues, it doesn't appear to be actively maintained

I'm not sure if this is intentionally ironic or not, but it does seem like if your small libraries aren't getting updated regularly because they are done, you at least want the meta library (in this case the single file libs repository) to be updated regularly with new small libraries.

> [..] you at least want the meta library (in this case the single file libs repository) to be updated regularly with new small libraries.

It's the meta-library collection repository I was talking about, not the single-file libraries.

Funny you chose to say jpeg, because jpegxl is just on it's way to getting big. If you're dealing with a lot of images the savings are probably big enough to warrant an update.

There really is nothing that can be considered completely stable.

>People think if a project on github hasn't been updated since 3 months then it has been abandoned!!

People are too quick to assume that all Github repos are meant for public consumption. Can only speak for myself really but most of what I've pushed there was designed with only me in mind. If others find it useful that's nice but don't expect me to accept pull requests.

Have you considered a "no maintenance intended" badge on those repos?

https://unmaintained.tech/

This is not at all close to what I'm advocating for.

The page says:

> Open Source is rewarding- but it can also be exhausting.

> The linking project’s code is provided as-is, and is not actively maintained.

Basically the attitude here is "I'm tired! Leave me alone!".

The attitude I'm advocating for is "This is feature complete! We only update this project for bug fixes or security patches."

I am suddenly reminded of this earlier discussion:

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

This is precisely why I have a private git repo.

It would be sad if people could only chose between "Public and I commit to maintain this for all of you" and "Private and it's just for me". What's wrong with "This is public but it's still for me, you're welcome to use it if you want to but don't expect anything from me".

This is what open source is really about for me.

I agree with this so much that I strongly feel that it should actually be an repos option as it clearly lays out the responsibilities of all parties should they choose to use the code.

It's almost like we should have some sort of text we can all copy paste in our repositories to indicate this sort of thing.

Mine will always contain: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ...

And then maybe we should add something about that people can actually use it if they want to: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files ...

Should try to start this is an effort for real!

I usually just put some text to the extent of "this code was written by myself for myself and I'm really not looking for pull requests" in the README.

If you get tired of repeating yourself, do what I wrote about in https://news.ycombinator.com/item?id=28663996 and just use the MIT license. It has all of this outlined explicitly already.

I see what you mean, but in my experience most people will at least skim the README while they ignore the license entirely. So, by putting it in a clearly visible position in the README (say just below the repo title) I catch a few extra people and prevent them from sending in issues/PRs in the first place.

It's also not like it's a lot of work, a 30 seconds one-time investment in my time is less time than I spend on most HN comments.

Totally agree, open source is about sharing code, designs, solutions to problems, etc. not running, maintaining, and and promoting a project.

Some open source efforts are geared towards running, maintaining, and promoting a project.

Adoptopenjdk comes to mind. https://adoptopenjdk.net/

This seems like a volunteer project _around_ open source rather than open source. It may seem pedantic but it feels useful (to me at least) to separate the act of sharing and collaboratively improving code from the projects and politics that often get built around that.

This is one reason I really like Common Lisp and Clojure: both communities have developed a mindset that allows libraries to be done and, as a result, I notice a lot less churn than in other languages.

I also like them for the same reason. The languages themselves evolve slowly (Clojure) or not at all (Common Lisp). A library that emphasizes simplicity and does One Thing Well can be stable and continue to be useful indefinitely. There are network effects too -- if my library uses stable libraries and is built on a stable language, it need not change at all.

On the other hand, there are the big libraries that, for convenience, pull one or two small things from several others -- their surface area becomes so large they are practically guaranteed to generate more work in terms of security updates, dependency conflicts, and the like. I experience this at times developing in Clojure, whose hosted nature means issues can emerge from the Java ecosystem, which is obviously enormous and dynamic.

We recently had a defect at work relating to a conflict between transitive (Java) dependencies from a third party library used to serialize exceptions prior to transmission to their service, and another tool used only for generating "literate"-style code documentation. While not a production defect, it cost us some time and could have been avoided (both by us and the libraries' authors) by more hard-headed evaluation of the tradeoffs involved in introducing certain dependencies in the first place.

I would use Occam's razor with this idea and posit that it is much more like that its a lack of overall mindshare with functional programming than with the nature of language abstractions.

Don't tell me that Lisp ever achieved cool-kid status that a thousand different libs wouldn't pop up basically overnight.

The thing about allowing libraries being done is a bit more nuanced than not having lots of different libraries doing the same thing. There are lots of competing libraries even now and existing libraries do get surpassed in popularity. But they keep working and don't become unusable or problematic as often as in other cultures.

I don’t think this is entirely right: there are plenty of languages with similarish mindshare that don’t have this: just building a Haskell project, for example, can be a nightmare if they hasn’t been maintained. Scala also has this issue, despite having a similar marketshare as Clojure.

If the premise is that you limit your dependencies have low maintenance code, you'd probably not include many (any?) of said thousands of libs. Also it isn't about the number of libs, but how often they change.

But what doesn't change?

Network protocols? No, HTTP/3 is here.

OS? Kernel, sure, but everything else no. E.g. most Linux OSs recently changed their entire init system.

CPU architectures? ARM was irrelevant a few years ago. Faster CPU instructions are arriving every year. You say, "okay, well just recompile." Which brings us to....

Build tools? These are a nightmare to make stable in the best of circumstances.

It's all fiction. Code rot is real.

http is not a networking protocol in the sense I meant. It's an application level protocol. Although you can still write a server that implements only http1.1 and it should still work fine.

A lot of the things that you describe as changing don't really need to change.

Operating Systems? Windows XP was probably the best windows, and it's from nearly 20 years ago. Looking at Windows 10, what exactly does it bring to the table? It's a much worse experience overall.

Compilers don't need to change either.

How often are changes in your web app directly warranted by a new init system or HTTP protocol? Does your code directly depend on what init system is running it, or somehow become unusable if it doesn't understand the latest HTTP version?

If yes, just what the hell are you making?

Yes to the first question. My SystemD-based web server doesn't work in systemd. (Well the web server itself probably works, but the packaging needs to change.)

As for the second, code can still work and yet be obsolete.

Typo: "my system v web server..."

I have a side project that I haven't updated in years. I haven't needed to because Windows is fantastic at backwards compatibility.

Also the website automatically handles payments and sending license keys.

The only work I do is when PayPal integration breaks because they make some minor change on their end.

Unfortunately, Windows 11 removed the IDeskBand interface I rely on so I might actually have to do some work.

Curious, do you limit yourself to the C win32 api on Windows? I hear that low of level never really changes, and you can do all the stuff the newer windows gui libs can do.

The answer is in Lehman's laws of software evolution. Most systems "must be continually adapted or [they] becomes progressively less satisfactory".

The argument is simple. The world changes all the time and most software interacts with the world. Therefore, software needs maintenance in order to keep up with the changing world.

Yeah, but the rate of that change makes all the difference.

Consider biological systems: they're constantly evolving, constantly in flux - and yet, all living things we can see with unarmed eyes are fixed in the scope of a human lifespan. Most of those don't show meaningful changes withing lifetime of a human society. Cooking recipes of our great grandparents are still valid today, because fruits and vegetables and meat didn't change that much[0] over the last century. Wood still works the same way it did 1000 years ago.

Being able to change much faster is good - as long as the changes tend to lead in useful direction. Software seems to be changing way faster than it's needed, because it's changing for the wrong reasons - instead of improving the value it provides, it's usually about one-upping competition, or forcing recurring payments, or forcing competitors to waste money (e.g. by introducing incompatibility on purpose). Software industry resembles a rain forest, in terms of both diversity and frequency of senseless murder (er, "survival of the fittest"). But as humans, we've dominated this planet by being smarter than that, by being more efficient than natural evolution.

[0] - Despite being optimized directly by our industrial processes.

Software close to the user have this need for adaption.

However, my experience is that the building blocks for making even large software systems are increasingly more stable and Debian GNU/Linux is a prime example of this.

That's a nice, succinct way to put it. Software that doesn't interact with the world can be finished. Software that does ends when the world does.

I suppose then that a benefit of pure functional programming is that you can statically analyze whether a given piece of software is plausibly "done" or simply unmaintained, depending on whether and to what extent it uses monads.

> People think if a project on github hasn't been updated since 3 months then it has been abandoned!!

This a heuristic that generally works. Most projects that don't have recent commits really are abandoned. And when you open a project on github, one of the first things you see is when every file was last updated. Maybe github should offer other heuristics, or of it already has them, display them more prominently.

I don't necessarily disagree, but this is the cultural problem I'm sort of pointing the finger at.

Packaging your software into a container-image accomplishes almost exactly the same thing, without the need to be using a stack that can create standalone static binaries.

I would point out, though, that even when you can just continue to use a single pinned version of a Docker image forever (because the program itself is stable, or is part of a stable system that only uses the program in precise ways), people still value regular releases, and see non-upgrading images as “rotting” — because they can contain vendored deps, and those deps can have security vulnerabilities discovered in them over time.

Docker is especially bad for this. A jar file that runs today will probably run fine in 10 years on future Java. The container might, but it almost certainly has a huge number of security vulnerabilities, and maybe no one uses AMD64 and ARM anymore.

I haven't worked a lot with Docker or similar containerization tools, but my impression is they require you to have an internet connection to download stuff.

At least with Docker, when you write or download a docker file for the first time, it's just a description of stuff that needs to be downloaded and maybe commands that need to be executed.

This kind of thing is qualitatively much worse than a statically linked executable binary in terms.

> a stack that can create standalone static binaries.

Yea, a language that has the notion of a compiler is a MUST if you actually care about this kind of thing.

they're specifically talking about the resulting image built using whatever dockerfile you had. they can be exported to a file or pushed to repos to be reused elsewhere.

It'd be useful to have a way to tell visitors this project still works without having to push commits to refresh the last updates timestamp.

I do this in the README. Include a "state of the project" section.

Seeing no updates in 3 months is one thing. Seeing no updates on a project that describes itself as a work in progress is another thing.

Isn't this why we have CI/CD and scheduled pipelines?

Seems like a waste if it's just doing the same work all over again just to update a timestamp. A waste that someone has to pay for.

You are right; it's because the "modern" CI/CD is ill-designed, thanks in part to being "generalized" to handle text and "generalized" tools like C compilers and makefiles... instead of, you know, working in the actual problem-space.

See this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26....

> Isn't this why we have CI/CD and scheduled pipelines?

I mean, kind-of. One of the problems with CI/CD though is that they're poorly designed for the job they do; see this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26....

The TL;DR here is that by structuring your code and storing it in a database structured hierarchically you can solve CI/CD in a MUCH nicer manner: your root node's history becoming a history of the project in a compilable state.

I evaluate the liveness of a github project based on the responses to questions (latest post, time to reply). Not by when the last change was made.

"Art is never finished only abandoned"

"Klingon software is not released, it escapes"

Anything that connects to or supports something that connects to the internet eventually gets used as some part of vulnerability, and hence needs to be updated.

But, I agree with your sentiment. Endless feature bloat is not necessary for vast majority of software. The expectation that every software must remain updated forever is just not sustainable.

I completely agree with you, but your last point is exactly why recent updates are a proxy for ‘well-maintained.’ Software is so complex that it _has_ to have dependencies, and even if you vendor them / compile to an executable, that doesn’t account for upstream bug or security fixes.

1) If you buy into this concept, you would naturally limit your dependencies to the bare minimum.

2) Static linking does a good job of protecting against when upstream introduces new bugs or security holes.

Static linking also protects you from security patches.

I like writing low-dependency software, but what that means is that I pick a distribution to build on and use their packages. If a library is not packaged, it has to be really good for me to depend on it.

Sure, it might break once in a blue moon depending on how stable the distribution you use is, and you'll need to refresh your stuff every 4-9 years when a new version of the base OS is released and the old one goes EOL, but most of the time the result will be extremely low-maintenance.

> limit your dependencies to the bare minimum

I get this desire, but likely it guarantees more work for yourself and probably more undiscovered bugs, because with only one set of eyes, to invert Linus’ law, many bugs may lurk deep.

Have you actually tried to reduce dependencies?

I mean, are you speaking from experience, or just theorizing?

Here's something to keep in mind: when you depend on a huge library that has 40 features, it's likely your program only needs 5 of them.

So, while the huge library benefits from "many eyes", your particular program would benefit much more from not depending on a library with a lot more features than you need.

Also I don't know if you've seen how open source works, but chances are the number of people actively looking at the source code for these libraries to uncover bugs or security holes is very small to non-existent.

You don’t need to be condescending. We all know that using dependencies saves time, and it’s not possible to build any practical software without them. An OS is a dependency. A GUI library is a dependency. A database is a dependency.

Sure, you can limit them, but you can’t live without them. That’s not theorizing, that’s the whole industry’s collective wisdom.

What part of my comment was condescending?

> That’s not theorizing, that’s the whole industry’s collective wisdom.

There's no wisdom there. The industry is too young to have any meaningful wisdom to speak of. It's mostly fashion driven.

> An OS is a dependency. A GUI library is a dependency. A database is a dependency.

Well, I did make a distinction in my original post about stable dependencies, and I included the OS as a stable dependency.

I also never said you should have "zero" dependencies. My point is about minimizing dependencies as much as you can.

This was the condescending part:

> Have you actually tried to reduce dependencies?

> I mean, are you speaking from experience, or just theorizing?

Why is it condescending?

I asked this question because your comment does not jive with my experience. So before countering your point I wanted to confirm whether you had some experience that was opposite to mine or not.

Where is the condescension? In my mind I'm being polite and not making assumptions.

If I wanted to be condescending I would tell you that you have no idea what you're talking about.

First, you weren’t condescending to me, you were condescending to someone else. Second, saying “you have no idea what you’re talking about” is aggressive, not condescending.

“Have you actually tried X?” is condescending, because it places you in a position of superiority, framed as an “honest” question. If in your mind that is a polite and honest conversation, your mind is clouded, as me an other people have now let you know.

TBH, opening your post with "Have you tried X?" _does_ read like a very short step from "you have no idea what you're talking about", whether you meant it like that or not.

But you can choose dependencies which has been stable for years. Like OS calls and libraries with a long stable track record. Those are good enough to be productive.

If you're sincerely interested in a thoughtful discussion, you should dial back the smug tone in your posts.

Wow, so you ask me for credentials, accuse me of theorizing, and then by the time you finally get around to addressing my point, you hypocritically theorize with “it’s likely” and “chances are”! Well done, I’m not wasting my time on you just like I wouldn’t by rolling my own logging library for the umpteenth time. Good luck out there.

I didn't ask you for credentials nor accuse you of anything. It was an honest question.

I disagree. How many times does software use 3rd party dependencies when the standard library would have sufficed with a bit of extra effort? With python, golang, and others the standard library should cover most cases

Go is pretty darn good at avoiding breaking changes to the standard library. But, um, do you remember Python 3? You just proved my point with that one, in your own words.

> What I'm advocating for here requires that your program be compiled into a native executable binary file, and it must embed all its library dependencies (aka static linking).

the super example of this is justine's project

https://github.com/jart/cosmopolitan

it's pr fucking cool

> Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine. Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable.

> Like, why don't we just let projects be "done"? Things don't need to be maintained and updated for eternity.

I agree with this but

> native executable binary file

This is hard because new architectures, instructions, optimizations show up every few years.

> Like, why don't we just let projects be "done"? Things don't need to be maintained and updated for eternity.

As the Buddha taught, desires are numberless. I don't think I've ever even heard of a piece of software that hit 1.0 and people were like, "Welp, it's perfect, never change a thing." I've certainly never worked on one. Indeed, the biggest sign of project success to me is releasing an initial version and people being shocked, shocked at the obvious features I missed. And I love it, as that's proof that they're really trying to use it for their real-world needs.

"In my mind, the best software engineering is where you solve a problem once and your solution just works and needs no configuration or maintenance or updates."

https://cr.yp.to/software.html

> and Windows is kind of known for bending over backwards to maintain compatibility with old programs

Maybe they used to, but good luck running anything made for Windows XP on current version of Windows. But you will have a better luck if you run it with Wine on Linux.

I have an application I developed for a client starting in 2005 using Delphi 7; my VM is based on Windows XP, and the app worked fine on Windows 7 and is now used on Windows 10. I had to update one setting in an external configuration file for slight differences in the ADO driver, but other than that I haven't rebuilt the executable for years.

I was genuinely pleased for the client as they are nice people running an essential service on a budget that is always under threat, and this result means not needing to pay for a silly 'fresh' version of the application.

How many security features inherent to 64bit processes are they missing? Or is that not relevant for their deployment?

No, no relevant in this case.

> Yes, to a certain degree it's impossible to design software that does not exist as a part of an ecosystem, which is why I put it in quotes.

I’m doing a big embedded project and all the code is self contained! The only inputs are physical user inputs.

Well, bugs do get found, and continual new demands from humans make more optimizations necessary. SemVer is the compromise between stability and continual improvement, and I think it works pretty well, all considered.

"Evergreen" might be a word we can use here.

Can you elaborate about this mindset in the context of vulnerabilities and bugs?

Reply on news.ycombinator.com