Sistem D'yi Aydınlatmak

@xiep Yorumunuza daha fazla katılamıyorum.

@juanfgs okuyan tek kişi gibi görünüyorsun, en azından bunun için seni alkışlıyorum, ama benim yorumumdaki çok önemli bir şeyi okumalısın, buraya yazmam önemli değil:

»NIH Nerede? Görünüşe göre yaşlı Lennart trol yapmayı ve büyük olmayı seviyor. "

Masum bir nedenle yazdığını sanmıyorum, Nisan'ın Şaka Günü (kötü ruh hali) için başka bir Lennart şakası olduğunun, ayrıca /, / vb. Ve diğer her şeyi / Linux. 🙂

Not: Teşekkürler ama İngilizcemi pratik yapmama gerek yok, 6 yaşımdan beri bu dili kullanıyorum
aaahh ve diğer her şey doğru, doğrula 🙂

@juanfgs, sizi özellikle bu konudaki sözünüze alıyorum:

«Ve gerçek şu ki, anti-sistemlerin çoğu bu testi geçemiyor, yine de bir nedenden ötürü arkasındaki insanlardan DAHA FAZLASINI BİLEN bir avuç insan: Debian, Fedora, Archlinux, Linux çekirdeği, tüm GNOME projesi Systemd, SUSE ve uzun süredir şikayet etmedikleri için muhtemelen KDE projesi de.

Öyle olsa bile, zehirli ve kin dolu konuşması, başardığı tek şey ayrılık, problemler ve diğerleri yaratmaktır. Xorg, NetworkManager, PulseAudio'dan tehdit ettikleri için nihayet BSD'ye geçmelerini bekleyemeyeceğim nokta bu ve tamamen teknik cehaletten mi yoksa bundan şikayet etmeyeceklerinden mi bilmiyorum. "

Öyleyse size GÖRE, sistem karşıtı hepimiz zehirli ve iğneleyiciyiz ki başardığımız tek şey ayrılık, problemler vb. Size burada okuyabildiğim en büyük öfke olduğunu söyleyeyim. Bir sistemin yapısal sorunları gün ışığına çıktığında sistem yanlısı neden rahatsız oluyor bilmiyorum, ki bu onları bir noktada etkileyecektir, çünkü şu anda onlara hiçbir şey olmamış olabilir, ama bir noktada yapacaklardır. olacak ve sonra bazı anti-sistemd onlara defalarca söyledikleri kelimeleri hatırlatacak ve kimse onları durdurmayacak ve belki başka bir anti-sistemd onlara yardım edecektir.

Kişisel olarak systemd'yi sevmiyorum ama bu init kullanmadığım anlamına gelmiyor, kullanmak zorundayım çünkü işimde eğer bu init ile bir makineye dokunmam gerekiyorsa, nasıl kullanacağım konusunda bilgi sahibi olmalıyım BT. Ayrıca kişisel olarak Archlinux'a geldiğimden beri kullanıyorum, hatta Debian ve Gentoo'da da, bu yüzden bana systemd kullanmadığım için vizyonumun taraflı olduğunu söylemeyin, kullandım ve ne kadar topal olduğunu biliyorum. ve eğer forumda birine yardım etmem gerekirse DesdeLinux veya IRC veya Debian listesinde (ki bu benim en uzun süre kaldığım ve işimde hala kullandığım dağıtım) bunu zevkle yapacağım çünkü eğer Linux topluluğunda sevdiğim bir şey varsa o da şudur: farklılığa rağmen her zaman yardımdır.

Şimdi BSD'ye geçmek mümkün, ancak bunu yalnızca systemd başka bir seçeneği kullanmama izin vermeyecek kadar öldürücü hale gelirse yapacağım, bu arada Linux'ta kalıyorum, tüm bu çılgınlığı devre dışı bırakıyorum, Bir şeyleri gruplandırır.

Glibc'de kimsenin onları gizleyemeyeceği hataları var, çekirdeği ve yüzlerce çalıştırılabilir dosyayı etkileyen devasa Glibc hataları var. Glibc ve systemd arasındaki fark, birincisinin BİNLERCE yazılım projesinin ikili dosyalara dönüştürülebildiği bir temel olması, systemd ise kararlı, kanıtlanmış ve pratik olarak yanılmaz bir parça olmak olan bir init olmasıdır. Sadece bu değil, Glibc yüzlerce farklı donanım mimarisine (CPU), farklı optimizasyon bayraklarına ve CPU'nun benzersiz özelliklerine, farklı yazılım optimizasyon biçimlerine, systemd'den çok daha zahmetli ve zor bir işe uyum sağlamalıdır. İki proje arasında aynı ölçekte bir karşılaştırma sunmanın bir yolunu gerçekten görmüyorum.

