Debian live

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

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

חשבתי לעצמי שיהיה נחמד לבוא עם סביבה מוכנה במקום לבוא ולהתקין הכל במקום בסביבה זרה, ומה יותר מתאים לזה מLIVE CD + כונן קשיח נייד?
הבחירה הטבעית שלי היתה Knoppix, הורדתי את הISO, העלתי אותו בVirtualBox, שמתי את האפליקציה על הדיסק הנייד והתחלתי לנסות להפעיל אותה.
למרבה הצער היו מלא בעיות, כשהקש ששבר את ראש הגמל היה שlibstdc++ היה מגרסא לא מתאימה.
החלטתי לוותר על התענוג, וביגוני חיפשתי בגוגל "Debian live cd".
התוצאה המפתיעה היא שיש פרוייקט בשם Debian live!

כמו תמיד עם live cd, חיפשתי מאיפה מורידים את הISO, התחלתי להוריד, ולמרבה המזל מהירות ההורדה היתה כ20K בשניה.
למה מזל?
כי במהירות כזו, היה לי מספיק זמן כדי להסתכל קצת מסביב.

About

A Debian Live system is a Debian operating system that does not require a classical installer to use it. It comes on various media, including CD-ROM, USB sticks, or via netboot.

Why Debian Live?
Although the Debian Live project is about the framework to create your own customized Live system, we offer some prebuilt images. Currently, builds for three desktop environments (GNOME, KDE and Xfce) as well as the standard system are available.

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

מסתבר שהתהליך הוא פשוט במיוחד. כדי ליצור דיסק בסיסי ועובד:
[code]
apt-get install live-helper
mkdir live-cd
cd live-cd
lh_config
lh_build
[/code]

במילים, מתקינים את live-helper, יוצרים ספרית עבודה, משתמשים בlh_config כדי ליצור קופיגורציה בסיסית, ובlh_build כדי לבנות ממנה ISO.
התהליך יכול לקחת זמן, ומומלץ להתקין את apt-cacher כדי לחסוך בזמני הורדה של חבילות דביאן.
אפשר לבדוק את הISO עם VirtualBox. המערכת שהוא מכיל היא בסיסית מאוד, אבל אפשר להתקין בתוכה מה שרוצים עם apt-get.
יש כמה דרכים להוסיף חבילות שיהיו מותקנות מראש בISO:
כדי להוסיף חבילות סטנדרטיות, בסך הכל צריך להוסיף את השם שלהן בLH_PACKAGES בקובץ config/chroot בספרייית הקונפיגורציה שיצרתם.
יש גם דרכים להוסיף חבילות מותאמות אישית, ואפשר גם להוסיף קבצים ספציפייים בקלות.
מי שהתקין את apt-cacher ירצה לשנות את מקורות ההתקנה של יצירת הISO, אפשר לעשות את זה על ידי עריכה של config/bootstrap.

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

אני ממליץ בחום על Debian live למי שצריך Live CD.
קל מאוד ליצור דיסקים איתו, והתוצאה היא מערכת דביאן לכל דבר, שעולה מCD/DVD.

לינוקס לאמא

סידרתי לאמא שלי מחשב, ועליו לינוקס בלבד.
המחשב די ישן, אבל בהחלט מספיק: פנטיום 4 במהירות 2.6 ג'יגה הרץ עם 512 מגה זכרון ודיסק של 80GB.
אמא שלי חסרת כל נסיון עם מחשבים, ולא השתמשה במחשב מעולם עד עכשיו.
התקנתי לה דביאן לני, עם פיירפוקס ות'אנדרבירד בעברית (התקנות ידניות, אין את החבילות האלו בלני), וגם KDE בעברית כדי שתרגיש בנוח.
סך הכל אני אופטימי, בתוך יום אחד היא למדה את הדברים הבסיסיים (הפעלה וכיבוי של המחשב, גלישה באינטרנט, שליחה וקבלת אימיילים).
אני מרוצה מזה שאני אוכל לעזור לה מרחוק בלי בעיה:
התקנתי שרת SSH, ודאגתי שהמחשב שלה יהיה זמין בHOST קבוע (למרות שאין לה כתובת IP קבועה).

