קטגוריה: לינוקס

על שימוש ב VIM ו OCD

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

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

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

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

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

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

אבל הגישה של vi היא שונה כאן. אם כל משפט נגמר בנקודה, אפשר להתחיל בגישה הבאה:
בואו נלחץ על ‏ 2f.‎ (כלומר הספרה שתיים האות f ואז נקודה) ונגלה כי אנחנו מגיעים לנקודה השלישית הנמצאת בשורה שלנו. עכשיו ניתן להקיש 2w ו… הגענו למיקום הנכון. מכאן נלחץ על cw ונשנה את המילה הרצויה.

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

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

תנו לי לנסות את זה שוב. אולי אעשה את זה כך: ‎ 2‎)‎ ואז על w ואקנח ב cw.  טוב זה פחות הקלדות.
ועכשיו נשאלת השאלה – האם אני עדיין יכול לקצר את התהליך. אמנם במקום 7 תווים ירדתי ל5, עדיין זה הרבה בעיני.

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

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

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

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

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

שעתיים עם void-linux

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

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

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

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

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

אז אני ניתקתי את עצמי מכך, והלכתי לכיוון של ארץ' וחשבתי ש void-linux דומה בגישה שלה ל ארץ'. טעיתי.

ובכן, אין יחסית הרבה בחירה בהפצה הזו, היא מאוד דעתנית. אפשר לבחור סוג מימוש של libc שהוא glibc או musl.
אין למשל תמיכה ב systemd ובמקומה יש ruinit.

ההפצה בברירת מחדל מגיעה עם live cd, בטעמים של שולחנות עבודה Enlightenment, Cinnamon, LXDE, LXQT, MATE ואפילו Xfce.
מה חסר? ובכן גנום, kde4 ו plasma.

אני החלטתי ללכת לכיוון של musl ו live cd שהוא רק shell. רציתי להרגיש את ההפצה בברזל שלה.
והיא ממש מדהימה, קלה וזריזה מאוד.

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

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

אוקי, עשיתי בוט להתקנה, ו… עכשיו הגיע הזמן להתקין דברים. אז להפצה יש מנהל חבילות משל עצמה בשם xbps שדווקא עניינה אותי, אבל המסך שלי נתקע פתאום כשהתקנתי neovim, אם כי ההפצה עצמה המשיכה לרוץ בהצלחה. מסתבר שהיה משהו בתוכנה עצמה שנעל עדכון מסך, שעד עכשיו לא הבנתי מה הוא ולמה. ד"א Ctrl+q לא עבד, ניסיתי 🙂

היכולת להשתמש במנהל חבילות בינארי הוא לא חדש, והפורמט הוא בס"כ הסוואה ל tar.xz.
התוכן שם קצת מוזר לי אבל, למשל רשימת החתימה של הקבצים משתמשת ב xml בקובץ בשם files.plist.
גם הקובץ props.plist הוא למעשה קובץ xml.

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

יש לכך שני סיבות עיקריות עבורי:

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

האם זה אומר שהיא גרועה? לא! רחוק מזה!
היא פשוט לא בשבילי, ואני אשאר בנתיים עם ארץ' 🙂

 

חודש עם Tilix

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

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

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

tilix

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

בנוסף לכך שיש לי split שקל לעבור בניהם עם המקלדת, אפשר גם ליצור משהו שנקרא session, ממש כמו virtual desktop. וגם אליהם ניתן לעבור בקלות עם המקלדת.
היא מאפשרת למשל לשתף מקלדת עם כל או חלק מהטרמינלים הפתוחים בסשן, כך שהקלדה במקום אחד תתקבל גם בשאר, חיפוש של תוכן שהודפס למסך (למשל לוג שאתם פתחתם עם tail -f, ואולי פספסתם משהו בו), ואפילו ניהול של clipboard, בנושא שאל העתקה והדבקה, ולא בניהול של היסוטוריה וכיוב' שלו, הוא יודע לספק הודעת מערכת כאשר פעולה הסתיימה, להגדיר מסוף כ readonly (לא מקבל מקלדת, בניגוד ל CTRL+S שפשוט משהה את הפעילות) ובנוסף, יש לו תמיכה בכלים שונים שלא ניסיתי עדיין.

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

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

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

