In Ubuntu 10.04 – due to be released on late April of this year – the window buttons (close, maximize,minimize) will be on the left side of the window! See here for the branding screenshots.

In the previous release, Ubuntu already changed the order of the minimize and maximize buttons so instead of the MS-Windows-like order (minimize, maximize, close) Ubuntu has been putting the maximize button first. A minor change but it looks now to be a preparation to this very major change – starting with the next version, all the buttons are moving to the left side, like in Macintosh:

And just to compare, here’s the MacOS X implementation:

Care to tell the difference?

OK, on the Mac, the button order is reversed then in the new Ubuntu: close, minimize, maximize. So I’m not really sure what’s going on.

Anyways, quite likely people who are used to Ubuntu, other Linux desktops and even MS-Windows are all going to hate this setup, and there is no configuration option to turn this off – this is the Ubuntu way, so so either suck it up or change your operating system.

Or you can start messing with GConf (GNOME’s configuration system which is very much like the MS-Windows registry). If you do want to upgrade to the latest Ubuntu and keep your window buttons where you are used to, you can install the GNOME configuration editor (“Configuration Editor” in Ubuntu’s Software Center, or “gconf-editor” in Synaptic), look under /apps/metacity/general for button_layout, read its help description and modify what you want.

Or if you want to just go back to the old behavior without messing with stuff, follow these easy steps:

1. Invoke the run dialog by pressing ALT-F2
2. In the command text, put this: gconftool -s /apps/metacity/general/button_layout -t string "menu:maximize,minimize,close"
3. Click on “Run”

Your windows buttons should now immediately revert to the old setup. If you ever want to try the new setup again, use this command: gconftool -s /apps/metacity/general/button_layout -t string "maximize,minimize,close:".

Related articles by Zemanta

• Ubuntu dumps the brown, introduces new theme and branding (arstechnica.com)
• Ubuntu Gets New Themes, Logo, Boot Screen, Indentity and So Much More! (omgubuntu.co.uk)
• Ubuntu Lucid Lynx changes its spots (go.theregister.com)

עד עכשיו הסתכלתי על זה בצורה מאוד משועשעת – מה חושבים להם האמריקאים האלה עם השטויות שלהם, שהרי בארצנו לעם היהודי (אור לגויים כאמור) אין בעיות עם שטויות שכאלה: נהוג אצלנו חינוך למדע וכולם יודעים שאבולוציה זו הדרך הנכונה לתאר את התפתחות החי והאדם בכדור הארץ. כל זאת למרות, ואולי בגלל, הדת היהודית שהיא בסופו של דבר המקור לכל השטויות של האמריקאים.

אבל מסתבר שזה לא בדיוק המצב בארץ, וגם אצלנו כדאי לשים לב למה שקורה בנושא של אנשים המתיימרים להיות מדענים ומצד שני להטיף לראיה של העולם כפי שכתוב בספר בראשית: כפי שנכתב בכתבה מה-21 לפברואר בהארץ, המדען הראשי החדש של משרד החינוך הישראלי – ד”ר – גבי אביטל – מצוטט אומר דברים קשים מאוד נגד מוסכמות מדעיות ברורות כמו אבולוציה והתחממות גלובלית, והנה כמה ציטוטים נבחרים:

אם בספרי הלימוד יכתבו באופן מפורש שמוצא האדם מהקוף – ארצה שהתלמידים ייחשפו לדעות אחרות ויתמודדו אתן. יש הרבה אנשים שלא חושבים שתורת האבולוציה היא נכונה”

וגם:

“יש כאלה שעבורם האבולוציה היא דת והם לא מוכנים לשמוע שום דבר אחר. חלק מהחובה שלי, במסגרת תפקידי במשרד החינוך, היא לבדוק את תוכניות הלימודים וספרי הלימוד”

ואפילו:

“כל הסממנים של דת פנאטית נמצאים שם [בארגוני ירוקים] – קנאות והרבה רוע. הירוקים אומרים ש’יישרף העולם – רק שיהיה ירוק’ [...] כדור הארץ לא הולך להיות מושמד. הקב”ה הבטיח לנו…וההשפעה של האדם היא זניחה”

