Upgrade to Fedora 17...

I upgraded to Fedora 17 using preupgrade tool few days ago. This is writeup with experiences of that process. Maybe it helps someone out there... :)

As I didn't want to reinstall everything from scratch, I decided to use preupgrade tool. Additional benefit of this tool is that it first downloads all the necessary packages and then start the upgrade proces. So, I started preupgrade in a mid of the day and it started to download all the necessary packages. Then, it asked me to reboot machine in order for upgrade to start. Since there were over 6000 packages to upgrade I decided to start the upgrade process in the evening when I' going to sleep so that the next morning the laptop is ready for use. Thus, I declined upgrade at that moment and continued to work as normal.

In the evening I started again preupgrade tool. This time, for some unknown reason, it complained because of third party repositories I'm using (more specifically, because of rpmfusion). So, I disabled all but Fedora's repositories and restarted preupgrade. Well, it went almost without any problem. The only thing that happened is that installer stuck somewhere around 1/3rd of the installation process and I only discovered it when I woke in the morning. After reboot it continued as if nothing happened so the only consequence was that I had to wait in the morning for it to finish. Otherwise, everything was OK.

Next, I decided to recompile OMNeT++ since I'm using it for some simulations. I'm using the newest version, 4.2.2. There was a minor problem because of newer gcc (it is 4.7.0) but quick googling gave solution immediately. It could be that if you are using some older version you'll have much more problems because of changes in the C++ compiler shipped with Fedora.

Then, I started yum in order to see what new gnome-shell plugins are available. As I started installation of one plugins, after the installation finished, yum showed a lot of errors like the following ones:

389-ds-base-libs-1.2.11.1-1.fc17.x86_64 is a duplicate with 389-ds-base-libs-1.2.10.6-1.fc16.x86_64

ConsoleKit-0.4.5-2.fc17.x86_64 has installed conflicts filesystem < ('0', '3', None): filesystem-2.4.44-1.fc16.x86_64

Obviously, something went wrong with preupgrade process. So, first I tried package-cleanup tool, but without any success. It wanted to remove packages, which a) isn't what I wanted, and b) it didn't managed to remove them anyway. Then, I tried recipe from this link. That one didn't work either. So, I ended up manually removing packages with yum and then installing them again. This took me several hours, not the best way to spend your time.

Finally, after solving that problem everything else seems to work. There is one thing that annoys me. gnomines is very slow to react on clicks. At the initial opening it takes 1 or 2 seconds to start, and after each click there is a noticeable delay. I don't know what causes it, but I certainly do hope that they will fix it soon. :)

Update 1 [20120605]
Ok, there is one additional issue I found out. But this one occurs every time I install new version of Fedora, so I already know what to do. :) Namely, if you are on a network where domain name ends in .local (e.g. server.local.) then DNS is not invoked but mdns4 is used. This is manifested in a way that those servers are inaccessible with a message Server not found, or something similar. Anyway, the root cause is in the file /etc/nsswitch.conf, i.e. the line that defines how host names are resolved is set to:

hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname

you should remove mdns4_minimal and the content within square brackets, so it should look like this:

hosts:      files dns myhostname

And that's it!

Update 2 [20120614]
Well, it seems that VMWare Workstation isn't working with a new Fedora. I'm using kernel 3.4.0-1.fc17.x86_64. Anyway, when I start vmware, it tells me that it has to configure vmware and then, during build process, the following error while building blocking FS appears:

