פורסם ב

EBuild

הפוסט הזה מיועד למתכנתי ג'אווה שעובדים עם Eclipse.

אז אתם מתחילים פרוייקט, מפתחים, משתמשים בכל מני JARים מפרוייקטים אחרים בתוך הסביבת עבודה, מוסיפים פרוייקטים אחרים לרשימת התלויות של הפרוייקט שלכם, והכל עובד בתוך Eclipse.
ואז אתם צריכים לשחרר JAR שירוץ מחוץ לסביבת הפיתוח שלכם.
פה יש כמה אפשרויות:
1. להשתמש באופצית הExport JAR של Eclipse.
2. ליצור build.xml לפרוייקט

לפרוייקטים פשוטים, האפשרות הראשונה תספיק, אבל היא בהחלט לא עושה נעים בבטן. כדי ליצור את הJAR חייבים את Eclipse, וזה לא מאוד מיקצועי.
האפשרוית השניה היא מה שכמעט כולם עושים:
בדרך כלל מעתיקים build.xml מהפרוייקט השכן, ומתחילים לעקם אותו עד שיתאים לפרוייקט הנוכחי.
על הדרך עוד פעם מוסיפים – הפעם לbuild.xml החדש – את המסלול לJARים שהפרוייקט צריך כדי להתקמפל, ואולי גם את המסלול לספריות הbin של פרוייקטים אחרים שהפרוייקט הזה צריך, או אולי פשוט קריאה לקובץ הbuild.xml של הפרוייקטים האלו, ואז שימוש בתוצרים שלו.
אחרי זמן שיקח בין חצי שעה לחצי יום, תלוי בבלאגן שיש לכם בפרוייקט, כנראה תהיה לכם מערכת build עובדת לפרוייקט, שעושה בדיוק מה שאתם רוצים.
תהיה לכם תחושה נעימה בבטן, כי תוכלו לבנות את הפרוייקט שלכם מחוץ לEclipse (וככה גם אחרים אם בניתם את העסק נכון).

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

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

המפתח העצלן כבר מזמן שאל את עצמו: "מה, אין דרך אחרת?"
הרי לרוב הפרוייקטים, Eclipse מכיל את כל המידע שצריך בשביל לבנות אותם.
מעבר לזה, המידע הזה תמיד נכון בהגדרה כי אחרת לא תוכלו לפתח כלום וזה יהיה הדבר הראשון שתתקנו ברגע שתעשו איזה שינוי.
Eclipse שומר את רוב המידע בתוך קבצי ה.claspath בתוך כל פרוייקט (וגם קצת בתוך קבצי ה.project). הקבצים האלו הם קבצי XML פשוטים למדי, שלא השתנו משמעותית מאז ימי Eclipse הראשונים.
אז הנה רעיון:
מה אם במקום לשכפל את המידע גם בEclipse וגם בbuild.xml, ניצור build.xml אחד שקורא את המידע על הפרוייקטים מEclipse, מבין מה סדר הבניה הנכון של הפרוייקטים, איזה JARים צריך לכל פרוייקט ובונה את העסק לפי זה?
אותו build.xml קסום ומופלא יעבוד כמעט לכל פרוייקט Java שפותח בתוך Eclipse בצורה שקופה, בלי שום התעסקות ותחזוקה של קובץ build.xml ספציפי לפרוייקט.
נשמע טוב מכדי להיות אמיתי?
ובכן, שחררתי מערכת כזו בדיוק, ולמערכת קוראים ebuild.
התחלתי לפתח אותה לפני שנים, והיא ליוותה אותי דרך ארבע מקומות עבודה עד עכשיו (למעשה דרך כל מקומות העבודה שהיו לי בתחום ההיטק).
המערכת משוחררת תחת רשיון FreeBSD (רשיון תעשו מה שבזין שלכם, לא מזיז לי) ודף הבית שלה הוא http://ebuild.firefang.net.
בגדול, כדי להשתמש בה, מה שצריך לעשות זה:

  • לקחת את הקוד שלה ולהכניס לפרוייקט נפרד בסביבת העבודה.
  • להעתיק את example-common.properties לcommon.properties (הוא מכיל הגדרות ספציפיות למחשב שלכם, למרות שכרגע אין מה להתעסק איתו ברוב המקרים).
  • ליצור קובץ build.properties בתוך הפרוייקט שאתם בונים (מאוד פשוט ומינימלי)
  • להריץ עם ant -Dproject=YOUR_PROJECT, כאשר YOUR_PROJECT הוא השם שם הפרוייקט שלכם בסביבת העבודה.
  • לקחת את התוצרים האיכותיים מספרית הbuild שנוצרה תחת הפרויקט.

