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.
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 am frustrated: I want to yum install ruby and install Ruby 2.4.1 or 2.3.0. Instead it seems that I have to use RVM or rbenv to get any version after 2.0.0 and both of those tools require some arduous process.
Why is this so complicated? Shouldn't I be able to install Ruby with a single yum command and use '/usr/bin/ruby' like I would '/usr/bin/java'?
Things change between Ruby versions. With the release of Ruby 2.4.0, many gems and applications needed to be updated in order to be compatible without breaking, including JSON, Rails, Nokogiri and others.
Now, with a OS distribution, people usually expect two things:
relative stability over its release cycle, so, things which worked yesterday continue to work tomorrow
that all shipped packages are compatible to each other.
If the CentOS maintainers were to upgrade their Ruby version mid-release, they would have to ensure that all other software they ship which depends on Ruby is also compatible with this new version, probably by also updating it. This leads to a maintenance nightmare since, often, these updates also change features which break the first point of requiring stability.
Because of that distributions usually ship a single version of Ruby (or Python or Perl) and only fix necessary bugs by backporting the fixes to their versions. Major updates are usually only done with a complete new OS release. How often this happens depends on the distribution you use. CentOS/RHEL tend to be very slow, Debian is so-so, Ubuntu has slower-to-update LTS releases and quicker-to-update regular releases.
In general, you trade stability for bleeding edge. And for their base OS, most people running servers tend to favor stability.
To use a newer version of Ruby for your own apps, you can still use rbenv, RVM, or any of the other Ruby installers. You can install these custom Ruby versions along the OS version and configure your own applications to use these versions.
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.
My application requires a GUI, and I was thinking of using GTK+ because by far it is the best library for Graphical User Interface. When I looked at the GTK+ page and went to Language Bindings, I found the following:
If Ruby is a good language and has a lot of programmers, why doesn't Ruby support GTK+ 2.14 and newer versions?
Because bindings to a more recent versions hasn't been yet written ? ;-)
Ruby-GNOME project is probably the most known implementation, see status of Gtk2. They also provide bindings for Gtk3, version 3.4 .
The differences between 2.12 and 2.24 are relatively marginal, there is no point it should you keep back at writing Gtk2 UIs in Ruby. The project is very active, latest commits was done a day ago.
Btw. linking on Linux/BSD systems is done to the major version so it'll run regardless minor subversion is currently installed. If there is some very specific feature added in latest versions you can write binding yourself, it's very easy. However as you are just at learning stage I'd bet you'll ever get in such situation in the near future.
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.