Sistem D'yi Aydınlatmak

Bilgisayarlarımız her geçen gün hayatımızın giderek daha önemli bir parçası haline geliyor; herhangi bir sorun yaşadıklarında ruh halimizi, neşemizi etkiliyor, haha. Tabii ki, Windows kullanıcıları panik ataklara daha yatkın: virüsler ( yaşasın Linux! ), HDD'yi birleştirme, PC için Clean Master'ı bulup kurma ( Linux'ta da sistemi temizlememiz gerekiyor; BleachBit tercih edilen alternatiflerden biri ). Son zamanlarda, bazı Linux kullanıcıları systemd adı verilen belirli bir baş ağrısıyla karşılaşıyor .

Neyse, konuya gelecek olursak, son zamanlarda oldukça popüler olan systemd hakkında ilginç bir makale okudum .

Bazılarının ( ve bir arkadaşımın sözlerini kullanacağım ) "her şeye hükmeden tek yüzük " olarak gördüğü Systemd ... diğerleri içinse tamamen kayıtsız; bilgisayar düzgün çalıştığı sürece, init'in X veya Y yapıp yapmadığı veya systemd kullanılıp kullanılmadığı umurunda değil. Bana gelince... kısaca init'i tercih ederim; daha basit buluyorum.

Makaleyi burada bırakıyorum:

Başlamadan önce, Debian'da yapılan değişikliklerden şiddetle hoşlanmadığımı belirtmeliyim, ancak sevgili spiralimi terk etme niyetim de yok. Sadece, bir konuyu tartışacaksak, mümkün olduğunca hazırlıklı olmamızı sağlamaya çalışıyorum, kendim systemd yanlısı olmasam da. Systemd'yi açıklığa kavuşturmak için, geliştiricilerin bakış açılarını paylaştığı bir web sitesine başvuracağım; bu siteyi, Debian kullanıcısı olmamasına rağmen systemd yanlısı gibi görünen bir meslektaşım sayesinde fark ettim. Bunları söyledikten sonra, systemd hakkında söylenenleri açıklığa kavuşturmaya başlayabilirim diye düşünüyorum.

systemd ikili tabanlıdır

Belki de bizi en çok şok eden yönlerden biri budur, eğer her şey ikiliye dayanıyorsa, günlükler aracılığıyla genellikle yaptığımız şeyleri nasıl izleriz? Bu efsanenin nasıl doğduğu hakkında hiçbir fikrim yok, ama bu tam olarak doğru değil.

systemd, neredeyse yalnızca düz metin dosyaları aracılığıyla yapılandırılır. Çekirdek komut satırı ve ortam değişkenleri aracılığıyla da değiştirilebilen bazı ayarlar. Yapılandırmanızda ikili hiçbir şey yok (XML bile). Sadece basit, anlaşılır ve okunması kolay bir metin dosyası.

systemd fanları homer simpson

Bu şey monolitik ve her şeyi kontrol ediyor

Bahsi geçen web sitesine ulaşmadan önce, kendim de böyle düşündüğümü itiraf ediyorum, ancak geliştiricilerinin söylediklerini okuduktan sonra fikrim bir şeyi değiştirdi ...

Tüm yapılandırma seçenekleri etkinleştirilmiş olarak systemd'yi derlerseniz, 69 ayrı ikili dosya oluşturursunuz . Bu ikili dosyalar farklı görevlere hizmet eder ve çeşitli nedenlerle dikkatlice ayrılmıştır. Örneğin, systemd güvenlik göz önünde bulundurularak tasarlanmıştır; bu nedenle, çoğu arka plan programı minimum ayrıcalıklarla (örneğin çekirdek yeteneklerini kullanarak) çalışır ve yalnızca çok özel görevlerden sorumludur, böylece güvenlik yüzeyleri ve etkileri en aza indirilir. Ayrıca, systemd önyüklemeyi önceki çözümlerden daha fazla paralelleştirir. Bu "paralelleştirme", birden fazla işlemin paralel olarak çalıştırılmasıyla oluşturulur. Bu nedenle, systemd'nin birçok ikili dosyaya ve dolayısıyla işleme çok iyi bir şekilde bölündüğü açıktır. Aslında, bu ikili dosyaların çoğu o kadar iyi ayrılmıştır ki, systemd dışında da çok kullanışlıdırlar.

69 ayrı ikili dosya içeren bir pakete monolitik demek pek doğru olmaz . Ancak önceki çözümlerden farklı olarak, tek bir tarball içinde daha fazla bileşen gönderiyoruz ve bunları birleşik bir yayın döngüsüyle tek bir depoda birbirine bağlı tutuyoruz.

Bu Unix'e benzemiyor

Bunda kesinlikle bazı gerçekler var. Systemd kaynak dosyaları, orijinal UNIX satırlarından tek bir kod satırı içermez. Bununla birlikte, ilham UNIX'ten türetilmiştir ve bu nedenle systemd'de çok sayıda UNIX vardır. Bir örnek, "her şey bir dosyadır" UNIX fikri olabilir ki bu, systemd'de tüm hizmetlerin bir çekirdek dosya sisteminde çalışma zamanında açığa çıkarılmasıdır cgroupf'ler. Dolayısıyla, UNIX'in orijinal özelliklerinden biri, yerleşik terminal desteğine dayalı çoklu koltuk desteğiydi. Systemd ile tekrar doğal olarak çoklu koltuk desteğini getirdik, ancak bu sefer grafikler, fareler, ses, web kameraları ve daha fazlasını kapsayan günümüzün donanımı için tam destek sağladık. Aslında systemd'nin, her birinin kendine özgü amaçları olan ancak birlikte kullanıldıklarında parçaların toplamından daha fazlası olan bir entegre araçlar paketi olarak tasarımı, aşağı yukarı UNIX felsefesinin merkezinde yer alır. Dolayısıyla, projemizin işlenme şekli (yani işletim sistemi çekirdeğinin çoğunu tek bir git deposunda tutmak), işleri halletmek için BSD modeline (Linux'un aksine gerçek bir UNIX'tir) çok daha yakındır (çoğu durumda çekirdek işletim sistemi tek bir CVS / SVN deposunda tutulur) ki bu Linux'ta hiçbir zaman geçerli değildir.

Sonuçta, bir şeyin UNIX olup olmadığı sorusu çok az önemli. Teknik olarak mükemmel olması, UNIX'e pek de benzersiz değildir. Bizim için UNIX önemli bir etkidir (aslında en büyüğüdür), ancak başka etkilerimiz de var. Bu nedenle, bazı alanlarda systemd çok UNIX olacak ve bazılarında biraz daha az olacaktır.

Bu çok karmaşık ...

Bunda kesinlikle bazı gerçekler var. Modern bilgisayarlar karmaşık yaratıklardır ve üzerlerinde çalışan işletim sistemi de kesinlikle olacaktır, bu yüzden karmaşık olmaları gerekir. Bununla birlikte, systemd kesinlikle aynı bileşenlerin önceki uygulamalarından daha karmaşık değildir. Daha basittir ve daha az fazlalığa sahiptir. Öte yandan, basit bir systemd tabanlı işletim sistemi oluşturmak, geleneksel Linux kullanımlarından çok daha az paket içerecektir. Daha az paket, sisteminizi kurmayı kolaylaştırır, karşılıklı bağımlılıklardan ve dahil olan tüm bileşenlerin birçok farklı davranışından kurtulur.

Bu kabuk komut dosyalarını kullanmama izin vermiyor

Bu tamamen yanlış. Biz onları önyükleme işlemi için kullanmıyoruz çünkü bu özel amaç için en iyi araç olmadıklarına inanıyoruz, ancak bu systemd'nin onlarla uyumsuz olduğu anlamına gelmez. Kabuk komut dosyalarını systemd servisleri veya arka plan programları olarak kolayca çalıştırabilirsiniz; herhangi bir dilde yazılmış komut dosyalarını systemd servisleri olarak çalıştırabilirsiniz çünkü systemd, yürütülebilir dosyanızın içinde ne olduğuna en ufak bir önem vermez. Dahası, biz kendi amaçlarımız için kabuk komut dosyalarını yoğun olarak kullanıyoruz: systemd'yi kurmak, derlemek ve test etmek için. Ve komut dosyalarını erken başlatma işlemine yapıştırabilir, normal servisler için kullanabilir, son kapatmada çalıştırabilirsiniz—pratik olarak hiçbir sınır yok.

Bu noktada, sanırım bazı temel inançlar açıklığa kavuşmuş olabilir. Kendimi değişim yanlısı olarak görmesem ve " her şeye hükmedecek tek bir şeytan " fikrine dair çekincelerim olsa da, sonunda kimsenin bunun hiç işe yaramadığını söylemeye cesaret edemeyeceğini düşünüyorum. Hatta systemd ile "bilgisayarın daha hızlı çalıştığını" fark eden bazı kullanıcılar bile tanıyorum, ancak bu başka bir tartışma konusu olurdu. Şimdilik, birçok dağıtımın benimsediği init sistemi hakkındaki görüşlerinizi burada tartışmaya davet edebilirim; ancak en güçlü tepkiler şu anda Debian topluluğunda görülüyor ve bu durum yüzünden yeni bir çatal bile ortaya çıkardı. Beğenip beğenmemeniz kişisel bir mesele; ben ise sadece systemd'yi gizemden arındırmak için elimden gelenin en iyisini yapmak istiyorum, ki bu da nihayetinde Debian'ın bir sonraki kararlı sürümü olan Jessie'de yer alacak.

GUTL'de (ki bu da DesdeAbreus'tan alınmıştı ) makaleyi gördüm.

