registery ?

[KKnDoIt]

SHELL מול GUI: הדעה שלי

לדעתי ההבדל בין SHELL לבין GUI שונה מאוד בחלונות וביוניקס: בחלונות, הדרך _היחידה_ לעשות חלק גדול ממהגדרות היא באמצעות GUI. מאחר וההגדרות שמורות ברג'יסטרי, לפעמים בצורה של מספרים שהרכבם לא קריא לבני אדם (מספרים בינאריים), ומאחר והמיקום של המפתח לא מפורסם באופן פורמלי ונגיש, זו הדרך לעשות את הדברים. מעבר לכך, ברור כי קל יותר לעבוד עם גואי מאשר לפתוח את עורך הרג'יסטרי, שהוא ממילא עוד סוג של תוכנת GUI. ביוניקס הגישה שונה לחלוטין, ואת זה צריך להבין כאשר מדברים על ההבדל בין שתי השיטות: כמעט כל ההגדרות רשומות בקבצי טקסט הקריאים לבני אדם, הכתובים בצורה מבנית (בדומה לקוד מקור של תוכנית בשפת C, למשל), וניתנים לשינוי בקלות על ידי עריכה בעורך טקסט. אני אומר "כמעט" ולא "כל" כי אני לא איש יוניקס מקצועי, ואני עובד עם CYGWIN ולא יוניקס של ממש. מאחר וההגדרות שמורות בקבצי טקסט, ניתן להכין בקלות כלים לעריכה אוטומטית שלהם, הן משורת הפקודה והן כלי GUI. זה כלל לא משנה אם עובדים עם מסוף טקסט או עם GUI: בכל מקרה השינויים ירשמו בקבצי טקסט. זו בדיוק מהות ההבדל בין שתי המערכות: בלינוקס: הגואי הוא מעטפת שמשמשת כדי להסתיר את הפקודות הישירות מהמשתמש, אבל בסופו של דבר הן עושות את אותו השינוי בקבצים שאפשר לעשות באופן ישיר באמצעות כלי שורת פקודה. לכן, השאלה מה קל יותר תלויה באיכות המעטפת ובאיכות הגואי (BASH ו- ZSH מול KDE ו- GNOME, וכדומה). יתירה מזו: מאחר וכלים גרפיים הם מעטפות המבצעים את אותה עבודה של כלי שורת הפקודה, אפשר בקלות יחסית לפתח כלים חדשים, גרפיים (מבוססי דפדפן, או ספריית גואי אחרת) כדי לבצע קונפיגורציה של תוכנות שונות, שעד עכשיו היה ניתן להגדירן באמצעות עורך טקסט או כלי שורת פקודה. בחלונות אין ממש ברירה. המעטפת _לא_ מאפשרת לעשות הכול, ואת מה שהיא עושה, היא עושה באמצעות עריכה של הרג'יסטרי. מבחינה זו, זה מצב הפוך ללינוקס: בחלונות המעטפת היא "מעטפת" עבור הגואי. ועוד פרט קטן: המטעפת של חלונות (CMD) לא מדגדגת אפילו את הרמה של מעטפת מודרנית ללינוקס (BASH, למשל). פשוט אין מה להשוות. להשוות בין CMD לבין BASH זה כמו להשוות בין הגואי של חלונות 3.11 לגואי של חלונות XP.

 

[אינגולמו]

אני מסכים

כי זה נכון ששיטת העבודה תלויה באיכות ה-SHELL ו-GUI. זה גם מה שאני מנסה לטעון פה. יש אנשים שחושבים אחרת, כמו אלדד, ואני לא אשבור את הראש בלנסות לשכנע אתכם, כי כנראה יש איזה הבדל בסיסי יותר בדרך הגישה/ההבנה שלנו בנושא. ות'אמת, אין לי כח לנסות לברר אותו

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

