2009-07-07

RHEL/CentOS bi-arch problems

Posted in Computers, Personal, PlanetDebian, rant at 10:57 CEST (+0200) by sven

Oh well, I think RHELs support for multiple architectures installed at the same time (and thus the same support in CentOS) really needs some rethinking.
While the following might not be able to happen with the default installation media (I didn’t verify), it still can happen if you run your own mirrors and actually need both architectures listed in your yum repositories…
Anyway, what happened today is just one example of how the multi-arch support caused problems for me:

On a Xen Dom0, I needed to apply a kernel upgrade (from 2.6.18-92something to 2.6.18-128something) and as a result, a reboot. At this point you should memorize that the old kernel worked quite fine and all I did was a yum update followed by a reboot. A procedure I did on quite a number of Dom0 machines in the past weeks.

Well, the reboot this time didn’t work, the kernel halted after printing:
request_module: runaway loop modprobe binfmt-464c

Well, reboot again, select old kernel, systems boots fine….

What happened was that both the x86_64 and i686 versions of the old kernel was installed, so yum update updated both, probably first the x86_64 version, then the i686 version (but I didn’t check). Well, while for the old kernel, grub booted the x86_64 kernel with the x86_64 initrd, for the new kernel it tried to boot the i686 kernel with the x86_64 initrd. (verified by unpacking the initrd and the vmlinuz kernel image and running file on the binaries therein)

Now the big question is: How could the stupid yum/rpm/postinstall script system end up doing this? It is supposed to warn about conflicts if two packages ship different versions of the same file AFAICT, but there is no way the i686 and x86_64 versions of /boot/vmlinuz* could be identical. So there should have been a warning about this. And after that, how come the mkinitrd tool doesn’t even try to check wether the kernel architecture and that of the initrd binaries match? It happily packed 64bit binaries and 64bit kernel modules(sic!) when run against a 32bit kernel….

OK, enough of my frustration….
I really wished I had to maintain not RHEL/CentOS machines but Debian (based distro) machines here at work. Unfortunately, that won’t happen for various reasons…

While the bi-arch support in RHEL/CentOS is helpful in many ways, RPM and the way bi-arch works on these distros caused almost as much trouble to me already as it helped avoid.

2009-06-22

Another link collection 2009-06-22

Posted in Computers, Personal, PlanetDebian at 08:45 CEST (+0200) by sven

I seem not to post anything but links lately, but anyway,

Eddy Petrișor has a post about transitioning from lilo to grub2 (considering usage of LVM).

Romain Beauxis writes about what he dislikes about git (or probably most distributes version control systems) when it comes to team-maintained packages, to which Martin F. Krafft responded with an interesting post that puts some aspects of distributed versioning into a more balanced perspective then Romain had. After all though, I agree that there are uses to DVCSs which make sense (like being able to commit while not having any sort of connection to the “central” repository). However, I still think that relatively small “projects” like maintaining Debian packages have more to gain from the central repository then from the ability to commit while not connected. That is, at least as long as upstream doesn’t use a DVCS already, in which case there are other benefits from using the same DVCS, like easily pulling in upstream changes.

David Welton posted about a small script that swaps virtual desktops (please note that you will need to enable javascript to actually see the script).

While not technologically new to me, this post by David Pashley about copying files with netcat was a nice summarization of how to do it (and why it is sometime preferable over scp or rsync, plain or over ssh). One of the comments refers to mbuffer, which might also prove useful if you need really high speeds (>200MByte/s) or want some more advanced buffering options. The pv tool (alias Pipe Viewer) might be of interest to meter the throughput.

Phil Hands writes about getting an USB stick to boot (certain) ISO images with the help of grub4dos.

2009-05-18

Link collection 2009/05/18

Posted in Computers, Personal, PlanetDebian, Uncategorized at 14:06 CEST (+0200) by sven

  • Marco d’Itri about adding support for yet-unknown-to-kernel-drivers devices. More specifically: how to make udev tell ftdi-sio that it should accept a certain VendorID/ProductID combination in addition to previously supported ones.
  • Thomer M. Gil about ICMPTX, a combination made from proxy and server that tunnels IP through ICMP. Nice thing if you need a connection from some NATed and heavily firewalled location I guess. (Thanks go to Runa Sandvik for finding this.)
  • Non-technical in a way, but still a nice link: Image of the Shuttle transiting the sun, thanks to Pablo Lorenzzoni for this link.
  • Another post by Marco d’Itri that explains how to install Debian on a SheevaPlug. Not that I need this info now, but it might come in handy some day.

That’s it for now, will update the post if I find more interesting links in the next few days.

2008-10-08

How to solve a credit crisis …

Posted in Personal, PlanetDebian at 12:16 CEST (+0200) by sven

Anand Kumria wrote:

If IBM were to go bankrupt, would the government step in? Unlikely. Investors would lose (money), staff — another word for investors — would lose (jobs), but customers would win (their computers would keep working). Some customers would win more than others (especially those who had the equipment on lease); if no one is collecting, why pay?

