25 September, 2016 08:14 PM

The KOMA-Script bundle provides an option to specify the amount of binding correction needed in order to compensate for the width lost in the binding process. By default, it is added to the left margin, which is where the binding is applied for Left to Right languages. However, if a document is written in Hebrew or Arabic, one binds it on the right. The KOMA-Script manual does not consider that option. After a bit of playing I’ve found out that simply using a negative value for the binding correction works.

For example, if in an English document you would use

\documentclass[BCOR=8.25mm]{scrreprt}

For Hebrew you would set

\documentclass[BCOR=-8.25mm]{scrreprt}

24 September, 2016 11:19 AM

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

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

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

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

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

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

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

בברכה,

יוסף אור

23 September, 2016 02:47 PM

Creating abstracted Dockerfile is something I really wish existed. Every time, I write a `Dockerfile` for a specific base image I must specify the correct package manager command. You either use `apt-get` or `apk` or `yum` or any other call for the package manager. This is unfortunately, not very reusable. But, here is a simple schema how to use M4 macros to achieve this abstraction. continue reading...

07 September, 2016 09:12 PM

For the full article visit Confession of a Public Speaker

07 September, 2016 04:36 PM

gh-ost version 1.0.17 is now released, with various additions and fixes. Here are some notes of interest:

Hooks

gh-ost now supports hooks. These are your own executables that gh-ost will invoke at particular points of interest (validation pass, about to cut-over, success, failure, status, etc.)

gh-ost will set various environment variables for your executables to pick up, passing along such information as migrated/ghost table name, elapsed time, processed rows, migrated host etc.

Sub-second lag control

At GitHub we're very strict about replication lag. We keep it well under 1 second at most times. gh-ost can now identify sub-second lag on replicas (well, you need to supply with the right query). Our current production migrations are set by default with --max-lag-millis=500 or less, and our most intensive migrations keep replication lag well below 1sec or even below 500ms

No SUPER

The SUPER privilege is required to set global binlog_format='ROW' and for STOP SLAVE; START SLAVE;

If you know your replica has RBR, you can pass --assume-rbr and skips those steps.

RDS

Hooks + No Super = RDS, as seems to be the case. For --test-on-replica you will need to supply your own gh-ost-on-stop-replication hook, to stop your RDS replica at cut-over phase. See this tracking issue

master-master

While active-active are still not supported, you now have greater control over master-master topologies by being able to explicitly pick your master (as gh-ost arbitrarily picks one of the co-masters). Do so by passing --assume-master-host. See cheatsheet.

tungsten replicator

Similarly, gh-ost cannot crawl your tungsten topology, and you are able to specify --tungsten --assume-master-host=the.master.com. See cheatsheet.

Concurrent-rowcount

--exact-rowcount is awesomeness, keeping quite accurate estimate of progress. With --concurrent-rowcount we begin migration with a rough estimate, and execute select count(*) from your_table in parallel, updating our estimate later on throughout the migration

Stricter, safer

gh-ost works in STRICT_ALL_TABLES mode, meaning it would fail rather than set the wrong value to a column.

In addition to unit-testing and production continuous test, a set of local tests is growing, hopefully to run as CI tests later on.

Fixed problems

Fixed time_zone related bug, high unsigned values bug; added strict check for triggers, relaxed config file parsing, and more. Thank you to community contributors for PRs, from ipv6 to typos!

Known issues

Issues coming and going at all times -- thank you for reporting Issues!

We have a confirmed bug with non-UTF charsets at this time. Some other minor issues and feature requests are open -- we'll take them as we go along.

Feedback requests

We are not testing gh-ost on RDS ourselves. We appreciate community feedback on this tracking issue.

We are not testing gh-ost on Galera/XtraDB cluster ourselves. We appreciate community feedback on this tracking issue.

We value submitted Issues and questions.

Speaking

We will be presenting gh-ost in the next month:

• I will be presenting gh-ost at GitHub Universe, Sep. 14th
• Tom Krouper will be presenting gh-ost at DataLayer, Seattle, Sep 28th
• Tom Krouper and myself will be presenting gh-ost at PerconaLive, Amsterdam, Oct 5th

Hope to see you there, and thank you again to all contributors!

06 September, 2016 09:44 AM

When you see var j = {"x": 1} in JavaScript, it is plainly wrong to say that j is now JSON or references JSON or holds JSON for that matter.

That’s because j now references a data structure in memory. A data structure is not JSON nor YAML nor any other serialization format.

A data structure can sometimes be serialized to JSON or to YAML or to other formats. A data structure can sometimes be deserialized from these formats.

The code on the right side of the assignment looks like JSON. Don’t let this confuse you. It’s a JavaScript code and it evaluates to a data structure as many other JavaScript expressions do. It could easily be var j = {'a': 1, 'f': function() {} } . You wouldn’t say it’s JSON, right? There is not much difference between the two JavaScript expressions var j = {"x": 1} and var j = {'a': 1, 'f': function() {} } for this matter.

Data structure vs it’s serialized form

Data structure is the layout of the data. In our case it is in memory. Data structures can also be on disk, think data file of a database. Data structures are “good for” accessing and modifying the data that they hold. In our case it means one can use the expression j.x to access the field x or j.x = 7 to modify it.