ובכן, קצת 🙂

הייתי מאוד שמח לראות את Tilix משפרת מספר דברים אצלה:

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

במידה והשניים הראשונים יהיו, לדעתי מדובר במתחרה ראוי ל tmux (למעשה הוא כזה כבר עכשיו, אבל עדיין).
כמובן שגם אפשר להריץ tmux בתוך tilix, ואז בכלל זכיתם המון גמישות 🙂

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

 

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

יצירה וטעינה של ספרייה משותפת בגו

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

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

כיצד יוצרים ספרייה משותפת בגו? להמשיך לקרוא

מימוש RDP טבעי בשפת רובי

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

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

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

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

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

כתובת הפרויקט: https://github.com/Safe-T/rdp-rb

ניסויים בתורי הודעות

יש מערכת שאחרי load test הבנתי כי אני חייב לבזר את המערכות שבה. אז התחלתי לבצע מחקר על סוגים שונים של message queue בשביל לבזר את המערכת. עשיתי ניסויים עם המון מערכות שונות, כולל התייעצות עם אנשים שממשים כבר מערכות המשתמשות בהם, והגעתי להבנה כי כנראה ש RabbitMQ מתאים לצרכים שלי.

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

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

למשל אני עשיתי 2 הגדרות בלבד לRabbit להתאים למכונת הפיתוח החלשה שלי, והגעתי ללמעלה מ7 מליון בקשות בשניה אחת, עד שרוחב הפס נחנק, אבל ה load היה על 0.02 לאורך זמן רב. כלומר לא הגעתי ל load שהם דיברו עליו. אבל יכולתי לבדוק לאורך זמן, רק כאשר ירדתי בערך ל5 מליון בקשות בשניה, ואז הרוחב פס כבר לא נחנק לי.

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

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

כך שלי חסר מאוד מידע איך ומה בוצע בפוסט, אבל אני לא מצליח לשחזר את מה שהם כן מזכירים.
העניין הוא, שאני לא בוטח ברדיס לפעולות ה mq שאני צריך, כי אני צריך מחסנית יציבה של worker..
אם חלילה וחס הוא נפל, אסור שהמידע יאבד, ויותר מזה, במידה ואני צריך להוסיף workers, אני צריך מצב של ביזור המידע, בלי שworker אחד ידרוך על השני, ואני מקבל את זה בצורה טבעית ב Rabbit, (ועוד מספר סוגים של MQ שבדקתי), אבל רדיס מעולם לא תוכנן לזה. הוא נמצא בזיכרון, אני כמובן שיכול להכריח אותו לכתוב לדיסק (איטי מאוד, אבל זה מה שקורה עם persistence queue בRabbit), אבל בשביל לעשות תורים בגישה של Round Robin, ובכן, בלי לכתוב משהו ב lua, אני לא מכיר תמיכה לזה ברדיס, למרות שאשמח לגלות שיש.

ככול שאני עובד כרגע (אמנם עדיין בפיתוח) עם MQ, ככה אני אוהב יותר את הרעיון של השימוש ב Rabbit.
במערכת שאני בונה, יש לי מערכת חיצונית שהיא של ספק אחר שמדברת עם HorentQ, דרך הפרוטוקול שנקרא STOMP (בניגוד לRabbit שברירת המחדל שלו היא AMQP אך תומך גם ב STOMP), והיתרונות של מערכת כזו שהיא robust מאוד, מאפשרת להתמודד עם בעיות שונות, כדוגמת קריסת מערכת, ניתוק התקשורת, התנהלות של load balance של מספר שרתים וכיוב'…

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

 

 

סינטרה מודולרית

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

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

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

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

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

אנחנו משתמשים בRack בעצם, היות וכמעט וכל הframeworks עבור בניית מערכות web ברובי משתמשים בו, אנו זקוקים לקובץ קבוע בשם config.ru.

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

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

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

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

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

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

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

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

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