התוצר יהיה JAR שניתן להריץ בעזרת java -jar file.jar, וכן זיפ שכולל את הJAR ואת הספריות הדרושות כדי להפיץ את התוכנית.

נכון לכרגע, המערכת די בסיסית ומסוגלת לבנות פרוייקטי Eclipse בתוך סביבת העבודה (Workspace) שלכם.
בהמשך אני מתכנן להוסיף אפשרות לתייג פרוייקטם ולבנות ישר מCVS/SVN בלי לגעת בקוד בסביבת העבודה (זה דרוש כדי לשחרר גרסאות בצורה מסודרת).
בנוסף, אני מתכנן להוסיף אפשרות לebuild-hook.xml אופציונלי שיהיה ספציפי לפרוייקט שיכיל כל מני דברים שבאמת ספציפיים לפרוייקט מסויים.

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

  • ebuild תומך בזה בצורה טובה, אבל לא ברור לי אם הוא יתמודד עם JARים חיצוניים.
  • ebuild לא תומך בכל מני הרחבות מוזרות של eclipse, שמסתמכות על מידע שלא מופיע בקבצי ה.classpath. למשל 'user libraries'. אם אתם רוצים שהוא יעבוד בשבילכם, תעבדו פשוט.

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

פורסם ב

Day of release

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

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

Antenna 1.1.0-beta
קיבלתי תרומת קוד גדולה מצוות MTJ, הקוד מממש את הPreprocessor שכתבתי בANTLR 3.0, מה שיאפשר הכנסה של הPreprocesror לתוך MTJ.
MTJ הוא פרוייקט שמטרתו להכניס תמיכה בפיתוח קוד J2ME בEclipse. הפרוייקט יתבסס על EclipseME, שהוא הסטנדרט דה-פקטו לפיתוח J2ME עם Eclipse. הPreprocessor שלי כבר נמצא בתוך EclipseME די הרבה זמן, אבל היתה בעיה עם הרשיון של ANTR 2.7.7 שבו השתמשתי כדי לפתח אותו, ו Eclipse legal לא אישרו את הכנסת הקוד שלי לMTJ מהסיבה הזו.
הצוות של MTJ בחר לבצע Porting של הPreprocessor כך שיעבוד עם ANTLR 3.0 כי הרשיון שלו תואם את זה של Eclipse.
לפני כמה ימים הצוות קיבל אישור מEclipse legal לתת לי את הקוד שהם יצרו כדי שאני אקלוט אותו לתוך Antenna.
הקוד היה איכותי, ועבר את כל בדיקות היחידה שהגדרתי כבר, מה שנתן לי ביטחון גבוה שהוא עובד כמו שצריך. אחרי כמה שעות עבודה, הקוד הוטמע והיום שחררתי גרסא חדשה של Antenna שמשתמשת בPreprocessor החדש כברירת מחדל.

פורסם ב

גלויה מסין

יוצא לי לעזור לאנשים בפרוייקטי קוד פתוח שאני מעורב בהם מפעם לפעם, תמיד אני מקבל תודה, אבל אף פעם לא קיבלתי גלויה.
עזרתי לוויליאם בבעיה שהיתה לו בשימוש בAntenna, פרוייקט קוד פתוח שעוזר בתהליך הבניה של ישומי ג'אווה לסלולריים, וקיבלתי גלויה והזמנה לשנחאי :).
photo-000001.JPG
photo-000002.JPG

פורסם ב

ניהול מלאי חומרה – Inventory

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

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