אובייקטיבית, אני יכול רק להעיד לטובת WINDOWS, שה-SHELL שלה התחזק מאוד בשנים האחרונות, וכן ישנם SHELLS ממש טובים (כמו CYGWIN) ו/או תוספות של פקודות (כמו RESOURCE KIT). אני אישית משתמש בהם הרבה, אך אני לא אזנח את ה-GUI של מערכת ההפעלה הזו, כי יש לו הרבה דברים להציע כמו שכבר פירטתי.

 

[KKnDoIt]

זה בדיוק העניין:

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

 

[אלדד28]

נו, מילא. אתה לא קורא את מה שכתבתי

בהתחלה, אלא דבק בעמדה שהיא בכלל לא קשורה למה שהעליתי

 

[אינגולמו]

קראתי כל מה שכתבת

 

[אלדד28]

אז הצלחת לפספס אינסוף פעמים את

העובדה שאני מדבר על GUI ועל COMMAND LINE ככלים, ולא מדבר על מערכות הפעלה.

 

[אינגולמו]

גם אני לא דיברתי רק על מערכות הפעלה

 

[אלדד28]

השוואות בין יוניקס לבין WINDOWS?

 

[אלדד28]

פספסת את הנקודה שלי

בהינתן GUI מעולה, שלצידו COMMAND LINE מעולה, ובהינתן שאתה מיומן בשתיהן עד קצה גבול היכולת, ה-COMMAND LINE תמיד יהיה עדיף. כמו שכבר אמרתי, אני לא מדבר רק על מערכות הפעלה. אני מדבר על WEBCAMS, למשל, שנותנים לך לעבוד דרך WEB GUI או דרך TELNET. אני מדבר על ROUTER-ים שנותנים לך לעבוד דרך GUI או דרך TELNET. אני מדבר על studio max או על maya, שנותנות לך לעבוד דרך GUI או דרך COMMAND LINE מובנה בתוך התוכנית. וכן, אני מדבר על עבודה ברמת קבצים ב-WINDOWS בצירוף CYGWIN, ואני מדבר על עבודה ב-UNIX. ב-WINDOWS הבסיסי המושג "COMMAND LINE" כמעט ולא קיים כי הוא מאוד מאוד מאוד מנוון. להשתמש בו זה מיותר, כי הוא לא נותן כמעט כלום. אבל אם מוסיפים לו CYGWIN ועוד כל מיני תוספות, העבודה נהיית קלה מאוד. אה, ועוד דבר - היתרון של COMMAND LINE הוא בדיוק בהרגל, אז ברור שאתייחס להרגל; כשמתרגלים ל-COMMAND LINE העבודה הרבה יותר פרודוקטיבית מאשר דרך GUI.

 

[אינגולמו]

אתה לא יכול

להשוות שום דבר כזה באופן מעשי, כי כמו שאמרתי, אין חיה כזו. במציאות SHELL ו-GUI לא שקולים מבחינת יכולות באף סביבה, וכן אין מישהו הממוקצע בהם עד קצה גבול היכולת. בהנחה שהיתה חיה כזו, אז הדיון התיאורטי שאתה מציע הוא נושא אחר לגמרי. אם GUI ו-SHELL היו שקולים *לכל* פקודה שהיא - גם במהירות השימוש וגם במורכבותו, אז לא היה יתרון בשימוש של אחד מהם. בכל מקרה אחר, האם אפשר להראות שלכל פקודה שלא תהיה, הקונסול יתן פיתרון טוב יותר? בוודאי שלא, מכיוון שההבדלים, כאמור, הם במהירות השימוש, ומורכבות השימוש בפקודה מסויימת. ואז מיידית אפשר להראות דוגמאות שבהן מהירות שימוש באה על חשבון מורכבות שימוש (או ההיפך) ולסתור את הטענה שלך. למעשה, נתתי דוגמאות כאלה בהודעות קודמות שלי. הדוגמאות שנתת רק מחזקות את הטענה שלי, שכן הן ממחישות את ההבדל בין מורכבות השימוש לבין מהירות השימוש. אם ניקח את MAYA לדוגמה, שם ה-GUI עצמו *כתוב* ב-MEL ואפילו אז, שימוש ב-GUI הרבה יותר מהיר (ולכן עדיף) לדברים מסויימים מאשר ה-SCRIPT (ועדיין שים לב שה-SCRIPT יותר עשיר מה-GUI - הם לא שקולים). אני יכול להראות את זה לכל צירוף SHELL-GUI שתציג.

 

