ארכיון חודשי: אוגוסט 2011

pry

prypry הוא טרמינל רובי, אשר ממש דומה לirb למראית עין ראשונית, אבל הוא מכיל הרבה יותר יכולות ותכונות מאשר irb.

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

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

בימים האחרונים שהתחלתי לשחק איתו, אני חייב לציין כי הוא שינוי מרענן, מ IRB.

תעוד השימוש במסוף תוכלו למצוא בוויקי של הפרוייקט.

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

לינוקס לאנשי הווינדוז

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

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

אם אספק לכם התקן מערכת לWindows 95 שלא עבר התאמה ל Windows7 ו Win7 לא יכול לעבוד איתו, הבעיה היא לא בWindows אלא בחוסר התאמת ההתקן למערכת ההפעלה. כאשר אתם מספקים לי כלי אשר נבנה עבור הגרעין של לינוקס, לגרסת 2.6.18, ומצפים שאני אריץ אותו על גרסה 3.0, ובכן אתם עושים את אותו הדבר. יכול להיות שזה יעבוד, אבל יכול להיות שזה לא. הבעיה היא לא בגרעין, אלא בפיסת הקוד אשר לא מתוחזקת ומתאימה.

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

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

התקנת תוכנות מתבצעת על ידי מנהל חבילות. תפיסת העולם של מנהל חבילות קיימת מתחילת שנות ה90 בעולם הקוד הפתוח. זה התחיל עם ניהול קוד LaTex (נקרא ctan), המשיך במערכת הפעלה בשם FreeBSD (אשר נקרא ports), התקיים גם עבור שפת תכנות בשם Perl (עם cpan) וקיים כבר למעלה מעשור גם בלינוקס. אתם מכירים את זה בטח כ"חנות אפליקציות" (תגידו יפה תודה לחברת אפל), אשר מקור בודד להתקנה של הדברים. בוחרים מה רוצים, הוא מנהל תלויות עבורינו ומתקין בשבילנו את מה שצריך. יש הבטחה לאבטחה של התוכנות, ועולם כמנהגו מתקין תוכנות מותאמות להפצה. ישנם כמה סוגי תוכנות, ורק תוכנות אשר קשורות לגרעין, זקוקות להיות מותאמות לגרעין, תוכנות בצד המשתמש, ובכן לא קשורות לגרעין כמעט בכלל.

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

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

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

ברוכים הבאים ללינוקס.

Adhearsion

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

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

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

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

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

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

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

FPC JVM

יש מספר התפתחויות מאוד מעניינות עם FPC לאחרונה. דבר ראשון עובדים על תמיכה לעוד ארכיטקטורות מעבדים (חלקם הגדול שייכות ל ARM). דבר שני, הקפיאו את עץ הפיתוח של 2.5.1, מה שאומר שגרסה 2.6.0 צריכה לצאת בקרוב (שזה דבר יחסי כמובן). וכרגע עץ הפיתוח עומד על 2.7.1 .
יש דיבורים על כך, כי אולי יגרמו לפסקל (FPC וכנראה גם דלפי) להיות חלק מ Firebird SQL. כלומר שפה שאפשר לתכנת בה stored procedures, trigger וכו' … ממש כמו ב Pg, רק המטרה היא להימנע משפת C. אבל זה כמובן בשלב התאוריה בלבד. אם זה יתממש, אז זה יכנס ל Firebird 3.0.
אם זה לא מספיק, אז הסתבר כי Embarcadero – המפתחת של דלפי כיום, משתמשת ב FPC ולזרוס בשביל לפתח תוכנות גרפיות עבור iPad, בדגש על תכנת הסיוע שלהם לדיווח באגים.

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

כרגע, נכון לכתיבת הפוסט, חסר תמיכה בחלקים של בסיס השפה. היחידה שנקראת system – שהיא היחידה הבסיסית ביותר בפסקל, לא ממומשת עד סופה. גם ה RTL עדיין לא קיבל מימוש מלא. יש תחבירים בשפה שגם עוד לא קיבלו מימוש, וחלק גם לא יקבלו בשל מגבלות שפת Java. יש גם מספר מגבלות של פסקל מול ג'אווה, כדוגמת קוד מעגלי, אשר פסקל אינה תומכת בו (בצורה מכוונת), וכן עבודה עם namespace של ג'אווה, אשר כנראה כן ישתנה אבל בקרוב.