I’m wondering here where Anand got the idea that once a company went bankrupt, that you don’t need to pay to that company anymore. When a company goes bankrupt, at least in Germany the following happens: A trustee/liquidator is selected. This liquidator is then collecting the information who owes money to the company and who still needs to get (how much) money from it. The liquidator also has to check the option of selling company assets (which might include the contracts of customers that still have to pay) to fulfill the debts of the bankrupt company. After he turned all assets into money, the money is distributed among those who still have to get money from the bankrupt company.

Anyway, regarding his main argument that the (average) customer of a company (bank in this case) should never have to pay for the failed speculations of that company, I somehow have to agree with him. Someone putting money into a regular bank account or papers with fixed interest rate should never lose his money. But there are also customers buying bank shares with a chance of higher revenue than with fixed interest rate papers. These should suffer from failure of the bank management, as they more or less explicitly wanted to be tied to the success (or failure) of the bank.

However, this is mostly irrelevant, since the failure of so many “investment banks” has side affects that might cost the average inhabitant of the affected countries even more than the discussed rescue plans. One of these effects is that the banks are now much more conservative regarding lease and mortgage plans, effectively leaving many home owners with no option to fulfill previous obligations (remaining debt after a previous mortgage expired can’t be refinanced by a new mortgage), causing them to have to sell their homes to pay the first mortgage. This is in some way stupid because this causes people who were perfectly paying their mortgage rates to loose their house, while the bank which would be giving them a new mortgage could get a new and good customer, improving their income. On the other hand, if the other side effects of the current crisis cause those “good” mortgage customers to loose their jobs, they might turn into bad customers who are unable to pay their rates. All in all, this is a spiral that could cause the whole economy to break down (a small example: The bank is not giving out mortgages, so no one will build new houses so the builders loose their jobs so they don’t pay their mortgage rates anymore,…. – over simplified, but still shows what I mean). Unless the spiral is terminated in time, before too drastic things happen.

All in all, I do understand why the politicians try to rescue those banks (or at least the customers of those banks), though I think that in an economy with slightly higher regulation, there wouldn’t be the need for such a rescue plan. I know there are some german banks affected by the crisis as well (among them Hypo Real Estate and others), but the average private customer of such banks shouldn’t loose money due to the regulations we have in place.

In general, there should be some security fund which makes sure that private customers never loose money put into regular bank accounts or fixed interest papers, vice-versa, banks should calculate mortgages so that they can be pretty sure their customers are actually able to pay off their rates – it doesn’t make sense if someone starts off having to pay 500$/month for their mortgage and has to pay over 1000$ a few years (as in 2-3 years) later, because the bank raised the interest that much. I have no problem with people loosing money from shares of banks or other companies directly or indirectly through investment funds.

2007-12-27

Köhler unterzeichnet Gesetz zur Vorratsdatenspeicherung

Posted in IT-Security, Personal at 16:24 CET (+0100) by sven


Stoppt die Vorratsdatenspeicherung - www.vorratsdatenspeicherung.de

Leider hat unser geschätzter Bundespräsident Köhler das Gesetz zur Vorratsdatenspeicherung unterzeichnet. Daher rufe ich hiermit jeden dazu auf, Widerstand gegen dieses Gesetz zu leisten. Wie man das (legal) machen kann, steht unter anderem auf o.g. Webseite.

2007-10-22

RE Anthonys “some fun” post

Posted in Personal, PlanetDebian at 13:56 CEST (+0200) by sven

I really dislike posts like (sorry AJ, you are just one example) AJ Towns blog post
“Some fun”. What I dislike? Well, the post lacks critical information: Which slashdot post inspired him? What data is he talking about? How did he turn the data into those graphics?

Sorry AJ, your post is just the latest example of this style of post, and I really got frustrated over such posts, this is not meant as a personal attack.

Edit:
So to make my wish clear: Please, fellow bloggers, don’t assume that your readers are following your favourite web resources as closely as you do (and with the same specific interests). Explicitly say what you are writing about, reference resources needed to understand what you are doing, at least give readers a chance to find out what you did.

In AJs case, it would probably have been enough to reference the /. article or comment which inspired him.

2007-10-17

CPU feature flags and their meanings

Posted in Computers, Personal, PlanetDebian at 15:03 CEST (+0200) by sven

Since I never really found a nice overview of which CPU flags (see /proc/cpuinfo) mean what, so I gathered some information using the web, with the most notable sources being the BOINC FAQ entry on CPU Register Acronyms at [1] and the output of the nice little (though seemingly mostly unmaintained) cpuid utility. See my results at [2]. Any suggestions for enhancements and completions are highly welcome, just leave a comment to this post.

[1]: href=”http://boincfaq.mundayweb.com/index.php?language=1&view=176
[2]: http://blog.incase.de/index.php/cpu-feature-flags-and-their-meanings/

2007-09-01

IFA – Force-Feedback-Vest with tickling attacks.

Posted in Personal, PlanetDebian, Random links at 14:18 CEST (+0200) by sven

