הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
כתובת הייתה על הקיר - לקראת ההצבעה בכנסת על חוק המאגר הביומטרי
לא, שלא תבינו אותי לא נכון, אני ממש לא בעד הקמת המאגר הביומטרי שיש לו המון השלכות שליליות. אני עדיין מקווה שהחוק כפישהו לא יעבור...
כל מה רציתי לומר: "הכתובת מזמן הייתה על הקיר"
יש בעיה הרבה יותר עמוקה מהמאגר הביומטרי, הוא בסה"כ עוד שלב איבוד הפרטיות שחל בעולם כולו. רק שהפעם ממשלה החליטה לקחת בו חלק... זה היגיוני, עם בכל־כך הרבה מקומות נהנים מהמאגרים הביומרטיים, אז למה שהממשלה לא תיקח?
נתחיל, הנה ציטוט של ח"כ שטרית שהופיע ב־nrg.
בשדה התעופה יש מאגר [טבעות אצבעות] של 700 אלף איש
והנה כמה ציטוטים מאתר Facebook המפורסם:
More than 1 billion photos uploaded to the site each month
והנה הציטוט של מהכתבה של שחר שמש:
ארגון פשע שם מצלמה מעל דלת כניסה לבית בושת. כל מי שנכנס מצולם, תווי פניו משמשים לזיהויו במאגר הביומטרי, מאגר משרד הפנים (שכבר דלף) משמש כדי לבדוק האם הוא נשוי, ואם כן, מה היא כתובתו. אם הוא לא לקוח קבוע, כשבוע לאחר הביקור בבית הבושת דופק אדם בנימוס על דלתו, מגיש לו מעטפה חתומה עם תמונות, ודרישת תשלום.
ובואו נסכם:
- האם מישהו הכריח אותם לתת תביעת אצבע השדה התעופה כדי לזרז את תהליך המעבר הביקורת? אף אחד...
- האם מישהו הכריח אותם ליצור מאגר ביומטרי ענק של תווי פנים ההופכים את הזיהוי לקל ע"י תיוג מסודר? אף אחד...
- מישהו הכריח אותם לפרסם את מצבם האישי במאגר הביומטר הגדול בעולם? אף אחד...
אז אם נחליף את המילה "המאגר הביומרטי" ב־facebook או מאגר טביעות האצבעות הממשלתי במאגר שנמצא בשדה התעופה, מה ישתנה? שום דבר!
אז האם הבעיה היא החוק? או הבעיה היא הייתה עוד הרבה לפני? מפתיע, עד כמה הבעיה שתיארתי כאן לפני מספר חודשים צצה פתאום כשהכנסת החליטה "לטפל" בה.
לא, הבעיה היא לא החוק (אם כי אין לו הצדקה); האם באמת, פריצה למאגר והצלבת נתונים תהיה יותר קלה מהשגת מידע פרטי ביותר שכבר היום ניתן לעשות בקלות?
הבעיה היא אנחנו. אנחנו כבר מזמן ויתרנו בעצמנו על כל הפרטיות שלנו בעידן הדיגיטלי. כדי לראות את התמונות של חברים שלנו אנחנו פותחים חשבון ב־facebook עם התמונות המתויגות שלנו, כדי לעבור מהר בשדה התעופה אנחנו נותנים את טביעת האצבע שלנו, כדי לקבל הנחות בסופר אנחנו נותנים המון פרטים ולמעשה מאפשרים לעקוב אחרי הרגלי הצריכה שלנו.
למעשה, לא צריך לחוקק חוקים... פשוט כדי לחיות בחברה המודרנית, אנחנו מוותרים על הפרטיות והאנונימיות שלנו, כי זה מה שהסביבה דורשת והחברה כבר קיבלה את זה; ואם אתה לא מוכן לקבל את זה אתה תהיה כבשה שחורה.
אז מה לעשות? לוותר?
לא, אני מקווה שחוק המאגר הביומטרי כפישהו לא יעבור, כי ממש לא בא לי לתת טביעת אצבעות שלי לאף אחד (אפילו לצה"ל, אבל שם לא הייתה לי כל־כך ברירה). מה שהרבה יותר חשוב להעלות מודעות הציבור, כי לא צריך חוקים, לא צריך דליפות כדי לאסוף מידה שרובנו נותנים כל־כך בקלות.
Mono או לא Mono, זאת השאלה...
לאחרונה יש עשרות כתבות ודיונים בנושא Mono... הנושא מזכיר לי מאוד את "מלכודת ה־Java המפוסמת" שהייתה רלוונטית עד ש־Java שוחררה תחת רישיון חופשי ע"י Sun... רק שפה יש גם כמה נקודות נוספות:
| תכונה | Java | C# |
|---|---|---|
| מימוש סטנדרטי "דה־פקטו" | Sun | Microsoft |
| פורטביליות | גבוהה נתמכת ע"י Sun | רק עם מימוש של Mono |
| פטנטים | ??? | ישנם |
| מימוש חופשי שפת התכנות | מלאה | חלקי 2.0 מול 3.5 |
| מימוש חופשי של ספריה | 1.4--1.5 לעומת 1.6 | חלקי |
למעשה, היום, אם מסתכלים על Mono... אז יש איתו הרבה יותר בעיות בהשוואה למה ש־Java הייתה פעם (וגם זה כבר לא רלוונטי לאחר שחרור Java תחת GPL).
אבל נעזוב כרגע נושא של פטנטים, בעיות של שימוש בטכנולוגיה לא חופשית. יש בעיה הרבה יותר פרקטיות ומשמעותית:
- Mono, עם כל הכבוד לו (ויש כבוד) נגרר ומפגר בצורה משמעותית בהשוואה של טכנולוגית .Net של Microsoft. המצב של ספריה עוד יותר בעייתי. למעשה, היום להריץ יישום C# כפישהו מ־Windows על Mono לא יותר פשוט מאשר להריץ אותו על wine (אם לא יותר קשה).
- השחקן הראשי בפיתוח טכנולוגיית Net. לא מעוניין בהשקעה בפיתוח ב־Mono. למעשה, Microsoft לא מנסה להפוך את הטכנולוגיה שלהם ל־Cross-Platfor אלא רק "עוזרת" לעתים רחוקות לפרויקט Mono כשזה מאוד חשוב להם (כמו, תמיכה ב־SilverLight שמאפשרת להם להגיד שזאת טכנולוגיה Cross-Platform).
- מעבר לכך ש־C# היא שפה קצת יותר נחמדה מ־Java היא לא נותנת הרבה. רוצים משהו קל באותה מידה? תשמשו ב־D, Java או ב־Vala. לפחות הן טכנולוגיות בפני עצמן.
במילים אחרות... ל־Mono יש הרבה בעיות מעבר לבעיות המשפטיות, אז למה לעזאזל לתמוך בו? בשביל שפת תכנות נחמדה שיש רבות כמוה, או בשביל הספריות שלה שתפורות ל־Win32API?
גם אני נגד Mono... רק אולי גם מטעמים אחרים
תסריט פיתון להחלפת namespace של Boost.
הכנתי תסריט קטן שמאפשר שינוי גורף של Namespace עץ הקוד של Boost ל־Namespace חילופי כדי למנוע התנגשות בין גרסאות Boost שונות: http://art-blog.no-ip.info/files/rename.py.
הרצה: ./rename.py /path/to/boost/tree new_namespace_name
עכשיו כל ה־defineים וכל הסימבולים יימצא ב־namespace אחר ואפשר יהיה לבנות רכיבים ללא תלות בגרסת Boost.
הערות:
- השימוש על אחריותכם, גם אם זה יאכל לכם את החתול או יהרוס את כל הקוד במחשב שלכם.
- הוא עדיין די ראשוני, אבל הצלחתי לקמפל רוב הספריות החשובות ולהריץ כמה regression tests.
את התסריט כתבתי לפתרון אפשרי לבעיה שהצגתי במאמר הקודם
דברים שלא נאמרים על Boost.
או ליתר דיוק, לא מודגשים לגביו.
http://boost.org היא אחת הספריות הפופולריות ביותר ב־C++, היא מהווה ל־C++ מה ש־JDK מהווה ל־Java, מה ש־RTL ו־FCL מהווים ל־FreePascal, היא מה ש־Python Standard Library מהווה ל־Python.
היא, למעשה, הספרייה שנותנת את הכלים העשירים הנדרשים לעבודה, מעבר לגרעין הקטן של השפה. בפרט:
- תמיכה ב־Threads.
- עבודה עם socketים.
- כלי עיבוד טקסט.
- ביטויים רגולריים.
- עבודה עם זיכרון משותף.
- ועוד.
היום, היא בהחלט מהווה דה־פקטו סטנדרט בתחום C++, כך שחלקים גדולים ממנה כבר נכנסו ל־STL הבא של C++.
יחס עם זו. יש לה חיסרון אחד עצום שבמקרים רבים לא מורגש ע"י מפתחי יישומים, אבל כן מורגש ע"י מפתחי ספריות ו־toolkitים שונים. החיסרון הוא העדר תאימות כלשהי של ABI לאחור והעדר תאימות מלאה של API לאחור.
המשך...השוואת FPC ושפות אחרות
נתחיל מהטבלה שמשוואה מספר שפות תכנות פופולריות: Python, Java, C, C++ ו־FPC. כאשר אני מתמקד במספר רבדים: תכונות שפה מרכזיות, סגנונות פיתוח ותכנות אפשריים, ספריות וספקים.
השוואה לפי תכונות:
| Feature | Python | Java | C | C++ | FreePascal |
|---|---|---|---|---|---|
| Core: | |||||
| Memory man. | Automatic | Automatic | Manual | Semi-Automatic | Manual |
| Resources man. | Automatic1 | Manual | Manual | Semi-Automatic | Manual |
| Inheritence | Multiple | Sinlge | No | Multiple | Single |
| Polymorphizm | Duck | Dynamic | No | Dynamic+Static | Dynamic |
| Reflection | Yes | Yes | No | No | No |
| Language Features | |||||
| Generic Programming | Irrelevant | Limited | No | Turing Complete | Limited |
| Generic methods | Irrelevant | Yes | No | Yes | No |
| Requires interfece | Irrelevant | Yes | - | No | No |
| Functional Programming | Yes | Very Limited | No | C++03 Limited C++0x Full | None |
| Libraries: | |||||
| Standard: | Rich | Rich | Poor | Limited | Rich |
| conteiners | Yes | Yes | No | Yes | Yes |
| threading | Yes | Yes | No | No | Yes FCL |
| GUI | Yes | Yes | No | No | Yes LCL |
| 3rd party libs.: | Rich | Rich | Rich | Rich | Poor |
| Other: | |||||
| Standards | None | Yes | Yes | Yes | Outdated |
| Implementations: | CPython, Jthon, IronPython | GNU, Sun, IBM | Lots | Many: GNU, MS, HP, Sun, Intel... | Single |
| Defacto-Vendor | Yes: CPython | Yes: Sun | None | None | FPC |
| Performance | Poor | Medium | High | High | High |
הערות:
- רק ב־CPython.
סיכום:
- Python: נותנת לעבוד עם כל סגנונות פיתוח אפשריים, קל לפיתוח וניהול משאבים, אבל סובל משתי בעיות עיקריות: ביצועים ו־vendor lock in.
- Java: שפה יחסית מגבילה מבחינת הגישה שלה, אבל בטוחה לפיתוח ותכנות בזכות: GC, ספריה סטנדרטית מאוד עשירה פשטות השפה.
- C: שפה שכמטע ולא מספקת כלים "מודרניים"... כבודה במקומה מונח, ועדיין יש לה המון יישומים במיוחד בתחום embedded, או כל תחום אחר בו צריך לרדת לרמת תכנות נמוכה ולשמור על קומפקטיות וקריאות של הקוד.
- C++: שפה מאוד עשירה, הרכיבים המודרניים היחידים שחסרים לה זה: העדר Reflection, העדר GC מלא (אם כי ב־C++ RAII מחליף אותו בהצלחה) ואולי צורך בספריות צד ג'. כמובן עם הכוח בא גם החיסרון: שפה מסובכת שלוקח זמן ללמוד אותה לעומק ולהבין את הרבדים השונים שלה.
- עכשיו הגיע תורה של FPC: היא נמצאת איפשהו בין C לבין Java:
- מצד אחד, אין לה GC ומצד שני אין לה גם RAII שיש ב־C++, ניהול המשאבים שם ידני לחלוטין ממש כמו ב־C.
- יכולות הירושה מוגבלות לירושה בסגנון C#/Java.
- תמיכה ב־Generics מוגבלת, אין תכנות פונקציונלי (במובן lambda calculus) וגם אין Reflection.
- ספריה סטנדרטית די עשירה (אם לוקחים גם FCL ו־LCL), אבל העדר ספריות צד ג' כואב, הרבה יותר
נשאלת השאלה: מהו הערך המוסף ש־FreePascal נותנת מעבר לתחביר שנחשב לקצת יותר קריא? נדמה שלא הרבה.