במקרה הזה, הגדרתי כי במצב של ‎:development משתמשים ב Sinatra::Reloader, אשר מגיע עם Sinatra-Contrib – תת פרוייקט המספק הרבה כלי עזר לדברים שונים.
הסיבה לשימוש ב Reloader הוא לא לאתחל את השרת בכל שינוי שעושים למחלקה של סינטרה, כאשר Reloader מגלה כי התוכן של הקובץ השתנה, הוא גורם ל rack לטעון אותו שוב, וככה אנחנו לא זקוקים לטעינה מחודשת של השרת עצמו.

המערכת שכתבתי, משתמשת ב template בשם haml, למעשה פעם ראשונה אשר אני משתמש בה מרצון. תוכלו למצוא את ה layout.haml שהוא המסגרת הרגילה וכן כרגע קובץ בשם index.haml תחת ספריית view.
ועבור העיצוב, אני משתמש ב Foundation 5, אשר אני אוהב אותה יותר מאשר bootstrap.
עבור Javascript יש גם את jQuery וגם את knockout.js, כאשר אני נעזר גם ב lodash.js למספר דברים פשוטים, והיא מספקת בעצם גרסה שעברה אופטימיזציה ל underscore.

את הקבצים של Foundation, וכל ה Javascript ניתן למצוא תחת public.

דבר אחרון שנשאר לספר עליו הוא שאני משתמש במשהו אשר נקרא puma.
מה זה ?
puma הוא משהו שלוקח את rack וגורם לו להיות שרת לכל דבר ועניין, אשר ניתן לבצע עליו חיבור לשרתי HTTP שונים, כדוגמץ apache או nginx.
החיבור נעשה על ידי הגדרת proxy בשרתים.

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

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

האקינג לראוטר, או איך להפוך ראוטר לקוד פתוח

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

מאז לא היו לי אתגרים באמת מעניינים בנושא ההאקינג של מכשירים, עד שרכשתי את WDR4300 של TP-Link והחלטתי שאני לא אוהב את הרעיון שאין לי שליטה על הראוטר שלי.

גיליתי שאני מוגבל, היות ובמדינת ישראל יש הגבלת תדרים על ידי משרד הביטחון (ולא משרד התקשורת) – WTF ?!
אז בגלל זה אני למשל לא הייתי יכול לעדכן את הראוטר לגרסה חדשה יותר של TP-Link, כי אין להם הורדה של גרסה "ישראלית" המגבילה תדרים (מצטער אבל זה הזוי).

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

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

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

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

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

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

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

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

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

בכל מקרה, אני מאוד נהנה 🙂

מזלגות נעוצים

בתקופה האחרונה, נעשו מספר פעולות fork לפרויקטים מוכרים, בהם node.js ודביאן.
בנוסף, פרויקט docker מקבל מתחרה, לאחר שחברת CoreOS הודיעה כי לא מקובל עליה הכיון של docker.

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

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

החשיבה כאילו systemd גוזל משהו, בכך שהוא בא לסדר בלאגן ובעיות שיש במערכת הקיימת כיום, מקבלת תירוצים של "נוצרת תלות במערכת", והתשובה שלי היא: "כי עד עכשיו התלות ב sysv לא היתה קיימת ?"

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

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

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

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

Rocket
במידה ולא שמעתם על docker, אתם כנראה ישנים איפשהו, או שרחוקים מעולם ה IT. זה השם החם ביותר מאז שסייבר ומחשוב ענן נכנס לעולם, או אולי זה היה 42 ?

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

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

החברה של CoreOS, רוצים container ומשהו שזו כל ההתמחות שלו, אבל docker מתחיל להיות stack שלם של דברים, והם ממש לא אוהבים את זה, כי בסופו של דבר,זו סוג של תחרות, לא ?

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

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

systemd

זהירות פוסט ארוך מאוד

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

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

מהפכה נוספת, היא החלפת הגישה של sysv כמעט לגמרי, עם מנהלי init שונים, כאשר זה שלוקח את הכי הרבה אש, וגם בשימוש הרב ביותר הוא systemd. זה השם שלו, כפי שהוא כתוב. והd בסוף מצייג כמובן את המילה daemon, כי הוא יושב ב pid 1, ומנהל את העליה של כל השאר, אחרי שמנהל האתחול (כדוגמת grub) מריץ אותו.

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

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

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