Serialized form of a data is a string of characters that can be saved to a file, read from such file or sent over the network. There is no easy way to manipulate such data directly. Modifying serialized data usually involves deserializing it, modifying and serializing back.

Serialization limitations

Not any data structure can be serialized at all. Example (specific to JSON format):

var j = {}
j['circ'] = j
JSON.stringify(j)
TypeError: Converting circular structure to JSON

Not any data structure can be serialized in a way that would ensure that desirialization would produce similar data structure. Example (specific to JavaScript + JSON):

var j = {'a': 1, 'f': function() {} }
JSON.stringify(j)
'{"a":1}'

Have a nice week!

05 September, 2016 04:57 AM

When purchasing an SSL certificate at dnsimple I was amazed to discover that by default it’s dnsimple who generates the private key for you. The checkbox that says “I want to provide a custom CSR” is unchecked by default. Not checking it causes dnsimple to generate your private key and a CSR for you. Simple – yes. Secure – no.

Generating a private key for anyone but yourself is a big security no-no. This is common knowledge for people that are selling certificates. Still somehow it’s default at dnsimple.

Please stop doing these stupid things!

03 September, 2016 04:07 PM

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

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

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

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

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

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

01 September, 2016 08:16 PM

I am learning Ruby, and coming from Python it's not a an easy thing. Ruby is confusing, it has a weird syntax, and things are not really simple as in Python. There is still tons of stuff which seem like dark magic. There's `nil`, there are `gems` and `bundler`. And there is _Rails, which isn't Ruby_. Ruby is good for so many people out there, and I am sure you can do amazing things in it. I already know it's never going to be my weapon of choice, but it's not bad knowing my way around it. I'd like to know how to set up a simple project, read and debug code, install gems and package ruby projects. I have been ignoring Ruby for too long. continue reading...

23 August, 2016 02:57 PM

ערב טוב.

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

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

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

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

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

ערב טוב,

יוסף אור

14 August, 2016 04:05 PM

Last week we released gh-ost, GitHub's online schema migration tool for MySQL. As with other open source releases in the MySQL ecosystem, this release was echoed by several "Why not PostgreSQL?" comments. Having been active in open source since many years now, I'm familiar with these responses, and I find this is a good time to share my thoughts. Why? XKCD knows the answer:

I picked one post I wish to address (latest commit: 3dfbd2cd3f5468f035ec86442d2c670a510118d8). The author invested some time writing it. It nicely summarizes claims I've heard over the years, as well as some prejudice. Through responding to this post I will be generalizing thoughts and impressions to address the common reactions. Dear @brandur, let's grab a beer some day; I fundamentally disagree with your post and with its claims.

EDIT: linked post has been updated following this writing; I'd like to thank the author for his consideration. Also see his followup post. The version I've responded to in this post is this commit.

This is not an anti-PostgreSQL post

Disclosure: I appreciate PostgreSQL. I always wanted to be a proficient PostgreSQL user/DBA. I think this project is one of the finest examples of quality open source. It sets some high standards for open source in general, and for RDBMS in particular. I am not emotionally attached to MySQL to the extent that I would hate everything that is not called "MySQL". I never understood this approach. I am not interested in religious wars. I'm an engineer and this post follows engineering guidelines.

Background

gh-ost delivers powerful online schema migrations to MySQL, differentiating itself from existing tools by being triggerless, auditable, controllable, testable, imposing low workload on the migrated master. It addresses the same problem addressed by existing tools as of 2009.

Feature X

The most basic premise of this post is: MySQL does not have feature X, PostgreSQL does, therefore PostgreSQL. 

We'll discuss the truth of the above shortly, but let's first discuss the essence of this guideline.

It should be generally agreed that a statement of the form "A doesn't have feature X therefore B" is incomplete. We understand complex systems have varying feature sets.

MySQL has some features PostgreSQL doesn't. Take, as example, the feature R: MySQL has got it since ages ago, and yet PostgreSQL is slow to adapt it, and relied on 3rd party solutions for many years. MySQL's implementation of R is far more elaborate than PostgreSQL's.

But if we follow the rule suggested above, we must now migrate from PostgreSQL to MySQL, because PostgreSQL does not have feature R (or one of its variants). Infinite loop!

In practice, we evaluate the pros and cons, the features the products A and B have or do not have. Which feature is more important to us? X or R? Is one of them fundamentally required for our operation? Can we work around it if we don't get it directly from the product? That, and experimentation, is the way an engineer should approach a choice of technology.

In the world of RDBMS we are interested, among others and in no particular order, in write latency and throughput, read scale out, durability, loss of data in the event of failure, failure promotion schemes, DR, consistency, SQL features, etc. by this list alone it is impossible to claim "PostgreSQL is better than MySQL"  nor "MySQL is better than PostgreSQL".

The particular claim and advice

The author suggests we should be using PostgreSQL because it inherently solves the problem for which we embarked on developing gh-ost. That is, that PostgreSQL supports true online schema changes. That statement is misleading and I resent the way that statement is delivered.

The post does not mention that PostgreSQL supports online schema changes for a limited set of operations. I went ahead to double check with the PostgreSQL documentation. I love the documentation! It is detailed and honest. I'm thoroughly satisfied that PostgreSQL only supports a limited set of online operations. I go against the fact the post does not mention that, and leads us to "understand" PostgreSQL has a magic wand.