נראה שהד”ר הנכבד לאוירונאוטיקה גבי אביטל, אדם דתי לפי הצהרתו, לא מחבב את “מאמיני דת האבולוציה” כהגדרתו, אבל לא ברור מה הבסיס המדעי שהוא עומד עליו בהצהירו “מדע הביולוגיה … יסודותיו עומדים על כרעי תרנגולת”. וזהו האחראי על החינוך למדעים במדינת ישראל. נראה שזה עוד תחום שבו האמריקנזיציה פושה במחוזותינו.

Related articles by Zemanta

• Bible Translation Wrong – God Didn’t Create The Earth Says Academic (dvorak.org)

בגרסה שלי הולכים ל-AM:PM וקונים שימורי חומוס שתי קופסאות מתאימות לארבעה אנשים וכל שאר הכמויות זה לפי זה.

בשביל לעשות את המרק קצת יותר מעניין – וסמיך – למרות ההתחלה “הבעייתית”, אני מוסיף תפוחי אדמה וחברים – בטטה הולכת טוב, כמו גם ארטישוק ירושלמי (למה באמת קוראים לזה ככה, זה ממש לא נראה כמו ארטישוק) או קולורבי.

נתחיל עם כך בשני תפוחים אדמה מקולפים, כשאפשר להחליף את אחד התפוחים במשהו אחר מקביל. אני כפי שציינתי מעדיף בטטה או קולורבי. נחתוך לריבועים של כס”מ ונבשל בסיר עד שהם קצת מתרככים (משהו כמו 20 דקות על אש גבוהה).

עכשיו נסנן את התפוחים ונחזיר אותם לסיר (המים של הבישול הראשון מכילים הרבה עמילן מתפוחי האדמה שזה לא טעים) ונוסיף להם את החומוס – בלי המים מפחיות השימורים, אין לי עניין בהן ואני שופך אותם לכיור. עכשיו צריך להוסיף מים עד שהירקות מתכסים ועוד קצת. ולהביא לרתיחה.

תוך כדי שהמים מתחילים להתחמם, נתחיל לתבל – אני מוסיף:

• שום קצוץ והרבה – מסתבר שעשרה שיני שום לא ממש מורגשות, אז אם אתם אוהבים שום אפשר להוסיף יותר.
• כף כמון (לא להתבייש – שימו כף שלמה, מתי יוצא לכם לשים כף של כמון בתבשיל?)
• חצי חף חוויאג’ למרק
• חצי כף כורכום (כן, המרק הזה הולך לצאת צהוב)
• קצת פלפל וקצת מלח
• כף אבקת מרק עוף או משהו דומה – אם יש לכם ציר אז אפשר, אבל כנראה עדיף לשמור אותו למשהו שבו זה באמת יעשה הבדל. צימחוניים יכולים להשתמש באבקת מרק “בטעם עוף”.

המרק מוכן כשהתפ”א מתפרקים בקלות אם לוחצים עליהם עם כף והחומוס כבר מתחיל להפרק לבד. בשלב זה אפשר להוסיף למרק חופן כוסברה או פטרוזיליה קצוצה ולבשל עוד כעשר דקות – זה נותן למרק קצת טעם “ירוק”.

לבסוף נטחן חצי מהמרק כדי לתת לו סמיכות ומרקם כמו שאני אוהב (אני לא אוהב מרקים מימיים מדי). במתכונים בד”כ תמצאו הוראות כמו למזוג חצי מהמרק למעבד מזון – זה הרבה יותר מדי עבודה שבלנדר יד ישר בתוך הסיר יכול לחסוך (שלא לדבר על החסכון בניקיון אחר כך), הבעיה היא איך למנוע מכל התוכן של המרק להטחן. כדי לטחון רק חלק מהתוכן של המרק אני פשוט מפריד בין החצי שאני רוצה לטחון לחצי שאני לא רוצה ע”י זה שאני שם מסננת קטנה שתחסום מהבלנדר לשאוב את כל המרק אליו, או אפשר להשתמש בשלוש כפות שמחזיקים כמו מניפה.