Aynısı GCC için de geçerli, GCC bu arada birçok dili destekleyen (resmi olmayanları sayan toplamda 13) ve Glibc'ye çok benzer özelliklere sahip, birçok mimariyi (sürüm 70 için 4.9 mimari), ikili optimizasyonu destekleyen bir derleyici. bayraklar, CPU optimizasyon bayrakları ve diğer birçok özellik. Şimdi aynı zorluk seviyesindeler, init'e sahip bir derleyici. Cevap çok açık, o systemd'den başlayarak C'de ve GCC kodunun çoğu assembler'da ya da bir şeyleri ikili olarak çalıştırmak için assembler kullanmanız gerekiyor, bu biraz "yapılması zor" bir şey.

GCC ve Glibc ile ilgili sorun nedir? Elbette. Linus bile onlara saldırısını verdi, ancak GCC ve Glibc'de olumlu bir şeyleri var, sistemde sıklıkla unutuluyorlar ve bu, bildirilen bir hata, görülen bir hata, bir hata düzeltildi.

Ayrıca, Kay Sievers'ın yalnızca çekirdek cmdline'ı kırmakla kalmayıp onu kapatmak istediğini de unutmaz, ne de olsa "jenerik geneldir".

Bence yanlış okuyup analiz ettiniz (analiz etmek önemlidir) ya da kendinize bunu yapma şansı bile vermediniz. İki işlemin bilgi aktarması, bir sistemin kırılması için bir neden değildir, ancak, ağ kontrolü, günlükler veya çekirdek döküm gibi dinamik eylemlere sahip ikili dosyalarınız olduğunda, bilgileri doğrudan init'e ilettiğinizde, işler ters gidebilir ve yanlış gideceklerdir, çünkü bazı ikili dosyalar bozulursa, geri kalanı kırma şansı çok daha yüksektir ve bu oldukça gerçekçidir ve bu, son zamanlarda çekirdek cmdline çökmesi, Nvidia geliştiricilerinin systemd-212 sayesinde yaşadığı acpi sorunları, hepsi bir söylediklerimin örneği.

@anonymous, sadece TTY sorununun Linux'ta nasıl gelişeceğini görmek istiyorum. CONFIG_VT kodu ortaya çıktığında, VT'yi iki iyi farklılaştırılmış parçaya (çekirdek alanı ve kullanıcı alanı) bölme lehine, VT'leri kullanıcı alanından kontrol etmek için bir araca ihtiyacımız olacak ve orada systemd-consoled, geri kalanını çeken güçlü bir bağımlılık olarak oynayabilir. Sistemin çalışmasını mümkün kılmak için sistem bileşenlerini kurmak zorunda olma zorunluluğuna yönelik dağıtımlar. Söylediğim şey abartı değil, çok, çok büyük bir olasılık ve gerçekten endişe verici. KMSCon gibi başka projeler de var, ancak çoğu masaüstü ve dağıtım, systemd'nin lehine giderse, KMSCon gibi şeyler birçok kişinin düşündüğünden daha hızlı ölebilir.

@ anonymous, CONFIG_VT'nin kaldırılmasının sonunda toplam olacağı (okuduğumdan), yani çekirdekte yalnızca ilkellerin kalacağı, diğer araçların kullanıcı alanında olacağıdır, bu fena değil, aksine, çok sayıda eski kodu çekirdekten kaldıracak, bakımı kolaylaştıracak ve çok daha fazla yapılandırılabilir hale getirecek (konsol için tam KMS / DRM desteği). Kuşkusuz başlangıçta her iki sistem de olacaktır, ancak uzun vadede (15-20 sürümler) çekirdekten çıkabilir veya daha da erken, birçok araç artık bu tür kodu daha yeni ve daha iyi desteklenen kodlar lehine desteklememektedir.