עוד יתרון משמעותי הוא שהמחשב יחזיק מעמד הרבה יותר טוב מאשר מכונה עם חלונות. גם מבחינת ביצועים וגם מבחינת עמידות לווירוסים וכו'.
נו, אז מה אתם אומרים? הניסוי יצליח או לא? 🙂

גיבויים בלינוקס

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

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

גרסא נוספת של הגיבוי הזה היא "מלא + דיפרנציאלי", בשיטה הזו גיבוי מלא נשמר, וכל גיבוי חלקי שאחריו הוא יחסי לגיבוי המלא, ולא לגיבוי החלקי האחרון. זה אומר שקבצים שהשתנו אחרי הגיבוי המלא יאוכסנו שוב ושוב, מצד שני יהיה הרבה יותר קל לשחזר את הגיבוי לרגע נתון.

הגיבוי התמים הוא פשוט להעתיק את הקבצים, כמו שהם, לספריה אחרת (ואולי למחשב אחר).
הבעיה עם זה היא שקבצים שלא משתנים יתפסו מקום כל פעם מחדש, מה שאומר שסך הכל הצריכה של המקום תהיה גבוהה מאוד.
הפתרון הוא לאכסן רק קבצים חדשים, אבל איך אפשר יהיה לשמור על הפשטות של השיטה התמימה?
אם אבד לי קובץ, אני רוצה לגשת לגיבוי של אתמול ולמצוא אותו שם, גם אם הוא לא השתנה כבר חודש.
כדי להנות משני העולמות, אפשר להשתמש בשיטה הבאה:
נגבה עם rsync, ולפני הגיבוי הבא, נעתיק את הספריה שגיבינו למקום חדש, אבל במקום להעתיק ממש את הקבצים ניצור hard-links לקבצים, ואז נגבה שוב עם rsync.
ברגע שrsync יזהה שקובץ השתנה, הוא יצור קובץ חדש במקום הלינק, ולא יפגע בקובץ המקורי שימשיך להיות זמין תחת הספריה המקורית שאליה הוא נכתב.
הרעיון הוא של מייק רובל, שפרסם אותו ב2004. מאז פותחו לא מעט סקריפטים שממשמשים את השיטה. אני משתמש בsnapback2 כדי לבצע את הגיבויים שלי.
כדי להתקין את snapback2, עקבו אחרי ההוראות האלו:

[code lang="bash"]
wget http://www.perusion.com/misc/Snapback2/Snapback2-0.913.tar.gz
tar xzf Snapback2-0.913.tar.gz
cd Snapback2-0.913/
cpan -i Config::ApacheFormat
perl Makefile.PL && make && make test && make install && echo great success
[/code]
cpan הוא מנגנון ניהול החבילות של שפת פרל. אם לא הפעלתם את cpan לפני כן, הוא ישאל כמה שאלות די קלות לפני שהוא יתקין את Config::ApacheFormat.
שימו לב לפלט של הפקודה האחרונה, אם הוא לא מסתיים ב "great success" אז היתה בעיה בהתקנה.
snapback2 עובד דרך הרשת, מה שאומר שאפשר לגבות איתו בקלות מכונה אחרת או את המכונה המקומית, אבל קודם צריך לדאוג לכך שנוכל להכנס בלי סיסמא (זהירות עם זה, צריך לשמור על הקובץ id_dsa.pub מכל משמר, כי מי שישיג אותו יוכל להכנס למכונה שאתם מגבים!).
[code lang="bash"]
ssh-keygen -t dsa
cat ~/.ssh/id_dsa.pub | ssh root@other_machine "cat – >> ~/.ssh/authorized_keys"
[/code]

קובץ ההגדרות /etc/snapback/snapback2.conf של snapback נראה ככה:
[code lang="xml"]
Hourlies 2
Dailies 7
Weeklies 4
Monthlies 4
AutoTime Yes

AdminEmail root

LogFile /var/log/snapback.log
ChargeFile /var/log/snapback.charges

SnapbackRoot /etc/snapback

DestinationList /root/backup