Online table operations are supported in PostgreSQL for adding/removing indexes, for removing columns, and for adding columns under certain conditions. As an example, adding a nullable column is an online operation, whereas adding a column with default value is a locking operation.

A very big part of our schema migration including adding/removing indexes and adding columns. Many of these operations fall under the lockless, online operations PostgreSQL would allow. However a large part of our migrations also consists of adding columns with default values, changing data types (e.g. From INT to BIGINT), changing character characteristics (e.g. length of text column), space reclamation, and others. These changes are blocking in PostgreSQL.

The premise of the post now turns to: it's a pity you invested time and money in developing a tool that solves 100% of your problems when you could have switched to PostgreSQL which would solve 40% of your problems!

If I were to insist my fellow engineers at GitHub migrate to PostgreSQL in order to solve the migration problem, and then, once this technical transition is complete let them know 60% of the migrations are not at all addressed and that we are still stuck with the very same problem we started with, I would not be a very popular engineer.

Moreover

"the same advancements never happened in MySQL" is a false statement.

As mentioned in the gh-ost announcement, MySQL as of 5.6 does indeed support online, non blocking alter table. In fact, it supports many more variants of online alter table than PostgreSQL does (however, noticeable difference is that PostgreSQL makes those changes transactional whereas MySQL does not).

Also as mentioned, one of the shortcomings of the MySQL implementation is that it is aggressive, and may cause a high impact on the running master. In my understanding the PostgreSQL implementation is no different. There's nothing to cause throttling, to play nice with the running workload. Yes, in PostgreSQL you can Ctrl-C your ALTER, but who wants to Ctrl-C a 10 hour operation?

gh-ost addresses that as well. Its throttling gives super powers over the migration process, kicking in throttling based on master load, replication lag, various human controlled criteria, effectively making it very lightweight on the master.

Misdirection?

"there's a level of seemingly willful misdirection here that I just can't wrap my head around"

XKCD to the rescue again:

I dare say this is not the kind of thing a person would say in person, and the accusation is rather severe. It is also ironic. Dear author, consider:

• PostgreSQL does not really solve 100% of the problem gh-ost does, and yet you claim we'd be better off with PostgreSQL.
• MySQL does indeed provide more variants of online alter table than PostgreSQL does, and yet you claim it has no online alter capabilities.
• I might claim there's a seemingly willful misdirection in your post. I might claim nowhere in your write up do you mention the deficiencies in PostgreSQL.

Instead, I'd rather like to think that you, and others, are misinformed, basing your opinion on rumors and prejudice instead of facts.

I also observe that people all around the world like to willfully differentiate themselves from others. Even in tech. this is the topic for another post, but consider explaining to a complete outsider, say your doctor, why people who work in tech, are engineers, work with data, work with databases, work with relational databases, work with open source relational databases, people who have so much shared experience, still insist on "us and them", and seek to see the negative in the other. Sheesh.

Paraphrasing a memorable sarcastic quote from the movie Erin Brockovich: the fact so many of the largest tech companies today choose to use MySQL as their backend database does not mean it's crap.

No. We really think MySQL does a good job. It is not perfect. We work around some of its limitations.

Claims

The claim "you'd be better off with PostgreSQL" (not a quote from aforementioned post) cannot be made without understanding the specific workload of a company/product. It would be presumptuous of me to approach a PostgreSQL based company and say "oh hey why use PostgreSQL? You'd be better off with MySQL!"

It makes perfect sense to say "PostgreSQL handles problem X better than MySQL" or even "if your one most important requirement is X, you should switch to PostgreSQL". Otherwise claiming one database is wholly better than the other cannot be taken seriously.

Deficiencies? Any project of scale has deficiencies. It is granted. We observe and measure, and take features and deficiencies into calculation, and that makes for good engineering.

• If you're using PostgreSQL and it works well for you, you're doing the right thing.
• It you're using MySQL and it works well for you, you're doing the right thing.
• If you found that PostgreSQL works better for you where MySQL does not, and you decided to switch over, you're doing the right thing.
• If you found that MySQL works better for you where PostgreSQL wasn't, and you decided to switch over, you're doing the right thing.
• If you found that PostgreSQL works better for you where MySQL wasn't, but decided to stick with MySQL because migrating would be too costly, you're doing the right thing.
• If you found that MySQL works better for you where PostgreSQL wasn't, but decided to stick with PostgreSQL because migrating would be too costly, you're doing the right thing.
• If you pick one over the other because of licensing constraints, you're doing the right thing.
• If you choose to switch over because of rumors, prejudice, FUD, politics, religion, you're doing it wrong.

Final personal note, on pride

"Yesterday, GitHub broadcasted an indomitable sense of self-satisfaction far and wide..."

Oh hey, XKCD again. But I would like to ask an honest question: if some pg-gh-ost were to be released, a tool that would solve 100% of your PostgreSQL migrations requirements, doing it better than PostgreSQL does, covering all cases, throttling as your daily sqoop imports kick in, as your rush hour traffic kicks in, giving you far and wide greater control over the migration process, what would you do?