האפשרות שחסרה לי ביותר שם היא האפשרות להצמיד מסמכים (צילומים של קבלות ותעודות אחריות, צילומים של רכיבי חומרה וכו'), לכל רכיב.
inventory.jpg

פורסם ב

ביצועים של פענוח וידאו 1080p בקידוד H264

התחלתי לבדוק איך המחשב בסלון מתמודד עם וידאו של 1920X1080 בקידוד H264 – זה וידאו Full HD שיש בBlueRay, וזה מה שאני ארצה להציג על המקרן (שמתמהמה קצת, אולי היום).
המחשב הוא פנטיום D במהירות שעון של 3Ghz, זכרון של 2GB וכרטיס מסך GeForce 8600 GT 512MB, לכאורה לא אמור להיות קובץ וידאו שיהיה מעבר לכוחותיו.
ניסיתי לנגן עליו עם mplayer קובץ דגימה של Matrix – שישים שניות סרט בקובץ של 70 מגה – והמחשב לא סחב אותו כמו שצריך:
הווידאו זז לאט, והסאונד יצא מסינכרון עם התמונה מהר מאוד.
מחשב שהיה פאר היצירה לפני שנתיים, לא סוחב היום משימה של ניגון וידאו. מי אומר שאין צורך במעבדים יותר חזקים?
לשם הבדיקה, ניסיתי את אותו קובץ במחשב החדש – פנטיום Core-DUO 3Ghz, זכרון 4GB וכרטיס מסך GeForce 9800 GT 512MB והוא סחב אותו יפה מאוד.
אז נראה על פניו שצריך מפלצת רצינית כדי לנגן את הקבצים האלו, יותר מהתפלצון שיש לי בסלון.
נסיון ראשון, הדרייבר של כרטיס המסך:
הבדיקה שלי היתה כשxorg, שרת הX (השרת שאחראי על מערכת החלונות והתצוגה) עבד עם הדרייבר הגנרי vesa ולא עם הדרייבר של NVidia כי היתה לי בעיה עם הדרייבר האחרון שלהם.
ניסיתי את הדרייבר nv, שהוא דרייבר פתוח קוד לכרטיסי NVIDIA שלא תומך בהאצת תלת מימד, ולא היה שיפור.
התקנתי את הדרייבר של NVIDIA במחשב בסלון (ונאלצתי להשתמש בגרסא קודמת שהתקנתי לפני כמה שבועות במחשב החדש), עדיין אין שיפור.
למרות שכרטיסי NVIDIA החדשים מגיעים עם תמיכה בפענוח קבצי וידאו בחומרה – טכנולוגיה בשם PureVideo, הדרייברים שלהם ללינוקס לא תומכים בזה, ולכן אף פרוייקט קוד פתוח ללינוקס לא משתמש ביכולת הזו של החומרה.
אז שימוש בחומרה הזו יורד מהפרק כדי להאיץ את העסק, לפחות עד שNVIDIA ישחררו דרייבר שתומך בזה.

נסיון שני, שדרוג של mplayer:
החבר'ה בערוץ הirc של mplayer נבהלו כשסיפרתי להם על איזו גרסא אני בודק:
[code]
[rsk] same mplayer version's?
[omry] hmm, sec
[rsk] also using svn generally speeds up things compared to RC2.
[rsk] especially if you are using a distro package
[omry] hmm, actually the mplayer on the slower box looks older :MPlayer 1.0rc1-4.1.2 (C) 2000-2006 MPlayer Team
[omry] compared to MPlayer dev-SVN-r25315 on the faster box
[rsk] that's ancient
[rsk] please burn it with fire
[omry] dispatching the nukes 🙂
[/code]

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

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

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

נסיון חמישי ודי:
הרצתי את mplayer עם פרמטר -benchmark, והוא סיפר לי די מהר שהמחשב איטי מדי:

[code]
************************************************
**** Your system is too SLOW to play this! ****
************************************************

Possible reasons, problems, workarounds:
– Most common: broken/buggy _audio_ driver
– Try -ao sdl or use the OSS emulation of ALSA.
– Experiment with different values for -autosync, 30 is a good start.
– Slow video output
– Try a different -vo driver (-vo help for a list) or try -framedrop!
– Slow CPU
– Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
– Broken file
– Try various combinations of -nobps -ni -forceidx -mc 0.
– Slow media (NFS/SMB mounts, DVD, VCD etc)
– Try -cache 8192.
– Are you using -cache to play a non-interleaved AVI file?
– Try -nocache.
[/code]
יופי של הודעת שגיאה.
כדי לשלול בעיה של קול או דרייבר תצוגה איטי, הרצתי את mplayer עם
[code]
mplayer -benchmark -vo null -ao null file.mkv
[/code]
מה שמריץ את הווידאו בלי סאונד ובלי תצוגה – פענוח בלבד – לא היה שיפור.

ניסיתי את ההצעה השניה:
[code]
mplayer -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all file.mkv
[/code]
פה כבר היה שיפור אדיר – הסרט רץ חלק
לא הרגשתי ירידה באיכות, למרות שאמורה להיות איזו שהיא פגיעה באיכות.

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

פורסם ב

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

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

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

אז אם לא פתרון ברמת הבלוקים, נשאר פתרון ברמת מערכת הקבצים.
mhddfs הוא פתרון כזה בדיוק.
הרעיון הוא שמאחדים כמה מערכות קבצים, אחת על השניה בoverlay. כשפותחים קובץ הקובץ שיפתח יהיה הקובץ במחיצה הראשונה (אם במקרה אותו קובץ מופיע באותה באותה ספריה ביותר ממערכת קבצים אחת, נראה רק את הראשון (שיסתיר את כל האחרים).
כשכותבים קובץ, mhddfs עושה משהו מעניין:
כשיוצרים קובץ, המערכת תבחר אוטומטית את המחיצה עם הכי הרבה מקום בשבילו. בנוסף, אם במהלך כתיבת הקובץ נגמר המקום, הקובץ מוזז בצורה שקופה למחיצה עם מקום (כמובן שאם אין כזו מחיצה, האפליקציה מקבלת את השגיאה הרגילה).
אחד היתרונות הוא שהקבצים עדיין נגישים דרך המחיצות המקוריות, ככה שגם אם hddfs לא עובד משום מה, הנתונים עדיין שם ונגישים.
mhddfs ממומש כמערכת קבצים במרחב המשתמש (FUSE), מה מה שנותן לה יתרונות נוספים, למשל – משתמשים יכולים להשתמש בה חופשי בלי שמנהל המערכת יגדיר מראש את התצורה בקובץ fstab.

[code]
# mhddfs /mnt/500gb/,/mnt/200gb,//mnt/160gb /storage -o allow_other
[/code]

יוצר מערכת קבצים חדשה ב/storage, בנפח כולל של 775GB עם מקום פנוי כסכום המקום הפנוי בשלושת המחיצות:
[code]
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 459G 258G 179G 60% /mnt/500gb
/dev/sdb2 159G 17G 142G 11% /mnt/200gb
/dev/sda3 158G 138G 21G 87% /mnt/160gb
/mnt/500gb;/mnt/200gb;/mnt/160gb 775G 412G 341G 55% /storage
[/code]

כדי להגדיר את זה בfstab, נשתמש בשורה המוזרה הבאה (תחביר סטנדרטי לfuse) בfstab:
[code]
mhddfs#/mnt/500gb,/mnt/200gb,/mnt/160gb /storage fuse defaults,allow_other 0 0
[/code]

דרך חבילת הדביאן היומית.

פורסם ב

רשיונות קוד פתוח

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

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

כדאי לשים לב שהרשיון מדבר על הפצה ולא על שימוש. מותר לכל אחד לקחת קוד ששוחרר תחת GPL, ולהשתמש בו כרצונו בלי הגבלות ובלי חובות כל עוד התוצר לא מופץ. לכן זה בסדר להשתמש בקוד ברשיון GPL לשימוש פנימי בחברה (ולא בגלל שאף אחד לא יגלה, אלא כי זה ממש בסדר). כמו כן, אפשר להשתמש חופשי בקוד GPL בצד השרת, בלי לחשוש – גם אם השרת משרת משתמשים חיצוניים לארגון.
יש לציין שתוצרים של תוכנית ששוחררה תחת GPL לא נדבקים בGPL, למעט במקרים מאוד מיוחדים בהם התוצרים מכילים חלקים מהתוכנית המקורית (כמו למשל YACC – תוכנית לייצור קוד לפענוח שפות).
הגרסא הנפוצה ביותר של GPL היא גרסא 2, וממש לאחרונה יצאה גרסא שלוש של GPL, שנועדה להתמודד עם השינויים שהתרחשו בעולם התוכנה מאז שוחרר GPL2 ב1991 – למשל הפריחה של תעשיית הפטנטים; בנוסף, GPL 2 נכתב תוך מחשבה על חוק זכויות היוצרים האמריקאי, ולכן הוא לא מאוד מתאים לשימוש מחוץ לארצות הברית.
patents growth

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

רשיונות "עשה מה שאתה רוצה"
הרשיונות הבאים נופלים לקטגוריה של "עשה מה שאתה רוצה", כדאי לקרוא את הרשיון עצמו לפני השימוש, אבל בגדול המגבלות שהם מטילים הם מינימליים אם בכלל, וקל לעמוד בהם (דברים מסוג של לצרף עותק של הרשיון למוצר הסופי ו/או לציין שנעשה שימוש בקוד מסויים).
Apache license , שווה לקרוא את הFAQ שמסביר בדיוק מה מותר ומה אסור בשפת בני אנוש.
BSD license, אחד הרשיונות הפשוטים והמתירנים ביותר.
Mozilla public license – הרשיון של ארגון מוזילה, שמשחרר בדרך כלל תחת MPL, GPL וLGPL את הקוד שלו (הרשיון לבחירת המשתמש). עדכון: לא ממש מתאים לקטגוריה הזו (תודה לצפריר).
Eclipse public license, הFAQ
: Public domain נחלת הציבור. רשיון "העשה מה שבא לך" האולטימטיבי.
באופן מפתיע, לפעמים הוא מתירני מדי – Eclipse למשל מסרבים לקבל קוד תחת הרשיון הזה כי הם לא יכולים להבטיח שכולו נקי מזכויות יוצרים. (הטענה הזו מבוססת על נסיון שלי עם Eclipse, שרוצים לקלוט קוד שכתבתי שמסתמך על קוד תחת הרשיון הזה (ANTLR V2)

פורסם ב

ניהול מלאי חומרה

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

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

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

פורסם ב

CoreCodec וגוגל קוד

גוגל סגרו את פרוייקט CoreAVC שהתארח בגוגל קוד בעקבות דרישת חברת CoreCodec – בטענה של הפרת זכויות יוצרים לפי הDMCA.
הפרוייקט סיפק פאצ'ים לmplayer ולmythtv ולxine שאיפשרו שימוש בקודק לפענוח וידאו בפורמט H.264 שפותח בCoreCodec, ולדברי המפתחים לא סיפק את הקודק עצמו להורדה.

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

The details are as follows:
Infringing Materials Hosted on and/or Linked To From the Site. The Site hosts and/or contains one or more links to CoreAVC, which contains CoreCodec's copyrighted Software. We have directly verified by downloading the file from the Site provided by Google Inc. that the file does include CoreCodec's copyrighted Software.

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

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

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

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

פורסם ב

השדרוגים הם מהשטן

זוכרים שהזמנתי כונן קשיח נוסף וכונן DVD חלופי במקום זה ששבק?
שניהם היו כמובן בממשק SATA, והתסבר שהמחשב שאליו הם מיועדים סבל ממחסור חמור בערוצי SATA פנויים, כל שני הערוצים שעל לוח האם שלו היו תפוסים.
בינתיים התקנתי את הדיסק במחשב השני, והזמנתי כרטיס בקר SATA שמוסיף עוד ארבעה ערוצי SATA. אתמול הוא הגיע לשמחתי, וכשחזרתי מהעבודה התיישבתי להתקין את הבקר, את הכונן הקשיח ואת הכונן DVD.
בהתחלה פשוט התקנתי את הכל, הדלקתי את המחשב וקיוויתי לטוב – תקוות שהתבדו מהר מאוד: המחשב נתקע בBOOT, לפני שהתחיל להעלות את GRUB (טוען הBOOT של לינוקס). התחלתי לשחק קצת בחיבורים וגיליתי שהמחשב לא אוהב שאני מחבר את הDVD לבקר הSATA החדש, ולכן חיברתי אותו ישירות ללוח האם ואת אחד משני הכוננים הקשיחים הישנים חיברתי לבקר הSATA. אחרי שהמחשב הצליח להכנס לGRUB כאשר כל ארבעת הכוננים מחוברים (שני הרדיסקים ישנים, אחד חדש וכונן DVD חדש), הקרנל התחיל לעלות ונתקע כמובן כשחיפש את מערכת הקבצים במחיצת השורש (/)
חשבתי לעצמי, בטח הוא לא אוהב את השינויים, וניתקתי הכל כדי לוודא שהוא עובד במצב שבו הוא היה קודם.
במפתיע, הוא עדיין סרב לעלות כשלא מצא את מערכת הקבצים של /.
עכשיו כבר התחלתי לנסות להעריך כמה זמן יקח לי להתקין את הכל מחדש ולהביא את העסק למצב עובד (זה שרת הדואר שלי, ולא רציתי להשאיר אותו לא עובד), לא אהבתי את ההערכה.
החלטתי לנסות לעלות מדיסק של Knoppix 4.0 ישן שהיה לי, אבל הוא טען שהביוס שלי דפוק במיוחד וסירב לעלות. חשבתי לעצמי שאולי הדיסק KNOPPIX דפוק במיוחד וצרבתי את Knoppix 5.1, שהסכים עם הדיסק הקודם בדיאגנוזה וסרב גם הוא לעלות.
שלפתי מהמחסן את אחד מכונני הDVD הישנים שלי, שהתעטר בכיתוב "אולי דפוק, 22/2/2008", ניסיתי אותו ומשם דווקא Knoppix הסכים לעלות (לא שכחתי לסמן את הכונן בכיתוב "מספיק טוב בשביל קנופיקס, 14/4/2008") – בשיטוט במחשב מתוך הקנופיקס שמתי לב שהכונן החדש התיישב לו על SDA ודחף את הכונן הראשון שהיה בSDA אל SDC. זה גרם לי לחשוב שאולי זו הבעיה.
ביצעתי BOOT רגיל אל GRUB, ופתאום שמתי לב שהשורה של הקרנל נראית ככה:
[code]
kernel /boot/vmlinuz-2.6.24-1-686 root=/dev/hde1 ro
[/code]
שורה שאופיינית לטעינת הקרנל מדיסק ATA רגיל ולא מSATA (שמופיע תחת sdx ולא תחת hdx).
התחלתי לנחש ולנסות כל מני אפשרויות ובסוף הצלחתי לבצע BOOT כאשר השורש בsdb2, סוף סוף קצת התקדמות!
חיברתי את כל הכוננים, ניחשתי וניחשתי שוב עד שהצלחתי עם sdc2, ונכנסתי למערכת.
לא ממה התחשק לי לשנות את הfstab ואת קובץ התפריט של GRUB לתצורה החדשה, כי ידעתי שברגע שאני אשנה משהו בחומרה הכל ישבר שוב.
נכנסתי ל#debian@irc.freenode.net, ושאלתי איך מונעים מהקרנל לשנות את שמות הכוננים כל פעם שמשהו משתנה.
ענו לי שאפשר, אבל זה קשה, ועדיף בכלל לעגן מחיצות לפי הUUID, ולא לפי שם הכונן.
UUID למחיצה? לא ידעתי שיש!
מסתבר שזה פשוט במיוחד, החל מגרסא מסויימת של הקרנל, יש בdev ספריות חדשות:
[code]
/dev/disk/by-id/
/dev/disk/by-label/
/dev/disk/by-path/
/dev/disk/by-uuid/
[/code]

הספריה שמעניינת אותנו במקרה הזה היא /dev/disk/by-uuid/ שמכילה קבצים שנראים כך:
[code]
0427f3ec-17e1-4cd1-b195-7f5bdf861a28 -> ../../sdc3
3f7f2c77-88af-4e9a-a139-ba95900e0354 -> ../../sdb1
[/code]

אלו לינקים סימבוליים שנוצרים אוטומטית, ומאפשרים גישה אל המחיצה בצורה שאינה תלויה בשם של הכונן עליו היא יושבת.
המזהה היחודי (UUID) של המחיצה לא משתנה עד שלא יוצרים מחדש את המחיצה (או אולי מפרמטים אותה, אני לא בטוח).
כמובן שאפשר להשתמש בו גם מתוך קובץ התפריט של grub:
[code]
kernel /boot/vmlinuz-2.6.24-1-686 root=/dev/disk/by-uuid/8397dc08-be26-491d-9a06-c3fc93303d82 ro
[/code]

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

אגב, לדעתי מה שגרם לכל הסיפור הזה היה קודם כל שדרוג שביצעתי לקרנל דרך apt-get לפני מספר שבועות, שקילקל את menu.lst של GRUB.
בגלל זה גם כשניתקתי את הכל וחזרתי למצב הראשוני עדיין לא הצלחתי לבצע BOOT.
המסקנה שלי היא שצריך לבדוק טוב טוב את menu.lst אחרי שדרוג של הקרנל (אם אני אגיד את זה בקול רם אולי אני אזכור את זה בפעם הבאה!).
בנוסף, כדאי להשתמש בUUID ולא בשם הדיסק כשמעגנים מחיצות.

לבסוף, אני גאה לציין שהמחשב הסלוני שלי, שמשמש אותי כשרת דואר וכמכונת ווידאו סלונית שודרג בהצלחה ועכשיו יש לו נפח איחסון של 200+200+500=900GB.
האח, הידד.