Thursday, February 27, 2014

Poticanje ljudi na odlazak iz Hrvatske - piljenje grane na kojoj sjedimo...

Često čujem kako netko potiče ljude da se javljaju na oglase za poslove van Hrvatse te ih dodatno potiču na taj korak odlaska. Moram priznati da me to većim dijelom zabrinjava, čak užasava, a jednim malim dijelom i nasmijava. Zadnji primjer, koji me je na kraju i nagnao da napišem ovaj post, je sljedeći:


Moram odmah istaknuti kako se u ovom konkretnom slučaju radi o računalnim stručnjacima, no sve se to može, a i mora, primjeniti i na ostali visoko obrazovani kadar.

Dakle, zbog čega me to zabrinjava, a i nasmijava? Pa, da bi se to shvatilo nužno je prvo razjasniti različite perspektive iz kojih se to može gledati, ili drugim riječima, različite dionike (engl. stakeholders). Naime, o perspektivi ovisi što je istina, i kao što je odmah jasno, očito je da postoji više istina. Pri tome, nepobitna je činjenica kako se svaki od dionika mora voditi svojim vlastitim interesima. To je na kraju krajeva, jedino racionalno ponašanje.

Dakle, dionici, odnosno perspektive su:
  1. Osoba koja odlazi van.
  2. Osobe/ljudi koji ostaju u Hrvatskoj.
  3. Osoba koja potiče ljude na odlazak van. Ova kategorija se nadalje može podijeliti na one koji potiču i vani su, te oni koji potiču i u Hrvatskoj su.
  4. Tvrtka koja je vani i traži zaposlene.
Ostatak teksta ću, dakle, podijeliti prema svakoj od tih dionika, te sagledati situaciju iz perspektive svakog od njih. Ključni dio je druga točka, otisnuta masnim slovima, i ako ne čitate pretjerano detaljno ovaj post, ipak bi preporučio da na tu točku obratite pozornost jer je u njoj suština ovog posta.

Primjetite inače da mi klasifikacija nije savršena jer postoji određeno preklapanje. Međutim, nemam niti volju niti namjeru učiniti tu klasifikaciju savršenom. Bitna je poanta koju želim poručiti i mislim da će ova klasifikacija za to biti sasvim odgovarajuća.

Osoba koja odlazi van

U ovom slučaju, nemam što komentirati. Budući da svatko gleda svoj interes, tako i svaka osoba može i mora za sebe odlučiti i odvagati koje su najbolje opcije i postupiti shodno tome.

Možda bi samo kao malu digresiju  mogao reći kako je problem da odlaze van osobe kojima je i u HR dobro, a one kojima je u HR loše, ostaju u HR. Naravno da to nije apsolutno pravilo, ali, mislim da prosjek jako dobro reflektira to što sam rekao. I ta činjenica je bitna, ali tek u kontekstu iduće točke...

Ljudi koji ostaju u Hrvatskoj

Ovdje bi se moglo napraviti daljnje raslojavanje i detaljnija analiza, ali nema potrebe jer stvar je vrlo jednostavna. Naime, ovu grupu bi najbolje mogao opisati kao ekipu koja sjedi na grani, nekolicina reže tu granu, a ova grupa se ponaša kao da ih nije briga. U biti, i nije ih briga jer nemaju pojma.

Koji su razlozi zašto to tako tragično doživljavam:

  1. Novci poreznih obveznika su utrošeni na školovanje tih ljudi, i to ne mali. Dakle, porezni obveznici bi mrali biti zabrinuti kamo se bacaju njihovi novci!
  2. Stručni, obrazovani ljudi su ono što pokreće moderne ekonomije. Hrvatska, odlaskom takvih ljudi, ostaje na ljudima sa srednjom stručnom spremom i prema tome osuđena je na propast.
  3. S takvim odljevom trebali bi se zabrinuti tko će školovati buduće generacije, a također, trebali bi se zabrinuti tko će nas u budućnosti liječiti, ili tko će nam  zarađivati penzije.
  4. Sposobni ljudi čine okolinu koja napreduje, i vuče sve za sobom. Ako nema sposobnih ljudi, nema ni napretka okoline.
Mislim da su to vrlo jaki razlozi zašto nikome normalnome ne bi smjelo pasti na pamet da potiče ljude na odlazak van. 

Kao jedan zanimljiv primjer spomenut ću moj rodni grad, Viroviticu. Naime, iz Virovitice mnoštvo srednjoškolaca je otišlo na studij u Zagreb, Osijek, Rijeku. No, jako malo se i vratilo nazad. To je slučaj barem od kad sam ja otišao na studij. Rezultat je taj da Virovitica, kao i velika većina Hrvatske, stagnira i vrlo vjerojatno se nalazi u fazi kada povratak više nije moguć. Dakle, to će se desiti i Hrvatskoj.

Osobe koje potiču na odlazak i nisu u Hrvatskoj

Tu nemam što dodati, osim da tim ljudima nije ni u džep ni iz džepa to što će tamo netko iz neke države otići, i na taj način osiromašiti tu državu. Koji su motivi te ekipe, teško je reći.

Osobe koje potiču na odlazak i jesu u Hrvatskoj