Would you write an offensive post filled with accusations, ranting about the deficiencies of PostgreSQL and how people even consider using such a database that needs a third party tool to do a better job at migrations? Would you tweet something like "Or... Use MySQL!"

Or would you embrace a project that enriches the PostgreSQL ecosystem, makes it even a greater database to work with, understanding PostgreSQL is not yet perfect and that more work need to be done?

I take pride in my craft and love making an impact; if we ever do meet for beer I'm happy to share more  thoughts.

s/gh-ost/anything/g

Peace on earth

13 August, 2016 06:13 AM

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

הטקסט המלא

12 August, 2016 04:42 PM

אחרי התאוששות קצרה, פוסט קצת ארוך לסיכום אוגוסט פנגווין 2016

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

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

לטובת אלו שלא שרדו עד למושב הסיכום, אסכם את עיקרי דברי, עד שיפורסמו ההקלטות:

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

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

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

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

להתראות בהמשך!
תומר

08 August, 2016 07:44 PM

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

מאז הפרסום הקודם עשיתי אינטגרציה של ZendServer להפצות הלינוקס השונות (Debian, Ubuntu, RHEL/Centos), עסקתי בקמפול של PHP לכל מיני ארכיטקטורות (חוץ מאינטל) וגם הפכתי לחבר בקהילת ה-PHP עם תרומות קוד בסיסיות ועבודה עם צוות האבטחה של הפרוייקט ושאר ההפצות. בנוסף, עבדתי בלינווייט כדי לשלב את הידע שלי מפרוייקטי קוד פתוח עם תהליכי הפיתוח של החברה (ברמת הניהול וברמה הטכנית). הרקע שלי הוא של sysadmin וארכיטקט מערכת, ואז המשכתי בעיקר לעולם תהליכי הפיתוח Continuous Integration. במסגרת פרוייקטי הקוד הפתוח צברתי ניסיון עם GIT וכמובן בעבודה מול קהילה. כיום אני חבר בשלושה פרוייקטים: Debian, LibreOffice ו-PHP (רמת התרומות משתנה לפי העניין והזמן הפנוי).

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

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

פרטים נוספים אפשר למצוא בפרופיל הלינקדאין שלי: https://www.linkedin.com/in/liorkaplan

08 August, 2016 12:10 PM

I’ve made available in my personal repository amd64 builds of LyX 2.2.1 for Debian Jesie.

Enjoy!

06 August, 2016 01:18 PM

שלום כולם,

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

אנחנו רוצים להזכיר לכם שהרשמה מראש עוזרת לנו לייעל את הכניסה לכנס ולקצר תורים — אנא עזרו לנו לעשות את הכנס קל יותר לכולם.

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

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

להתראות בכנס!

02 August, 2016 06:27 AM

On 1st August 2011, exactly 5 years ago, the first edition of the Perl Weekly newsletter was published. Since then we have published 6,676 articles by 248 authors in 262 issues. The number of subscribers grew to 6,196. The number of Twitter followers is 2,072. Let's celebrate!

For the full article visit Perl Weekly - The first 5 years

01 August, 2016 04:17 AM

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

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

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

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

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

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

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

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

הטקסט המלא

31 July, 2016 08:25 PM

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

Full text

13 July, 2016 08:14 PM

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

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

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

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

09 July, 2016 04:14 PM

I recently checked the Debian PHP 5.4 changelog and found out this message (5.4.45-0+deb7u3 and 5.4.45-0+deb7u4):

* most patches taken from https://github.com/kaplanlior/php-src
Thanks a lot to Lior Kaplan for providing them.

I was very pleased to see my work being used, and I hope this would save other time while providing PHP long term support.

Also, while others do similar work (e.g. Remi from RedHat), it seems I’m the only when that make this over GIT and with full references (e.g. commit info, CVE info and bug number).

Comments and suggestions are always welcome… either mail or even better – a pull request.

Full text

08 July, 2016 12:07 AM

A year ago I’ve blogged about people requesting CVE without letting upstream know. On the other hand, per requests from Debian, I’m working on improving PHP upstream CVE request process. For the last few release this means I ask the security list members which issues they think should have CVE and ask for them in parallel to the release being made (usually in the space between the release being tagged publicly and is actually announced).

In the last week, I’ve encountered a case where a few CVE were assigned to old PHP issues without any public notice. The fixes for these issues have been published a year ago (August 2015). And I find out about these assignment through warning published by the distributions (mostly Debian, which I’m close to).

Sometimes things fall between the chairs, and it’s perfectly OK to ask for CVE to make sure security issues do get attention even if time has passed. But after the issues (and fixes) are public, I don’t see a reason to do so without making the request itself public as well. And even if the request wasn’t public, at least notify upstream so this info can be added to the right places. Most of these bug were found out when I started to add sequential number into the CVE search after getting an a notice from Debian for two of the issues.

• CVE-2015-8873 for PHP #69793
• CVE-2015-8874 for PHP #66387
• CVE-2015-8876 for PHP #70121
• CVE-2015-8877 for PHP #70064
• CVE-2015-8878 for PHP #70002
• CVE-2015-8879 for PHP #69975
• CVE-2015-8880 for PHP aa8cac57 (Dec 2015)

