הבלוג של ארתיום :: תכנה חופשית

ל־CppCMS יש קהילה פעילה

בחודש חודשיים אחרונים אני רואה פעילות ערה מסביב ל־CppCMS. רשימת התפוצה הפכה להיות פעילה, דיווחי באגים מגיעים ואפילו…

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

האמת היא, אני שמח ש־CppCMS לאט־לאט צובר תאוצה והקהילה נבנית מסביבו.

המשך...

למה להמציא גלגל מחדש זה לא תמיד עובד טוב

לאחרונה אני מנסה להגר ל־CMake מ־autotools בפרויקט CppCMS בעיקר כדי להבטיח תמיכה טובה יותר בסביבת Windows ובפרט ב־MSVC מתישהו בעתיד.

עשיתי כבר הרבה עובדה והענף הניסיוני עבר ל־CMake. אפילו לא מעט אנשים ברשימת התפוצה התלהבו מהעובדה שהמערכת תעבוד על CMake… רבים חוץ ממני. אחרי שהתחלתי לעבוד אתה בצורה יותר עניינית הבנתי: היא באמת יותר מוצלחת בפיתוח ל־Windows מאשר autotools בעיקר בגלל שהיא קצת יותר גמישה בנושא ה־exports וכמובן התמיכה ב־MSVC.

אבל פה בערך נגמר היתרון. עכשיו אני אתלונן על דברים שמעצבנים אותי:

המהירות שאנשי CMake מתלהבים ממנה זאת גם עקב אכילס שלה. יש לזה מספר נקודות:

ב־autotools הייתה הפרדה ברורה בין automake שמגדיר את מבנה הפרויקט לבין autoconf שמגדיר את קונפיגורציית הפלטפורמה. מצד אחד זה היה קצת מפריע אבל מצד שני זה היה מאוד נוח: הוספת קובץ חדש לא פרויקט לא דרשה הרצת configure מחדש מצד אחד, מצד שני כל שינוי בצורת הקונפיגורציה ביצע הרצת configure שלמה.

לעומת זאת, CMake אף פעם לא מנקה את ה־Cache שלו (אלא אם אתה עושה את זה במפורש). מה שגורם לכך ששינויים בקונפיגורציה לא תמיד יבואו לידי ביטוי כי ב־cache שלו הוא זוכר משהו אחר (אולי בדיקה אחרת לא תקינה).

מצד שני, אם אני מוחק CMakeCache ומעדכן את CMakeLists.txt הוא לא זוכר את הפרטרים המקורים שהרצתי אתו את cmake כמו "איפה נמצאות הספריות או איזו אופציה שאני העברתי"
מנגנון מעקב אחרי התלויות של CMake לא בודק את הקובץ config.h משמע… אם עשיתי שינויים בקונפיגורציה הקוד לא ייבנה מחדש. צריך להריץ make clean ו־make שוב! העיקר שיש להם cache חזק.

הרבה מגנונים הקיימים לוקים בחסר או לא מתוכננים היבט. לדוגמה:

משהו מאוד פופולרי כמו AC_SEARCH_LIBS שמאפשר לך לבדוק אם פוקנציה מסוימת קיימת, אם כו אז אל תעשה דבר, חפש אותה בספריות. דוגמה קלאסית. pthreads, iconv, dlopen, socket שלפעמים מהווים חלק מהספרייה הסטנדרטית ולפעמים דורשים ספריות חיצוניות. אין פונקציונליות כזו בכלל.
בדיקת sizeof היא בכלל פנינת CMake. יש לה מספר בעיות:
- היא נעשית ע"י הרצת קוד מה שאומר היא לא תעבוד בקרוס־קומפילציה. כאשר ב־autotools עושים טריק מאוד יפה המאפשר לבצע בדיקה כזו ללא הרצת קוד אלא קומפילציה בלבד.
- היא לא מאפשרת להוסיף header כך שלא ניתן לבדוק sizeof של טיפוסים הנמצאים ב־includes לא סטנדרטיים.
אין פונקציונליות דומה ל־AC_ARG_ENABLE המאפשרת להציג רשימת הפרמטרים לקונפיגורציה והערות לגביהם – קרי אין כלי כמו ‎./configure –help שמאוד עוזר בהרבה מקרים.

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

אני מקווה שיום אחד autotools ידעו לתמוך גם ב־MSVC בסה"כ זה לא אמור להיות מי יודע מה מסובך… ICU משתמשים ב־autotools יחד עם MSVC בצורה מוצלחת למידי (למעשה הבעיה היא אפילו לא automake ו־autoconf הם דווקא איכשהו עובדים עם הקומפיילר, (הוא מסתבר כן תומך בהרבה דגלונים הרגילים כמו "‎-o -I" ועוד) הבעיה היא בעיקר libtool.