Za njih mogu reći sve što sam rekao i za one koji ostaju u Hrvatskoj, jedino što su ovi oni koji pile granu i/ili navijaju da se grana što prije prepili. Dakle, šutljiva većina nanosi štetu svojom neaktivnošću i nerazumijevanjem, ovi nanose najveću štetu i trebalo bi ih javno osuditi u novinama. No, kad smo već kod toga, ni novinari previše ne kuže.

Trtvke koje su vani i vrbuju 

One imaju i te kakvu korist od ljudi koji dolaze jer, obično, u svojoj okolini ne mogu pronaći dovoljno kadra. To je sigurno tako za Silicijsku dolinu, Irsku, ali i niz drugih država/regija gdje se nalazi skoncentrirana nekakva industrija, a lokalna okolina nije u mogućnosti pružiti dovoljno ljudskih resursa.

Sunday, February 23, 2014

Kernel upgrade to 3.13.3-201 and VMWare Workstation...

I just started VMWare for the first time after upgrade and restart into kernel 3.13.3-201, and it didn't work. Well, I already got used to it. Anyway, the fix was very quick. I found a patch in a post on VMWare forums, downloaded it and applied it. The application process is a bit more manually involved that with the previous patches. You need to:

  1. Switch to root user.
  2. Go to the /usr/lib/vmware/modules/source directory
  3. Unpack vmnet.tar using tar command.
  4. Enter into newly created vmnet-only directory
  5. Apply patch (patch -p1 < path_and_name_of_unpacked_patch_file). Patch shouldn't make any noise, only patched file is displayed.
  6. Go one level up (exit vmnet-only directory)
  7. Rename existing vmnet.tar into something else, just in case.
  8. Create new vmnet.tar (tar cf vmnet.tar vmnet-only)
  9. Start vmware
And that's it...

Saturday, February 22, 2014

Messing up Zimbra upgrade, a.k.a. dangerous --platform-override option...

You know that Zimbra's installer has --platform-override option that enables you to install Zimbra on unsupported platforms, like CentOS. Well, it also allows you to mess up things. Namely, I downloaded Zimbra for RHEL6, but was upgrading an existing installation on CentOS5. And I didn't noticed anything unusual until upgrade process failed! It failed very early with an error message from loader that it couldn't start perl binary. Namely, the error message I got, was similar to:
/usr/bin/perl: symbol lookup error: /opt/zimbra/zimbramon/lib/i386-linux-thread-multi/auto/IO/IO.so: undefined symbol: Perl_Tstack_sp_ptr
It wasn't exactly that one, but similar! Well, I was surprised because Zimbra's upgrade process is good and robust, and I had never problems with it, but since I had some local customizations on my installation I suspected those to be the cause. So, I ended up by copying CentOS' Perl installation into Zimbra tree. This process wasn't actually so easy to do and that should've warned me that something is terribly wrong, but I continued nevertheless. But, when I managed to pass that point, the next one finally made me realize the mistake. Namely, mysql binary required Glibc 2.7, while in CentOS 5 is some earlier version. Now, I knew what mistake I've made.

Here is also a point I realised that I'm facing a long night trying to recover Zimbra installation!

So, I've downloaded the correct version of Zimbra, the one I intended to upgrade to, manually installed it using rpm tool, and then restarted upgrade process with:
/opt/zimbra/libexec/zmsetup.pl
And here my problems continued. Namely, the upgrade script correctly figured that I'm trying to upgrade, it also correctly figured the old and the new version, but it stuck on starting mysql server. After some time I managed to figure out where the problem is, namely, existing mysql database has password while the installation process assumes there isn't one. So, it couldn't determine if mysql was started or not, and everything stalled. I lost some time trying to make database not to ask for the password, and even though I managed to do something, luckily, in the mean time I stumbled on the following Wiki page:
Recovering from wrong platform upgrade
I made it large because it really got me out of the problem. It is written for version Zimbra version 5, but it works on 7, too. In a nutshell, you install the old Zimbra versions you had and then start from there with the idea of making a rollback. BUT, BIG WARNING, this is possible only if your localconfig.xml file is intact. In my case, I erased it, but the upgrade process saved a copy which I was able to recover! I had some additional problems while testing installation as suggested byt the Wiki page, but all of them were related to the tweaks I did to my installation of Zimbra, i.e. binding Zimbra to a single IP address.

What have I learned

Well, first and foremost, do a backup before doing an upgrade. Yes, I know it was stupid, and beginner's, mistake, but as I've said, Zimbra's upgrade process is really good, at least for me. The real reason I didn't do it was that it takes several hours to make it. If I had copy, I would revert to that copy, and I would only need to fix RPM database. So, to avoid the same thing happening again, now I did make a backup process which rsync'es all of Zimbra tree to an alternative location every day.

Next thing is, localconfig.xml file is extremely important, so I did additional backup of that file, too. Note that in the file are all passwords so, it's also critical from the security perspective!

Also, I would suggest that Zimbra adds checks into installation script to guard against mistakes like the one I did. It turns out, after some googling, that there are a lot more other posts with the similar problems. This can be easily done for CentOS/RHEL with appropriate requirements in RPM packages.

And for the end, here is one other story about failed Zimbra upgrade which I find interesting.

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)

Blog Archive