לינוקס לאמא

סידרתי לאמא שלי מחשב, ועליו לינוקס בלבד.
המחשב די ישן, אבל בהחלט מספיק: פנטיום 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]

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

IP2C 2.0.0

שחררתי גרסא חדשה של IP2C, מהירה מתמיד וגם תומכת בבסיס הנתונים של Software77.

[code]
All tests done on an Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GH
PHP:

* No cache: 5000 searches/sec (Fast startup, slow query)
* Memory cache: : 5700 searches/sec (Slow startup, fastest query)

Java:

* No cache: 13900 searches/second. (Fast startup, slow query)
* Memory mapped file: 265k searches/second. (Fast startup, fast query)
* Memory cache: 281k searches/second. (Slow startup, fastest query)
[/code]

Antenna processor -> MTJ

הPreprocessror שפיתחתי במסגרת העבודה של בVollee, שנכלל בפרוייקט הקוד הפתוח אנטנה (פרוייקט שעוזר בפיתוח ובבניה של ישומי ג'אווה למכשירים סלולריים), אושר על ידי Eclipse Legal, ויכלל בMTJ.
MTJ הוא פרוייקט Eclipse רשמי שמטרתו להוסיף לEclipse תמיכה בפיתוח ישומי ג'אווה למכשירים סלולריים. כבר היום יש את EclipseME, פלאגין שפותח במשך שנים על ידי קרייג סטרה, שעושה את אותה עבודה – למעשה וקרייג עובד עם צוות MTJ, וMTJ מיועד להיות תחליף רשמי של EclipseME.
תהליך הקליטה של הPreprocessor לא היה קל:
הקוד המקורי הסתמך על ANTLR 2.7 (שמייצר אוטומטית קוד לפענוח קוד לפי הגדרה פורמלית – Parser generator) – הבעיה עם ANTLR 2.7 היתה שהרשיון שלו לא תאם את הרשיון של Eclipse (מסתבר שPublic domain זה לא תמיד טוב מספיק). למרבה המזל, ANTLR 3.0 כבר שוחרר ברשיון BSD שתאם את הרשיון של Eclipse, אבל הוא לא תאם את הקוד של הPreprocessor.
החב'רה בMTJ שאלו אם אני מוכן להמיר את הקוד כך שישתמש בANTLR 3.0: בינתיים עזבתי את Vollee ואת כל העולם של הפיתוח לסלולריים (בשעה טובה ומוצלחת) אז סירבתי, אבל אמרתי שאשמח לייעץ להם ולעזור מרחוק.
הם הרימו את הכפפה, וכמעט בלי עזרה מפתח אחד – דייגו סנדין – המיר את העסק לANTLR 3.0 תוך כשבועיים.
הזמן עבר, ולפני חודשיים צוות MTJ קיבל אישור למסור לי את הקוד, כדי שאקלוט אותו לתוך Antenna.
מכיוון שהקוד כלל בדיקות יחידה מקיפות, שדייגו הקפיד להשתמש בהן כדי לבדוק את ההמרה – התוצאה היתה טובה מאוד.
עוז זמן עבר, והיום הקוד קיבל אישור מEclipse Legal ויכנס לענף הראשי של MTJ.

יבוא SQL ישירות מתוך קוד ג'אווה

כשכותבים בדיקת יחידה (Unit test) לקוד שקשור לבסיס נתונים, צריך לאתחל את בסיס הנתונים לאיזה שהוא מצב ידוע ויציב לפני כל בדיקה.
מול MySQL, אפשר להשתמש בmysql עצמו כדי ליבא סקריפט SQL מוכן, אבל זה לא נחמד במיוחד:
צריך לפתוח תהליך חדש, ויש כל מני בעיות מעצבנות עם זה (בג'אווה למשל, חובה לקרוא את הפלט של התהליך, אחרת הוא יתקע בכתיבה לפלט הסטנדרטי כשיתמלא הבאפר).
הרבה יותר נחמד יהיה ליבא את הקובץ ישירות מתוך ג'אווה, בשימוש בJDBC, לא?
הנה קוד שעושה בדיוק את זה, הוא מקבל זרם קלט (InputStream) שיכול להיות כל דבר, וגם Connection JDBC שחיברתם מבעוד מועד, וקולט את הSQL לתוך בסיס הנתונים.
הקוד מתמודד עם הפלט הסטנדרטי של mysqldump.

[code lang="java"]
public static void importSQL(Connection conn, InputStream in) throws SQLException
{
Scanner s = new Scanner(in);
s.useDelimiter("(;(\r)?\n)|(–\n)");
Statement st = null;
try
{
st = conn.createStatement();
while (s.hasNext())
{
String line = s.next();
if (line.startsWith("/*!") && line.endsWith("*/"))
{
int i = line.indexOf(' ');
line = line.substring(i + 1, line.length() – " */".length());
}

if (line.trim().length() > 0)
{
st.execute(line);
}
}
}
finally
{
if (st != null) st.close();
}
}
[/code]

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

משתמש תרם שיפורי ביצועים משמעותיים לIP2C

אם יש משהו שאני אוהב בפרוייקטי קוד פתוח, זה שאנשים מוכנים לפעמים לעבוד די קשה כדי לשפר אותם.
את IP2C, ספריה למציאת המדינה של כתובת IP שחררתי לפני כמעט שנתיים, וכתבתי גם פוסט שמספר על המימוש שלה פה.
IP2C ממומשת בPHP ובג'אווה. מה שמיוחד בה זה שהיא מסוגלת לחפש ישירות על הקובץ, מה שאומר שחיפוש בודד הוא מאוד מהיר כי לא צריך להעלות את כל הקובץ לזכרון.
הייתי לגמרי מרוצה מהביצועים של הספריה בPHP (כ1200 חיפושים בשניה במחשב האחרון שמדדתי), אבל הביצועים בג'אווה היו טובים יותר משמעותית – כ8000 חיפושים בשניה על אותו מחשב בעבודה ישירות על קובץ הנתונים.
ההבדל בביצועים בין PHP לג'אווה לא הטריד אותי, כי היה לי ברור שPHP תהיה יותר איטית מג'אווה, אבל הוא כן הטריד את תומס רומר שהתיישב על העסק לילה שלם ושיפור את הביצועים של גרסאת הPHP ב150%.
תומס כתב פוסט מעניין על השינויים שהוא עשה, ושלח לי את השינויים. שבמבט ראשון נראים טובים ואני אקלוט אותם לפרוייקט אחרי בדיקה מעמיקה יותר.

בנוסף דיברנו קצת בIRC, והוא יעבוד על תמיכה בבסיס הנתונים של software77 :
software77 מספקים בסיס נתונים של IP למדינה, שאמור להיות יותר איכותי מבסיס הנתונים שIP2C משתמשת בו כרגע (webhosting.info), אבל יש להם קצת בעיות בעקביות המידע.
התחלתי לעבוד על תמיכה בבסיס הנתונים שלהם לפני כמה חודשים טובים, אבל כשראיתי שזה נמשך יותר מדי הקפאתי את העסק (שעדיין נמצא בTODO שלי, קבור איפשהו 🙂 )
תומס ימשיך מאיפה שהפסקתי.

iFuse

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

קצרים

מייקרוספט תורמת 100,000 דולר לקרן התוכנה של אפאצ'י.
המהלך הופך את מייקרוסופט לספונסר פלטינום כמו גוגל ויאהו.

שאלתי כבר, האם מייקרוסופט משתנה?

——————–

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

עוד על זה כאן.

רשת ג'יגהביט

הנתב הקודם – 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]
שכבר מסתדר מצויין עם מה שראיתי ומדדתי.