What is Linux kernel versions(like 2.x, 3.x, 4.x)'s major difference?
And 2.x and 3.x version have stable version?
Actually I think you should know that stable/EOL and longterm mean:
As kernels move from the mainline into the stable category, two things can happen:
They can reach End of Life after a few bugfix revisions, which means that kernel maintainers will release no more bugfixes for this kernel version, or
They can be put into longterm maintenance, which means that maintainers will provide bugfixes for this kernel revision for a much longer period of time.
And here are longterm release kernels and stable kernels:
mainline: 4.10-rc4
stable: 4.9.4
stable: 4.8.17
longterm: 4.4.43
longterm: 4.1.37
longterm: 3.18.46
longterm: 3.16.39
longterm: 3.12.69
longterm: 3.10.104
longterm: 3.4.113
longterm: 3.2.84
If you want to see Linux kernel changelog or bugs,you can check out this,and also you can read the feature history of Linux kernel.
Hope this helps.
I have no experience whatsoever with kernel development but this same question about the significance of major version numbers came to my mind at some point too.
The first point of call to answer this question is The Linux Kernel Archives that groups the versions into:
v0.x - historic
v1.0 - changelog
v1.1
v1.2
v1.3
v2.0 - changelog
v2.1 - development
v2.2 - stable
v2.3 - development
v2.4 - stable, stayed around for ~10 years
v2.5 - development
v2.6 - stable, stayed around for ~12 years
v3.x - the transition from version 2.6.39 to 3.0 is a perfectly normal version increment, following the pattern set for the 2.6 series *
v4.x - switch from 3.x to 4.0 version numbers is entirely meaningless and it should not be associated to any important changes in the kernel *
So while up to version 2.6 there is a development/stable pattern (see timeline), from version 2.6 the different major version number appears to signify nothing and the things one should pay attention to when switching kernels is the changelog and length of support. Beyond that changing from 2 to 3 or from 3 to 4 is not going to be any different than switching from 3.x to 3.y.
There is a post on Unix & Linux that goes more into gore details of the highlights of particular kernel versions.
Please find this reference to start for your question.
Related
Ruby comes automatically installed on OS X. I assume when you get a new Mac it comes with the latest stable release of Ruby. Do you have to update it yourself manually over time, or does it get upgraded automatically when you upgrade your OS?
I assume when you get a new Mac it comes with the latest stable release of Ruby.
No, it comes with whatever release Apple felt confident to support for the lifetime of the OS release.
Do you have to update it yourself manually over time, or does it get upgraded automatically when you upgrade your OS?
Those two are not mutually exclusive.
Yes, it does get upgraded automatically, in order to, e.g., patch security vulnerabilities. However, an OS vendor will generally avoid updating anything they ship as part of the OS as much as possible, since they generally guarantee backwards-compatibility, and the easiest way to guarantee backwards-compatibility for third-party code that you have no control over, is to just not change it.
For example, macOS 10.14.6, which is the current release of macOS and was released 4 weeks ago, ships with Ruby 2.3.7, which was released 18 months ago.
The last release of Ruby 2.3 was Ruby 2.3.8, and the Ruby developers stopped providing security patches to Ruby 2.3 6 months ago. (Note that Apple does still provide security patches for Ruby 2.3 as part of macOS, though.)
So, yes, it does get upgraded automatically, with e.g. security fixes, but if you want a different version than the one shipped with the OS, you have to install it yourself.
Short answer: No.
Long answer:
If you just want a taste of Ruby, then no, you really don't need to do anything.
If you want to use Ruby to do something non-trivial, like beyond a "Hello, world!" application, then yes you should update.
The best approach is to use a Ruby version manager like RVM or rbenv where you can get the latest version of Ruby, specific historical versions if necessary for testing, as well as alternate implementations like JRuby and Rubinius.
These version managers make it possible to have multiple versions of Ruby installed simultaneously and you can switch between at any time. You can even pin different projects at specific versions if they haven't been updated to work with the latest Ruby, a common problem with older code-bases.
This pattern plays out with any language, be it Ruby, Python, Perl, Node.js, C# or what have you. If you're doing serious development in those languages the first thing you do is install a version manager and the best version for your situation.
I've visited the website to download the latest version and I found that 2.8.4 was released after 2.9.1. Why does that happen? And which one should I download?
Why are companies still running Java 6 and 7 while they are end of life? Why is Java 8 still updated when Java 9 and 10 are available?
My point is that at one point, Hadoop 2.7.x was the stable branch. 2.8, 2.9 introduce some potentially breaking or otherwise major, possibly unstable change. The previous releases still need support to address bugs and backport useful features. You're welcome to read the release notes to see what those may be.
It's worth mentioning that the Hadoop vendors like Hortonworks and Cloudera are currently using some version 2.7 with some patches applied on top of what you'd get on the Apache site.
Meanwhile, if you want the latest and greatest, and don't care about stability, you can use Hadoop 3.x, but if you want other things like Spark, Sqoop, HBase, Hive, then I'd suggest staying at 2.7 for now. Or at least read over the documentation for each component and see if you can find installation requirements.
AFAIK the installation of Lazarus consists from downloading it and FPC from SVN and compiling. There's a problem(*) with the newest versions and I'd like to install a stable version. However, all I have are the SVN revision numbers and I couldn't find out what versions are stable and what work together.
(*) Our application crashes when compiled on Ubuntu 32 and run on OpenSUZE. No idea, what's exactly going on, but this is a too complicated problem for including it in this question.
No, both projects provide releases, and these releases are the only ones formally declared stable, currently Lazarus 1.2.6 (from the 1.2 stable branch) using FPC 2.6.4 (also from stable 2.6 branch).
Lazarus mentions the prefered version of (release, stable) FPC with every release and for 1.2.6 that is 2.6.4.
Of course the status of moving trunk is sometimes more stable than other times, e.g. currently it is quite usable because a new major (FPC) branch is imminent, an event that only occurs once every 2-3 years. But there are no guarantees there, and this branch still must go through the formal release process.
Many users from emerging targets that are not supported in the stable branches often use it though.
I want to play a bit with ChronicleMap and a bit confused which version should I use in production.
1.* looks like 'released' one, 2.* looks like in alpha stage. I would use release version but from my understanding current documentation refers features from an alpha version.
I.e. I don't see OffHeapUpdatableChronicleMapBuilder in 1.0.2. Since it is a 'official' documentation I can think that 2.* can be used in production as well. Can it?
PS Environment - java 8, 64 bit windows for dev, linux in production.
Chronicle Map 2.x is the version you should be considering.
It is in beta now, with no significant enhancements planned, only bug fixes.
The beta version is suitable for development and the API won't change significantly before the release.
How long it is a beta release depends on how many bugs are reported. Of course we are hoping this will be a week or two.
The first production quality release will be 2.1.
I want to know which gcc/g++ version released is the most stable to date? I had an impression that gcc version 2.95 was the most stable but a few peers told me that gcc 3.x versions are now the most stable.
The 2.95 branch hasn't had an update in over ten years. I certainly wouldn't be using it for anything voluntarily. Use whatever is the latest available for your system unless you have specific knowledge of a need to use something else (a vague "impression" is not specific knowledge, actual bugs and specific compatibility problems are).
Even 3.x is rapidly aging. There is no general reason not to use 4.x.
The only gcc versions that are actively worked on - i.e. debugged and stabilized are gcc-4.n where n > 3 these days. Use the gcc-4.* series. Even cygwin and mingw are off gcc-3.* these days.
GCC 4.6.2 has been released recently, on 27 Oct 2011.
And chosing a specific version of GCC is not a guarantee that your binary will work on all linux-es you want, because distributions may have different versions of the C++ standard libraries.
I'll recommend not using something older than GCC 4.5, and preferably 4.6. However, you might want to use the version used to compile your linux distribution.