פורסם: 14/08/2012 - 14:21
נושא ההודעה: למה Arch ?
|
השינויים האחרונים ב Arch גרמו לחלק מהמשתמשים התמרמרות קלה על כך שההפצה מאבדת את ייחודה ולמעשה הופכת להיות כשאר ההפצות . אחד המפתחים של ארצ , אלן מקר (אני מקווה שאני כותב נכון את השם) , מנסה לענות למשתמשים הנ"ל :
http://allanmcrae.com/2012/08/are-we-removing-what-defines-arch-linux/
אני אישית עברתי לארצ מסיבה אחת ויחידה : הפצה מתגלגלת , רציתי את התוכנות הכי חדשות שיש היום כל הזמן .
אבל בנוגע לשינוים האחרים אני סבור שארצ היתה חייבת לעשות אותם אם היא רוצה להיות רלוונטית כיום . אי אימוץ של טכנולוגיות חדשות או התאמה ל upstream תביא את ארצ בסופו של דבר להיות לא רלוונטית גם אם היא שומרת על ייחודה . הגבול שצריך להישמר הוא במודולריות של ארצ ובכך שארצ לעולם לא תכריח משתמש להתקין רכיב כזה או אחר אלא אם זה לחלוטין הכרחי לצורך איתחול של המערכת וגם במקרה כזה ארצ צריכה לשמור על מדיניות של אפס פאצטים עצמייים וזאת על מנת לאפשר למשתמש בצורה הפשוטה ביותר האפשרית להחליף כל רכיב ברכיב אחר עם מינימום בעיות או שבירות של המערכת .
|
|
|
| חזרה לתוכן הדיון |
פורסם: 14/08/2012 - 18:04
נושא ההודעה: Re: למה Arch ?
|
| מתר : |
אני אישית עברתי לארצ מסיבה אחת ויחידה : הפצה מתגלגלת , רציתי את התוכנות הכי חדשות שיש היום כל הזמן .
אבל בנוגע לשינוים האחרים אני סבור שארצ היתה חייבת לעשות אותם אם היא רוצה להיות רלוונטית כיום . אי אימוץ של טכנולוגיות חדשות או התאמה ל upstream תביא את ארצ בסופו של דבר להיות לא רלוונטית גם אם היא שומרת על ייחודה . הגבול שצריך להישמר הוא במודולריות של ארצ ובכך שארצ לעולם לא תכריח משתמש להתקין רכיב כזה או אחר אלא אם זה לחלוטין הכרחי לצורך איתחול של המערכת וגם במקרה כזה ארצ צריכה לשמור על מדיניות של אפס פאצטים עצמייים וזאת על מנת לאפשר למשתמש בצורה הפשוטה ביותר האפשרית להחליף כל רכיב ברכיב אחר עם מינימום בעיות או שבירות של המערכת . |
כי ארצ' זה מ-א-ג-נ-יב. ארץ' זה האובונטו החדש מבחינת Hype
|
|
|
| חזרה לתוכן הדיון |
פורסם: 14/08/2012 - 21:06
נושא ההודעה:
|
|
"מינימום בעיות או שבירות של המערכת"
LOLOLOLOLOLOL!!!!!
הצחקת את GLIBC ונפגעיה.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 08:47
נושא ההודעה:
|
|
היום לשימחתי כבר יש 2 קבוצות משתמשים.
המפתחים : שרוצים מערכת כמה שיותר יציבה לאורך זמן
כל השאר: שרוצים תוכנות חדשות פיצרים חדשים
פעם לינוקס היתה מחוז של מפתחים ושל שרתים
היום היא הגיעה למיין סטרים ונדרשת להיות גם וגם .
מזל שיש מספיק הפצות שנותנות מענה לכל קבוצה
ובכל זאת תחת מטריית ה GNU\LINUX והקרנל המשותף של לינוס
לגבי GLIBC זה מאד מטריד כי זה חלק בסיסי מידי שלא אמור להישבר.
_________________
מערכת: GNU/Linux debian
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 09:00
נושא ההודעה:
|
|
הבעיה פה היא לא הקדמה, אלא שבירת מוסכמות בגלל גחמות של חברה כלשהי.
אין שום דבר רע לדעתי ב-SYSTEMD, הרע הוא השינויים שעושים תוך כדי.
אתן לך דוגמה מהמצב שלי (שהוא רחוק מלהיות רק בעיה שלי), הרבה משתמשים ותיקים גורסים שהיכולת לשים כל ספריה במחיצה משלה הוא דבר טוב במקרה של קריסות ותורם למידור.
אצלי בבית אני מריץ ג'נטו כשרוט שלי יושב על raid1 והשאר (חוץ מכמה מחיצות זניחות) יושב על raid5.
חשוב לציין שמדובר ב-swraid שמגיע על הקרנל, אני אחד שלא אוהב את הנישה של initrd ו-initramfs, אלה דברים לא נחוצים לדעתי ו-initramfs נשאר בזיכרון אחרי העליה של המערכת.
אם הייתי רוצה שישאר לי זבל בזיכרון, הייתי נשאר בחלונות.
בכל מקרה, אצלי יש מידור, היות והרוט שלי קטן יחסית, הוא יושב במחיצה של 3 ג'יגה, את שאר המחיצות הכבדות (/var, /usr,/ opt, /home) יושבות על ה-raid5 לגיבוי ולביצועים.
נכון להיום אני משתמש ב-udev-176 כשאני יכול בעיקרון להשתמש באחרון (186 אם אני לא טועה), הסיבה שאני לא זה כי בגלל אותם גחמות של החברה מפתחת את udev, בכל הגירסאות מעל, אני חייב initramfs אם usr ו-var נמצאות על מחיצה נפרדת.
לי זה לא נראה הגיוני.
ניחא, היו מאפשרים להשתמש במנגנון החדש, אבל הם הסירו אותו בכלל.
בקיצור, לא כל שיפור הוא טוב.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 09:50
נושא ההודעה:
|
|
אני אורח "1" (משתמש וותיק באתר שאין לו כוח להכנס בחשבונו כך אני משתמש שנים)
לדעתי לא רק ...
לא כל שינוי ב Kernel הוא "שיפור" .
כל פעם בא לאיזה מתכנת לבנות "פיצ'ר" חדש .
שלא תמיד מיטיב את הפעולה .
לדוגמה מתכנת בה לו לבנות אפשרות לחסכון בחשמל בהתקן אלחוטי wireless wifi
הסיבה שלאותו מתכנת יש מחשב נייד . אצל אותו מתכנת החסכון בחשמל נותן יתרון בזמן סוללה .
הבעיה עכשיו עם כל המחשבים הניידים : כרטיסי רשת אלחוטיים כל הזמן עם בעיות ניתוקים.
גם ביטול חסכון בחשמל בקטגוריה של networking בקרנל לא מבטלת את הבעיה לחלוטין.
ואם אני רוצה להפעיל שרת שיעבוד עם כרטיס רשת אלחוטי ?
למרות שיש בקרה עדיין נכנסים לקרנל כל מיני שטויות .
אגב wobnl : ב gentoo מה עדיף gentoo-sources או vanilla-sources .
אגב בארץ' נדהמתי מלפני כמה חודשים אין יותר ifconfig משום שאחד המתחזקים בראשיים חושב שהכלי מיושן ואינו נחוץ .
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 09:51
נושא ההודעה:
|
|
הבעיה עכשיו עם כל המחשבים הניידים : תיקן נייחים כמובן .
בעיית ניתוקים ב wifi זה כבר נפוץ מאז הוסיפו את הפיצ'ר
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 09:56
נושא ההודעה:
|
| אורח 1 : |
אגב wobnl : ב gentoo מה עדיף gentoo-sources או vanilla-sources .
|
זה תלוי בצרכים שלך, אני משתמש ב-GS.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 12:51
נושא ההודעה:
|
|
אני רואה שלא הייתי ברור מספיק וגרמתי לקצת עירבוב של נושאים . הבעיה היא לא חדשנות מול יציבות (שזה ויכוח עתיק בלינוקס שלא בהכרח קשור לארצ) אלא האם ארצ עדיין עומדת בהגדרת ה Kiss שלה ?
Glibc דווקא מחזק את ה Kiss של ארצ , ארצ לא אחראית לבאג מ Upstrem (אם אכן היה כזה , אני משתמש יותר משנתיים בארצ ולא חוויתי שבירה של המערכת) אבל ארצ כן נותנת בידי המשתמש את האחריות על המערכת שלו . ה Kiss של ארצ לא אומר אפס באגים אבל הוא כן אומר שאם היתה שבירה או סתם אי שביעות רצון משדרוג מסוים המשתמש יכול לשנמך לגירסא קודמת או להחליף את הרכיב במשהו אחר (נניח מה Aur ) .
דוגמא אחרת היא systemd : ארצ לא אחראית למבנה של systemd ולא יכולה להשפיע עליו הבעיה היא שיש משתמשים שטוענים שהמעבר לריבוי קבצי קונפיגורציה הוא בניגוד ל Kiss של ארצ שבו משתמשים בקובץ יחיד ( Rc.conf ) , האם זה צריך למנוע את המעבר ל Systemd ? האם זה באמת מנוגד ל Kiss או שסתם קשה להתרגל למערכת חדשה ?
אגב לגבי Ifconfig אצלי הוא עדיין קיים ....
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 12:58
נושא ההודעה: Re: למה Arch ?
|
| מתר : | | אלן מקר (אני מקווה שאני כותב נכון את השם) |
מקריי (כמו נהג הראלי המנוח קולין מקריי).
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 13:20
נושא ההודעה:
|
אורח 1:
* חיסכון בחשמל נדרש לכל המשתמשים. הוא נדרש למשתמשים עם מחשבים ניידים שרוצים סוללה שתחזיק מעמד יותר זמן. הוא נדרש גם עבור משתמשים בחוות שרתים שחשבון החשמל שלהם הוא חלק לא מבוטל מהוצאותיהם.
* ifconfig ושות' מוחלף בֹֹֹ-ip ושות'. מוצלחים יותר. סבלו עד לא מזמן מחוסר תיעוד. ר' לדוגמה
https://lists.debian.org/debian-devel/2012/08/msg00203.html
דוגמה לבעיה עם ifconfig:
| קוד: |
sweetmorn:~# ip addr add 172.16.46.24/24 dev eth0
sweetmorn:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1c:23:20:99:1f
inet addr:192.168.0.134 Bcast:192.168.15.255 Mask:255.255.240.0
inet6 addr: fe80::21c:23ff:fe20:991f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:30436 errors:0 dropped:0 overruns:0 frame:0
TX packets:14257 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6247245 (5.9 MiB) TX bytes:1779915 (1.6 MiB)
Interrupt:17
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:185 errors:0 dropped:0 overruns:0 frame:0
TX packets:185 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:16750 (16.3 KiB) TX bytes:16750 (16.3 KiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.2.0.26 P-t-P:10.2.0.25 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:6160 (6.0 KiB)
sweetmorn:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1c:23:20:99:1f brd ff:ff:ff:ff:ff:ff
inet 192.168.0.134/20 brd 192.168.15.255 scope global eth0
inet 172.16.46.24/24 scope global eth0
inet6 fe80::21c:23ff:fe20:991f/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:1d:e0:72:12:9b brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/none
inet 10.2.0.26 peer 10.2.0.25/32 scope global tun0
sweetmorn:~# ip addr del 172.16.46.24/24 dev eth0
|
כמו שאתם רואים, ifconfig לא ראה יותר מכתובת IPv4) אחת להתקן. לעומתו ip לא מניח שלהתקן אחד יש כתובת אחת.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 14:33
נושא ההודעה:
|
|
אני אוהב את ההפצה הזו, אך היא לא מושלמת. ה-glibc הוא באחריות ארץ' - שינוי התיקיות בשדרוג שלהם שבר דברים. היו גם לא מעט בעיות בחתימות על חבילות, השטות שלהם של החלפת קישור ברירת המחדל של פייתון ל-3 ועוד. יש גם את אי שמירת x קרנלים הישנים יותר בעת שדרוג קרנל.
בכל מקרה, הכל היה פשוט יותר אם היו מעדכנים את ה-changelog כראוי עבור החבילות. לא ברור לי מדוע הם מתעקשים לא לעשות זאת (זה דבר ש-lint של כל הפצה אחרת לגבי חבילות היה תופס).
מדוע אני לא יכול בעזרת מנהל החבילות לראות מה נשתנה בחבילות לפני השדרוג ? האופציה קיימת, המידע פעמים רבות לא. זה דבר בסיסי שכל הפצה שמכבדת את עצמה מתחזקת ומספקת, בטח כזו שמיועדת למשתמשים מתקדמים יותר.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 15:33
נושא ההודעה:
|
מי שלא מרוצה מ-systemd אבל רוצה לעשות משהו בנידון: קבוצה של מפתחים בגנטו החליטו לכתוב חלופה פשוטה יותר ששמה הוא OpenRC. ר':
http://www.gentoo.org/proj/en/base/openrc
|
|
|
| חזרה לתוכן הדיון |
פורסם: 15/08/2012 - 15:58
נושא ההודעה:
|
| mksoft : | אני אוהב את ההפצה הזו, אך היא לא מושלמת. ה-glibc הוא באחריות ארץ' - שינוי התיקיות בשדרוג שלהם שבר דברים. היו גם לא מעט בעיות בחתימות על חבילות, השטות שלהם של החלפת קישור ברירת המחדל של פייתון ל-3 ועוד. יש גם את אי שמירת x קרנלים הישנים יותר בעת שדרוג קרנל.
בכל מקרה, הכל היה פשוט יותר אם היו מעדכנים את ה-changelog כראוי עבור החבילות. לא ברור לי מדוע הם מתעקשים לא לעשות זאת (זה דבר ש-lint של כל הפצה אחרת לגבי חבילות היה תופס).
מדוע אני לא יכול בעזרת מנהל החבילות לראות מה נשתנה בחבילות לפני השדרוג ? האופציה קיימת, המידע פעמים רבות לא. זה דבר בסיסי שכל הפצה שמכבדת את עצמה מתחזקת ומספקת, בטח כזו שמיועדת למשתמשים מתקדמים יותר. |
אוקי זה כבר טיעונים יותר חזקים : אם אני קורא בין השורות נכון הרי שמה שמפריע לך זה לא שינוי ספציפי כזה או אחר כפי שאלן מקריי חושב אלא הדרך הכללית שבה מנוהלת ההפצה הזו והכלים שנתנים למשתמש לצורך קבלת החלטה (לדוגמא changelog) . למען האמת אני די מסכים עם זה לאור העובדה ש Arch מגדירה את עצמה כ user-centric . קיבלתי .
|
|
|
| חזרה לתוכן הדיון |
פורסם: 17/08/2012 - 13:00
נושא ההודעה:
|
בניגוד ל־upstrat של Ubuntu.
או init של sysv.
או init של busybox.
נשבר הזין שפעם בשלוש שנים עושים שינוי כזה מהותי במערכת שעובדת. אני מבין את הצורך במקבול... אבל לפעמים לינאריות היא דבר טוב.
האונס שעשו מפתחי udev הוא מחטף לא יאמן: קושרים שני שירותים לא תלויים אחד בשני בקוד אחד, כך שאחד מכריח שימוש בשני.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 17/08/2012 - 16:33
נושא ההודעה:
|
| elcuco : |
נשבר הזין שפעם בשלוש שנים עושים שינוי כזה מהותי במערכת שעובדת. אני מבין את הצורך במקבול... אבל לפעמים לינאריות היא דבר טוב.
האונס שעשו מפתחי udev הוא מחטף לא יאמן: קושרים שני שירותים לא תלויים אחד בשני בקוד אחד, כך שאחד מכריח שימוש בשני. |
+1
מסכים, זה בדיוק מה שעשו מפתחי גנום וKDE. אני לא מבין את הצורך בלשבור דברים. רוצים לעבוד לגנום שלוש? היו צריכים להגר דבר ראשון את הישומים הבסיסיים לGTK 3 ולדאוג שכל הפיצ'רים הישנים יהיו בגרסה החדשה. ורק אחר כך לאפשר לאנשים להתשמש בSHELL.
לא היה שום צורך לאנוס אנשים שמתשמשים במחשב ישן להשתמש בSHELL.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 17/08/2012 - 17:07
נושא ההודעה:
|
| elcuco : |
בניגוד ל־upstrat של Ubuntu.
או init של sysv.
או init של busybox.
נשבר הזין שפעם בשלוש שנים עושים שינוי כזה מהותי במערכת שעובדת. אני מבין את הצורך במקבול... אבל לפעמים לינאריות היא דבר טוב.
האונס שעשו מפתחי udev הוא מחטף לא יאמן: קושרים שני שירותים לא תלויים אחד בשני בקוד אחד, כך שאחד מכריח שימוש בשני. |
לעניין הלינאריות: בדביאן יש כבר היום מערכת sysv עם מקבול - נכנס בגרסה הנוכחית ושיפר בצורה משמעותית את זמן העליה.
הן upstart והן systemd דורשים ריצה של תהליך ראשי שמקבל אירועים שונים ומטפל בהם (לדוגמה: ע"י העלאת או הורדת שירותים). השירותים לא עולים או יורדים כתוצאה מתוכנית שמופעלת ע"י המשתמש, אלא כתוצאה מבקשה של המשתמש לתהליך הראשי. כך פועל גם launchd ב-OSX והתהליך המקביל בסולריס.
מפתחי OpenRC טוענים שאפשר לכתוב מערכת שירותים טובה ללא צורך בתהליך מרכזי כזה.
הדרישות מהמערכת:
* פשוט לכתוב הגדרות שרותי אתחול (השווה ל-systemd).
* חישוב אוטומטי של תלויות בין שירותים - אם sshd מצהיר שהוא צריך לרוץ אחרי ש-syslogd עלה, צריכים לדאוג לסדר הין השניים
* תאימות אחורה לסקריפטי sysv קיימים כדי לאפשר מעבר חלק
התחליף שלהם ל-udev הוא בינתיים mdev של busybox.
דעתי האישית היא ש-systemd הוא מערכת טובה אך למתחזקיה יש קצת בעיה של כפיית דעתם כאשר הם חושבים שהם יודעים טוב יותר מהאחרים. לכן לא מזיק שיש מי שבודק את הנחותיהם בדרך הכי קונסטרוקטיבית שיש: עם קוד.
|
|
|
| חזרה לתוכן הדיון |
|
|
ת.הצטרפות: 27/12/2011
·
הודעות: 48
·
![שלח דוא\](./modules/PNphpBB2/templates/PNTheme/images/lang_hebrew/icon_email.gif "שלח דוא\"){kind=icon}