[barakbl]

זה פשוט.

כשאתה מרנדר בתלת מימד, או כשאתה רוצה לעבד תמונה, אתה זקוק ליישום גואי. חד וחלק. יחד עם זאת, ישומי גואי חזקים, למשל gimp (תוכנה לעריכת תמונות - www.gimp.org לעוד מידע) יכללו תמיכה בשפות סקריפט כאלה ואחרות שיאפשר לך לבצע דברים מורכבים בזמן קצר. הנקודה היא לא גואי כחלון מול קונסול כחלון שנראה כמו DOS (ככה הכי קל להסביר לכולם מה הכוונה), אלא תפיסה מול תפיסה. התםיסה האחת אומרת שיש רק כפתורי NEXT פשוטים והמון המון רכיבים גרפיים, והתפיסה השניה מניחה שיש משהו בקודקוד של המשתמש ונותנים לו גמישות רבה יותר ובתמורה, הוא צריך להיות יותר מיומן. רוב אנשי היוניקס שדיברת עליהם עם המנדרייק, כבודם במקומם מונח, ואני לא חושב שיש בעיה בגישה שלהם, בדיוק להיפך. אני חובש שאין שום רע בניהול/שליטה על המחשב על מערכת גרפית, אישית, אני כמעט ולא יוצר מהמערכת הגרפית בתחנה שלי (כשאני על שרת אז אין בכלל מערכת גרפית, כמעט תמיד, וטוב שכך), זה מאוד נוח ויעיל שאני יכול לפתוח טרמינלים (או חלונות קונסול) רבים במקביל תחת אותה מערכת גפרית ולנווט בינהם. בשורה התחתונה, הפרודוקטיביות של שימוש בטרמינל, אצל משתמש מנוסה גבוהה בהרבה. אני חושב, שהגישה הגמישה של משתמשי יוניקס ותיקים שעובדים רק או כמעט רק עם קונסול, היא גישה שמאפשרת להם להיות יותר פרודוקטיבים. דוגמא: קח לך סצנריו (אמיתי). כאחד ממנהלי אתר הפינגווין החלטנו יום אחד שאנחנו רוצים לעבור ל utf-8 (יוניקוד). ברגע שההחלטה נפלה היה צורך להמיר את כל העמודים הקיימים (ואת כל מסדי הנתונים!) ל utf-8. עשינו חיפוש של דקה וחצי בגוגל, אודות דרך להמיר ל utf-8 את המסמכים, ובסיומו גילינו שיש פקודה של ה shell שיודעת להמיר מסמך שמועבר אליה כפרמטר, קוראים לה iconv (אגב, זה גם lib שאפשר לשלב באפליקציות שכותבים). מכאן לשם, תוך דקות כתבנו סקריפט שסורק את כל התקיות שאנחנו רוצים במערכת שלנו (כלומר התקיות שבהן אנחנו רוצים שיתבצע השינוי, וזה לא כל התקיות במערכת). את כל הפעולה עשינו דרך ssh, בגלל שאין לנו גישה לשרת. מיותר לציין שגישה ב ssh על פס רחב או אפילו פס צר (שזה מה שהיה לי עד לפני חצי שנה) זה משהו סביר מאוד, מהיר ויעיל. את מסד הנתונים המרנו באמצעות כלי shell של mysql שמאפשר לך ליצא את המסד לקובץ טקסט חיצוני, ביצענו עליו הרצה של iconv ואז העברנו את היצוא בחזרה לשרת, עם התיקונים. צריך להבין, שכל זה לוקח שניות לביצוע, בצורה מרוחקת מאוד יעילה. תאר לך שאת כל זה היינו עושים עם כלים גרפיים.... לכלים גרפיים יש לא מעט יתרונות, בלא מעט מקרים, בעיקר כשאתה מכין תוכנה/אפליקציה ללקוח, שרוצה משהו פשוט וידידותי ולא נדרש שהוא יהיה בעל "פרופסורה" (בכוונה מגזים) במחשבים... אלא שלסיכום, מה שניסיתי לאמר זה, שכלי cmd, כשיש shell טוב ומשתמש מיומן, לעולם יהיו קלים יותר. אפ לפני שנתיים היית שואל אותי, הייתי בדעתך (ואני מדבר על אחרי שהיה לי נסיון של חודשים ואולי אפילו יותר בלינוקס). אלא שעכשיו, אחרי שאני מכיר (לעומק אני חושב) את שני הגישות, אני בדיעה שונה לגמרי, ובכל מה שנוגע לניהול המערכת, אין על היכולות של המעטפת.

 