And while working on processing these issues for PHP, I also notice they weren’t updated for libGD where appropriate (including recent issues).

Beyond keeping the eco-system up to date, another aspect of publicity is getting opinions from other parties. For example, in the case of CVE-2015-8879, RedHat doesn’t agree with the classification of the bug as security. To give an example of a way things should happen is the request of CVE for PHP 5.5.34 in April, in which the Gentoo security team asked for assignment without upstream knowledge, Debian representative CCs upstream (Thanks!) and also asks CVE for issues covered by Ubuntu, to which the Ubuntu guy then adds some details.

I hope this blog post will reach the anonymous people behind these CVE requests, and also the people assigning them. Without transparency and keeping things in synchronization, the idea of having a centralized location for security warning is not going to accomplish its goals.

Full text

07 July, 2016 11:51 PM

git clone https://github.com/microsoft/vscode
cd vscode
scripts\npm install

06 July, 2016 10:21 AM

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

הטקסט המלא

24 June, 2016 09:35 AM

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

Licence

Copyright by Shlomi Fish, 2016.

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

27 May, 2016 12:43 PM

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

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

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

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

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

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

You should delete your Facebook account, too.

21 May, 2016 09:30 PM

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

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

21 May, 2016 05:59 AM

29 April, 2016 08:55 AM

27 April, 2016 07:46 PM

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

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

LXC+LVM+Snapshots = LLS

Architecture

Further work

14 April, 2016 12:15 PM

AsyncIO נמצאת בספריה הסטנדרטית של פייתון החל מגרסה 3.4, ומספקת תשתית לכתיבת קוד מקבילי הרץ ב-Thread בודד.

ההרצאה אודות AsyncIO שהועברה במסגרת PyWeb-IL 52 זמינה בעמוד הרצאות ומצגות.

08 April, 2016 06:49 AM

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

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

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

Enjoy!

25 March, 2016 04:14 PM

הטקסט המלא

13 March, 2016 02:11 PM

הטקסט המלא

13 March, 2016 02:11 PM

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

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

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

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

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

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

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

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

הטקסט המלא

05 March, 2016 10:50 PM

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

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

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

Things to consider are:

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

LVM/ZFS over a few HDs

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

tar | split

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

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

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

Span Files

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

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

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

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

09 February, 2016 12:28 PM

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

הטקסט המלא

31 January, 2016 05:35 PM

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

הטקסט המלא

24 January, 2016 04:00 PM

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

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

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

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

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

פרויקט של גוף ממשלתי שהשורשים שלו נטעו בסוף 2012, הגיע למצב של פיילוט ב2015, שעכשיו ב2016 כנראה שיכנס להיות בכל הארץ אצל אותו גוף ממשלתי.

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

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

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

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

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

23 January, 2016 02:01 PM

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

GRUB to the rescue!

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

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

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

13 December, 2015 01:33 PM

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

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

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

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

07 December, 2015 03:42 PM

I've started blogging again! In order to avoid cross-posting between the different blogs, I'll just give a brief paragraph and a link back to the original post. Here we go:

Getting into a network and getting data out of a network are two different challenges. Just because an employee clicked on a malicious link and got hacked, it doesn’t mean the attacker gets to walk off with PII, Financials, Source Code etc. In this blog post, we’ll explore the known breach method of using ICMP protocol for data exfiltration but with a twist. Instead of showing how to use this breach method with some custom made tools, we’re going to do it using the default and common ping utility– red team style!

Continue reading: http://blog.safebreach.com/2015/12/02/i-see-your-true-echo_request-patterns-pinging-data-away/

Full text

02 December, 2015 07:55 PM

התחלתי לתרגם מאוחר לאחר הקפאת המחרוזות של Django 1.9, התרגום עמד על 95%.

מקווה שלא פספסתי את מיזוג המחרוזות של 1.9. נכון ליום שבת, ה־25 בנובמבר התרגום עומד על 100% עבור:

• django-core
• django-formtools - הוסר מ־django.contrib
• django-people (האתר)
• django-contrib-comments

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

• django-localflavor
• django-docs

01 December, 2015 07:58 AM

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

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

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

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

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

24 November, 2015 08:51 AM

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

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

16 November, 2015 11:13 AM

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

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

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

08 November, 2015 04:58 PM

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

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

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

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

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

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

OK, warnings aside, let's begin.

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

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

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

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

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

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

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

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

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

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

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

5T = 4 seconds

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

05 November, 2015 06:12 PM

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

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

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

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

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

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

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

02 November, 2015 01:44 PM

FullPageOS

Hey all,

Today I am announcing a RaspberryPi operating system that addresses a small need we have – Get the RaspberryPi to display a webpage on full screen with no hassle.
The OS is called FullPageOS. And you can download it here.

Why I built it

A friend of mine, Tailor Vijay wanted something to stream video and add titles to it. Also I was looking for a way to start the RaspberryPi with a browser on full screen for a stats screen at work, and apparently the only thing available is complex guides that only partly work on today’s RaspberryPi.

So what I did last weekend is build a distro based off the code of OctoPi, the 3D printer operating system I built. All this distro does is start Chromium at boot on full screen, with a URL of your choice. The url can be changed conveniently from a text file on the /boot FAT folder. So all you have to do is set the wifi and url via text files, boot, and voilà!
Among the minor tweaking is the elusive setting of disabling the screen from blanking.