כמו כן, הוצג תחביר חדש בנוסף, על מנת להשתמש בספריות java מתוך קוד פסקל:

{$namespace x.y.z}
type
JavaClassName = class [external ['package.name'] [name 'ExternalClassName']] [(JavaSuperClassName|ProtocolName [, ProtocolName, ProtocolName])]
[strict][private, protected, public]
 [variables declarations]
 [method declarations]
end;

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

לעוד מידע בנושא, ניתן לגשת לדפי הוויקי בנושא.

שלום ולא להתראות גוגל+

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

הראשונה לשנות את השם ששמתי שם, השנייה היתה למחוק את החשבון, השלישית היתה למחוק לגמרי את כל החשבונות שלי מגוגל.

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

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

עקרון זהבה

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

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

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

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

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

הפוסט מוגש כחומר למחשבה.

Would you like to be FB maintainer ?

Several months ago, I removed myself as Firebird package maintainer at Arch Linux (AUR). The reason was lack of time by my side, and a lot of work is still needed to be made with the packages.

So I removed myself, in order to allow other person to take charge of it, but no one raised the orphan packages (and they are looking for a warm home, with good parent. Really, they are good packages), and AUR does not have very good FB packages because of it.

Would YOU like to be the package maintainer ? To follow the Firebird community, in sickness and in health ? To fix issues, and make the best effort to make it work for everyone ?

ניהול גמיש

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

הכוונה היא כמובן אספקת API אחיד, אבל לשנות את המימוש של הAPI הזה לפי מה שאנחנו רוצים. הדגמתי בעבר את cmem אשר בעצם מחליף את מנהל הזיכרון ברירת המחדל של ה RTL ומשתמש ב malloc של libc במקום. אבל FPC מאפשר לנו להחליף הרבה יותר מרק ניהול זיכרון. יותר מזה, ההחלפה היא לא עבור כל אפליקציה אלא רק עבור יחידה שנרצה שזה יהיה בה המצב, כך שאפשר להשתמש במנהל המתאים במקום המתאים.

שינוי המנהלים מתבצע על ידי שינוי רשומה המכילה API ועבודה עם פונקציות מתאימות לרישום הרשומה.
בברירת מחדל ניתן ליצור מנהלים חדשים עבור Variants, Threads, ניהול זיכרון, מנהלי משאבים (תמונות וכו' למשל אשר יכולות להיכנס לקובץ הריצה או חיצוניים מאוגדים לקובץ אחד), Unicode ו WideString.

מה שקורה הוא שעבור רשומה מסויימת יש callback אשר אנחנו צריכים "לאייש" בשביל שתהיה תמיכה כלשהי באותה פקודה. העניין הוא שאנחנו לא צריכים אבל לשכתב תכנה ולשים בה פתאום פקודות לא מוכרות. כלומר גם אם אני עובד עם ניהול זיכרון של cmem, אשר מנהל עבורינו את הזיכרון עם malloc, עדיין הפקודות שלי נשארות זהות, כלומר GetMem. הפקודה GetMem למעשה, בפועל מריץ את הcallback המתאים לפי מה שנרשם ליחידה בשימוש.

אז איך גורמים לכך שהרישום ישפיע על כל היחידה שאנחנו עובדים איתה אתם בטח שואלים, ובכן מגדירים את הרישום בחלק הInitialization (או begin, אם אתם "old-school") של היחידה:

...
implementation
...
Const
 CMemoryManager : TMemoryManager =
    (
      NeedLock : false;
      GetMem : @CGetmem;
      FreeMem : @CFreeMem;
      FreememSize : @CFreememSize;
      AllocMem : @CAllocMem;
      ReallocMem : @CReAllocMem;
      MemSize : @CMemSize;
      InitThread : nil;
      DoneThread : nil;
      RelocateHeap : nil;
      GetHeapStatus : @CGetHeapStatus;
      GetFPCHeapStatus: @CGetFPCHeapStatus;
    );

Var
  OldMemoryManager : TMemoryManager;

Initialization
  GetMemoryManager (OldMemoryManager);
  SetMemoryManager (CmemoryManager);

Finalization
  SetMemoryManager (OldMemoryManager);
end.

מתוך קוד המקור של cmem.

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

סיכום אוגוסט פנגווין 2011

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

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

חזון ללא מימוש הוא חלום בהקיץ. מימוש ללא חזון הוא סיוט

*הכותרת לקוחה ממשפט יפני מוכר

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

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

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

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