[אינגולמו]

אני הייתי

עושה בדיוק כמוך. אבל נתתי בנוסף דוגמאות שבהם ה-SHELL היה יוצר לי עבודה יותר מסובכת. דוגמאות *אחרות*, כדי לחזק *גם* את הצד השני. אם היית עובד ב-WINDOWS והיית מגלה שיש תוכנת GUI שמישהו כתב, שעושה בדיוק מה שרצית: לוקחת קובץ DB וממירה ל-UTF8, לא היית משתמש בה? אני הייתי בהחלט משתמש בה ושומר אותה. באותה מידה, אם אני כותב SCRIPT, אני שומר אותו לימים גשומים.

 

[אלדד28]

אתה צודק במאה אחוז -

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

ניקח למשל טלפון בתוכנה - כלומר, תוכנה שמאפשרת לך לעשות VoIP. אתה צריך לבדוק את התוכנה שלך שעובדת מול הטלפון הנ"ל. הטלפון הזה נמצא איפשהו, ולך יש גישה ב-TELNET אליו, כלומר COMMAND LINE, או גישה דרך WEB GUI נוח מאוד. ב-WEB GUI יש לך ספר טלפונים, שמכיל עשרה מספרים כלשהם, שאתה גם זוכר בעל פה. הטלפונים האלו מגיעים לעשרה טלפונים אחרים. ב-GUI יש לך בסה"כ שני מסכים. המסך הראשון מראה את ה-CALL IN PROGRESS, אם יש כזו, מאפשר לך לנתק אותה, ומאפשר לך לעשות שיחה חדשה. כשאתה מקליק על "CALL", שעושה שיחה חדשה, נפתח ספר הטלפונים, ומאפשר לך לבחור מספר טלפון, וללחוץ על ה-OK - ככה אתה מחבר שיחה. ה-COMMAND LINE מכיל שתי פקודות, Call ו-Disconnect, או Disc. הראשונה מקבלת כפרמטר מספר טלפון; השניה לא מקבלת פרמטרים. בנוסף יש לך היסטוריה בסיסית ב-COMMAND LINE הזה, שמאפשרת לך "להזכיר" פקודות (חץ למעלה פשוט). אתה צריך לעשות 1000 שיחות, אחת אחרי השניה, לטלפונים השונים, בכל פעם למספר אחר. בוא נסתכל על הפרוצדורה: COMMAND LINE: אתה כותב Call, חושב שניה ונותן את אחד ממספרי הטלפון, לוחץ ENTER, מחכה שניה, כותב Disc ו-ENTER. אחרי הפעם הראשונה אתה כבר יכול להזכיר את ה-Disc בעזרת החץ. (אני אתעלם מהעובדה שאפשר לפתוח EDITOR בסיסי, להכין "SCRIPT" ולהריץ אותו - שזה עוד יותר נוח). GUI: אתה מזיז את העכבר ל-CALL, מקליק, נפתח חלון חדש; אתה מזיז את העכבר לאחד המספרים, מקליק, מזיז ל-OK, מקליק, מאשר את ההודעה "Call connected", חוזר למסך הראשון, מקליק שם על ה-Disc. זהו. הדוגמה הזו היא סופר פשוטה. לא מערכת הפעלה, לא מערכת מסובכת, לא כוח מיוחד שצריך מה-COMMAND LINE - שתי השיטות זהות לגמרי פונקציונלית. אני מזמין אותך אלינו למעבדה, שם עומדים אנשים ועושים את זה בפועל מדי יום. באיזו שיטה לדעתך הם משתמשים? ניחשת נכון. אין שם אף אחד שעובד עם ה-GUI. אני באמת צריך להסביר לך למה?

 