Şimdi diyorsunuz ki systemd yaparsa 50 uygulama daha yapamaz (50 uygulama daha hayal ediyorum). Peki, KMSCon'un (bu anlamda en eski proje) güçlü bağımlılıklarını görürsek, bunlar libudev'dir (yakında systemd'ye katılacak kod, desteklenmeyecek ve kendi başına çalışırsa systemd ile çakışacaktır), libdrm, libxkbcommon, libtsm ve systemd'nin kendisi çoklu oturumu idare eder, bu yüzden bunu gördüğünüzde, bir GNU / Linux işletim sisteminin sorunsuz çalışması için gerekli olan birçok aracı kendi başlarına alırken işlerin nasıl şekillendiğini anlarsınız.

@ anonymous kesinlikle diğer olasılıktır, eudev bu konuda daha fazla güçlenecek ve farklı araçlar seçmek için seçenekleri açık tutacaktır.

Not: Dediğiniz gibi, VT'lerin fbdev ile birlikte KMS / DRM'nin avantajlarından nasıl yararlandığını görmek ilginç olurdu 😀

@dariem, fikri anladığınızı görmek için basit bir şekilde açıkladı:

Söylediğiniz şey kesinlikle modüler programlardan ve süreçlerden her zaman beklenen davranıştır. Modülerlik bu amaçla uygulandı, iki süreci ayırmak ve kendi hafıza alanlarını işgal etmek ve bazı yollarla (IPC, vb.) İletişim kurmak, böylece bir şeyler ters giderse, o zaman kötü bir şey olmaz. Ve sistem kesintisiz olarak çalışmaya devam edebilir. Potansiyelliği ve mevcut hesaplamaya sağladığı muazzam güvenilirlik marjı nedeniyle kesinlikle büyük desteği olan bir teori. Şimdi, bu her zaman doğru değildir (hayat her zaman güzel değildir) ve kesinlikle bu olayların kurbanı olduğunuzu düşünüyorum (bu, kullandığınız işletim sisteminden bağımsız olarak kesinlikle herkes için geçerlidir) ve vereceğim birkaç örnek.

Birincisi, sistemin geri kalanı beklendiği gibi çalışmaya devam ederken bazen bir sürücüyle çıldıran ve sizi grafiksiz bırakan Xorg ile gider (bu, systemd gibi modüler bir süreçtir). Şimdiye kadar o kadar iyi ki, modüler süreçlerin sistemi bozmak zorunda olmadığı teorimiz iyi çalışıyor. Ancak (her zaman bir miktar vardır ama) bazen Xorg çılgınlıktan daha fazlasını verir ve bazı garip nedenlerden dolayı (fare kontrolünden grafik sürücüsüne kadar değişebilir) yalnızca Xorg çökmesi değil, aynı zamanda size en güzel çekirdek paniğini de verir ve monitörde Picasso gibi bir grafiti) hayal edebileceğiniz gibi ve sonra fark edersiniz ki, ne kadar modüler olursa olsun, bir süreç birbiriyle iletişim kurup bilgi / veri alışverişi yaparsa ve bunlardan birinde bir şeyler ters giderse ve Bazı nedenlerden dolayı, hata doğru bir şekilde ele alınamaz, söz konusu işlemlerin etkilenme şansı artar, çünkü basit olarak verilerin yanlış veya basitçe bozuk olması ve ardından felaket gelir.

