תגית: google

about

פרסות הזברה

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

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

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

  1. user@linux:~> cat /etc/issue
    Welcome to openSUSE 11.1 - Kernel \r (\l).
    []
  2. כצפוי מכרום חסר התוספים []
  3. ולראיה פרסום זה []
report

ושמחת בtagך

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

נושא נוסף הוא כיצד להתמודד עם מידע שכבר קיים. וזו סוגיה רב שכבתית:

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

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

בחלומי אני מנהל ענן תגיות אחד, הכולל תגיות פרטיות ותגיות משותפות, תגיות ב-WordPress, Drupal, Google Apps ומערכת הקבצים שלי.

feedback

וכעת, למאזינינו בחו"ל

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

לחסרי סבלנות, תרגומים מיידיים, בחסות גוגל:

אנגלית:

It turns out that there are two readers abroad who do not speak Llachodis. I conceived using plugin translation, but after I received documents from Argentina who Lsfngalit automatic translation, I think I'll wait.
Impatient, instant translations, sponsored by Google

יידיש:

עס טורנס זיך אַז עס זענען צוויי רידערז ין דער פרעמד, וואָס זיי נישט רעדן ללאַטשאָדיס. איך קאַנסיווד ניצן פּלוגין איבערזעצונג, אָבער נאָך איך באַקומען דאָקומענטן פֿון ארגענטינע וואָס לספנגאַליט אָטאַמאַטיק איבערזעצונג, איך טראַכטן איך וועט וואַרטן.
ומגעדולדיק, רעגע טראַנזליישאַנז, באצאלטע דורך גוגל

וספרדית:

Resulta que hay dos lectores en el extranjero que no hablan Llachodis. Concebí utilizando la traducción de plug-in, pero después de haber recibido los documentos de Argentina que Lsfngalit de traducción automática, creo que voy a esperar.
Impaciente, traducciones instantáneas, patrocinado por Google

news

סולמות וסבלנות

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

faq

סקלביוליות

ניסיתי למצוא מונח בעברית ל-Scalability. התרגום היחידי שמצאתי הוא הקישור המביך הבא1.

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

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

צחוק בצד, אחד הטיעונים של אנשי ה-IT היא: "תנו לנו משאבים כמו X, ותקבלו שרות כמו X". גוגל, למשל, מתחייבת לזמינות של 99.9% (חודשית). דהיינו 72 שעות כשל, עדיין מהווה עמידה בתנאים. אני מצליח לשמור על 99.4%. אבל זמינות ועמידה בתנאי שרות אינה מעניינית את המשתמש ברגע שבו הוא זקוק לשרות. לא בכדי מיקור החוץ זוכה לכותרות, הן בשרות והן בפיתוח.

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

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

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

  1. ואני לא היחידי שמחפש מונח שכזה []
  2. ועלי []
content