במילים אחרות… אם אתם לא מתכוונים לתמוך ב־MSVC תתרחקו מ־CMake, אבל ממש תתרחקו ממנו.

המשך...

תכירו Boost.Locale

אחרי תהיות עמוקות על תמיכה בלוקליזציה ב־C++‎, הבנתי שלא ניתן יהיה ללכת איתה רחוק. לקחתי ICU והתחלתי לעטוף אותו בסביבה ידידותית לתכנות C++‎ מודרני.

אחרי הרבה עבודה הבנתי… כל מה שאני עושה יהיה שימושי הרבה מעבר ל־CppCMS ולכן החלטתי להכין ספריה נפרדת שמטפלת בלוקליזציה במטרה לשלב אותה ב־Boost. כך נולד Boost.Locale שנותנת כלים פשוטים וחזקים לעבודה עם לוקליזציה.

דוגמה פשוטה שתבהיר את החשיבותה ועוצמתה. הנה קטע קוד שמציג למשל את תאריך המאמר באתר:

out << format(translate("{1}, posted  at {2,date} on {2,time} by {3}"))
          % title % date % author;

ועכשיו המתרגם יכול לתרגם את המשפט לצורה הבאה:

"{1}, פורסם ב{2,locale=he_IL@calendar=hebrew,date} ‏(לועזי {2,date}) ב־{2,time} ע"י {3}"

מה קרה כאן? התצוגה באנגלית תהיה

‎Some article was published at 11/8/2009 on 10:30 PM by somebody

כאשר התצוגה בעברית תהיה

מאמר מסוים פורסם בכ"א בחשון התש"ע (לועזי 08/11/2009) ב־22:30 ע"י מישהו

למעשה, בלי שימוש ב־libhdate, בלי לעבוד קשה מידי, קיבלתי אפשרות להציג את התאריך העברי והלועזי לפי הלוקל העברי, רק בגלל ש־ICU תומך בלוח־השנה העברי.

למעשה, עבזרת Boost.Locale ניתן לעשות המון דברים בצורה פשוטה. למשל:

cout << as::spellout << 123 <<endl;

יידפיס בלוקל עברי

מאה עשרים ושלוש

יאפשר לחלק מילה "שָלוֹם" לארבעה תווים בהתחשב בניקוד: "שָ", "ל", "וֹ" ו־"ם" ועוד. למיין טקסט בצורה נכונה ועוד עשרות פעולות חשובות שניתנות ע"י ICU רק בצורה נוחה וטבעית ל־C++‎.

תכירו Boost.Locale:

תיעוד http://cppcms.sourceforge.net/boost_locale/docs/.
תיעוד מפורט של פונקציות ומחלקות: http://cppcms.sourceforge.net/boost_locale/docs/doxy/html/
קוד מקור (דרך svn)‏ https://cppcms.svn.sourceforge.net/svnroot/cppcms/boost_locale/trunk

תהנו, אשמח גם לתגובות.

המשך...

על תמיכה בלוקליזציה ב־C++‎ ועל תקן שבור

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

אבל נשאר מקום אחד שבו C++0x כמעט ולא נגע, אפילו שהתקן שבור לחלוטין – לוקליזציה…

לצורך הדגמה בואו נכתוב תכנה טרוייואלית שמדפיסה מספר לקובץ טקסט number.txt:

#include <iostream>
#include <fstream>
#include <locale>


int main()
{
        // Set global locale to system default;
        std::locale::global(std::locale(""));

        // open file "number.txt"
        std::ofstream number("number.txt");

        // write a number to file and close it
        number<<13456<<std::endl;
}

תכנה פשוטה אפילו טריוויאלית. עכשיו בואו נעשה אותו דבר ב־C.

#include <stdio.h>
#include <locale.h>

int main()
{
        setlocale(LC_ALL,"");
        FILE *f=fopen("number.txt","w");
        fprintf(f,"%'i\n",13456);
        fclose(f);
        return 0;
}

גם פשוט ביותר.

בואו נריץ את התכנות כאשר הלוקל הוא en_US.UTF-8… ונקבל בקובץ number.txt את המספר: 13,456, עכשיו נעשה אותו דבר, רק נגדיר לוקל נפוץ אחר ru_RU.UTF-8‏: כך LC_ALL=ru_RU.UTF-8 ./a.out ונקבל:

 ‎13<?>456