şairlik-1984

Sistem akımı?

Ben bir konu bu kadar tartışma yarattığında fazla haber okumayanlardanım, daha teknik detaylarda kalmayı tercih ediyorum. Mesele şu ki... Bazen bazı konuların tamamen teknik bir tartışma veya münazara olmaktan çıkıp şov dünyasındaki dedikodulardan biri haline geldiğini hissediyorum 

Öncelikle, bir kullanıcının systemd hakkında "systemd VS intelligence" başlıklı açık bir eleştirisi , ardından Linus Torvalds'ın systemd'nin sanıldığı kadar kötü olmadığını söylemesi ( ve haklı olduğu noktalar var ), uselessd adlı bir çatal ... yorum yok... ve uzun lafın kısası, sonunda Devuan.

Söyledikleri kadar kötü mü, daha az kötü mü yoksa daha kötü mü olduğunu söylemeyeceğim. Sistem benim için gayet iyi çalışıyor, ancak şahsen çeşitli şeyleri (örneğin logları) düzenleme şeklini sevdiğim için init'i tercih ederim. Ama eğer systemd bir yarış atı olarak adlandırılacaksa ve init'in yerini alacaksa ( her şeyi yapan ama yavaş olmayan bir iş atı mı olacak? ), o zaman... değişiklik çok radikal olmadığı, kullanıcılar çok fazla sorun yaşamadan uyum sağlayabildiği ve sistem daha iyi çalıştığı sürece (evet, daha iyi, belki bu benim için yeterli olmayacak!), o zaman memnuniyetle karşılıyorum! 😉


Google'da tercih edilen kaynak olarak ekleyin.