51–60 of 112 posts
I stopped letting my iPhone update. I swear every update makes it slower and buggier. My old iPad which was perfectly fast and great at the time is now almost unusable after 4 iOS upgrades. It won't even play Sudoko without constant mini freezes.
I'm sure cybercriminals are very thankful for people like you. Are you also still running Windows XP, because newer versions slow down your computer which "was perfectly fast and great at the time"?
Earlier quoted context omitted.
But on the other hand, if the software is stable and no longer needs updating why force small inconsequential changes just to appear to be maintained? Just release when there's something to release.
There is no software without bugs. People seem to know that. Developers sometimes do not.
If someone opens an issue, will it get addressed quickly? That's what users care about.
Earlier quoted context omitted.
Terrible examples, considering that these are programming languages that people will use to run code from random sources. "git clone foo && cmake foo" can definitely be a security problem, and not just because the code itself is untrusted.
It's not cmake's job to limit the behaviour of programs written with it.
Earlier quoted context omitted.
> There is such a thing as finished software. With no major bugs. That does not need constant updates. The general attitude (both on HN and elsewhere) is that if any security update exists for a product you use then you are a complete moron not to update it immediately. There is virtually no acknowledgment of any nuance on the topic in my experience.
Not applying a security update is willingly leaving a known security hole in place. At best, you are making your system insecure, and at worst, you are putting others on your network and/or in your social circles at risk.
Earlier quoted context omitted.
It's not cmake's job to limit the behaviour of programs written with it.
OTOH, allocating & using memory correctly so that a maliciously-crafted Makefile can't get elevated permissions is .
Earlier quoted context omitted.
All software has bugs. There is no such thing as finished software. The size of a bug is in the eye of the beholder. Sorry for the Shellshock. Edit, took me two seconds to find: https://news.ycombinator.com/item?id=502651 . Just as response to http://cr.yp.to/djbdns/guarantee.html
You may be missing the point if the post. Good software asymptotically aproaches bug free over time. Meaning it should require fewer and fewer updates less and less frequently. But reduced frequency of updates is percieved as death of software, and this is actually a problem. I even see it in developers who use it as a metric when choosing frameworks and libraries which is a mistake for older software. I saw a study…
Earlier quoted context omitted.
But on the other hand, if the software is stable and no longer needs updating why force small inconsequential changes just to appear to be maintained? Just release when there's something to release.
Some people just want to stay home and watch movies and live a tranquil life while others don't feel good if they aren't permanently moving and discovering the world.
Software updates are a kind of project heartbeat. The content of them is less important than the signal, "this project is still alive, and maintainers are fixing issues for people". If a project does not put out updates, then users may (understandably) worry that if they have an issue, it won't get addressed promptly. I actually don't think there is anything wrong with having time-based releases, and putting very lit…
But on the other hand, if the software is stable and no longer needs updating why force small inconsequential changes just to appear to be maintained? Just release when there's something to release.
This emphatically does not work very well for big projects. The problem is human pyschology and the unreliability of all effort estimation processes (in software development). Once people get used to the idea that "well, we'll just postpone the release a little bit" then it eventually becomes a routine thing and for popular projects there's always someone who has a good reason that their particular feature should make it in before the release. (Because who knows when the next release will be?)
The Linux kernel and the C++ ISO standards committee have got this EXACTLY right (since C++11). Predictable releases means:
a) you don't need to rush anything particularly because you know there'll be a new release in N months.
b) any incidental small (not-worthy-of-a-release) bugs get fixed in the interim.
c) downstreams can plan based on when your next release is going to happen.
Predictability is a huge deal and IMO it's incredibly underappreciated just how much it matters. Even if it meant a 10% or 20% 'efficiency' loss (on some metric) I would personally still consider it a win.
For an example of not doing it this way, look at C++ pre-2011 and perhaps also ECMAScript pre-2015. (This is also rampant is development, though no public examples come to mind right now. I'm sure some other commenter can supply some. It's so bad that it can in fact kill projects.)
EDIT: I forgot to mention: Regular updates also means that the "consumer" must get into the practice of regularly applying updates... and will thus become forced to get better at doing that. Ideally to the point of having completely automated updates.