I never was really happy with my TLA as nickname -- but well, thl (from Thorsten Heiner Leemhuis oder Thorsten Leemhuis) was the thing that sprung to my mind when I needed a nickname for IRC. I actually tried to think about something else quite a bit of time back then, but I didn't find something better that was free, so I just started using thl.
But recently I thought again to look out for something else -- IRC once again was the trigger, as thl was owned by someone else on OFTC already (and there was actually somebody else on freenode that tried to use thl these days). So I searched for something else.
I considered "steinlaus" (Petrophaga lorioti), but that joke is hard to understand for people outside of Germany (I'm actually wondering how many Germans will understand it these days), so I took something more international.
Dienstag, 24. April 2007
Samstag, 14. April 2007
Evil?
'Our informal corporate motto is "Don't be evil."' -- that's written on the top of Google's Code of Conduct. Well, they managed that in the beginning imho when they were still a search engine and not much more. But they are becoming evil more and more in my eyes -- they were imho more then big enough already to be trusted and had much to much control over the Web already. Now they are buying DoubleClick. That really makes me anxious; where will that end? I'm starting to fear a Google controlled Internet where I can't visit a website without having "Big Brother Google" watching me. Just imagine what might happen if Google buys Microsoft (or vice versa); just a cooperation would be bad enough probably. <Prediction of the day>But I suppose Google will buy Canonical first</prediction of the day> ;-)
Google until now was one of the rare sides that were allowed to set cookies on my machine for more than one session as I had some settings saved that influenced what search results I get and how they are formated. That will change now. I'll probably look out for another blog hosting, too, and will try to get rid of gmail (which I'm using for jabber only anyway).
Google until now was one of the rare sides that were allowed to set cookies on my machine for more than one session as I had some settings saved that influenced what search results I get and how they are formated. That will change now. I'll probably look out for another blog hosting, too, and will try to get rid of gmail (which I'm using for jabber only anyway).
Donnerstag, 5. April 2007
exclude=*-devel.i386 [Update]
I'm normally trying to use the default software and settings my linux distribution provides as much as possible, as everything that one changes in my experience fires back sooner or later and requires manual adjustments (read: time) to make it work again; that makes slightly advantages often obsolete if looked back at the situation in retrospective later.
But well, today I made a big exception again. I added "exclude=*-devel.i386" to my /etc/yum.conf; getting all those *-devel.i386 packages by default really annoyed me, as I always forgot to add the ".x86_64" when running "yum install foo-devel". The download of those i386 packages consumes bandwidth and takes time; installing and updating the packages later takes even more time. And even worse: you end with lots of unwanted and unneeded userspace apps and libs for i386 as well, as the devel packages normally depend on them; those packages are not cached by rpmdev-rmdevelrpms either, so I end up with lots of cruft on my hardisk.
All this IMHO for a small benefit: to be able to develop i386 packages on a x86_64 host. How big is the number of users doing that? And does it really work in practice? A lot of configure scripts and apps (including rpm) in my experience seem to get confused if you try to compile something for i386 on a x86_64 host (even when remembering to use setarch). So it's really the best and the safest to use a chroot (e.g. mock) for this purposes as far as I can see.
So in other words: is installing *-devel.i386 packages on x86_64 really a sane default for Fedora? I really doubt it. It creates more trouble for the growing number of x86_64 users and makes it a slightly bit easier for only a small group of users. I'm really wondering if it would be better to have those *-devel.i386 packages in a separate Fedora-add-on repository that people just can enable if they really want them.
[Update] Seems I need to clarify something, as I got two comments on this blog now, and it seems both users got tracked into the wrong direction. Rahul for example wrote:
>> All this IMHO for a small benefit: to be able to
>> develop i386 packages on a x86_64 host
> This is not the primary benefit. The primary reason
> is that there is a number of third party software that
> are still 32 bit and multi lib by default helps them
> work better without fiddling.
You got me wrong here. I'm all for having .i386 libs and maybe even some i386 apps (like firefox) in the repo, because (as your write) they are needed for third party software (for example). I was taking about the *-devel.i386 packages only.
But well, today I made a big exception again. I added "exclude=*-devel.i386" to my /etc/yum.conf; getting all those *-devel.i386 packages by default really annoyed me, as I always forgot to add the ".x86_64" when running "yum install foo-devel". The download of those i386 packages consumes bandwidth and takes time; installing and updating the packages later takes even more time. And even worse: you end with lots of unwanted and unneeded userspace apps and libs for i386 as well, as the devel packages normally depend on them; those packages are not cached by rpmdev-rmdevelrpms either, so I end up with lots of cruft on my hardisk.
All this IMHO for a small benefit: to be able to develop i386 packages on a x86_64 host. How big is the number of users doing that? And does it really work in practice? A lot of configure scripts and apps (including rpm) in my experience seem to get confused if you try to compile something for i386 on a x86_64 host (even when remembering to use setarch). So it's really the best and the safest to use a chroot (e.g. mock) for this purposes as far as I can see.
So in other words: is installing *-devel.i386 packages on x86_64 really a sane default for Fedora? I really doubt it. It creates more trouble for the growing number of x86_64 users and makes it a slightly bit easier for only a small group of users. I'm really wondering if it would be better to have those *-devel.i386 packages in a separate Fedora-add-on repository that people just can enable if they really want them.
[Update] Seems I need to clarify something, as I got two comments on this blog now, and it seems both users got tracked into the wrong direction. Rahul for example wrote:
>> All this IMHO for a small benefit: to be able to
>> develop i386 packages on a x86_64 host
> This is not the primary benefit. The primary reason
> is that there is a number of third party software that
> are still 32 bit and multi lib by default helps them
> work better without fiddling.
You got me wrong here. I'm all for having .i386 libs and maybe even some i386 apps (like firefox) in the repo, because (as your write) they are needed for third party software (for example). I was taking about the *-devel.i386 packages only.
Abonnieren
Posts (Atom)