How to set it up

What’s nice about FullPageOS is that its simple, no need to install packages, just flash it like any distro, set your wifi and URL settings and boot.

1. Open the FAT filesystem that is mounted as /boot
   on the pi
2. Set the URL you want in the file fullpageos.txt
3. If you need to set up wifi, set your wifi settings with the file fullpageos-network.txt or any way you want are used to on the RaspberryPI
4. Plug to HDMI display, internet and boot

Known issue with black boarders

On some screens I tried FullPageOS I got a black boarder, to fix this, you need to edit config.txt and uncomment the line:

disable_overscan=1

This fixes the issue.

Contribution is appreciated!

FullPageOS works, but its missing the shiny slickness that OctoPi has today. For example if someone wants help me write a nice default boot page that would be great! The current default url is just the github page. So as usual, pull requests are welcome.
The source works just like an OctoPi build, and as a by product I wanted to show how easy it is to create custom distros for the RaspberryPi using this build method. We could, really, build a universal custom distro system based off these things. There is already a variant system that was ported from OctoPi code.

FullPageOS image can be downloaded here

Thanks

• Thanks Taior Vijay for inviting me to the Metor hackathon and asking me to set up a webpage in kiosk mode on the Pi.
• Thank you Doc’s Tech for hosting the image.

Share and enjoy,
Guy

Full text

20 October, 2015 04:04 PM

ShapeDo logo

Hey all,

It’s my 29th birthday this week, and that sorta made me realise no one really knows what I have been doing the past 18 months, so I thought it’s time to tell you how I founded a company. Unlike the tutorials and guides I wrote here, I am not sure this would work for everyone, but it did work for me.

The Idea

I have started one of my biggest and ambitious projects yet, after collaborating with people around the world bringing OctoPi to the world, I realised that something was missing from the scene of 3D design – a decent version control and collaboration tools.

This was the initial idea, as you will see things played out differently, but what was important with this idea was contagious, I got the feeling everyone I told about it wanted to join me, it was wonderful.

Assembling the team

My talent is mostly in the core backed stuff, so I found myself going to one of the more talented web developers I know for help, my co-worker at Zend, Amit. It started by asking him javascript questions. When he realized what I was doing, he started helping me out, and he was fast, suddenly in days my core stuff was accessible to the world with a simple and elegant interface. At that time we thought this is going to be a nice open source project, not something commercial, but as the server load grew on Amit’s little server we understood we needed some way to pay its bills, so I started to look for someone that would help me figure out how to sustain this financially. Since our idea was “github for 3D printing”, it seemed like there should be a way to support it, perhaps charge for closed-source projects.

I’ve been going around the Makerspaces in Tel-Aviv, mostly XLN and T.A.M.I, in some random workshop I came across someone who said “You should write an executive summary, I don’t mind helping you out”. I didn’t even know what an executive summary was at the time, and today it makes me realise how much I learned about fundraising during this year. I later found his name was Ari and he was between companies. We set to meet at Google Campus and write it since we both went to some ecology hackathon that was going on there.

We ended up drunk from exhaustion and pizza, scooting on chairs at the space and we also had a draft. As we wrote it, the idea spread to Ari, and he realized he that he wanted to join. I introduced him to Amit. It took a while to put our trust in Ari, less time than we expected, and today I know ShapeDo would not have reached anything without Ari’s help. Eventually we wrote a few basic agreements on paper and Ari made sure we register a company, ShapeDo was born.

The Pivot

We worked on a new site for 3D printing and launched, we got coverage on 3D printing industry, and the user base grew, but people were not really using the collaboration features. It turns out most people 3D printing share are simple one person designs in one afternoon projects. However, what is special about the 3D printing industry is that there is no 3D CAD tool that was built for it. So you end up meeting designers from mechanical engineering, gamers, architects, programmers and any discipline that has a 3D design program that can export the printable files. We (everything eventually becomes “we”) found that everyone wanted this kind of tool in their workplace, while in 3D printing was not as urgently needed.

Ari and I had a talk where he thought we should pivot either to construction planning, or mechanical engineering. In the end construction seemed more favourable because AutoDesk, who rule that realm, had neglected collaboration (also known as, product lifecycle management or PLM) for the past decade, and so there was a lot of low-hanging fruit. At first I didn’t want to pivot, after all 3D printing was my idea, but eventually, I let it go. A lot of what a startup is about is letting go of your ownership, a company has to grow beyond you. We slowly found ourselves with a technology for an industry we know nothing about, so we learned, we banged on doors and met with architects, contractors, constructors, anyone that is in the process of construction, we can’t cover everything, but we were getting an idea of what is going on.

Investors and our Investment

The pivot did more than point us to users we could talk to and find out what they actually need, it also made the business proposition make more sense. The goal was not to just build a big collection of files for people to share, it was to build a system we could charge for. We started getting investors interested, we first started talking to angel investors, but it seemed to be much harder than anticipated. Angels seem to be mostly interested in apps. Something your 6 year old could download, something they can understand, there are a small number of them that would understand what it means to sell something to a construction enterprise. So it made the process much harder, we found that the first meeting was just for grasping what we actually do, before talking about the investment itself.

