Does anybody know the reason why fedora 10 (quite a modern linux distro I'd say) still shipped with boost version 1.34, while latest release is 1.38 ?
Operating systems are seldom shipped with the latest versions of anything. It's not just a matter of packaging the latest version of X with the OS, because every other part that depends of X has to be tested with the new version. Compatibility on paper doesn't always mean compatibility in reality - there can and will be surprises.
That's why for instance Debian's stable releases include almost ancient software sometimes; ancient, but stable.
Probably because people aren't willing to chip in and help keep the package up to date.
Hint, hint.
If it's any consolation, Ubuntu Jaunty looks like it will have 1.37...
My guess is that they shipped a somewhat old library because it still worked, and they didn't want to test a new version. Distos are usually one or two versions behind on most packages. Also, 1.38 didn't exist when Fedora 10 was released. For Fedora 11, they might ship a newer version.
Probably they didn't have packages that depend on libboost > 1.34.
Don't know about Fedora, but Debian/testing was stuck on 1.35 for most of last year while they got Lenny released. Meanwhile boost released 1.36, 1.37 & 1.38 fast and furious within a 7 month period.
I don't see it as a big deal. Stuff boost releases is generally in a very stable "done" state, not a work in progress. If you're using something in 1.3x, then it's pretty unlikely you'll hit bugs which you need a later version to fix. If you absolutely want some new library they've released, then building a /usr/local version from sources isn't that onerous.
Related
SDL2 is often described as breaking backwards compatibility with SDL 1.2.
This implies that within different versions of SDL2, the API and ABI remain backwards-compatible.
However, I have not been able to find any authoritative source confirming that this is the case.
For example, for GLIBC, Red Hat maintains a webpage which states:
One of the GNU C Library's (glibc's) unwritten rules is that a program built against an old version of glibc will continue to work against newer versions of glibc.
This guarantee is very useful for portability, as it means that a program can be compiled against an older version of GLIBC and run on any platform that ships at least that version or any newer version of GLIBC.
The closest to such a guarantee that I have been able to find for SDL2 are the release notes for PySDL2, a separate project, which make passing references to "backwards compatibility":
Improved compatibility with older SDL2 releases […]
[…] properly wrapped now to retain backwards compatibility with previous SDL2 releases
[…] provide backwards compatibility for previous SDL2 releases […]
There are also two issues on Github which make passing mentions to "backwards compatibility" in the context of using SDL2, but also aren't actually directly tied to the SDL library at all.
Is there any official or authoritative source documenting or guaranteeing backwards compatibility across different versions of SDL2?
I.E., If I compile a program to dynamically link against an older version of SDL2, is it safe to assume that it will work on platforms that provide a newer version of SDL2?
Official Statements
It appears that one of the first goals reached in the development of SDL2 was to stabilize the ABI, explicitly so that no breaking changes would happen to it until SDL 3, according to the original author and main developer of SDL:
slouken
Regular
Mar '13
As of tonight, SDL 2.0 is ABI locked!
This means that no breaking changes will happen to the API until SDL
3.
Cheers!
From the SDL wiki:
We are obsessive about SDL2 having a backwards-compatible ABI. Whether you build your game using the Steam Runtime SDK or just about any old copy of SDL2, it should work with the one that ships with Steam.
A similar process is planned for the development of SDL 3:
slouken commented 22 days ago (4 Oct 2022, 18:45 GMT)
Our current plan is to make all the ABI breaking changes immediately before the very first SDL3 release, so we have a stable ABI from the very beginning.
Empirically
If we go on abi-laboratory.pro, we may see that SDL2 has more or less kept its promise of perfect ABI compatibility throughout every release:
Source
Specific changes between each version can furthermore be reported by clicking on the percentages.
I'm playing around with the Xcode 10 beta, and I noticed while doing compile-time checks of the Swift version number that projects with the Swift Language Version set to Swift 4 in their Build Settings are reporting as Swift 4.1.50 (betas 2, 3, and 4 do this; I didn't get a chance to test beta 1). This strikes me as... bizarre, to say the least. The current AppStore version of Xcode, Xcode 9.4.1, reports its version as Swift 4.1.2.
So... What happened to Swift 4.1.3 through 4.1.49? Or is this a bug that I should file? Or is the 50 significant in some way?
You can test this yourself with my test file, Swift Version Checker
According to Jordan Rose on the Swift bug tracker:
This is the least bad answer we could come up with, given that we may still release more 4.1.x versions if there's, say, a bad security vulnerability in one of them. (This has happened before.) We needed a version number that was greater than any existing 4.1 version, but still less than 4.2.
We did consider other ideas, but this is the one we went with for maximum compatibility. We at least won't have this problem in the future thanks to SE-0212.
So, what I take from this is that there might still have to be an actual 4.1 release sometime in the future, but that would just be a security patch atop 4.1.2, so the logical number for that would be 4.1.3. Meanwhile, the pseudo-4.1 Swift that the Swift 4.2 compiler can digest needs its own number that also reflects it's a dialect of 4.1, and their conclusion was 4.1.50, which is safely far enough away from 4.1.2 to allow for as many security patches as they want.
I'm somewhat confused on the Linux kernel version numbers. I noticed that many Linux distributions do no use the latest Kernels, in fact I have seen a few using version 2.4. Is there a reason for this? Is there any differences between 2.4, 2.6, 3.2 apart from age? What are the security implications of using an older kernel?
Different kernels have different features and improvements the developers of a distribution take a look at features they are going to support then decide which kernel to use based on the most stable support of that kernel.
It is the decision of the distribution developer which one to use, and they would go with the one they felt comfortable with.
This is a feature of software development its like asking what Java 1.1 and Java 1.7 is and whats the difference is apart from age... the answer is many things.
Most kernels and software will also have a security patch schedule and it is up to the user to keep their systems patched and up to date if you do not then you invite security issues as they are never fixed.
between major releases (e.g. 2.4 and 2.6), new features are introduced and old features are deprecated, eventually making the kernel binary incompatible.
this is important if you depend on some kernel-module that is not part of the mainline kernel (e.g. it is proprietary and the original authors don't provide updated modules; or it is open source (but never made it into the kernel) and nobody is willing to spend time to migrate the code)
also a new major release might change the system behaviour significantly. i remember that when switching from 2.4 to 2.6, many people that needed low latency audio (that's my background, so forgive me) would stay with the old kernel, since the new scheduling algorithms performed worse in some situations.
I hope the below page would help us in understanding the linux version numbering system:
http://www.linfo.org/kernel_version_numbering.html
A snap from http://www.tldp.org/FAQ/Linux-FAQ/kernel.html#linux-versioning
Linux version numbers follow a longstanding tradition. Each version has three numbers, i.e., X.Y.Z. The "X" is only incremented when a really significant change happens, one that makes software written for one version no longer operate correctly on the other. This happens very rarely -- in Linux's history it has happened exactly once.
The "Y" tells you which development "series" you are in. A stable kernel will always have an even number in this position, while a development kernel will always have an odd number.
The "Z" specifies which exact version of the kernel you have, and it is incremented on every release.
There is a human-readable changelog for the Linux Kernel.
Some people take the attitude "if it works - don't change it". So, there are security implications of running an older kernel - but there's also the risk that upgrading may break something.
As kernels improve/change, they might break expectations that held on earlier versions. If a distribution becomes unstable because too many software breaks under the new version of the kernel, the developers might opt to use an earlier version until the software is able to handle the changes in the new kernel.
Typically a binary image may not be portable between kernels where the first or second part of the version number changes. So in order to upgrade from 2.4 to 2.6, a large proportion of libs and executables will need to be upgraded / recompiled too. This can be a particular problem if you use closed source applications/drivers.
Most Linux distributors will back port patches from newer kernel versions depending on the security impact / demand for additional functionality. If you're not able to upgrade your entire system at regular intervals, then you need to find a distribution which explicitly supports a long support cycle with a good history of back porting (e.g. RHEL, SuSE).
I've just inherited an application written in Groovy (version 1.3.5) and would like to upgrade it to the newest release (version 1.7.5).
I can't seem to find a reference that enumerates the differences in syntax, etc., which I would need to be aware of ... and yes, I looked at http://groovy.codehaus.org
Does anyone know of a good place that lists version changes?
Many thanks,
~Aki
I think your best bet would be to try it and see where your tests fail.
You do have tests right? ;-)
If not, I'd write some, then try the upgrade and fix where needed.
I don't believe there is a single page where you'd find all the changes from one version to another.
You could maybe collate something by going through all the release notes, but it's probably quicker to just try it.
You can find the changes from one version to another by looking at the release notes. However, the release notes only describe the changes from version N to version N + 1. I don't know how many versions there were between 1.3.5 and 1.7.5, but I'd guess at least 10.
To discover all the changes between 1.3.5 and 1.7.5, you'll have to look at the release notes for each release. Starting from this page, you should be able to find them all, here are some links to get you started.
1.7.5
1.7.4
1.6.9
1.6.8
1.5.8
You should be able to get older releases (and their notes) from the distribution archive.
Having said all that, reading release notes doesn't guarantee anything, (though it's a good way to learn about new features). The only way to be sure that your code runs under the newest version is to compile and test it under that version.
I'm debugging a program that runs fine on one machine running (fill in the blank with some linux distro and version) but acts flaky on another machine running (different distro/version).
A helpful clue would be to see a side-by-side list of versions of all the major libraries provided by each distro - Qt, boost, libpng, fftw3, etc. including all the obscure ones. We're not concerned about upgrades to libraries that may have happened since (for now).
Today it's Red Hat 5 vs. Fedora 13, but in the past I've wanted to compare Fedora and Ubuntu, and in the future any combination of major distros and versions, from at least four years ago up to last week, could come up. I'm hunting for a general way to find these library version differences.
A web app that lets one pick any two distros and get a list would be awesome. Does such a thing exist? (If not, there's an idea for some entrepreneur.)
Note: I don't have access to one of the machines, so sorting and comparing 'ls /usr/lib' is out.
The closest I know about would definitely be this one (the name rpmfind.net should give away it's RPM centric so Ubuntu will probably not be listed): http://rpmfind.net/linux/RPM/