41–50 of 288 posts
I upgraded my Ubuntu distribution last week and my old Xerox Phaser laser printer stopped working over the network. Something like this should never happen. I hate spending my weekends troubleshooting the Samba configuration. Maybe I will connect the printer to a Windows VM.
As a red teamer/pentester, this is an attacker's dream. This has to be a joke.
I upgraded my Ubuntu distribution last week and my old Xerox Phaser laser printer stopped working over the network. Something like this should never happen. I hate spending my weekends troubleshooting the Samba configuration. Maybe I will connect the printer to a Windows VM.
"Be on this version. Now."
DOS 5.2 ftw
Do what my Tandy 1000 did, and burn DOS 3.3 right to ROM. None of this wimpy flash-but-with-a-read-only-bit, no fancy UV-erasable EEPROM...just honest-to-goodness-blown-fuse ROM. Boots immediately too.
There’s something to be said for being on the oldest minor version that still receives patch releases (usually the LTS if there is such a thing). Unfortunately most FOSS libraries don’t have the luxury/resources to support parallel releases. So to get security fixes you need to keep somewhat up to date with other changes. The worst place to be is having to fix a CVE in a hurry, but first having to upgrade your framew…
I guess enterprise Linux subscriptions are such a tax, right ? It pays for Red Hat/SUSE/Canonical to maintain and old stable version CVE free for you, so you don't have to update so often.
It's wonderful.
Semantic versioning is a curse. It makes perfect logical sense until you are a few iterations in and quickly run into dependency hell as shown in the diagrams in the article. My solution to this isn't "never update anything", but rather "never version anything". People can choose to stick to the bits they originally got, which is perfectly fine, or they can switch to the current "live" one. As a developer I'm only ev…
That's valid under semver.
The crazy diagrams show what happens when you want to support lots of old versions.
I have semver stuff at work where I only maintain the latest version. Bugfixes bump the patch version, adding a feature bumps minor, removing a feature bumps major.
I don't make any special effort to bump or avoid bumping anything. It gives me a rough idea of whether a given version has new stuff in it (x.1.0 or x.2.0) or is just a bugfix (x.0.1 or x.1.1)
Dependency hell has nothing to do with how you label your versions and everything to do with how much you want to annoy users by breaking whatever you like vs annoy yourself by taking the time to set stable APIs and hold compatibility backwards and forwards.
Semver vs. Git commit hashes vs. "just one number" vs. web browser versioning vs. "just timestamp" is all just different labels on the same soupcans.
Earlier quoted context omitted.
I guess enterprise Linux subscriptions are such a tax, right ? It pays for Red Hat/SUSE/Canonical to maintain and old stable version CVE free for you, so you don't have to update so often.
Sure, or if you prefer: the price of Debian Stable is that you only get security updates and bug fixes until the next Stable release. It's wonderful.
Earlier quoted context omitted.
I guess enterprise Linux subscriptions are such a tax, right ? It pays for Red Hat/SUSE/Canonical to maintain and old stable version CVE free for you, so you don't have to update so often.
Sure, or if you prefer: the price of Debian Stable is that you only get security updates and bug fixes until the next Stable release. It's wonderful.
Earlier quoted context omitted.
You don't need semantic versioning for that. "Oh, this was introduced in build 22456" works just as well.
Except that using a build number in the way you're describing is just a worse semantic version. You now have no way to indicate if your changes are breaking. Separation of your pipelines also just got a lot more hectic because you could have a situation where you don't know what happened when you're missing "versions" (builds) because it's failing but still incrementing... Using build numbers for versioning doesn't r…
I'm with the GP on this. Pinning to a specific version is a code smell. You should have enough confidence in your regression suite to always use the latest version. And hopefully enough confidence in your vendors that they're not going to break a bunch of stuff.