בשביל עוד ניקוד אפשר לטגן בצד עוד כמה שיני שום ובצל או כרשה עד שהשום שחום מכל הצדדים ולזרוק את זה לתוך המרק בסוף (לפני או אחרי הטחינה). בתאבון.

זהירות ספויילרים (קראו אחרי הסרט)
חומרה מדהימה – כנראה שהיא עדיין עובדת בגלל שהיא לא דיגיטלית או אפילו אלקטרונית.

אני חושב שהמציג, פריק-מונקי, קצת פישל בכך שהוא לא הריץ PPP על גבי החיבור וניגש עם דפדפן מקומי, אבל זה כנראה היה מאריך את הסרט בעוד 10 דקות ומעבר לגבול שיו-טיוב מרשים

So here’s why I won’t buy this (or the Nexus One, or the Motorola Milestone which I was very much interested in): No Bluetooth Dial-Up Networking.

Apparently, something that I’ve taken for granted with my 3 years old Nokia and Sony-Ericsson phones is sorely missing on Android, even with 2.1. Supposedly you can get it to working by installing some 3rd party applications (that cost extra), but its hardly the experience I expect from a network enabled “superphone” released in the year 2010.

Other things I require in my most important communication device:

• Ability to install 3rd party applications (so no Blackberries. Yes, I know they have 3rd party applications, but there are about 10).
• E-Mail push with standard IMAP servers (so no Blackberries, Maemo, or iPhone. Also most Nokia devices won’t do it).
• Bluetooth object exchange (so no iPhone or Palm Pre – because these US oriented devices won’t let users transfer files to the device so they will have to buy their ringtones from the network provider).
• USB mass storage emulation (again, no iPhone).

On another note – one thing that totally irks me in the current “hip” discussions about phones is the iPhone-envy: everyone talks like the iPhone is maybe the biggest market holder, or possibly its the RIM Blackberry or the Windows Mobile.

Which is all a load of horse shit – Nokia sells more devices then anyone even though its uncool to talk about their very very useful Series 60 based smart phones. If you look at the article linked below – the one about SE hoping to get bigger in the US, and read through to the market share analysis you’ll see what I mean: SE is the 4th largest phone provider in the world 14.6 million units shipped in 2009Q4 – who is ahead of them? Is it Apple or RIM? No – its Nokia, LG and Samsung. And fifth place is Motorola.  All the so called iPhones and Blackberries are niche players.

Related articles by Zemanta

• Sony Ericsson turned down the Nexus One (mobilecrunch.com)
• Sony Ericsson hopes to get bigger in the US with new touch-screen phones (taragana.com)
• MWC 2010: The Year of The Android (wired.com)
• 2009 Smartphone Stats Worldwide, Nokia and Symbian dominate but competition is fierce (allaboutsymbian.com)

בגדול קשה להרוס עוף בתנור – קחו כרעי עוף, סדרו בתבנית,קחו כמה מרכיבים שנשמעים הגיוניים ביחד (כמו שזיפים ורוטב רימונים, דבש וסויה או דבש וחרדל, אולי קטשופ וחרדל? ) ערבבו ושפכו על העוף ושימו בתנור לשעה. הנה הגרסה שלי למשהו קצת יותר מעניין:

המצרכים:

• עוף. לצורך הנושא השתמשתי בשתי כרעיים שלמים, אבל אני מניח שאפשר להשתמש בחלקים אחרים, אבל המידות להלן זה לשתים או שלוש כרעיים

לרוטב:

• שני תפוחים
• טבעות אננס, משתי פחיות שימורים קטנות – מעבר לכך שאננס טרי טוב קשה להשיג וקשה להכין (ואני עצלן), אני משתמש במי האננס לרוטב. אני מעדיף את הגירסה של Dole שניתן להשיג ברוב הסופרים בארץ כי היא מכילה רק אננס (בלי סוכר או חומרים משמרים ). אם יש לכם קופסה גדולה כמו בתמונה בקישור להלן, אז אני חושב שאפשר להשתמש בחצי מזה.
• בצל
• רוטב טריאקי