Ari and I went around looking for an investment, I had an 80% time job so I had an extra day to do this. I had a few chats about it with Gina, who also had that extra day for OctoPrint. I think that 80% is good when you want something steady while looking for funds, stability in your life in one part lets you explore radical stuff in another.

Eventually we set a meeting with Incentive, we got a warm recommendation for them for the accelerator Ari was going to at the time called Siftech (an accelerator is a place you got to for a few months that helps your startup out with a physical location and various services, usually paid). Indeed when we met with them they seemed much better than the angel investors we were talking to. The catch was that we had to base our offices in Ariel University (though today it seems not so bad, there is never traffic to work). The program they offer was enough to keep us and an extra worker for a 1.5-2 years. Working on something as volatile as ShapeDo means you don’t want to have to think about personal finance, it means you don’t have time to consider the company’s. So we went through a due diligence, it took a while, but it was a good process for us and the company. Today our offices are located in the investors offices.

Today, Happy 29th Birthday

Today we found a go to market, something we can sell, and we are just in the process of hiring someone from the industry to help us out. Our system is flooded with real customer data. Things are going great. But as I saw every step of the way, everything can explode the next day, nothing is certain, and I think that kind of attitude is what got us this far.

I hope this helps the people around me to know what is going on, I feel like I had to let this be known. It might even help others that are on a similar path. I’ve been playing with 3D printers for fun in the meantime, and I might post a few findings.

As always, would love to hear your comments.

Celebrating first day at the office

Example of what we do today

What we are selling today is a a construction planning collaboration platform and a comparison tool for constructors. At the bottom you can see how complex an architectural plan is, and how easy it is to spot the changes marked in purple detected by our software, normally this would have been done on hard paper by the constructor.

Architectural plan with the changes marked in purple between two versions

Full text

20 September, 2015 09:23 AM

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

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

10 September, 2015 07:58 AM

As you probably already knew, Wikipedia is a website. A website has content—the articles, and 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 knew 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. “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 ill. It slipped for quite a few months because in late 2014 I became a father, and a lot of new messages happened to be added at the same time, but Hebrew is back at 100% now. And I keep doing this.

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

Preparation

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

• Get a translatewiki.net account if you haven’t already.
• Make sure you know your language code.
• Go to you preferences, to the Editing tab, and add languages that you know to Assistant languages.
• Familiarize yourself with the Support page and with the localization guidelines for MediaWiki.
• Add yourself to the portal for your language. The page name is Portal:Xyz, where Xyz is your language code.

Priorities, part 1

The translatewiki.net website hosts many projects to translate beyond stuff related to Wikipedia. Among other things 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 many 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 them, but because I don’t have time for that, I have to prioritize.

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

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

I usually don’t work on translating other projects unless all of the above projects are 100% translated to Hebrew. I occasionally make an exception for OpenStreetMap or Etherpad, but only if there’s little to translate there and the untranslated MediaWiki-related projects are not very important, for example, they are unlikely to be used by anybody except a few software developers, but I translate those, too.

Priorities, part 2

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

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

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

Getting Things Done, One by One

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

I have surprising advice.

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

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

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

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

Getting All Things Done

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

But let’s go further.

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

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

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

But you’ll be able to congratulate yourself on the accomplishments along the way, and on the big accomplishment of getting everything to 100%.

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. 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 quietly competing with other languages. Open the statistics for Extensions Used by Wikimedia – Main. 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. Then six messages more to go up another notch. 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 Wikimeda. It’s over 10,000 messages, but the same strategies work.

Good Stuff to Do Along the Way

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

Developers are people just like you are. They may know their code very well, but they may not be the most brilliant writers. And though some messages are written by professional user experience designers, some 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. 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, and there should be more. Here’s the localization guide for French, for example. Create your own with the title “Localisation guidelines/xyz” where “xyz” is your language code.

As in Wikipedia, Be Bold.

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

Well done and congratulations.

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

The way I do this is having a list of links on my translatewiki.net user page. I click them every day, and if there’s anything new to translate, I immediately translate it. Usually there is just a small number of new messages to translate; I didn’t measure, 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. The same techniques apply everywhere.

What Do I Get for Doing All This Work?

The knowledge that thanks to you people who speak your language can use Wikipedia without having to learn English. Awesome, isn’t it?

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

Is There Any Other Way in Which I Can Help?

Yes!

If you find this post useful, please translate it to other languages and publish it in your blog. No copyright restrictions, public domain (but it would be nice if you credit me). 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.

27 August, 2015 01:05 PM

This post is based on my personal need to mount/umount some network shares automatically when I’m switching between networks (e.g Homer/Office). Later on I was looking to make it more modular and came out with this solution, which can be further extended.

NetworkManager have a nice option to execute scripts after ones connect/disconnect to a network, you can find more in the Arch wiki page including some examples.

The problem I had with the way dispatcher.d works is that it execute all the files in the dispatcher.d folder in a linear order, and you have to code each script to handle the interface, connection state and the network you’re connecting to, so at first all my scripts looked something like this,

#!/bin/sh
### ONE OF OLD SCRIPT FORMAT

USER='username'
REMOTE='user@host:/remote/path'
LOCAL='/local/path'