כאשר אם נריץ תכנה ב־C נקבל דווקא משהו נכון: ‎13 456

אופס… מה קרה כאן? כשאני עושה את אותו הדבר דרך C ודרך C++‎ אני מקבל תוצאה שונה, יותר מזה, הפלט של תכנה שכתובה ב־C++‎ מצביעה על טקסט UTF-8 לא תקין! (אפשר לבדוק בקלות עם iconv).

מה בעצם קראה כאן?

לפי הגדרות הלוקל הרוסי. התו שמפריד בין אלפים ומאות הוא תו U2002 – ‏ EN SPACE – סוג של רווח שונה מרווח ASCII רגיל U0020. כלומר בגלל שמדובר בתו Unicode שהוא לא בתחום ASCII הוא צריך להיות מקודד כמחרוזת ארוכה מבית 1.

אז למה ספריית C מתמודדת יפה מאוד עם בעיה זו וספריית C++‎ לא?

עכשיו בואו נסתכל בהגדרות הסביבה להצגת מספרים: המחלקה ‏std::numpunct‎ מייצגת את סימון ההפרדה thousands_sep‏ כבית בודד! לכן אין שום סיכוי לייצג תו Unicode U2002, לעומת זאת, ספריית C, מייצגת את סימון ההפרדה כמחרוזת ולא כתו בודד. מכאן, אין שום בעיה לייצר מספרים.

זאת הייתה דוגמה של בעיוה הטריוויאלית לשחזור. קיימים עוד בעיות עקרוניות רבות כאלה בתקן לוקליזציה הקיים ב־C++‎ היום. חבל שהוועדה שמטפלת ב־C++0x כלל לא התייחסת לנושא זה — אולי הגיע זמן להעלות את הנושא?

המשך...

ייסורי בינאום ולוקליזציה בשנת 2009

מה יותר פשוט מאשר להציג תאריך ושעה בהתאם למקובל באיזור? בארה"ב תכתוב ‎6/15/2008 8:30 PM ובישראל תכתוב 15/6/2008 20:30. לא מסובך, נכון? כמובן ‎strftime‎ עושה את העבודה הנאמנה בצורה טובה. אכן, יש אופציות ‎"%x"‎ ו־‎"%X"‎ להצגת תאריך ושעה בהתאם ללוקל מקומי.

עכשיו בואו נעשה את הדרך ההפוכה: יש לנו טופס HTML בו אנחנו רוצים להציג תאריך ולתת למשתמש אפשרות לערוך אותו? במילים אחרות אני רוצה אופציה של פענוח תאריך ושעה לפי התבנית המקובלת לאיזור ובשפה הספציפיים… ואכן, יש פונקציה הפוכה ל־strftime ‏— strptime. שעושה את העבודה ההפוכה.

כמובן גם ב־C++‎ יש מקבילות std::facet מסוג: std::time_put ו־std::time_get עושות את העבודה וגם מאפשרות להשתמש ביותר מ־locale אחד בתהליך, שמאפשר, למשל לייצר טקסט שונה למשתמשים שונים בחוטים שונים. ב־C ובשירותי מערכת ההפעלה הסטנדרטיים אין כלי כזה, יש רק strftime_l ו־strptime_l הלא מתועדים ולא מוגדרים לפי סטנדרט שעושים את העבודה.

מכאן, הכל פשוט… על הנייר. במציאות המצב הרבה יותר מסובך:

הגדרות סטנדרט C++‎ של std::time_get מכילות באג לוגי שמקשה מאוד על יצירת כלים לפענוח תאריך ושעה בצורה נכונה וגם כשעובדים, הם עושים זאת בצורה חלקית — כי אין מקבילה של strptime המלאה של C.
גם API של C, מסתבר כלא תמיד עובד כמו שצריך.

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

    en_US.UTF-8
    strftime        10/05/2009 11:36:38 PM to 2009-10-05 23:36:38
    std::facet      10/05/2009 11:36:38 PM to 2009-10-05 00:00:00
    icu::DateFormat Oct 5, 2009 11:36:38 PM to 2009-10-05 23:36:38
    he_IL.UTF-8
    strftime        05/10/09 23:36:38 to 2009-10-05 23:36:38
    std::facet      05/10/09 23:36:38 to 1909-10-05 23:36:38
    icu::DateFormat 23:36:38 05/10/2009 to 2009-10-05 23:36:38
    de_DE.UTF-8
    strftime        05.10.2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05.10.2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.10.2009 23:36:38 to 2009-10-05 23:36:38
    en_GB.UTF-8
    strftime        05/10/09 23:36:38 to 2009-10-05 23:36:38
    std::facet      05/10/09 23:36:38 to 1909-10-05 23:36:38
    icu::DateFormat 5 Oct 2009 23:36:38 to 2009-10-05 23:36:38
    ja_JP.UTF-8
    strftime        2009年10月05日 23時36分38秒 to 2009-10-05 23:36:38
    std::facet      2009年10月05日 23時36分38秒 to 2009-10-05 23:36:38
    icu::DateFormat 2009/10/05 23:36:38 to 2009-10-05 23:36:38
    ar_EG.UTF-8
    strftime        05 أكت, 2009 IST 11:36:38  to 2009-10-05 00:00:00
    std::facet      05 أكت, 2009 IST 11:36:38  to 2009-10-05 11:36:38
    icu::DateFormat ٠٥/١٠/٢٠٠٩ ١١:٣٦:٣٨ م to 2009-10-05 23:36:38
    tr_TR.UTF-8
    strftime        05-10-2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05-10-2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.Eki.2009 23:36:38 to 2009-10-05 23:36:38
    ru_RU.UTF-8
    strftime        05.10.2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05.10.2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.10.2009 23:36:38 to 2009-10-05 23:36:38
    zh_CN.UTF-8
    strftime        2009年10月05日 23时36分38秒 to 2009-10-05 23:36:38
    std::facet      2009年10月05日 23时36分38秒 to 2009-10-05 23:36:38
    icu::DateFormat 2009-10-5 下午11:36:38 to 2009-10-05 23:36:38

כפי שניתן לראות:

std::facet לא מתמודד עם שעון של 12 שעות המכיל ציון AM/PM.‏
std::facet לא מוסוגל לשחזר שנה בעזרת שתי ספרות בלבד וזורק אותנו משנת 2009 ל־1909 ב־2 מתוך 9 דוגמאות.
strptime לא מצליח לשחזר שעה בכלל ו־std::facet וטועה ב־12 שעות בלוקל מצרי.יש לציין שזה באג בייצוג locale כי הפורמט המוגדר הוא ‎"%Z %I:%M:%S"‎ במקום ‎"%p %I:%M:%S"‎ — להציג איזור זמן במקום סימון AM/PM המתאים (م).

במילים אחרות… מימוש של std::facet גרוע, יש בעיות בייצוג locale באופן כללי.

עצוב שזה המצב בשנת 2009…

המשך...

נפלאות ה־Comet בשרתי האינטרנט המודרניים...

כפי שפרסמתי לאחרונה, אני עובד על תמיכה ב־Comet או HTTP Push ב־CppCMS. כאשר הכוונה לאפשרות שרת האינטרנט ליידע את הלקוח על אירוע חדש, למשל: "הגיעה מסר מידי חדש, או מחיר המניה השתנה" – למעשה להעביר אירועים ללקוח בזמן אמת.

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

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

אבל, מה קורה אם הלקוח סוגר את הקשר לפני שהוא מקבל תשובה? בבקשות HTTP רגילות זה אירוע נדיר והיישום בצד השרת יכול בקלות "להתעלם" ממצב כזה. ביישומי Comet זה שונה: מספיק שמישהו נכנס לאתר שמחכה לדף שמבצע בקשה מסוג זה ויוצא ממנו, הקשר לקבלת עדכונים ייסגר.

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

אבל מה? יישום ה־Comet בד"כ לא מדבר ישירות עם הלקוח בעזרת HTTP אלא מדבר עם שרת web בעזרת פרוטוקול סטנדרטי כמו FastCGI או SCGI. לכן, תפקידו של השרת הוא לדווח ליישום על כך שהלקוח סגר את הקשר. למעשה פרוטוקול FastCGI מגדיר במפורש דרך להפסיק בקשה מסויימת ע"י סגירת ה־socket או שליחת בקשה מיוחדת "Abord Request", כנ"ל ניתן לבצע בעזרת scgi ע"י ניתוק ה־socket.

פשוט? כן. האם זה קורה בפועל? לא ממש.

אחרי שמימשתי מערכת ניתוק הקשר ובדקתי אותה על שרת http פנימי, החלטתי לבדוק את ההתנהגות של שרתי web אמתיים: Lighttpd,‏ Nginx ו־Apache2. מה שגיליתי היה ממש לא נעים: למעט Nginx אף שרת לא מדווח על ניתוק הקשר לא מעל FastCGI ולא מעל SCGI.

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