[אלדד28]

אני בהחלט יכול לנתח את היכולות

של GUI אולטימטיבי אל מול COMMAND LINE אולטימטיבי, גם אם הוא לא קיים במציאות. אתה אומר - "אם GUI ו-SHELL היו שקולים *לכל* פקודה שהיא - גם במהירות השימוש וגם במורכבותו, אז לא היה יתרון בשימוש של אחד מהם" זה לא עובד ככה. GUI אולטימטיבי יעשה חלק מסוים מהמטלות בצורה מהירה יותר מ-COMMAND LINE, ולהיפך. העניין הוא שכשאתה מתרגל ל-COMMAND LINE, אתה הרבה יותר פרודוקטיבי בצורה גלובלית. עצם העובדה שהידיים שלך לא עוזבות את המקלדת זה יתרון עצום. תחשוב לרגע איך אתה עובד ב-GUI עם מלא CHECKBOX-ים, למשל. הרי אתה תשחק עם ה-TAB ועם ה-SPACE, כדי לסמן מה אתה רוצה. רוב האנשים (אלו שאינם מיומנים כמוך) יזיזו את העכבר ויקליקו על כל אחד בנפרד. ההבדל במהירות ניכר, לדעתי. נעבור לדוגמה אחרת - נגיד, SETTINGS של פרויקט ב-VS. בוא נניח לרגע שאתה זוכר בעל פה את כל הפרמטרים של CL, ועושה את העבודה הזו על בסיס יומיומי. נגיד שהעבודה שלך היא לעבור על מאות פרויקטים בשבוע ולשנות את ה-SETTINGS שלהם. היית עובד עם ה-GUI של VS, או שהיית יושב ומשנה את ה-DSP-ים? (בין אם בעזרת SCRIPT ובין אם ידנית, דרך NOTEPAD). התשובה ברורה לי לגמרי. אז נכון, יש מקום ל-GUI. היתרון של GUI הוא בעיקר בהצגה של הדברים. למשל, אם אני עובד על MAYA, יקשה עליי מאוד לעבוד בלי GUI, מן הסתם. כשאתה מתחיל לעבוד, לעומת זאת, אם אתה יודע מה אתה רוצה בדיוק ואיך להגיע לשם - COMMAND LINE עדיף משמעותית. פקודות מדויקות וקצרות עדיפות על משחקים ונדידות עם העכבר. יש עוד יתרון משמעותי ל-GUI והוא הנגישות שלו. אנשים מהשורה מפחדים מ-COMMAND LINE, ועד מהפכת ה-WIN95 לא התפרצו המחשבים לבתים. זה יתרון גדול, אבל שוב - אני לא מדבר על משתמש שנמצא רוב הזמן ב-IDLE, אלא על משתמש שטוחן עבודה. משתמש כזה יעדיף במרוצת הזמן את ה-COMMAND LINE, כי אין מה לעשות - זה פשוט יותר פרודוקטיבי. לסיכום הדיון המיותר הזה, אין לי מחלוקת איתך בנוגע לשיתוף פעולה בין GUI לבין COMMAND LINE. אתה צודק - כדי למקסם את הפרודוקטיביות צריך לעבוד עם שניהם, כל אחד בנקודות החוזק שלו. ספציפית ל-WINDOWS ברור שה-COMMAND LINE הוא דפוק ולא ראוי בכלל להתייחסות, ולכן אין לך הרבה ברירה אלא לעבוד עם GUI - אבל COMMAND LINE במהותו הוא כלי יותר חזק ויותר ENABLING מ-GUI.

 

