RaspberryPi alarm clock

Hey all,

So do you have a RaspberryPi not doing anything at home? Got that 2GB class 4 SD card that you just don’t know what to do with it? Well this guide is for you! It will let you turn your Pi in to an IOT alarm clock, no code, no complicated commands, just flash, edit two text files and you are good to go. The alarm clock is controlled from Telegram, so you can set it and turn it off from your smartphone. I find that usually using my phone wakes me up. So it’s useful for me. You can also edit the alarm and use any mp3 file you want.
The code is all available in github. AlarmBot is the Telegram Bot. An AlarmPi is the distro (built with CustomPiOS yet again).

Steps to install

1. Download the image here
2. Unzip and flash it to an SD card (small enough to fit a 2GB card)
3. While it downloads and flashes, let’s create a telegram bot and get a token for it!
   1. Send a message to bot father
   2. Send /newbot
      

      Setting a new bot

   3. Copy the telegram token that is in the last message
4. Open newly flashed image and edit two files, one for the wifi, and one for the bot token:
   1. Put in alarmpi-wpa-supplicant.txt your wifi address (skip if using Ethernet cable). Here is how it should look:
      
   2. In config.ini,  paste the newly created bot token from step 3. This is where the token goes:
      
   3. optionally, you can change the alarm.mp3 file to the sound of your choice.
5. Boot your pi and connect it to speakers, wait a bit, because it will reboot internally twice. And send /start to your bot.
6. You’re done! Let’s see how we can set alarm with telegram!

How to use the telegram bot

Once you got a reply to /start and you know the bot is working you can use “/help” to list all the available commands.

First, set the /timezone to your location, and make sure you can see the correct time with the /time command.

Now let’s set an alarm, type /new and you will get the option to pick an alarm that works daily or weekly (code contributions would be great to add more types of alarms).

Once you have alarms, you can manage them in the /list command.

You can disable, or delete commands using this menu. Selecting the bell will disable it, the X will delete an alarm, pressing on the alarm names would close the table.

To stop an alarm that is going, send /stop to the bot.

You can test the alarm using the /test command.

There is no reason why any Pi on earth should not be doing something

So this AlarmPi distro is usable, it lets you burn and flash a device within minutes and make it useful instead of lying and collecting dust in your house. The reason people are not using Pis is because making them do something requires “a guide”, aka list of instructions you are probably going to get wrong to do something simple. Building something as robust as this would take hours, and would be hell to maintain and receive code contributions. But AlarmPi is easy to read and modify. There is a repo for the bot, and a repo for the distro. If a new rapsberrypi comes out and there is a new Raspbian, all you got to do is rebuild and release. No manual editing. And takes less time to build and supports over 40 devices already which run Armbian.

The code base of AlarmBot lets you control crontabs, it could be used for controlling

• AlarmBot on github
• AlarmPi on github

As always, code contribute are appreciated!

Full text

14 August, 2017 11:01 AM

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

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

דיברתי עם Karen Sandler לגבי הבאה של outreachy לישראל ואיך אפשר לגייס אנשים לפרוייקט בארץ.

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

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

בלילה ניסיתי להתמודד עם העלאה של php-ssh2, בעיה שהצלחתי לפתור רק למחרת.

12 August, 2017 06:47 PM

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

מעבדים מרובי ליבות זה לא דבר חדש. יש 4 ליבות במעבד, 6,8,10, ועכשיו 12, 14,16 ואפילו 18 ליבות במעבד אחד. אינטל במשפחת המעבדים לדסקטופ (Skylake) מכרה מעבד עם 10 ליבות ו-20 נימים ב-1700$ ובמשפחה החדשה (Skylake-X) היא מוציאה ותוציא מעבדים עד 18 ליבות (אותו מעבד יעלה לך $2000). AMD מהצד השני הוציאה את משפחת Ryzen עם 4,6,8 ליבות (עם 8,12,16 נימים בהתאמה) ועתה עם משפחת ה-Threadripper היא מוציאה מעבדים עם 8,12,16 ליבות (ו-16,24,32 נימים בהתאמה). מהצד מי שמסתכל רק על ליבות, לא נראה שיש כזה הבדל גדול. נכון, AMD כרגע מובילה עם מעבד 16 ליבות אבל בחודש הבא אינטל תעקוף זאת עם 18 ליבות. מה הביג דיל?

ההבדל הענק הוא מתחת לכיסוי המעבד, וכאן 2 החברות נוקטות גישות שונות לחלוטין. אם נסתכל עם מיקרוסקופ אלקטרוני לתוך אחד ממעבדי ה-Skylake-X, נראה שהמעבד מורכב מחתיכת סיליקון אחד שעליה תוכננו כל הליבות, מה שנקרא "מעבד מונוליטי" – הכל תחת אותו סיליקון, לכל ליבה יש כמות די גדולה של זכרון מטמון L2 וישנו זכרון מטמון מסוג L3 (שהוא יותר קטן בהשוואה למעבדים הקודמים) שמשותף לכל הליבות והתקשורת בין הליבות עובדת בשיטה שנקראת MESH. לשיטה הזו יש יתרון גדול בכך שאם מריצים אפליקציות שרצות כתהליך יחיד – המעבדים של אינטל יותר מהירים מ-AMD אולם כשאפליקציות מתפרסות על כמה שיותר נימים וליבות – יש יתרון למעבדים של AMD (תלוי כמובן איזה מעבד משווים מול איזה מעבד).

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

מדוע בעצם AMD לא בנו את המעבדים כמו שאינטל בונה? מכיוון שמעבדים אלו מהווים פלטפורמה שהיא שונה ממה שאינטל מציעה ב-Skylake-X והיא יותר מזכירה מה שיש בתחנות עבודה מבוססות Xeon עם 2 מעבדים, כלומר ה-Threadripper זו מערכת שבנויה מ-2 מעבדים ובהתאם העבודה מבוצעת כך. חלק מכם שעובדים על שרתים מכירים זאת כ-SMP וליתר דיוק: NUMA ככל שזה מגיע לפריסת אפליקציות וניהול זכרון. בשיטה הזו ניצול מהירות הגישה של אותם פיסות זכרון מוצמדות גם ל"מעבד" שקרוב לזכרון על מנת לקבל ביצועים מיטביים. אם נחזור לרגע למעבדי Skylake-X של אינטל, המעבדים הללו עובדים בשיטה של UMA בכך שכל הזכרון מדבר עם פיסת סיליקון אחת, יהיה מה שיהיה.