ההכנה כפי שציינתי היא די פשוטה: חצי בצל וחצי תפוח אני טוחן בבלנדר ומוסיף לתוך זה את המיץ מקופסאות השימורים של האננס וחצי כוס טריאקי. הרוטב צריך לצאת יותר “מימי” מ”משחתי” אז אם צריך (תלוי במידת הסמיכות של הטריאקי) אני מוסיף מירין. זה הרוטב – אפשר להוסיף עוד קצת תיבול, לדוגמה אני מוסיף חצי כפית חרדל וקצת זנגביל (מיובש לאבקה או גרוס טרי) בשביל לתת לרוטב קצת “שפיץ”.

את שאר התפוחים אני פורס לשמיניות ואת הבצל לפרוסות לאורך (כמו פלחים של תפוח, בעצם) ומסדר בתבנית בין חתיכות העוף (מי שרוצה יכול להפריד את הכרעיים לשוק וירך מראש). על כל זה להניח מעל את טבעות האננס ולשפוך את הרוטב ולהכניס לתנור מחומם מראש לכ-200 מעלות.

האוכל צריך להיות מוכן תוך שעה וחצי בערך, אבל אל תסמכו עלי ותבדקו.

In the mean time, if you want to run something a bit more modern maybe you’d want to upgrade your CentOS installation to Fedora 12 which can be considered pretty stable after a few months on the market. The reasons for the change may be numerous – maybe you need to run the latest subversion (with better merge tracking) or a new version of Ruby. Either way, if upgrading from CentOS 5 to Fedora 7 was a pain, guess how it is more the two years later?

Before we get to the action itself, I would be remiss if I would not recommend you to reconsider what you are about to do – this is a challenging exercise for many system admins and can sometimes end badly. I do not guarantee anything and if it breaks you get to keep both parts. Often its much faster and easier to just go to the server, stick a Fedora 12 DVD in the slot, reboot and let the DVD upgrade your system. That being said, this is fun if you’re into that sort of thing, so if you’re still with me, lets dive in!

So Bring On the Pain

We’ll start with a fully updated CentOS 5.4 – there’s no reason for getting more pain then necessary, and upgrading a CentOS 5.3 or earlier to 5.4 is painless – just run yum upgrade -y and grab yourself a cup of coffee (notice that we use “upgrade” and not “update” – theoretically this may result in old packages being removed, so pay attention, but from my experience EPEL based distributions are very stable and do not normally get stuff obsoleted during a major version’s lifetime). Upgrading will also usually install a new kernel, so if that happens please do a reboot before continuing. Important: This is also a good time to disable SELinux if you have it in “enforcing” mode – after the upgrade the security labels will be in a mess and with SELinux enabled its going to break your system and you will not be able to log back in. To disable it, edit /etc/sysconfig/selinux and in the line that says SELINUX=enforcing change the value to “disabled”, save and reboot the machine – SELinux mode is set only during boot time.

Its also important to note that this procedure is based on a default install of CentOS 5.4 – while its likely that it will work without changes on a machine upgraded from a previous CentOS, if you customized your installation then some packages that I assume are installed, notable a GNOME desktop, may be missing and some procedures listed below will break unexpectedly – if this happen use your best judgment or contact me for advice.

The next thing we need to know before installing, is where to get Fedora 12 packages from: You can find these at a mirror close to you – look for a mirror in the Fedora 12 mirror list. After you select your mirror, go into releases/12/Fedora where you will find 3 directories – under source/SRPMS you’ll find your source RPM packages (which you will need a few); under i386/os/Packages or x86_64/os/Packages (depending on what architecture you currently have installed) you’ll find the relevant binary packages.

RPM Incompatibilities