Exclude /cdrom
Exclude /dev
Exclude /home/*/temp
Exclude /media
Exclude /proc
Exclude /tmp
Exclude /var/cache
Exclude /var/log
Exclude /var/lib/mysql
Exclude /root/backup # Important not to backup the backup 🙂

Directory /

[/code]

הקובץ הזה מגבה את כל מה שרלוונטי, ואולי כמה דברים לא רלוונטים שעדיין לא הכנסתי לExclude.
ויוצר מבנה ספריות דומה לזה:
[code lang="xml"]
`– root@server.com
|– daily.0
| |– bin
| |– boot
| | …..
| `– www -> /var/www
|– daily.1
| |– bin
| |– boot
| | …..
| `– www -> /var/www
|– daily.2
| |– bin
| |– boot
| | …..
| `– www -> /var/www
|– hourly.0
| |– bin
| |– boot
| | …..
| `– www -> /var/www
`– hourly.1
|– bin
|– boot
| …..
`– www -> /var/www
[/code]

כדי להריץ את הגיבוי אוטומטית פעם ביום ניצור קובץ הרצה בcron.daily
[code lang="bash"]
echo "#! /bin/sh" > /etc/cron.daily/snapback2
echo "/usr/bin/snapback2" >> /etc/cron.daily/snapback2
chmod +x /etc/cron.daily/snapback2
[/code]
חדי העין ישימו לב שלא גיביתי את /var/lib/mysql, שמכילה את בסיסי הנתונים של MySQL.
הסיבה היא שלא מומלץ לגבות את בסיס הנתונים של MySQL על ידי העתקת הקבצים, במיוחד אם השרת רץ (והוא רץ כל הזמן), כדי לא לתפוס קבצים תוך כדי שהם נכתבים (מה שיגרום לגיבוי של בסיס הנתונים להיות דפוק).
גיבוי MYSQL
אני משתמש בסקריפט הזה, שמגבה את אל בסיסי הנתונים אל /var/backups/mysql, ויוצר מבנה ספריות דומה לזה:
[code lang="xml"]
|– daily
| |– omry_blogs
| | |– omry_blogs_2008-09-21.Sunday.sql.gz
| | |– omry_blogs_2008-09-22.Monday.sql.gz
| | |– omry_blogs_2008-09-23.Tuesday.sql.gz
| | |– omry_blogs_2008-09-24.Wednesday.sql.gz
| | |– omry_blogs_2008-09-25.Thursday.sql.gz
| | `– omry_blogs_2008-09-26.Friday.sql.gz
| | `– omry_paypal_2008-09-26.Friday.sql.gz
| `– omry_wordpress_en
| |– omry_wordpress_en_2008-09-21.Sunday.sql.gz
| |– omry_wordpress_en_2008-09-22.Monday.sql.gz
| |– omry_wordpress_en_2008-09-23.Tuesday.sql.gz
| |– omry_wordpress_en_2008-09-24.Wednesday.sql.gz
| |– omry_wordpress_en_2008-09-25.Thursday.sql.gz
| `– omry_wordpress_en_2008-09-26.Friday.sql.gz
|– monthly
`– weekly
[/code]
כמובן שהספריות האלו מגובות אוטומטית במסגרת הגיבוי של מערכת הקבצים.
כדי להשתמש בסקריפט, יש לשים אותו ב/etc/cron.daily ולערוך אותו ככה ששם המשתמש והסיסמא יהיו אלו של משתמש שמורשה לגשת לכל בסיס הנתונים. לא לשכוח לשנות את ההרשאות של הקובץ ככה שרק root יוכל לקרוא אותו.
כדי לחסום את הנפח שהגיבויים האלו תופסים, ניצור בcron.weekly סקריפט שמוחק גיבויי mysql ישנים מ60 יום:
[code lang="bash"]
echo "#!/bin/sh" > /etc/cron.weekly/delete_old_mysql_backups
echo "find /var/backups/mysql/ -type f -mtime +60 -exec rm {} \;" >> /etc/cron.weekly/delete_old_mysql_backups
chmod +x /etc/cron.weekly/delete_old_mysql_backups
[/code]

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

חטאי אימפריה סולרית

אחד המשחקים עם השם הכי פיוטיים שנתקלתי בהם לאחרונה הוא Sins of a solar empire.
המשחק הוא משחק אסטרטגית חלל בזמן אמת, דו מימדי בפועל (כל העצמים נמצאים על אותו מישור) אבל תלת מימדי מבחינת תצוגה.
בדומה למשחקי אסטרטגיית חלל כמו Master of orion, בונים אימפרייה חללית, חוקרים טכנולוגיות, בונים חלליות וכו'.
המשחק הוא בזמן אמת והתצוגה דומה לתצוגה של Homeworld (למרות שHomeworld הוא יותר תלת מימדי).
ובכל זאת הוא שונה מHomeworld מאוד. בHomeworld מה שמניע את העסק הוא הקרב עם האוייב בשלב הנוכחי והשלב הוא ממוקד וקטן יחסית.
בחטאים השלבים יכולים להיות גדולים מאוד, ומה שמניע את המשחק הוא הרצון לכבוש כוכבי לכת ואסטרואידים כמה שיותר מהר.
עוד הבדל מהותי מאוד הוא שHomeworld המשחק הוא בעיקר מונחה קמפיין עלילתי, ובחטאים אין קמפיין. בהתחלה חשבתי שזה חיסרון עצום, אבל אחרי ששיחקתי במשחק ראיתי שהוא מספיק טוב וממכר גם ככה.

המפה מחולקת לשמשות, ולכל שמש כוכבי לכת.
ספינות חלל קופצות מכוכב לכת לכוכב לכת, במסלולים מוגדרים מראש (לכל פלנאטה יש 'שכנים').
star.jpg
לכל פלאנטה יש באר כבידה, כדי לקפוץ החוצה צריך לצאת ממנה (אפשר לראות בתמונה את באר הכבידה מסומנת במעגל בהיר)
sins-well-thumb.jpg

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

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

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

סך הכל, חטאי אימפריה סולרית הוא אחלה משחק.
קניתי אותו כדי לתמוך בסטארדוק (שפיתחו בעבר את Galactic civilization הזכור לטובה).

כדי לחסוך לי איתחולים לחלונות משחקים שלי, קניתי מנוי שנתי לCedega ב45$ – מחיר של משחק בודד.
Cedega מאפשר לי להריץ את Sins, ועוד הרבה משחקים ישירות על הלינוקס.
התמיכה לא מושלמת, אבל טובה מספיק כדי שהמשחק יהיה מהנה מאוד.
רוב התצלומי מסך פה נלקחו מSins שרץ על לינוקס :).

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

זבלן הלוגים

לתשומת לב הנוסעים צפונה:
שלשום השרת שלי בסלון נתקע, רסטרטי אותו, וקיבלתי הודעות שגיאה על חוסר מקום.
מחיצת השורש שלו בגודל של 30 ג'יגה בלבד, אבל זה אמור להספיק כי אין לא כותב לשם שום דבר מיוחד.
מחקתי איזה 2 ג'יגה של קוד מספריית הsrc, (שזה קוד של כל מני דברים שהורדתי וקימפלתי בעבר) בתקווה לקנות כמה חודשים של שקט.
היום בבוקר, פוף, עוד פעם אין מקום.
הפעם החלטתי לרדת לעומק העניין..
הניחוש הראשון היה כמובן ספריית הלוגים של המערכת /var/log..
syslog תפס 2.6 ג'יגה, וdaemon.log תפס 6.4 ג'יגה.
נפח עצום, במיוחד למחיצה של 30GB, ובמיוחד לאור זה שהכל מהשבוע האחרון (logrotate כיון את daemon לפני שבוע, והוא היה קטן ונחמד).
בתוך daemon.log ראיתי ערמת הודעות כאלו:
[code]
Aug 29 10:36:46 home famd[3423]: fd 4 message length 1347375956 bytes exceeds max of 4136.
[/code]
נראה שfamd התחרפן קשות..
famd הוא File Alteration Monitor Daemon, פתרון וותיק למעקב אחרי שינויים בקבצים, ולא ממש נדרש בימינו כי inotify החליף אותו.
בכל אופן, אני בטוח לא צריך אותו, אז העפתי את הנבלה ואיפסתי את הלוגים.

ובא שלום וגואל, ומשיח על חמור שחור.

PHP4 מגיע לסוף החיים, אבל עדיין בשימוש של כ38% מהשרתים

שוחררה הגרסא האחרונה (ככל הנראה) בענף של PHP 4.4.
הגרסא הזו מסמנת את סוף התמיכה הרשמית בPHP4.
PHP5 כבר בחוץ במשך יותר משלוש שנים, אבל עד עכשיו האימוץ שלו היה די איטי, מסיבות של ביצה ודינוזאור:
מפתחי התוכנות לא רצו להפסיק לתמוך בPHP4 כדי לא לאבד משתמשים. חברות אירוח האתרים לא טרחו לשדרג כי כל התוכנות החשובות תמכו גם ככה בPHP4 והמשתמשים, מה איכפת להם?
בשנה שעברה נפתח אתר gophp5.org, ששם לעצמו למטרה לדחוף את האימוץ של PHP5.
הרעיון הוא שאם מסה מספיק גדולה של פרוייקטים תעבור לPHP5, ומסה מספיק גדולה של חברות אירוח תעבור לPHP5, לשאר חברות האירוח לא תהיה ברירה והן תאלצנה לשדרג או לאבד משתמשים, ואז לשאר הפרוייקטים לא תהיה סיבה להשאר בPHP4 והם יוכלו להתחיל סוף סוף לנצל את היכולות של PHP5.
בפברואר 2008 כבר היו מעל 100 פרוייקטי תוכנה שהתחייבו להפסיק לדאוג לתמיכה בPHP4 (זה לא אומר שהם ילכו וישברו את התמיכה בPHP4 בכוונה, פשוט שהם יפסיקו לדאוג שקוד חדש ירוץ בPHP4), ומעל 200 חברות איכסון שתומכות בPHP 5.2 כביררת מחדל וgophp5 טענו להצלחה והפסיקו לאסוף הרשמות.

אז למה לא לתמוך בPHP4? הנה דוגמא מאתמול:
JSON הוא דרך להעביר מבנה נתונים כלשהו לייצוג של מבנה הנתונים כאובייקט ג'אווה סקריפט, והוא אחת הדרכים הפשוטות והיעילות ביותר להעביר נתונים מקוד בצד השרת לדפדפן (שפשוט מפעיל על הטקסט שחוזר את המפסק (parser) של ג'אווה סקריפט כדי לקבל אובייקט מוכן לשימוש.
למרות שראשי התיבות של AJAX הן Asynchronous Javascript And XML, מעולם לא השתמשתי בAJAX כדי להעביר XML, למעשה אני מוצא את הרעיון מזעזע. הרבה יותר קל להעביר JSON, או אפילו קוד HTML ממש.
JSON משמש בהרבה מאוד פרוייקטים מבוססי AJAX, ומכיוון שאין בPHP4 תמיכה מובנית בJSON (אחרי הכל, PHP4 הוא בן שמונה, וJSON הוא די חדש בשכונה) צריך להשתמש בספריות חיצוניות שיודעות להעביר אובייקט PHP לפורמט JSON, אחת הספריות הנפוצות היא Services_JSON (למעשה אני משתמש בספריה הזו בFireStats).
הספריה כתובה בPHP, ולמרות שהיא עובדת נכון, היא לא ממש עובדת מהר, במיוחד כשממירים מבני נתונים גדולים (לא עצומים, משהו בסדר גודל של מערך עם 1000 אובייקטים טיפה מורכבים) לJSON.
ממש אתמול ניסיתי לשפר ביצועים של ישום PHP, אחרי חפירות גיליתי שאחד הדברים שמאטים מאוד את העסק היה המרה של תשובה לדפדפן לJSON בשימוש בServices_JSON, כשאני אומר איטי, אני מתכוון ל8 שניות.
שמונה שניות שהשרת טוחן את הCPU שלו כדי להכין תשובה ללקוח (במקרה הספציפי הזה, במקרים אחרים עם יותר נתונים זה כמובן יותר גרוע).
ברגע שראיתי את זה, לקח לי בדיוק שניה וחצי להיזכר שPHP5 תומך בJSON. בדיקה מהירה בphp.net הניבה את שתי הפונקציות הפשוטות json_encode וjson_decode. החלפתי את השימוש ב Services_JSON בקריאה לפונקציות של php5, ולא הייתי מופתע במיוחד לראות שהמרה של אותו מבנה נתונים לוקחת פתאום 40 מילישניות.
שיפור של פי 200, בזמן עבודה של כמה שניות (טוב, חוץ מלמצוא את הבעיה 🙂 )
השיפור נובע מכך שהתמיכה של PHP בJSON לא כתובה בPHP אלא בC, ולכן היא הרבה הרבה יותר יעילה.
השיפור הזה התאפשר רק כי הפרוייקט הספציפי הזה לא צריך לתמוך בPHP4.

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

אז איך מתקדם האימוץ של PHP5?
החל מFireStats 1.3 ששחרתי לפני יותר משנה, FireStats מכילה רכיב ששולח (באישור המשתמש) מידע מערכת אנונימי. חלק מהמידע הוא גרסאות הPHP והMySQL.
הכוונה היא שאני אוכל להשתמש במידע הזה כדי להחליט בצורה יותר מושכלת במה אני צריך לתמוך.
המידע הצטבר לי בבסיס הנתונים, ונכון לכרגע יש לי מידע על כמעט 12000 התקנות. מה שאומר כמעט 12000 שרתים בעולים (אני מתעלם ממקרים של כמה התקנות על אותו שרת).
למי שתוהה, זה לא אומר שFireStats הותקנה 12000 פעמים, אלא ש12000 פעמים המתקינים הסכימו לשלוח מידע מערכת אנונימי.
מי שרוצה את המידע הגולמי מוזמן לקחת אותם מפה (יצוא MSQL, כ5 מגה דחוסים, 65 מגה פרושים).

אז ישבתי כמה שעות כדי להוציא מהנתונים הגולמיים שני גרפים נחמדים:
הראשון הוא אחוזי ההתקנות של PHP 4 מול PHP 5, במהלך השנה האחרונה.
למרות שאחוזי ההתקנה של PHP4 ירדו במהלך השנה האחרונה מ52% ל38%, עדיין מי אי אפשר להתעלם ממנו. נקווה שהוא ימות סופית בקרוב:
installed php versions
השני הוא אחוזי ההתקנות של הגרסאות המשמעותיות של MYSQL:

כיף לראות שMYSQL 5.0 שולט בשוק, אבל נראה שMYSQL 4.0 הזוועתי נתקע על 7% ולא רוצה למות.
בכל מקרה, MYSQL 4.0 הוא בהחלט מועמד לנטישה, וכבר היום יש לא מעט תכונות חשובות של FireStats שלא נתמכות בגרסא הזו.
installed mysql versions

iFuse

כשהיתי בסיאטל לפני כשמונה חודשים, קניתי לי אייפוד טאצ'.
המכשיר יפה, מהיר ומגניב אבל חסר בדבר אחד עיקרי:
חייבים להשתמש בiTunes כדי להעלות עליו קבצים.
iTunes היא אחת התוכנות המאוסות ביותר שאני מכיר, היא כבדה מאוד, הממשק שלה מעצבן ומתנשא (כן, ממשק מתנשא, יש דבר כזה), והיא מלאה באגים, וכדי לעצבן ממש – היא מחייבת חלונות או טייגר (Mac OS X).
השימוש העיקרי שלי בטאץ' הוא לשמיעת פודקסטים, ומטבע הדברים אני צריך לעדכן את העסק לפחות פעם בשבוע.
כשרק קיבלתי את המכשיר ביליתי די הרבה זמן בנסיונות להשתמש בVMWare או בVirtualBox (תוכנות ווירטואליזציה) כדי להריץ חלונות בתוך VM ועליו את הiTunes, אבל התמיכה של התוכנות האלו בUSB לא היתה מספיק טובה ונאלצתי להשתמש בעותק חלונות אמיתי כדי לעדכן את הקבצים, מה שגרם לכך שלפעמים לא עדכנתי אותם לתקופות ארוכות פשוט כי לא יצא לי להעלות את החלונות.
לפני כמה חודשים VMWare שיפרו מספיק את התמיכה שלהם בUSB והחל מגרסא שש בערך אני יכול לעדכן את האיפוד בלי לאתחל את המחשב, דבר ששיפר משמעותית את תדירות העדכונים שלי.
אבל עדיין, להריץ חלונות בתוך VMWare, ובתוכו להריץ את iTunes זה חתיכת מבצע כדי לעדכן קבצים.
אם פרצתם את הטאץ' שלכם, נוספה אפשרות נוספת:
להתחבר למכשיר דרך חיבור אלחוטי, לעגן את מערכת הקבצים עם sshfs (מערכת קבצים מבוססת fuse שמאפשרת לעגן דרך SSH).
העסק לא עבד מספיק טוב לטעמי, גם כי היו לי בעיות בחיבור האלחוטי וגם כי המכשיר אהב להכנס לסטנד-ביי תוך כדי עדכון, מה שגרם לחיבור להתנתק.
חוץ מזה זה פשוט לא עבד כמו שצריך ברמה של עדכוני הקבצים, למרות שאני מאמין שבחזית הזו המצב השתפר מאז.
התחלתי לחקור למה אין מימוש פתוח של פרוטוקול התקשורת שאפל מממשים על גבי חיבור הUSB, ונתקלתי בפרוייקט iFuse, ששם לעצמו מטרה לממש את הפרוטוקול ולספק כלי לעיגון מערכת הקבצים של אייפוד טאץ' ואייפון (שוב על בסיס fuse)
הפרוייקט היה תקוע במשך חודשים ארוכים בנסיונות למצוא דרך מסביב להצפנה בפרוטוקול (הפרוטוקול מוצפן בSSL, נבזי במיוחד מצד אפל), אבל לפני כמה שבועות היתה פריצת דרך ומאז יש התקדמות כמעט יומית.
נכון לכרגע קריאה של הקבצים, וקבלת רשימה של קבצים בספריה נתמכות יפה.
עדיין יש קשיים עם כתיבה של קבצים, אבל לדעתי זה עניין של כמה שבועות.
ברגע שהעסק יעבוד, תפתח הדרך לאינטגרציה אמיתית של הטאץ' עם מגוון התוכנות ללינוקס שמנהלות שירים על מכשירים נישאים.

רשת ג'יגהביט

הנתב הקודם – OfficeConnect של 3COM אף פעם לא היה טוב במיוחד.
החל מפינגים לא יציבים כאשר אני מתחבר דרך הנתב, וכלה במצב קטטוני עד כדי חוסר תקשורת בין שני המחשבים שמחוברים אליו שדורש אתחול של הנתב.
החלטתי להחליף את העסק, ובהתחלה חשבתי ללכת על נתב אולטימטיבי שיתן לי גם תקשורת אלחוטית מהירה, גם תקשורת מקומית מהירה וגם יכולת חיוג בכבלים ובADSL.
כשלא מצאתי משהו טוב מספיק שממש עשה לי את זה, החלטתי לשנות את האסטרגיה.
שינוי 1:
החלפת התשתית התקשורת שלי מכבלים לADSL.
על הדרך שדרגתי את חבילת התקשורת שלי מ1500/500 ל8000/800,
המחיר הוא 210 שקל לחודש עם התחייבות לשנה, כ90 שקלים יותר ממה ששילמתי קודם, וקו מהיר בהרבה – ויותר חשוב, יציב מאוד בניגוד לתשתית של הכבלים.
כחלק מהעסקה, ביקשתי מבזק לספק נתב. הם סיפקו נתב של ROTAL, לא פאר היצירה אבל מספיק טוב לצרכי התקשורת שלי מבחינת תקשורת אלחוטית ותקשורת אל האינטרנט.
הנתב יציב ולא נתקע כמו ה3COM המחורבן שהיה לי קודם, מה שפתר את הבעיה הזו, אבל לא נתן לי תקשורת יותר מהירה בין המחשבים.

שינוי 2:
כדי לפתור את הבעיה הזו, הזמנתי לי נתב ג'יגביט של Edimax, ושני כבלי רשת CAT6 שמתאימים לתקשורת הזו.
היום הם הגיעו, וחיש מהר התקנתי את הסוויץ', חיברתי אליו את המחשבים ובדקתי את המהירות:
קודם כל העתקת קובץ בין שני המחשבים. היה לי ברור שאני אתקע במגבלה של מהירות הכוננים הקשיחים שהיא נמוכה הרבה יותר מאשר ג'יגביט לשניה.
יצרתי קובץ של 1 ג'יגה, מלא לחלוטין באפסים עם
[code]
dd if=/dev/zero of=bigfile bs=1024 count=1000000
[/code]
שמתי אותו בספריה שחשופה בפרוטוקול HTTP, והורדתי עם WGET:
[code]
wget http://yadan.net/omry/bigfile

–2008-07-24 19:33:13– http://yadan.net/omry/bigfile
Resolving yadan.net… 10.0.0.2
Connecting to yadan.net|10.0.0.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 1024000000 (977M) [text/plain]
Saving to: `bigfile'

100%[==============================================>] 1,024,000,000
39.6M/s in 25s

2008-07-24 19:33:38 (39.1 MB/s) – `bigfile' saved [1024000000/1024000000]
[/code]

כצפוי, לא מהירות שמרעידה את האדמה, אבל פי 3.5 יותר טוב ממה שנקבל ברשת 100 מגהביט בתאוריה (במעשי זה יותר מהיר פי 4-5).

לבדיקה הבאה רציתי מה המגבלה האמיתית של התשתית, בניטרול גורמים מציקים כמו מהירות הקריאה/הכתיבה של הכוננים.
חיפשתי קצת במאגר החבילות של דביאן, ומצאתי את iperf, תוכנית פשוטה לבדיקת ביצועי רשת.
iperf יודע לבדוק רוחב פס בתקשורת TCP או UDP, והוא עובד בשיטת שרת לקוח:
במחשב אחד מריצים אותו כשרת, במחשב השני כלקוח, ונותנים להם לבדוק את המהירות.
[code]

omry@home:~$ iperf -c 10.0.0.1
————————————————————
Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 3] local 10.0.0.2 port 52685 connected with 10.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.09 GBytes 940 Mbits/sec
[/code]

הרבה יותר מרשים.
אומנם לא הג'יגביט המובטח, אבל מספיק קרוב בשבילי, במיוחד לאור החומרה הזולה שקניתי לצורך העניין (סוויץ' ב150 שקל, וכבלי רשת של 15 מטר ו3 מטר ב70 ו30 שקל בהתאמה).

מכיוון שווידאו ב1080P הוא די גבולי על המחשב שיש לי בסלון (פנטיום D במהירות 3GHZ), החלטתי לנסות לבדוק איך הרשת סוחבת הזרמת וידאו ב1080P.
כדי לבדוק את זה, התחברתי מהמחשב בסלון אל המחשב בחדר (עם מעבד יותר חזק, Core 2 duo) עם ssh -X, מה שמאפשר לשלוח את הפלט של תוכניות גרפיות מהמחשב בחדר למחשב בסלון.
הפעלתי את mplayer במחשב בחדר על קובץ וידאו ב1080p (בטמן מתחיל), והפלט הוזרם למחשב בסלון.
הווידאו זז חלק לגמרי. אומנם לא שומעים כי הסאונד הולך למחשב הלא נכון, אבל זו בעיה אחרת ואני בטוח שאני אפתור אותה.
מה שלא ברור לי, זה למה בכלל זה עובד:
בהנחה של שכל פיקסל מיוצג ב4 בתים (ARGB), ושיש 25 פריימים לשניה (וכמובן כל בייט הוא 8 בתים), אז:
[code]
1920x1080x4x25x8=1,658,880,000
[/code]
1.6 ג'יגה ביט לשניה.
אפילו אם כל פיקסל הוא רק שלוש בתים (בלי A), ירדנו ל1.2 גיגהביט וזה עדיין לא מספיק.

אז איך בדיוק הסרט זז חלק על רשת של 1 גיגה ביט?

עדכון:
שמתי לב שmplayer מדווח על הפרמטרים המדוייקים של הסרט:
[code]
VIDEO: [avc1] 1920×800 24bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
1920x800x3x23.976×8=883,851,264
[/code]
שכבר מסתדר מצויין עם מה שראיתי ומדדתי.

איחוד פשוט של מספר מערכות קבצים בלינוקס

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

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

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

[code]
# mhddfs /mnt/500gb/,/mnt/200gb,//mnt/160gb /storage -o allow_other
[/code]

יוצר מערכת קבצים חדשה ב/storage, בנפח כולל של 775GB עם מקום פנוי כסכום המקום הפנוי בשלושת המחיצות:
[code]
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 459G 258G 179G 60% /mnt/500gb
/dev/sdb2 159G 17G 142G 11% /mnt/200gb
/dev/sda3 158G 138G 21G 87% /mnt/160gb
/mnt/500gb;/mnt/200gb;/mnt/160gb 775G 412G 341G 55% /storage
[/code]

כדי להגדיר את זה בfstab, נשתמש בשורה המוזרה הבאה (תחביר סטנדרטי לfuse) בfstab:
[code]
mhddfs#/mnt/500gb,/mnt/200gb,/mnt/160gb /storage fuse defaults,allow_other 0 0
[/code]

דרך חבילת הדביאן היומית.