Almost exactly a year ago, I posted a blog article titled Is 7 years of RHEL support still sufficient ?. In that article I make the case that with RHEL major releases moving from 1.5 years to 3 years and virtualization reducing the importance of hardware life cycles, RHEL support should be extended beyond 7 years.
Yesterday Red Hat announced that it did just that. From today Red Hat offers RHEL Extended Life Cycle Support (ELS) on top of normal subscriptions for specific versions and variants. Meaning that for RHEL3 only i686 AS/ES and for RHEL4 i686 and x86_64 AS/ES and ia64 AS are taken into consideration and are thus more expensive than regular support. No pricing information is available yet.
After a fair share of improvements and plugins, including plugins to monitor Dstat's own performance, it was time to get another release out of the door. Last week I updated the documentation and manpage, and this week Dstat 0.7.2 saw the light.
Your systems may already have picked it up, but if you haven't noticed, CentOS 5.5 has been released. You can find more information in the RHEL 5.5 release announcement.
Additionally, the CentOS community compiles its own list of interesting tidbits in the CentOS 5.5 release notes, which is an interesting read as well. The CentOS 5.5 LiveCD is released at the same time and has a its own release notes in the wiki.
Yesterday arrived at another hotel and the wireless internet caused problems, not on Windows XP, only on my Linux system (CentOS 5.4, kernel 2.6.18-194.el5, iwlagn v1.3.27k). The behavior was that it infrequently would associate, but when it did DHCP failed. The moment it associated I could sniff other network traffic though. Being downtown San Francisco doesn't help either, I had more than 60 access points broadcasting their services...
I always forget this command and it takes a while to search for it, but if you ever start doing administration work on systems and you want to keep track of what you have been doing for documentation, always remember the script command.
I am referencing it here, so I will never forget !
Seven years is a long time. Most people won't know where they are in 7 years. I'm interested to find out how many kids will be running around the house in 2016 :-) However if you are responsible for thousands of Enterprise Linux servers, seven years may no longer be sufficient.
Let me explain what I mean. When Red Hat released RHEL2.1, seven years of support was perfect, seemed more than one would want. RHEL3 came 18 months after RHEL2.1 and after one year of testing RHEL3 and 3rd party integration new systems could be deployed, giving you 6 years of support. Your hardware would usually not outlive the operating system support.
Today Red Hat released a minor update (v5.4) of their Red Hat Enterprise Linux 5 product line. The minor releases comprise mostly of bug-fixes and feature enhancements and the official announcement is pretty light on both, likely because Red Hat has its yearly summit right now in Chicago. (And yes, I lack the budget to go there :-/)
With disappointment and regret I decided to resign from the CentOS team after having spent the prior weekend thinking it through. It was not the first time I was in this situation, but this time the number of reasons weighed up against the belief that I can make a difference from within the team.
I love Firefox a lot, more than any other browser actually. With my small set of addons, me and Firefox, we conquer the world every day !
That's why I hate it when my buddy Firefox is chewing away too many CPU cycles while not doing anything. It is really frustrating because it heatens my lap(top), flattens my battery and slowens my work. (yeah yeah, I know that is not proper English)
I just read the ComputerWorld article "Are there too many desktop Linuxes?" and once again I think the author is missing something very obvious and important.
If we are talking about Desktop Linux, we are talking about the consumer and enterprise market. If we are talking about the consumer and enterprise market, we are talking mostly about non-technical people and not me or you (since you are reading my blog, I do not consider you the average computer user).
When you need to know whether hyper-threading is enabled without the luxury to reboot the system (and consulting the BIOS), you can simply look at the output of /proc/cpuinfo and compare the siblings with the cpu cores fields.
Even though /proc/cpuinfo shows you all the logical CPUs (processor field) in the system, the siblings field holds the number of logical CPUs for the physical CPU this entry belongs to (including both the cores and the hyper-threaded LCPUs).
In other words, if you see:
I cannot say I am sad about this, nor am I really happy. Different viewpoints help people choose what they find important and sometimes we can learn from it. But it also does not surprise me since it is much more rewarding to construct, help and share than it is to destroy, trash or conceal.
But the past weeks no new stories have been reported on KernelTrap, not even a notice of what has happened. So is KernelTrap dead ?
Today I had an interesting conversation with a colleague about the Linux
provisioning (how I dislike that word) deployment system we are developing at a customer. And in the midst of things he brought up how he started with Linux.
Apparently we share the same story, and I wondered how many other people were driven to Linux by frustration over some unexplained Windows bug at the time.
My story goes back to 1995, involved Windows 95 and an expensive CD burner I bought. I was already using Linux on a 80386, but that one was slower and did not have an internet connection.
At a customer today I was confronted with a situation where VMware ESX processes had log-files open that were already deleted. This can happen when logrotate was incorrectly configured, or when operational staff removed big files to clean up diskspace quickly.
However when the file is still open, you can remove the file-entry (link) to the inode, but the diskspace will not become available until all kernel references to the inode are gone (and a process having the file open counts as a reference too).
Killing the VMware processes that had the file open was not an option since we just wanted to truncate the file without impacting the guests.