The main problem we have to address when upgrading to Fedora 12 is that the RPM format has changed with RPM version 4.6, and the version of RPM installed in CentOS 5 (version 4.4) can’t be used to install packages from Fedora 12. So we’ll need to start by building a new version of RPM from source and install them. Start by installing a some required packages using the command
yum install -y mc rpm-build redhat-rpm-config elfutils-devel elfutils-libelf-devel readline-devel zlib-devel nss-devel gettext-devel libselinux-devel ncurses-devel bzip2-devel python-devel libcap-devel libacl-devel libtool gcc-java gcc-c++ java-1.6.0-openjdk-devel audit-libs-devel pam-devel texinfo sharutils doxygen

We’ll use mc to extract the source files from the source RPM files that are packed in a new format our current RPM installation does not understand, and rpm-build to build those sources. The rest of the files are development libraries that are needed by software we will be building.

If you are doing this on a 64bit CentOS install, you should make sure to remove the 32bit versions of packages you have installed – CentOS, like all Fedora based operating systems, install a lot of 32 bit packages by default for backward compatibility, and these will cause a lot of conflicts during build and installation, so better remove them before starting. To remove them, the easiest way is to run the command
yum remove glibc.i686

This will remove a lot of packages and all but a few should be 32 bit packages (the few 64bit packages that are removed should be safe to remove). If you actually need 32bit support, you can reinstall it later.

Building Required Software

The next thing we need to do is get some source RPM packages from Fedora 12 source mirror, extract them, build new binary packages that work on our system and install the new binary packages. This process boils down to the following steps that have to be repeated for each package:

1. Download the src.rpm file: from the Fedora mirror, from the source/SRPMS directory we discussed previously. I usually cd /usr/src/redhat and download there – it saves some cding back and forth and still keeps things relatively organized.
2. Extract the source code: we need to use Midnight Commander to extract the source code because the RPM version installed in CentOS does not understand the package format of the new RPM files from Fedora 12 – if you try to install the new RPMs directly you’d get a lot of checksum errors. So start mc in the directory where you downloaded the package. From the MC view, locate the src.rpm file you just downloaded, position the cursor over it using the arrow keys and press ENTER. you should now be “inside” the source package and should see a pseudo-file named CONTENTS.cpio. Position the cursor over the content pseudo-file and hit ENTER again to get to the actual archive content. Now hit TAB to move to the second file view and navigate to /usr/src/redhat/SOURCES – if you followed my advice in the previous step, it should be right in the same directory. use TAB to get back to the source archive, mark all the files by pressing * and press F5 and ENTER to copy them to the sources directory. Now exit MC by using the F10 key.
3. Build the packages: navigate to /usr/src/redhat/SOURCES and there should be a file named <package-name.spec>. This is the RPM specification file with the instructions on how to build the required binary packages. Use the command
rpmbuild -bb --clean --rmsource --rmspec <package-name&gtl.spec
to start the build. Sometimes you will also need to add the switch --nodeps if the RPM specification lists some requirements which we do not want to install and are not really mandatory to build. This is not safe to do per-se, but we will use this when we have to. If the build completes successfully, then the output from the build should end with something like this:
+ exit 0
. If the build was completed successfully, then rpmbuild will also have removed the source files automatically as they are not needed anymore.
4. Installing the new software: once the build process completes, it should note that it “wrote” some binary RPM files. Install all these files using the command
rpm -Uhv <list of binary RPM files>
with the full paths of all the RPM files the build process listed. If there are RPM files which end in “debuginfo” or “static”, you don’t need to install these, but do install “devel” packages. Sometimes I’ll ask you to also add the switch --nodeps to this command as well, or even --replacefiles. Again this is not safe per-se, but a bit of ambiguity here can save a lot of time.

So now that you know what to do, lets get to work:

1. Download tcl-8.5, build it with --nodeps and install it with --nodeps --replacefiles
2. Download db4-4.7, build it with --nodeps and install it using rpm -ihv instead of rpm -Uhv and also add --nodeps
3. Download popt-1.13, build it with --nodeps and install it using --replacefiles
4. Download file-5.03, build it normally and install it using --nodeps
5. Download libcap-2.16, build it normally and install it using rpm -ihv instead of rpm -Uhv and also with --replacefiles
6. Download lua-5.1.4, build it normally and install it normally
7. Download fakechroot-2.9, build it with --nodeps and install it normally. I’ve seen that some mirrors are missing this package for some reason, if your mirror does not have it, try other mirrors or try the ISOC Israel mirror where I found this package: http://mirror.isoc.org.il/pub/fedora/releases/12/Everything/source/SRPMS/
8. Download xz-4.999 from my RPM site at http://rpms.geek.co.il/centos5/SRPMS, build it normally and install it normally. We can’t simply build it from Fedora source repository because the Fedora source package for xz uses the XZ compression format – so you need xz installed in order to build and install xz, kind of a chicken and egg problem. Weird.
9. Download rpm-4.7, build it normally and install it with --nodeps

Setting Up

Now that we have a new RPM that can install Fedora 12 packages, its time to get the Fedora release package – this contain the software repository configuration that we need to upgrade our system to Fedora 12. You can download these files from the mirror directory for the architecture you need – look for the package fedora-release-12-1.noarch.rpm. But before we install it, we need to remove the old centos-release package as it will conflict with the new package – so run
rpm -e centos-release --nodeps

then run

rpm -Uhv fedora-release-12-1.noarch.rpm


Its All Downhill From Here

Now we’re just left of installing the new system. Its not as easy as doing a yum upgrade and its a bit more complicated then the Fedora 7 upgrade we did 2 years ago, but its manageable.

We’ll start by removing some development packages and other not important packages that can cause us to waste time on conflict resolution. Run the command
rpm -e $(rpm -qa '*-devel') gcc-java elfutils-libelf-devel-static elfutils-devel-static gcc gcc-c++ rpm-cron rpm-build rpm-apidocs glibc-headers pilot-link gnome-pilot evolution evolution-connector launchmail


Now we need to download some packages and install them manually before yum can work properly. From the Fedora 12 mirror of your architecture (32bit or 64bit), download these packages:

audit
audit-libs
audit-libs-python
binutils
ca-certificates
curl
dirmngr
e2fsprogs
e2fsprogs-libs
glib2
glibc
glibc-common
gnupg2
gpgme
libcom_err
libcurl
libffi
libksba
libss
libssh2
libuser
lua
ncurses
ncurses-base
ncurses-libs
nscd
nspr
nss
nss-util
nss-softokn
nss-softokn-freebl
openldap
openssl
pam
passwd
pinentry
prelink
pth
pygpgme
python
python-libs
python-pycurl
python-urlgrabber
readline
rpm
rpm-libs
rpm-python
shadow-utils
sqlite
util-linux-ng
wget
yum
yum-metadata-parser


Then install all the downloaded packages at the same time by using the command
rpm -Uhv --nodeps
followed by all the files that you downloaded. I normally create a directory, download all the files there, and then use rpm -Uhv --nodeps *. If all went well so far, then you should see that RPM is installing all the files without problems (there may be a few configuration files that are saved, but that’s OK). At the end of the installation, you may get some errors about triggers failing because of missing libtermcap.so.2 – that is expected and you can ignore it for now.

At this point running YUM should work with the new version – try it out by invoking yum clean all, it should complete without errors. If you have an error in this stage then I suggest going back and checking what you missed.

Just About Done

All that we have left to do now, is upgrade the system using the new YUM to upgrade all the packages to the latest versions from the Fedora 12 repository. The first thing is to upgrade BASH, because the current (old) version of BASH we have installed is broken and unless we fix it, all the RPM scripts will break. So run the command
yum install -y bash


We’ll need to resolve a few other problems before we can run the full upgrade:

• The GCC Java package installed in CentOS 5.4 does not upgrade well to the newer GCC Java, so we’ll need to remove it by hand – run the command
rpm -e java-1.4.2-gcj-compat --nodeps
to get rid of it. The new GCC Java package will be installed automatically as part of the upgrade.
• The Fedora logos package can’t automatically replace the CentOS provided one, for some reason, so we’ll need to do it by hand:
yum install -y fedora-logos