[אינגולמו]

....

"GUI אולטימטיבי יעשה חלק מסוים מהמטלות בצורה מהירה יותר מ-COMMAND LINE, ולהיפך." יפה, ולכן אין יתרון מהירות בהכרח לאחד מהם. תודה רבה. "אתה הרבה יותר פרודוקטיבי בצורה גלובלית. עצם העובדה שהידיים שלך לא עוזבות את המקלדת זה יתרון עצום." זה לא משכנע. שני קליקים עדיין יכולים בסוף לבצע משהו שיקח 20 דקות לכתוב. אפילו אם יש לי 8 ידיים... "רוב האנשים (אלו שאינם מיומנים כמוך)" חשבתי שהניתוח שלך אמור להיעשות על משתמשים שהם מיומנים עד קצה גבול היכולת, לא? כמוני

שיד אחת כותבת ויד שניה על העכבר... (ככה אני עובד) את בעיית ה-VS הייתי פותר ב-SCRIPT, כמובן. אבל כלל לא התייחסת לבעיות אחרות שהעליתי בהודעות קודמות, שמציגות יתרון עבור ה-GUI. אתה ממשיך למשוך לכיוון דוגמאות שנותנות יתרון ל-SHELL. סבבה, אני יודע שיש כאלה, אני בעצמי נתתי כמה. "כשאתה מתחיל לעבוד, לעומת זאת, אם אתה יודע מה אתה רוצה בדיוק ואיך להגיע לשם - COMMAND LINE עדיף משמעותית" זה סותר את הדברים האחרים שאמרת בהודעה: אם GUI מהיר יותר עבור חלק מהפעולות (גם עבור משתמש מיומן), אז איך CL עדיף במקרים האלה? אם אתה טוען, כמוני, שצריך לעבוד בשתי המתודות כדי למקסם את הפרודוקטיביות, אז איך פתאום SHELL עדיף בכל המקרים? יכול להיות שלא הבנתי... "ספציפית ל-WINDOWS ברור שה-COMMAND LINE הוא דפוק ולא ראוי בכלל להתייחסות" מצטער, ממש לא נכון. אתה אולי מתכוון ל-CL של WIN95 או משהו כזה. ה-CL של NT די חזק, שלא לדבר על NT SHELLS כמו CYGWIN. ואם אתה גם מתקין תוספות כמו RESOURCE KIT, אתה *יכול* כמעט לא לגעת ב-GUI, למרות שכאמור, זו לא תהיה הגישה הכי פרודוקטיבית. "לסיכום הדיון המיותר הזה, אין לי מחלוקת איתך בנוגע לשיתוף פעולה בין GUI לבין COMMAND LINE" גם אני אוהב אותך!! שנה טובה!

 

[אלדד28]

נמשיך.