Bunun olamayacağını düşünüyorsanız, size Xorg, mesa, nouveau ve çekirdeğin drm / kms sürücüsünde bulunan eski bir hatanın bazı hata raporları (Debian'da benimki ve birkaç fotoğrafı var) bırakıyorum. ayrı çalışırlar ** ve modüler olurlar **, birlikte çok iyi anlaşamazlar, en azından bu koşullar altında.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619

Şimdi size systemd ile vereceğim diğer örnek. Eski Sysvinit'imiz, eski olmasına rağmen, çok güvenilir olduğu bir tuhaflığa sahipti, o kadar ki / etc / fstab'ınız bir bölüm girişine sahipse (sistem için önemli değil, a / mnt / Disk160GB anlıyor) ve bunu yapamıyordu. Herhangi bir nedenle takılamazsa, montaj atlandı, size bir uyarı mesajı verdi ve önyükleme işlemine devam edildi. Şimdi, systemd modülerliğine rağmen başka bir hikaye, / etc / fstab içinde bir girişiniz varsa ve systemd herhangi bir nedenle onu monte etmenin imkansız olduğunu görürse, sadece bölümün kullanılabilir olmasını beklemekle kalmaz (normal programlanmış davranış ), ancak zaman biterse, sisteminiz durdurulur ve kurtarma moduna girip bu satırı / etc / fstab'dan kaldırmaktan başka bir şey yapamazsınız, aslında bir şeyler başarısız olur. Önyüklemedeki otomatik bağlama sırasında bu küçük ayrıntı artık kalmadı ve tüm süreç durdu, ilk başta (sistemd-) küçük ayrıntı daha çirkindi, çünkü döküm göründü ve yeniden başlatman gerekiyordu. Ayrıntılardan geçen biri size söyler.

Verebileceğim bir başka örnek de systemd'deki coredumpd. coredumpd, yakalanan bilgileri diske yazması için varsayılan olarak tüm bilgilerini journald'a aktarır, şimdiye kadar o kadar iyi ki, systemd'nin modülerliğini kendi yararımıza kullanıyoruz. Ancak bazen, çekirdek pompaları çok büyük olduğunda, birkaç GB alabilecek kadar büyük olduğunda ve karottan journald'a ve ardından diske bilgi aktarımı sürecinde, Xorg'un çalışmayı durdurması ve hatta çekirdeği bile kernel panik. Bu sadece sistemd'de olmaz, aynı zamanda tasarlanma şekli hata faktörünü artırır ve başka hoş olmayan ayrıntılar yaratır (bunların arasında artan bellek tüketimi, günlük bozulması, eksik dökümler), kim çalışmak zorunda kalırsa KDE coredump ile, kesinlikle bunun gibi birkaç bölümden geçtiniz ve döküm bölümünüz için / etc / fstab içinde senkronizasyon seçeneğine sahip olmanın önemini anlamış olacaksınız ve dökümleri işlemek için başka bir seçeneği kullanamayacağınız gerçeğinden kesinlikle nefret edeceksiniz. sisteminizin kurulu olması. Systemd-coredumpd ile neler olabileceğine bir örnek.

https://bugs.archlinux.org/task/41728

Şimdi bitirmek için:

Modüler programlar ve süreçler olmaları gerekmiyor mu? Evet, modülerdir. Çekirdek, burada bahsettiğim tek monolitik şeydir, ancak aynı zamanda modülleri (LKM) de kabul eder, bu nedenle temel tasarım biçimi bu tür bir yapıda tasarlanmamış olsa da bir tür hibrit çekirdek haline gelir ve bu, belirli koşullar altında biraz dengesiz hale getirir.

Bu modülerlik, bir şeyler ters giderse süreçlerimin ve sistemimin çökmesini önlememe izin vermemeli mi? Doğru, modülerlik, yüksek derecede kararlılık ve güvenilirlik elde etmek için tasarlanmış bir ölçüdür, ancak% 100 yanılmaz bir ölçü değildir, çünkü eğer bir şeyler ters gidebilirse, ne kadar modüler olursa olsun, basitçe ters gidecektir. gerçeklik.

Çekirdeğe eklenen cgrupların ve diğer seçeneklerin kullanımını mümkün kılmak için hangi sistemin her şeyi kontrol etmesi gerekir? Tamamen yanlış. Bu hiç gerekli değildir, systemd, şu anda sahip olduğu hizmetlerin sayısını devralmak zorunda kalmadan, sistemde olacak süreçlere ve arka plan yordamlarına cgroupların başlatılmasını ve atanmasını kontrol etmek için bir arayüzle bırakılabilirdi ve buna en iyi örnek; OpenRC ayrıca cgroup kullanma yeteneğine sahiptir ve bu nedenle bu görevi yerine getirmek için çok istilacı değildir.

Systemd hakkında konuşurken neden önyargılı ve korkuyorum? Bunu nereden aldığına dair hiçbir fikrim yok, çünkü cevabımı gördüğünüz gibi bundan korkmuyorum, sadece systemd hakkında sevmediğim yönlerden ve üçüncü şahısların görüşlerine güvenmeden şimdiden bahsediyorum.

Son olarak şunu söylüyorsunuz: "Programcı, beklenmedik girdi ve çıktılarla başa çıkabilecek kod eklememek konusunda o kadar kötüyse, bu başka bir şey ..."

Kesinlikle programcının, programının bazı hatalı veri girişleri ile kırılmasının tüm olası yollarını işleyen bir kodu dahil etmemesi KÖTÜ, bana bir rezalet gibi görünüyor. Ne kadar iyi bir programcı olursa olsun, kişi yanılmaz ve başarısızlık korumalı bir program tasarlayamaz, HER ZAMAN bir başarısızlık olacak, hangisi ya da bu şekilde gün ışığına çıkacak ve ne zaman olursa olsun, şükürler olsun. bir güvenlik açığından yararlanan bir bilgisayar korsanı veya korsan tarafından, bir kod incelemesi ve denetimi veya programcının güvenebileceği başka herhangi bir yolla kullanımı sırasında rastgele bir başarısızlık. Böyle bir şey söylemeden önce kelimeleri ölçmek daha iyidir.

Selamlar.