In the recent online article heise online – IFA special – Force-Feedback-Weste mit Kitzelattacke, Heise News (a german IT news site) had a really nice caption under one image showing a new force-feedback vest by Philips. The image looks like this:
Image of the new Philips Force-Feedback Vest
The german caption is: “Philips’ Force-Feedback-Weste ermöglicht tödliche Kitzelattacken in PC-Shootern.”
Translation to english is: “Philips Force-Feeback-Vest allows deathly tickling-attacks in PC-Shooters.” (Means First-Person-Shooters).

Nice. That’s at least a pleasant way of dying: Being tickled to death.

Of course, the article itself clears up the misunderstanding: The vest is more tickling than “punching” the player, even if his game-ego is killing most ferociously.

2007-07-26

The DM GR

Posted in Computers, Personal, PlanetDebian at 16:03 CEST (+0200) by sven

Following up to Myon’s post, I also wanted to blog my honest opinion about the GR. Given my current understanding of the GR, I hope to see it fail (and will send my vote shortly after this blog entry I think). The reason is not that I think it shouldn’t be made easier to contribute to Debian (on the contrary). But the GR micro-manages too much and on the other hand doesn’t make the current NM process any easier for DM’s than for any non-DM applicant to the NM process. Also, like some others said before, I seriously doubt that a big part of the current DD-applicants (i.e. those in the NM queue at some level) would prefer DM status over DD status. And the same is true (IMHO) for other people wanting to contribute to Debian. This is a simple thing: If I contribute to something regularly in my spare time (like most contributors in the FL/OSS world do), I also would like to have some influence over its directions. And a DM is missing this influence even more than a DD is.

So what should be done instead in my opinion?
I think that a DM like status is fine as part of a (possibly re-designed) NM process. Given the current NM process, I would like people been given a DM like status after they finished the T&S (tasksIIRC and skills) part if their AM found their skills and knowledge of the policy rules sufficient to give them that status. If that is all they wanted, they can drop from the NM process at that point and stay DMs. If they want to become DDs later on, they can resume the NM process at that very step (or continue right ahead).

This would do several things:

  • introduce the DM status as an alternative to full DD status
  • integrate the DM status closer with the existing NM process
  • take some load of the friendly sponsors who upload non-DD packages now, giving them more time to help more new contributors
  • give people waiting for DD status some intermediate level at which they already can do more than before their joining of the NM queue

So I really think “more discussion” is the only valid option for me in this GR. If you want to change my mind: Please leave some feedback in my blog. Or give a precise (but brief) description why the current proposal is better than integration with the current NM process in one way or the other.

Abbreviations:

  • DD = Debian Developer (a full Debian project member, includes voting rights)
  • DM = Debian Maintainer (planned to be a somewhat restricted DD, among others without voting rights)
  • NM = New Maintainer (should actually be: New Developer)
  • GR = General Resolution (a way in Debian to create new rules or to ask the project leader or others in the project to do or refrain from doing something)

Update:
The GR even seems to contradict itself a bit. If the upload rules are applied in an AND fashion, one of these rules is superfluous (the first one), at least if I’m not mistaken:

  • the Maintainer: field of the uploaded .changes file corresponds with the owner of the key used (ie, non-developer maintainers may not sponsor uploads)
  • the most recent version of the package uploaded to unstable or experimental includes the field “DM-Upload-Allowed: yes” in the source section of its control file
  • the most recent version of the package uploaded to unstable or experimental lists the uploader in the Maintainer: or Uploaders: fields (ie, non-developer maintainers cannot NMU or hijack packages)

The first rules also means that no DM could ever do an upload for packages team-maintained in the fashion cyrus-imapd-2.2 is maintained (Maintainer address is the teams mailinglist address, all uploading team members are in the Uploaders field). This is IMHO a serious flaw in the proposal. If the first rule was dumped, all would be well for team maintainers.

2007-07-02

Improving graphs

Posted in Computers, Personal, PlanetDebian at 13:02 CEST (+0200) by sven

In Improving simple charts, Dirk Eddelbuettel wrote a nice little summary how to produce “nicer” charts using R. However, in my opinion, the charts he provided as alternate options to the original, purely linear graph are less readable for the average person. If anything, using a logarithmic scale on the original Y axis (number of packages not built after a specific date) would be of use, but the other graphs only hide the original point of the post Dirk replied to (How old are our (Debian’s) packages?). The point was that 94% of all packages had been rebuilt since the release of Sarge or, if you want to put it the other way around, 1264 (6%) were built before Sarge was released. This relationship is hidden from immediate recognition by the reader of the graphs. I admit though, that Dirk’s second graph (Number of packages against age in days with the age being on y logarithmic scale) is also insightful. The other two graphs he presents might make sense in a scientific publication if some point in the “more detailed” areas of the graph needs proving, but for this specific problem, they really don’t make sense to me. Actually, I would question their use even in scientific publications, since they distort the original data a lot. Scientists are pretty much used to logarithmic scales these days, but I couldn’t work out how the scales work on those two graphs. And another note on the second graph (logarithmic age): The way the X axis is labeled (10, 20, 50, 100,..) is also pretty non-intuitive to me. I’m much more used to something like 5, 10, 20, 40, 80, 160 and so on, which gives the same distance between each label and seems a lot more usable to me..

(edit: Fix spelling of Dirk’s surname)

« Previous entries Next Page » Next Page »