interface=$1 status=$2
if [ "$CONNECTION_UUID" = "uuid" ]; then
  case $status in
    up)
      export SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')
      su "$USER" -c "sshfs $REMOTE $LOCAL"
      ;;
    down)
      fusermount -u "$LOCAL"
      ;;
  esac
fi

I hated that I had to replicate the if/case template for each script I was adding, so I came with a different approach. And in my current setup I added the following file to the dispatcher.d folder

#!/bin/bash

DEVICE=${1}
STATE=${2}
CWD=$(dirname "$0")

LOG='/var/log/NetworkManager_dispatcher.d.log'

# DEBUG
echo "$(date +"%F %T") Called with ($*) and connection uuid is: ${CONNECTION_UUID}" >> ${LOG}

# Needed only if you need to display notification popups
#export DISPLAY=:0.0
#export $(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$(pgrep session)/environ)


for FILE in ${CWD}/${CONNECTION_UUID}/${STATE}/*
do
        #DEBUG
        echo "$(date +"%F %T") Running ${FILE}" >> ${LOG}
        . "${FILE}"
done

NetworkManager pass 2 parameters to each script it runs under the dispatcher directory,

• $1 == The Device name, e.g eth0/enp0s25, tun0
• $2 == The Connection state, e.g up/down, vpn-up

And so if we have connected to the home network with, The “master” script will list all the files under 

${CONNECTION_UUID}/up

And so my dispatcher folder structure look like this,

# tree /etc/NetworkManager/dispatcher.d 

/etc/NetworkManager/dispatcher.d 
├── 4237f1af-15bf-46f7-a3a1-9a37c0d075de/
│   ├── down/
│   │   └── 00-umount-freenas-media*
│   └── up/
│       ├── 00-mount-freenas-media*
│       ├── 70-wifi-wired-exclusive.sh*
│       └── 99-set-display*
├── fdd94fcd-c801-401c-9caa-ebb21e10bc9e/
│   ├── down/
│   └── up/
│       └── 99-set-display*
...
├── Home -> 4237f1af-15bf-46f7-a3a1-9a37c0d075de/
├── Office -> fdd94fcd-c801-401c-9caa-ebb21e10bc9e/
...
└── 88-MASTER-DISPATCHER*

Remarks

• Make sure to uncheck the “Auto connect to this network” for each profile in NetworkManager.
• You will need to create the folders hierarchy your self.
• Make sure the files under the dispatcher folder are marked as executables.

Links:

• NetworkManager – Arch wiki

15 August, 2015 08:28 PM

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

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

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

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

1. רספברי פאי 2, עם קופסת ABS קשיחה וספק כוח – סביבות $42. אם אתם רוצים ספק שגם יודע לדחוף זרמים כראוי, אני יכול להמליץ על המפלץ הזה.
2. להתקין דביאן וקודי על כרטיס 16GB, נגיד עוד כ$5.
3. כבל HDMI.
4. זהו. סטרימינג מהרשת, מכוננים של USB או משרת הטורנטים שבחדר העבודה. מי צריך יותר מזה, תכלעס? אה, וזה אפילו מריץ מיינקראפט לילדה, אז בכלל…

אופציונאליים:

• להתקין הפצה מוקדשת למדיה בשם OpenELEC
• להוסיף דונגל WIFI שנתמך בלינוקס ללא מאמץ.
• לקנות מקלט DVB-T נתמך לינוקס ולקלוט עידן+, ואז כנראה (עוד לא ניסיתי) אפשר לשפר ביצועים ע"י רשיון MPEG2 בחומרה. עוד מידע באתר LinuxTV.
• להתקין BerryBoot אם רוצים לנסות הפצות שונות בנוחות.
• עכבר אלחוטי, מקלדת אלחוטית, עכבר אויר וכדומה.

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

אני מקווה שלא שכחתי כלום. בהצלחה!

09 August, 2015 05:11 PM

This YouTube video doesn’t need any further explanation beside it’s title: The Drupal Rap song – Everyday I’m Drupalin’

The post The Drupal Rap song – Everyday I’m Drupalin’ appeared first on Liran Tal's Enginx.

13 April, 2015 05:26 PM

My predecessor(s) had left a bunch of people at my work place (not even developers) with sudo access to chown and chmod – for the purpose of data management. For a while I had tried to explain that having sudo access to just those two commands is effectively having full root access on the machines.

I had to demonstrate it. So I did:

cat <<EOF >> make-me-root.c
#include <unistd.h>
int main() {
    setuid(0);
    execv("/bin/bash", NULL);
    return 0;
}
EOF

gcc -o make-me-root make-me-root.c
sudo chown root make-me-root
sudo chmod u+s make-me-root

./make-me-root

Alright, demonstrated. Now it’s time for the raising eyebrows to follow.

And now also comes the part where I know it’s almost impossible to revoke privileges from people after they got used to a broken workflow.

30 January, 2015 12:43 AM

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

The post נקסוס 4 לא עובד על פלאפון? appeared first on לינוקס ותוכנה חופשית.

25 December, 2014 06:55 PM

הטקסט המלא

23 October, 2014 12:30 AM

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

Full text

14 September, 2014 06:20 PM