"יפה, ולכן אין יתרון מהירות בהכרח לאחד מהם. תודה רבה." למה לעוות את דבריי? ראה תשובתי האחרת, למעלה. בעבודה שוטפת יש יתרון מהירות, והוא שייך ל-COMMAND LINE. "שני קליקים עדיין יכולים בסוף לבצע משהו שיקח 20 דקות לכתוב" ברור, בהינתן ה-GUI שעושה כל מה שאתה מדמיין בעולם. הבעיה היא ש-GUI כזה לא רק שלא קיים - הוא לא יכול להיות קיים, מטעמי סיבוכיות. כל הקטע ב-GUI הוא שהוא עושה משימות נפוצות בקלות; משימות טיפונת פחות נפוצות, או משימות שדורשות הגדרה קטנטנה נוספת - והופ, אכלת אותה. או שה-GUI יסבך לך נורא את החיים, או שהוא בכלל לא ייתן לך לעשות את זה. שים לב שמעולם לא חלקתי עליך שיש משימות שעדיף עבורן להשתמש ב-GUI. בפעם האלף, אני תומך בשילוב בין השניים לפי הצורך; הבעיה היא שמרבית המשימות בכל מקרה אינן מכוסות על ידי ה-GUI, מהסיבה הפשוטה שהקומבינציות שלהן אינסופיות. " אם אתה טוען, כמוני, שצריך לעבוד בשתי המתודות כדי למקסם את הפרודוקטיביות, אז איך פתאום SHELL עדיף בכל המקרים? יכול להיות שלא הבנתי..." כנראה שבאמת לא הבנת. בפעולות בודדות ("העבר קובץ מכונן :E בספריה X לכונן :F בספריה Z, תוך שאתה מכווץ אותו עם WINZIP"), ברור שאפשר למצוא איזשהו GUI שיעשה בשבילך את העבודה. זה למעשה בדיוק כמו לכתוב SCRIPT שיעשה את זה, אלא שאתה מסתמך על GUI קיים, וזה מצוין. הבעיה מתחילה כשיש לך עבודה שוטפת. אז מכיוון שלא הבנת - אני אסביר. בפעולה בודדת X יכול להיות יתרון ל-GUI או ל-COMMAND LINE. בפעילות שוטפת שמורכבת מהמון פעולות בודדות, היתרון של ה-GUI נעלם כלא היה, ובמקומו עולה יתרון ה-COMMAND LINE (לא SHELL אלא COMMAND LINE). במהלך הפעילות השוטפת הנ"ל יש סיכוי טוב מאוד שחלק (קטן מאוד) מהפעולות יבוצע מהר יותר על ידי GUI. למשל, הפעלת תוכנה מסוימת שנמצאת על ה-DESKTOP יהיה מהיר יותר מכתיבת כל ה-PATH שלה וכו'. מצד שני, את דוגמת ה-WINZIP האמורה, אם נשליך לרגע ללינוקס, אפשר לעשות הרבה יותר מהר מרמת ה-COMMAND LINE, בהינתן הכלים והקיצורים המתאימים; במיוחד אם אתה עובד כרגע ב-CONSOLE, ולעשות את זה ב-GUI זה אומר לפתוח Konqueror, להגיע לספריה, וכו'. "מצטער, ממש לא נכון. אתה אולי מתכוון ל-CL של WIN95 או משהו כזה. ה-CL של NT די חזק, שלא לדבר על NT SHELLS כמו CYGWIN." CYGWIN זה יוניקס, וברור שעם הכנסתו ל-WINDOWS, ה-COMMAND LINE של WINDOWS יקבל עוצמות שבחיים לא הכניסו לו ב-MICRO$OFT.

 

[אלדד28]

אה, ואיך שכחתי -

אני אוהב אותך יותר

, ושנה טובה גם לך

 

[eyalbd]

ההצעה שלי

מבחינת האפליקציה - אין שום יתרון. שמור מידע בתיקיית המשתמש למשל כפי שעושה MOZILLA:

C:\Documents and Settings\eyalb\Application Data\Mozilla​

אל תשמור ברגיסטרי למעט שיוכי קבצים או אולי אם יש לך רכיבי COM אל תשמור בתיקיית ההתקנה שמור בצורת טקסט - שתהיה לך אפשרות לפתוח עם עורך טקסט או תוכנית אחרת ולתקן או לערוך. INI מספק במרבית המקרים. XML יכול לעזור את אתה חייב מבנה היררכי. אל תמציא API לכתיבה או קריאה של קבצי קונפיגורציה. תשתמש במשהו קיים.

 

[eyalbd]

רגיסטרי - כיצד עושים זאת נכון

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