הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא אינטרנט.
1984 הדיגיטלי
בעקבות פרשת טראמפ, החלטתי להבין מה קרה שם בגבעת הקפיטול. לא מהפרשנים אלא מהמקור. מה הייתה ההסתה לכאורה שגרמה להמון משולהב להתפרץ. פתחתי גוגל: trump capitol speech, הגעתי למלא פרשנויות אבל לא למקור. שיניתי גרסאות החיפוש אותה תוצאה... מוזר. פתחתי bing בקישור השני מצאתי וידאו מלא. זה צרם לי אבל המשכתי הלאה. ראיתי ש־twitter החזירו את החשבון לעת עתה.
היום מדברים בחדשות שהחשבונו נחסם לצמיתות. מעניין. Googe: twitter trump. מגיע לעשרות כתבות של חדשות על חסימת חשבון - אבל לא הקישור לחשבון עצמו. הפעם אני פותח bing במידי ובקישור הראשון אפשר למצוא את חשבונו החסום - ממקור ראשון. הפעם האסימון נפל.
זוכרים את תפקידו של וינסטון ב־1984? הוא היה אחראי על שיפוץ עיתונים ישנים ומחיקת היסטוריה לא רצויה. אם לא קראתם את הספר עד עכשיו - הזמינו אותו מיד. אז מסתבר גם גוגל התאימו את המציאות. הרי זה ידוע - אם אתה לא בגוגל אתה לא קיים! אחד כלי המחקר האינטרנטי - שנותן לנו בעצם גישה לאינסוף מידע ודיעות, עוזר למצוא מקורות הוא מונע את המידע.
עד היום לא הסתמכתי על כלי תקשורת אחד כדי לגבש עמדה על משהו חשוב - כי ידוע לכל כלי תקשורת יש אג'נדה משלו. לכן תמיד הסתכלי במספר דיווחים משני צידי המתרס. ידיעות וישראל היום. ערוץ 13, 12 ו־20 ואם הנושא חשוב באמת הייתי מחפש את המקורות - למשל קראתי את פסק דינו של אלאור אזריה. צפיתי בשידורי הבג"ץ בנושא חוק הלאום. כי לא סמכתי על פרשנויות.
אבל עד עכשיו הנחתי שחיפושים בגוגל יביאו אותי לתוכן הרצוי. מסתבר גם פה - אין להסתמך על ספק יחיד. תארו לעצמכם אם בחיפוש בגוגל אחרי פרשת תיק 4000 או המימד החמישי - כל התוצאות הראשוניות היו מביאות אותי ל"אין כלום כי לא היה כלום" או להפך "הינה הוכחה לשחיתות"... כוח עצום. כוח משחית!
ובעיקר מטריד...
טוב, מזל שכבר פיתחתי הרגלי הצלבת מקורות. עכשיו אצטרך גם להצליב מנועי חיפוש. האמת לא ציפיתי. ציפיתי שאין לצפות לפרטיות מגוגל או פייסבוק. אבל לא ציפיתי להטיה מכוונת שלא קשורה לנושאים מסחריים כמו קידום מוצרים.
טוב אז מאין תבוא הישועה? bing? duck-duck-go? yandex? יש עוד אלטרנטיבות?
מישהו מכיר מנוע חיפוש מבוסס FOSS?
התמונה נלקחה מויקיפדיה
רשת חברתית חופשית או פעם זה היה אחרת
לאחרונה חסמו לדונלד טרמפ את חשבון הטוויטר שלו. לא אתייחס כאן לסוגיית חופש הביטוי ואם התנהגותו של טרמפ הולמת פחות או יותר מהציוצים של חומייני, פוטין או רבים וטובים אחרים. הרי מדובר בפלטפורמה פרטית של חברה פרטית שזכותה להחליט על תנאי השימוש שלה ולקבוע את האג'נדה שלה. כך גם פייסבוק ועוד כלים נפוצים אחרים.
בסופו של דבר אנחנו נקבע במה נרצה להתשמש ונצביע ברגליים בעד או נגד התנהגותה של חברה כזו או אחרת.
אבל מה... אנחנו בעצם נעולים. אם אין לך twitter או facebook או פלטפורמה נפוצה אחרת אתה לא תגיע לקהל היעד שלך. בעצם מספר רשתות חבריות שולטות בשוק ובעלות כוח רב בהשפעה על דעת הקהל וחשיפה של אנשים כאלה ואחרים. זה לא חדש. עוד מתחילת עידן הפייסבוק ראיתי כיצד הוכחדו מספר טכנולויות של רשתות חברתיות של פעם. כי באמת פייסבוק נתן פלטפורמה זמינה ונוחה ובעלת רף כניסה מאוד־מאוד נמוך למשתמש קצה. אבל מה האלטרנטיבות שהיו ונכחדו?
בלוגים
פעם אנשים שרצו להגיד משהו כתבו בלוגים. בלוגרים אחרים הגיבו לכתבות אחרות. ציטטו וקיבלו ציטוטים של אנשים אחרים. היה מנגנון מבוזר שאפשר לקשר בין הבלוגים. היה נהוג שבלוגר שמגיב לבלוג של מישהו אחר משאיר את הקישור לבלוג שלו. חלקם ניהלו מקבצי rss-feed של בלוגים שעקבו אחריהם.
מוכר? נכון - זה ממש כמו פייסבוק! רק במספר הבדלים
הקמת בלוג הייתה עניין לא טריוויאלי שדרש רצינות חשיבה וכתיבה יחסית מסודרת
בד"כ אנשים לא פרסמו "מאמרים" בסגנון
בוקר - 16 גרביים - אף זוג 😕
ייצור חבילות גרביים בה כל זוג שונה מאחרים צריכה להיות מוגדרת בחוק כהתעללות בבני אדם
אלא השקיעו בתוכן איכותי. ומה הקמת בלוג לא הייתה עניין מסובך אבל גם לא משהו פשוט.
היה קשה ליצור קשרים חברתיים
היה הרבה יותר קשה להגיע לכל החברים שלך שהיו מתעניינים בדעות שלך (גם אם אלו דעות על גרביים). בפייסבוק אוטומטית, חלק ניכר ממכריך עם גם העוקבים שלך. בבלוגים היה צריך לגרום לאנשים אחרים להוסיף אותך ל־rss-feeder שלהם - וכמובן שרוב רובם לא ניהלו כאלה.
ברוב הפלטפורמות הפתוחות התוכן היה שלך
אם פתחת בלוג ב־wordpress יכולת להוריד את התוכן/גיבוי בכל רגע ולהעביר אותו לשרת wordpress פרטי - זה אומנם לא שיטה פשוטה למשתמש ביתי, אבל כל דמות חשובה ומשפיעה הייתה יכול לעשות זאת. ולכן הדרך היחידה להוריד את הבלוג מרשת היה בעזרת צו בית המשפט - לטוב ולרע.
פורומים
לפני קצת יותר מעשור פורומים היו בשיאם. אפשר היה ליצור קבוצות דיון. אנשים הסתכלו וכתבו. פורומים היו מנוהלים בצורה זו או אחרת.
ההקמה של פורומים הייתה קשה ומסובכת (עשיתי זאת פעם). אבל אפשר היה גם להקים פורום בפלטפורומות פתוחות אבל זה היה פחות נפוץ.
גם זה פייסבוק הרג - והאמת לא הביא תחליף ראוי. כדוגמה שכאבה לי אישית - היו מספר פורומים בתחום סלסה בארץ עם תוכן איכותי מעניין ודיונים מרתקים. כולם כמובן נמחקו הוזנחו לאחר הופעת פייסבוק.
אז מה אפשר לעשות מלבד לדבר על זכרונות הימים שעברו?
- להחזור ולכתוב בפלטפורמות פתוחות כמו בלוגים ולהפנות אליהם מפייסבוק טוויטר ורשתות אחרות על מנת שהתוכן יישאר פתוח ויהי מה.
- להקים פרוטוקולים וסטנדטים להחלפת מידע ביו הבלוגים וייבוא/ייצוא מידע. כבר יש תשתיות לזה ופרוטוקולים קיימים - צריך לחדש ולהתאים אותם לדור הנוכחי
לתת לשוק להקים פלטפורומות מתחרות שעובדות על בסיס המידע החופשי והזמין שיהיה
- קל להתחיל - לכל אחד
- לק לעבור מפלטפורמה אחת לשניה - על ידי דרישה לעמידה בתקנים חופשיים ומבוזרים
מי מרים ו/או הרים כבר את הדגל?
שוחררה גרסה יציבה 1.0.0 של CppCMS המופצת תחת רישיון כפול
היום, אחרי מספר שנות פיתוח, שוחררה גרסה יציבה של CppCMS 1.0.0, אחרי תקופה ארוכה של גרסאות בטא. הגרסה הזו מהווה אבן דרך משמעותית בהתפתחות של CppCMS, הן מבחינה טכנולוגיות והן מבחינה עסקית.
החל מגרסה 1.0.0, ספריית CppCMS תהיה זמינה תחת רישיון חופשי LGPLv3 ותחת רישיון מסחרי שיאפשר פיתוח יישומים קנייניים תוך שמירה על שלמות המוצר והגנה על הסודות המסחריים שלו.
למידע נוסף על הרישוי החלופי והמחירים אנא כנסו לאתר שלנו:
http://commercial.cppcms.com
גרסה זו, עברה שכתוב יסודי ושינויים ארכיטקטוניים עמוקים שהזניקו את הפופולריות שלה מיד עם שחרור גרסאות בטא ראשונות. מבין החידושים הטכנולוגיים:
- הכנסה של API ו־ABI יציבים
- תמיכה מובנית ב־Ajax ו־Comet
- שיפורים מהותיים בלוקליזציה
- תמיכה מובנית ב־Windows
- שיפורים משמעותיים באבטחה: מסנני XSS וכלים למניעת CSRF ועוד.
- שרת HTTP מובנה לפיתוח ומערכות משובצות
הענף הישן יציב CppCMS 0.0.x לא נתמך יותר. כל משתמשיי הענף הישן מתבקשים לעבור לגרסה החדשה. יש לציין, לא ידוע לי על משתמש אחד שנשאר עם הגרסה הישנה.
על nginx ועל symbolic links
בעקבות הכתבה של עופר כהן הגעתי לטבלת השוואה מעניינת בין Apache לבין nginx. מה שהפתיע אותי זה שכדי להעביר קובץ http://example.com/site/files/images/layout/header.png השרת nginx מבצע קריאת stat בודדת. הטבלה עשתה השוואה עם apache שעשה O(n) קריאות עבור תיקיה בעומק n לעומת O(1) עבור nginx...
ברגע שראיתי את זה נדלקה לי נורת אזהרה! מה עם symbolic links?
הסבר: נניח אני איצור קישור סימבולי בשם mypicture.png שיפנה ל־/etc/passwd או לקובץ רגיש אחר, אז ע"י גישה לקובץ תמים אני אוכל לקרוא כל קובץ שיש לשרת web הרשאות לקרוא.
לכל השרתי web יש אופציה לא לעקוב אחרי קישורים כאלה מטעמי אבטחה וזאת גם אופציה מומלצת לעבודה. מה חשוב, זה שבלתי אפשרי לעשות בדיקה כזו ב־O(1) קריאות מערכת ההפעלה (לפי עומק התיקיה).
אז החלטתי לבדוק בעזרת strace, כמה קריאות stats בפועל מבצעים apache, lighttpd ו־nginx כשהאופציה כזו מופעלת וגיליתי... ש־nginx בכלל לא תומך באופציה כזו! קרי הגדרת אבטחה בסיסית שכל שרת אינטרנט החל מ־apache ועד ל־thttpd תומכים בו (אגב גם השרת הפנימי של cppcms) בכלל לא מופיעה בו!
התשובה (רוסית) של מפתח nginx היא להשתמש ב־mount -o nosymfollow עבור מערכת הקבצים כדי לעקוף את הבעיה.
חבל...
Nginx? תודה לא... Lighttpd
לאחרונה יש יותר ויותר כתבות על Nginx ועד כמה השרת הזה מעולה. נתח השוק של Nginx לפי הסקירות האחרונות של Netcraft עומד על כ־10%. אז כנראה יש סיבה לכך!
עכשיו, דברים שלא מספרים:
- רוב שרתי ה־Nginx המופיעים ב־Netcraft עובדים כ־Reverse Proxy או מטפלים בעיקר בקבצים הסטטיים. בהרבה מאוד המקרים Nginx הוא מתפקד כ־Load Balancing Frontend לפי שרתי Apache.
- התמיכה של Nginx בתוכן דינאמי היא בין מועטה עד לוקה בחסר:
- אין תמיכה ב־CGI כלל.
- אין תמיכה בניהול של שרתי FastCGI, כך שהשירות התוכן הדינאמי שלך חייב לרוץ התהליך נפרד ואתה צריך לדאוג לו (למשל להעלות אם הוא נפל מסיבר כלשהי)
- הגדרות FastCGI לא תואמות תקן -
PATH_INFOלא מוגדר כברירת מחדל. צריך לעבוד קשה כדי שהוא יעבוד נכון. מה שגורם לא מעט בעיות לאלה שמגלים שהיישום שלהם שבור בצורה לא ברור ולא מבינים למה. - תמיכה ב־SCGI שבורה לחלוטין. הוא לא מטפל ב־Status כמו שצריך, שזה אומר שרוב ההפניות תהינה שבורות אלא אם היישום שלך ישלח את התשובה כ־HTTP נקי.
להמשיך?
כן, אם אתם צריכים Reverse Proxy או לטפל בתוכן סטטי זהו שרת מעולה. אחרת, תחשבו פעמיים.
אני ממליץ בחום על Lighttpd: מהיר כמו Nginx ובנוי על אותם העקרונות, מתועד היטב, מטפל תוכן סטטי ודינאמי בצורה יוצאת מן הכלל. קל לקינפוג ועוד.
לפני שאנשים יקפצו ויגידו:
Lighttpd זולג!
אז התשובה היא, לא הוא, לא זולג.
ציטוט:
there are no memory leaks just stupid ways to use lighttpd.
e.g. it is really stupid to stream large files via a fastcgi app, when x-lighttpd-send-file could do a much more efficient job
תקראו עוד:
