Red Hat® Satellite is a system management solution that makes Red Hat infrastructure easier to deploy, scale, and manage across physical, virtual, and cloud environments. Red Hat Satellite enables users to provision, configure, and update systems to help ensure that they are running efficiently andsecurely, and remain compliant with relevant standards. By automating most tasks related to maintaining systems, Red Hat Satellite helps organizations increase efficiency, reduce operational costs, and enable IT to better respond to strategic business needs.
I know we have our disagreements. At times I don’t know where you are going. Or whether even you know where you are going. But that’s OK. Because you are still awesome. You still pay my bills. You are still fun to use. And you are still on every single computer I can get my hands on, both at home and at work.
While I had a few hiccups with you over the years – those Gnome and KDE fights, those boot loader changes, and still painful inclusion of SELinux, you’ve always been there for me. I’ve helped me to build numerous projects. To make new friends. To understand the world better.
Please continue to be what you are. Please continue to change. Please continue to improve. Just, if you can, think of me, your biggest fan and seasoned user, once in a while.
Chris Haney has put together a simple application that allows one to browse through numerous Linux screenshots. More than 400 different Linux distributions are presented, with many of them featuring screenshots from different releases. This is interesting both in terms of how much a distribution has changed over time, and how one distribution compares to another.
I wish these were organized a bit differently, allowing more of a photo gallery experience. But I’m sure the improvements will come over time.
At the June 8 meeting of the Fedora engineering steering committee (FESCo), the group decided that Fedora 16 will ship with Btrfs as its default filesystem. Btrfs is a relatively new copy-on-write filesystem with many interesting features such as read-only and writeable snapshots, multiple device support for RAID, online filesystem defragmentation, and more, though it is still marked as experimental in the kernel. “AGREED: Feature is approved. Will add some base critera to the page to be met by feature freeze. This is just a swap of ext4 to btrfs for default, not change of lvm or other parts of default.“
As noted in the comments, Btrfs is marked as an experimental feature in the kernel. As also noted in the comments, many other features which were marked as experimental were brought into production and that seemed to work fine.
While I personally have no knowledge of Btrfs stability or readiness for production, I am slightly worried by that move. First of all, ext4 – current default filesystem – works fine for me and for everyone I know. Why fixing something that works? It seems that Btrfs is a better choice for server platforms. And while Fedora is mostly used on the desktop, it is still a testing platform for Red Hat distribution which is, in fact, a server-oriented line of products.
On another note, Fedora 15 upgrade was a bumpy ride. Again, not just for me, but for everyone I know. Switch to Gnome3, sysctl, and other changes didn’t quite work out of the box for many people. Btrfs might do the same. I think it’s better to push such a change at least to Fedora 17. Let people recover slightly. Focus instead on fixing things which are broken. Let people regain confidence in Fedora distribution and its upgrade paths. Please.
I’ve heard a few harsh words about Subversion before. Mostly these came from sysadmins who complained about all bits and pieces Subversion requires to work properly. Some mentioned that it is not trivial to compile with the set of options that is different from the default.
Today I spent about three hours together with The Master of Strace trying to make Subversion command line client svn work on one of our old machines that runs Red Hat Linux 6.2. The only way to success, it seems, was to compile the static version of svn. Since we needed support for https:// URLs, we had to build with OpenSSL. OpenSSL is not trivial to compile statically too, because of it enourmous love of Kerberos5. While trying to make it work we also jumped through a number of versions of Subversion and other components.
Finally, we managed to build everything. In case you’ll ever need a statically compiled version of svn (from Subversion version 0.17.1 (r4503)), you can get it here (the binary is about 7 MB):
As far as I am concerned it works just fine. It runs on Red Hat Linux 6.2 and can work (import, checkout, commit, etc) with repository running on one of the recent versions (1.1.4 if I recall correctly).
Needless to say that today I’ve heard a few more not-for-kids-ears words and phrases towards Subversion developers.