Nginx הוא היחיד דיווח על כך ליישום FastCGI באופן מידי ואפשר לי לטפל בלקוח ש"נעלם"
Apache דיווח רק אחרי timeout ארוך של כדקה הן ב־FastCGI והן ב־SCGI.‏
lighttpd בכלל שכח מזה והחזיק קשרים פתוחים כל הזמן – יותר מזה בירידה, הוא התלונן על כך שהיישום שלי "נעלם" ולא ענה לבקשת השרת (שאין לו כבר למי להעביר אותה).

בקיצור… זה היה מאוד מאכזב. אני הייתי מוכן לקבל את זה מ־Apache שידוע כשרת שלא נועד לטפל בהרבה קשרים פתוחים, אבל Lighty? פתחתי על זה באג.

מזל שמימשתי שרת HTTP פנימי בעצמי.

המשך...

CppCMS פוגש Comet

פרסמתי כאן כתבה על טכנולוגיית Comet (או Server Push) הנתמכת בגרסה הבאה של CppCMS.

הצגתי כדוגמה קלאסית: מימוש של יישום Chat, בצד הלקוח ובצד השרת, בכ־50 שורות קוד בכל אחד מהם, עם שימוש ב־XHR Long Polling.

המשך...

חדשות CppCMS...

לאחרונה אני עובד בענף ה־refactoring של CppCMS ומבצע שינויים גדולים. אביא כאן סקירה קצרה של השינוי שכבר נמצאות בגרסה ניסיונית:

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

חלק מהספריות הוסרו בגלל אי תאימות לדרישות החדשות:
- libfcgi ירד כי ה־API שלו לא מאפשר גישה א־סינכרונית, במקומו, מימשתי את הפרוטוקול בעצמי על בסיס Boost.Asio.
- ספריית CgiCC ירדה בגלל האיכות הירודה שלה וחוסר יכולת סבירה לתקשר עם המפתח של אותה הספרייה הבעייתית.
כך שבגרסה הבאה, תהיה לי אפשרות להכין debים ו־rpmים בקלות…
עד היום, פיתוח מול CppCMS דרש שימוש בשרת חיצוני, למרות שיש לי סקריפט הפעלה אוטומטית של lighttpd, ‏nginx ו־Apache, עכשיו מימשתי שרתי HTTP פנימי פשוט שמקל על הפיתוח ובנוסף, עתיד יקל על שיבוץ התשתית ביישומים שדורשים ממשק web ובמערכות משובצות מחשב.

כך שכיום, CppCMS החדש תומך בשלושה ממשקים FastCGI,‏ SCGI ו־HTTP.‏
התווספה תמיכה מסודרת בלוקליזציה עם שימוש ב־std::locale, כך שתצוגת התאריכים, מספרים, מחרוזות וכד' יתבצעו בהתאם למקובל באותה שפה.
בגלל שימוש מקיף ב־Boost – ספריה בלתי תלויה בפלטפורמה, אני סוף־סוף אוכל להכריז על Windows כפלטפורמה שנתמכת באופן (חצי) רשמי.

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

אבל לאט־לאט ההשפעה של השינויים הארכיטקטוניים מתחילים להתבהר.

המשך...

לתמוך או לא לתמוך, זאת השאלה (ב־Win32)?

כפי שפרסמתי בעבר, אני עובד על שינויים בפנימיים עמוקים ב־CppCMS שבין השאר יאפשרו:

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

בגלל שאני עושה שינויים כל־כך מהותיים, חשבתי, אולי להוסיף גם תמיכה בעוד פלטפורמה בנוסף לתמיכה ב־Linux,‏ FreeBSD,‏ Solaris ו־Cygwin… להוסיף תמיכה ב־Windows.

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

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

המשך...

כתובת הייתה על הקיר - לקראת ההצבעה בכנסת על חוק המאגר הביומטרי

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

כל מה רציתי לומר: "הכתובת מזמן הייתה על הקיר"

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

נתחיל, הנה ציטוט של ח"כ שטרית שהופיע ב־nrg.

בשדה התעופה יש מאגר [טבעות אצבעות] של 700 אלף איש

והנה כמה ציטוטים מאתר Facebook המפורסם:

More than 1 billion photos uploaded to the site each month

והנה הציטוט של מהכתבה של שחר שמש:

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

ובואו נסכם:

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

אז אם נחליף את המילה "המאגר הביומרטי" ב־facebook או מאגר טביעות האצבעות הממשלתי במאגר שנמצא בשדה התעופה, מה ישתנה? שום דבר!

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

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

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

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

אז מה לעשות? לוותר?

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

המשך...