make: Entering directory `/tmp/vmware-root/modules/vmblock-only'
make -C /lib/modules/3.4.0-1.fc17.x86_64/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/kernels/3.4.0-1.fc17.x86_64'
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/dbllnklst.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/file.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/block.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/inode.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/super.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/control.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/filesystem.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/module.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/stubs.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/dentry.o
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c: In function ‘FsOpReadSuper’:
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c:528:4: error: implicit declaration of function ‘d_alloc_root’ [-Werror=implicit-function-declaration]
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c:528:15: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[2]: *** [/tmp/vmware-root/modules/vmblock-only/linux/filesystem.o] Error 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmblock-only] Error 2
make[1]: Leaving directory `/usr/src/kernels/3.4.0-1.fc17.x86_64'
make: *** [vmblock.ko] Error 2
make: Leaving directory `/tmp/vmware-root/modules/vmblock-only'

The solution for this I found here. Basically, the function d_alloc_root has been renamed to d_make_root and that search/replace operation should be done within the archive vmblock.tar (in /usr/lib/vmware/modules/source/). Actually, there is only one occurence of d_make_root in file linux/filesystem.c.

Update 3 [20120822]
I had problem with Python setuptools because of upgrade. See here for details.

Vrlo zanimljiv slučaj u vezi sigurnosti korisnika...

Dakle, desio se jedan vrlo zanimljiv slučaj u kojemu je nešto napravljeno kako bi se korisnici zaštitili a korisnici su optužili krivu tvrtku. Istovremeno, Microsoft nije ništa napravio i u očima korisnika on je bolji, iako je te iste korisnike ostavio na cjedilu!? Zvuči zanimljivo, zar ne?

Dakle, da opišem malo konkretnije što se desilo, samo što ću naravno izbaciti iz priče konkretna imena kako bi zaštitio nedužne (tj. sebe :)).

Dakle, u Oracleovoj Java implementaciji otkriven je ozbiljan propust koji omogućava vrlo jednostavno kompromitiranje računala. Iz tog razloga Mozilla je odlučila onemogućiti Java podršku u Firefox pregledniku. Ako se pitati zašto, odgovor je zato što preglednik ne može forsirati korisnika da nadogradi Java okruženje. Ono što može je spriječiti korisnika da koristi Java Applete dok dotični ne nadogradi Javu.

Međutim, što korisnici znaju o Java programskom okruženju. To je retoričko pitanje jer odgovor je jasan kao dan i glasi: ništa! Ono što oni znaju je da koriste aplikaciju od Jedne tvrtke (TM) - primjetite veliko početno slovo. Ali ne znaju da ta aplikacija ovisi o Javi. U biti, još ljepše je što ti dijelovi koji ovise o Javi nisu nastali unutar Jedne tvrtke, već su kupljeni od Druge tvrtke (TM) - opet, primjetite veliko početno slovo. Uglavnom, aplikacija na Firefox pregledniku odjednom ne radi i eto hrpe gnjevnih korisnika koji optužuju Jednu tvrtku. Međutim, Druga tvrtka nije samo Jednoj tvrtki prodala svoje Java rješenje, prodala je i trećim tvrtkama. Pratite me? :) Ali tim trećim tvrtkama i dalje aplikacije rade, a rade zato što oni svojim klijentima kažu da koriste Internet Explorer koji bez ikakvih problema izvršava ranjivo Java okruženje.

Uglavnom, rezultat su gnjevni korisnici Jedne tvrtke koji su istovremeno zaštićeni, i sretni korisnici trećih tvrtki koje nije briga za vlastite korisnike i koji su ranjivi, a vjerojatno dobar dio njih i zaražen na neki način. Zanimljivo, zar ne. :)

A naravno, tu je i Druga tvrtka koja da iole malo drži do svojih korisnika, direktnih i indirektnih, dobro bi razmislila može li eliminirati Java programski jezik iz svojih proizvoda. U biti ne samo to, ta tvrtka bi obavijestila svoje klijente o navedenom propustu. Ali Drugu tvrtku brine samo profit, moguće i da je nekompetentna (u to neću ulaziti sada) i rezultat je jedan veliki krš i lom!

Power supplies...

Have you ever asked yourself how the power supply within you computer works? How complicated it is? Or how did it develop? I never did. For me, it was a black box that takes 220V (or 110V, depending where you live) on input and produces 12V/5V on output. Basically, you don't notice that they exist, but now and then you have some problems caused by them, e.g. when they fail, or when they are not powerful enough.

Today I stumbled on this article about power supplies. I have to say that it is well research article about modern power supplies. It was motivated by Steve Jobs' claim that the power supply within Apple ][ was revolutionary and that the guy that designed it, Rod Holt, didn't get a credit for it. So, the blog's author did an extensive research and found out that Jobs wasn't right. Anyway, I recommend that you read that post, it's very good with a lots of references.

It's interesting how I came accross that post. Initially I stumbled upon a post on Hacker News about some guy that left Google and this Guy explains why. Now, there are different opinions about this topic and maybe I write about it in the future, in the mean time, I found this post about power supplies to be rather interesting.

One more thing. That guy that wrote post about power supplies also wrote a post about iPhone USB charger that he bought cheaply in eBay. What's interesting is that this charger almost certainly doesn't follow safety regulations which means that you can suffer electrical shock. So, don't save money on something that can endanger your life!