• The DeviceKit package conflicts with the old kernel, but YUM dependency resolution fails to take into account that we are installing a new one, so we’ll need to upgrade the kernel manually. There is also another conflict of very old packages with very new ones that we’ll need to resolve, so run
rpm -e rhgb mkinitrd --nodeps
yum upgrade -y kernel
rpm -e $(rpm -qa kernel* | grep 2.6.18)


Before we do the full upgrade, lets make sure that we can log in after the system reboots. We’ll update OpenSSH and some required files:
yum upgrade -y openssh-server 'pam*' '*selinux*'
(the quotes are important). Now restart the SSH server:
service sshd restart

Now try to log in to the server, which should work (if you disabled SELinux at the start).

Now, finally, we can run the full upgrade. Execute
yum upgrade -y

and go do something more fun for a while – it will take some time to download and install more then 1000 packages.

After that is done, we need to recreate the initial ramdisk for the boot process to complete, because the one created during the upgrade is broken. Run this command:
dracut -f /boot/initramfs-2.6.*.img $(rpm -q --qf '%{version}-%{release}.%{arch}' kernel)


Lastly, we want to make sure that the system is using the new style boot process using upstart and not using the old inittab file to manage the console, otherwise when we reboot we won’t have a local login console. So run
mv -f /etc/inittab.rpmnew /etc/inittab


When the dust settles, you should be able to reboot to a working Fedora 12 installation.

It is also recommended to look in the file system and find all the backups of configuration files in the form *.rpmnew files and *.rpmsave file and merge any changes in them back to the original configuration files. rpmnew files are new configuration files that the upgrade has brought in and contain new functionality that should be put in – instead of forcing the change they are backed up with a .rpmnew extension. rpmsave files are configuration files that had local changes but should have been removed – instead of losing the changes, they are backed up with a .rpmsave extension.

What I normally do is run
find / -name '*.rpmsave'
and go over each file and decide if it has important configuration and if so figure out where it should go now. Then I delete the rpmsave file. I then run
find / -name '*.rpmnew'
and go over each file by comparing it to the current configuration file using a diff tool and put in the new configuration that you like. If you know for a fact that you do not care about the specific configuration file, you can just move the rpmnew file over the old configuration.

Good luck, and let me know if you have any issues with this procedure. Again – there are so many pits here that an unwary traveler may fall into. I tested this procedure on a VM and had to restore it from snapshot more then once, and its important to note that if you get disconnected from the machine during the process, you won’t be able to restore it as after about the second step the SSH server will not accept new connections until the full upgrade is done. I believe that by following this procedure, and maybe with a bit of creative thinking, one can successfully upgrade a running CentOS 5 server, but it won’t be completely without downtime and there is a lot of risk in this. If the service is very important to you – go to the server farm and stick a disc in there .

Its most annoyingly present when setting the keyboard layout switching command to ALT+SHIFT (like in MS-Windows), then you can’t do any keyboard shortcut that has ALT+SHIFT in it – such as ALT+SHIFT+TAB to move to the previous window.

Well, finally there is a solution! As detailed in FreeDesktop.org’s Bugzilla and Ubuntu’s Launchpad , and thanks to Ilya Murav’jov we now have a patch to solve this ancient X11 problem.

By changing the X server behavior to trigger the layout switch only when releasing the shortcut keys and only if no other key has been pressed, we can now enjoy a perfectly working “switch to previous window” action Also all of the (default) ALT+SHIFT+<some key> keyboard shortcuts in Eclipse will finally work for me out of the box. This will also solve the Firefox keyboard shortcut problem I talked about in this post.

Now, this is just a preliminary patch. It has not been accepted anywhere yet and X.org developers will most likely want to have this configured and have the old behavior by default – at least for a while. So expect more changes and a lot more time until you see this in a repository near you. But if you are of the adventurous kind, and are running Ubuntu Karmic (9.10) or Lucid (10.04 alpha), then you can try to add my PPA to your system and upgrade your X.org server to the patched version.

On the other hand, if you’re really into pain ( ) here’s how to build it yourself on your Ubuntu system:

1. Start by enabling the Ubuntu source repositories: open the “System” menu and go to “Administration” and start “Software Sources”. In “Software Sources”, click the checkbox labeled “Source code” – it may turn in to a dash instead of a check box, that’s ok. Click “Close” and when it asks if you want to update the repositories, click “Reload”.
2. Now go to “System” -> “Administration” again and start “Synaptic Package Manager“. When it loads, use the quick search to look for “pbuilder” and check that for installation, then “devscripts” and also choose to install this. Click the “Apply” button to install them and wait until the installation is done.
3. Create yourself a directory where you can put the source to be built. Now we need to go to the terminal for the rest of the work, so run it from “Applicatoins” -> “Accessories” and then use it to change into the directory you just created.
4. run apt-get source xserver-xorg-core to download the source for the X server.
5. Once the download is done, go to the FreeDesktop.org Bugzilla bug I linked above and download the patch from there (it should be the first one under attachments) and save it – in the directory you created you should now find a directory named xorg-xserver-someversion/debian/patches – save the patch there. Its a good idea to make sure the file ends with “.patch“.
6. In the same directory where you saved the patch, edit the file “series” and add the file name of the patch file in the last line.
7. Now back in the terminal, go into the xorg-xserver-someversion directory and run dch -n. This will open an editor that will let you write a changelog entry for the change you have just done. Write something meaningful and save it.
8. To start the build, we want to first create a build chroot as described in the PBuilder Ubuntu Wiki page: run sudo pbuilder create --debootstrapopts --variant=buildd and wait for it to finish – it will take some time. When it is done, you can start the build by running pdebuild from the directory where you’ve put the source package. If you have a PGP key that you want to sign the new package with, you probably want to run pdebuild --auto-debsign so it will automatically sign the new package for you at the end of the build, otherwise you can sign it later or not sign it at all.
9. Once the build is done, you should find your new X server DEB packages under /var/cache/pbuilder/result and you can install them by double clicking or by running sudo dpkg -i <deb files> from the terminal.

If there is interest, I can also build Fedora 12 packages with the patch – let me know.

[Update]

I’ve finished building Fedora 12 packages for the patched X.org. If anyone is interested in proper shift key handling on Fedora 12, then you can find updated X.org RPMs here. These are compiled for 64bit Fedora 12, but you can also find there the source RPM from which you can build 32bit packages if you are so inclined.

sorry, but your wrong. Linux can’t run executables. I am a Linux administrator.

Source

והפעם Truth or Consequences N.M – אני לא חושב שהסרט הזה בכלל הופץ בארץ, אבל אולי אפשר לתרגם את שמו כ”אמת או השלכות, ניו-מקסיקו” (כנראה לא בהפצה מסחרית בישראל. בבתי הקולנוע בארץ היו כנראה קוראים לזה “אמת או מוות בניו-מקסיקו” או משהו כזה). הסרט קרוי על שם העיר (האמיתית) שבה מתרחשת לכאורה סצינת הסיום של הסרט – אם כי באופן משעשע הסרט לא צולם בניו-מקסיקו (לא ברור לי למה, ניו-מקסיקו אמורה להיות מקום די מוצלח לצילום סרטים).

זהו הסרט הראשון של קיפר סאתרלנד כבמאי (והוא גם משחק באחד התפקידים הראשיים) וכנראה הסיבה שהוא לא הפך לסרט פולחן היא ההפצה המאוד מוגבלת שלו (מוטיב שכנראה יחזור בפינה הזאת הרבה): לפי וויקיפדיה הוא הופץ בשבעה בתי קולנוע בלבד והרוויח פחות ממאה ועשרה אלף דולר בקופות הקולנוע.

הסרט עצמו הוא סרט פשע/מסע מעניין עם דמויות מורכבות שמתפתחות תוך כדי העלילה, ואפילו יש קצת אקשן. אבל הסיבה שאני חושב שהסרט הזה צריך להיות סרט פולחן הוא הסוף הקצת צפוי מראש וקצת מפתיע ובעיקר סצינת הסיום שחשבתי שהיא מאוד חזקה. אני לא הולך להרחיב מעבר לזה, אבל אני ממליץ לצפות אלא אם אתם לא אוהבים סרטים קשים לצפיה .