אם ננסה לבדוק מה השיטה היותר טובה להריץ אפליקציות מאוד כבדות (רינדור וידאו, תלת מימד, וירטואליזציה וכו') – גם אינטל וגם AMD יאמרו בפה אחד: NUMA, כך כל מעבדי Xeon של אינטל ומעבדי EPYC (ועכשיו Threadripper) עובדים. כך גם הפצות לינוקס וגם Windows Server 2012/2016 עובדים כבר שנים רבות.

מעבדי Threadripper בעצם באים להתחרות יותר בזוג מעבדי ה-Xeon שיש בתחנת עבודה, אבל במקביל AMD מודעת בהחלט לכך שרוב משתמשי Threadripper יעבדו תחת Windows 10. ימי ה-Windows NT Workstation עברו מזמן מהעולם וזה מה שיש, ולכן AMD הוסיפה מצבים שונים למעבד כשבראשם 2 מצבים (מתחתם יש כל מיני אפשרויות שלא ניכנס אליהם כרגע): מצב היצירה (Creator mode) ומצב משחק (Game mode): בברירת המחדל המעבד עובד במצב Creator שבהם 2 פיסות הסיליקון עובדות, ובמצב Game Mode רק פיסת סיליקון אחת עובדת והמשתמש "מאבד" 8 ליבות ו-16 נימים (בהתאם לסוג המעבד) על מנת להריץ תוכנות ומשחקים ש"מתחרפנים" ברגע שהם רואים שיש יותר מ-20 נימים למכונה ובמצב Game mode אותם תוכנות ומשחקים רצים יותר מהר. הפתרון הזה הוא מעין "מעקף" עד שיצרני תוכנות ומשחקים (ליתר דיוק משחקים) יוסיפו תמיכה ל-Threadripper באופן טבעי.

מבחינת זכרון, ה-Threadripper הוא המעבד הראשון בעולם שנותן תמיכה בזכרון לא רק שקיים בשוק, אלא זכרון שגם עדיין לא מיוצר באותו גודל. כיום מקלות הזכרון DDR-4 מיוצרים בגדלים עד 16 ג'יגהבייט ו-Threadripper תומך בכך בלי שום בעיה אך בעתיד לכשייצרו מקלות של 32 ג'יגהבייט הוא יתמוך בכך ללא שום בעיה. בנוסף, מעבד Threadripper גם תומך בזכרון ECC (מקלות UDIMM בלבד) עד 1 טרהבייט זכרון אך שוב, כרגע מקלות UDIMM מיוצרים בגודל עד 16 ג'יגהבייט, כלומר מבחינת זכרון, המגבלה כרגע היא של גודל המקלות שמיוצרים בשוק, והמעבד אינו מגביל אותך בכמות הזכרון שתכניס.

אחת השאלות הכי חשובות שכל צרכן צריך לשאול את עצמו אם הוא רוצה לשדרג מעבד, היא השאלה: מה אני מריץ ומה אני צריך? אפשר להשוות את זה לעולם הרכב: האם לקנות לדוגמא יונדאי או שצריך Pick Up Track כמו בתמונה? וכאן הכל תלוי בצרכים.

אם לדוגמא הצרכן מריץ משחקים, פה ושם עורך וידאו Full HD, אפליקציות אופיס ואולי אפילו 2-4 מכונות וירטואליות, אז במקרה כזה מעבד Threadripper אינו מתאים. למי הוא כן מתאים? לכל מי שצריך הרבה יותר: וידאו 4K/6K/8K (גם RAW) עם המון זכרון ורינדור וידאו כמה שיותר מהיר, מספר כונני SSD בחיבור NVME, כ-64 ג'יגהבייט זכרון ומעלה, מעל 2 כרטיסי GPU (בתצורה טבעית של X16), ו/או הרצה של vSphere עם הרבה מכונות וירטואליות. מדובר בסופו של דבר במפלצת שנותנת ביצועים ובמקביל לא בדיוק חסה על חשבון החשמל שלך (תצטרך ספק כח של 750 וואט ומעלה, ואם אתה חושב על Overclocking – תתכונן לרכוש ספק של עד 1.5 קילוואט!). תחום נוסף ש-Threadripper יכול "לקרוץ" אליו הוא תחום הקונסולידציה: אם יש לך 3-4 מכונות PC שמריצות דברים שונים, אפשר לאחד אותם למכונה אחת. יש לך מספיק מקום לזכרון, מספיק מקום להכניס מקלות NVME SSD, יש 6 כניסות SATA, ויש במערכת 64 נתיבי PCIe (כאשר 4 מתוכם תפוסים ל-X399 Chipset) כך שאפשר להכניס הכל. מעבד לכך, רוב היצרנים שמוכרים לוחות אם מבוססי X399 ל-Threadripper נותנים לך גם כרטיס 10 ג'יגה (לא SFP אלא חיבור RJ45 רגיל).

המחיר? זול בהשוואה למעבדי ה-12/14/16/18 ליבות של אינטל אך עדיין – זה לא מחשב שרוכשים ברגע. רק המעבד עולה $1000 (בגירסת 16 ליבות, $800 בגירסת 12 ליבות), ומחיר לוח האם נע בין 350-550$. תוסיף ספק כח מינימום 750 וואט, כמות זכרון (הזכרון הוא QDR כך שלביצועים מיטביים יש לקנות קיטים של 4 מקלות, כלומר אם אתה רוצה 32 ג'יגהבייט, יש צורך לרכוש קיט של 4 מקלות עם 8 ג'יגהבייט זכרון פר מקל), SSD מהיר, כרטיס GPU טוב – ואנחנו מגיעים בקלות כמעט ל-10,000 שקל (כולל מע"מ). אם תרצה להזמין חלקים ולהרכיב פה בארץ, הם יהיו זמינים לקראת סוף אוגוסט.

לסיכום: AMD לראשונה נכנסה לתחום שאינטל היתה בו אקסלוסיבית והוא תחום תחנות עבודה רציניות עם תג מחיר זול בהשוואה למה שאינטל מציעה ויחד עם זאת עם ביצועים טובים מאוד כשמשווים PPD (כלומר Performance Per Dollar), ואינטל נאלצה לראשונה בחייה כתוצאה מהתחרות להמציא מעבדים חדשים עם יותר ליבות והצרכנים בהתאם מרוויחים. למי שצריך תחנת עבודה חזקה, ה-Threadripper נותן תשובה מעולה. אם אתם קונים תחנות עבודה ממותגות (HP, לנובו, DELL) – תוכלו לרכוש מחברת Alienware (חברה בת של DELL) ושאר היצרנים יציעו תחנות ממותגות החל מינואר 2018. אם לעומת זאת אינך מפחד מהרכבה עצמית, אני מאמין שבשבוע הקרוב או אחריו תוכל להזמין לוח,ספק,מעבד וכו'.

הטקסט המלא

12 August, 2017 04:29 PM

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

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

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

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

11 August, 2017 05:04 AM

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

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

אז מה לא אינטואיטיבי עבורי?  הכל
סתם, הנה הדגמה קטנה לרובי:

[1, 2, 3, 4].each_with_index do |elem, idx|
puts "arr[#{idx}]=#{elem}"
end

המקביל (למעט שימוש ב format string) של זה בפיתון:

for idx, elem in enumerate([1, 2, 3, 4]):
print('arr[{}]={}'.format(idx, elem))

לפני שאסביר מה מפריע לי, בואו נראה איך זה יתבצע ב ES6 למשל:

[1, 2, 3, 4].forEach( (elem, idx) => console.log('arr[%d]=%d', idx, elem) )

בגו (go/golang) זה יראה ככה:

slice := []int{1, 2, 3, 4}
for idx, elem := range slice {
 fmt.Printf("arr[%d]=%d\n", idx, elem)
}

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

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

בגו, יש לולאה מסוג אחד – for.
הלולאה הזו מסוגלת לבצע איטרציה באמצעות range, או להיות לולאת for כפי שהיא מוכרת בתחביר C.
אין עוד סוגים של לולאות.

אז מה מפריע לי בפיתון?
אני יכול לבצע איטרציה פשוטה של

for elem in [1, 2, 3, 4]:
...

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

אבל בפיתון האיטרציה מסוגלת להתבצע באמצעות הגדרה של שני מתודות: __iter__ ו __next__ (או next בגרסה 2), אז למה אין איטרציה לאינדקס? למה צריך משהו חיצוני בשביל זה?

סבבה, אפשר "לבלוע" את זה, אם זה היה הדבר היחיד.

הנה בעיה נוספת:

ברובי, יש לי פעולה כזו:

[1, 2, 3, 4].join(',')

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

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

','.join(str(n) for n in [1, 2, 3, 4])

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

','.join([1, 2, 3, 4])

הוא יצעק עלי:

TypeError: sequence item 0: expected str instance, int found

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

אפילו ES עושה את זה בגישה שאני מצפה לה:

[1, 2, 3, 4, 5].join(',')

כלומר זה לא ייחודי לרובי.

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

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

רובי:

[1, 2, 3, 4].length
[1, 2, 3, 4].count

ES:

[1, 2, 3, 4].length

פיתון:

[1, 2, 3, 4].count() # TypeError: count() takes exactly one argument (0 given)
# oh, it looks up if an element exists... and how many times, okay then ...

len([1, 2, 3, 4])

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

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

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

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

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

אה, ועוד דבר, ברובי, count לא קיים למחרוזת אמנם, אבל בכל מה שיורש מ enumerable (כדוגמת מערך ו hash) ב3 צורות:

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

עבור Hash שימוש מספר 2, תמיד יחזיר 0, כי הבדיקה מורכבת מעט יותר, הרי על מה אנחנו רוצים לבצע את הספירה? על מפתחות? סבבה, יש מתודה בשם keys. על ערכים? סבבה, יש מתודה בשם values. שתיהן מחזירות מערכים. לבדוק אם מפתח וערך מתקיימים ביחד, זה לא הגיוני עבור count להחזיר, כי לא יכולים להיות 2 מפתחות באותו השם. לבדוק האם מפתח קיים, משתמשים ב include?‎ (סימן השאלה בסוף). אותו הדבר לגבי מערך, אותה מתודה תחזיר האם איבר קיים, שוב פעם ירושה, הפעם מ BasicObject.

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

09 August, 2017 07:49 AM

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

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

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

אני מחלק אותם למספר סוגים (אין חשיבות לסדר):

פודקאסטים טכניים:

• AWS – פודקאסט המלמד על המוצרים של אמזון ל"ענן".
• BSD Now – פודקאסט על קוד פתוח בדגש על עולם ה BSD.
• Go Time – פודקאסט על שפת גו, פרוייקטים מעניינים, ראיונות עם מפתחים וכיוב'.
• The Changelog – פודקאסט על תוכנה חופשית, קוד פתוח וראיונות עם אנשים מעניינים.
  הפודקאסט הוא בחסות Changelog.
• The Linux Action Show!‎ – פודקאסט על טכנולוגיה, תוכנה חופשית וקוד פתוח, בעיקר על לינוקס.
• מפתחים חסרי תרבות – פודקאסט חדש וצעיר על עולם התוכנה, בעברית.
• רברס עם פלטפורמה – פודקאסט על עולם התוכנה והטכנולוגיה, בעברית, עם רן תבורי, אורי להב, ואחרים. יש גם ראיונות עם אנשים. אני גם הופעתי באחד הפרקים שלהם בעבר.
•  Malicious Life – פודקאסט חדש בנושאי אבטחת מידע.
  פודקאסט באנגלית, אבל מבית הפודקאסטים של רן לוי.

פודקאסטים בהיסטוריה:

• Revisionist History – פודקאסט המדבר על נושאים שונים בהיסטוריה, פוליטיקה כללית וכיוב'.
• The Ancient World – היסטוריה עתיקה, כדוגמת מה קרה במצריים, כאן, בדרום אמריקה וכיוב', באותם הזמנים. הרבה לפני היוונים והרומאים.
• The China History – ההידטוריה של סין, כולל הגישה הפוליטית ואפילו קצת מיתולוגיה בנושא.
• The History of Rome – ההיסטוריה של רומא, כניסה לאירועים שונים, לוחות זמנים, סקירות כלליות וגם יסודיות על רומא, מכיצד היא נוסדה והסיפור על האחים, דרך כל המלחמות, ההבדלים בין התקופות ולימוד על כל קיסר שהיה ואירועים שונים.
• המשחק הגדול – פודקאסט ובלוג מדהים, הוא למען האמת יותר בנושא של גיאו פוליטיקה, אבל זה חופף עם לימוד היסטוריה.
• קטעים בהיסטוריה – פודקאסט מדהים של יובל מלחי.

פודקאסטים בכלכלה ועסקים:

• Founders Talk – פודקאסט בנושא עסקים ובעיקר סטארטאפים, כיצד הסטארטאפ קם, אילו בעיות מתמודדים וכיוב'.
  פודקאסט זה הוא מבית Changelog.
• Masters of Scale with Reid Hoffman – פודקאסט על עסקים, סטארטאפים ומה נדרש בשביל להקים עסקים טובים. סיפורים הצלחה וכישלון.
• Spartan Up! – A Spartan Race for the Mind!‎ – פודקאסט שמעודד לחשוב חיובי ולהתמיד עם דברים. המקימים שלו הם אנשים אשר הקימו מירוץ שנקרא Spartan Race, הוא מירוץ שדורש מזוגות ויחידים להתמודד בתנאים מאוד קשים בשביל להגיע לפסגה. הפודקאסט עצמו, אבל לוקח כל פעם מישהו אחר שהשיג מטרה כלשהי בחיים שלו, בלי קשר למירוץ.
• 30 דקות או פחות – פודקאסט של האקסלרטור במיקרוסופט, הלוקח כל פעם יזם ישראלי אחר ומדבר עליו, על המסלול שהוא הגיע וכיוב', בנוסף גם מנהלי קרנות הון סיכון נמצאים בראיון שם.
  הפודקאסט לוקח כל פרק עד 30 דקות, במטרה שיהיה ניתן לשמוע אותו בפעם אחת, ולא בהמשכים.
• השבוע: פודקאסט על סטארטאפים – פודקאסט המדבר על סטארטאפים שונים, על הצלחות, וכישלונות וכיוב'.
• חיות כיס – פודקאסט המדבר על עולם הכלכלה בצורה די קלה ופשוטה להבנה.
  הפודקאסט מבית "כאן", תאגיד השידור.
• עושים עסקים -ראיונות מעוד מעניינים עם מנהלים של עסקים, אקסלרטורים ועוד.
  הפודקאסט מבית "עושים היסטוריה" של רן לוי.
• עושים שיווק באינטרנט – פודקאסט בנושא העולם העסקי באינטרנט, וכיצד מבצעים דברים ורעיונות לסוגי הכנסה שונים.
  הפודקאסט מבית "עושים היסטוריה" של רן לוי.

פודקאסטים בתזונה:

• Keto Talk With Jimmy Moore & The Doc – פודקאסט בנושאי תזונה קיטוגנית, מציג נושאים שונים וטיפים ואזהרות שונות.
• Robb Wolf – The Paleo Solution – פודקאסט בנושאי תזונה פליאוליטית, של רוב וולף – ביו כימאי, המדבר על עולם הפליאו, ומסייע לאנשים להתמודד עם דברים שונים בנושא התזונה, והגוף שלהם בכלל, ביחד עם עוד אנשי מקצוע שונים.
• The Livin' La Vida Low-Carb Show With Jimmy Moore – פודקאסט על תזונה קיטוגנית או דלת פחממות בכלל, עם ג'ימו מור.

פודקאסטים בידע כללי:

• Curiosity Podcast – פודקאסט חדש על ידע כללי כמעט בכל נושא בעולם, כולל מחקרים אחרונים או פחות מוכרים.
• Geekonomy – פודקאסט על כל דבר שזז בערך, וגם כאלו שכבר לא.
• Invisibilia – פודקאסט על המוח האנושי מבחינה פסיכולוגית.
• S-Town – פודקאסט החוקר פרשת רצח אחת! שהייתה בבית המשפט .
• Serial – פודקאסט בנושא חקירת רצח אחת! שהיתה בבית המשפט.
• Stuff You Should Know – פודקאסט בנושא של ידע כללי.
  מהבית של How Stuff Works
• Sworn – פודקאסט בנושאי בתי משפט בארה"ב וחקירות רצח.
• לא סופי – פודקאסט בנושאים פילוסופיים עם פרופסור אושי שוהם קראוס ויובל מלחי. פודקאסט המשך ל"קטע פילוסופי".
  מבית היוצר של "קטעים בהיסטוריה", ומתארח ב"כאן", תאגיד השידור.
• עושים היסטוריה – פודקאסט מדהים בידע כללי של רן לוי.
• פה ושם בארץ ישראל – פודקאסט מעניין של יפתח מזור.

09 August, 2017 07:48 AM

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

1. רברסים פלטפורמה – קבוצה של ישראלים  מדברים על טכנולוגיה. יותר מדי טכנולוגיות ווב, אבל התוכן די סביר. RSS
2. הפילוסופיה של הקוד – פודקאסט ישראלי מאוד טכני, חבל שלא ממשים אותו. מעט פרקים ולא מתוחזק מאז 2014… אבל שווה. RSS.
3. עושים היסטוריה עם רן לוי – האיש גיק והוא מספר סיפורים … על איך המציאו אבקת שירפה, ההיסטוריה האמיתית מאחורי "משחקי הכס",  מגיפות של גפנים (יין), "להתיש את הקודו", ועוד. מאוד מגון, ולא תמיד קשור ישירות בתוכנה. אני מאוד ממליץ על הפוקטאסט הזה. RSS
4. שעה היסטורית – שידור חוזר של תוכנית רדיו ששודרה בשנות ה־80 (!) ברשת ב', ברדיו. אולי שווה לקרא לזה ריבוט… עוד אחד שאני ממליץ עליו בחום. אין קשר בין זה וטכנולוגיה – היסטוריה נטו. RSS
5. Dot.Net Rocks – התחילה לפני כמה שנים (10 שנים ב"אוויר") בתור פודקאסט על טכונולוגיות מיקרוסופט בלבד, אבל בשנים אחרונות העולם השתנה והם מדברים על… כל טכנולוגיה כמעט. פעם בחודש יש להם GeekOuts [RSS] שבהם מדברים על … צליית בקר, אנרגיה אטומית, מסעות אל מאדים… ה-Geekouts מאוד מומלצים. מאוד. איכות השמע כאן ממש טובה, אולי כי אחד מהמגישים הוא מוסיקאי. RSS
6. Bad Voltage – חבורת סתומים שעוסקים בתוכנה חופשית מדברים שטויות על … אין לי מושג. חצי מהזמן הם יורדים אחד על השני… צחוקים מטורפים וזה פודקאסט שהתוכן המרכזי הוא תוכנה חופשית. RSS
7. Coverville – כאן תשמעו שעה וחצי של חידושים. מוסיקה מצויינת. RSS
8. Floss Weekly – פעם בשבוע מראיינים מישהו ("מנהיג") של פרוייקט קוד פתוח/תוכנה חופשית. המנחה הוא רנדל שווארץ, איש מוכר מאוד בתחום של פרל, הוא כתב את הספרים של אוריילי. RSS
9. Software engineering Radio – קבוצה של אנשי תוכנה מדברים על תוכנה מכיוון יותר אקדמאי. ממוקד מאוד בג'אווה. אני לא יכול להגיד שהוא מומלץ. הוא די משעמם לפעמים. הקריינים יבשים. RSS
10. The Linux Link Tech Show – הסבתא של כל התוכניות. ראיינו את סטאולמן פעמיים, וכבר מעל 500 פרקים. איכות השמע השתפרה מאז שנטשו את אסטריסק ועברו אל מאמבל. התכונית כולה מופקת בעזרת תוכנה חופשית מהיום הראשון. RSS
11. This week in science –  התוכנית הזאת עוקבת אחרי מה שקורא במדע מדי שבוע. ביולוגיה, פיסיקה כימיה. בשנים האחרונות היא קצת מעייפת אותי. אני מניח שזה רק אני. RSS
12. CPP Cast – פודקאסט שמדבר על ההתפתחויות בשפת C++. הוא מאוד טכני, ולא ממש טוב בתור האזנה… אלא כדי להבין "אוקי, זאת ספרייה שאני צריך ללמוד עליה". מאוד מומלץ לחובבי C++ בלבד. RSS
13. גיקונומי – פודקאסט ישראלי במלא מובן המילה שמארח את האנשים הכי מעננים. שעתיים וחצי ללא עריכה. מרתק. RSS
14. Adam Savage – Still untitled – אדם סאבג' ממכסחי המיתוסים יש לו פודקאסט משלו (ויש ערוץ יוטיוב שבוא בונים דברים מגניבים). RSS
15. Dan Carlin – Hardcore history. זהו אחד הפודקסטים הכי טובים בעולם. האיש משווק את עצמו בתור "לא היסטוריון" אבל הוא מסביר היסטוריה בצורה מדהימה. פרק אחד יכול להיות שעתיים רצוף שהוא מדבר אל מיקרופון… והפרק האחרון היה …  4:30 שעות.  האיש עושה סדרה של 4 פרקים אודות מלחמת העולם הראשונה והיה לי קשה להקשיב לזה, כי היה גרפי מדי. חזרתי אחרי חודש ולמדתי. ממליץ בחום (גם הפרקים הג'ינגס חאן היו ממש טובים). RSS

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

הטקסט המלא

06 August, 2017 07:51 PM

Background: what is NGS?

NGS, the Next Generation Shell is a (work in progress) shell and a programming language built ground up for systems engineering tasks. You can think of it as bash that’s designed today: sane syntax, data structures, functional programming, extensibility, cloud in mind, declarative primitives.

What’s the problem with constructing command line arguments?

The problem affects only more “advanced” cases of constructing command line arguments when some arguments might or might not be present. Let’s consider this example:

# Made-up syntax, resembling NGS
args = []
if 'Subnets' in props {
  args += '--subnets'
  args += props['Subnets']
}
if ... {
  args += ...
}
if ... {
  args += ...
}
...
aws elb create-load-balancer ... $args

Wouldn’t it be cleaner to get rid of all the ifs? … and what happens if props['Subnets'] is an empty array?

How Argv facility in NGS solves the problem?

Argv is a result of factoring out the common code bits involved in constructing command line arguments. The ifs above were also factored out. They are now in Argv.

Let’s look at usage example (real NGS code, from AWS library)

argv = Argv({
  '--load-balancer-name': rd.anchor.name
  '--listeners': props.ListenerDescriptions.encode_json()
  '--subnets': rd.opt_prop('Subnets', props).map(only(ResDef, ids))
})
rd.run('create ELB', %(aws elb create-load-balancer $*argv))

The important points here are:

1. Argv is a function with a single parameter which must be of type Hash (also called “dictionary” in some languages)
2. The keys of the Hash are switches’ names (--load-balancer-name, --listeners, --subnets)
3. The values of the Hash are values for the switches

The “if” that decides whether a switch is present in the resulting argv is inside Argv implementation and your code is clean of it. The values of the Hash are considered when Argv decides whether a switch should be present. null, empty array and instances of type EmptyBox are considered by Argv as missing values and it discards the switch. For convenience, instances of type FullBox are unboxed when constructing the result of Argv.

The Argv facility is yet another point among others that shows why NGS and systems engineering tasks are best fit.

Have a nice weekend!

04 August, 2017 05:26 PM

orchestrator 3.0 Pre-Release is now available. Most notable are Raft consensus, SQLite backend support, orchestrator-client no-binary-required client script.

TL;DR

You may now set up high availability for orchestrator via raft consensus, without need to set up high availability for orchestrator's backend MySQL servers (such as Galera/InnoDB Cluster). In fact, you can run a orchestrator/raft setup using embedded SQLite backend DB. Read on.

orchestrator still supports the existing shared backend DB paradigm; nothing dramatic changes if you upgrade to 3.0 and do not configure raft.

orchestrator/raft

Raft is a consensus protocol, supporting leader election and consensus across a distributed system.  In an orchestrator/raft setup orchestrator nodes talk to each other via raft protocol, form consensus and elect a leader. Each orchestrator node has its own dedicated backend database. The backend databases do not speak to each other; only the orchestrator nodes speak to each other.

No MySQL replication setup needed; the backend DBs act as standalone servers. In fact, the backend server doesn't have to be MySQL, and SQLite is supported. orchestrator now ships with SQLite embedded, no external dependency needed.

In a orchestrator/raft setup, all orchestrator nodes talk to each other. One and only one is elected as leader. To become a leader a node must be part of a quorum. On a 3 node setup, it takes 2 nodes to form a quorum. On a 5 node setup, it takes 3 nodes to form a quorum.

Only the leader will run failovers. This much is similar to the existing shared-backend DB setup. However in a orchestrator/raft setup each node is independent, and each orchestrator node runs discoveries. This means a MySQL server in your topology will be routinely visited and probed by not one orchestrator node, but by all 3 (or 5, or what have you) nodes in your raft cluster.

Any communication to orchestrator must take place through the leader. One may not tamper directly with the backend DBs anymore, since the leader is the one authoritative entity to replicate and announce changes to its peer nodes. See orchestrator-client section following.

For details, please refer to the documentation:

• orchestrator/raft: overview
• orchestrator/raft vs. shared backend DB setup, comparison

The orchetrator/raft setup comes to solve several issues, the most obvious is high availability for the orchestrator service: in a 3 node setup any single orchestrator node can go down and orchestrator will reliably continue probing, detecting failures and recovering from failures.

• See all orchestrator high availability solutions

Another issue solve by orchestrator/raft is network isolation, in particularly cross-DC, also refered to as fencing. Some visualization will help describe the issue.

Consider this 3 data-center replication setup. The master, along with a few replicas, resides on DC1. Two additional DCs have intermediate masters, aka local-masters, that relay replication to local replicas.

We place 3 orchestrator nodes in a raft setup, each in a different DC. Note that traffic between orchestrator nodes is very low, and cross DC latencies still conveniently support the raft communication. Also note that backend DB writes have nothing to do with cross-DC traffic and are unaffected by latencies.

Consider what happens if DC1 gets network isolated: no traffic in or out DC1

Each orchestrator nodes operates independently, and each will see a different state. DC1's orchestrator will see all servers in DC2, DC3 as dead, but figure the master itself is fine, along with its local DC1 replicas:

However both orchestrator nodes in DC2 and DC3 will see a different picture: they will see all DC1's servers as dead, with local masters in DC2 and DC3 having broken replication:

Who gets to choose?

In the orchestrator/raft setup, only the leader runs failovers. The leader must be part of a quorum. Hence the leader will be an orchestrator node in either DC2 or DC3. DC1's orchestrator will know it is isolated, that it isn't part of the quorum, hence will step down from leadership (that's the premise of the raft consensus protocol), hence will not run recoveries.

There will be no split brain in this scenario. The orchestrator leader, be it in DC2 or DC3, will act to recover and promote a master from within DC2 or DC3. A possible outcome would be:

What if you only have 2 data centers?

In such case it is advisable to put two orchestrator nodes, one in each of your DCs, and a third orchestrator node as a mediator, in a 3rd DC, or in a different availability zone. A cloud offering should do well:

The orchestrator/raft setup plays nice and allows one to nominate a preferred leader.

SQLite

Suggested and requested by many, is to remove orchestrator's own dependency on a MySQL backend. orchestrator now supports a SQLite backend.

SQLite is a transactional, relational, embedded database, and as of 3.0 it is embedded within orchestrator, no external dependency required.

SQLite doesn't replicate, doesn't support client/server protocol. As such, it cannot work as a shared database backend. SQLite is only available on:

• A single node setup: good for local dev installations, testing server, CI servers (indeed, SQLite now runs in orchestrator's CI)
• orchestrator/raft setup, where, as noted above, backend DBs do not communicate with each other in the first place and are each dedicated to their own orchestrator node.

It should be pointed out that SQLite is a great transactional database, however MySQL is more performant. Load on backend DB is directly (and mostly linearly) affected by the number of probed servers. If you have 50 servers in your topologies or 500 servers, that matters. The probing frequency of course also matters for the write frequency on your backend DB. I would suggest if you have thousands of backend servers, to stick with MySQL. If dozens, SQLite should be good to go. In between is a gray zone, and at any case run your own experiments.

At this time SQLite is configured to commit to file; there is a different setup where SQLite places data in-memory, which makes it faster to execute. Occasional dumps required for durability. orchestrator may support this mode in the future.

orchestrator-client

You install orchestrator as a service on a few boxes; but then how do you access it from other hosts?

• Either curl the orchestrator API
• Or, as most do, install orchestrator-cli package, which includes the orchestrator binary, everywhere.

The latter implies:

• Having the orchestrator binary installed everywhere, hence updated everywhere.
• Having the /etc/orchestrator.conf.jsondeployed everywhere, along with credentials.

The orchestrator/raft setup does not support running orchestrator in command-line mode. Reason: in this mode orchestrator talks directly to the shared backend DB. There is no shared backend DB in the orchestrator/raft setup, and all communication must go through the leader service. This is a change of paradigm.

So, back to curling the HTTP API. Enter orchestrator-client which mimics the command line interface, while running curl | jq requests against the HTTP API. orchestrator-client, however, is just a shell script.

orchestrator-client will work well on either orchestrator/raft or on your existing non-raft setups. If you like, you may replace your remote orchestrator installations and your /etc/orchestrator.conf.json deployments with this script. You will need to provide the script with a hint: the $ORCHESTRATOR_API environment variable should be set to point to the orchestrator HTTP API.

Here's the fun part:

• You will either have a proxy on top of your orchestrator service cluster, and you would export ORCHESTRATOR_API=http://my.orchestrator.service/api
• Or you will provide orchestrator-client with all orchestrator node identities, as in export ORCHESTRATOR_API="https://orchestrator.host1:3000/api https://orchestrator.host2:3000/api https://orchestrator.host3:3000/api" .
  orchestrator-client will figure the identity of the leader and will forward requests to the leader. At least scripting-wise, you will not require a proxy.

Status

orchestrator 3.0 is a Pre-Release. We are running a mostly-passive orchestrator/raft setup in production. It is mostly-passive in that it is not in charge of failovers yet. Otherwise it probes and analyzes our topologies, as well as runs failure detection. We will continue to improve operational aspects of the orchestrator/raft setup (see this issue).

03 August, 2017 01:32 PM

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

יותר מחצי שנה לא כתבתי פוסט, למעשה כמעט 8 חודשים אני חושב. המון חדשות חולפות בקצב מסחרר ואי אפשר להתעמק בכלום, וגם החלפת מקום עבודה מוריד מהזמן הפנוי לכתיבה של יותר מציוצים בטוויטר. אם אתם לא עוקבים, חוק הזיהוי הביומטרי עבר והחל מיוני כולם חייבים לתת טביעות אצבע ופנים. מי שישלם כופר מיוחד יוכל להשאר מחוץ למאגר (אם אתם באמת מאמינים שלא ישמרו לכם את תביעת האצבע אחרי שיכתבו אותה לשבב בתעודה), אבל יצטרך לעשות את זה פעמיים בעשור במקום פעם אחת. ההמשך עכשיו יכול להיות אחד משלושה עיקריים: או שהפניה שלנו לבג"צ תצליח והמאגר יבוטל מתישהו ב-2018, או שיהיה מהפך בחירות וקואליציה חדשה תחליט למחוק את השרץ, או שהגזרה תשאר, ועד 2022 (2027 למי שרץ להחליף תיעוד במאי) כל הישראלים שישארו פה יאלצו להשתדרק למאגר. בינתיים כבר היו דליפות בהודו וסיפורים מסוכנים אחרים, אז נחיה ונראה. על עדכונים של פאדיחות הבית הלבן אני גם לא ארחיב, אתם בטח צופים כמוני בסטיבן קולבר ביוטיוב.

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

• סיסמאות ארוכות וקשות, ושונות לכל אתר.
• כמה ארוכות וקשות? כאלו שבחיים לא תזכרו, בשביל זה יש מנהלי סיסמאות. על זה כנראה פוסט נפרד בעתיד.
• אם השירות מציע אימות כפול, הפעילו אותו תמיד! יוצא דופן – אימות באמצעות סמס, זה כנראה חלש ובעייתי מדי, ומאלץ אתכם לתת לשירות את מספר הטלפון שלכם, אז לשיקולכם. חפשו בהגדרות המשתמש שלכם, יש אלפי אתרים שתומכים.
• כדאי להחליף סיסמאות פעם בשנה, אבל אפילו אני לא עד כדי כך קדוש. החליפו כשיוצא לכם.
• אפשר לסנכרן סיסמאות ושאר מידע בין דפדפנים באמצעות Chrome Sync או Firefox Sync/Weave אבל לבחור במקרים כאלו סיסמת הצפנה ארוכה וקשה, אפילו 64 תווים, שתשמר כמובן מוצפנת במנהל הסיסמאות שלכם.

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

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

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

משהו שיש לך – תעודה בלתי ניתנת לזיוף, אם ע"י שימוש בשיטות ייצור סודיות וייחודיות ואם ע"י חתימה דיגיטלית, או אולי מפתח כלשהוא שלא ניתן לשכפל. כשאני אומר מפתח עולה לכם אולי בראש מפתח פלדלת או ייל, אבל את אלו כבר שכפלו כי הופיעו בטעות בתמונה. הסיפור הכי מצחיק היה כשסוכני TSA הצטלמו ברוב היבריס עם צרור המפתחות שלהם שפותח כל מנעול מזוודות בשוק, ואנשים מיהרו להעתיק את המבנה מהתמונות, וכמזה שנתיים אפשר להוריד את כל המפתחות מגיטהאב להדפסה בתלתפסת בייתית. לא, אני מתכוון למפתחות הצפנה פיזיים, כלומר מעין התקן USB עם מעבד קטן וזכרון שאי אפשר לקרוא, וניסיון למעקף פיזי של ההגנות אמור להרוס אותו ללא שוב. כאלו יש מספר מוצרים בשוק ואחד היצרנים הבולטים הוא Yubico. אני סוקר את המוצר שלהם כאן כי אחרי שלמדתי את הנושא ברשת הגעתי למסקנה שזה אחד משניים-שלושה הכי מעניינים, מגוונים ונגישים, ואין לי שום קשר איתם מעבר לזה (וכמובן לא קיבלתי מהם מוצר או טובות), ולכן קניתי אותו. יש להם אפילו יבואן רשמי בארץ אבל אחרי שקיבלתי מהם ספאם, העדפתי לשלם את המחיר המלא של הזמנה מחו"ל (אמזון או הריסלר הזה). שווה להציץ, לפעמים יש להם סייל 50% הנחה ליום-יומיים.

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

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

• מול אתרי ווב יש לי את שירות U2F שמזכיר את יישומון Google Authenticator רק שלא צריך להעתיק שישיות ספרות ולא ניתן להעתיק את הסודות ע"י יישומון זדוני (מצד שני, אי אפשר לגבות, לטוב ולרע…)
• משמש לפתיחת כספות סיסמאות כמו Keepass או LastPass.
• הוא יודע לעבוד במוד challenge-response מכמה סוגים, שמאפשרים לי למשל לאבטח את הלאפטופ שלי כך שלוגין פשוט (בקונסול, GDM או מנעילת מסך) ללא הכרטיס תיחסם (מודול PAM ששולח לו צ'אלנג' ורואה שהוא מחשב אותו נכון ואז מאשר גם לפי הסיסמא). לחלונות ומאק יש אפשרות דומה.
• בשיטה אחרת גם פתיחת ההצפנה של הדיסק (root on LUKS) לא תתאפשר בלי שהסיסמא תעבור פיענוח דרך הכרטיס.
• הוא יודע להצפין ולפתוח מסרים עם מפתח RSA של GPG עד 4069 ביט (2048 בלבד בגרסת Yubikey NEO של ההתקן, לצערי).
• משמש אמצעי אימות לחיבור SSH, אם ע"י שמירת המפתח הסודי או דרך אימות PGP שעד לאחרונה לא הכרתי אפילו שקיים.
• הוא יודע לחתום על Docker Images (לא בגרסת NEO) למי שזה מעניין אותו.
• הוא יודע לייצר קודים חד פעמיים מסוג HOTP (אין לו שעון פנימי, אז אין TOTP בלי תוכנה מסייעת).
• האתרים שכרגע אני עובד איתם בעזרתו: חשבונות גוגל השונים, גיטהאב, בלוגים מבוססים וורדפרס.
• אתרים בהם אני לא משתמש אבל תומכים: סיילזפורס, פיכסבוק ודרופבוקס.
• אתרים שהייתי רוצה לעבוד איתם אבל לא תומכים (בינתיים): פייפאל, בנקים ישראליים, חברות ביטוח ובריאות, אמאזון, טוויטר, ובעצם כל אתר אחר שאני נכנס אליו עם סיסמא.
• רוב התוכנות והדרייברים פתוחים וברשיון חופשי, אפשר גם לבנות שרת אותנטיקציה משלך לשרתים אחרים ועוד המון אפשרויות לאנשים פרטיים וללקוחות תאגידיים.

שו"ת

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

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

אני בונה היום אתר, להשקיע באימות כזה למשתמשים שלי?
גם TOTP-2FA וגם U2F – לדעתי כן, במיוחד אם האתר שומר פרטים אישיים של כרטיסי אשראי, בריאות מטופלים ועוד כיוצא באלו. יש ספריות חופשיות שקל לשלב, ולמערכות כמו וורדפרס, דג'נגו, ג'ומלה, רובי-או-ריילז ואחרות יש כבר מודולים מוכנים לקטיפה מהעץ, אז חבל להתעצל!

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

יש מתחרים ראויים?
יש כמה. חלקם יתנו U2F בלבד בפחות מ$10-$20, חלקם יקרים מאוד אבל עושים דברים נוספים כמו לשמש כארנק קריפטומטבעות (למשל Trezor ואחרים) ויש גם אופציות "האקריות" פתוחות כגון OnlyKey שמוסיף שכבות הגנה כמו סיסמא, פיצ'רים כמו השמדה עצמית וכדומה. יש מצב שאקנה כזה בעתיד, למרות שהוא נראה פחות עמיד מכנית לשבירה ושיפשופים.

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

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

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

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

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

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

31 July, 2017 04:51 PM

Electric Sheep running on a Raspberry Pi

Hey all,
So its been a while since I had time to release something fun. After developing CustomPiOS I thought I might write something to demonstrate how easy it is to make your own RaspberryPi distribution with it. So I made one that runs Electric Sheep on boot. Its called ElectricSheepPi.
Electric Sheep is a collaborative abstract artwork that keeps evolving as you vote for “sheep”. So it makes nice visuals and is great to play on a spare screen and Pi. Raspberrypi 2 works, Raspberrypi 3 is recommended for smooth visuals. You can see examples of the visuals on youtube.

To run it

1. Download the image
2. Flash it like any distro
3. set up wifi, set your wifi settings with the file electricsheep-network.txt or electricsheep-wpa-supplicant.txt.
4. Plug to HDMI display, internet and boot

Its easy to write a custom distro with CustomPiOS!

To write I had to write a module for CustomPiOS, it was just 32 lines mostly copied from the electric sheep install manual. To make stuff start on boot I used the gui module which lets you start any gui application full screen at boot, that’s 2 lines in the config file.

Thank you Doc’s Tech for hosting the image yet again!

Full text

18 July, 2017 02:11 PM

As part of my work at Zend (now a RogueWave company), I maintain the various patch sets. One of those is the changes for PDO_IBM extension for PHP.

After some patch exchange I decided it’s would be easier to manage the whole process over a public git repository, and maybe gain some more review / feedback along the way. Info at https://github.com/kaplanlior/pecl-database-pdo_ibm/commits/zend-patches

Another aspect of this, is having IBMi specific patches from YIPS (young i professionals) at http://www.youngiprofessionals.com/wiki/index.php/XMLService/PHP, which itself are patches on top of vanilla releases. Info at https://github.com/kaplanlior/pecl-database-pdo_ibm/commits/zend-patches-for-yips

So keeping track over these changes as well is easier while using git’s ability to rebase efficiently, so when a new release is done, I can adapt my patches quite easily. Make sure the changes can be back and forward ported between vanilla and IBMi versions of the extension.

Full text

16 July, 2017 01:13 PM

הגענו לזמנים טובים, בהם סוף סוף לאינטל יש תחרות הן במעבדים לדסקטופ, הן במעבדי קצה-גבוה-מאוד לדסקטופ (Super High End Desktop – או SHED בקיצור) והן במעבדים לשרתים, בין אם מדובר בשרת עם תושבת למעבד אחד או 2 (אינטל עדיין ממשיכה עם 4 ו-8 מעבדים על לוח אבל רוב החברות כלל לא רוכשות את זה. יותר זול לרכוש מספר שרתים עם 2 מעבדים מאשר אחד עם 4 או 8 מעבדים).

ועם התחרות, מגיעים נסיונות השכנוע לגרום לחברות לרכוש את המעבדים והשרתים. כל יצרני השרתים מייצרים שרתים הן עם מעבדי AMD Epyc והן עם מעבדי ה-Skylake-SP. יצרניות המעבדים מפרסמים השוואות מאוד סלקטיביות (Cherry Picking) בין המעבד שלהם לזה של המתחרה וזה לחלוטין לגטימי. ב-AMD החליטו לא להשוות למעבדי ה-Skylake-SP אלא למעבדי דור 4 של Xeon.

באינטל לעומת זאת, בחרו מוטו אחד שמסביב לו הם בנו את כל הקמפיין והם הוציאו מצגת שרצה סביב המוטו הזה. מהו המוטו? שמעבדי Epyc הם בעצם 4 מעבדי Ryzen 7 1800X של AMD "מודבקים ביחד", שזה בערך כמו לאמר שמעבדי Skylake-SP הם מספר מעבדי Skylake-X מודבקים ביחד.

האם לטיעון הזה יש רגליים? לא. למעבדי Epyc יש דברים שאין בשום מעבד Ryzen דסקטופ, דברים כמו:

• כמות זכרון מטמון L3 כפולה (64 מגהבייט)
• כמות מסלולי PCIe – ב-Epyc יש 128, ב-Ryzen 7 יש 24
• תמיכה בעד 4 טרהבייט זכרון (ב-Ryzen זה נגמר ב-64 ג'יגהבייט)
• ב-Epyc אין Chipset כלל וכלל בשעה ש-Ryzen חייב את ה-X399 Chipset.
• ה-TDP (מעטפת צריכת חשמל) שונה – ב-Epyc היא נעה סביב 170-180 וואט ואילו ב-Ryzen היא מקסימום 95W (ללא Overclocking). לפי ההגיון של אינטל זה היה אמור להיות 380W.
• אין את ה-Infinity Fabric שמאפשר לחבר 2 מעבדים יחד ותקשורת ביניהם (שמבוצעת על 64 כניסות PCIe – בכדי להוזיל את המחיר).

ויש עוד דברים שהם ממש שונים שוני של יום ולילה בין מעבדי הדסקטופ של AMD למעבדי השרתים.

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

המעבד של אינטל בהחלט מנצח, נכון? נחמד, רק שהמעבד שאינטל הביאה להשוואה עולה 2200$ והוא לשרת והמעבד שהיא בחרה משורת המעבדים של AMD הוא את ה-Ryzen שרץ רק על דסקטופ ועולה $420. אני קורא לזה: השוואה בין תפוחים למטאטאים.

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

שוב אינטל חוזרים על ההטעיה של Epyc שמורכב כביכול מ-4 מעבדי Ryzen, ולגבי ה-Track Record, חבל שאינטל מזכירה זאת בשעה שהיא עברה על כל חוק אפשרי כדי לגרום לכל היצרנים לא לייצר שום שרת עם מעבדי AMD והאיחוד האירופאי דפק לאינטל קנס של 1.4 מיליארד יורו על כך (אינטל עדיין מערערת על כך), ולקינוי – Lack of Ecosystem… אהמממ… כל יצרני הלוחות והשרתים תומכים במעבדים של AMD, חברת Baidu החליטה לרכוש כמות גדולה של המעבדים ומיקרוסופט… מכניסה אותם ל-Azure.בנוסף, כל חברות התוכנה הגדולות (כולל VMware, יצרני הפצות לינוקס, Oracle ואחרים) תומכים בהם לחלוטין. לא הייתי קורא לזה Ecosystem גרוע.

את השקף לעיל .. חבל שאינטל יצרו והם מנסים להפוך אנשים שהפרנסה שלהם היא וירטואליזציה – לטיפשים/מטומטמים. כל מי שניסה אי פעם Live Migration יודע שאתה מאבד תכונות מסויימות ברגע שאתה מעביר VM בין שרת לשרת ב-Live Migration כאשר בכל שרת יש דור אחר של מעבדי אינטל, וכן, אותו דבר קורה גם עם מעבדי Epyc אך יש דרכים לעקוף זאת.

בנוסף, אם אנחנו כבר מדברים על וירטואליזציה, אולי תשמחו לשמוע על "סוד" קטן: עם VT-D של אינטל, אם יש לכם נניח כרטיס רשת עם 4 או 6 פורטים (יש לי 2 כאלו של 6 פורטים פה בבית, דבר מדהים!) תוכלו למפות אל הכרטיס כולו ל-VM בלבד. עם SR-IOV של AMD לעומת זאת, תוכלו למפות כל כניסה ישירות ל-VM ללא כל שכבות התרגום ולקבל 95% ביצועים! בנוסף, עם Epyc יש 64 מסלולי PCIe כך שאפשר לדחוף מספר רב כרטיסים לשרת ולמפות כל אחד פר VM ומימוש ה-SR-IOV עושה את החיים הרבה יותר קלים, וזה נתמך ב-VMWare 6, Xen, KVM.

בקיצור – אם כבר מדברים על וירטואליזציה, יש לאינטל לא מעט מה לשפר ואולי לגמור סוף סוף עם הבעיה שעדיין כיום ב-2017 חלק לא קטן מהמחשבים מגיע ללא VT-D? זה כבר פאדיחה.

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

לפנינו טבלת המחירים של אינטל למעבדי Skylake-SP. יש מגוון מעבדים (58) שמחולקים ל-4 משפחות, בטבלה למעלה רואים את המשפחה הכי יקרה וה-5 המעבדים העליונים – הם היחידים עם 28 ליבות (המקסימום שאינטל מוכרים) עם אפשרויות כמו הכפלת זכרון (תמיכה ב-LR DIMM), תמיכה ב-Omnipath ועוד.

שימו לב למחירים מצד ימין. רוצה מעבד עם הכי הרבה ליבות? המינימום שתצטרך להיפרד ממנו זה 8719$. המעבד הכי יקר של AMD לשרתים הוא ה-Epyc 6701 והוא עולה פחות ממחצית מהסכום של אינטל – כ-4200$. רק מההפרש אפשר לרכוש 2 שרתים בתצורת בסיסית של HPE או DELL או שרת אחד עם כמות זכרון ודיסקים גדולה.

אלו המחירים של AMD, הטבלה העליונה היא למעבדים עבור לוחות בעלי 2 תושבות ואילו הטבלה למטה הם ללוחות עם תושבת מעבד אחת, כך שכפי שאתם יכולים לראות, אתם יכולים לרכוש שרת עם לוח ומעבד יחיד עם 32 ליבות, 64 נימים, עד 2 טרה זכרון ו-64 מסלולי PCIe – ב-2100$, רבע מהמחיר שאינטל מבקשת על מעבד יחיד עם 28 ליבות. חתיכת חסכון, לא?

לכל חברה יש ארכיקטורה משלה למעבדים ויש דברים שאינטל מעולה בהם אך יש דברים ש-AMD מעולים בהם והכל תלוי בצרכים שלכם. אם מחר תרצה לדוגמא להקים שרת Microsoft SQL Server "על הברזל" ולא ב-VM (באמת???) – אז קנה את המעבדים של אינטל. וירטואליזציה? המעבדים של AMD נותנים פתרון יותר טוב הן ברמת מיפוי ציוד והן ברמת ביצועים (שים לב שעם מעבדי Epyc ו-VMWare תצטרך את VMWare vSphere 6.5U1) ויש עוד סיטואציות רבות ולכן מומלץ לקרוא סקירות עצמאיות ולא להקשיב לסוכני מכירות הן של אינטל או AMD. יחד עם זאת, אני כן ממליץ לחשוב עם ראש פתוח ולקחת בחשבון את התחרות במקום "להינעל" על יצרן מעבדים מסוים. בניגוד להצהרות של אינטל, כש-AMD מכרו את מעבדי ה-Opteron הם בהחלט נתנו תמיכה ללינוקס על המעבדים ול-AMD יש היסטוריה מכובדת של תמיכה בלינוקס עוד לפני שאינטל החליטו להסתכל על לינוקס בצורה רצינית.

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

אשמח אם תוכלו לשתף פוסט זה עם מנמר"ים / מנהלי IT אחרים.

הטקסט המלא

15 July, 2017 09:17 AM

I've been working on the Bailador book and the Crowdfunding campaign for more than 3 months now. About 2 of them publicly. The campaign ends in a week and the book already has 68 pages. It might be time to explain why am I doing this? It's clear that the money is not good. I could earn a lot more in the time I spend on writing the book. Then why?

For the full article visit Why am I writing the Bailador Book?

13 July, 2017 02:51 PM

ההכנות לאוגוסט פינגווין 2017 מעלות הילוך!

למי שלא יודע עדיין, אוגוסט פינגווין, הכנס השנתי של קהילת הקוד הפתוח והתוכנה החופשית בישראל, יתקיים השנה ב־7-‎8 בספטמבר במכללת שנקר בר״ג.

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

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

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

שיהיה קיץ קריר ונעים!

12 July, 2017 02:36 PM

הטקסט המלא

12 July, 2017 09:01 AM

This is not my typical blog post style. So no "how to" or opinnions. Just some reflections on how I submitted a patch to Python's standard library. continue reading...

11 July, 2017 06:56 AM

10 July, 2017 06:04 PM

Background

I’m a systems engineer. The job that I’m doing is also called system, SRE, DevOps, production engineer, etc. I define my job as everything between “It works on my machine” of a developer and real life. Common tasks are setting up and maintaining cloud-based infrastructure: networking, compute, databases and other services. Other common tasks are setting up, configuring and maintaining everything inside a VM: disks+mounts, packages, configuration files, users, services. Additional aspects include monitoring, logging and graphing.

The problem

If we take specifically systems engineering tasks such as running a VM instance in a cloud, installing and running programs on a server and modifying configuration files, typical scripting (when no special tools are used) is done in either bash or Python/Ruby/Perl/Go.

Bash

The advantage of bash is that bash is domain specific. It is convenient for running external programs and files manipulation.

# Count lines in all *.c files in this directory and below
wc -l $(find . -name '*.c')

# Make sure my_file has the line my_content
echo my_content >my_file

# Run a process and capture the output
out=$(my_process)

The disadvantage of bash is horrible syntax, pitfalls everywhere, awkward error handling and many features one would expect from a programming language (such as data structures, named functions parameters, etc) are missing.

# Inconsistent, awkward syntax,
# result of keeping backwards compatibility
if something;    then ... fi
while something; do ... done

# Can remove / if MY_DIR is not defined
# unless in "set -u" mode
rm -rf "$MY_DIR/"

# Removes files "a" and "b" instead of "a b"
myfile="a b"
rm $myfile

# Silently ignores the error unless in "set -e" mode
my_script

# Function parameters can't be named, they are
# in $1, $2, ... or in $@ and $*
myfunc() {
  FILE="$1"
  OPTION_TO_ENABLE="$2"
  ...
}

Leave bash alone, it was not intended for programming, don’t do anything in bash, just use external programs for everything.

What do you observe? Is it or is it not used as a programming language in real life?

General-Purpose programming languages

Python/Ruby/Perl/Go are general-purpose programming languages.

The advantage of general-purpose programming languages is in their power, better syntax, ability to handle arbitrary data structures.

orig = [1,2,3]
doubled = [x*2 for x in orig]

The disadvantage of general-purpose programming languages is that they are not and can not be as convenient for systems engineering tasks because they are not focusing on this particular aspect of programming (in contrast to bash and other shells for example).

# Write whole file - too verbose
f = open('myfile', 'w+')
f.write('mycontent')
f.close()

# Run a process and capture the output
# https://docs.python.org/3.5/library/subprocess.html
proc = subprocess.Popen(...)
try:
    outs, errs = proc.communicate(timeout=15)
except TimeoutExpired:
    proc.kill()
    outs, errs = proc.communicate()

Summary

My conclusion is that there is no handy language for systems engineering tasks. On one hand there is bash that is domain specific but is not a good programming language and does not cover today’s needs, on the other hand there are general-purpose programming languages which do not specialize on this kinds of tasks.

You can use Puppet, Chef, Ansible, Terraform, CloudFormation, Capistrano and many other tools for common systems engineering tasks. What if your task is not covered by existing tools? Maybe one-off? Maybe a case where using one of the existing tools is not an optimal solution? You would like to write a script, right? In that case, your life sucks because scripting sucks. That’s because there is no convenient language and libraries to get systems engineering tasks done with minimal friction and effort.

Solution

I suggest, creating a new programming language (with a shell) which is domain specific, as bash, and which incorporates important features of general-purpose programming languages: data structures, exceptions, types, multiple dispatch.

My way of looking at it: imagine that bash was created today, taking into account today’s reality and things that became clear with time. Some of them are:

• The shell is used as a programming language.
• A system is usually a set of VMs and APIs, not a single machine.
• Most APIs return JSON so data structures are needed as multiple jq calls are not convenient.
• Silently ignoring errors proved to be bad strategy (hence set -e switch which tries to solve the problem).
• Silently substituting undefined variables with empty strings proved to be bad strategy (hence set -u switch).
• Expanding $x into multiple arguments proved to be error prone.
• Syntax matters.
• History entries without context have limited usefulness (cd $DIR for example: what was the current directory before cd and what was in $DIR ?)
• UX
  • Spitting lots of text to a terminal is useless as it can not be processed by a human.
  • Feedback is important.
    • Exit code should be displayed by default.
    • An effort should be made to display status and progress of a process.
    • Ideally, something like pv should be integrated into the shell.

I’m not only suggesting the solution I’ve just described. I’m working on it. Please give it a try and/or join to help developing it: NGS – Next Generation Shell.

# Make sure my_file has the line my_content
echo my_content >my_file

# Run a process and capture the output
out=`my_process`

# Get process handle (used to access output, exit code, killing)
p=$(my_process)

# Get process output and parse it, getting structured data
amis=``aws ec2 describe-images --owner self``
echo(amis.len()) # number of amis, not lines in output

# Functional programming support
orig = [1,2,3]
doubled = orig.map(X*2)

# Function parameters can be named, have default values, etc
F myfunc(a,b=1,*args,**kwargs) {
  ...
}

# Create AWS VPC and Gateway (idempotent)
NGS_BUILD_CIDR = '192.168.120.0/24'
NGS_BUILD_TAGS = {'Name': 'ngs-build'}
vpc = AWS::Vpc(NGS_BUILD_TAGS).converge(CidrBlock=NGS_BUILD_CIDR, Tags=NGS_BUILD_TAGS)
gw  = AWS::Igw(Attachments=[{'VpcId': vpc}]).converge(Tags=NGS_BUILD_TAGS)

Popular questions with answers

I don’t think scripting is the right approach.

It really depends on the task, constraints, your approach and available alternative solutions. I expect that situations needing scripting will be with us for a while.

Another programming language? Really? Why the world needs yet another programming language?

I agree that creating a new language needs justification because the effort that goes into creating a language and learning a language is considerable. Productivity gains of using the new language must outweigh the effort of learning and switching.

NGS creation is justified in exactly the same way as many other languages were justified: dissatisfaction with all existing programming languages when trying to solve specific problem or a set of similar problems. In case of NGS the dissatisfaction is specifically how existing programming languages address the systems engineering tasks niche. NGS addresses this particular niche with a unique combination of features and trade offs. Productivity of using NGS comes from best match between the tool and the problems being solved.

Yet another shell? We have plenty already but they all have serious adoption problems.

NGS will be implementing ideas which are not present in other shells. Hopefully, the advantages will be worthy enough to justify switching.

I’ll be just fine with bash/Python/Ruby/Perl/Go

You will. The decision to learn and use a new language depends on your circumstances: how many systems engineering tasks you are doing, how much you suffer, how much easier the tasks will become with NGS, how easily this can be done in your company / on your project and whether you are willing to take the risk.

You could just write a shell based on Ruby or Python or whatever, leveraging all the time and effort invested in existing language.

I could and I didn’t. Someone else did it for Python and for Scala (take a look, these are interesting projects).

• I don’t think it’s the right solution to stretch existing language to become something else.
• NGS has features that can not be implemented in a straightforward way as a library: special syntaxes for common tasks, multiple dispatch.

One could just write a library for Python or Ruby or whatever happens to be his/her favorite programming language, leveraging all the time and effort already invested in existing language.

In order to be similar to NGS, one would not only have to build a library but also change language syntax. I personally know only two languages that can do that: Lisp (using reader macros) and Perl6 (using grammar facility). These are general-purpose programming languages. Turning them into something NGS-like will be a significant effort, which I don’t think is justified.

PowerShell appears to be similar to what you describe here.

Note that I have very limited experience with PowerShell. The only aspect I definitely like is consistent usage of the $ sigil.

• It’s probably a matter of taste and what you are accustomed to but I like NGS’ syntax more. PowerShell is pretty verbose.
• DSC appears to be focused on resources inside a server/VM. NGS plans similar functionality. Meanwhile, NGS uses this approach in the AWS library: vpc = AWS::Vpc(NGS_BUILD_TAGS).converge(CidrBlock=NGS_BUILD_CIDR, Tags=NGS_BUILD_TAGS)

There are libraries for Python that make systems engineering tasks easier.

Right, sh for example. Such solution can’t be used as shell, it just improves the experience of calling external program from Python.

Was this post convincing? Anything is missing to convince you personally? Let me know!

Have a nice day!

07 July, 2017 05:24 AM

The more work on orchestrator, the more user input and the more production experience, the more insights I get into MySQL master recoveries. I'd like to share the complexities in correctly running general-purpose master failovers; from picking up the right candidates to finalizing the promotion.

The TL;DR is: we're often unaware of just how things can turn at the time of failover, and the impact of every single decision we make. Different environments have different requirements, and different users wish to have different policies. Understanding the scenarios can help you make the right choice.

The scenarios and considerations below are ones I picked while browsing through the orchestrator code and through Issues and questions. There are more. There are always more scenarios.

I discuss "normal replication" scenarios below; some of these will apply to synchronous replication setups (Galera, XtraDB Cluster, InnoDB Cluster) where using cross DC, where using intermediate masters, where working in an evolving environment.

orchestrator-wise, please refer to "MySQL High Availability tools" followup, the missing piece: orchestrator, an earlier post. Some notions from that post are re-iterated here.

Who to promote?

Largely covered by the missing piece post (skip this section if you've read said post), consider the following:

• You run with a mixed versions setup. Your master is 5.6, most your replicas are 5.6 but you've upgraded a couple replicas to 5.7. You must not promote those 5.7 servers since you cannot replicate 5.7->5.6. You may lose these servers upon failover.
• But perhaps by now you've upgraded most of your replicas to 5.7, in which case you prefer to promote a 5.7 server in the event the alternative is losing your 5.7 fleet.
• You run with both STATEMENT based replication and ROW based. You must not promote a ROW based replica because a STATEMENT based server cannot replicate from it. You may lose ROW servers during the failover.
• But perhaps by now you've upgraded most of your replicas to ROW, in which case you prefer to promote a ROW server in the event the alternative is losing your ROW fleet.
• Some servers can't be promoted because they don't use binary logging or log_slave_updates. They could be lost in action.

Noteworthy that MHA solves the above by syncing relay logs across the replicas. I had an attempt at doing the same for orchestrator but was unsatisfied with the results and am wary of hidden assumptions. I do not expect to continue working on that.

Intermediate masters

Recovery of intermediate masters, while simpler, also adds many more questions to the table.

• An intermediate master crashes. What is the correct handling? Should you move all of its orphaned replicas under another server? Or does this group of replicas form some pact that must stick together? Perhaps you insist on promoting one of them on top of its siblings.
• On failure, you are likely to prefer promoted server from same DC; this will have least impact on your application.
  • But are you willing to lose a server or two to make that so? Or do you prefer switching to a different DC and not lose any server in the process?
  • A specific, large orchestrator user actually wants to failover to a different DC. Not only that, the customer then prefers flipping all other cluster masters to the other DC (a full-DC failover)
• An intermediate master had replication filters (scenario: you were working to extract and refactor a subtree onto its own cluster, but the IM crashed before you did so)
  • What do you do? Did you have all subsequent replicas run with same filters?
  • If not, do you have the playbook to do so at time of failure?
• An intermediate master was writable. It crashed. What do you do? Who is a legitimate replacement? How can you even reconnect the subtree with the main tree?

Candidates

• Do you prefer some servers over others? Some servers have stronger hardware; you'd like them to be promoted if possible
  • orchestrator can juggle with that to some extent.
• Are there servers you never want to promote? Servers used by developers; used for backups with open logical volumes; weaker hardware; a DC you don't want to failover to; ...
  • But then again, maybe it's fine if those servers act as intermediate masters? So that they must not be promoted as masters, but are good to participate in an intermediate master failover?
• How do you even define the promotion types for those servers?
  • We strongly prefer to do this live. Service discovery dictates the type of "promotion rule"; a recurring cronjob keeps updating orchestrator with the server's choice of promotion rule.
  • We strongly discourage configuration based rules, unless for servers which are obviously-never-promote.

What to respond to?

What is a scenario that kicks a failover?

Relate to the missing piece post for the holistic approach orchestrator takes to make a reliable detection. But regardless, do you want to take action where:

• The master is completely dead and everyone sees that and agrees? (resounding yes)
• The master is dead to the application but replication seems to be working? (master is at deadlock, but replication threads seem to be happy)
• The master is half-dead to the application? (no new connections; old connections includign replication connections keep on running!)
• A DC is network partitioned, the master is alive with some replicas in that DC; but the majority of the replicas are in other DCs, unable to see the master?
  • Is this a question of majority? Of DC preference? Is there at all an answer?

Upon promotion

Most people expect orchestrator to RESET SLAVE ALL and SET read_only=0 upon promotion. This is possible, but the default is not to do so. Why?

• What if your promoted server still has unapplied relay logs? This can happen in the event all replicas were lagging at the time of master failure. Do you prefer:
  • To promote, RESET SLAVE ALL and lose all those relay logs? You gain availability at the expense of losing data.
  • To wait till SQL_THREAD has consumed the logs? You keep your data at the expense of availability.
  • To abort? You let a human handle this; this is likely to take more time.
• What do you do with delayed/slow replicas? It could take a while to connect them back to the promoted master. Do you prefer:
  • Waiting for them to connect; delay promotion
  • Advertise new master, then asynchronously work to connect them: you may have improved availability, but at reduced capacity, which is an availability issue in itself.

Flapping

You wish to avoid flapping. A scenario could be that you're placing such load on your master that it crashes; the next server to promote as master will have the same load, will similarly crash. You do not wish to exhaust your fleet.

What makes a reasonable anti-flapping rule? Options:

• Upon any failure in a cluster, block any other failover on that cluster for X minutes
  • What happens if a major power down issue requires two or three failovers on the same cluster?
• Only block further master failovers, but allow intermediate master failovers as much as needed
  • There could be intermediate master exhaustion, as well
• Only allow one of each (master and intermediate master), then block for X minutes?
• Allow a burst of failovers for a duration of N seconds, then block for X minutes?

Detection spam

You don't always take action on failure detection. Maybe you're blocked via anti-flapping on an earlier failure; or have configured to not automatically failover.

Detection is the basis to, but independent of failover. You should have detection in place even if not failing over.

You wish to run detection continuously.

• So if failover does not take place, detection will keep noticing the same problem again and again.
  • You get spammed by alerts
• Only detect once?
  • Been there. When you really need that detection to alert you find out it alerted once 6 hours ago and you ignored it because it was not actionable at the time.
• Only detect a change in diagnosis?
  • Been there. Diagnosis itself can flap back and forth. You get noise.
• Block detection for X minutes?
  • What is a good tradeoff between noise and visibility?

Back to life

And old sub-tree comes back to life. Scenario: DC power failure.

This subtree claims "I'm cluster X". What happens?

• Your infrastructure needs to have memory and understanding that there's already a running cluster called X.
• Any failures within that subtree must not be interpreted as a "cluster X failure", or else you kick a cluster X failover when there is, in fact, a running cluster X. See this PR and related links. At this time orchestrator handles this scenario correctly.
• When do you consider a previously-dead server to be alive and well?
  • I do mean, automatically and reliably so? See same PR for orchestrator's take.

User control

Failover tooling must always let a human decide something is broken. It must always allow for an urgent failover, even if nothing seems to be wrong to the system.

Isn't this just so broken? Isn't synchronous replication the answer?

The world is broken, and distributed systems are hard.

Synchronous replication is an answer, and solves many (I think) of the above issues, creating its own issues, but I'm not an expert on that.

However noteworthy that when some people think about synchronous replication they forget about cross-DC replication and cross-DC failovers,on upgrades and experiments. The moment you put intermediate masters at play, you're almost back to square one with many of the above questions again applicable to your use case.

29 June, 2017 03:01 PM

I have been contemplating the idea for quite some time, but finally I've decided to extend the Bailador crowdfunding campaign by another month.

For the full article visit Extending the Bailador crowdfunding campaign by another month

22 June, 2017 06:27 AM

אז לפתע פתאום האקדמיה ללשון שינתה את כללי הכתיב.

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

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

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

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

אני מרוצה מהשינוי של „תכנה” ו„יזמה” ל„תוכנה” ו„יוזמה”. אני גם מרוצה למדי מהשינוי של מילות היחס „אתי, אתך” ל„איתי, איתך”, ושל „עתים” ל„עיתים”, אבל מוזר לי ביותר שלא נוספה בהזדמנות הזאת האות יו״ד למילים כמו „אִגרוף” ו„מִחזור”, כדי לא להתבלבל עם „אֶגרוף” ו„מַחזור”. זה היה יכול להיות כלל פשוט ושימושי, והוא ממש לא היה אמור להיות שנוי במחלוקת. חבל שזה התפספס.

עוד משעשעים אותי ה„אישורים” שנינתו למילה „אומנם” וליו״ד בצורת הגוף הראשון בזמן עתיד בבניין נפעל, למשל „איכנס” במקום „אכנס”. אני תמיד כתבתי אותם בכתיב מלא. את „אומנם” כתבתי בווי״ו כי גם „אֻמנם” הוא ניקוד תקני ולא רק „אָמנם”, וצליל u תמיד אמור להיכתב בווי״ו (אם כי עכשיו גיליתי לראשונה שהניקוד „אֻמנם” מיועד לשאלות, לפחות לפי אבן־שושן). ובבניין נפעל כתבתי תמיד „איכנס”, „איזהר”, וכו׳, כי הניקוד בחיריק תקין כמו בניקוד בסגול (ר׳ למשל גזניוס 51p).

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

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

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

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

18 June, 2017 11:03 AM

Sometimes you need quick and dirty implementation of greatest common divisor and its extended variant. Actually, because the fractions module comes gcd function, probably the implementation of the exteded greatest common divisor algorithm is more useful. Both implementations are recursive, but work nonetheless even for comparatively large integers.

# simply returns the gcd
gcd = lambda a,b: gcd(b, a % b) if b else a

# egcd(a,b) returns (d,x,y) where d == a*x + b*y
egcd = lambda a,b: (lambda d,x,y: (d, y, x - (a // b) * y))(*egcd(b, a % b)) if b else (a, 1, 0)

The code above is Python 2 and 3 compatible.

17 June, 2017 02:14 PM

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

משום מה בחרו לאחסן חלק מידע בשרתי גוגל וב CDN של bootstrap במקום לאחסון בשירותי הממשל, אבל לפחות את רוב האתר איחסנו תחת הדומיין gov.il.

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

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

אם היו מאפשרים להשתמש במידע של govmap בתנאי השימוש, יכול להיות שהיה אפשר למשל לשתף מידע עם OSM או לאפשר משיכת מידע ושכבות בתוכנות צד שלישי ובאתרים אחרים.זאת כמובן ע"י נתינת הקרדיט הנדרש  כמו שעושים כשמתמשים ב OpenLayers או Marble אבל אי אפשר.

מישהוא החליט לאסור את שיתוף ושימוש ולכן אם אתה כותב תוכנה חופשית ב GIS לא כדאי לך התקרב לgovmap בלי בירוקרטיה, וזה ממש חבל כאשר יש לך API נוח כמו KeshetAnnan שיודע למשוך מידע מרשות המיסים וממערכת המיפוי בפעולת rest פשוטות.

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

כאשר ניגשים לאתר מגלים שהוא מתהדר בתמיכה ב דסקטופ טאבלט ומובייל. רק שככל הנראה אין זה לא כולל פיירפוקס (אבל זה עובד ב IE ו Edge) על Win10  או Gnu/Linux.

בפיירפוקס זה נראה כך :

ואם בודקים בשגיאות רואים :

10:28:24.704 Error: this.predictorInput.offsetParent is null
AmlPredictor/this.Initialize@https://www.nadlan.gov.il/scripts/dis/bundleJS.js?v=1.0.24:20725:9
a/this.link/<@https://www.nadlan.gov.il/KeshetAnan/dis/out.directives.js?v=1.0.24:2:1846
timeout/timeoutId<@https://www.nadlan.gov.il/scripts/dis/bundleJS.js?v=1.0.24:38440:28
completeOutstandingRequest@https://www.nadlan.gov.il/scripts/dis/bundleJS.js?v=1.0.24:27065:7
Browser/self.defer/timeoutId<@https://www.nadlan.gov.il/scripts/dis/bundleJS.js?v=1.0.24:27453:7
 1 bundleJS.js:33796:18
 consoleLog/< https://www.nadlan.gov.il/scripts/dis/bundleJS.js:33796:18
 $ExceptionHandlerProvider/this.$get</< https://www.nadlan.gov.il/scripts/dis/bundleJS.js:30737:7
 timeout/timeoutId< https://www.nadlan.gov.il/scripts/dis/bundleJS.js:38443:11
 completeOutstandingRequest https://www.nadlan.gov.il/scripts/dis/bundleJS.js:27065:7
 Browser/self.defer/timeoutId< https://www.nadlan.gov.il/scripts/dis/bundleJS.js:27453:7

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

קונקי 4.4.25 הצליח להציג את דף החיפוש, אבל לא הצליח להציג את התוכן, חיפוש ע"ג המפה כן עושה רושם שיעבוד :

לפעמים המפה מוצגת ולפעמים זה :

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


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

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

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

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

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

14 June, 2017 10:59 AM

00:00.0 Host bridge: Intel Corporation Device 5904 (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Device 5916 (rev 02)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 02)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1)
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Device 9d58 (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Device 9d71 (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
02:00.0 Network controller: Intel Corporation Wireless 3165 (rev 79)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

14 June, 2017 10:37 AM

debian.org.il היה חלק מה"חוב הטכני" שלי. מדובר באתר די פשוט שנבנה עם Django pre-1.0 ופייתון 2.6, והציג נהלים לקויים (כמו הכללת שם הפרוייקט ב־import).

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

הקוד החדש באתר כולל:

• עיצוב Mobile first וריספונסיבי, מבוסס על Pure.css
• פייתון 3
• Django 1.11
• משתמש ב־class based generic views
• ארגון קוד משופר
• החלפת יישום התגים המותאם ב־ django-taggit
• הגדרות מבוססות משתני סביבה, בעזרת django-environ

הפריעה לי גם העובדה שהקוד מעולם לא פורסם (היה קובץ settings.py בודד, עם הסיסמאות בתוכו וכד'). גם נקודה זו טופלה והקוד זמין כעת בגיטהאב:

https://github.com/MeirKriheli/debian.org.il

09 May, 2017 02:41 PM

This year I decided to participate in Midburn, the Israeli version of burning man. Whiling thinking of doing something different from my usual habit, I found myself with volunteering in the midburn IT department and getting a task to make it an open source project. Back into my comfort zone, while trying to escape it.

I found a community of volunteers from the Israeli high tech scene who work together for building the infrastructure for Midburn. In many ways, it’s already an open source community by the way it works. One critical and formal fact was lacking, and that’s the license for the code. After some discussion we decided on using Apache License 2.0 and I started the process of changing the license, taking it seriously, making sure it goes “by the rules”.

Our code is available on GitHub at https://github.com/Midburn/. And while it still need to be more tidy, I prefer the release early and often approach. The main idea we want to bring to the Burn infrastructure is using Spark as a database and have already began talking with parallel teams of other burn events. I’ll follow up on our technological agenda / vision. In the mean while, you are more than welcome to comment on the code or join one of the teams (e.g. volunteers module to organize who does which shift during the event).

Full text

19 April, 2017 03:01 PM

The following screenshot of a systemd issue reported on github saysit all. I don't care if systemd is technically superior, the way it's being developed is truely bothering. It's leadership is insisting on being blunt ingoring users, misleading and even wrong. continue reading...

17 April, 2017 02:36 PM

Sometimes programming language developers decide that certain practices are bad, so bad that they try to prevent their use through the language they develop. For example: In both Java and C# multiple inheritance is not allowed. The language standard prohibits it, so trying to specify more than one base class will result in compiler error. […]

15 April, 2017 05:24 PM

As you probably already know, Wikipedia is a website. A website has content—the articles; and it has user interface—the menus around the articles and the various screens that let editors edit the articles and communicate to each other.

Another thing that you probably already know is that Wikipedia is massively multilingual, so both the content and the user interface must be translated.

Translation of articles is a topic for another post. This post is about getting all of the user interface translated to your language, as quickly and efficiently as possible.

The most important piece of software that powers Wikipedia and its sister projects is called MediaWiki. As of today, there are 3,335 messages to translate in MediaWiki, and the number grows frequently. “Messages” in the MediaWiki jargon are strings that are shown in the user interface, and that can be translated. In addition to core MediaWiki, Wikipedia also has dozens of MediaWiki extensions installed, some of them very important—extensions for displaying citations and mathematical formulas, uploading files, receiving notifications, mobile browsing, different editing environments, etc. There are around 3,500 messages to translate in the main extensions, and over 10,000 messages to translate if you want to have all the extensions translated. There are also the Wikipedia mobile apps and additional tools for making automated edits (bots) and monitoring vandalism, with several hundreds of messages each.

Translating all of it probably sounds like an enormous job, and yes, it takes time, but it’s doable.

In February 2011 or so—sorry, I don’t remember the exact date—I completed the translation into Hebrew of all of the messages that are needed for Wikipedia and projects related to it. All. The total, complete, no-excuses, premium Wikipedia experience, in Hebrew. Every single part of the MediaWiki software, extensions and additional tools was translated to Hebrew, and if you were a Hebrew speaker, you didn’t need to know a single English word to use it.

I wasn’t the only one who did this of course. There were plenty of other people who did this before I joined the effort, and plenty of others who helped along the way: Rotem Dan, Ofra Hod, Yaron Shahrabani, Rotem Liss, Or Shapiro, Shani Evenshtein, Inkbug (whose real name I don’t know), and many others. But back then in 2011 it was I who made a conscious effort to get to 100%. It took me quite a few weeks, but I made it.

Of course, the software that powers Wikipedia changes every single day. So the day after the translations statistics got to 100%, they went down to 99%, because new messages to translate were added. But there were just a few of them, and it took me a few minutes to translate them and get back to 100%.

I’ve been doing this almost every day since then, keeping Hebrew at 100%. Sometimes it slips because I am traveling or I am ill. It slipped for quite a few months because in late 2014 I became a father, and a lot of new messages happened to be added at the same time, but Hebrew is back at 100% now. And I keep doing this.

With the sincere hope that this will be useful for translating the software behind Wikipedia to your language, let me tell you how.

Preparation

First, let’s do some work to set you up.

• Get a translatewiki.net account if you haven’t already.
• Make sure you know your language code.
• Go to your preferences, to the Editing tab, and add languages that you know to Assistant languages. For example, if you speak one of the native languages of South America like Aymara (ay) or Quechua (qu), then you probably also know Spanish (es) or Portuguese (pt), and if you speak one of the languages of the former Soviet Union like Tatar (tt) or Azerbaijani (az), then you probably also know Russian (ru). When available, translations to these languages will be shown in addition to English.
• Familiarize yourself with the Support page and with the general localization guidelines for MediaWiki.
• Add yourself to the portal for your language. The page name is Portal:Xyz, where Xyz is your language code.

Priorities, part 1

The translatewiki.net website hosts many projects to translate beyond stuff related to Wikipedia. It hosts such respectable Free Software projects as OpenStreetMap, Etherpad, MathJax, Blockly, and others. Also, not all the MediaWiki extensions are used on Wikimedia projects; there are plenty of extensions, with thousands of translatable messages, that are not used by Wikimedia, but only on other sites, but they use translatewiki.net as the platform for translation of their user interface.

It would be nice to translate all of it, but because I don’t have time for that, I have to prioritize.

On my translatewiki.net user page I have a list of direct links to the translation interface of the projects that are the most important:

• Core MediaWiki: the heart of it all
• Extensions used by Wikimedia: the extensions on Wikipedia and related sites
• MediaWiki Action Api: the documentation of the API functions, mostly interesting to developers who build tools around Wikimedia projects
• Wikipedia Android app
• Wikipedia iOS app
• Installer: MediaWiki’s installer, not used in Wikipedia because MediaWiki is already installed there, but useful for people who install their own instances of MediaWiki, in particular new developers
• Intuition: a set of different tools, like edit counters, statistics collectors, etc.
• Pywikibot: a library for writing bots—scripts that make useful automatic edits to MediaWiki sites.

I usually don’t work on translating other projects unless all of the above projects are 100% translated to Hebrew. I occasionally make an exception for OpenStreetMap or Etherpad, but only if there’s little to translate there and the untranslated MediaWiki-related projects are not very important.

Priorities, part 2

So how can you know what is important among more than 15,000 messages from the Wikimedia universe?

Start from MediaWiki most important messages. If your language is not at 100% in this list, it absolutely must be. This list is automatically created periodically by counting which 600 or so messages are actually shown most frequently to Wikipedia users. This list includes messages from MediaWiki core and a bunch of extensions, so when you’re done with it, you’ll see that the statistics for several groups improved by themselves.

Now, if the translation of MediaWiki core to your language is not yet at 18%, get it there. Why 18%? Because that’s the threshold for exporting your language to the source code. This is essential for making it possible to use your language in your Wikipedia (or Incubator). It will be quite easy to find short and simple messages to translate (of course, you still have to do it carefully and correctly).

Getting Things Done, One by One

Once you have the most important MediaWiki messages 100% and at least 18% of MediaWiki core is translated to your language, where do you go next?

I have surprising advice.

You need to get everything to 100% eventually. There are several ways to get there. Your mileage may vary, but I’m going to suggest the way that worked for me: Complete the easiest piece that will get your language closer to 100%! For me this is an easy way to strike an item off my list and feel that I accomplished something.

But still, there are so many items at which you could start looking! So here’s my selection of components that are more user-visible and less technical, sorted not by importance, but by the number of messages to translate:

• Cite: the extension that displays footnotes on Wikipedia
• Babel: the extension that displays boxes on userpages with information about the languages that the user knows
• Math: the extension that displays math formulas in articles
• Thanks: the extension for sending “thank you” messages to other editors
• Universal Language Selector: the extension that lets people select the language they need from a long list of languages (disclaimer: I am one of its developers)
  • jquery.uls: an internal component of Universal Language Selector that has to be translated separately for technical reasons
• Wikibase Client: the part of Wikidata that appears on Wikipedia, mostly for handling interlanguage links
• VisualEditor: the extension that allows Wikipedia articles to be edited in a WYSIWYG style
• ProofreadPage: the extension that makes it easy to digitize PDF and DjVu files on Wikisource
• Wikibase Lib: additional messages for Wikidata
• Echo: the extension that shows notifications about messages and events (the red numbers at the top of Wikipedia)
• MobileFrontend: the extension that adapts MediaWiki to mobile phones
• WikiEditor: the toolbar for the classic wiki syntax editor
• ContentTranslation extension that helps translate articles between languages (disclaimer: I am one of its developers)
• Wikipedia Android mobile app
• Wikipedia iOS mobile app
• UploadWizard: the extension that helps people upload files to Wikimedia Commons comfortably
• Flow: the extension that is starting to make talk pages more comfortable to use
• Wikibase Repo: the extension that powers the Wikidata website
• Translate: the extension that powers translatewiki.net itself (disclaimer: I am one of its developers)
• MediaWiki core: the base MediaWiki software itself!

I put MediaWiki core last intentionally. It’s a very large message group, with over 3000 messages. It’s hard to get it completed quickly, and to be honest, some of its features are not seen very frequently by users who aren’t site administrators or very advanced editors. By all means, do complete it, try to do it as early as possible, and get your friends to help you, but it’s also OK if it takes some time.

Getting All Things Done

OK, so if you translate all the items above, you’ll make Wikipedia in your language mostly usable for most readers and editors.

But let’s go further.

Let’s go further not just for the sake of seeing pure 100% in the statistics everywhere. There’s more.

As I wrote above, the software changes every single day. So do the translatable messages. You need to get your language to 100% not just once; you need to keep doing it continuously.

Once you make the effort of getting to 100%, it will be much easier to keep it there. This means translating some things that are used rarely (but used nevertheless; otherwise they’d be removed). This means investing a few more days or weeks into translating-translating-translating.

You’ll be able to congratulate yourself not only upon the big accomplishment of getting everything to 100%, but also upon the accomplishments along the way.

One strategy to accomplish this is translating extension by extension. This means, going to your translatewiki.net language statistics: here’s an example with Albanian, but choose your own language. Click “expand” on MediaWiki, then again “expand” on “MediaWiki Extensions”, then on “Extensions used by Wikimedia” and finally, on “Extensions used by Wikimedia – Main”. Similarly to what I described above, find the smaller extensions first and translate them. Once you’re done with all the Main extensions, do all the extensions used by Wikimedia. (Going to all extensions, beyond Extensions used by Wikimedia, helps users of these extensions, but doesn’t help Wikipedia very much.) This strategy can work well if you have several people translating to your language, because it’s easy to divide work by topic.

Another strategy is quiet and friendly competition with other languages. Open the statistics for Extensions Used by Wikimedia – Main and sort the table by the “Completion” column. Find your language. Now translate as many messages as needed to pass the language above you in the list. Then translate as many messages as needed to pass the next language above you in the list. Repeat until you get to 100%.

For example, here’s an excerpt from the statistics for today:

Let’s say that you are translating to Malay. You only need to translate eight messages to go up a notch (901 – 894 + 1). Then six messages more to go up another notch (894 – 888). And so on.

Once you’re done, you will have translated over 3,400 messages, but it’s much easier to do it in small steps.

Once you get to 100% in the main extensions, do the same with all the Extensions Used by Wikimedia. It’s over 10,000 messages, but the same strategies work.

Good Stuff to Do Along the Way

Never assume that the English message is perfect. Never. Do what you can to improve the English messages.

Developers are people just like you are. They may know their code very well, but they may not be the most brilliant writers. And though some messages are written by professional user experience designers, many are written by the developers themselves. Developers are developers; they are not necessarily very good writers or designers, and the messages that they write in English may not be perfect. Keep in mind that many, many MediaWiki developers are not native English speakers; a lot of them are from Russia, Netherlands, India, Spain, Germany, Norway, China, France and many other countries, and English is foreign to them, and they may make mistakes.

So report problems with the English messages to the translatewiki Support page. (Use the opportunity to help other translators who are asking questions there, if you can.)

Another good thing is to do your best to try running the software that you are translating. If there are thousands of messages that are not translated to your language, then chances are that it’s already deployed in Wikipedia and you can try it. Actually trying to use it will help you translate it better.

Whenever relevant, fix the documentation displayed near the translation area. Strange as it may sound, it is possible that you understand the message better than the developer who wrote it!

Before translating a component, review the messages that were already translated. To do this, click the “All” tab at the top of the translation area. It’s useful for learning the current terminology, and you can also improve them and make them more consistent.

After you gain some experience, create a localization guide in your language. There are very few of them at the moment, and there should be more. Here’s the localization guide for French, for example. Create your own with the title “Localisation guidelines/xyz” where “xyz” is your language code.

As in Wikipedia, Be Bold.

OK, So I Got to 100%, What Now?

Well done and congratulations.

Now check the statistics for your language every day. I can’t emphasize how important it is to do this every day.

The way I do this is having a list of links on my translatewiki.net user page. I click them every day, and if there’s anything new to translate, I immediately translate it. Usually there is just a small number of new messages to translate; I didn’t measure precisely, but usually it’s less than 20. Quite often you won’t have to translate from scratch, but to update the translation of a message that changed in English, which is usually even faster.

But what if you suddenly see 200 new messages to translate? It happens occasionally. Maybe several times a year, when a major new feature is added or an existing feature is changed.

Basically, handle it the same way you got to 100% before: step by step, part by part, day by day, week by week, notch by notch, and get back to 100%.

But you can also try to anticipate it. Follow the discussions about new features, check out new extensions that appear before they are added to the Extensions Used by Wikimedia group, consider translating them when you have a few spare minutes. At the worst case, they will never be used by Wikimedia, but they may be used by somebody else who speaks your language, and your translations will definitely feed the translation memory database that helps you and other people translate more efficiently and easily.

Consider also translating other useful projects: OpenStreetMap, Etherpad, Blockly, Encyclopedia of Life, etc. Up to you. The same techniques apply everywhere.

What Do I Get for Doing All This Work?

The knowledge that thanks to you people who read in your language can use Wikipedia without having to learn English. Awesome, isn’t it? Some people call it “Good karma”.

Oh, and enormous experience with software localization, which is a rather useful job skill these days.

Is There Any Other Way in Which I Can Help?

Yes!

If you find this post useful, please translate it to other languages and publish it in your blog. No copyright restrictions, public domain (but it would be nice if you credit me and send me a link to your translation). Make any adaptations you need for your language. It took me years of experience to learn all of this, and it took me about four hours to write it. Translating it will take you much less than four hours, and it will help people be more efficient translators.

07 April, 2017 07:34 PM

When I first discovered Linux and the world of Free Software, I was already programming in the Microsoft ecosystem for several years, both as a hobby, and for a living. I thought switching to writing Linux programs was just a matter of learning a new API. I was wrong! Very wrong! I couldn’t find my […]

03 April, 2017 09:04 PM

את התרגום של Django 1.10 פספסתי עקב עומס. התחלתי לתרגם לקראת השחרור הצפוי של Django 1.11, ביום שלישי הרביעי באפריל. הפעם התרגום עמד על 93%.

נכון ליום שבת, הראשון באפריל בנובמבר התרגום עומד על 100% עבור:

• django-core
• django-formtools
• django-people
• django-contrib-comments

נשארו בחוץ, שוב, עקב חוסר זמן והיקף המשימה:

• django-localflavor
• django-docs

01 April, 2017 03:27 PM

Chicago in the 1930s was a hive of organized crime where the bad guys always had the upper hand. As dramatized by the film "The Untouchables," lawman Eliot Ness confides to Officer Jim Malone that he is prepared to do “everything within the law” to take down Al Capone. But streetwise Malone tells Ness that, to win, he must be prepared to do more. “He pulls a knife, you pull a gun. He sends one of yours to the hospital, you send one of his to the morgue. That’s the Chicago way.”

Like ‘30s Chicago, the dark web is crawling with global crime syndicates, and everyone I've talked to says fighting the Chicago way sounds appealing. The problem is that the same laws that make hacking a crime also make it a crime to retaliate.

Read full article at Forbes here

Full text

16 February, 2017 12:12 AM

I’m using rsync to sync files from my computer to a FAT formatted SD card. Using the --update flag to rsync makes it “skip files that are newer on the receiver”. It seems that it should work as follows: After the first sync, any subsequent syncs will only transfer those files which changed in the meantime. However, I noticed that transfer times are usually longer than expected, which led me to think that things are not working as they should.

As --update relies only on modification date, obviously something is wrong with it. After ruling out several other possibilities, I’ve guessed that the modification date of some files get mangled. A quick check about FAT revealed that FAT can only save modification times in 2 second granularity. I’ve also used rsync’s --archive flag, which among other things attempts to preserve modifications times of the files it copies. But what about FAT’s lower granularity for modification time? That was apparently the culprit. Some files when copied got a modification time which was up to 1 second before the original modification time! Hence, every time I’ve synced, from rsync’s perspective, the target was older than the source, and hence needs to be overwritten.

This can be demonstrated by the following session:

$ dd if=/dev/urandom of=test-even bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 6.20716 s, 16.9 MB/s
$ cp test-even test-odd

$ touch -t 201701180000.00 test-even 
$ touch -t 201701180000.01 test-odd

$ stat -c %Y test-*
1484690400
1484690401

We’ve created two files test-even and test-odd with random content. We’ve set the modification time of test-even to be on an even second, and for test-odd to be on an odd second (one second apart). Simply syncing the files to a FAT partitioned device works as expected:

$ rsync -av --update test-{even,odd} /media/guyru/4E09-6457
sending incremental file list
test-even
test-odd

sent 209,766,550 bytes  received 54 bytes  7,627,876.51 bytes/sec
total size is 209,715,200  speedup is 1.00

Resyncing immediately also works:

$ rsync -avv --update test-{even,odd} /media/guyru/4E09-6457
sending incremental file list
delta-transmission disabled for local transfer or --whole-file
test-even is uptodate
test-odd is uptodate
total: matches=0  hash_hits=0  false_alarms=0 data=0

sent 78 bytes  received 136 bytes  428.00 bytes/sec
total size is 209,715,200  speedup is 979,977.57

Both files are reported as being up-to-date. But what happens if we unmount and remount the device and then sync?

$ umount /media/guyru/4E09-6457 
$ udisksctl mount --block-device /dev/disk/by-uuid/4E09-6457 
Mounted /dev/sdd1 at /media/guyru/4E09-6457.

$ time rsync -avv --update test-{even,odd} /media/guyru/4E09-6457
sending incremental file list
delta-transmission disabled for local transfer or --whole-file
test-even is uptodate
test-odd
total: matches=0  hash_hits=0  false_alarms=0 data=104857600

sent 104,883,314 bytes  received 131 bytes  7,769,144.07 bytes/sec
total size is 209,715,200  speedup is 2.00

This time test-odd was reported as needing to be updated. So what changed? My guess is that while the device was mounted, modifcation dates were cached using normal granularity. Once I’ve remounted the file-system, the cache was purged, the the low-granularity modification date was used. That meant test-odd now had a modificaiton time which was one second before the original.

So how can it be avoided? Probably the trivial solution is to tell rsync not to copy over the modification date. This means that the copied files would probably anyway get a new modification time which is more than 1 second later than the original, hence even when rounding the modification time as FAT does it will still work. But a much better solution is built right into rsync: --modify-window

When comparing two timestamps, rsync treats the timestamps as
being equal if they differ by no more than the modify-window
value. This is normally 0 (for an exact match), but you may
find it useful to set this to a larger value in some situations.
In particular, when transferring to or from an MS Windows FAT
filesystem (which represents times with a 2-second resolution),
–modify-window=1 is useful (allowing times to differ by up to 1
second).

By using --modify-window=1 we can overcome the problem, as the files will be deemed as modified at the same time. Indeed it solves the problem:

$ rsync -avv --update --modify-window=1 test-{even,odd} /media/guyru/4E09-6457
sending incremental file list
delta-transmission disabled for local transfer or --whole-file
test-even is uptodate
test-odd is uptodate
total: matches=0  hash_hits=0  false_alarms=0 data=0

sent 82 bytes  received 140 bytes  444.00 bytes/sec
total size is 209,715,200  speedup is 944,663.06

23 January, 2017 06:45 PM

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

הטקסט המלא

13 January, 2017 12:10 PM

A little less than six months ago, we held the first PyCon in Israel. To our dismay, it took us this long to post all the videos from the event, but now they’re finally up, and you can finally catch up on The Track Not Taken.

We’d like to take this opportunity to clear the 2016 table and summarize the conference, to give it some closure.

The conference was a lot of work and fun to organize, and truly wonderful to witness. We’ve had:

• About 350 visitors over the two days
• 3 inspiring keynotes
• 32 talks on different subjects
• 15 foreign speakers
• 12 sponsors
• 2 cinema theaters for the two tracks

Over and beyond the hard data, there was a great feeling of a community coming together.

There’s a few points we want to discuss in more details:

Diversity

We made a conscious effort to make the conference more welcoming to diverse populations. This included a well-defined Code of Conduct, as well as reaching out to specific communities, which are usually underrepresented in technical conferences. This included, of course, the cooperation with Django Girls Tel Aviv, who were invited to the conference; we did not collect the statistics of visitor gender, but we have reason to believe it was significantly more balanced than usual. We also reached out to some other groups who were less clearly visible. By all the feedback we got, everybody felt very welcome.

To our regret, we could not show the same level of diversity among the speakers. Only 3 of the 32 accepted talks were presented by women, and none of these were Israeli. Further, we did not have a travel-support plan for speakers, and partly as a result of that, we did not have any speaker from the less-privileged parts of the world. We still have some way to go there.

We intend to keep pursuing diversity in future editions of PyCon Israel.

Budget

In the spirit of Open Source and transparency, we’re happy to share a summary of our budget (all numbers are thousands of Shekels).

Income

Sponsorship: 246

Ticket sales: 54

Total: 300

Expenses

Venue (incl. food): 134

Conf. party (food+movie): 41

Keynote speakers travel: 30

Speaker’s dinner: 13

Video recording & editing: 20

T-shirts & other swag: 28

Wireless internet: 5

Various other: 3

Total: 274

As you can see, we ended with a positive balance of close to 26K ILS. This is more than we intended, a miss we attribute to over-cautiousness and inexperience. A small part of this surplus will go to support Hamakor, the Israeli F/OSS association which helped make the conference happen, and the rest will go into the budget of the next PyCon Israel.

Community organizations

We’d like to call out three special groups which could use your help — participation as well as sponsorship; groups whose ongoing work enabled this conference and will hopefully enable others like it in the future:

• The Python Software Foundation. They are the good people who take care of the ongoing development of the Python language and the global activities around it. The PSF sponsored PyCon Israel 2016, as it does many such events,
• PyWeb-IL — the mostly informal group of people, with a mailing list and a meetup group, whose continuous activity and monthly mini-conferences are the beating heart of the Israeli Python community,
• And last but not least — Hamakor, the Israeli Free and Open-Source Software NPO, whose main mission is to handle the legal and financial side of activities and conferences like ours.

2017

Since so long has passed, we can also add a look to the future: Preparations for PyCon Israel 2017 have already started! You can join the organizing team, or just keep track of our progress via our different channels -

Blog: https://medium.com/@pyconil

Twitter: @pyconil, #pyconil

YouTube channel: https://www.youtube.com/channel/UC8ApA9ibgkf0XK7lgTVZgEQ

Facebook: https://www.facebook.com/pyconisrael/

Google group: https://groups.google.com/forum/#!forum/pycon-israel (requires registration)

Website: http://il.pycon.org/

Final words

Watching the months of preparations come to full fruition made our hearts burst with joy. We’d like to thank everyone involved — all CFP submission authors, the invited and accepted speakers, the sponsors (and in particular the Diamond sponsors, Red Hat & Cymmetria), the vendors (and in particular the helpful staff of our wonderful venue at Yes Planet), the Israeli Python community in general for making such an event possible, and you, the attendees, for making it a reality.

See you in 2017,

The PyCon Israel organizing team

18 October, 2016 07:45 PM

צהריים טובים.

לאחר מחזור פיתוח בן שישה חודשים, שוחררה גרסה 3.22 של שולחן העבודה GNOME !

גרסה זו מכילה 22980 שינויים שנרשמו ב־Git על ידי 775 תורמים, בהשוואה ל־28933 שינויים על ידי 837 תורמים ב־3.20.

אחוז התרגום עומד על 80% (36912 מחרוזות מתורגמות, 3682 מעורפלות ו־49874 שאינן מתורגמות), בהשוואה ל־80% (36069 מחרוזות מתורגמות, 3702 מעורפלות ו־4937 שאינן מתורגמות) ב־3.20 ו־82% (37120 מחרוזות מתורגמות, 3326 מעורפלות ו־4675 שאינן מתורגמות) ב־3.18.

על התרגום בעיקר אני אחראי, ולאחרונה הצטרף ניב באר ותרגם את חלק מהתיעוד למשתמש „צעדים חדשים ב־GNOME” (נקרא ‏gnome-getting-started-docs) ואפילו החל לתרגם ליישומים (טרם מצאתי זמן להכניס את התרגומים האחרונים שלו).

להלן מוטמע סרטון המציג את GNOME 3.22. קריינות על ידי קארן סנדלר, לשעבר מנכ״ל קרן GNOME, ומייק טרנטינו. עריכה על ידי Bastian Ilsø, שעורך סרטונים אלו כבר למספר שחרורים.

כרגיל, אוסיף כאן שיר. שיר יפה, שפשוט נהניתי לנגן על הפסנתר.

בברכה,

יוסף אור

23 September, 2016 02:47 PM

ערב טוב.

בשבוע האחרון תרגמתי ובכך צמצמתי פערים של חצי שנה ללא תרגום, והבאתי את GNOME לתרגום מלא (להוציא את gitg ואת gnome-builder, שלא תורגמו גם בגרסה הקודמת).

אחוז התרגום עומד על 80% (36915 מחרוזות מתורגמות, 3727 מעורפלות ו־4987 שאינן מתורגמות), בהשוואה ל־80% (36069 מחרוזות מתורגמות, 3702 מעורפלות ו־4937 שאינן מתורגמות) ב־3.20 ו־82% (37120 מחרוזות מתורגמות, 3326 מעורפלות ו־4675 שאינן מתורגמות) ב־3.18.

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

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

את השיר, הפעם, אקדיש ליום המיוחד, לגעגוע לירושלים.

ערב טוב,

יוסף אור

14 August, 2016 04:05 PM

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

הטקסט המלא

12 August, 2016 04:42 PM

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

הטקסט המלא

31 July, 2016 08:25 PM

Fuzzing is a technique in software testing where you generate a number of random inputs, and see how a program handles it. So what does a testing technique have to do with a process such as the Cyber Kill Chain as developed by Lockheed Martin? Easy! Just as fuzzing a software produces resilient software, fuzzing a process will produce a validated process. The Kill Chain takes about seven steps that adversaries must complete in order to achieve their goals, but will it always be the case? Can an attacker pull off a successful attack with just one step? Or three? That’s what we’re going to fuzz out ...

Full text

13 July, 2016 08:14 PM

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

הטקסט המלא

24 June, 2016 09:35 AM

If you are using Travis CI, you can check the latest build after a failed build by going to the “Build History” tab in your project’s main page (= https://travis-ci.org/shlomif/fc-solve or equivalent), and selecting the new commit.

Licence

Copyright by Shlomi Fish, 2016.

You can reuse this entry under the Creative Commons Attribution 3.0 Unported licence, or at your option any later version of it. See the instructions on how to comply with it.

27 May, 2016 12:43 PM

I used Facebook quite a lot. I posted lots of things, I got to know a lot of people, I learned about things that I wouldn’t learn anywhere else, I shared experiences.

But the feeling that I am the product and Facebook is the user got stronger and stronger as time passed. It happens with many other companies and products, but with Facebook it’s especially strong.

In February 2015 I stopped posting, sharing and liking, and I deleted Facebook apps from all my other devices. I continued occasionally reading and exchanging private messages in a private browser window.

Then I noticed that a few times things were shared in my name, and people liked them and commented on them. I am sure that I didn’t share them, and I am also quite sure that it wasn’t a virus (are there viruses that do such things on GNU/Linux?). Also, a few people told me that they received messages from me, and I’m sure that I didn’t send them; It’s possible that they saw something else under my name and thought that it’s a message even though it was something else, but in any case, nobody is supposed to think such a thing. That’s not how people are supposed to interact.

I am not a bug, not an A/B test, not a robot, not an integer in a database. I am Amir Aharoni and from today Facebook doesn’t use me. There are other and better ways to communicate with people.

Stop saying that “everybody is on Facebook”. I am not. I don’t feel exceptionally proud or special. I am not the only one who does this; a few of my friends did the same and didn’t write any blog posts or make any fuss about it.

You should delete your Facebook account, too.

21 May, 2016 09:30 PM

פוסט זה הוא תגובה לטור של ג׳קי לוי בישראל היום. מר לוי היקר, אני יהודי חרד. לא חרדי. אינני נוהג ללבוש שחורים, אפילו לא כאסטרטגיית דיאטה. את השקפתי הדתית ניתן לסכם במילה „אתאיסט”, אף כי אני מקיים באדיקות את הוראות מורינו הדגול רוג׳ר רביט (הוראות שמהכרותי עם הצדדים היותר פומביים של אישיותך, גם אתה לא […]

The post על פטרת צפרניים ופרטיות appeared first on לינוקס ותוכנה חופשית.

21 May, 2016 05:59 AM

Cloudify is an open-source Python Shop developing an orchestration framework for any cloud infrastructure provider allowing to use the tools of your choice to manage your applications. Cloudify’s mission statement is to allow organizations to realize the benefits of cloud computing by simplifying the management of cloud applications at scale.

Our complex challenges vary from scaling and healing to abstracting common tools like Docker, Puppet, Chef, Telegraf and the likes via Cloudify plugins. We adhere to PEP8 and do not compromise on code quality! OpenStack contributors are welcome.

We’re looking for brilliant developers to join us on a journey to take the concept of orchestration to the next level. http://github.com/cloudify-cosmo is our home. You’re invited.

29 April, 2016 08:55 AM

בכמה חודשים האחרונים, מאז השידרוג אל StarCraft 2 v3.0 הוא לא עבד אצלי בפדורה.

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

לגבי המשחקיות – בחלונות 10 זה עובד יותר מהיר. גם אחרי שביטלתי Composite במנהל חלונות (kwin  במיקרה שלי) היה המון tearing על המסך. ולא נדבר על השיהוקים שבהם אפילו הקול קפא למשך 70 מילי שניות. אבל זה השתפר לקראת המשחק השלישי הכל עבד יותר טוב.

אבל זה עובד על תוכנה חופשית. אני שוב בלינוקס… איזה כיף

הטקסט המלא

24 April, 2016 05:32 PM

In our company developers deal with massive datasets that needs to be easy to copy, modify a fraction of it and scrape. Snapshotting is an ideal solution here. Each developer has a personal vserver (LXC container). The missing piece here is to provide them with a way to manipulate partitions and snapshots from inside of their vservers.

To enable users manipulate partitions from inside of the virtual server, I wrote LLS (LXC+LVM+Snapshots) scripts.

LXC+LVM+Snapshots = LLS

Architecture

Further work

14 April, 2016 12:15 PM

Freecell Solver version 4.2.0, has been released. It is available in the form of a source archive, from the download page. Freecell Solver is an open source library and some command line applications, for automatically solving several variants of card Solitaire / Patience games, including Freecell.

This release sports the new configuration theme “-l conspiracy-theory” (or “-l ct”) which is somewhat faster than the best contender up to it, “-l amateur-star”, some relatively minor bug fixes, new compile-time options, and many small and somewhat larger code cleanups, refactorings, and optimisations.

“conspiracy-theory” is a reference to the Jewish holiday of Purim, which took place around the time of its release and an old post of mine about it.

Enjoy!

25 March, 2016 04:14 PM

הטקסט המלא

13 March, 2016 02:11 PM

Imagine you are in Tasmania and need to move 35TB (1 million files) to S3 in the Sydney region. The link between Tasmania and continental Australia will undergo maintenance in the next month, which means either one or both:

• You cannot use network links to transfer the data
• Tasmania might be drifting further away from the mainland now that it is untethered

In short, I’m going to be presented with a bunch of HDs and I need to copy the data on them, fly to Sydney and upload the data to S3. If the HD given would be 35TB I could just copy the data and be done with it – no dramas. Likely though, the HDs will be smaller than 35TB, so I need to look at a few options of doing that.

Things to consider are:

• Files should be present on the HDs in their original form – so they can be uploaded to S3 directly without needing a staging space for unzipping etc
• HDs should be accessible independently, in case a HD is faulty I can easily identify what files need copying again
• Copy operation should be reproducible, so previous point could be satisfied if anything goes wrong in the copying process
• Copying should be done in parallel (it’s 35TB, it’ll take a while)
• It has to be simple to debug if things go wrong

LVM/ZFS over a few HDs

Building a larger volume over a few HDs require me to connect all HDs at the same time to a machine and if any of them fail I will lose all the data. I decide to not do that – too risky. It’ll also be difficult to debug if anything goes wrong.

tar | split

Not a bad option on its own. An archive can be built and split into parts, then the parts could be copied onto the detination HDs. But the lose of a single HD will prevent me from copying the files on the next HD.

tar also supports -L (tape length) and can potentially split the backup on its own without the use of split. Still, it’ll take a very long time to spool it to multiple HDs as it wouldn’t be able to do it in parallel. In addition, I’ll have to improvise something for untarring and uploading to S3 as I will have no staging area to untar those 35TB. I’ll need something along the lines of tar -O -xf ... | s3cmd.

tar also has an interesting of -L (tape length), which will split a volume to a few tapes. Can’t say I am super keen using it. It has to work the first time.

Span Files

I decided to write a utility that’ll do what I need since there’s only one chance of getting it right – it’s called span-files.sh. It operates in three phases:

• index – lists all files to be copied and their sizes
• span – given a maximum size of a HD, iterate on the index and generate a list of files to be copied per HD
• copy – produces rsync --files-from=list.X commands to run per HD. They can all be run in parallel if needed

The utility is available here:
https://github.com/danfruehauf/Scripts/tree/master/span-files

I’ll let you know how it all went after I do the actual copy. I still wonder whether I forgot some things…

09 February, 2016 12:28 PM

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

הטקסט המלא

31 January, 2016 05:35 PM

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

הטקסט המלא

24 January, 2016 04:00 PM

With huge USB flash drives of today it is sad that one can't easily put several bootable ISO images on it and have nice on-boot selection menu.

GRUB to the rescue!

Historically GRUB is being used for hard disks and syslinux for floppies and flash drives. But nothing prevents using GRUB for flash drives as well. Here are instructions for creating bootable GRUB-based USB flash drive (disk on key):

1. Create vfat partition. For big drives you must use fat32 format.
2. Unpack the http://t11.meshanet.com/skliarie_blog/boot.tar.gz onto it. It will create single directory boot on the drive.
3. Customize boot/grub/grub.cfg file, put iso images accordingly
4. On linux box, put bootable MBR onto the DOK (for example on /dev/sdf):
1. mount /dev/sdf /mnt/dok
2. grub-install --force --no-floppy --root-directory=/mnt/dok /dev/sdf
3. umount /mnt/dok 

1. Unpack the initrd
   gzip -dc /mnt/dok/boot/knoppix/minirt_ska.gz | cpio -i
2. Modify the init file (put sector numbers that are correct for your DOK)
3. Compress back the initrd
   find ./ | cpio -H newc -o | gzip -9 -c > /mnt/dok/boot/knoppix/minirt_ska.gz

13 December, 2015 01:33 PM

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

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

ההרצאה כולה נכתבה להצגה בדפדפן.. הנה לינק, והנה עמבד:

https://ira.abramov.org/3DPadventures/ אנא גלשו למצג המקורית אם משום מה זה לא מציג לכם פה.

07 December, 2015 03:42 PM

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

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

ברמה הטכנית, מדובר על אפליקציית עמוד אחד (Single Page Application), שעושה שימוש בין השאר ב-React, Flux ו Node, ועובדת מול Rest API פתוח. אולי זה נראה כמו תהליך אופייני של כתיבה מחדש של מערכת, אבל בעיניי מדובר בהרבה יותר מזה. מבחינת המתכנתים באוטומטיק המעבר לעבודה על המערכת החדשה דרש אימוץ של כלים וטכנולוגיות חדשות במהירות שיא, ולמידה תוך כדי תנועה. אנדי פיטלינג, מרכז הפרוייקט, כותב על התהליך מאחורי הקלעים ומסביר על הבחירות שלנו, ועל השינויים שעברנו כחברה כדי ליישם אותן.

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

כן, אנחנו מגייסים עובדים – בואו לעבוד איתנו.

24 November, 2015 08:51 AM

Verigreen – https://github.com – is a lightweight, server side solution for verification of git commits. Now open-sourced  by HPE’s VeriGreen team.

The post VeriGreen – lightweight, server side solution for verification of git commits appeared first on Liran Tal's Enginx.

16 November, 2015 11:13 AM

This a quick hack I found while I was looking to run a knock script before connecting to servers which I have the SSH service protected with a knock sequence. In my setup I used the ProxyCommand option in the ssh_config file to loop over my loop-back interface.

Host server1
    User root
    Hostname server1.com
    ProxyCommand bash -c 'knock-script %h; sleep 1; ssh 127.0.0.1 -W %h:%p'

# in the above
# %h is a place holder for the hostname i.e server1.com
# and i added 1 sec delay before running the ssh tunnel
# to give the script on the server side time to validate my knock.

08 November, 2015 04:58 PM

As part of my work on the IBM X-Force Application Security Team, a few months ago I wanted to see if I could reproduce a Rowhammer-exploit-type memory corruption via an externally-generated electromagnetic pulse (EMP). The idea here was to target primary memory (usually [S]DRAM) to perform a bit-flip via an electromagnetic pulse-induced glitch.

I have (thus far) failed miserably to build an actual exploit; more on why in a subsequent blog post.

In this post, I'd like to detail my IBM-sponsored single-pulse glitcher (EMP generator) build (yes, it involves Tupperware) and touch on some basics of the theory of operation of its various components.

DISCLAIMER 1: IF YOU DON'T KNOW EXACTLY WHAT YOU'RE DOING, DO NOT TRY REPRODUCE THIS BUILD OR PLAY AROUND WITH HIGH-VOLTAGE CAPACITORS. IT'S POTENTIALLY DANGEROUS (READ: DEADLY)!

DISCLAIMER 2: EVEN IF YOU KNOW EXACTLY WHAT YOU'RE DOING, DO NOT BUILD THIS! LEAVING IT AROUND COULD BE DANGEROUS TO SOMEONE WHO TOUCHES IT (LIKE YOUR KIDS)!

Disclaimer 3: My build's EMP range is in the order of millimeters to centimeters and the interference it causes is relatively weak. It's not a weapon and was built at my employer for security-research purposes only and used only within a private lab. Do not use this build for nefarious reasons!

OK, warnings aside, let's begin.

I'll start by detailing the most basic build which simply consists of a single capacitor, a switch and a coil of wire like so:

If the capacitor was charged, closing the circuit (by flipping the switch) would induce an extremely high current over the coil load (as there is very little resistance in the circuit). This is because capacitors store energy. The amount of energy stored by a capacitor is denoted by Farads, or the symbol F.
As the electrons flow from the negative pole to the positive pole of the capacitor, a magnetic field is formed as per Maxwell's correction to Ampère's Law. In our circuit above, these electrons flow through the coil - a solenoid - concentrating the magnetic field inside the coil. The strength of this field is proportional to the current flowing through the solenoid which, in turn, is proportional to the energy dissipated by the capacitor discharge.

It is this magnetic field that causes electronics to go crazy. This is due to the fact that the field can excite electrons (and hence current flow) within the target device (the exact reverse of what's happening on the EMP side). If one manages to excite the target enough, Bad Things May Happen.

It follows therefore that the more energy stored within the capacitor, the stronger the magnetic field will be.

The decision that we have to make at this point is which capacitor to chose. We need a capacitor capable of quickly discharging its stored energy and one with large enough capacity to induce a sufficiently-strong magnetic field within the solenoid. We don't wish for the field to be too strong as our range of operation for this project (glitching memory) is in the order of millimeters and the target devices operate at around 3.3 volt so the glitch amplitude shouldn't need to be that high to induce some undefined behaviour.

The easiest capacitor to go for, imho, is a 330V 80uF flash capacitor. You'll see this advised by a number of glitcher-building guides on the net. The reason is that it's easily available and comes with a charging circuit to match! Just find a disposable camera with a flash and gut it (actually getting more difficult to find these days; I think I found the last 3 in the country).

A word of caution when opening these cameras. Make sure the capacitor is discharged before touching any part of the circuitry inside. You can do this by firstly winding up the camera and charging the flash. Then activate the shutter to discharge the capacitor. Additionally it's a good idea to make sure it has fully discharged by shorting both ends of the capacitor with a rubber-handled screwdriver (it might make a spark - the energy dissipates as light and heat - but it's likely safe to do with a capacitance of this value).

In our first circuit above, we assumed that the capacitor was already charged. In our working circuit we will need to charge the capacitor.

In order to charge capacitors, one must apply a potential difference (voltage) over it's poles which is greater than its rated voltage for a set amount of time. The time that a capacitor takes to charge is specified by the RC time constant, tau T, of the circuit such that the capacitor will be charged to 63% after 1T. At 4T the capacitor will be charged to 98%. The charging time between 0T and 4T is called the transient period. After 4T the capacitor enters the steady-state period. At 5T the capacitor is considered to be fully charged.

In our circuit, we have selected a value of R = 10k. Our capacitance is C = 80uF.

T = RC
  = 10k x 80u
  = 800 milliseconds

5T = 4 seconds

So in order to charge our capacitor to capacity, we need to apply 330V over its poles for 4 seconds.

The challenge now is to provide a 330V source with which to charge the capacitor. One can use a DC-DC step-up transformer, however luckily the disposable camera which we pillaged above has a nice little charging circuit which we can re-purpose for our needs.

The circuit in most disposable cameras has a feedback mechanism whereby closing the switch causes the charging process to commence and it automatically stops charging when the target voltage is reached (this is so that one doesn't need to hold down the flash button on the camera for the whole duration of the transient period). We'll consider it a black-box for our purposes and using this charger, we can update our circuit diagram as follows:

The push button switch in the diagram above commences the charging procedure. After the capacitor has reached capacity, closing the switch between the capacitor and the solenoid will create the EMP.

Even though we now have a full EMP circuit, I added a number of features to my design.

Firstly, I doubled the capacitance of the circuit in order to create a stronger pulse. I pillaged another 80uF capacitor from a disposable camera and added it in parallel to the first capacitor. This gives a total capacitance of 160uF.

I then added a high impedance voltage-divider circuit which allows me to digitally measure the voltage of the circuit. This is connected in parallel over the capacitor. The reason for the high impedance is that I don't want the capacitor to discharge ('bleed') its energy though this path otherwise there won't be any energy to discharge through the coil!

The total impedance of the voltage divider is just over 2.2M. To understand the affect that this has on the circuit, we need to take a look at how the capacitor discharges.

As with the charging circuit above, the capacitor will discharge 63% of its energy in 1T and be fully discharged at 5T. The impedance of the voltage divider is approximated 2.2M, therefore:

T = RC
  = 2.2M * 160uF
  = 58.6 minutes

As one can see, the bleeding through the voltage divider is quite slow and doesn't have a major affect on the energy of the EMP if the EMP is triggered shortly after the capacitor is charged.

Interestingly this also provides a built-in safety feature. Forgetting to discharge the circuit could prove hazardous as capacitors will hold their charge for a long time. The voltage divider will cause the circuit to bleed the capacitors over time as even though the impedance is high, there is some current flowing through this path. The capacitors I'm using will generally be considered safe at around 42V. They will be discharged to this value at roughly 2.2T, so after about 2 hours and 10 minutes.

The aforementioned voltage divider is connected to a microcontroller (MCU). The one I'm using is the MicroPython board which is a pretty awesome bit of kit (highly recommended). I use this board connected over USB to a PC to control the glitcher (mostly). The voltmeter gives me an indication of the current level of charge of the capacitor. The MCU is also connected to two relays. The first relay is used to complete the charger circuit (in place of the disposable camera push button). The second relay connects a 3.3k resistor over the poles of the capacitor. I can use this to very quickly discharge (bleed) the circuit and even use it to select a particular voltage for the pulse (I can bleed the circuit for a very short time causing a controlled drop in capacitor charge; to half the voltage for example). This is a 35W rated part as it needs to be able to handle the amount of energy dissipated through it (high current). The interface is shown in the video of the capacitor charging below:

The final part of the build is the solenoid itself. I have experimented with a number of different coils; diameter, number of windings etc. The ideal coil depends on the application and isn't an exact science at all. For my needs I wanted a small, focused EMP with which I could target a RAM IC without glitching the surrounding electronics. My first attempt at a large coil tended to reset my computer! I then made a few smaller coils out of insulated copper wire wound around ferrite iron cores. Here are some pictures of my various coils:

So does the glitcher work? Well yes! I verified this experimentally. As mentioned, the large coil can reset my computer. I used the smaller coils to target RAM IC chips in a PC. I was able to cause some havoc with RAM contents but I'll leave that for another blog post.

As for how the glitch actually looks on the target; according to Wikipedia, what we should see is a damped sinewave pulse. This is due to coupling on the ground plane between the glitcher and the target. I won't go into this in detail but it's all on Wikipedia if you're interested. Throwing an EM pulse out at a scope probe shows exactly this affect so all seems to be working well:

That's all for now folks! Leaving you with a picture of the glitcher in all it's tupperwear-enclosed glory!

05 November, 2015 06:12 PM

So it has been a while since my last CUPC/8 (formerly known as CUPCake) update.

Over the past few months I have spent a significant amount of time working fleshing out the instruction set, implementing support in the assembler and simulator and coding the Kernel (the status of which will be discussed in another blog post).

I have also spent some time back with the hardware itself; integrating and testing the physical RAM and MMU FPGA modules, bus interfaces etc.

Additionally, I finally got around to starting the documentation (see here). Some of it is already slightly out of date but hopefully I'll revise it soon.

As development has progressed, I have continually challenged my original design decisions and this has resulted in a few design revisions.

The main change is that the memory board is no longer responsible for loading the ROM into primary memory on boot. It just didn't make sense for me to use a powerful (relative to CUPC/8) XMEGA MCU within the context of the project as a whole.
As such, I have removed the XMEGA from the design. The ROM chip is now connected directly the the SoC over I2C. The SoC also now includes a small ROM buffer on-chip (termed ROM0) which will hold code that will be responsible for bootstrapping the ROM code. ROM0 is memory-mapped into the 64k memory region by the MMU. The hard reset vector points to the start of the ROM0 and will therefore execute it on boot.
The ROM0 code will be minimal; consiting of a stripped-down I2C driver responsible for the loading of the off-chip ROM chip (ROM1) into primary memory and jumping to the ROM1 start vector.
This is somewhat similar to how modern CPUs bootstrap today.

My next milestone is to get the hardware SPI and I2C modules working properly and interfacing ROM1 with the FPGA development board.

02 November, 2015 01:44 PM