I've recorded the Programming Bootcamp for Scientists video course in September-October and used it as the material for a course. Finally I found a home for it where it will be easy to sell it as a stand-alone course. It is on Leanpub now: at Programming Bootcamp.
For the full article visit Programming Bootcamp - available online
אחד הדברים הטובים שמתרחשים בעולם הטכנולוגיה שאפשר לברך עליו בכל הזדמנות – הוא עניין החידושים שכתוצאה מכך, הלקוח מקבל מוצר יותר איכותי ובמחיר יותר זול מבעבר. אם יש משהו שאפשר לאמר על מסכי הטלויזיה של חברת שיאומי – זה שסוף סוף הלקוח שאינו מבין גדול בטכנולוגיה, צבעים, HDR, סטנדרטים ועוד – מקבל מוצר כלל לא רע בסכום שנע בין 1700 ל-1900 שקלים.
רכשתי את המסך מדגם L55M5-5ASP דרך שופרסל. המסך הגיע לאחר יומיים מרגע ההזמנה. הרכבתי אותו והתחלתי לבדוק את ההגדרות, ולהלן התרשמותי:
מבחינת תצוגה, מסך זה מכיל פאנל מסוג VA. פאנל זה נחשב לפאנל שמציג צבעים בצורה די טובה, עם רמת ניגודיות די גבוהה, גווני שחורים כהים ועוד. החסרון של פאנל זה לעומת זאת קשור בזווית הצפיה – אלו שצופים בצורה ישירה במסך, יזכו לראות תמונה מעולה, ואילו אלו שצופים מהצדדים, יראו יותר גוונים אפורים כהים במקום גוונים שחורים לדוגמא. (אגב, בארץ משום מה כותבים שהמסך הוא "LED". הוא לא, זו התאורה האחורית, לא הפאנל).
מבחינת שימושיות והגדרות – שיאומי, כמו חברות רבות אחרות, משתמשות ב-Android TV מההתחלה ועד הסוף. המסך תומך בכל הכניסות הסטנדרטיות (כבלים, אנטנה, לוויין, 3 כניסות HDMI כולל תמיכה ב-ARC וגם 2 כניסות USB 2.0 – נחמד!), ומערכת האנדרואיד יודעת לסרוק את התחנות ולהציג מעין "קיר" שעליו מופיעות התחנות והתוכניות משובצות על אותו "קיר" יחד עם תוכן אונליין כמו נטפליקס, אמזון פריים, יוטיוב ועוד. ההגדרות במסך הן פשוטות (לפעמים פשוטות מדי, הווה אומר: חסרה פונקציונאליות, על כך – בהמשך) ולמי שיודע להסתדר בקלות עם הטלפון שלו, יוכל להסתדר בקלות עם הטלויזיה הזו.
כמו שכולם יודעים, ישנה תחרות עזה בין היבואנים שמייבאים מסכי טלויזיה שונים ולכן קשה לדעת מה לבחור, וכאן חשוב לזכור משהו אחד: מיהו הצופה? אם הצופה הנכבד לא מבין בעניין של רוויית צבעים, הוא "מתלהב" מאיכות הוידאו שמוצגת בחנות החשמל ו"כזה הוא רוצה" – אז אותו צרכן נכבד יכול לעצור את החיפושים ולרכוש את מסכי הטלויזיה של שיאומי בהתאם לגודל מסך שהוא מעוניין (יש מספר יבואנים בארץ, כולל היבואן הרשמי, לא מצאתי יתרון לאף אחד מהם, וכששוחחתי עם 2 חברות לגבי תקלות/באגים – לא ניתנה שום עזרה רצינית). כשמנסים להשוות את המסכים של שיאומי מול מסכים מתחרים באותו מחיר, מוצאים מסכים בני שנתיים ויותר עם איכות צבעים זהה או נמוכה יותר.
מי שמחפש תמיכה ב-HDR יוכל למצוא זאת גם בטלויזיות של שיאומי, אולם חשוב לזכור ש-HDR הוא תקן די רחב, ומסכים שונים מציגים תמונה באיכות שונה. אל תצפו לקבל ממסך של שיאומי תמונה כמו שתקבלו ממסכי סמסונג, LG או סוני היוקרתיים. יש תמיכה, האיכות היא בינונית פלוס והיא מופעלת אוטומטית בשידורי וידאו אונליין שמשדרים HDR.
מבחינת האנדרואיד שמגיע עם המסכים – מדובר באנדרואיד 9 (כן, כולם מחכים ששיאומי תשדרג לאנדרואיד 10) ויש תמיכה מלאה לחנות, תמיכה מלאה בעברית, ואפשר להתקין אפליקציות וגם פה ושם כמה משחקים נחמדים שניתן להתקנה לשחק עם השלט (לא כדאי "להשתולל" יותר מדי – למכשיר יש 8 ג'יגהבייט אחסון ו-2 ג'יגהבייט זכרון, זה לא טלפון אנדרואיד מודרני), ואם חשקה נפשכם לצפות בתכנים אונליין שאינם משודרים בארץ – אתם במרחק קצר מהתקנת VPN דרך החנות, ותוך דקות ספורות תוכלו לצפות באמזון פריים או נטפליקס ממדינות אחרות (לגבי אמזון פריים – פעם עובד לי, פעם לא…)
עד כאן – הנקודות הטובות. עכשיו מגיע החלק של נקודות קצת פחות טובות…
שיאומי בדרך כלל עושים עבודה די טובה בכל הקשור לחומרה – הן מבחינת טלפונים והן מבחינת ציוד רב אחר שהחברה מוכרת, אולם כשזה מגיע לתוכנה… הייתי ממליץ לחברה להיות קצת יותר בקשר עם הלקוחות ולתקן באגים בתכיפות יותר גבוהה. להלן מספר באגים שגיליתי, חלקם יכול להיות Deal Breaker וחלקם לא ממש:
לסיכום: האם הייתי ממליץ לקוראים שמחפשים לרכוש מסך טלויזיה לרכוש את המסך הזה? אם דיוק צבעים אינו פקטור חשוב – אז כן, בהחלט. אם לעומת זאת עומק צבעים, בהירות ודברים אחרים בנושא חשובים לאותו מתעניין – עדיף לחפש מסך אחר.
Enabling HTTP/2 in nginx is quite simple. You need to add the http2 parameter to the listen 443 directive. So find the line that looks like:
listen 443 ssl;
and change it into
listen 443 ssl http2;
And reload your nginx configuration:
$ sudo systemctl reload nginx.service
Few notes:
http2 in one of your server blocks. You don’t need to do so for every virtual server (unless they use a different port). See here.http2 to your port 80. Browsers don’t support unencrypted.
How to transfer history between two repositories, or a super repository to it's submodules.
in my case, I'm extracting the history of the path
"engine/C87AOP"
1. Prepare a bundle to clone a repository, which will be used for git filter-repo later
cd ~/git/source_repo
mkdir ~/git/working_dir
git bundle create ~/git/working_dir/C87.bundle master
2. Clone from the bundle file:
cd ~/git/working_dir/
git clone -b master ./C87.bundle
3. Extracting only C87AOP history by using git filter repo:
git checkout -b C87AOP_ENGINE
git filter-repo --path engine/C87AOP --refs C87AOP_ENGINE --force
4. adding a remote on destination repo to ~/git/working_dir
cd ~/git/dest_repo
git remote add local file:///home/user/git/working_dir/C87/
5. fetching the branch C87AOP_ENGINE from the remote local we added on step 4
git fetch local C87AOP_ENGINE
6. creating a new working branch locally
git checkout -b merging_history_from_c87
7. merging the branch C87AOP_ENGINE with local brnach
git merge local/C87AOP_ENGINE --allow-unrelated-histories
8. git checkout master
9. git merge merging_history_from_c87
10. git push origin master
11. git branch -d merging_history_from_c87
12. git remote remove local
13. rm -rfi /home/user/git/working_dir
אחת הטכנולוגיות המדהימות בתחומי מחשבים שנכנסה לחיינו לפני מספר עשורים – היא טכנולוגיית התממשקות USB עם ציוד מסוגים שונים. זו הטכנולוגיה שסוף סוף "הרגה" חיבורים שונים שהיה צריך להתמודד איתם, החל מחיבורי ה-PS/2, חיבורים סריאליים, חיבורי מדפסות, וחיבורים אחרים (זוכרים SCSI??).
אבל, כמו תמיד, כשבונים מפרט לטכנולוגיה ע"י מספר חברות ובאמצע נכנסים אינטרסים, לחצים ו"כיפופי ידיים", יוצא סלט איום – כמו הסלט שקשור לשמות החיבורים, מהו "דור" החיבור ועוד. כך אפשר לדוגמא למצוא שיש USB 3.1 אבל בעצם יש ל-3.1 שני דורות, Gen 1 ו-Gen 2 כאשר Gen 1 יכול להעביר נתונים במהירות עד 5 ג'יגהביט ו-Gen 2 מאפשר להעביר נתונים במהירות מדהימה של 10 ג'יגהביט, אבל … אם אין כיתוב מדויק מהו החיבור עצמו בציוד או בלוח האם, ואם אין לך את הכבל המתאים – זה פשוט לא יעבוד.
וכאן מתחילה הבעיה המהותית: כבלי USB Type C נראים זהים אחד לשני. עם Thunderbolt לדוגמא אפשר להבדיל בקלות בגלל סימון הברק שקיים על החיבורים בכבל ובחיבור במחשב. עם USB, המקסימום שתמצא אולי, אולי, זה סימון קטן של "10" שמציין שמדובר ב-USB 3.1 Type C Gen 2, אבל גם את זה לא תמצא במחשבים ניידים רבים.
אז לפני שאנחנו נכנסים לתוך הסלט הזה, חשוב לדעת קודם כל מה אנחנו מחפשים ומה ניתן למצוא כיום בשוק ברוב הזמן.
נתחיל בכבל USB Type C פשוט שניתן לרכוש בכל חנות מחשבים (שימו לב, כבל כזה כולל חיבור Type C בשני הצדדים). כבל כזה בדרך כלל יוכל להעביר מידע במהירות של עד 10 ג'יגהביט (תלוי אם ה-Port שאנחנו מחברים אותו תומך בחיבור Gen 2 מינימום) ויכול להעביר עד 60 וואט (W) חשמל מספק הכח. בחלק מהמקרים – מספרים אלו יצנחו מטה אם אנחנו מנסים לגרום לכבל להעביר גם מתח וגם נתונים (המספרים דינמיים, אבל מבחינת חשמל זה יכול לצנוח ל-9 וואט ולגבי מהירות נתונים – 5 ג'יגהביט ומטה). נקודה חשובה כשרוכשים כבל כזה היא אורך הכבל: ככל שהכבל יותר ארוך, מהירות העברת הנתונים תצנח למעט אם מדובר בכבל הכולל שבב בתוך חיבור ה-USB Type C בכבל עצמו – על כך אתייחס בהמשך פוסט זה.
אם אנחנו מעוניינים לחבר ספק כח בחיבור Type C אל המחשב הנייד, חשוב לבדוק כמה וואט (הכפלה של וולט X אמפר) הספק מציע. אם הספק מציע מעל 60 וואט, נצטרך כבל Type C PD – כבל זה יוכל להעביר עד 100 וואט, אך מבחינת העברת נתונים, המהירות בכבל כזה היא מהירות של USB 2.0 (כלומר – עד 480 מגהביט ברוטו).
אם אנחנו רוצים גם להעביר יותר מ-60 וואט וגם מהירות נתונים גבוהה, ישנן מספר חברות שמציעות כבלים כאלו (כמו UGREEN ואחרים), אך הכבלים הזולים מגיעים באורך כבל קצר – עד כמעט מטר (ברוב המקרים זה 80 ס"מ) ובדרך כלל הם יקראו בפשטות 100W PD USB C Cable (הנה דוגמא), כפי שאתם יכולים לראות בלינק – הכבל באורך 1 מטר אך הוא מסוגל להעביר וידאו 4K, נתונים במהירות 10 ג'יגהביט וחשמל 100W. כבל כזה יכול להתאים למקרים בהם רוצים לחבר מסך בחיבור Type C ללאפטופ קרוב. צריכים כבל באורך 1.80? יש את הכבל הזה, או את הכבל הזה, אך כפי שניתן לראות – אין מבחר רב, ולכן, בהתאם לצרכים – כדאי לרכוש גם כבלים קצרים (לתקשורת מהירה) וגם כבלים יותר ארוכים (טעינה עוצמתית).
בכל הקשור לכבלי USB Type C והעברת נתונים במהירות מעל 10 ג'יגהביט (USB 3.1 Gen 1 מעביר 5 ג'יגהביט, Gen 2 מעביר 10 ג'יגהביט, ו-USB 3.2 2X2 מעביר 40 ג'יגהביט) – כאן, לצערי, המצב יותר מורכב ומטעה – כבלים רבים המציינים כי הם מסוג USB 3.2 2X2 עם יכולת העברת נתונים במהירות 20 ג'יגהביט – הם לא יותר מכבלים שיכולים להעביר עד 10 ג'יגהביט (הנה דוגמא) ולכן אם אתם מחפשים כבל כזה (מתוך הנחה שהציוד שלכם אכן תומך במהירות 20 ו-40 ג'יגהביט) – יהיה מומלץ להסתכל על כבלים של Thunderbolt (ברוב המקרים זה יהיה תואם במהירויות הנ"ל, אך בכל מקרה כדאי לבדוק עם היצרן/המשווק של הציוד).
עניין חשוב נוסף הוא תמיכה בפיצול ב-USB Type C. יש לא מעט מפצלי USB שמוציאים מתוכם שלל חיבורים שלא קיימים במחשב הנייד (מספר חיבורי USB Type A, כניסה לכרטיסי SD, מיקרו SD, חיבור HDMI, חיבור Display Port ועוד). מפצלים אלו הם מעולים, אולם בדרך כלל כדאי לבדוק את הנקודות הבאות:
לסיכום: פוסט זה נגע "על קצה המזלג" בעולם המורכב של USB ובמיוחד Type C. לא כל כבל USB Type C יכול להתאים למטרות שלנו ולא כל פרסום שיווקי על כבלים כאלו הוא נכון. אם אתם מחפשים מעל הכל חיבורים להעברת נתונים מאוד מהירה (מעל 10 ג'יגה) אני ממליץ לכם לחפש פתרונות של Thunderbolt, ואם אתם מחפשים לחבר סוגים שונים של ציוד לצורך טעינה ותצוגה – הסתכלו בפרטים שכתבתי לעיל.
Hey all,
The latest Raspeberry Pi I am releasing is a distro that lets you flash and run social network called Pleroma. Its part of a group federated social networks known as the Fediverse. There are about 4 million users to date, although this does not compare to the giants today, its enough that the software is fairly mature and it looks and feel like networks you know, and there are enough people to follow and get a decent feed to read. It also mean you can use it for different uses not covered by mainsteam social networks.
Requirements
Setup
pleromapi-wpa-supplicant.txt at the root of the flashed card when using it like a flash drive/boot/docker-compose/pleroma/environments/pleroma/pleroma.env # Make sure to use your specific domain and email, otherwise you won't get an HTTPs cerfificate
ADMIN_EMAIL=admin@ops.pleroma.social NOTIFY_EMAIL=pleroma+admin@ops.pleroma.social DOMAIN=pleroma.gnethomelinux.com VIRTUAL_HOST=pleroma.gnethomelinux.com LETSENCRYPT_HOST=pleroma.gnethomelinux.com LETSENCRYPT_EMAIL=your_email_sent_to_letsencrypt@example.com/home/pi/scripts/make_admin_usercurl -k http://pleromapi.local -H "Host: ops.pleroma.social"/var/lib/pleroma/config.exsSource code is avilable here:
https://github.com/guysoft/PleromaPi
The docker-compose settings are forked on Pleroma’s gitlab:
https://git.pleroma.social/guysoft/pleroma-docker-compose/
Thats it! You should have a running Pleroma instance which is connected to the federated social network known as the Fediverse.
I would really value comments on how to improve this so it would be easy and hassle free to set up a social network instance.
Having your own node in the network mean you have full control on what is allowed to be posted, and what servers your Pi will allow to view. You can federate or defederate any content and you are not restricted to the current networks. So no more censorship, or moderate content you and people on your server don’t wish to see.
The question “should I do it in bash or in Python?” is both frustrating and common. Why one even needs to choose between two alternatives which are both inadequate for the task at hand? Why try to pick one of the square pegs for the round hole? I believe that you should not be in this annoying situation when just trying to write a script and get back to your endless stream of other todos.
bash does not meet any modern expectations for syntax, error handling nor has ability to work with structured data (beyond arrays and associative arrays which can not be nested). Let it go. You are not usually coding in assembly, FORTRAN, C, or C++, do you? They just don’t match the typical Ops tasks. Don’t make your life harder than it should be. Let it go. (Let’s not make it a blanket statement. Use your own judgement when to make an exception).
Python along with many other languages are general purpose programming languages which were not intended to solve specifically Ops problems. The consequence is longer and less readable scripts when dealing with files or running external programs, which are both pretty common for Ops. For example, try to check every status code of every program you run, see how your code looks like. Sure you can import 3rd party library for that. Is that as convenient as having automatic checking by default + list of known programs which don’t return zero + convenient syntax for specifying/overriding expected exit code? I guess not.
Your disorientation and frustration is completely legitimate.
Multitude of attempts to provide viable alternatives by different people are in progress. As others authors, I would like to help my Ops colleagues to avoid frustration and be productive. It just feels good.
Informative section is over. Shameless plug about an alternative that I am developing and how it is special follows.
How Next Generation Shell differs from the alternatives? Reasonable question that I would ask too before investing any more time if I was the reader.
Current shells as well as proposed alternatives treat UI as nothing has happened since the 70-s: mostly typing commands and getting some text back.
How about real interaction with the objects on the screen? Oops. In a typical shell there are no objects on the screen, it’s just a dumpster of combined text (if you are lucky; could be binary) from stdout and from stderr from one or more processes (unless steps were taken). WTF? It doesn’t help you to win. It helps you to lose time. NGS does what is intended to make you productive. I have organized my thoughts about how the UI should look and behave on the wiki page.
It looks like alternative solutions have the “let’s make the shell better” approach and therefore are heavily based on the shell syntax and paradigms.
There is also “let’s make a library for existing language” approach which doesn’t hit the target either. Can’t have a syntax for common ops tasks for example.
And finally there is “let’s make a library and a syntax on top of existing language”. Not sure about this one. Sounds good in theory. Looked some time ago at something like this and the overall impression was … awkward (for the lack of better word).
Approach in NGS: let’s make a good programming language for Ops, which fits the use cases and has syntax and facilities for the most common tasks such as running external programs.
The language follows the principle that the most common tasks should have their own syntax or a library function (depending on usage frequency). Examples:
``external program`` – runs external program and parses the output (JSON is auto detected, easily extensible for anything else).status(), log(), debug(), retry() – standard library functions. How many times an Ops person should write his/her own retry()? It’s insane.Argv() facility for constructing command line parameters (for calling external program).p=$(my_prog my_args &); ....; p.wait().Small number of “big” core concepts in the language (types with inheritance, multiple dispatch and exceptions).
Most of the standard library is in NGS.
The UI (only recently started working on it) is in NGS. It doesn’t make sense that when a user of the shell wants to fix a bug in the UI and suddenly he/she needs to learn Go, Rust, C or whatever other language.
We use NGS at work.
Most of the demo scripts come from either current or previous work.
If you are like me, you will find at least some satisfaction in using the most appropriate tool before continue to the myriad of other tasks that are in your todo queue.
Reddit: https://www.reddit.com/r/devops/comments/jm3cwe/bash_or_python_the_square_pegs_and_a_round_hole/
לחלק מהאנשים נמאס מהווב, והחליטו לעשות לו ריבוט. כתבו פרוטוקול להעברת מידע חדש במקום HTTP (S) ותסדיר תצוגה חדש במקום HTML. הפרוייקט נקרא Gemini. הינה אתר הבית שלו בווב המיושנת: https://gemini.circumlunar.space/
יש שם הוראות התקנה לתוכנת “גלישה”, אני התקנתי משהו שהיה כתוב ב־go וזה נתן לי ממשק טקסטואלי. התקנה של שניות בודדת והתוכנה מגיבה מאוד מהר הפרוטוקול ממש.
הפרוייקט הזה מיותר ואין טעם להשקיע בו. הם מימשו מחדש את gopher (אני רק זכיתי לקרא עליו ולא השתמשתי בו אף פעם). הפרוייקט מנסה לפתור את בעיית העברת המידע וגם התצוגה. נניח, ואני לא בטוח בזה, ש־http לא מספיק טוב, אוקי. נניח שהפרוטוקול הטקטואלי שהם מציגים יותר טוב. שכבת התצוגה לטעמי מיותרת. יש פתרון יותר טוב בשטח שנקרא markdown שמספק את מה שהם רוצים.
פתרון יותר טוב לבעייה שהם מציגים הוא לגרום לדפדפנים להציג markdown בצורה native ואז לבנות אתרים שרק שולחים markdown. יש לנו שרתים טובים להעברת המידע, יש לנו עורכים טובים בשביל התוכן. אין טעם לעשות “עוד אחד”.
אין מה לראות – תמשיכו הלאה.
This post is outdated. For a newer version see Amir Aharoni’s Quasi-Pro Tips for Translating the Software That Powers Wikipedia, 2020 Edition
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.
First, let’s do some work to set you up.
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:
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.
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).
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:
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.
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.
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.
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.
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.
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.
Versions of this post were already published in the following languages:
I’m deeply grateful to all the people who made these translations; keep them coming!
This is a new version of a post that was originally published in 2015. Much of it is the same, but there are several updates that justified publishing a whole a new version.
As you probably already know, Wikipedia is a website. A website has two components: the content and the user interface. The content of Wikipedia is the articles, as well as various discussion and help pages. The user interface is 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 the user interface translated to your language, and doing it as quickly, easily, 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 more than 3,800 messages to translate in MediaWiki, and the number grows frequently. “Messages” in the MediaWiki jargon are strings that are shown in the user interface. Every message can and should be translated.
In addition to core MediaWiki, Wikipedia also uses many MediaWiki extensions. Some of them are very important because they are frequently seen by a lot of readers and editors. For example, these are extensions for displaying citations and mathematical formulas, uploading files, receiving notifications, mobile browsing, different editing environments, etc. There are more than 5,000 messages to translate in the main extensions, and over 18,000 messages to translate if you want to have all the extensions translated, including the most technical ones. 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 impossibly enormous job. It indeed takes time and effort, but the good news are that there are languages into which all of this was translated completely, and it can also be completely translated into yours. You can do it. In this post I’ll show you how.
In early 2011 I completed the translation of all the messages that are needed for Wikipedia and projects related to it into Hebrew. 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. Since then, if you can read Hebrew, you don’t need to know a single English word to use it.
I didn’t do it alone, 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, Dagesh Hazak, Guycn2 and Inkbug (I don’t know the real names of the last three), 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.
However, 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 only 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 because I am ill. It slipped for quite a few months in 2014 because my first child was born and a lot of new messages happened to be added at about the same time, but Hebrew got back to 100%. It happened again in 2018 for the same happy reason, and went back to 100% after a few months. And I keep doing this.
With the sincere hope that this will be useful for helping you translate the software that powers Wikipedia completely to your language, let me tell you how.
First, let’s do some work to set you up.
If you haven’t already, create a translatewiki.net account at the translatewiki.net main page. First, select the languages you know by clicking the “Choose another language” button (if the language into which you want to translate doesn’t appear in the list, choose some other language you know, or contact me). After selecting your language, enter your account details. This account is separate from your Wikipedia account, so if you already have a Wikipedia account, you need to create a new one. It may be a good idea to give it the same username.
After creating the account you have to make several test translations to get full translator permissions. This may take a few hours. Everybody except vandals and spammers gets full translator permissions, so if for some reason you aren’t getting them or if it appears to take too much time, please contact me.
Make sure you know your ISO 639 language code. You can easily find it on Wikipedia.
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 Indonesia like Javanese (jv) or Balinese (ban), then you probably also know Indonesian (id). 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.
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:
I usually don’t work on translating other projects unless all 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.
So how can you know what is important among more than 18,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).
Have you read the general localization guide for Mediawiki? Read it again, and make sure you understand it. If you don’t, ask for help! The most important section, especially for new translators, is “Translation notes”.
A super-brief list of things that you should know:
Learn to use the project selector at the top of the translation interface. Projects are also known as “Message groups”. For example, each extension is a message group, and some larger extension, such as Visual Editor, are further divided into several smaller message groups. Using the selector is very simple: Just click “All” next to “Message group”, and use the search box to find the component that you want to translate, such as “Visual Editor” or “Wikibase”. Clicking on a message group will load the untranslated messages for that group.
The “Extensions used by Wikimedia” group is divided into several more subgroups. The important one is “Extensions used by Wikimedia – Main”, which includes the most commonly used extensions. Other subgroups are:
There is also a group called “EXIF Tags”. It’s an advanced part of core MediaWiki. It mostly includes advanced photography terminology, and it shows information about photographs on Wikimedia Commons. If you are not sure how to translate these messages, ask a professional photographer. In any case, it’s OK to do it later, after you completed more important components.
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 remove 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. The list is ordered not by importance, but by the number of messages to translate (as of October 2020):
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 actually, 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.
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” (this may take a few seconds—there are lots of them!), 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. This strategy can work well if you have several people translating to your language, because it’s easy to divide work by topic. (Going to all extensions, beyond Extensions used by Wikimedia, helps users of these extensions, but doesn’t help Wikipedia very much.)
Another fun 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 Georgian. You only need to translate 37 messages to pass Marathi and go up a notch (2555 – 2519 + 1 = 37). Then 56 messages more to pass Hindi and go up one more notch (2518 – 2463 + 1 = 56). And so on.
Once you’re done, you will have translated over 5600 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 way over 10,000 messages, but the same strategies work.
Invite your friends! You don’t have to do it alone. Friends will help you work more quickly and find translations to difficult words.
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. There are developers who know their code very well, but who are not the best 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. Also, 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. English is foreign to them, and they may make mistakes.
So if anything is hard to translate, of if there are any other problems with the English messages to the translatewiki Support page. While you are there, 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 using 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 or improve 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 itself, Be Bold.
Well done and congratulations.
Now check the statistics for your language every day. I can’t emphasize enough how important it is to do this every day. If not every day, then as frequently as you can.
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 are just a few new messages to translate; I didn’t measure precisely, but usually it’s fewer 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 or more? 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.
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”. Also, the knowledge that you are responsible for creating and spreading the terminology in your language for one of the most important and popular websites in the world.
Oh, and you also get enormous experience with software localization, which is a rather useful and demanded job skill these days.
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.
Thanks!
השליט העליון שכב במיטת בית החולים. הוא התקשה לנשום והתקשה לחשוב. את מעט הריכוז שעוד הצליח לגייס הפרו הצפצופים הדחופים של מכונות הניטור והחמצן. המחלה הארורה השיגה אותו לבסוף. כמו שהזהירו המדענים, החיסון לא עבד. הוא שמח כשנזכר שהורה על הוצאתם להורג. "מה הטעם במדענים", חשב לעצמו בלעג, "אם אינם מועילים בריפוי המגיפה?"
לאט לאט, הנהן בראשו להסכמה. הרופאים ביקשו להרדים ולהנשים אותו. לא היתה ברירה, הם אמרו. בלי זה, הוא לא ישרוד את הלילה. הנהונו גרם לפרץ של פעילות. רופאים ואחיות החלו בשרשרת של סידורים. השליט לא סמך על רופאות ואסר על לימודי רפואה לנשים כבר לפני שנים רבות.
לבסוף שככה הפעילות ורופא זקן ניגש אליו. השליט העליון לא ראה את הרופא הזה קודם אך על פי יחס שאר אנשי הצוות אליו השליט העליון הבין שהוא רופא בכיר. השליט העליון היה טוב מאוד בלקרוא אנשים ומצבים. משהו הטריד אותו ברופא הזה. הרופא הזקן התכופף. השליט העליון הבחין בתואר "פרופסור" על תג השם שלו, אבל לא הצליח להתרכז מספיק כדי לקרוא את השם המלא. הוא לא אהב פרופסורים.
הרופא הזקן הביט בשליט העליון ואז, מבלי להסיר את עיניו ממנו, הנהן. רופא אחר, צעיר יותר, נחפז אל השליט העליון והוא חש דקירה בזרועו. הרופא הזקן נפנף והרופא הצעיר התרחק במהירות.
השליט העליון חש לפתע קור. "מה זה?" ,חשב, "מישהו פתח את החלון?". לא הייתה זאת מחשבה הגיונית, כך ידע, אבל הוא מצא שקשה לו עוד יותר להתרכז. הוא חש עייף. הרופא הזקן התקרב עוד יותר אליו, הביא את פיו לאוזנו, ואמר משהו. השליט העליון ניסה מאוד להתרכז להבין מה נאמר. זה היה קשה מאוד. לבסוף הבין. פיו נפער, אבל אף בת קול לא יצאה. עיניו נעצמו.
"Sic Semper Tyrannis"
TL;DR – this is not nearly good enough in most cases and it’s only small fraction of what you are paid for.
I want this post to be the canonical place to refer people to who say “but it works” because people who explain why this is not OK are tired of repeating the same arguments, me included.
Following is not an exhaustive list but it should give you some perspective which is opposite from the narrow-minded “but it works”.
Typically, your Software Engineering $Job pays you for:
If you claim that you are “done” because “it works”, congratulations, you have a (probably) working prototype. That’s typically small part of a project.
Related term – “Tactical Tornado”, look this up.
Update 2020-09-13: Reddit discussion
רשתות נוירונים מהווים היום את שיטת הלמידה החשובה ביותר. הם הביאו לפרצות דרך חשובות. היום כל אדם בעל ידע בתכנות ורקע מתמטי סביר יכול לממש דברים שהיו מדע בדיוני לפני עשור. כוח החישוב העצום של מעבדים גרפיים וזמינות גבוהה של נתונים שינה את פני למידה החישובית. היום אם אתה רוצה להתעסק תחום ראיה ממוחשבת, עיבוד קוד תרגומים וכד' חייב להכיר את השיטות האלה.
היום קיימות עשרות תשחתיות (frameworks) לעבודה עם רשתות נוירונים - וכל הפופולריים ביניהם הם תכנה חופשית: tensorflow, pytorch, caffe, keras, mxnet ועוד רבים אחרים הם תכנה חופשית שמופצת תחת רשיונות די מתרניים. חברות ענק שעומדות מאוחרי חלק מהם כמו facebook ו־google דואגים להחזיק את הקוד הפתוח - כי רק כך ניתן לשרוד בעולם הזה בו השיטות והמאמרים שפורסמו לפני שנה כבר לא מספיק עדכניים.
אבל, יש פה אבל אחד גדול מאוד. כל התשתיות האלה, דורשות שימוש ב־GPU על מנת לקבל תוצאות בזמן סביר. נקח לדוגמה את הרשת המקורית הידועה בשם alex-net שהייתה אחת פרצות הדרך מהמשעותיות ביותר בתחום הלמידה החישובי בשני עשורים אחרונים. זמן אימון הרשת ב־2012 לקח סדר גודל של שבועיים תוך שימוש בשני כרטיסים גרפיים.
כמובן אין כל פסול בשימוש בכרטיסים גרפיים - הם בסה"כ עושים מה שהם יודעים לעשות טוב number-crunching. אבל, היום כמט כל התשתיות מסתמכות של טכנולוגיה אחת וספק אחד - כולם משתמשים ב־cuda וב־nVidia. יתרה מזו חלק מהתשתיות מסתכמות באופן בלעדי על ספריה סוגרה אחת בשם cuDNN שמאפשרת לנצל את כל החישוב של החומרה עד תום. cuDNN ו־cuBLAS הן הספריות שבלעדיהם tensorflow או pytorch פשוט לא יכולים להקיים מבחינת לקוח הקצה.
כן, קיימות תשתיות שמאפשרות אימון גם על טכנולוגיה פתוחה. לדוגמה ל־caffe יש ענף opencl העובד על בסיס טכנולוגיות פתוחות ויודע לרוץ גם על כרטיסים של AMD ואפילו של Intel. אבל
בהתחשב בעובדה שחלק מהאימונים יכולים לקחת שעות רבות אפילו ימים זה הופך את הענף של opencl לפחות רלוונטי. הסיבה לאיטיות היא שהמימוש לא נהנה האופטימיזציות מטורפות וכתיבה ב־assembly ש־nVidia הייתה יכולה לעשות ב־cudnn ו־cuBlas.
אבל מה עם AMD? האם הם ישנים? כן ולא. AMD דאגו לפתח אלטרנטיבה בשם ROCm. למעשה אם אתה עובד על לינוקס ויש לך כרטיס כמו rx580 או Vega 56 אתה יכול באמץ סביר להריץ את ה־tensorflow ו־pytorch ואפילו caffe על AMD. והיתרון הגדול של ROCm הוא שמדובר בקוד פתוח לחלוטין. החסרון?.. מאיפה להתחיל
למעשה נראה כי AMD עשתה הכל כדי למנוע ממישו אפילו להסתכל בכיוון שלהם לטובת deep-learnים.
מה עם פתרונות עבור intel? הרי גם להם יש GPU? מעבר לעובד שביצועי Intel GPU הם בדיחה, גם intel דאגה לכתוב ספריית deep-learning משלה שלא עובדת עם שום כרטיס גרפי אחר.
למרות שמבחוץ נראה שכל נושא למידה חישובית על רשתות נוירונים מתבסס על תכנה חופשית, במציאות יש רק דרך אחת לעבוד - לעבוד עם הקוד הסגור של ספק אחד. ללא שילוב של nVidia/cuda/cudnn התחזיות של Deep-Learning די עגומות
שוחררה גרסת בטא הראשונה. השינויי העיקרי - לפי דרישת הקהילה זה מעבר ל־C++11 כברירת מחדל - מה שאפשר לנקות חלקים נכבדים מספריית booster הממשים פונקציונליות שהייתה חסרה ב־C++2003:
ביניהם:
std::error_code ונגזרותיוauto_ptr ז"ל ל־unique_ptr ועוד.ראוי לציין שהגרסה הקודמת עבדה עם C++11 אבל לא ניצלה את היכולות שלה כמו למשל move-constructor וכד'.
כיוון שהשינויים לא ב־100% תואמים לאחור זוהי גרסת משמעותית מבחינת משתמשים.
חייב לציין שעל אף שינויים בחלק מה־APIים - כל הדוגמאות ואפליקציות שונות כגון הבלוג הזה עברו בנייה ללא שינווים בכלל.
בנוסף כיוון ש־python2.7 הגיע ל־End-Of-Life הסבתי את הקוד של unit-tests ושל ה־template compiler לתמיכה גם python2.7 וגם ב־python >= 3.5. חייב לציין שאני עדיין מתפלא מהשטות הזו של הסבת מחרוזות ל"unicode" במקום שימוש ב־utf-8 פשוט. למה להרוס לאנשים שאת הקוד הקיים?
What is the quickest way to generate lots of random data on the command line? Usually when I had to wipe hard-drives I would simply use dd to copy from /dev/urandom over the device. However, `/dev/urandom is quite slow and wiping hard-disks can take a long time that way. So, I decided to benchmark a few methods to generate long random streams that are usable in such scenarios.
The benchmark is based on the dd command. For example:
$ dd if=/dev/urandom of=/dev/null bs=4k count=1M
This command will copy a 4GB of random bytes from /dev/urandom over /dev/null. This is probably the simplest method to create a large stream of random bytes, and as it turns out, also the slowest.
The second construct I tried is to use OpenSSL to create a stream of random data which I can read with dd and then write to the target. For example the following would use AES-128 with a random key:
$ openssl rand -hex 32 | openssl enc -aes-128-ctr -in /dev/zero -pass stdin -nosalt | dd if=/dev/stdin of=/dev/null bs=4k count=1M
Let’s breakup this command: openssl rand -hex 32 will generate a random encryption key to be used by the AES encryption. openssl enc -aes-128-ctr -in /dev/zero -pass stdin -nosalt does the actual encryption. It reads the (random) key from stdin and then uses it to encrypt /dev/zero using AES-128 in counter mode. As /dev/zero in an endless stream of zeros, it will simply output an endless stream of (pseudo-)random data. We can also repeat the same command only swapping aes-128-ctr with aes-256-ctr. For most (all?) usage scenarios it doesn’t provided any added security benefits but does have a (small) performance penalty.
Apart from AES, which is a block cipher, we can also try to use actual stream ciphers like the old rc4 and the modern chacha20.
Additionally, many new CPUs come with AES-NI extension which speeds up AES operations considerably. We can repeat the benchmark while disabling AES-NI to see how the different methods will perform if used a CPU that doesn’t support AES-NI.
Finally, I’ve repeated the test with /dev/zero as input, just to have an upper-limit in terms of performance to compare against.
| AES-NI | No AES-NI | |
| /dev/zero | 0.42609 | |
| /dev/urandom | 18.8967 | |
| chacha20 | 2.69306 | 3.79217 |
| aes-128-ctr | 2.04106 | 14.9022 |
| aes-256-ctr | 2.24756 | 18.9014 |
| rc4 | 7.77392 |
The results clearly show that you should avoid /dev/urandom. It’s simply not suitable for this task and doesn’t perform well. The various methods of using OpenSSL perform much better. The best performance is achieved by the two AES variants, with aes-128-ctr being the fastest. However, if AES-NI is not supported by the CPU, AES takes a huge performance hit, and is even slower than the (not-so-)good and old RC4. However, ChaCha20 (a modern stream cipher) performs within 30% of AES if AES-NI is available, but if AES-NI is not supported ChaCha20 outperforms the AES variants. So, unless you know AES-NI is supported ChaCha20 is the safe choice.
נדרשתי למערכת אשר צריכה לעבוד מאחורי NAT.
עם NAT יש מספר בעיות, אשר אחת מהן היא כיצד אני מקבל דברים פנימה, ולא רק כיצד אני ממפה את הפנים כלפי חוץ.
כלומר נגיד ואני רוצה לגשת ל 10.0.0.12 ב HTTP כאשר אני נמצא באינטרנט, והשרת נמצא מאחורי 10.0.0.12, אין לי סיכוי ללא יכולת לעשות Port forwarding, הנגשת השרת כלפי חוץ או reverse proxy כלשהו.
אותו הדבר הפוך. יש לי הרבה מחשבים שצריכים לקבל פנימה תקשורת מבחוץ כשהם לא יזמו את הפניה, מה שאומר שאין session פתוח, ואין דרך ככה סתם להתומדד עם הבעיה הזו בתקשורת ללא כלים נוספים.
כאשר יש אפשרות לשלוט ברשת, ניתן להוסיף כלים שונים, אבל מה קורה כאשר אין לך יכולת לשלוט ברשת הפנימית, אבל עדיין צריך להיכנס פנימה? ובכן, משתמשים ב VPN ויוצרים רגל חדשה בין 2 קצוות (או יותר).
הגעתי למצב שבו הייתי לתמוך במספר מערכות הפעלה בהם לינוקס, ווינדוז ואנדרואיד (שהוא custom לחומרה).
בהתחלה הלכתי לכיוון OpenVPN אך באנדרואיד מצאתי מספר בעיות שלא התאימו כפיתרון היות והאנדרואיד הותאם בצורה מלאה לחומרה מסויימת, אשר לא יכולתי לגרום ל VPN לעבוד כמו שצריך בלי שהרשת תשאר לי יציבה, ולמעשה הרבה פניות נפלו לי ולא יצאו מהמכשיר, וחלק מהבקשות לא נכנסו למכשיר.
אז התחלתי לחפש פתרון אחר וגיליתי כי ישנו VPN קוד פתוח חדש יחסית בשם Wireguard אשר מפשט מאוד כיצד הרעיון ש VPN עובד.
הרעיון של Wireguard הוא שכל חיבור בין אם "שרת" ובין אם "לקוח" הוא בעצם Peer.
כאשר אני רוצה לתהחבר ל"שרת", אני אשים את הכתובת להתחבר אליו, ובמידה ואני רוצה למצוא שכנים אני אגדיר אותם במפורש בקובץ ההגדרות עבור אותו Peer.
ברגע שהבנתי את העיקרון הזה, ולי לקח זמן להבין את הרעיון הזה, למעשה הבנתי לגמרי כיצד Wireguard מוגדר ועובד.
ישנם מדריכים מדהימים ברשת, כולל באתר, הרשמי, כך שלא אכנס להגדרות כאן.
שמתי לב כי הוא מתפקד הרבה יותר טוב במרבית האנדרואידים, ויש לו תמיכה ב QR Code בשביל לטעון קובץ הגדרות מאוד פשוט. דבר שמקל מאוד מאשר להזין את הנתונים ידנית.
כמו כן, מצאתי כי קשה לייבא את הקובץ בצורה פשוטה במכשירי האנדרואיד שהיו ברשותי, ולכן זה היה הפתרון הקל ביותר.
אחד הדברים המדהימים באמת של Wireguard זו הפשטות ליצור תעודות הצפנה.
פקודה קטנה ליצור מפתח פרטי ופקודה נוספת לקחת את המפתח הזה וליצור מפתח ציבורי.
בקובץ של המכשיר שמים את המפתח הפרטי, ובהגדרות של כל מי שצריך לדבר איתו שמים את המפתח הציבורי.
המפתחות שמורים כשורת base64 ואין התעסקות עם המון כלים כדוגמת easy-rsa של openvpn, ואין צורך להתעסק עם openssl.
קובץ ההגדרות יראה בצורה הזו ב"לקוח":
[Interface]
PrivateKey =
Address = 10.1.0.2/24
[Peer]
PublicKey =
PersistentKeepalive = 20
Endpoint = address:port
AllowedIPs = 0.0.0.0/0, ::/0
[Peer]
PublicKey =
AllowedIPs = 10.1.0.3/32
[Peer]
PublicKey =
AllowedIPs = 10.1.0.2/32
היצירה של ה QR התבצעה על ידי באמצעות לינוקס עם הפקודה qrencode בצורה הזו:
qrencode -t PNG -o qr_conf_for_phone.png --verbose < wg_conf_for_phone.confוקובץ ההגדרות נוצר כקובץ png, שאפשר להציג על המסך ולגרום לתוכנה לסרוק אותו.
בשורה התחתונה, אני מאוד מרוצה מה vpn שלא רק קל להגדרה אלא נראה יציב יותר.
אחרי שלוש שנים שבהן האתר הזה רץ מעל שרות האחסון של Scaleway, קיבלתי מהם הודעה שהחומרה שעליה אני רץ (dual core ARM CPU, 2GB RAM, 50GB SSD) תפסיק לעבוד בעוד מספר חודשים. הם הציעו לי לעבור באותו מחיר לשרת VPS מבוסס אינטל, אלא שעוד לפני שהספקתי להגיב, קיבלתי את המכתב שזו כותרתו: We’re evolving our Instances prices, או בתרגום חופשי: נמאס לנו להיות הכי זולים בשוק, אז נעלה את המחיר ב 66%.
החלטתי שזה הזמן לחפש שרות אכסון חדש, והגעתי דרך חבר לעבודה ל OVHcloud. השרת הבסיסי נראה על הנייר חלש יותר (מעבד אחד בלבד ודיסק קטן יותר), אבל בבדיקות ביצועים בשטח הוא משמעותית יותר מהיר. זה מורגש גם בעבודת ההתקנה (פרטים בהמשך) וגם בזמן ריצה, כפי שנמדד ע״י StatusCake. המחיר זהה למחיר (הישן) של Scaleway: שלושה אירו לחודש, בלי התחייבות.
השרת שלי מריץ בנוסף גם שני שרתי node קטנים, כך שהעברת כל הטוב הזה היא לא פשוטה, ולכן החלטתי הפעם ללכת על Docker. למי שלא מכיר את Docker, מומלץ לקרוא את סדרת המאמרים באתר של רן בר-זיק. שם הוא גם מדגים התקנת WordPress. אני בחרתי לעקוב אחרי המדריך של Michael J. Stealey ב GitHub, שממנו גם עשיתי פורק לריפו משלי. המדריך הזה קצת יותר מתאים לסביבה הנוכחית שלי שכוללת MariaDB במקום MySQL, וגם סקריפטים מוכנים לתמיכה ב https, דרך השרות של Let’s Encrypt.
רוב התהליך עוקב אחרי ה README, אבל מכוון שלא התחלתי מאתר חדש כפי שהמדריך מתאר, ביצעתי מספר שינויים, כמו שיחזור של ה DB ומבנה הקבצים מהשרת הנוכחי. זו הייתה טבילת האש הראשונה ל restic שהזכרתי באחד הפוסטים הקודמים והוא הוכיח את עצמו מצויין. שחזור של MySQL שרץ בתוך קונייטנר הוא קצת מורכב, וגם כאן יש לבר-זיק מדריך טוב.
אז נשארו לי כמה קצוות לסגור, כמו חידוש אוטומטי של הסרטיפיקטים ב Let’s Encrypt, והפעלה של גיבויים, אבל בסך הכל נראה שדוקר עושה עבודה טובה, והמעבר הבא יצריך ״רק״:
sudo docker-compose up -d
The post עוברים דירה appeared first on בלוג פשוט.
אני לא אוהב ביקורות של “הינה מכשיר, קיבלתי אותו לבדיקה היום”. אי אפשר ללמוד כלום מיום עבודה. אז הינה ביקורת אחרי חודשיים:
לגולש ברוך שכתב פה הודעה בפוסט קודם:
אני לא יודע אם רק עכשיו התגובה שלך מוצגת באתר, אם כן, סליחה שלא אישרתי אותה. בכל מיקרה – כן, הכל עובד בצורה די שקופה. הודעות Whatsup לא תמיד מגיעות מיידית (לא הבנתי חוקיות, לפעמים זה באמת מגיע מיידית). אבל זה עובד לא רע למעט זה.
הבעייה שלי היא … המסביב. איך מגבים Whatsup. איך מוחקים/מאתרים מרחוק את המכשיר כשהוא נאבד. התמיכה ב־Chromecast היא חסרה לי. השלוש חנויות שאני נאלץ להתמודד איתן זה מעיק.
אני מודע לכך שלא כתבתי יותר משש שנים ואני מקווה שמישהו עוד עוקב אחרי הבלוג. אבל לאחרונה קניתי מחשב חדש וכמובן שהתקנתי עליו ארץ׳ וחשבתי שתיאור התהליך יוכל לעזור למישהו. לי לפחות יוכל לעזור בעתיד לדעת מה בדיוק עשיתי.
למרות הכותרת המפוצצת, לא מדובר על מדריך מלא עם הסברים ובטח לא על מדריך פשוט של העתק־הדבק. חשוב להבין מה אתם עושים ובמחשבים אחרים ייתכן שהפקודות יצטרכו להיות שונות.
בהתקנה התבססתי על שני מדריכים עיקריים:
בתור התחלה, הורדתי את תקליטור ההתקנה של ארץ׳, „צרבתי” אותו על החסן נייד והעליתי את המחשב ממנו.
wifi-menu
או שמתחברים עם כבל לרשת קווית
בדיקה שמחובר:
ping -c3 google.com
timedatectl set-ntp true
אצלי כבר היה מותקן אובונטו מהיצרן ולכן השארתי את שתי המחיצות הראשונות של uefi ומחיצת שחזור ומחקתי את המחיצה של אובונטו
fdisk /dev/nvme0n1
יצרתי מחיצה ל־swap של 24G, מחיצת שורש של 30G ומחיצת בית של 175G שנשארו (לפי הסדר הזה)
mkswap /dev/nvme0n1p3 swapon /dev/nvme0n1p3 mkfs.ext4 /dev/nvme0n1p4 mkfs.ext4 /dev/nvme0n1p5
pacman -Sy reflector
cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak
reflector -c "IL" -f 12 -l 10 -n 12 --save /etc/pacman.d/mirrorlist
mount /dev/nvme0n1p4 /mnt
mount /dev/nvme0n1p5 /mnt/home
pacstrap /mnt base linux linux-firmware nano intel-ucode
genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot /mnt
ln -sf /usr/share/zoneinfo/Asia/Jerusalem /etc/localtime
hwclock --systohc
nano /etc/locale.gen
en_US.UTF-8 UTF-8
he_IL.UTF-8 UTF-8
locale-gen
echo myname > /etc/hostname
nano /etc/hosts
127.0.0.1 localhost
::1 localhost
127.0.1.1 myname.localdomain myname
passwd
pacman -S grub efibootmgr
mkdir /boot/efi
mount /dev/nvme0n1p1 /boot/efi
grub-install --target=x86_64-efi --bootloader-id=GRUB --efi-directory=/boot/efi
grub-mkconfig -o /boot/grub/grub.cfg
useradd -s /bin/bash -g users -G sys,adm,wheel -m user
passwd user
pacman -S xorg-server xf86-video-intel
pacman -S eog evince file-roller gdm gedit gnome-calculator gnome-color-manager gnome-control-center gnome-disk-utility gnome-font-viewer gnome-keyring gnome-logs gnome-menus gnome-screenshot gnome-session gnome-settings-daemon gnome-shell gnome-shell-extensions gnome-system-monitor gnome-terminal gvfs gvfs-gphoto2 gvfs-mtp mutter nautilus networkmanager simple-scan totem xdg-user-dirs-gtk
לא כל גנום חובה, חלק אני רציתי
להפעיל את השירותים
systemctl enable gdm NetworkManager
pacman -S sudo
nano /etc/sudoers
%wheel ALL=(ALL) ALL
pacman -S base-devel wget
wget https://aur.archlinux.org/cgit/aur.git/snapshot/yay-bin.tar.gz
tar -xzf yay-bin.tar.gz
cd yay-bin
makepkg -si
קצת סיפור להוריד ולבנות את החבילה של הגופנים אז אפשר להוריד אותה מדרייב:
pacman -U ttf-ms-win10-10.0.18362.116-2-any.pkg.tar.xz
yay -S culmus culmus-fancy-ttf ttf-alef
pacman -S firefox-i18n-he chromium
pacman -S libreoffice-fresh-he
libhdate-glib vlc mlocate reflector zsh zsh zsh-completions zoom parcellite
reboot
אם התקנתם הכול נכון אז המערכת תעלה ותוכלו להינות ממנה. בהצלחה!
Earlier today I presented orchestrator on DB AMA. Thank you to the organizers Morgan Tocker, Liz van Dijk and Frédéric Descamps for hosting me, and thank you to all who participated!
This was a no-slides, all command-line walkthrough of some of orchestrator‘s capabilities, highlighting refactoring, topology analysis, takeovers and failovers, and discussing a bit of scripting and HTTP API tips.
The recording is available on YouTube (also embedded on https://dbama.now.sh/#history).
To present orchestrator, I used the new shiny docker CI environment; it’s a single docker image running orchestrator, a 4-node MySQL replication topology (courtesy dbdeployer), heartbeat injection, Consul, consul-template and HAProxy. You can run it, too! Just clone the orchestrator repo, then run:
./script/dock system
From there, you may follow the same playbook I used in the presentation, available as orchestrator-demo-playbook.sh.
Hope you find the presentation and the playbook to be useful resources.
ביחד עם משבר הקורונה, אנשים רבים גילו כי לצד העבודה מהבית הרישיון לתוכנות ה-GIS שלהם נשאר במשרד. סדנאות ה-QGIS שלנו מיועדות למי שרוצה להשתחרר ממגבלות עולם ה-GIS הקנייני ולעבוד עם תוכנה ללא מגבלות על שימוש והתקנות וזאת מבלי לוותר על יכולות של התוכנה.
לצד סדנה בהתאמה אישית לארגונית (דרך zoom בתקופת הקורונה) המאפשרת גמישות מקסימלית של התכנים, אנחנו מפעילים סדנאות חודשיות עם תוכן קבוע. סדנאות QGIS שלנו ביוני 2020:
סדנאות המבוא מיועדות לאנשים שרוצים לעבוד עם מפות ולבצע ניתוחים מרחביים במסגרת תחומי העיסוק שלהם: כלכלנים, מהנדסות, אדריכלים, מתכננות ערים, אקולוגים, ארכיאולוגיות, גיאולוגים ועוד. הן מיועדת גם למי שלא מכיר GIS או מכיר ברמה בסיסית.
ניתן להשאיר פרטים בטופס ההתעניינות ונחזור אליכם עם פרטים וכיצד להרשם או להצטרף לניוזלטר החודשי שלנו כדי לקבל עדכונים על סדנאות עתידיות.
יש לי מספר מערכות שפיתחתי במהלך השנים שנמצאות בשימוש יומיומי על ידי מספר חברות מאוד מוכרות בארץ וכן משרדי ממשלה.
במהלך הקורונה, עוד משרד ממשלתי החל להשתמש בו על מנת לדווח לאנשים כי שהו במחיצת חולי קורונה, או נמצאו חיוביים בעצמם.
אם עד הקורונה, השימוש במערכת שלי, גם בימי בחירות עמד על כמות מסויימת, לכמות הזו נוספה עוד דרישה – לא עמידה בעוד מליוני בקשות בשניה (למזלנו), אלא להתמודד עם בקשות מאוד גדולות שמכילות יותר מידע ממה שהמערכת שלי תוכננה להתמודד מההתחלה, וזאת מבלי לפגוע משתמשים הרגילים הקיימים במערכת.
אם בקשה רגילה לוקחת פחות משניה, אז בקשה כפי שנעשתה עבור המצב הנוכחי דרשה ממני לספק את אותו פרק הזמן, אך בפועל לקחה כ 4-6 שניות, בו בזמן ששניה נחשבת לארוכה מידי.
התחלתי למדוד מה המקומות שלוקחים הכי הרבה זמן וגיליתי כי משהו שהוא מחוץ לשליטתי הוא הגורם לכך.
אז התחלתי להסתכל על איך אני ניגש לאותו גורם, וגיליתי כי אני יכול לפרק את המידע למספר חלקים ולהתמודד איתם בצורה א-סינכרונית תוך כדי שאני מנהל את ההרכבה חזרה.
המערכת שאליה אני פונה מכילה קוד בטכנולוגיות שאני לא מכיר, אבל יש לי גישה לקוד שלהן. אז ניגשתי וגיליתי גם שם מספר דברים שאפשר לשפר.
למשל היה שם קוד שחיכה לפחות פעם אחת כ500 מילי שניות לתהליך להסתיים ובמידה ולא, היה עושה לולאה לבדיקה שכל סיום לולאה במידה והתהליך לא הסתיים, ישן עוד כ500 מילי שניות, ואפשר להבין כי זה צוואר הבקבוק האמיתי.
למרות שאין לי ידע או ניסיון בשפת התכנות המדוברת, שלא לדבר על הספריות, החלטתי לשכתב את הלוגיקה הזו.
יצרתי סוג של טיימר הסופר עד כמות מסויימת של מילי שניות ובמידה והגיע אותו timeout לפני שהתוצר הסתיים, הייתי מדווח שגיאה חזרה.
במידה והסתיים, המידע המתאים נשלח כי הוא התקבל חזרה, ובטיימר לא היה באמת sleep כלשהו אלא תפיסה של "אירועים" על ידי שיחרור מיוטקסים או לחכות לmutex מסוים להשתחרר. הידע מתי לשחרר אותו התבצע על ידי שמירת ה payload שמגיע בstreaming pipe עד אשר תו מסויים מגיע, או אורך מסוים הגיע (הראשון מבניהם). במידה ועד שזה מתבצע הגיע הזמן לשחרר, אז mutex אחר שספר ticks פעל כאשר הבדיקה היתה על אחד משניהם.
כמובן שזה נעשה בטרדים נפרדים, אבל הם ניהול זיכרון "בטוח", שבו יש מנהל אחד שמאפשר כל פעם לתפוס mutex של קריאה וכתיבה בזמן שכאשר הmutex תפוס לכתיבה, הוא חוזר חזרה, אך לקריאה הוא מחכה לשחרור.
לאחר השינוי הזה, המערכת התחילה לחזור אלי לרוב אחרי 10-200 מילי שניות, כאשר 500 מילי שניות היו לתוכן גדול בהרבה ממה שאותו משרד ממשלתי שולח אלי.
גרמתי למערכת לרדת לפעמים לפחות מ10 מילי שניות כאשר מקודם לכן הממוצע הנמוך עמד על 500 מילי שניות והגבוה על 700 מילי שניות.
למזלי, כל הנוגעים בדבר היו מאוד סבלניים עם הבעיה וזה קנה לי את השקט לפתור את הדברים במספר ימים, כלומר לבחון, להבין ולחפש פתרונות.
עכשיו צוואר הבקבוק האמיתי של המערכת שלי הוא תשתית, כלומר עמידה בכמות תעבורה מסויימת וזה כבר עולם לגמרי אחר.
Recent focus on development & testing yielded with new orchestrator environments and offerings for developers and with increased reliability and trust. This post illustrates the new changes, and see Developers section on the official documentation for more details.
In the past four years orchestrator was developed at GitHub, and using GitHub’s environments for testing. This is very useful for testing orchestrator‘s behavior within GitHub, interacting with its internal infrastructure, and validating failover behavior in a production environment. These tests and their results are not visible to the public, though.
Now that orchestrator is developed outside GitHub (that is, outside GitHub the company, not GitHub the platform) I wanted to improve on the testing framework, making it visible, accessible and contribute-able to the community. Thankfully, the GitHub platform has much to offer on that front and orchestrator now uses GitHub Actions more heavily for testing.
GitHub Actions provide a way to run code in a container in the context of the repository. The most common use case is to run CI tests on receiving a Pull Request. Indeed, when GitHub Actions became available, we switched out of Travis CI and into Actions for orchestrator‘s CI.
Today, orchestrator runs three different tests:
To highlight what each does:
Based on the original CI (and possibly will split into distinct tests), this CI Action compiles the code, runs unit tests, runs the suite of integration tests (spins up both MySQL and SQLite databases and runs a series of tests on each backend), this CI job is the “basic” test to see that the contributed code even makes sense.
What’s new in this test is that it now produces an artifact: an orchestrator binary for Linux/amd64. This is again a feature for GitHub Actions; the artifact is kept for a couple months or so per Actions retention policy. Here‘s an example; by the time you read this the binary artifact may or may not still be there.
This means you don’t actually need a development environment on your laptop to be able to build and orchestrator binary. More on this later.
Until recently not formalized; I’d test upgrades by deploying them internally at GitHub onto a staging environment. Now upgrades are tested per Pull Request: we spin up a container, deploy orchestrator from master branch using both MySQL and SQLite backends, then checkout the PR branch, and redeploy orchestrator using the existing backends — this verifies that at least backend-database wise, there’s not upgrade errors.
At this time the test only validates the database changes are applicable; in the future this may expand onto more elaborate tests.
I’m most excited about this one. Taking ideas from our approach to testing gh-ost with dbdeployer, I created https://github.com/openark/orchestrator-ci-env, which offers a full blown testing enviroment for orchestrator, including a MySQL replication topology (courtesy dbdeployer), Consul, HAProxy and more.
This CI testing environment can also serve as a playground in your local docker setup, see shortly.
The system tests suite offers full blown cluster-wide operations such as graceful takeovers, master failovers, errant GTID transaction analysis and recovery and more. The suite utilizes the CI testing environment, breaks it, rebuilds it, validates it… Expects specific output, expects specific failure messages, specific analysis, specific outcomes.
As example, with the system tests suite, we can test the behavior of a master failover in a multi-DC, multi-region (obviously simulated) environment, where a server marked as “candidate” is lagging behind all others, with strict rules for cross-site/cross-region failovers, and still we wish to see that particular replica get promoted as master. We can test not only the topology aspect of the failover, but also the failover hooks, Consul integration and its effects, etc.
There’s now multiple options for developers/contributors to build or just try out orchestrator.
As mentioned earlier, you actually don’t need a development environment. You can use orchestrator CI to build and generate a Linux/amd64 orchestrator binary, which you can download & deploy as you see fit.
I’ve signed up for the GitHub Codespaces beta program, and hope to make that available for orchestrator, as well.
orchestrator offers various Docker build/run environments, accessible via the script/dock script:
alpine linuxThis is the orchestrator amusement park. Run script/dock system to spawn the aforementioned CI environment used in system tests, and on top of that, an orchestrator setup fully integrated with that system.
So that’s an orchestrator-MySQL topology-Consul-HAProxy setup, where orchestrator already has the credentials for, and pre-loads the MySQL topology, pre-configured to update Consul upon failover, HAProxy config populated by consul-template, heartbeat injection, and more. It resembles the HA setup at GitHub, and in the future I expect to provide alternate setups (on top).
Once in that docker environment, one can try running relocations, failovers, test orchestrator‘s behavior, etc.
GitHub recently announced GitHub Discussions ; think a stackoverflow like place within one’s repo to ask questions, discuss, vote on answers. It’s expected to be available this summer. When it does, I’ll encourage the community to use it instead of today’s orchestrator-mysql Google Group and of course the many questions posted as Issues.
There’s been a bunch of PRs merged recently, with more to come later on. I’m grateful for all contributions. Please understand if I’m still slow to respond.
במרץ ואפריל, ביחד עם משבר הקורונה, אנשים רבים גילו כי לצד העבודה מהבית הרישיון לתוכנות ה-GIS שלהם נשאר במשרד. סדנאות ה-QGIS שלנו מיועדות למי שרוצה להשתחרר ממגבלות עולם ה-GIS הקנייני ולעבוד עם תוכנה ללא מגבלות על שימוש והתקנות וזאת מבלי לוותר על יכולות של התוכנה.
לצד סדנה בהתאמה אישית לארגונית (דרך zoom בתקופת הקורונה) המאפשרת גמישות מקסימלית של התכנים, אנחנו מפעילים סדנאות חודשיות עם תוכן קבוע. סדנאות QGIS שלנו במאי 2020:
סדנאות המבוא מיועדות לאנשים שרוצים לעבוד עם מפות ולבצע ניתוחים מרחביים במסגרת תחומי העיסוק שלהם: כלכלנים, מהנדסות, אדריכלים, מתכננות ערים, אקולוגים, ארכיאולוגיות, גיאולוגים ועוד. הן מיועדת גם למי שלא מכיר GIS או מכיר ברמה בסיסית.
ניתן להשאיר פרטים בטופס ההתעניינות ונחזור אליכם עם פרטים וכיצד להרשם או להצטרף לניוזלטר החודשי שלנו כדי לקבל עדכונים על סדנאות עתידיות.
שלום לחברי וחברות עמותת המקור,
בתאריך 26.4.2020 בשעה 19:00 תכונס אסיפה כללית של עמותת המקור – עמותה ישראלית לתוכנה חופשית וקוד מקור פתוח (ע"ר).
בשל המצב הנוכחי ובהתאם להנחיות, אסיפת העמותה תתבצע באמצעות שיחת וידאו מלווה בצ׳ט. פרטים טכניים על אופן ההתחברות לשיחה ישלחו בהמשך. יש לוודא יכולת השתתפות הכוללת וידאו טרם תחילת האסיפה, לא תתאפשר הצבעה ללא הזדהות ויזואלית.
על סדר היום:
בשל העיכוב בהכנת הדוחות לשנת 2018 והצורך לאשר אותם בהקדם, החליט ועד העמותה כי האסיפה תכונס כעת לאישור של דוחות אלו בלבד. טיוטות הדוחות עצמם יועברו לעיון החברים לפני האסיפה. אנו מקווים שדיון עליהם יתקיים בפורומים של העמותה באופן כתוב לפני האסיפה, משיקולי הנגשה ואסינכרוניות גם יחד. אם יהיה דיון באסיפה הוא יתקיים בצ׳ט, אך הצבעות יתקיימו בוידאו משיקולי זיהוי. כמובן, בעקבות זאת, כל ההצבעות יהיו גלויות.
אנו בעיצומן של העבודות להכנת דוחות 2019. לאחר שדוחות אלו יהיו מוכנים, תכונס אסיפה נוספת לאישורם, שתכלול גם בחירות למוסדות העמותה ונושאים נוספים.
במידה ובמועד שנקבע לא יהיה קוורום של חברי האסיפה (רבע מכלל חברי העמותה), האסיפה תדחה בשעה ותתקיים באותו מקום, בכל הרכב שהוא. חברים שלא יכולים להשתתף במועד שנקבע, רשאים להפקיד יפויי כוח חתום בידי חבר עמותה אחר, בו הם מפרטים כיצד בכוונתם להצביע בסוגיות שעל סדר היום.
האסיפה פתוחה גם למי שאינו חבר עמותה, אך זכות ההצבעה תינתן רק לחברי עמותה. במידה ואתם כיום חברי העמותה ומעוניינים להפסיק את חברותכם, אנא שלחו על כך הודעה בכתב לכתובת board@hamakor.org.il בטרם האסיפה, כדי שלא נידרש לספור אתכם במניין הדרוש לקוורום. במידה ואתם לא חברים ורוצים להצטרף, נשמח מאוד — אנא פנו לועד ובקשו זאת, כפי שמתואר בעמוד ההצטרפות לעמותה.
חברי העמותה אשר לא שילמו את חובותיהם בגין דמי החבר בשנים האחרונות יקבלו בימים הקרובים הודעה אישית המפרטת את חובם לעמותה. נודה מראש על טיפול בתשלום החוב לפני כינוס האסיפה.
בכנס אייקון 2019 נתתי הרצאה על השורשים הבודהיסטים וטאואיסטים של מסדר הג'די מסדרת סרטי מלחמת הכוכבים. ההרצאה ההיא לא הוקלטה אבל בצוק העיתים וברוח הנדיבות עשיתי שחזור שלה בזום עם כמה א.נשים אמיצים והנה התוצאה לפניכם.
בהרצאה משולבים מספר קטעים קצרים (לצד הסברים שלי) מסדרת הסרטים והזכויות להם שייכים כמובן לחברת דיסני. השימוש בקטעים הוא לצרכי ביאור ונעשה בהבנה שהשימוש נופל תחת החרגת השימוש ההוגן של חוק זכויות היוצרים הישראלי.
מעבר לכך בסוף ההרצאה יש קטע בונוס מיוחד – גילוי של גלגולו הנוכחי של יודה, כאן ועכשיו!
תהנו!
After two years at noris network AG, yesterday was my last day with this company. It has been a long time since it felt so hard leaving a company. In my two years I worked with really great people on some of the most cutting edge technologies. All these things were not possible without the help of so many great people with whom I worked with. Some of them might read this post, so here is a big thanks. I wanted to summerize my two years and gather all the lessons I learned in one place for my future self and others too. It's quite hard summerize such an eclectic post. It's been a wild ride in noris network with lots of new technologies and ideas. We have had a lot of success. I would like to think that a great part was because we opted to work in an open source matter, even thougah not all our projects where open source. This blog post is a summary of the good things we did, and the positive leasons we learned. I hope reading through these will inspire you to choose a similar path. continue reading...
חלפה למעלה משנה מאז שהתמיכה ב-7.0 php הופסקה, וזה הזמן לשדרג את הבלוג לגרסה 7.4. כרגיל, צריך לקרוא את כל ה breaking changes, אבל אם הבלוג והתוספים מתוחזקים לגרסה העדכנית ביותר, אפשר לסמוך בדרך כלל שהכל יעובד. גיבוי של הקוד והדאטה רצוי גם כן.
את הגיבויים אני מבצע לאחרונה בעזרת restic, כאשר הקבצים מועלים לאכסון (הזול יחסית) של Backblaze B2.
אחרי שמכניסים את הגדרות ל restic למשתני סביבה, סקריפט הגיבוי פשוט למדי:
#!/bin/bash
d=$(date +%Y-%m-%d)
mysqldump -u *** -p *** > ~/backup/sql/yehudab-${d}.sql
gzip ~/backup/sql/*.sql
tar -czf ~/backup/site/yehudab.com-${d}.tar.gz yehudab.com
restic backup ~/backup
לצורך השדרוג, עקבתי אחרי המדריך ב CloudBooklet. מכוון שאני מריץ php דרך ngnix, ביצעתי את הסעיפים הרלוונטים לגרסת fpm.
אה, וכמובן, להשתמש ב vi, כי nano זה לחלשים.
אחרי השדרוג, אני מנסה לשמור את הפוסט הזה ובום error 500. בדיקה מהירה בלוג של nginx על השרת מגלה ששכחתי להתקין את php7.4-memcache שהמדריך הנ"ל לא מחשיב כ common extension. הרצת:
sudo apt install php7.4-memcache
וריסטרט לשרת פתרו את הבעיה.
You probably are familiar with the phenomenon of students, who pay other people to write term papers, theses and projects for them to submit in order to meet academic requirements.
Few years ago, a computer science student named R. (a pseudonym) approached me and asked me to write for him and his partner a computer program, so that they will submit it to meet a requirement in order to pass a course, which they were studying.
I am approaching your question from the point of view of a mentor, teacher or a wise person needing to advise a young person, who is in a difficult situation and who is considering a bad solution to his problem. What the young person really needs is not to have someone else do his project for him, but long-term thinking: what are the long-term consequences of this solution, what alternative solutions exist, which obstacles exist in the alternatives, how to overcome those obstacles, the need to summon courage to change course.
For starters, as far as I am concerned, what you asked for is in the grey area between cheating and having an original solution to the problem. This is because certificates are not worth that much in the vocation of software development. Either the developer knows how to program or he doesn’t know, no matter what degrees or impressive certificates he has. If he does not know how to program, then within half a year his employer, if the employer has a clue, knows about it, and gives him a kick in the ass – reducing the long-term damage. Also, there are several people, who take on big projects and hire other people to do the actual work. However, the difference is that they have to provide the project with services such as marketing skills, project management, search and selection of development tools, money handling, etc. – instead of (or in addition to) software development skills.
Now to the point. Before proceeding further with what you and your partner are contemplating doing – I highly recommend that both of you read Ayn Rand’s “The Fountainhead” and follow Peter Keating’s career development in the book. He started out relying upon other people, like you are contemplating doing, made an impression on the right people and reached the top of his profession.
But… he didn’t last long and eventually he fell. And the sad truth is that he trained for the wrong vocation. There was a vocation that suited him perfectly, and he could really excel at it, but his mother pressed him to learn the vocation he actually learned (and in which he eventually failed). The saddest thing about his story is that when he realized which vocation is right for him and started engaging in it – it turned out that he started it too late and could not reach a high level of proficiency in that vocation.
If you and your partner decide to pay someone else to do your project, then:
I suggest that you first carefully review the decisionmaking process that led you to decide on a vocation in the software world. If you have taken psychotechnic tests and consulted with a specialist in the area of vocational selection, one of the tests was probably as follows:
Why am I telling you all this? Because if you kept the papers from your evaluation (or you can get them), you might find there a clue for identifying a vocation, which really attracts you and in which you can excel.
The next step is to determine if you have relatives, who are unwilling to accept that your future is not in the lucrative and profitable software world, but in another direction. Then check if and how to neutralize their influence upon your choice of the vocation that fits you.
I assume that the computer world is appealing to you, so you may want to check out some other vocations in this world besides writing software (I remember that in Hadassah Institute for Professional Selection Counseling in Jerusalem, where I did my vocational counselling, there was a library with descriptions of thousands of vocations – such a library could help you choose the right vocation for you). Examples: training, installation and configuring, software testing, maybe even administrative project management. Then go on to specialize in the vocation that suits you and in which you can excel.
True, you already started studying and already invested two years in your studies, and now I am proposing to write off all this investment and start over? Yes, however as far as getting a certificate or a degree is concerned, some of the investment will probably be lost. But as I said above, certificates are not that valuable in the software world. Like a pilot’s license does not turn someone, not having the aptitude to pilot, into an ace fighter pilot; also a software developer’s certificate does not turn someone not fit to be software developer into a great software developer. In terms of content – I’m sure you’ve learned something that will help you in any direction you choose for the rest of your life. And as far as the requirements for finishing your studies are concerned, once you know which direction is right for you, you probably can switch to a major which fits your vocational goals. In this case, you’ll probably be able to use some of the credits of the courses that you already completed. So what you already studied is not a total loss.
A student, who is paying someone else to do his homework, term papers, projects or theses, is like a basketball player who is paying someone else to go to his team’s practice sessions.
Mr. Magoo is an old cartoon character famous for his inflated sense of status and an extreme case of myopia, made worse by his refusal to wear corrective glasses. As a result of his poor vision and ego, Magoo would find himself in precarious — and hilarious — situations because he was unable to see the danger right in front of him. Typically, the oblivious Magoo would leave a trail of destruction behind him..
Enterprises today approach security a lot like Mr. Magoo, operating with the idea that they are more important than they really are and therefore are unable to see the real risks that beset them. The result? A lot of unnecessary damage.
Read the full article at Forbes here
לאחר 16 שנים של פעילות שהתבססה כולה על מתנדבים, ולאחר שנים של גידול משמעותי בפעילות העמותה, הגיעה העת לצמוח לשלב הבא. עמותת המקור שמחה להודיע על העסקת עובד ראשון – מנכ"ל העמותה הנכנס, סחף קדוש.
במסגרת תפקידו סחף יטפל בחלק ניכר מהתפעול השוטף של העמותה, יקח חלק פעיל בהפקת הכנסים והאירועים השונים המתקיימים במסגרת העמותה, יוציא לפועל מהלכים אסטרטגיים, ויסייע לנו להתפתח ולצמוח כקהילה ולהתקדם לעתיד משמעותי יותר בקידום הקוד הפתוח והתוכנה החופשית בארץ.
וכעת ניתן לו להציג את עצמו:
שלום לכל חברי וחברות המקור,
שמי סחף קדוש, ואני התמנתי בימים אלו למנכ"ל העמותה.
קצת עליי – בן 28 מראשון לציון, בעברי סמנכ"ל אגודת הסטודנטים של המכללה למנהל (עמותה), סמנכ"ל חברה קבלנית, וגיק מושבע.
בוגר תואר ראשון במשפטים, ולפני בחינות הסמכה לעריכת דין.
מקווה כי אוכל לתרום מנסיוני למען העמותה בפרט ולמען קידום הקוד הפתוח והתוכנה החופשית בכלל.
אשמח לעזרתכם וכאן למענכם, סחף.
During the last several years, personal computers and smartphones became capable of displaying the local time, correctly adjusted for daylight saving time (DST) – and without requiring human intervention beyond selecting the correct timezone.
Nowadays, there are also some IoT devices, which need to support local time management – displaying it, or otherwise making it available.
Timekeeping is performed using the Internet protocol NTP, which provides the correct UTC. When using a PC or a smartphone, the timezone is usually selected by manual user action.
However, some IoT devices may not have the UI needed for convenient timezone selection. Then it is desirable to support automatic timezone selection as a default.
There are some websites, which discover your IP address and provide you with the best guess of your timezone.
Since those websites usually provide the timezone name rather than the string describing the DST transition dates (the so-called tz_string), the next step is to figure out the DST transition dates from the timezone name.
In devices with plenty of memory this is carried out by means of a timezone database.
For example, in Debian/Ubuntu based systems, this database is stored in the /usr/share/zoneinfo directory and occupies 3.5MB (the relevant package in Ubuntu 18.04 is tzdata and its version, as of Nov. 2019, is 2019c-0ubuntu0.18.04).
However, IoT devices are typically based upon memory-constrained controllers and cannot afford to store locally the whole timezone database – just to correctly determine the local time for a single timezone.
Therefore, IoT devices need to access an Internet based service to get the correct timezone information, just as they get UTC time updates using NTP. In other words, those IoT devices effectively outsource the timezone database management.
An Internet service, for providing the correct tz_string corresponding to a timezone name, needs to keep the timezone database up to date at all times.
I implemented the internet service as follows.
The GitHub project tddpirate/tzdata2tzstring includes redacted versions of both an implementation of the above website and a sample ESP8266 client.
I wish to thank the Python Israel Telegram group members for advice about selecting a Python WSGI framework. I ended up selecting Falcon because benchmarks indicated that it is faster than Flask and Bottle.
The members of the לינוקס Telegram group deserve thanks, too. They helped me find the mechanism for appending my own postprocessing scripts after a Debian/Ubuntu package installation or upgrade.
It is a very bad idea to run database (especially production one with lots of I/O) on BTRFS because the filesystem at any random time might become readonly:
Oct 24 12:30:22 db02 kernel: BTRFS: error (device nvme0n1) in btrfs_run_delayed_refs:2936: errno=-28 No space left
Oct 24 12:30:22 db02 kernel: BTRFS info (device nvme0n1): forced readonly
As I write these pieces for Forbes Tech Council, I’ve tried to chip away at the Hollywood reputation that hackers have been given over the years. That reputation often keeps people from making good decisions about how to protect their networks and data, keeps people focused on the wrong security priorities, and causes people to give up before the game is over.
It’s important to keep in mind, however, that while criminal hackers may be smart and devious, they are also, in a sense, entrepreneurs who are in the game to make a quick buck. As such, they realize that hacking costs money and so they will do what they can to keep their operating costs low. Why, then, would you expect a criminal hacker to expend time and money developing specialized tools when there are easier ways to get to what they want?
Read the full article at Forbes here
בתקופה הקרובה אני מתכוון לכתוב סדרת מדריכים בנוגע להתקנת Arch Linux. בהסברים אתייחס להתקנות במצבים השונים: התקנה בסכימת מחיצות MBR או GPT והתקנה תחת Legacy Bios או UEFI, אז כדי שההסברים העתידיים יהיו ברורים אקדים ואסביר אה המונחים הללו (שאצל רבים לא ממש ברורים)
אתחיל בהסבר על GPT ו- MBR:
מדובר בשתי דרכים שונות להגדיר את מנהל האתחול ואת טבלת המחיצות (Partitions) בדיסק הקשיח. ה- MBR-Master Boot Record היא השיטה הישנה והמסורתית בה הביוס פונה לאזור שבתחילת הדיסק הקשיח, קורא את מנהל האתחול (446 בתים ראשונים בדיסק), קורא את טבלת המחיצות שמוגדרת אח"כ (64 בתים), ואז טוען את מערכת ההפעלה (באמצעות מנהל האתחול) מהמחיצה המסומנת כ- Active. בשיטה זאת ניתן להגדיר עד 4 מחיצות ראשיות (Primary Partition). במידה ומעוניינים בעוד מחיצות, ניתן, על חשבון מחיצת Primary Partition אחת, להגדיר עוד 23 מחיצות לוגיות (באזור שנקרא Extended Partiton). לפיכך MBR תומך בעד 26 מחיצות – כמספר האותיות האנגליות. שימוש ב- MBR, מעבר להגדרה המוזרה של המחיצות, מגביל אותנו להשתמש בדיסקים בגודל של עד 2 טרה בייט, אין לו שרידות של טבלת המחיצות ולא מתבצעת בדיקת של שלמות ונכונות הנתונים שלה (משמש מצע טוב ונוח להידבקות בוירוסים).
טכנולוגיית GPT נותנת מענה לחסרונות של MBR: היא תומכת בדיסקים הגדולים מ- 2TB (תמיכה בעד 9.4 מיליארד טרהבייט), היא לא מוגבלת (תאורטית) בכמות המחיצות ואין בה הפרדה ל- Extended Partition ו- Logical Devices. טכנולוגיית GPT שומרת 2 העתקים של טבלת המחיצות ומבצעת עליהם בדיקת CRC, ובמידה וטבלת מחיצות אחת משתבשת היא משחזרת אותה מהגיבוי. GPT מהווה שדרוג של ממש ל- MBR ואני לא מוצא שום היגיון להשתמש כיום ב- MBR בהתקנה של מערכת הפעלה חדשה.
אמשיך בהסבר על Legacy Bios ו- UEFI bios. אז כמו שכתבתי: שניהם מהווים את הביוס של המחשב. מדובר באותו רכיב קושחתי שמתווך בין מערכת ההפעלה לחומרת המחשב. כשמדליקים את המחשב הרכיב הראשוני שנטען זה הביוס. הוא זה שמבצע את בדיקת ה- POST, מאפשר להיכנס ולערוך את ההגדרות שלו, לבדוק את זיהוי החומרה ולשנות ערכים שונים (נניח לשנות את קצב השעון עבור ביצוע over clocking, לשנות את המתח שמזינים את זכרונות ה- RAM ועוד…). לאחר הבדיקות העצמיות של החומרה, הביוס ניגש לדיסק הקשיח ומעביר למנהל האתחול את המשימה של טעינת מערכת ההפעלה. אבל כאן לא נגמרת פעילותו. כשמערכת ההפעלה עובדת והיא, למשל, צריכה לכתוב מידע לדיסק הקשיח, היא תעביר את הבקשה (דרך הקרנל של מערכת ההפעלה) לביוס והוא זה שיפנה בפועל את הבקשה לבקר שבדיסק הקשיח. אז במחשב, כפי שניתן להבין, הכל עובר ועובד דרך הביוס!
קיימים כאמור שני סוגים של ביוס: ה- Legacy Bios הוותיק שמאופיין במסך טקסטואלי (בדרך כלל רקע כחול וטקסט לבן או צהוב). לעומתו ה- UEFI Bios, שאמור להחליף אותו, הוא בעל ממשק גרפי יפה ומודרני (מכיל תמיכה בעכבר, אנימציות של מאוורררים מסתובבים, מדי חום גרפיים ועוד). UEFI טוען את מערכת ההפעלה מהר יותר, הוא גמיש יותר (ניתן לספק לו דרייברים נוספים במדיית ההתקנה) והוא זקוק למחיצה נפרדת בה הוא שומר את קבצי הקונפיגורציה ומנהל האתחול.
תאימויות:
מערכת הפעלה חלונות תומכת בסכימת מחיצות GPT רק אם משתמשים ב- UEFI. בלינוקס אין מגבלה כזאת: היא תומכת בסכימת מחיצות GPT גם ב- Legacy וגם ב- UEFI
אני מקווה שההסבר הקצר הזה עשה לכם סדר בראש והרקע הזה יעזור לכם להבין את פרוצדורות ההתקנה השונות שאדגים ב Arch
מי שעוקב אחרי הבלוג שלי יודע שעברתי להשתמש ב- Arch Linux . אז נכון: Arch זאת הפצת Bleeding Edge (רחוקה מאוד ממודל ה- LTS השמרני של Ubuntu לא כל שכן מדביאן היציבה). מסיבות שונות נמנעתי בעבר מלהשתמש בה, אך עם פיתוח כלים נוחים לביצוע Snapshot (כגון Timeshift, CYA או אפילו Snapshot ברמת LVM), כבר לא צריך להיות קיים החשש של "מה יקרה אם…" (במקרה הכי גרוע מבטלים את העדכון האחרון וממשיכים הלאה).
ממשק ההתקנה של Arch אינו פשוט למתחילים, אבל כמי שביצע לא מעט התקנות, אני יכול להעיד שבסך הכל הוא מאוד פשוט ואינטואטיבי: עוקבים אחר ההוראות (הברורות בד"כ) עד שמסיימים לבנות את שולחן העבודה.
אחד היתרונות הגדולים של Arch הן אפשרויות הבחירה: לא בוחרים עבורך את שולחן העבודה או את האפליקציות איתן תעבוד. אתה צריך לבחור הכל, ובכך אתה בונה לעצמך את שולחן העבודה האולטימטיבי. ב- Arch כמעט ולא עושים החלטות עבורך: בחרת Gnome תקבל Gnome טהור – ללא שום קוסטומיזציה של ההפצה (כנ"ל בכל שולחן עבודה אחר שתבחר). אתה צריך להפשיל שרוולים ולייפות בעצמך את שולחן העבודה: לבחור פונטים יפים, לבחור בערכת נושא ואייקונים הקולעים לטעמך, אך גם אם תעשה את כל הפעולות הללו, עדיין תצטרך לטפל בבעיות "פינתיות" (למשל שאפליקציות QT לא יראו טבעיים בשולחנות עבודה מבוססים GTK). בהתחלה יהיו לך כמשתמש לא מעט נושאים לטפל בהם אבל פה היתרון הגדול: אפשרויות הלימוד שלך כמשתמש הן עצומות. ל- Arch יש WIKI נפלא, בעיני הטוב ביותר מכל הפצות הלינוקס, ודרכו אתה יכול ללמוד המון על לינוקס ועל Arch. ההפצה מאפשרת לך כמשתמש להינות מחבילות התוכנה העדכניות ביותר (ועדיין מאפשרת לשמרנים מבינינו לבחור בקרנל LTS וב- OpenOffice LibreOffice Still). כיום Arch די יציבה. אני נוהג לעדכן את ההפצה אחת לשבוע (sudo pacman -Syu). לא הייתי ממליץ לעדכן את ההפצה באופן יומי וגם לא לעדכן אותה אחת לפרק זמן ארוך מידי… בכל יום שישי אני מבצע Snapshot ואז מעדכן אותה. בינתיים Arch לא "נשברה" לי אפילו פעם אחת, אבל גם אם כן אוכל לתקן זאת בקלות.
להשתמש באובונטו זה משעמם! כתבתי להשתמש וזאת המילה הכי נכונה ומדוייקת (כי חוץ מלהשתמש בהפצה אתה בדרך כלל לא צריך לעשות כלום…).
הערה: עם יציאתי לפנסיה , התפנה לי זמן ואני מכשיר אנשים לעבוד עם לינוקס (הדרכה שמותאמת לרמות שונות – הכל לפי בקשת הלקוח). לפרטים נוספים היעזרו בפרטי הקשר שלי כאן.
This is a short tutorial on how to build a data source for Grafana using Python Bottle micro-framework. Eventually, you can use this code to connect to any database (including SQLite). continue reading...
לאחר הפסקה לא קצרה עקב שחיקה, חזרתי לתרגם את Django עם שחרור 2.2 RC1. נכון ליום שלישי ה־19 במרץ התרגום עומד על 100% עבור:
נשארו בחוץ, שוב, עקב חוסר זמן והיקף המשימה:
Collection of links to emails, articles and posts about Linux Kernel CoC situation arranged by date.
Examples of several wrong ways to make your app secure
RealtimePi logo
Hey all,
So it started as a curiosity, and it looks like its working. I made a Raspbian-based distro that ships with a realtime kernel called RealtimePi. You can download the latest here. It’s open source, sources are here.
A realtime system means its deterministic, it means you should know how long things take to run. They way to do is is to apply a patch to the linux kernel that makes it non-preemptible. To explain – Preemption is the act of temporarily interrupting a task being carried out by a computer system, without requiring its cooperation, and with the intention of resuming the task later.
This is useful for building hardware and robotics, low latency audio and other gpio because there are no surprises when it comes to timing. It seems like something good to try out with the RaspberryPi, because of the GPIO and IOT capabilities.
Bundled with CustomPiOS you can build your customized realtime-kernel device.
You can test the realtime kernel is enabled, by running in the commandline
uname -a
You should see something like this, note PREEMPT RT which indicates its realtime:
Linux realtimepi 4.9.52-rt37 #1 PREEMPT RT Fri Oct 6 22:29:28 UTC 2017 armv6l GNU/Linux
The line should look a little different for armv7
I am not an expert with actually building realtime systems, so input on how it preforms, and examples would be appreciated!
את היום הראשון של הכנס פתחתי כרגיל בדוכן הרשמה (front desk) והייתי שם עד הצהרים כדי שהצוות ירשום את הגל אנשים שהגיעו.
לצערי הכנסים של דביאן נפתחים מאוד בעצלתיים מבחינת תוכן – יש הרצאת/טקס פתיחת ואחרי אין ישר רצף גדול של הרצאות אלא טפטוף קטן של נושאים והרצאות. קצת מאכזב מבחינתי. ומצד שני, אפשר לי להתחיל לעבוד על החבילות של עברית בדביאן בלי לדאוג לפספס תוכן כלשהו. אבל לפני שאפשר לעבוד על החבילות, צריך לייצר סביבה מתאימה. לקח לי זמן להוריד חלודה לגבי מה צריך, ואיך לייצר משהו שיודע לבנות בתוך chroot (גם כדי שהבניה תהיה נקייה, וגם כי אני משתמש ב-testing בעוד שהבניה נעשית ב-unstable). בעזרת כמה תזכורות מ-Bálint הכל הסתדר, ויש סביבה עובדת עם sbuild.
השלב השני היה להתחיל להמיר את ההיסטוריה של הצוות מ-SVN ל-GIT ואז לדחוף את זה לשרת ה-GitLab החדש של דביאן. עשיתי את זה בנפרד עבור כל חבילה, כאשר הראשונה בתור היא Hspell כי צפריר הספיק להכין את הרוב מראש. ואחר כך עבדתי על המרת Culmus כי לא הייתי רוצה שהגרסה הבאה תצא בלי פונטים בעברית (על הדרך כבר הועלתה גרסה 0.132). כל המאגרים זמינים תחת Debian Hebrew Packagers בכתובת https://salsa.debian.org/hebrew-team . למי שצריך לעשות משהו דומה, הכלי להמרה היא git svn clone ואפשר להשתמש בהוראות שיש באתר git-scm.com בכתובת https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git . על בסיס הפקודות שלהם עוד עשיתי כמה שינויים קלים, אבל החלקים החשובים נמצאים שם.
בין לבין שמעתי את הדיווח השנתי של Chris Lamb במסגרת תפקידו כ-Debian Project Leader. בין השאר גיליתי שם כי דביאן תחגוג השנה יום הולדת 25 באמצע אוגוסט, וישר החלטתי לפתוח event כדי לחגוג עם עוד אנשים. נתראה שם בקרוב (: בנוסף, גיליתי כי המעבר של דביאן ל-GitLab נובע בין השאר גם מהשינוי שלהם בנושא ה-Content License Agreement ושינוי ל-Developer Certificate of Origin מה שמאפשר ליותר אנשים לתרום קוד בלי לוותר על הזכויות שלהם או לקרוא מסמך משפטי כבד. שאפו ל-GitLab, ואיזה כיף לעבור לעבוד במערכת מתקדמת.
הכנס השנתי של דביאן, Debconf, מתקיים השנה בפעם הראשונה באסיה (Hsinchu, Taiwan). הישג מכובד לאחר שנים של אירופה / ארה"ב ולפעמים דרום אמריקה. וגיוון מבורך בהמשך לכנס בדרום אפריקה לפני שנתיים. כלומר הפעם טסים לכנס מזרחה ולכן גם כולם סובלים מג'ט לג חמור יותר. לצערי זה גם גרם לי לתרום הרבה פחות בדוכן הרשמה (front desk) למרות שזה אחת ההתנדבויות הקבועות שלי.
היום הפתוח התנהל בחלקו בסינית, כך שאפילו לא ניסיתי ללכת להרצאות (גם לבודדות שהיו באנגלית), ובמקום זה התמקדתי בקצת שיחות עם אנשים (למרות העייפות). הספקתי לדבר עם Bálint Réczey שעובד עבור Canonical בצוות Ubuntu Foundation שאחראי על הסנכרון עם דביאן והתרומה של שינויים לקהילה. גם ניצלתי את ההזדמנות כדי לשמוע באיזה כלים הם משתמשים בפעילות, כדי לתזכר את עצמי. אחרי כמעט שנה שלא נגעתי בחבילות, אני בהחלט חלוד (וגם צריך לסדר את סביבת העבודה על המחשב). אגב, קנוניקל מחפשים אנשים עובדים, אם מישהו מתעניין, צרו קשר בפרטי (יש אפשרות לעבוד מרחוק, ואוכל לעזור בסידורים הנדרשים).
בהמשך הערב ישבתי על באג שדיווח לקוח על פיצ'ר של PHP שלא עובד לו מול OpenSSL. תפסתי את Kurt Roeckx שאחראי על החבילה בדביאן וגם עושה עבודת upstream בכמה שנים האחרונות כדי לבדוק את הנושא. אחרי קצת שאלות מולו ובדיקות שלי הסתבר שהבעיה היא לא ב-OpenSSL אלא ב-PHP, ואחרי מספיק חיטוטים בקוד נפתח באג #76676.
לאורך היום יצא לי להכיר את הלן (Helen Koike), בחורה נחמדה שסיפרה שהיא לא מעורבת מאוד בדביאן, ובאה ללמוד קצת כי היא הולכת לעזור לצוות המארגן של שנה הבאה. תייגתי אותה כעוד מישהי שעושה עבודה כללית ולא משהו טכני (הקהילה מורכבת גם מכאלה) והמשכתי הלאה. יותר מאוחר בערב, בשיחה רנדומלית גיליתי שהיא עשתה פעילות על הקרנל במסגרת Outreachy, תרמה דריברים, עובדת ב-Collabora בצוות שמתעסק עם הקרנל וכו'. היא פשוט צנועה לאללה. ניסיתי לדחוף אותה לתרומה בצוות קרנל של דביאן והיא אמרה שהיא לא יודעת לארוז חבילות. הסברתי לה שהיא יודעת לתקן באגים בקרנל, וזה תרומה משמעותית לצוות. בנתיים מישהו אחר יכול לארוז. ויותר חשוב לתקן באגים.
במקביל, למדתי כמה מהר אנחנו מתייגים אנשים לפי המקום שנוח לנו לתייג אותם. ומצד שני, שיש אנשים (ויתכן שבעיקר נשים) שהם סופר צנועים ולא מספרים על כל הפעילות והיכולות שלהם וכך דברים מתפספסים (ברושם הראשוני ומעבר).
לסיום הערב, עשיתי תיאום עם צפריר לגבי החבילות של עברית בדביאן שדורשות תשומת לב בעקבות מהעבר מ-Alioth ל-Salsa שעל הדרך סגר את רשימות התפוצה הצוותיות וגם מכריח את כולם לעבור ל-GIT. כאשר המטרה היא לעשות את המיגרציה, לתקן את הבאגים שדווחו מולן כתוצאה מכך, שגם מונעים מהן להכנס ל-testing (ולכן לגרסה הבאה של דביאן). והדבר משמעותי, כי תהליכי ה-freeze מתחילים בספטמבר. בסופו של דבר, אני הולך להקדיש את הזמן לחבילות, בעוד שצפריר יתעסק בדברים אחרים שלו. שזה סה"כ הוגן, כי במהלך השנה לא יצא לי לתרום כלום לתחזוקת החבילות האלה.
מי שרוצה לעקוב אחרי הכנס מרחוק, אז הלוח זמנים נמצא בכתובת https://debconf18.debconf.org/schedule, רק לא לשכוח שהכנס מתקיים באזור זמן +8, כלומר 5 שעות לפני ישראל (ריאלית, אפשר לצפות בהרצאות של אחרי ארוחת הצהריים כאן, שזה 9 בבוקר בישראל).
I love using a dark theme on my system, currently I’m running the Adapta theme. But not all applications looks great in dark themes, some need tweaking, this is a quick hack to overwrite the default theme used for a specific application.
In this example I’ll be overwriting the theme for virt-manager.
First we’ll copy the default launcher/desktop file to the local dir, and then we will change that file,
sudo cp /usr/share/applications/virt-manager.desktop /usr/local/share/applications/virt-manager.desktop sudo vim /usr/local/share/applications/virt-manager.desktop
And do this small change, prefix the application Exec command with
env GTK_THEME=theme_name
--- /usr/share/applications/virt-manager.desktop 2018-02-28 22:48:50.000000000 +0200 +++ /usr/local/share/applications/virt-manager.desktop 2018-07-09 11:00:40.000000000 +0300 @@ -55,7 +55,7 @@ Comment[sv]=Hantera virtuella maskiner Comment[uk]=Керування віртуальними машинами Icon=virt-manager -Exec=virt-manager +Exec=env GTK_THEME=Adapta virt-manager Type=Application Terminal=false Categories=System;
$ openssl x509 -outform der -in certificate.pem -out certificate.crt
$ openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes
$ openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
למרות כותרת ההרצאה הפרובוקטיבית, ההרצאה שלי ב־PyWeb-IL 75 עוסקת במקרים בהם עלינו לעזוב את מחוזות ה-ORM/ODM.
מצגת ההרצאה NoORM זמינה בעמוד הרצאות ומצגות.
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):
There was some progress made this week, especially with fine tuning the letters and revising those letters I’m not so sure about.
The one letter I’m struggling with is Aleph (א), I can’t seem to find the right balance.
I got a lot of feedback and many good tips, thank you everybody 
I’m doing my best to take them all into account.
I was trying to add some Hebrew glyphs to a font file, but the free font creation programs I tried (FontForge and the Demo of TypeTool) are not so friendly, it will take some more time to do.
Links to v0.8:
PDF file
Illustrator CS4 File
I opened an issue on launchpad and it was added to the Ubuntu Font Family Wishlist queue.
As an added bonus Mark Shuttleworth himself gave his blessing to this design effort (!)
It was a fun mail to start the day with
I want to quote one thing he wrote:
It *would* be useful if you could start building up a Hebrew community that can provide early and accurate feedback to DM when they start the Hebrew design process.
And later, Paul Sladen wrote:
developing a typeface takes a very long-time (months and months), and although
work on Hebrew won’t be incorporated until the Ubuntu 11.04 development cycle,
it is very useful to start working on it now!
So, I really want to start working on it seriously (too bad I didn’t start this before August Penguin…)
This week I guess I’ll finish the initial design with the good tips I got from Paul Sladen and from Maxim Ioresh, but this is only the beginning:
A real OpenType font must be created and refined, people need to test it, to find where it breaks.
And there are more variants – we have to do the Bold font, the Italic and Bold Italic, and by the time these will be finished there most likely be some Condensed variants too… so I need designers, typographers and testers to pitch in, we have a bit more than 6 months, it’s enough, but not a lot of time for a community project.
Original post: http://tombigel.com/2010/08/26/hebrew-for-the-ubuntu-font/
This is fun! I love Open Source.
After serving in the board of a few technological Israeli associations, I decided to run as an individual candidate in the OSI board elections which starts today. Hoping to add representation outside of North America and Europe. While my main interest is the licensing work, another goal I wish to achieve is to make OSI more relevant for Open Source people on a daily basis, making it more central for communities.
This year there are 12 candidates from 2 individual seats and 5 candidate for 2 affiliate seats (full list at OSI elections wiki page). Wish me luck (:
האם אתם רוצים מערכת כזו? התשובה מורכבת.
כן, זה נחמד לשבת בעצלנות על הספה ולהגיד "הי גוגל, תדליק לי דוד", או אפילו להדליק אוטומטית את הדוד ברגע שיצאתי מהעבודה ע"י נתינת קואורדינטות של המשרד ליישומון IFTTT ולתת לו להקשיב לGPS.
לא, זה לא נחמד שכל מילה שנאמרת בבית מוקלטת ונשלחת לשרתים של גוגל או אמאזון (אלקסה) או מוקרוסופט (קורטנה) וכולי. זה גם לא חכם להשקיע בציוד שמייקר את החיים בבית והופך אותך תלוי ביצרן או משהו. למשל זו הסיבה שלא אקנה נורת פיליפס HUE בעשרות דולרים כי כשהיא נשרפת אני צריך למעשה לקנות נורה ומחשב קטן. אני מעדיף לחבר ממסרי SONOFF ולשלוט בהם בעצמי. כמו כן, אני לא אחבר בקרוב את מנעול הדלת למערכת ממוחשבת. אני לא ממליץ לסמוך עליה בנקודות אבטחה, אבל אפשר להסתפק במגע בנקודות הנוחיות.
אני לוקח רגע ומפרק מערכת ממוצעת כדי לסבר את האוזן למי שלא מכיר את הטכנולוגיה שמאחורה. בגדול יש כאן כמה רכיבי תוכנה תפורים ביחד כדי לגרום לקסם לקרות:
התכוונתי (וויתרתי בגלל סיבות) לשחק עם עוזרים חכמים פתוחים. נתקלתי באינדיגוגו של מייקרופט (גיבוי עסקי לא יכול להזיק). כמו כן גיליתי שיש פרויקט בשם Jasper שכבר לא זז שנה ועוד אחת מליסה, כנראה גם אחרים.
מה דרוש? כרגע סבלנות וחוש טכני. כמו שלא לכולם מתאים לפרמט את האנדרואיד ולהתקין LineageOS, או ללמוד לקנפג קודי, וכולי. זה פרויקט לסקרנים, עקשנים, שאין להם בעיה לבנות ולהלחים כמה דברים לבד. הנה המידע שאספתי והפרמטרים שהייתי בוחר להתחיל איתם אם הייתי הולך על הפרויקט.
קריאה לעומק של תשובות מייקרופט לתומכי הקיקסטארטר ושל תנאי הפרטיות שלהם שכנעה אותי שהם לא עומדים בדרישות הפרטיות שלי בתצורה הנוכחית שלהם. בגדול הם "מתכננים" גרסא מקומית של רכיב ה־STT (דיבור לטקסט) שתרוץ על מחשב לינוקס או חלונות אבל זה עוד לא שם, ובתלות ברכיב שיבחרו, יכול להיות שזה ידרוש GPU חזק כדי לבצע את הניתוח בצורה מהירה ככל הניתן. מנתח ה־STT הנוכחי שלהם לא מספיק טוב והחדש שיכנס בסוף החודש צריך הרבה יותר כוח מחשוב. אז כדאי לחכות. בעתיד זו תהיה אפליקציה או תמונת Docker מוכנה שנוכל להריץ על שרת PC כעזר לרספברי בלי להסתמך על שרתי החברה.
כאמור, בפוסט המקורי כתבתי שאני בודק את המערכת לביתי אבל הוטל ווטו משפחתי. אני עדיין אנסה לראות איך זה להתקין עוזר AI שכזה על הלאפטופ או הדסקטופ, ואוסיף דיווחים כשיהיו.
אני יכול להגיד בביטחון מוחלט שכ - 60% מהמשתמשים ברשת האינטרנט, מחוברים אליה דרך רשת אלחוטית כזאת או אחרת. זה כמובן מקל מאוד על תוקפים פוטנציאלים, כמעט בכל מקום היום יש רשתות WiFI פתוחות שמאפשרות גלישה חופשית ברשת, בישראל אין אוטובוס ציבורי שלא מתהדר ב - WiFi, זה נהפך להיות סטנדרט - ופה מגיעה החולשה הכי גדולה. התוקף היום יכול לשבת בנוח ולתקוף את הרשת, אף אחד לא יחשוד בבחור (או בחורה) שמשחק במכשיר האנדרואיד שלו.
Data.gov.il was created in 2011 after the Israeli social justice protests as part of the the public participation initiative and started to offer data held by the government. Back then the website was based on Drupal. In 2016 it was changed to CKAN, a designated system for releasing data. This system is licensed under the AGPLv3 requiring source code availability for anyone who can access the the system over a network, de facto for every user.
Since the change to CKAN, open source people asked the state to release the code according to the license but didn’t get a clear answer. All this time when it’s clear it’s violation. This led Gai Zomer to file a formal complaint in March 2017 with the Israeli State Comptroller. Absurdly, that same month the ICT authority mentioned a policy to release source code it owns, while failing to release code it has taken from others and adapted.
With the end of the summer break and Jew holidays, and after I wasn’t able to get the source, I decided to switch to legal channels, and with the help of Jonathan Klinger and my company, Kaplan Open Source Consulting, we notified they should provide the source code or we’ll address the court.
Well, it worked. In 3 days time the CKAN extensions where available on the website, but in a problematic way, so users weren’t able to download easily. This is why we decided not to publish this code release and let them fix it first. In addition we made it clear all the source code should be available, not only the extensions. Further more, if they already release it’s recommended to use git format instead of just “dumping” a tarball. So we told them if they aren’t going to make a git repository we’ll do that ourselves, but in any case, would prefer them to do that .
While this issue is still pending, the ICT authority had a conference called “the citizen 360” about e-gov and open government in which they reaffirmed their open source plans.
A slide about open source from the Israeli ICT authority presentation
Now, a month later, after our second letter to them, the about page in data.gov.il was updated with links to the ICT authority GitHub account which has the sources for the website and the extensions. A big improvement, and an important mark point as the commit to the repository was done by an official (gov.il) email address.
Beyond congratulating the Israeli ICT authority for their steps forward and the satisfaction of our insisting on them became fruitful, we would like to see the repository get updated on a regular basis, the code being given back to the various CKAN extensions (e.g. Hebrew translation). In general, we hope they would to get inspired by how the how data.gov.uk is doing technical transparency. If we allow ourselves to dream, we would like to see Israel becoming a dominate member in the CKAN community and among the other governments who use it.
We’re happy to be the catalyst for open source in the Israeli government, and we promise to keep insisted where needed. We know that due to other requests and notifications more organizations are on their way to release code.
(This post is a translation from Hebrew of a post in Kaplan Open Source Consulting at https://kaplanopensource.co.il/2017/11/20/data-gov-il-code-release/)
הפוסט הבא נכתב כתשובה למישהו שאמר לי “הטרמינל קורא את השורה הראשונה בקובץ (*sh), ומחליט כיצד להריץ אותו”. והאמת היא שזה לא נכון, כי הקרנל בכבודו ובעצמו מטפל בזה.
זה היה לפני 12 שנים, פעם ראשונה שהתקנתי אובנטו על המחשב שלי. אובנטו 0505. מאז עברו הרבה מאוד ביטים באינטרנטים, למדתי הרבה, אבל תמיד שמרתי חסד נעורים להפצה הלינוקס ששמה לה למטרה להנגיש את שולחן העבודה של מערכת ההפעלה הנפלאה הזו. תחילת המיליניום, היתה תקופה קשה למשתמשי לינוקס. אי אפשר היה לצפות כמעט בסרטים ברשת … להמשיך לקרוא אובנטו 1710 – גירסה ששווה להתקין
אמ;לק: סקירת מוצר שיוסיף לכם שכבת הגנה על חשבונות מקוונים וגם על המחשב האישי. זו תהיה כתבה ראשונה בסדרת פוסטים על אבטחת מידע בסיסית לישראלי המצוי, למרות שהפוסט הספציפי הזה אולי לא מיועד ממש לכולם כי הוא עוסק בחומרה יעודית שעולה בסביבות $50 (כולל משלוח) ולא תוכנה זמינה וזולה/חינם.
יותר מחצי שנה לא כתבתי פוסט, למעשה כמעט 8 חודשים אני חושב. המון חדשות חולפות בקצב מסחרר ואי אפשר להתעמק בכלום, וגם החלפת מקום עבודה מוריד מהזמן הפנוי לכתיבה של יותר מציוצים בטוויטר. אם אתם לא עוקבים, חוק הזיהוי הביומטרי עבר והחל מיוני כולם חייבים לתת טביעות אצבע ופנים. מי שישלם כופר מיוחד יוכל להשאר מחוץ למאגר (אם אתם באמת מאמינים שלא ישמרו לכם את תביעת האצבע אחרי שיכתבו אותה לשבב בתעודה), אבל יצטרך לעשות את זה פעמיים בעשור במקום פעם אחת. ההמשך עכשיו יכול להיות אחד משלושה עיקריים: או שהפניה שלנו לבג"צ תצליח והמאגר יבוטל מתישהו ב-2018, או שיהיה מהפך בחירות וקואליציה חדשה תחליט למחוק את השרץ, או שהגזרה תשאר, ועד 2022 (2027 למי שרץ להחליף תיעוד במאי) כל הישראלים שישארו פה יאלצו להשתדרק למאגר. בינתיים כבר היו דליפות בהודו וסיפורים מסוכנים אחרים, אז נחיה ונראה. על עדכונים של פאדיחות הבית הלבן אני גם לא ארחיב, אתם בטח צופים כמוני בסטיבן קולבר ביוטיוב.
היום אני רוצה לספר לכם על הצעצוע החדש שלי, יוביקי 4. כל מי שמכיר אותי, יודע שככל שנכנסתי בשנים האחרונות לתחום הזכויות הדיגיטליות, אני יותר ויותר מתעניין בתחומי הצפנה, זיהוי והזדהות, סיסמאות חזקות וכדומה. זה רק אספקט קטן מהעולם הזה, וכמובן לא משנה כמה חזקה הסיסמא שלכם לפיכסבוק אתם עדיין צריכים להיות אחראים למה שאתם מפרסמים שם. בכל מקרה כדאי גם שלא יגנבו לכם את החשבון עצמו, ולכן אני ממליץ תמיד:
כמה מילים על אימות כפול, או אימות בשני פקטורים: אחד הדברים הראשונים שמוגדרים בפרוטוקול זיהוי (ולא משנה אם אנחנו מדברים על סיסמא לאתר או כשאתם מתיישבים מול הפקיד בבנק) הוא הגדרת שיטת הזיהוי, כששיטות אימות הזיהוי מתחלקות ל3 קטגוריות כלליות: מי אתה, מה אתה יודע, ומה יש לך.
מי אתה – זה לרוב זיהוי ביומטרי, הבעיות איתו שאת חלק מהמדידות הביומטריות יקר למדוד או קל לזייף, ובמיוחד זה לא שונה מול כל גורם, ולכן אם היכולת להתאמת במקום אחד דלפה, הרי שהיא טובה לאחרים שסומכים על אותה השיטה. זה שווה ערך לסיסמא לא חזקה, שכתובה בצורה לא מוצפנת בכל מיני מקומות שאתה מסתובב בהם, שניתן לזייף ואי אפשר להחליף. רעיון גרוע. הצעתי היא שאם ספק השירות נותן בחירה, אל תסתפקו לעולם בזיהוי ביומטרי כאמצעי זיהוי ראשי. לא מול משרד הפנים או רשויות המס, לא טביעת האצבע לפתיחת הטלפון, לא להפעיל חתימה אלקטרונית במחשב, לא טביעה קולית מול השירות הטלפוני של הבנק, כל אחת מהשיטות האלו כבר הוכחה כקלה לזיוף.
משהו שאתה יודע – זו לרוב סיסמא, ובמקרים הפחות מוצלחים: תאריך יום הולדת, קוד סודי מגב כרטיס האשראי, תאריך ההוצאה של תעודת הזהות האחרונה שלך, מספר תעודת הזהות, שם הנעורים של אימא, שם חיה או מורה או בי"ס ראשון וכיוצא באלו דברים שקל לגלות עליכם ע"י בילוש או כיוס.
משהו שיש לך – תעודה בלתי ניתנת לזיוף, אם ע"י שימוש בשיטות ייצור סודיות וייחודיות ואם ע"י חתימה דיגיטלית, או אולי מפתח כלשהו שלא ניתן לשכפל. כשאני אומר מפתח עולה לכם אולי בראש מפתח פלדלת או ייל, אבל את אלו כבר שכפלו כי הופיעו בטעות בתמונה. הסיפור הכי מצחיק היה כשסוכני TSA הצטלמו ברוב היבריס עם צרור המפתחות שלהם שפותח כל מנעול מזוודות בשוק, ואנשים מיהרו להעתיק את המבנה מהתמונות, וכמזה שנתיים אפשר להוריד את כל המפתחות מגיטהאב להדפסה בתלתפסת ביתית. לא, אני מתכוון למפתחות הצפנה פיזיים, כלומר מעין התקן USB עם מעבד קטן וזכרון שאי אפשר לקרוא, וניסיון למעקף פיזי של ההגנות אמור להרוס אותו ללא שוב. כאלו יש מספר מוצרים בשוק ואחד היצרנים הבולטים הוא Yubico. אני סוקר את המוצר שלהם כאן כי אחרי שלמדתי את הנושא ברשת הגעתי למסקנה שזה אחד משניים-שלושה הכי מעניינים, מגוונים ונגישים, ואין לי שום קשר איתם מעבר לזה (וכמובן לא קיבלתי מהם מוצר או טובות), ולכן קניתי אותו. יש להם אפילו יבואן רשמי בארץ אבל אחרי שקיבלתי מהם ספאם, העדפתי לשלם את המחיר המלא של הזמנה מחו"ל (אמזון או הריסלר הזה). שווה להציץ, לפעמים יש להם סייל 50% הנחה ליום-יומיים.
אימות כפול, או אימות מרובה, הוא כזה שמשתמש ביותר משיטה אחת מאלו שפירטתי, ובמיוחד עדיף שלפחות משתי קטגוריות שונות.1
המוצר עליו אדבר פה הוא חד פעמי ולא ניתן לגיבוי או העתקה, ולכן הוא בגדר משהו שיש לי. לא אכנס כאן לכל הפרטים הטכניים הקטנים, אבל רשימת הדברים שעושה הכרטיסון הקטן הזה היא מרשימה:
זה לא פרנואידי?
למשתמש פרטי כיום, קצת. בעתיד אולי כבר לא. כדאי להתחיל להכיר או להתרגל.
להצפין את הדיסק? זה לא מעמיס את המערכת?
עם LUKS זה מובנה בקרנל, לחלונות ומאק יש משהו דומה, המחיר אחוז או שניים. אני לא ממליץ על ecryptfs שאובונטו מציעה להצפין אתה רק את ספריית הבית, זה פוגע בביצועים הרבה יותר. התחלתי לעשות את זה כשעבדתי בחברות שעסקו במידע רגיש, אצל מעסיקים אחרים הסתכלו עלי כמשוגע ובסוף באו להתייעץ איתי כשהמחשב הראשון נגנב מהמשרד או כשנציגים התחילו לצאת לשטח ולתערוכות ועלה הפחד שיגנבו סודות מקצועיים. אז כאמור לדעתי היום זו חובה שלא עולה הרבה לממש.
אני בונה היום אתר, להשקיע באימות כזה למשתמשים שלי?
גם TOTP-2FA וגם U2F – לדעתי כן, במיוחד אם האתר שומר פרטים אישיים של כרטיסי אשראי, בריאות מטופלים ועוד כיוצא באלו. יש ספריות חופשיות שקל לשלב, ולמערכות כמו וורדפרס, דג'נגו, ג'ומלה, רובי-או-ריילז ואחרות יש כבר מודולים מוכנים לקטיפה מהעץ, אז חבל להתעצל!
למה יוביקי 4 ולא גרסת הנאו?
טעם אישי. היוביקי 4 תומך במפתחות טיפה יותר גדולים, הוא טיפה יותר זול, קוד ה-PGP שלו פתוח בגיטהאב. לרוב האנשים גם הנאו יהיה מצוין, והיתרון הגדול שלו הוא NFC שעובד עם אנדרואידים שיש להם רכיב תקשורת תואם. אם רוצים להשתמש ביוביקי 4 (ללא NFC) על אנדרואיד, אפשר בעזרת כבל OTG, או לטלפונים חדשים, חיבור ישיר USB-C בדקם יוביקי החדש).
יש מתחרים ראויים?
יש כמה. חלקם יתנו U2F בלבד בפחות מ$10-$20, חלקם יקרים מאוד אבל עושים דברים נוספים כמו לשמש כארנק קריפטומטבעות (למשל Trezor ואחרים) ויש גם אופציות "האקריות" פתוחות כגון OnlyKey שמוסיף שכבות הגנה כמו סיסמא, פיצ'רים כמו השמדה עצמית וכדומה. יש מצב שאקנה כזה בעתיד, למרות שהוא נראה פחות עמיד מכנית לשבירה ושפשופים.
התוכנה צרובה ולא ניתנת להחלפה? אז מה אם יתגלה באג אבטחה?
כבר קרה פעם אחת, וכל הלקוחות קיבלו מפתח חדש עם קושחה מעודכנת. זה חלק מהשירות (והמחיר). אי האפשרות לעדכן את הקושחה זה פיצ'ר מתוכנן במכוון, כדי לא לאפשר החלפה לתוכנה שתגלה את המפתחות הסודיים ששמורים על המפתח.
כבר יש לי כזה מהמעסיק
אם המעסיק נתן לכם התקן כזה שישאר שלכם לשימוש אישי גם אחרי שתעזבו – כיף לכם! גוגל, פייסבוק וחברות טכנולוגיה אחרות עושות את זה. השתמשו בזה חופשי גם לחשבונות פרטיים!
אבל זה בעצם כרטיס חכם! יש לי כזה מרשות המסים ובתעודת הזהות החכמה החדשה!
כן ולא. יש על הכרטיסים האלו מעבד מספיק חזק לכל אלו ככל הנראה, ויכולות להזדהות בפרוטוקול כלשהו מול הממשלה יום אחד, אבל לא קושחה פתוחה שמאפשרת את כל הטוב שעליו כתבתי לעיל. אם הייתי שר הפנים, אחרי שהייתי מבטל את המאגר הביומטרי, הייתי מעביר נותן לכל הציבור תעודות חכמות עם היכולות האלו מובנות שישמרו עליהם ביום-יום. לצערי לא נראה לי שזה יקרה בזמן הקרוב.
למה לא כתבת פוסט כבר המון זמן?!
כי הייתי עסוק, וכי אף אחד לא שאל למה לא כתבתי כבר המון זמן, אז אולי מסתפקים בפרסונה הטוויטרית שלי…
אם יש לכן עוד שאלות, שתפו בבקשה בתגובות. אם זה מספיק מעניין לכלל הקהל, אולי אענה פה בגוף הפוסט.
-------
אז לפתע פתאום האקדמיה ללשון שינתה את כללי הכתיב.
הופתעתי מאוד מהשינוי של היום. אולי היו על זה ידיעות בפרסומים של האקדמיה, אבל למרות שאני מתעניין בלשון בכלל, ובכללי הכתיב בפרט, אינני עוקב אחרי כולם. למשל, בדיוק לפני מספר חודשים האקדמיה ללשון הקטלאנית הודיעה שהיא מתכננת לפשט את כללי הכתיב ולבטל הרבה מהסימנים מעל האותיות, אבל היא פרסמה טיוטה לדיון ציבורי, ולא הודיעה ישר על השינוי. (ויש דיון ציבורי, כי לאנשים אכפת מזה.)
אילו האקדמיה ללשון העברית פרסמה טיוטה, הייתי מעיר כמה דברים. אני אישית לא אוהב את הגושפנקה שניתנה ל„שיער”, „בריכה”, „ברירה”, ו„עבירה”, אבל בסדר, אני מבין שזה נפוץ, ואני אפילו שמח מאוד שאני לא צריך לבזבז את העצבים שלי על ויכוחים בנושא הזה. עם זאת, הכתיב החדש „מייד” מצער: גם הכתיב „מיד” היה נפוץ למדי, ולא עורר הרבה מחלוקות, והוא שמר על הקשר למילה „יד”.
אני הקפדתי מאוד על „ססמה” בתרגומי פיירפוקס וטוויטר, למרות התנגדויות רבות, ועכשיו זה בהדרגה יהפוך ל„סיסמה”. על זה לא חבל לי כל־כך, כי זאת ממילא מילה שאולה מובהקת, גם אם עתיקה, ואם אתם שואלים אותי, אפשר להוסיף יו״ד גם למילים שמיות מובהקות כמו פסגה, קדמה, וכיו״ב.
טיפ־טיפה חבל לי על הכתיב „שמים”, שעכשיו הפך ל„שמיים”. היה בזה דמיון יפה ל„מים”, אבל בסדר. עכשיו אני יכול להפסיק להחרים את יישום „ירושמיים”, שהפכה כבר מזמן למשהו פולחני עבור ירושלמים רבים.
אני מרוצה מהשינוי של „תכנה” ו„יזמה” ל„תוכנה” ו„יוזמה”. אני גם מרוצה למדי מהשינוי של מילות היחס „אתי, אתך” ל„איתי, איתך”, ושל „עתים” ל„עיתים”, אבל מוזר לי ביותר שלא נוספה בהזדמנות הזאת האות יו״ד למילים כמו „אִגרוף” ו„מִחזור”, כדי לא להתבלבל עם „אֶגרוף” ו„מַחזור”. זה היה יכול להיות כלל פשוט ושימושי, והוא ממש לא היה אמור להיות שנוי במחלוקת. חבל שזה התפספס.
עוד משעשעים אותי ה„אישורים” שנינתו למילה „אומנם” וליו״ד בצורת הגוף הראשון בזמן עתיד בבניין נפעל, למשל „איכנס” במקום „אכנס”. אני תמיד כתבתי אותם בכתיב מלא. את „אומנם” כתבתי בווי״ו כי גם „אֻמנם” הוא ניקוד תקני ולא רק „אָמנם”, וצליל u תמיד אמור להיכתב בווי״ו (אם כי עכשיו גיליתי לראשונה שהניקוד „אֻמנם” מיועד לשאלות, לפחות לפי אבן־שושן). ובבניין נפעל כתבתי תמיד „איכנס”, „איזהר”, וכו׳, כי הניקוד בחיריק תקין כמו בניקוד בסגול (ר׳ למשל גזניוס 51p).
טוב שיש עכשיו גושפנקה למילה „תיאטרון”, כי אני לא מכיר שום תיאטרון ישראלי שבכניסה עליו כתוב „תאטרון”. (אם יש כזה, זה מפדח למדי, אז עדיף שפשוט אודה: אני לא הולך להצגות מספיק.) מצד שני, מוזאון עדיין אמור להיכתב בלי יו״ד. אני אוהב את החלוקה החדשה הזאת, אבל יש לי תחושה שמוזאונים ימשיכו לקרוא לעצמם „מוזיאונים”, אם כי אפשר לשם השעשוע לנסות להחיות את המילה „בית נכאת”.
מעטים ישימו לב לזה, אבל עכשיו המילה „די” תיכתב תמיד ביו״ד אחת. גם ככה רוב האנשים כותבים אותה ביו״ד אחת, וזה תמיד היה נכון, אבל משום־מה האקדמיה אפשרה עד עכשיו גם „דיי” ו„דאי”. אפילו ראיתי את „דיי” בספרים שהאקדמיה הוציאה ממש לאחרונה (כמו „העברית בתקופת המנדט” הנהדר של יעל רשף). אבל זהו, לא עובד: רק „די”, וטוב שכך.
עוד דבר שמעטים ישימו לב אליו הוא השם של הכללים החדשים: „כללי הכתיב המלא”. עד עכשיו הם נקראו „כללי הכתיב חסר־הניקוד”. למיטב ידיעתי, המונחים כתיב מלא וכתיב חסר מעולם לא היו מוגדרים באופן מדויק למרות שאנשים רבים השתמשו בהם. „כתיב חסר” עדיין אינו מוגדר, אבל זה בסדר, כי הוא לא ממש נחוץ.
עכשיו יהיה ממש נחמד לעדכן גם את מילון האיות החופשי Hspell. נדב ודן, אם אתם קוראים את זה, אני אשמח לעזור.
מבחינה טכנולוגית, שנת 2016 היתה שנה מרתקת. לצערי, לא מצאתי סיכומים הולמים לשנה כה אינטסיבית ואולי אף הייתי אומר – מופרעת. אני חושב, שבמקום הראשון, בישראל, השנה הזו היתה קודם כל שנת האופניים החשמליים. רבים מתייחסים אליהם מבחינת היקף התאונות, אבל להערכתי העניין הגדול הוא מספר כלי הרכב הללו הנעים על הכבישים. אט אט, האופניים … להמשיך לקרוא סיכום שנה שנת 2016 + מצבה של התוכנה החופשית
Last updated:
05 December, 2020 11:18 AM
All times are UTC.
Powered by:
