Sistem D'yi Aydınlatmak

Bilgisayarlarımız her gün hayatımızın daha önemli bir parçasını oluşturuyor, bir tür sorunu varsa ruh halimizi, mizahımızı etkiliyor. Elbette, Windows kullanıcıları, virüslere kıyasla panik ataklarına daha yatkındır (çok yaşa linux!), ya HDD birleştiriliyorsa, ya PC için Clean Master (burada Linux'ta sistemi hala temizlememiz gerekmesine rağmen, BleachBit tercih edilen alternatiflerden biridir). Son zamanlarda Linux kullanıcılarının (bazılarının) belirli bir baş ağrısı var: systemd

İşin aslı, hakkında ilginç bir makale okudum systemd, bu trend uzun sürmez gibi görünüyor.

SistemD, bazılarına benzeyen (ve bir arkadaşın sözlerini kullanacağım), hepsine hükmedecek bir yüzük ... diğerleri, bilgisayar iyi çalıştığı sürece, init'in X ya da Y şeyler yapıp yapmadığı ya da systemd'nin kullanılıp kullanılmadığı umurlarında değil. Yazan bu kişiye, peki ... diyelim ki init'i tercih ediyorum, daha basit buluyorum 🙂

Makaleyi burada bırakıyorum:

Başlamadan önce Debian'da bir şeyleri değiştirme kararından hoşlanmadığımı söylemeliyim, ancak hiçbir noktada sevgili spiralimi terk etmeyi planlamıyorum. Bunu deniyorum, eğer bir konuyu tartışacaksak, kendimi sistem yanlısı olarak görmeme rağmen en azından mümkün olduğunca hazırlıklı hale getiriyoruz. Sistemin gizemini çözmeyi başarmak için bir web sitesine güveneceğim. geliştiriciler bakış açılarını verir Debian kullanıcısı olmamasına rağmen sistem yanlısı görünen bir meslektaşım tarafından elime geldi. Bununla birlikte systemd hakkında söylenenleri aydınlatmaya çalışabileceğimi 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 ...

Systemd'yi tüm yapılandırma seçenekleri etkin olarak oluşturursanız, 69 ayrı ikili. Bu ikili dosyalar farklı görevlere hizmet eder ve çeşitli nedenlerle dikkatlice ayrılır. Örneğin, systemd güvenlik göz önünde bulundurularak tasarlanmıştır, bu nedenle arka plan yordamlarının çoğu en az ayrıcalıklarla çalışır (örneğin, çekirdek yeteneklerini kullanarak) ve ayak izlerini en aza indirmek için yalnızca çok özel görevlerden sorumludur. güvenlik ve etki. Ayrıca systemd, önceki çözümlerden daha fazla önyükleme yapar. Bu "paralelleştirme" çalıştırılarak oluşturulur çeşitli süreçler paralel. Bu nedenle, systemd'nin birçok ikiliye ve dolayısıyla süreçlere çok iyi bölündüğü görülmektedir. Aslında, bu ikili dosyaların çoğu o kadar iyi ayrılırlar ki systemd dışında çok faydalıdırlar.

69 ayrı ikili dosya içeren bir paket neredeyse hiç çağrılamaz monolitik. Bununla birlikte, önceki çözümlerden farklı olan, tek bir tarball'da daha fazla bileşen göndermemiz ve bunları birleşik bir yayın döngüsü ile tek bir depoda zincirlenmiş halde tutmamızdır.

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 doğru değil. basitçe Bunları önyükleme işlemi için kullanmıyoruz, çünkü bu belirli amaç için en iyi araç olmadıklarını düşünüyoruz, ancak bu, systemd'nin onlarla uyumsuz olduğu anlamına gelmez. Kabuk betiklerini systemd hizmetleri veya arka plan yordamları olarak kolayca çalıştırabilir, içinde yazılmış betikleri çalıştırabilirsiniz. herhangi systemd hizmetleri olarak dil, çünkü systemd yürütülebilir dosyasının içinde ne olduğunu umursamıyor. Öte yandan, sistemi kurmak, oluşturmak ve test etmek için büyük ölçüde kendi amaçlarımız için kabuk komut dosyalarını kullanıyoruz. Ve komut dosyalarını erken başlatma sürecine yapıştırabilirsiniz, normal servisler için kullanılırlar, son durakta çalıştırılabilirler, pratikte sınır yoktur.

Bu noktada, değişimin savunucusu gibi hissetmeme ve "hakkında endişelerim olmasına rağmen, bazı temel inançların açıklığa kavuşmuş olabileceğini düşünüyorum.hepsini kontrol eden bir iblis"Bence sonunda hiç kimse en azından işe yaramadığını söylemeye cesaret edemeyecek, hatta systemd ile" PC'nin daha hızlı çalıştığını "fark eden bazı kullanıcıları bile tanıyorum, ancak bunlar tartışılabilecek başka şeyler olabilir. Şimdilik, sizi burada birçok dağıtımın benimsediği startup yöneticisi hakkında sahip olduğunuz bakış açılarını tartışmaya davet etmek bana kalıyor, ancak şu anda en büyük tepkiler Debian topluluğunda görülüyor. Hepsi bu. Hoşunuza gitsin ya da gitmesin herkes için bir mesele, benim açımdan sadece Debian'ın bir sonraki kararlı sürümü olan Jessie'de bulunacak olan sistemd'yi aydınlatmak için üzerime düşeni yapmak istiyorum.

 Makaleyi GUTL'de gördüm (bu da FromAbreus)

şairlik-1984

Sistem akımı?

Bir şey bu kadar tartışma yarattığında pek haber okumayanlardanım, daha teknik detaylarla kalmayı tercih ediyorum. Bu mu…. Bazen belirli konuların sadece teknik bir tartışma ya da tartışma olmaktan çıktığını ve ünlü dedikodularından biri haline geldiğini hissediyorum 🙁

Önce bir kullanıcıdan systemd'ye açık bir satır çağrıldı systemd VS zeka, sonra Linus Torvalds şunu söylüyor: systemd o kadar da kötü değil nasıl boyadılarve eğer varsa bir sebep), çatal adı verilen işe yaramaz … Yorum yok… ve sonunda Devuan.

Söyledikleri kadar kötü mü, daha az mı yoksa daha mı kötü demeyeceğim. Sistem benim için sorunsuz çalışıyor, ancak kişisel zevkim için init'i tercih ederim, çünkü çeşitli şeyleri organize etme yöntemi (örneğin günlükler gibi) daha çok seviyorum, ama hey, eğer sistem bir yarış atı olarak adlandırılırsa ve yerini alması gerekirse init (Her şeyi yavaş ama yavaş yapan yük katırımız mı olurdu?) Şey ... dostum, değişim aşırı derecede ani olmadığı sürece, kullanıcılar çok fazla sorun yaşamadan adapte olabilir ve sistem daha iyi çalışır (evet, daha iyi, benim için yeterli değil!), Hoş geldiniz 😀


Makalenin içeriği şu ilkelerimize uygundur editoryal etik. Bir hata bildirmek için tıklayın burada.

114 yorum, sizinkini bırakın

Yorumunuzu bırakın

E-posta hesabınız yayınlanmayacak.

*

*

  1. Verilerden sorumlu: Miguel Ángel Gatón
  2. Verilerin amacı: Kontrol SPAM, yorum yönetimi.
  3. Meşruiyet: Onayınız
  4. Verilerin iletilmesi: Veriler, yasal zorunluluk dışında üçüncü kişilere iletilmeyecektir.
  5. Veri depolama: Occentus Networks (AB) tarafından barındırılan veritabanı
  6. Haklar: Bilgilerinizi istediğiniz zaman sınırlayabilir, kurtarabilir ve silebilirsiniz.

  1.   Darkar dijo

    Çok güzel bir makale, Linux Mint 17.1 Rebecca'yı birkaç gündür systemd ile kullanıyorum ve önceki sürümlerden çok daha akıcı hissediyorum, bunun hakkında pek bir şey bilmiyorum çünkü bunu öğrenen sıradan bir kullanıcıyım ama Ben uyanık olacağım, bu systemD'nin zararlılarından bahsetmeyen okuduğum ilk makale.

    1.    SynFlag dijo

      Bir şey için, onun hakkında zararlılardan bahsetmeyen ilk okuduğunuz kişi olacak ve diğer yandan söyle bana, Nane'nizi sunucu olarak mı kullanıyorsunuz? Yani, bir hata varsa sizi rahatsız etmez. Bu yüzden Mint kullanıyorsun ve bu yüzden seni rahatsız etmiyor, hoşuna gitmiyor ama sistem de canını sıkmıyor. Böcekleriniz olduğunda ve bu nedenle ciddi ortamlarda ciddi sorunlar yaşarsanız sizi rahatsız edecektir.

      1.    carlos dijo

        Dostum, tavsiye ettiğin herhangi bir Debian Stable tabanlı dağıtım var mı? Debian'ı kullanabilirim, ancak yüklendikten sonra birçok şeyi, kodekleri vb. Yapılandırmanız gerekir ... Hangisini önerirsiniz? Teşekkürler.

    2.    Santiago Burgos dijo

      Ve Linux Mint'e systemd almayı nasıl başardınız? Bunu eklemek istedim ama yapacak ek bir şey olup olmadığını bilmiyorum (teoride Ubuntu'nun getirdiği gibi), konu hakkında herhangi bir rehberiniz veya bana iletebileceğiniz bir şey varsa, ben minnettar olurum

  2.   Giskard dijo

    Çok güzel makale. Bakalım Taliban anti-SystemD okuyup okumadı (ama bundan şüpheliyim)

    Her halükarda, bundan bir yıl sonra onların SystemD kullandıklarını göreceğim ve bir yıl önce söylediklerini inkar edecekler. Yani onlar. Değişime dayanıklı mı? Kesinlikle evet.

    1.    ela dijo

      Systemd'yi kabul etmek istemediğim için beni bir Taliban olarak görüyorsun, o zaman Systemd'yi kabul etmek istemediğimi kabul etmek istemediğin için seni bir Taliban olarak görüyorum. Yakınızdayız 😉

      1.    Jlbaena dijo

        Ancak makalelerinizin sonunda dediği gibi:

        «Elav: Kişisel Blog / Twitter / G + / ArchLinux Kullanıcısı. Bilgisayar bilimcisi, müzik aşığı, blog yazarı ve web tasarımcısı. DesdeLinux.net'in Yöneticisi ve Kurucusu. »

        yani, SystemD'nin benimsediği ilk dağıtımlardan birini kullanırsınız.

        selamlar

    2.    George Robles dijo

      Tamam evlat.
      Kelimeler olmadan !!!!, oynamaya devam edin, bu hayat pembe.

    3.    Tito dijo

      Sevgili Giskard, sizinki gibi yorumlar için, SystemD'yi ve ne anlama geldiğini bu yüzden reddediyorum.
      Ve eğer Linux için ve Linux için 20 yıl kullandıktan ve çalıştıktan sonra, ben bir Taliban'ım; Öyle olsun.

    4.    Giskard dijo

      Bir yıl içinde konuşuruz. Ve elav, senden bahsetmedim. Kendini Chacumbele olarak öldürdün.

    5.    Giskard dijo

      Bakalım, insanlar okuyup OKUMAYIN. SystemD'ye karşı Taliban var mı yoksa yok mu? Var! Ve diğer tarafta başkaları da var, sanki her derde deva gibi onu diş ve çivi savunanlar. Hepsi kimler? Hayır! Bir şey değil! Birine ya da diğerine sempati duyan ve hem kendisinin hem de başkalarının iyisiyle kötüsünü görenler var. Bunlarla sorunsuz konuşabilirsiniz. Ancak Taliban'ın OLDUĞUNU inkar etmeyecekler. Ve bir yandan diğer yana. Ve eğer birisi Taliban OLMAYACAĞINI anlayamadan bununla soktuysa, kanıtlar onları suçlu kıldığı için davamı dinlendiriyorum.
      SystemD hakkında biriyle diyalog kurarsam ve en başından bu kişi onu ismiyle değil, Systemshit veya benzeri bir şeyle çağırırsa, başlangıçta diskalifiye eden böyle bir kişiyle bir konuşma yapmanın mümkün olup olmadığını içtenlikle söylemelerini isterim. karşı taraf. Olamaz.
      Her neyse, okumak zorundasın. Bakalım, gelip "okulu bıraktıklarında çocukları döven bazı eschejfhduf (uydurulmuş kelime) var mı" dersem ve birkaçı da "eschejfhduf" u savunmaya gelirse, kendilerinin öyle olduğunu düşünmek değil mi?
      Pekala, eğer dışarıda biri (Taliban değil, lütfen ve eschejfhduf değil) init ve SystemD'nin (her ikisi de iyi ve kötü olan) artıları ve eksileri hakkında konuşmak isterse, burada olmaktan mutlu olacağım.
      Selamlar.

    6.    eş bayrağı dijo

      Taliban karşıtı sistem mi? ve söyle bana sen nesin Sistem yanlısı Taliban?, Öte yandan, neden okumayacağımızı, doğrudan yorum yapacağımızı düşünüyorsunuz? Tartışmayı kabul etmeyen ve LP gibi konuşan kapalı görüşlü Taliban kimdir :: « en iyisi, güven bana ne yaptığımı biliyorum ". ?

      Tüm makaleyi okudum ve size söyleyebilirim:

      Systemd ikili tabanlıdır: Doğru
      Gizem giderme: Yanlış

      LP söylenenleri yanlış temsil ediyor, yani systemd çekirdeği ikili, çok, çok fazla, PID1'e asılmak için çok fazla, o kadar çok ki, sizi #devuan temizlemenin maliyetine bakmaya davet ediyorum, örneğin, günlüğü systemd ve Debian'daki paketlerin geri kalanı, PAM'ın yerini alan günlük kaydının sistemle ne kadar bağlantılı olduğu göz önüne alındığında.

      Konfigürasyon kısa ve öz ve günlüğü devre dışı bırakmak gibi istemediğim HER ŞEYE izin vermiyor, çünkü ne PID'yi öldürebilir ne de durdurabilir ya da herhangi bir şey, yani modülerlik? , aynı başlangıç.

      ===========
      "Bu şey yekpare ve her şeyi kontrol ediyor."

      2 veya 69 ikili olmanın ötesinde, birbirleriyle dbus ile ve dolayısıyla tüm işletim sistemiyle iç içe geçerler, kolayca ilişkisiz olmalarına izin vermezler, en açık durum günlüktür, onu devre dışı bırakamazsınız, ayrıca arka plan yordamlarının başlangıcı veya hizmetler metin dosyaları olan, ancak bundan başka bir şey olmayan, systemd ve voila tarafından ayrıştırılan "birimler" aracılığıyla yapılır, hizmetlerde kurulanın ötesinde hiçbir değişiklik veya hackleme yapılmaz.

      =======

      "UNIX'e benzemiyor"

      Kısaca cevaplayacağım. Ne LSB'ye ne de POSIX'e uymuyor ve bugün #devuan'da yardımcı olan bir fedora geliştiricisi şöyle dedi: "Olmadığı doğru, önemli değil, önemli olan POSIX olan şeyleri çalıştırabilmesidir. dinlenme, kesinlikle çalıştığı ve iyi özelliklere sahip olduğu sürece hangi işletim sistemi veya neyse onunla ilgilenmiyorum ». Ve neden UNIX veya UNIX benzeri olması gerektiği: Bir şeyi yapın ve onu iyi yapın, sistemin yapmadığı bir şeyi.

      ===========

      Ancak, systemd kesinlikle aynı bileşenlerin önceki uygulamalarından daha karmaşık değildir. Daha basit ve daha az yedeklilik var »

      Daha az fazlalık? Sizden düz metin için BAŞKA bir syslog kurmanızı istiyorlar ve sistemd-journald-remote olmadan önce uzaktan günlük kaydı için istediler, yani rsyslog'a bağlı olmadan uzaktan günlük kaydı yapmadan üretime koydular, merkezi oturum açma gibi temel bir şey. Öyle olsa bile, çıktıyı ikili mi yoksa düz metin olarak mı isteyeceğimizi ve ayrıca ikili kullanacaksa neden berkeley DB olarak bilinen bir şeyin okunabilmesini istemediğini gösteren basit bir boole yeteneği yoktur. herhangi bir UNIX veya Linux sisteminden?

      Basit mi? Gerçekten mi? ne kadar basit olduğuna bir göz atın: http://wiki.gentoo.org/wiki/Comparison_of_init_systems

      Kod ve dosya satırlarının miktarına bakın.

      =========================

      "Bu, kabuk komut dosyalarını kullanmama izin vermiyor"

      Bu yanlıştır, ancak yine yanlış ifade edilmiştir, bash betiğinin kullanımına izin vermediği için eleştirilmemiştir, ancak hizmetleri başlatmak için kullanmadığı için eleştirilmemiştir, bu nedenle de değiştirilebilir, hacklenebilir ve upstart veya sysvinit kadar esnek değildir. Ve hacklenebilir derken, kodlanmış demek istiyorum.

      ============================

      Hâlâ şunu düşünüyorsunuz:

      1.- Hiçbir sebebim yok
      2.- Hiçbir şey okumadım ve ben bir Taliban mıyım?

      1.    Richard dijo

        Merak ediyorum ... Lennart'ın söylediğine gerçekten güvenmek zorunda mıyım? Tarafsız biri bana bazı şeyleri dikkate alabileceğimi söylerse, ama Red Hat Systemd'yi savunmak için bir şeyler yayınladığından bu benim için aynı tadı veriyor.

  3.   ArthurShelby dijo

    Ta ki buralarda biri sadece korku ve yanlış bilgi değil, mantıklı bir şey söyleyene kadar.

    1.    ela dijo

      Makale, Lennart'ın yazdıklarının İspanyolca çevirisidir.

      1.    Charlie kahverengi dijo

        Alınma ama çeviri Google Translator beta sürümüyle yapılmış gibi görünüyor… 🙁 Bazı paragrafları anlamakta zorlandım; her neyse, bilgiler takdir edilmektedir.

      2.    kırlangıç dijo

        @ Charlie-Brown, çünkü Lennart kendini İngilizce olarak nasıl ifade edeceğini çok iyi bilmiyor. Orijinali okumak bu kadar çirkin.

  4.   Charlie kahverengi dijo

    Verilen nedenler geçerli, ancak bazılarının daha fazla soru üretebileceğini düşünüyorum. Her halükarda, fırsatı olanlara tavsiyem: bilginin orijinal kaynağına git http://0pointer.net/blog/projects/the-biggest-myths.html (maalesef bazıları için İngilizce'dir) ve bu çok daha eksiksizdir ve SistemD kullanımının neden uygun olduğu düşünülen 30'a kadar nedeni kanıtlayacak kadar ileri gider.

    1.    ela dijo

      Bahsettiğiniz bu makale Systemd'nin yaratıcısı tarafından yazılmıştır. Açıkçası, çalışmalarını savunmak için ondan daha iyi kimse yok, ancak sizi bu videoyu izlemeye davet ediyorum http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html ve bana bu konudaki sonuçlarını anlatacaklar. Ben daha fazlasını söylemiyorum.

      1.    rolo dijo

        Bir ikili dosyada olan günlük günlükleri sorunu en çok eleştirilen noktalardan biridir, hatta linus, sistemin o kadar da kötü olmadığını kabul ettiği bir raporda bunu dile getirdi. Ayrıca linus, günlük verilerini almak ve düz metne koymak için bir komut dosyası oluşturabileceğinizi açıkladı.
        Ayrıca systemd, olası bir arıza riskini azaltarak günlük ikili dosyasının boyutunu yapılandırmanıza izin verir.

        Aslında, alıntı yaptığınız sanat çok ciddidir, çünkü nesnelliğe dair bir ipucu yoktur ve hatta gösterdiği hatanın gerçek mi yoksa sahte mi olduğunu merak etmeme neden olur (hatayı vermesi için özel mülk yazılımı siktirin).

        tüm programların bir noktada hataları vardır, ancak görünen o ki, systemd ile ilgili yanlış bir şey bulmak için her zaman kedinin beşinci ayağını arayacaklar.

        Örneğin: debian'da systemd'nin varsayılan init olmasına karar verildi, ancak sysvinit veya openrc veya upstart kullanılmasını engellemiyor ve bana iyi bir şekilde evet diyeceksiniz, ancak systemd'yi tamamen kaldıramazsınız ve cevabım bunun debian wheezy'de olduğu gibi olacağı olacaktır. openrc, systemd veya upstart'ı çalıştırabileceğiniz ancak sysvinit altında

        Not: kdbus ve linux kernel seviyesinde systemd ile entegrasyonu ile ne kadar çılgınca olacaklarını hayal etmek istemiyorum http://kroah.com/log/blog/2014/01/15/kdbus-details/

        1.    ela dijo

          Olabilirse. Ayrıca Systemd ile ilgili tartışmalardan resmi olarak çekilmeyi planlıyorum. Ne olursa olsun 🙂

      2.    yukiteru dijo

        @rolo'nun başarısızlığı belgelendi, kendisine birkaç hata raporu sunuldu, ona bir video sundular ve şimdi bunun sahte olduğunu söylüyorlar. Emin olmak istiyorsanız, adımları izleyin ve ne olacağını görün. Şimdi burada konu hakkında daha fazla bilgi, icat edilen böcekler var mı? Ben öyle düşünmüyorum.

        https://bugzilla.redhat.com/show_bug.cgi?id=958321
        https://bugzilla.redhat.com/show_bug.cgi?id=1054929
        https://bugzilla.redhat.com/show_bug.cgi?id=1055570
        https://www.libreoffice.org/bugzilla/show_bug.cgi?id=74280
        https://bugs.archlinux.org/task/32191
        https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 (Lennart ve harika açıklamaları)
        https://bugzilla.redhat.com/show_bug.cgi?id=974132
        https://bugzilla.redhat.com/show_bug.cgi?id=1157350

      3.    Emmanuel dijo

        Videonun bahsettiği şey kesinlikle ilginç. Bir geliştirici olarak bize her zaman bir detayın tüm sistemi / programı etkilememesi gerektiği söylendi, örneğin veritabanına yönelik bir seçme sorgusu başarısız olursa, neden tüm program çökmeli? SystemD ile aynı, eğer diğerleri başarısız olduğu için başarısız olursa, ne kadar iyi yapıldığını bilmiyorum. Açıktır ki, bir arızanın pratik olarak sistemin arızası olduğu durumlar vardır, ancak programın özellikleri ne kadar içsel olarak izole edilirse, ürün o kadar iyi olacaktır.
        Şimdi, yazılıma zayıf tarafından saldırmak yeni değil, çok yaygın bir uygulamadır ve aslında her programda yapılması gerektiği için SystemD'nin dergiye düştüğünü görmek, SystemD'nin ne olduğunun geçerli bir kanıtıdır. dedi veya inanmaya yönlendirdi.
        SystemD ile ne kadar çok şey birbirine bağımlı hale gelirse, işler o kadar kötüleşir. Bir cihazı monte etmeden önce sistemi çökertmediyse, şimdi işler o kadar iyi görünmeyebilir.
        SystemD fena değil, ondan nefret etmiyorum, ama pek çoğunun inanacağı şey bu değil. Avantajları var, ancak Upstart'ın sahip olmadığı veya sahip olabileceği hiçbir şey, elbette, Canonical dahil edildi ve artık kimse dikkat çekmek istemedi.
        Selamlar.

      4.    rolo dijo

        ancak bu videoda hiçbir zaman sistemin çöktüğünü bilmiyorum. yaptığı şey, hatayı oluşturmak için günlük bilgisinin ikilisini değiştirmektir, ancak önemli olan, systemd'ye her girdiğinde olmasıdır.
        Anladığım kadarıyla, günlük ikili dosyasının boyutunu sınırlarsanız, sınıra ulaştığında başka bir tane oluşturur ve bu böyle devam eder. tüm verilerin bozulma olasılığını azaltmak.

      5.    Jorge dijo

        Açık konuşalım ... Günlük dosyasını da değiştirmeyi kim düşünür? xD

      6.    anonim dijo

        @Jorgicio 4 Aralık, 2014 6:03
        Açık konuşalım ... Günlük dosyasını da değiştirmeyi kim düşünür? xD

        Eğer ironik bir şekilde söylediyseniz ... tamam, anladım :)), ama gerçekten sorduysanız, bakış açımı veriyorum.

        Benim için bunun bir hata olmadığı açıktır, bir özelliktir !! Buradaki fikir, uzaktan erişimde ayrıcalıkların artması durumunda, günlüğü sadece bozmak için düzenleyerek silmeyi kabul edenler için ve systemd'nin onu bozuk olarak silmesi ve böylece bu uzaktan erişimde tespit edilmekten kurtulmasının çok kolay olacağıdır.
        Bana paranoyak olduğunu söyle, ama başka düşünemiyorum ... Bu bir hata değil, bir özellik ve bu yüzden bu hatayı düzeltmeyi kabul etmiyorlar.

  5.   Daryo dijo

    uff şimdi tüm linux blogları systemd hakkında 200 makale yazıyor ki xD için ve xD için neredeyse tüm argümanları zaten biliyorum.

    ve yavaş yavaş bazı sistemd karşıtı argümanlar ve gördüklerim arasında ikna oldum (yanlış bir şey varsa lütfen beni düzeltin)

    Orada bir ikili günlüğü düzenlerken tüm sistemin nasıl çökertileceğine ve dosyanın bozuk olduğuna dair herhangi bir bilgi vermediğine dair bir makale bile gördüm.

    günlüklerdeki netlik eksikliği

    genellikle hata raporlarını görmezden gelen bir geliştirme ekibi

    Bu kadar büyük olmak ve bir initin içine pek çok şeyi dahil etmek, sistemi çok daha kararsız hale getirir ve yukarıda bahsettiğimiz gibi hatalar eklersek, linux'un bu kadar çok karakterize ettiği kararlılığı olmayan bir sistem yapar.

    modüler deniyor ancak parçaları aynı sistemin diğer parçaları olmadan çalışamaz.

    uzun vadede programlama sırasında bağımlılıklar oluşturan, gnome gibi yazılımları systemd'siz sistemlere neredeyse hiç taşınabilir hale getiren bir gelişme.

    Yıllardır çalışan ve bakım alan parçaların (networkd, logind vb.) yerini alır ve daha fazla hataya sahip olma eğiliminde olan herhangi bir ihtiyaç olmadan yenileri için değiştirir.

  6.   mat1986 dijo

    Açıkça systemd kullanan Arch tabanlı dağıtımları (Manjaro, Bridge Linux, Antergos) kullandığım andan beri, kullanımı ve kullanımı ile ilgili hiçbir şikayetim olmadığını söylemeliyim. Hizmetlerin başlatılması kolaydır - daha da fazlası, Bluetooth veya modem yöneticisinin varsayılan olarak devre dışı bırakıldığı Bridge'de. Hwdb.bin ile ilgili bir hata dışında (https://bbs.archlinux.org/viewtopic.php?id=189536) Çok sorun yaşamadım. Açıkçası bunun herkesin fikri olduğunu düşünmüyorum, ama şahsen hiç şikayetim yok 🙂

  7.   Solrak Gökkuşağı dijo

    NSA ile (arka kapılar ve ABD kontrolü) işbirliği yapmakla suçlanan bir şirketin (Red Hat) her şeyin kontrol edildiği bir sistem oluşturması fikrinden hoşlanmıyorum. Hepsini kontrol etmek, gerekirse karanlıkta bağlamak için bir yüzük ..

    Öte yandan, intel IRIS PRO 5200'ün benim için daha iyi çalıştığını ve openSUSE 13.1'i başlattığımda grafik sistemimin neredeyse hiç bozulmadığını itiraf etmeliyim. Ve evet, her şey daha iyi, çok daha hızlı başlıyor ve kapanıyor. Basit bir kullanıcı bana ne kadar fayda sağladı?

    1.    Juanfgs dijo

      sanık NSA ile işbirliği yapmak

      Önemli kısmı vurguluyorum

      Biri sizi uyuşturucu satmakla suçlarsa, otomatik olarak uyuşturucu satıcısı mısınız?

      1.    anonim dijo

        @yavbirah
        Uyuşturucu kaçakçısı hayır .... suç ortağı evet.

      2.    Juanfgs dijo

        Uyuşturucu kaçakçısı hayır .... suç ortağı evet.

        Tanrım ... Sana hakaret ederdim ama kendi sözlerin bunu senin için yapıyor.

  8.   Rafael Castro dijo

    Sadece systemd'nin yazıldığını ve bu şekilde yapılması gerektiğini açıklayın.

    Yazım

    Evet, systemd yazılır, system D veya System D, hatta SystemD değil. Ve bu da sistem d değil. Neden? Çünkü bu bir sistem arka plan programıdır ve Unix / Linux altında bunlar küçük harflidir ve küçük harf d ile son eklenmiştir. Ve systemd sistemi yönettiği için buna systemd denir. Bu kadar basit. Ama sonra tekrar, eğer her şey size çok basit geliyorsa, onu çağırın (ama asla heceleme!) Sistem Beş Yüz çünkü D, 500'ün Roma rakamıdır (bu aynı zamanda Sistem V ile olan ilişkiyi de açıklar, değil mi?). İsimde büyük harf kullanmanın uygun bulduğumuz tek durum (ama bundan da hoşlanmıyoruz) systemd ile bir cümleye başlamanızdır. Yüksek tatillerde sÿstëmd de yazabilirsiniz. Ama yine de, Système D kabul edilebilir bir yazım değil ve tamamen farklı bir şey (uygun olsa da).

    http://freedesktop.org/wiki/Software/systemd/

    1.    ela dijo

      Burada da mı? Bunu GUTL'ye koyarsınız .. ama dostum, herkes Linux diyor, GNU / Linux değil, bu yüzden SystemD ile aynı.

  9.   Germán dijo

    SystemD'nin sağladığı log sistemini veya cronu kullanmanıza gerek olmadığını söylüyorum, bu veya diğer alternatifler için syslog-ng ve cronie'yi takip edebilirsiniz.
    Aur'da olduğum için ArchLinux'ta systemD kullanıyorum ve bu debian ve redhat türevi yönteminden daha basit görünüyor, sizi metin dosyalarını düzenlemekten kurtaran ve komut dosyası kurulum yapılandırmasını basitleştiren birçok konsol komutuna sahip (unutmayın kemerde her şey konsol tarafından kurulur)
    Ve en azından sistem hızlı başlar, kemerde sistemi başlatırken hizmetleri paralel olarak başlatabilirsiniz, ancak risklidir

  10.   santiago dijo

    Sorunla ilgili kötü olduğunu düşündüğüm şey, çoğu tarafın taraf tutması veya siz pro-systemd veya anti-systemd olmanız ve bence onun iyi ve kötü yanları var, ben bir kullanıcıyım ve systemd ile biraz oynamaya başladım. gerçekten iyi şeyler, başlangıç, init'in geri kalanından daha hızlı ve daha az karmaşık, ancak derginin sayısı da beni çok rahatsız ediyor.
    Bunun iyi mi kötü mü olduğunu gerçekten söyleyebileceklerin, konuyla ilgili sistem yöneticileri veya uzmanlar olduğunu anlıyorum, ancak bana öyle geliyor ki, sistem telaşı bir süre önce teknik bir şey olmaktan çıktı ve daha "gösteriyi durduran" bir şey haline geldi. benim parçam biraz karşıyım ama kendimi anti ya da profesyonel olarak görmüyorum

  11.   yukiteru dijo

    @Kafadergisi

    Burada yorumlarınızın çoğunun Lennart'ın blogunda yayınladığı şeyle aynı olduğunu görüyorum, daha doğrusu bu yazıda: http://0pointer.de/blog/projects/the-biggest-myths.html.

    Elbette, gönderi bazı "açıklamalara" sahipti ve okuyacaklar için bilgileri sindirmeyi kolaylaştırmak için bazı teknik içeriği bir kenara bıraktı, ancak gerçek olsa bile ciddi ve samimi olacağız. acıtıyor: systemd, Lennart'ın reddettiği birçok şeye sahiptir, bu ve daha fazlası aslında. Ve bu anlamda kısmen açıklıyorum.

    1.- Lennart şişkin olmadığını ve yüksek bir NIH sendromu olmadığını söylüyor (Burada İcat Edilmedi Sendromu). Öyleyse lütfen birisi bana açıklayın: Bir init neden ağ denetimi (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), logs (journald), coredumps (systemd -coredump), debugs olmalıdır (systemd-coredump ve journald), acpi (logind), ayrıcalık yükseltme (logind), ntp kontrolü (systemd-timesyncd), dev üzerinde kontrol (systemd, udev'in tüm işlevselliğini aldı), / dev / random (rastgele sayı) kontrolü jeneratör) ve TTY (systemd-konsollu) üzerindeki en son kontrol? Systemd'nin artık özel erişimli (journald case) kendi bazılarını eklediği bu tür amaçlar için oluşturulmuş çok sayıda araç yok muydu? Çekirdek hata ayıklama ve cmdline'ı kırabilmek için bir init için bana hangi mantıklı ve kabul edilebilir açıklamayı veriyorsunuz? Buna, çekirdeğe entegre edilecek bir sonraki IPC olan kdbus üzerinde kontrol ekleyin. Elbette burada bana şunu söyleyecekler: «Ama tüm bunları kontrol etmek için başka bir araç kurabilirsiniz». Ve eğer doğruysa, ancak bu araçların çoğu, journald'ın sağladığı bir veri / akışa bağlanan syslog ve rsyslog durumunda olduğu gibi yalnızca systemd tarafından atılan bir veri akışı alır, böylece diğer araçlar hangi journald sürücüsünü görebilir , sonunda, bu sadece aynı şeyi yapan iki araca sahip olduğunuz anlamına gelir ve bunlardan biri bir pandoranın kutusu. (Lütfen bana kodun denetlenebileceğini söylemeyin, çünkü birini journald kodunu ve çerçevesini systemd ve diğer ilgili araçlarla "içmeye" davet ediyorum)

    2.- Lennart bize systemd'nin SysV ve LSB betikleri için destek sunduğunu da söylüyor. Bu bir "yarı gerçek" bir "beyaz yalan" dır, çünkü gerçek şu ki systemd-214 bash betikleri, SysV veya LSB için destek sunmuyor ve bu, o sürüm için Yayın notlarında ilgili.

    3.- Hangi sistem taşınabilir değildir? Bu başka bir tartışma konusu. BSD'de iyi çalışmaz, BSD'de systemd'nin çalıştırması gereken diğer araçlar arasında Cgroup yoktur. Ancak, taşınabilir olmadığı için değil, sistem tasarımı nedeniyle. BSD çekirdeği, onu destekleyecek minimum düzeyi karşılamayıncaya kadar, systemd o platformda çalışmayacaktır ve bu kimsenin hatası değildir, sadece BSD'nin ilgisi yoktur, ne de Lennart. Bu kadar basit. Şimdi, diğer C kitaplıkları için destek başka bir şey, iyi bilinen glibc sorunları (özellikle glibc 2.3, 2.5 ve 2.11 için bu ayrıntılardan kaçınmak için yapılmış seçeneklerin ve geçici çözümlerin miktarını görmek için elle bir çekirdek yapın, glibc'nin yıllar boyunca sürüklediği diğer kusurların yanı sıra) ama orada bitmiyor, Lennart kendisi kendi libc kitaplığını oluşturmayı tercih ettiğini çünkü çok daha hızlı olan grubu için bunu yapmaktan çok daha hızlı olduğunu söyledi. zaten oluşturulmuş (ve bu arada belgelenmiş) kodu okumak, ancak burada bitmiyor, glibc'yi kaldırmayı ve libc'lerini yalnızca systemd için değil, aynı zamanda Fedora için de kullanmayı planlıyorlar, bu da tüm paketlerinin yapımı için standart hale getiriyor. NIH Nerede? Görünüşe göre yaşlı Lennart trol yapmayı ve büyük olmayı seviyor.

    4.- Bu sistem monolitik değildir çünkü 69 ikiliye bölünmüştür. Evet pekala, bu tartışmalı. systemd, farklı görevleri yerine getiren 69 ikili dosyaya sahiptir, ancak bu ikili dosyalar görev bilgilerini systemd'ye aktarır, bu nedenle biri başarısız olursa, sistemi kırma şansı oldukça artar. Bu iyi belgelenmiştir, hata raporları bu gibi problemlerde ve hatta daha basit problemlerde, aptalca basit aslında. systemd yüzlerce ikili dosyaya bölünebilir, ancak çekirdeğiniz kontrol altında olduğu sürece kırılma riski devam eder ve artar ve bana inanmıyorsanız hata raporlarını okuyun ve eğlenin.

    Burada systemd'nin çöp olduğu hakkında yorum yapmadım, sadece "teknik" yorumlar yaptım (açıkçası teknik şeyler hakkında konuşmak çok karmaşık hale geliyor) ve geçerli, internette kolayca erişilebilen bilgilerle destekleniyor. Şimdi: Hangi Linux standart bir init'e ihtiyaç duyar? Evet, topluluk için kesinlikle çok değerli bir şey olacaktır. Çözüm hangi sistemdir? Hayır, yakın olmasına rağmen, kesinlikle birçok olumlu şeye sahiptir, ancak viral yayılması ve yaptığı şeylerin sayısı, neyin yanlış gidebileceği ve topluma zarar verebileceği riskini artırır.

    Not: Söylediklerimi doğrulayabileceğiniz materyaller bırakıyorum, okudum oldukça açıklayıcı olacak ve blogları veya bunun gibi herhangi bir şeyi, saf kişisel ve temelli eleştiriyi dahil etmediğimi görüyorum. Selamlar.

    http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
    http://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc
    http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
    https://bugzilla.redhat.com/show_bug.cgi?id=1057883 (@elav belki kendini tanımış hissediyorsun)
    https://code.google.com/p/d-bus/source/browse/kdbus.txt
    https://github.com/gregkh/kdbus
    http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html

    1.    ela dijo

      Amin kardeşim .. amin ..

    2.    pamp dijo

      Hala systemd'yi benimsememek için geçerli bir neden göremiyorum. Gördüğünüzü korkuyla yorumlayarak abartıya yol açarsınız. Ne açık ve iyi tanımlanmış avantajlar ne de dezavantajlar.
      Ek olarak, bu entegrasyon, bahsettiğiniz standardizasyona izin verir. Red Hat sadece systemd üzerinde değil, diğer dağıtımlardan farklı şirketler ve gönüllüler üzerinde çalışıyor.
      Sanırım hata, systemd'nin çalışmasının düzgün çalışılmamasıdır.

      1.    Xiep dijo

        Yukiteru'nun analizinde geçerli nedenler görüyorum. Korku yerine titizlik, kesinlik ve netlik gördüğüme dikkat edin. Bir göz doktoru sorunu olmalı.

      2.    yukiteru dijo

        Korku değil (bir kod parçasından korkmuyorum) ve abartılar da değil (burada söylediğim her şey belgeleniyor ve bunu doğrulayan pek çok bilgiyi ilettim, bu arada listelerden çıkan bilgiler ve Lennart'ın kendi el yazısından ve bir blog yazarının yorumlarından değil), GERÇEKTİR.

        systemd bunların hepsini ve çok daha fazlasını yapar ve bu ÇALIŞAN bir şeydir (korkmaktan farklı bir kavram) çünkü kesinlikle atıflar alır ve şu anda başka yollarla yapılabilen ve bu arada daha iyi çalışan ve daha istikrarlı olan şeyler yapar. . systemd çok Windows'a benzer ve bu gizlenemez, sadece userinit.exe, svchost.exe, smss.exe ve diğer bağımlılıkların ne yaptığını bilin ve bunları systemd ile karşılaştırın, benzerlik o kadar büyük ki kötü bir fikir. Şimdi, kesinlikle sistem, Windows muadilinden daha iyi bir kaliteye sahip olabilir (veya tam tersi olabilir, Microsoft için programlamadıkça kimse gerçekten bilmiyor), ancak Lennart'ın kendisini okuduğunuzda beni BÜYÜK ve KORKUNÇ olmakla suçlayamazsınız Listede, konuşma Glibc'den bıktığı için yepyeni bir C kütüphanesi yaratmaya ve napa'ya, libc'nin tüm Fedora paketlerini oluşturmak için kullanılabileceğine dair küçük ve önemsiz bir ipucu verin. Ve bunun bir yalan olduğunu ve abartıldığımı düşünüyorsanız, size bu bağlantıdaki mesajı bırakacağım: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (İngilizce)

        Şimdi tüm bunların önünde söylemek abartı mı, Linus CONFIG_VT'nin olduğu gibi olduğuna karar verdiğinde, çekirdekten (uzun süredir var olan durum) çıkıp kullanıcı alanına aktarması gerektiğini söyle bana, hemen hemen tüm Linux kurulumları için güçlü bir bağımlılık olan systemd gibi çılgınca bir şey olmayın (bir şeyin VT'lerle başa çıkması gerekir, sence de öyle değil mi?), bu, farklı sistem dışı dağıtımları ön plana çıkarmaz bir anahtarı zorlamak için. Bunun bir gerginlik olduğunu düşünüyorsanız, Lennart'ın neler yapabileceği ve ne yaptığı hakkında hiçbir fikriniz olmadığını söylememe izin verin, çünkü son değişiklikleri udev çatalı Gentoo eudev'in gelişimini etkiliyor ve tehditleriyle bunu yapmaya devam edecek. masanın altında (daha sonra Google + 'da yaptığı gibi şikayet etmek için)

      3.    yukiteru dijo

        @xiep Yorumunuza daha fazla katılamıyorum.

      4.    Juanfgs dijo

        Che Yukiteru, uzun ifadeniz libc'ye bağladığınız e-postanın bir Nisan şakası olduğu gerçeğini atlıyor, dipnota bakın ve tarihe bakın (31 Mart, muhtemelen Lennart'ın saat diliminde 1 Nisan)

        [1] GNU / Hurd'un başarılı olmasının ardından daha sonra bir çekirdek ekleyebiliriz
        yaklaşım.

        İngilizce-fu'nuzu pratik yapın çünkü sulu ve tüm "araştırmanızı" sorguluyor.

      5.    yukiteru dijo

        @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 🙂

      6.    Juanfgs dijo

        Masum bir sebepten yazdığımı sanmıyorum, Nisan'ın Şaka Günü (kötü ruh hali) nalist çılgınlığı için Lennart'tan başka bir şaka olduğunu biliyordum

        Bu düpedüz sansasyonellik, gerçeklere dayandığını söylüyorsun ama gerçekte adamın kötü olduğu ve dünyayı ele geçirmek istediğine dair önsezini takip ediyorsun ve konuşmanı yansıtmak için gerçekleri çarpıtıyorsun. Bu, sistem karşıtı insanlar hakkında beni çok rahatsız eden şeydir, konu gerçekleri çarpıtmak ve yarı doğruları söylemek söz konusu olduğunda, elbette kendi fikirleriyle yüklü olarak kelimeleri kestirmezler.

        Bu durumlarda benim "pratik kuralım", basitçe aşağıdaki mantıksal arızadır.
        - Ben bir web geliştiricisiyim / masaüstü uygulamaları veya cli
        - Hiç bir başlangıç ​​sistemi yazmadım.
        - Ben bir dağıtımın koruyucusu değilim.

        muhatapta olup olmadığını kontrol edin:
        - bir init sistemi oluşturdu
        - bir dağıtımın başlangıç ​​sisteminin aktif bir koruyucusudur

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

        Öyle olsa bile, zehirli ve kin dolu konuşması, başardığı tek şey, kopukluk, sorunlar ve başka şeyler yaratmaktır. Xorg, NetworkManager, PulseAudio'dan tehdit ettikleri için nihayet BSD'ye geçmelerini bekleyemeyeceğim nokta budur ve tamamen teknik bilgisizlikten mi yoksa bundan şikayet etmeyeceklerinden mi bilmiyorum.

      7.    yukiteru dijo

        @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.

        Şahsen, systemd'den hoşlanmıyorum, ancak bu init kullanmadığım anlamına gelmiyor, yapmalıyım çünkü tam da işimde bu init ile bir makineye dokunmak zorunda kalırsam, nasıl yapılacağına dair bilgim olmalı halledin. Ayrıca şahsen ben de onu Archlinux'a geldiğimden beri ve hatta Debian ve Gentoo'da kullandım, bu yüzden bana vizyonumun systemd kullanmayarak önyargılı olduğunu söylemeyin, onu kullandım ve aksadığını biliyorum ve eğer Burada, FromLinux forumunda veya IRC'de veya Debian listesinde (işimde en uzun süredir bulunduğum ve hala kullandığım dağıtımdır) birine yardım etmem gerekiyor. Bunu zevkle yapacağım, çünkü tam olarak Linux'tan hoşlanan bir şey varsa topluluk, farkına rağmen her zaman yardımcı olmasıdı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.

      8.    Juanfgs dijo

        ve gerçek şu ki, çoğu anti-sistemd

        !=

        Yani size göre tüm anti-sistemd

        Yine kelimeleri konuşmanıza uyacak şekilde büküyorsunuz. Bir politikacı / gazeteci için çok iyi bir materyalsin.

      9.    Juanfgs dijo

        Açıklığa kavuşturuyorum, benim sorunum Systemd'nin teknik problemlerinden bahsetmeleri değil, asıl mesele konuşmalarını çoğu kez yalanlarla dolduruyor olmaları, yani:

        Eğer systemd sizi bir microhttpd sunucusu kullanmaya zorlayacaksa (varsayılan olarak kurulu DEĞİL isteğe bağlı bir modüldür), systemd tek bir ikili ise, lennart'a microsoft tarafından ödeme yapıldığı için systemd kapatılacaktır, bu ikili günlükler Bunlar zorunludur. Kimsenin sistemli olmasını istemediğini ve bunun politik bir lobinin benimsenmesini istediğini.

        İşte şok eden bu, yalanlar. Makul bir tartışma olsaydı, buna değer olurdu, ama bu sadece iyi bir FUD.

        Beğenmediğinizi bana mükemmel göründüğünü, pek çok yazılımı, hatta programlama dillerini, dağıtımları ve diğerlerini sevmiyorum, ancak bununla ilgili bir şeyler icat etmiyorum ve okumak istediklerimi okumam da ifadelerimi geliştiren insanların imajına zarar vermek için kişisel duygularla doldurmak.

      10.    yukiteru dijo

        @juanfgs üzgünüm, ama belirli bir grup insana sadece bir yazılım parçasını sevmedikleri için "zehirli ve iğrenç" diyen ben değilim.

      11.    Juanfgs dijo

        Yine de onun konuşması zehirli ve iğrenç olan tek şey ayrılık, sorunlar ve diğerleri yaratmaktır.

        Yine kurban olmak için cümleleri bükmek.

      12.    yukiteru dijo

        @juanfgs tekrar söylüyorum, sizin tarafınızdan söylendi, sözlerinizi kontrol edin, sözlerinizi yanlış beyan etmiyorum, sadece 59 yorumunda sözlerinizi kopyalayıp yapıştırdım.

      13.    Juanfgs dijo

        Metinsel yorumumdan alıntı yapıyorum, tekrar okumak zorunda olduğun şey sensin çünkü anlamak istemiyorsun veya nasıl tartışılacağını bilmiyorsun. Bir şeyleri bağlamın dışına çıkarır ve size söylendiği gibi yorumlarsınız. Öyleyse, argümanlarınız tartışmalı olduğu için hakarete uğradığınızı hissettiğiniz bir dünyada yaşamayı seçmek istiyorsanız, Lennart, Red Hat ve Microsoft size zulmediyor, çünkü buna inanmayı seçiyorsunuz.

        Kısa burada çünkü mantıklı biri olmadığınızı anlıyorum çünkü anlamak istemiyorsunuz, her şeyi uygun gördüğünüz gibi yorumlamak istiyorsunuz.

        Eğer gücenmek istiyorsan alın, ama bu senin sorunun, dünyanın geri kalanı değil.

      14.    yukiteru dijo

        @juanfgs Yorumlarınızdan rahatsız değilim, gerçekten bir sebep göremiyorum, tartışıyoruz, medeni insanlar bunu rahatsız etmeden tartışıyor (bence bu).

        Şimdi, eğer insanları konuşmaları veya eylemleri için etiketlemek, önyargıda bulunmak (veya ne demek isterseniz) seviyorsanız (belki de benim yorumumu # 64 okuyup genişliğini ölçmelisiniz), bu sizin sorununuz, kendinizi bu eylemlerle sınırlandırın Kendinize doğru ve başkalarını o çantadan çıkarın.

        Selamlar.

      15.    Xiep dijo

        "Anti-systemd'nin çoğu", "hemen hemen tümü", "hepsi", "anti-systemd'nin bir kısmı" ... saparız, Mariano, saparız. Eldeki durumda: Yukiteru'nun önsezilere dayalı sansasyonel bir konuşma yaptığını hiçbir yerde görmüyorum (bu şekilde analizine atıfta bulunarak, tersine, dezavantajlar sistemi hakkında sağlam tartışmalar geliştirdi. posta listelerinden ve hata izlerinden uygun sorular ve materyaller (aynı zamanda kibar ve medeni bir şekilde). Muhtemelen bu nedenle bazılarını sinirlendiriyor ve ilk yorumda ona saldırıyorlar, onu itibarsızlaştırmak ve diskalifiye etmek için (bu sefer zehirli bir şekilde).

        Çoğu anti-sistemd söyleminin zehirli ve iğrenç olduğunu görürseniz, bazı sistem yanlılarının söylemlerinde gördüğüm (çoğunluk mu yoksa azınlık mı olduklarını bilmiyorum) histeri ve kimlerin zulmüdür, tam olarak, tüm gürültünün ortasında sağlam tartışmalar yapıyorlar. Benim ülkemde taciz edici muhalefet diyoruz.

        Systemd sizin için iyi gidiyor mu? Harika, bana harika görünüyor, ancak aynı şeyi düşünmeyenlerin çekincelerini ifade etmelerine izin verin (işletim sistemi aynı şekilde çalışmayabilir).

        selamlar

    3.    pamp dijo

      Oh bu arada, neden herhangi bir sistem hatası tüm bileşeni israf etme noktasına kadar patladı, ancak GCC, glibc ve hatta çekirdek gibi diğerleri, hatalarının çoğu için bu noktaya kadar eleştirilmedi?
      Sen kendin söyledin, glibc uzun zamandır sorunları sürüklüyordu. Llvm, zaman içinde GCC'ye göre avantajlara sahip olduğunu kanıtlamıştır. Ve burada aynı eleştiriyi görmüyorum.
      Neden diğer projelerle aynı şeyi yapmıyorsunuz?
      Benim için kolektif ve mantıksız bir korku.

      1.    yukiteru dijo

        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.

    4.    rolo dijo

      - lütfen birisi bana açıklasın: Neden bir init aşağıdakileri kontrol etmelidir:
      ağlar (systemd-networkd),
      dns (systemd-networkd),
      m-dns (systemd-networkd), l
      ogs (günlük),
      çekirdek dökümleri (systemd-coredump),
      hata ayıklama (systemd-coredump ve journald),
      acpi (logind), ayrıcalık yükseltme (logind),
      ntp(systemd-timesyncd),
      dev (systemd tüm işlevleri udev'den aldı),
      de / dev / random (rastgele sayı üreteci)
      TTY (systemd-konsollu)?

      Tekrarlanan ve tekrarlanan bir tema 100000, söylemeniz gereken şey, systemd'nin onlarsız çalışabileceğidir, aslında debian'da bahsettiklerinizin yarısı bile değildir.

      aynı şekilde geniş yaklaşımının sadece bir özelliğidir

      lennart: Well systemd, yapması gerekeni birçok farklı bileşene böler (bugünlerde 90'dan fazla ikili dosya). Her biri mümkün olan en az ayrıcalıkla çalışır.
      Bunun, tek bir pakette çok sayıda bileşene sahip olan temel unsurlardan çok fazla olmadığını düşünüyorum. Ve coreutils muhtemelen Linux'u UNIX benzeri bir işletim sistemi gibi hissettiren büyük projelerden biridir, değil mi?
      Ama evet, systemd, sysvinit'ten daha karmaşık, şüphesiz. Son 40 yılda bilgisayar kullanımı çok değişti ve birçoğu aslında başa çıkmak için belirli bir karmaşıklık seviyesi gerektiriyor… Bunun için çok az yol var.

      Çünkü, tamamen aynı şeyi yapan, ancak araçlarıyla ve başkalarının kullanılmasına izin vermeyen freebsd ile bu kadar taviz vermezsiniz, systemd'de durum böyle değildir.

      - Systemd'nin artık kendi eklediği, bazıları özel erişime sahip (journald case) bu tür amaçlar için oluşturulmuş çok sayıda araç yok muydu?

      Günlük temasının bilgiyi bir ikili dosyaya kaydetmesinin savunulacak en zayıf şey olduğunu inkar etmeyeceğim, ancak bu dünyanın sonu değil, düz metin olarak kaydedilebilir

      - Çekirdek hata ayıklama ve cmdline'ı kırabilmek için bir init için bana hangi mantıklı ve kabul edilebilir açıklamayı veriyorsunuz?

      Mmmmmmmmmmm …………………. çekirdeği kırmak ……. 5000000 şey çekirdeği kırabilir

      - Çekirdeğe entegre edilecek bir sonraki IPC olan kdbus üzerindeki bu kontrole ekleyin.

      Lennart'a göre Bu, geliştiriciler için olumlu bir ilişkiye sahiptir ve systemd, dbus'ı yöneticilere açmak için araçlar getirecek, ayrıca dergi ve ağ veriyolu arayüzleri verecektir.

      - Elbette burada bana şunu söyleyecekler: "Ama tüm bunları kontrol etmek için başka bir araç kurabilirsiniz." Ve eğer doğruysa, ancak bu araçların çoğu, syslog ve rsyslog durumunda olduğu gibi, yalnızca systemd tarafından atılan bir veri akışını alır,… .. bu, yalnızca aynı şeyi yapan iki araca sahip olduğunuz anlamına gelir ve bunlardan biri bir Pandora'nın kutusudur. (Lütfen bana kodun denetlenebileceğini söylemeyin, çünkü birini journald kodunu ve çerçevesini systemd ve diğer ilgili araçlarla "içmeye" davet ediyorum)

      burada komplo teorisine giriyoruz !!!!! bu sıska özgür yazılım hiçbir şey gizli değil

      3.- Hangi sistem taşınabilir değildir? Bu başka bir tartışma konusu. BSD'de iyi çalışmaz, BSD'de systemd'nin çalıştırması gereken diğer araçlar arasında Cgroup yoktur. Ancak taşınabilir olmadığı için değil, sistem tasarımı nedeniyle. BSD çekirdeği, onu desteklemek için gereken minimum düzeyi karşılamayıncaya kadar, systemd o platformda çalışmayacaktır ve bu kimsenin hatası değildir, sadece BSD'nin ilgisi yoktur, ne de Lennart.

      Bu tamamen doğru değil, bsd geliştiricileri, Lennart'ın kendi g + hesabında vurguladığı systemd'ye benzer bir şey yapıyor

      https://plus.google.com/115547683951727699051/posts/g78piqXsbKG

      https://www.youtube.com/watch?v=Mri66Uz6-8Y

      4.- Bu sistem monolitik değildir çünkü 69 ikiliye bölünmüştür. Evet pekala, bu tartışmalı. systemd, farklı görevleri yerine getiren 69 ikili dosyaya sahiptir, ancak bu ikili dosyalar görev bilgilerini systemd'ye aktarır, bu nedenle biri başarısız olursa, sistemi kırma şansı oldukça artar. Bu iyi belgelenmiştir, hata raporları bu gibi problemlerde ve hatta daha basit problemlerde, aptalca basit aslında. systemd yüzlerce ikili dosyaya bölünebilir, ancak çekirdeğiniz kontrol altında olduğu sürece kırılma riski devam eder ve artar ve bana inanmıyorsanız hata raporlarını okuyun ve eğlenin.

      Sysvinit kullanıyorsanız ve TTY dev acpi ntp'niz sistem arızalarınızı da bozarsa, terör ekmeyin.

      Monolithic freebsd ve hiçbir şey söylemiyorsun

      1.    anonim dijo

        @rol
        Şimdi systemd'yi alıp bu 90 ikiliyi ayrı paketlerde yaratan dağıtımları listeleyin, systemd ile 91 paket olacaktır.
        Ve systemd'yi kurarken benden bu 90 paketten herhangi birini bağımlılık olarak istemiyor.

        Cidden ve yine ısrar ediyorum… Lütfen make ile el ile 91 paket derlemek istediğim –configure-help seçeneklerini bana iletin.

        Görmek istemeyenlerden daha kötü bir kör yoktur ... çocuklar bu su ve yağdır, öyle görünüyor ki redhat'ın peşinde olduğu gerçeği görmeyen inatçı insanlar var.

      2.    yukiteru dijo

        @rolo Systemd'yi yüklemenizi ve journald, systemd-udev ve coredump'ı kaldırmanızı ve yapıp yapamayacağınızı görmek için doğrudan eudev ve syslog gibi seçenekleri kullanmanızı istiyorum.

        Bu yorum beni daha ciddiye alamazdı, ölüyorum. 😀

        Yeterince cidden, ışını göze yapıştırmak yerine gerçekten biraz okuma zahmetine girerler.

      3.    yukiteru dijo

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

    5.    Dariem dijo

      Başka bir deyişle, size göre, iki işlemin bilgi aktarması, onları o kadar bağlantılı hale getiriyor ki, birinin başarısız olması, diğerinin yüksek bir başarısızlık olasılığına sahip olmasını sağlıyor ... Bunu hangi yazılım geliştirme teorisinden anladınız? Mantıksız ve önyargılı korkuyla konuştuğunuz konusunda @pamp'a katılıyorum.

      Ve diğer büyük sorunuz, sistemin neden bu kadar çok şeyi kontrol etmesi gerekiyor? Basit cevap: çünkü sysvinit ve son zamanlarda Linux çekirdeğinde tanıtılan diğer tüm init avantajları boşa gidiyor, kimse onları kullanıcı alanında kullanmak için koymadığı sürece, "sinirleniyorlar" (Küba'da dediğimiz gibi ... iyi , israf) kimse olmadan kullanıyorum ve cgroups dahil olmak üzere donanım kaynaklarının (CPU, RAM, I / O, vb.) verimli kullanımında çok iyi avantajlar sağlıyorlar. Systemd'nin yaptığı tam olarak, bu iyi işlevleri Linux çekirdeğini kullanıcının hizmetine sunmaktır, ancak bunun için bu şeytanları başlatan kişinin kendisi olması gerekir.

      1.    yukiteru dijo

        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.

      2.    anonim dijo

        @Dariem
        Bu ikili dosyaların her birini ayrı paketler halinde derleyemezseniz, bir tane kurulmasını istediğiniz için hepsini kurmanız gerektiğini zorlarsınız, hepsini kurduğunuzda kurulamayan diğer paketlere adım atarsınız çünkü systemd'nin parçaları bu yerleri işgal ediyor.
        Sonunda her biri için ayrı ayrı yüklemenize izin veren bir paketiniz yoksa, büyük bir yürütülebilir dosyayı birkaç küçük yürütülebilir dosyaya bölmek ne anlam ifade eder?
        Systemd'nin her ileri düzey kullanıcısına genel istekte bulunmak, bana bu 90 modülü nasıl derleyeceğimi ve 90 paketi nasıl oluşturacağımı anlatmak için geri dönüyorum, eğer öyle hissedersem onları kurarım, yoksa kullanmakta olduğum programları kullanırım.
        Tüm bunlar çok kötü bir süt ... Görünüşe göre systemd tüm gnu / linux kullanıcılarının aptal olduğunu düşünüyor.
        Kayıt için, gentoo testini kullanıyorum ve birkaç ay önce systemd'ye geçtim ve journald ile yapamadım, bu da openrc'ye systemd'ye geçmek için gerekenden daha hızlı dönmemi sağladı.
        Systemd ile işlerin nasıl gittiğini görmeye devam etmek için, yakında gentoo'da yayınlanacak olan bir dizüstü bilgisayarda archlinux var ... kesinlikle kararlı.

      3.    yukiteru dijo

        @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.

      4.    anonim dijo

        @Yukiteru 3 Aralık 2014 8:49
        Bundan korkmuyorum, Bay Linus varsayılan seçenekleri bir sürümden diğerine kaldırmayacak, yeni sistemi YENİ olarak koyacak ve eski ile yeni arasında seçim yapmanıza izin verecek.
        Kullanıcı alanı kısmıyla ilgili olarak, bunu bağımsız olarak yapan bir paket yapabilirsiniz, eğer sistem bunu yaparsa, neden 50 tane daha yapamaz? Dahası, bunu yapmanın farklı yolları, farklı terminallerin tüm KULLANIMLAR ile farklı yollar benimsemesini sağlayacaktır. alıştığımız gibi etkinleştirmek ve devre dışı bırakmak için.
        Aynı şey kdbus için de geçerli, Linus söylediği gibi 3.19'da bunu kabul ediyor, bu kişinin aktif olması gerektiği anlamına gelmiyor evet veya evet.
        Openbox + compton'dan çok memnunum, benim için masaüstleri beni en azından etkilemeyecekleri için kaybolabilir.

      5.    yukiteru dijo

        @ 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.

      6.    anonim dijo

        @Yukiteru 3 Aralık 2014 9:46
        Burada gentoo'da libudev, sys-fs / eudev'i gösteren sanal bir tanesidir, bu nedenle gentoo çalışanları, eudev'i yeni çekirdek sistemi tarafından dikte edilen API'ye uyacak şekilde değiştirmeye özen gösterecektir.
        Bu yüzden systemd (merhaba devuan) dışındaki dağıtımların if veya if eudev kullanacağını düşünüyorum.
        Orijinal udev ile olan şey olacak, systemd bunu yuttu, ancak burada çekirdek, API tarafından DRM / KMS kullanarak konsollarla arayüz oluşturması için dikte edilen şey… Bunu kullanarak bir urxvt görmek istedim zaten… hehe
        Kabul ettiğim şey, sistemi kullananın hiçbir şeyi değiştirme seçeneğine sahip olmayacağıdır ... tam ve sert dayatma ve daha önce söylediğim gibi ... mezarlığa ağlama.

      7.    yukiteru dijo

        @ 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 😀

      8.    Dariem dijo

        Sizi eleştirdiğim kavramı tam olarak tekrarladınız, çünkü hiçbir zaman sistemden bahsetmedim, süreçler arasındaki iletişimden bahsettim ve tekrar ediyorum, bunu nereden alıyorsunuz çünkü iki süreç iletişim kuruyor, birinin ölümü şunu ima ediyor: diğerinin ölmek için geniş olasılıkları var mı? Ayrı bellek alanlarında bulunan iki işlemin birbirlerinin iç davranışını karşılıklı olarak nasıl etkileyebileceğini bana açıklayın. Bakalım, bu süreçlerden birinin bakış açısından kendimi açıklayacak mıyım, sadece bir IPC mekanizmasına erişiyor (sistem süreçleriyle iletişim kurmak için tanımlanan her ne ise). Programcı, beklenmedik girdi ve çıktılarla başa çıkabilecek bir kodu dahil etmeme konusunda o kadar kötüyse, bu başka bir şeydir, ancak bir diğerinin içini etkileyen bir işlemle ilgisi yoktur. Systemd-networkd çökerse, inetd çökmelerinin onu etkilememesi gerektiği gerçeği olan eski sysvinit ile olduğu gibi, journald veya systemd'yi öldürmek zorunda değildir, bunlar ayrı süreçlerdir.

      9.    yukiteru dijo

        @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.

      10.    Dariem dijo

        Xorg için verdiğiniz örnek en az uygun olanıdır çünkü KMS / DRM'ye geçiş yapmış olan herkes, sorunun Xorg sürücülerinin geliştiricileri tarafından sağlanan KMS'yi kontrol etmek için çekirdek modüllerindeki hatalardan kaynaklandığını bilir. KMS modülündeki bir hata, çekirdek paniği ile aynıdır, süreçler arasındaki iletişimle hiçbir ilgisi yoktur, çünkü bu durumda Xorg bir sistem çağrısı (sistem çağrısı) yaparak çekirdeğin ekran modunu değiştirmesidir, yani orada çekirdeği çağıran yalnızca bir işlem (Xorg), burada uğraştığımız şeyle hiçbir ilgisi yok.

        Systemd'nin bağlama noktasını bulamadığındaki mevcut davranışı, birisinin beğenmeyebileceği, diğer davranışı desteklemesini isteyerek çözülen, başarısız montajı görmezden gelen bir işlev olmasına bakılmaksızın ilgisizdir. Daha önce meydana gelen coredump, yalnızca speküle edilebilecek farklı nedenlerden kaynaklanıyor olabilir, ancak yürütmenin devam etmemesi, istenen bir davranıştan kaynaklanıyor olabilir, çünkü yeniden başlatılması gerektiğini söylüyorsunuz, bir çekirdek yok panik veya otomatik yeniden başlatma. Bunu yapmadığım için bir fikir veremem.

        Systemd-coredumpd ile koyduğunuz problem ve hata raporuna bağlantı ile ilgili olarak, her şey Arch Linux'taki bu problemin o dağıtım için derlediklerinde systemd'yi etkinleştirdikleri sıkıştırmadan kaynaklandığını gösteriyor. Sistemd'nin kendisinden çok sıkıştırma algoritmasında bir soruna benziyor. İşletim sistemi çökmüyor, bunun yerine karotları depolamak için kullanılan sıkıştırma algoritması sistemi boşaltıyor gibi görünüyor ve bu, systemd'yi derleyen Arch Linux geliştiricilerinin hatasıdır. Ancak, systemd, kaynak tüketimini sınırlamak ve çekirdek tarafından bildirilen tüm coredump'ların yakalanmasını etkinleştirmek / devre dışı bırakmak için ayarlara sahiptir. Belki systemd'nin Arch bakımcıları ve KDE kullananlar onlara bir göz atmalı.

        OpenRC'nin istilacı olmadan da cgroup kullandığını söylüyorsunuz. Sorun şudur: OpenRC, hangi kaynak tahsisinin en uygun olduğunu tam olarak bilmek için arka plan programı çalıştırılabilirlerinin adını nasıl tanır? Systemd'nin bu kadar çok şeyle ilgilenmesinin nedenlerinden biri olduğundan emin değilim, yürütülebilir dosyalara iyi bilinen bir ad veriliyor, ancak işin bu şekilde gittiğinden şüpheleniyorum. Ayrıca, yürütülebilir dosyaları doğrudan çağırarak bu hizmetlerin her birini çalıştırmak için ortada tire olması yükünü ortadan kaldırır.

        Systemd'nin birçok hataya sahip olabileceğini inkar etmeyeceğim, ancak oradan hepsini tasarlandığı şekle atfetmek için öyle düşünmüyorum. Sysvinit söz konusu olduğunda, süper kararlıydı, olgun bir yazılım parçasıydı, systemd daha yeni başlıyor.

  12.   Raphael Mardechai dijo

    SystemD, xD ile topları nasıl patlatıyorlar? Bundan çok nefret ediyorsanız, kendi dağıtımınızı oluşturun, bu da özgür yazılım için é_é

    1.    Büyük İskender dijo

      Nefretle ilgili değil, topluluğunuzu savunmakla ilgili.
      Bu arada dağıtımlar varsa Bağımsız "yeraltı":
      http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
      Saygılar

  13.   Wacos dijo

    çünkü microsoft ile her şeyi windows gibi davrandığını karşılaştırın .. eğer işler iyi çalışıyorsa ve linux'un gelişimi ve evrimi içinse sorun nedir ... yazılım programları vb. mükemmel olsaydı başlangıçtaki her projede değişiklik hataları olabilir, Biz insanız, ama bu yüzden hatalarımız var.

    eğer systemd başarısız olursa, sistem çöker ... ve eğer çekirdek, xorg, grub başarısız olursa ... çekirdeği bilgisayarlarında veya dizüstü bilgisayarlarında güncelleyerek sistemi kaybeden insanlar vardır ... bir şeyin mükemmelliği ...

    Sanki ortaya çıkan herhangi bir sistem, başlangıçta hatalar veya başka bir şeyle karşılaşmamış veya olgunluğunda bile başarısızlıklara sahipmiş gibi

  14.   lf dijo

    Systemd, kirli oyun ile bir standart olarak empoze edildi, birçok paket için zorunlu bir bağımlılıktır çünkü birçok program, ya onları sürdürdükleri için ya da yavaş yavaş ortadan kaldırdıkları için systemd tarafından absorbe edildi çünkü systemd zaten benzer bir şey sağladı.
    Bu, seçim özgürlüğünü sınırlar, yani dağıtımlar systemd'yi KULLANMAMAYI seçemezler, gentoo gibi direnmeye çalışabilirler, ancak bu daha çok systemd için geçici bir çözümdür, openrc, init ve initscripts için sadece sysv destekli bir hizmet yöneticisidir. systemd, openrc'den daha fazla işlevsellik sağlar ve her gün yeni işlevlere sahiptir. Yeni yazılım systemd'yi destekliyor ve benzer bir şeyin uygulanmasını gerektiriyor, bu da diğer init'leri daha karmaşık hale getiriyor ve systemd'ye daha benziyor, ki bu istediğin şey değil.
    Systemd, / etc / inittab dosyasından birkaç satırı okuyan ve ardından her bir initscript'i ve çalışma düzeyine göre ayarlarını yükleyen eski init ile karşılaştırıldığında birçok şey yapar. Eski yaklaşım çok daha basit ve daha bağımsızdı. Yeni bir homojenlik çağına geçiş aşamasındayız, çözüm yok, hüküm sürdüğü yol durdurulamaz.
    Birkaç yıl içinde debian kullanmak, arch veya fedora kullanmak arasında pratikte hiçbir fark olmayacak, bu şekilde devam edersek her dağıtımın kimliği kaybolacak ve systemd her gün daha müdahaleci hale gelecek ve hatta sistem adının bir parçası haline gelecektir. (systemd / gnu / linux)

    1.    msx dijo

      LOL

      Kiliseye ağlamak için>: D

  15.   msx dijo

    Don KZKG ne diyor, size şunu bırakıyorum: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648

    1.    lf dijo

      Sorun şu ki, siz Arjantinlisiniz (ben de öyleyim) ancak, özgür yazılım dünyasının belirli insanları cezbettiği söylense de, okuduğum Arjantinli Linux kullanıcılarının çoğunun kendilerini ifade etme şekli gerçekten endişe verici. Kurtardığım şey, Arjantinli olduğunuzu varsaymamanız, ancak maalesef ligleri gösteriyor.

    2.    x11tete11x dijo

      uyyuyy .. o çocuk ağır toplarla düştü ..

    3.    WACOS dijo

      güçlü yorum !!

    4.    hamBasic dijo

      Juju .. ..pochoclos .. xD

  16.   Tito dijo

    Bu makaleden, yaptıkları tek şeyin bir sistemi "dayatmak" olduğu anlaşılıyor. Daha iyi mi (hangisi değil) yoksa daha kötü mü olduğunu değerlendirmek için girmiyorum. Söylediğim, tekrarladığım, vurguladığım ve vurguladığım şey, bana herhangi bir şey empoze edilmesini gerçekten istemediğimdir.
    Şöyle ifadeler: "Onları önyükleme işlemi için kullanmıyoruz, çünkü bu belirli amaç için en iyi araç olmadıklarını düşünüyoruz."
    Ve bunu ya da o aracı kullanmak istersem bana kimsin?
    Her biri orada. Ben sadece kullanmıyorum, nokta ve kullanmasam da kullanmayacağım.
    İmza. Bir Taliban.
    (Palyaço beni eğlendirdiğim için)

  17.   Kuktos dijo

    genellikle bu konuyla ilgili bir baş ağrısı !!!! X_X

  18.   Tebris dijo

    Centos 6 ile sunucuları yönetiyordum ve systemd ile 7'ye gitmek bana hiçbir şeye mal olmadı, ağlama, hayat devam ediyor.

  19.   şakalar dijo

    Affedersiniz, ama bana klasik "windows server - Certified Man VS linux server - OpenSource Man" söylemini hatırlatan birçok şey okuyorum.

    1 - Bir hatayı zorlarsanız, başarısız olması normaldir. Gördüğüm videoların her biri zorunlu hatalar. Sanki anahtar kelimeleri syslog günlüğüne besleyen bir program yapıyorum ve aynı zamanda günlükten bilgi almak için grep tabanlı bir komut dosyası çalıştırmaya çalışıyorum. ... tabi ki başarısız olacak, buna ben sebep oldum.

    Dizel motora şeker döküp "Bak ... benzin daha iyi !!!" demek gibi bir şey. veya Windows'un yaptığı gibi, bir yapılandırma dosyasını yanlış yazın ve arka plan programının "Windows ile bu olmaz" demeye başlamadığından şikayet edin.

    2. - Bu sistem, kullanamayacağınız birçok şeyi bünyesinde barındırıyor mu? Peki sorun nedir? Bu, Windows'un Linux'a karşı kullandığı boş argümanın aynısıdır ... "Neden kullanmayacağınız zaman bin bir seçenek koymasını düz bir metin istiyorum?

    Yıllar önce bazı şeyleri okuduğumda, yekpare programları olan IBM çalışanlarının mysql hakkında havladığını duyuyorum. GNU / Linux ve topluluğunun çeşitliliğine teşekkür ediyor ve takdir ediyorum. Bana bir şeyi yapmam için 50 yol verirseniz, her an benim için en iyi olanı veya ihtiyacım olana uyanı seçeceğim. Bunda gerçekten bir sorun görüyor musun?

    3 - Konuşmaların seviyesine göre, herhangi bir dağıtımla çalışmak veya kendi dağıtımınızı kurmak ve bunu kendiniz sürdürmek için yeterli bir seviyeye sahip olduğunuzu anlıyorum. Neden systemd koymak ve ondan bir şeyler çıkarmak istiyorsunuz? İnit veya openRC'nize devam etmek daha kolay değil mi?

    Onlara linux'un temellerini öğretmemi isteyen insanlara hep aynı şeyi söylüyorum ... GNU / LINUX, WINDOWS değildir, aynı şeyleri yapmaya çalışmayın veya öyleymiş gibi düşünmeyin. Sistemd'in initd ile aynı olduğunu ya da aynı şekilde çalıştığını neden asimile ediyorsunuz? Systemd'nin işleyişini özümsemek ve potansiyelini kullanmak, init veya OpenRC gibi işlevler yapmaya çalışmaktan daha kolay değil mi? Beğenmemeniz normaldir.

    4 - Karmaşıklığın nesi var? Doğrusal programlamayı ne zaman verdiğinizi ve kesinlikle bir noktada şunu söylediğinizi hala hatırlıyorsunuz ... «Ve eğer şimdi her şeyi yapabilirsem ve yoksa kullanmama izin verirlerse neden nesneler üzerinde çalışmayı öğrenmek istiyorum?" ... (xD ise birkaç ay sonraki facepalm harikadır)

    Açık olalım. Mevcut init (ve ben systemd'yi dahil ediyorum), yalnızca karmaşıklık ekleyerek doldurulabilecek birçok eksikliğe sahiptir. Başka hiçbir şey yoktur, çünkü birbirine bağlı bir sistemin büyümesi için, zayıf bir parçaya sahip olma riskiyle karmaşıklık içinde büyümesi gerekir, ancak durgun kalmaktan daha iyidir.

    Gitmek uzun bir yol alıyor ve eğer… sistemd her şeyin çözümü değil. Ama hiçbiri SysVinit ile kalmıyor.

    1.    şakalar dijo

      Not: İş arkadaşımın bilgisayarını "Windows sunucu savunucusuna yapışıyorum" şeklinde kullanmamın ironisine dikkat edin, böylece onu okuyabilir. xD

      Teknik veriler ve bağlantılar veren diğer INIT'lerin savunucularına sadece bir şey… CHAPO !!! Bunun gibi argümanları ve verileri görmeyi seviyorum. Sadece bir not, Ekim 2014'ten önceki veriler yalnızca geçmişe aittir.

      Tartışılan birçok şey halihazırda düzeltildi ve 2013'te yayınlanan birçok test ortamı gözden geçirildi.

  20.   SynFlag dijo

    @rol

    Doğruysa, yapmadığınız videoyu gördüyseniz, günlüğün 8 MB olduğunu, daha fazla bir şey olmadığını ve her şeyin bozulduğunu görebilirsiniz, bu arada, journald çıktısını syslog'a gönderebilir misiniz? düz metin? Evet, ancak yine de journald tarafından oluşturulan günlüklere dokunursanız, bu olur, sistem kilitlenir ve anlaşılabilir bir durumdur, bakalım, günlük systemd kadar karmaşık şeylerle birlikte PID1'de asılı kalır, başarısız olur, görmezsiniz journald'ın aynı PID'sinden başka bir şey için düzenlemeye izin vermeyen bir kod parçasına sahip olması ve ayrıca logun ötesinde yazmaya devam etme yeteneğinin olmaması, Windows modunda düşünmeye ek olarak LP'nin kötü bir programcı.

    Bana bunun yalnızca systemd, RHEL7 klonunu kullanan dağıtımın en kararlı sürümü olan centos'ta olacağını söylemeyin ve hatayı rapor etmiyorum veya rapor etmeyi planlamıyorum.

    Gerçek şu ki, sistemle ilgili yorumları ne kadar çok okursam, onların gerçekten bir dine benzediğini ya da sizden yana olduğunuzu ya da düşman olduğunuzu anlıyorum, ancak bu IŞİD tipi dinlerin, İslam devletinin dinleri tamamen aşırılık yanlısı, aslında, deneyimlerden biliyorum, sistem severler, öyle düşünüyorlar ya da onlarla birliktesin ya da düşmansın. Lennart'ın küstahlığıyla teşvik ettiği şey buydu ve lütfen Linus'un onu desteklediği için beni becerme, sistem bu değildi, BU DEĞİLDİR, Fedora 15'te çıkar çıkmaz systemd kullandım ve bu sadece daha hızlı bir başlangıçtı. GNU / Linux modülerliğinin yerini almadı.

    Rsyslog'u öldürürsem, günlüklerini bozarsam veya bir çizimle değiştirirsem, başka bir şey değil, yalnızca günlüğüm biterse, hiçbir şey takılmaz, sistem etkilenmez.

    @Rafael Mardojai

    Devuan'ın yaptığı bu, Void Linux'un yaptığı ve systemd'den uzak duran diğerleri.

    @Yukiteru

    Elbette kimse seni okumaz, bana Taliban dedikleri gibi, pencereleri kullandığın veya ondan yorum yaptığın için seni okumuyorlar ve çünkü sistem severlerin çok azının söylediklerinin teknik kısmını anladığını ve sorunun da burada yattığını düşünüyorum.

    ======

    Gerçek şu ki, 2006'da bilinen bir kişinin bir konuda haklı olduğunu düşünüyorum:

    "İnsanların Linux kullanmasını veya bilmesini istemiyorum, bu Ubuntu adamlarının toplarım dolu"

    Ben neden?"

    "Bir şey bilindiğinde ve kitlelerce sıçradığında, mahvolur ve bunun birçok örneği vardır."

    Ben- "hangileri gibi?"

    "Debian'a ne olduğuna bakın, şimdi Ubuntu adında aptal bir oğlu var ve birkaç yıl içinde Ubuntu'yu emen" hackerlar "ve" geeksler "olacağını ve Ext3'ü NTFS'den nasıl ayırt edeceklerini bilmeyeceklerini unutmayın"

    Bir şeyler doğruydu…. Allan McRae'nin dediği gibi, bilenler arasında zaferler kazanır, çünkü makinesini nasıl çalıştırdığını umursamaz, onun için bu, düğme, sihir ve benim bir isteğim var. Güzel özelliklerle "çalışmaktan" daha fazla ilgilenmeyenler arasında, toplam, sunucu kullanımı için LFS veya Gentoo veya BSD gerçekten ve sonra onu sevenler arasında renkli ışıklar, güzel sesler ve şans oyunlarıyla bilgisayarlarını daha hızlı açtığı için , ancak sistem çağrısının ne olduğunu bilmiyorlar.

    1.    yukiteru dijo

      @SynFlag okumazlarsa, kullandığım işletim sistemi ile ilgili kendi kararlarıdır, işteysem ve bir Windows PC'den yorum yaparsam, elimde olan tek şey olduğu için, Debian Wheezy'de ve açıkçası sunucudan burada yorum yapamam.

      Evde bile kız kardeşimin bilgisayarını kullanmak zorunda kaldım çünkü bilgisayarım öldü (MB ve güç kaynağı bana karşı komplo kurdu) ve yine de zamanım olduğunda bir LiveCD bağlayıp Sabayon'u (OpenRC ile) yorum yapmak için kullanıyorum burada, aynen bu kelimeleri yazarken yaptığım gibi.

      Şimdi, eğer bana sistem karşıtı bir Taliban olduğumu söylerlerse veya düşünürlerse, bu benim için önemli değil. Dediğim gibi, systemd kullandım ve bacağın topalladığını biliyorum, sadece bu değil, genellikle yeni sürümlerde gelen şeyler hakkında bilgi edinmek ve ayrıca yapılan değişikliklerin farkında olmak için sistem listesini çok okurum. ve orada gerçekleşen tartışmalardan. Şimdi, herhangi bir sistem aşığı, bahsettiğim şeyin teknik yönünü anlarsa ve ben bağlantılarımı koyarsam (çoğunlukla sistemdeki git repo bağlantıları) ve o zaman bile gerçeği göremezse, bu sadece sattığımı düşünmeme izin verir. onların gözlerinde ve görme / düşünme / hissetme / sevme / yüceltme / övme / ibadet etme biçimlerindeki aşırılık o kadar büyüktür ki, Linus'un kendisi bile sistemi dışına atsa bile fark etmez, hala doğru olduklarına dair fikirlerinde yerleşiktir.

  21.   Ezequiel dijo

    Merhaba! Çok uzman değilim ve bu "sistem" in ne için olduğunu ve neden bu kadar çok konuşulduğunu, sorun nedir ve hangi alternatifi olduğunu bilmek istiyorum. Teşekkürler

  22.   Tito dijo

    SynFlag yorumu! Ben "inek", "inek" ve "Linux yanlısı" danım.
    Ve bizi bekleyen gelecek budur; Ubuntu çorbada bile; Yalnızca Steam'e erişmek ve en yeni popüler oyunu oynamak için Linux dizüstü bilgisayarlar. Ve kapsülün ne hakkında olduğunu bilmeyen küçük inek lejyonları.
    Postscript: systemd'nin arka plan kavramı berbat.

  23.   Hannibal Smith dijo

    adk ve forum düğmeleri ana sayfada görünmüyor

  24.   Dariem dijo

    Dolayısıyla @SynFlag'a göre artık anti-sistemd olmayan herkes bir n00b, aşırılık yanlısı dinci fanatik ve GNU / Linux'u bozan veba. Bu kadar dar bir görüşle, bu konunun tartışmaya değer olup olmadığını bilmiyorum. Suyun akmasına izin vermek daha iyidir ve uzun vadede olması gerekenler olacaktır.

    1.    rolo dijo

      Doğru, artık tartışılamayacak bir nokta geliyor. Sistemin özgür yazılım dünyası için olumlu bir şey olup olmayacağını sadece zaman bize söyleyecektir.

      Ayrıca bana systemd'yi kullanmayacak olan bu debian tabanlı dağıtımın meyve vermesi durumunda systemd hakkında hiçbir şey bilmek istemeyenlerin ruhlarını yatıştırmaya yardımcı olacağı fikrini veriyor.

      Gnome 3 ortaya çıktığında ve muazzam bir direnç inşa edildiğinde, tarçın ve birlik ortaya çıkana kadar, gnome uygulamalarını daha fazla konfigürasyon ve bilgisayar için daha çok düşünülmüş bir tasarımla bir masaüstünde kullanmaya devam etmeye izin verene kadar dokunma için çok fazla değil

      1.    Xiep dijo

        Belki bu, Rolo (Devuan'ın ortaya çıkışı), bir fikir birliği noktası olabilir. Bence hepimizin kutuplaşmış ve kavgacı bir tartışma ortamı içermesine ihtiyacımız var. Devuan, bir yapma biçiminin yaratılması ve sürekliliği için bir alan olacak ve bu ruhları sakinleştirmeye yardımcı olacaktır. Debian'da yaşadığımız süreç sancılı oldu, ancak durumla yüzleşmeliyiz, ayrılığı kabul etmekten başka çare yok. Bu biraz boşanmaya benziyor. Bu çatal, bir barış anlaşmasının bir kopyası ve bir nokta ve kısım olabilir. Elbette alternatifler vardı, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, şimdi Manjaro (birkaçını saymak gerekirse) ... ama "deb" sahnesi sistemd'siz bir alternatif gerektiriyordu. Açıkça görülüyor ki, kimse kimseyi ikna etmeyecek, argümanlar masada ve fikir birliği yok (systemd'nin iyi fikirleri olmasına ve bu yazılımın taşıdığı tehlikelerin açık olmasına rağmen). Artık çatalların ve kullanıcı için özgürlüğün elde edilmesinin zamanıdır (çünkü bu Özgür Yazılım ile ilgili, değil mi?).

        Süreci etkileyen faktörlerden biri, Debian'a güvenen bazılarımızın "hayal kırıklığı" hissiydi. Devuan'ın bir türev değil çatal olarak sunulmasının nedeni budur. Gerginlik var çünkü kimse olanları sevmiyor; ne sistem yanlısı (dolayısıyla karalamayı deneyen bazı öfkeli saldırılar) ne de anti-systemd (çatala bahse giren). Ortamda hem bir yandan hem de diğer yandan "ne kadar yetenek kaybedebiliriz?"

        Tüm Debian kullanıcıları dağıtıma "belirli" bir şekilde bakarlar (bu, diğer dağıtımlara da uygulanabilir). Teknik kalitesine, sosyal sözleşmesine, Linux dünyasındaki etkisine, yıllar içinde kazandığı saygıya, kritik üretim ortamlarındaki istikrarına hayran olanlar var ... Bazı kullanıcılarda bu algı değişmiş, hayal kırıklığı ortaya çıkmıştır. . Hayal kırıklığı, hayal kırıklığı, ona ne istiyorsan söyle. Oradan ayrılığa kadar sadece küçük bir adım var.

        Debian boşanması, NetBSD ve OpenBSD ile olana benzer. Zaman gösterecek olmasına rağmen. Çatalda çok fazla beklenti görüyorum ve bu da kısacık ve kısır bir dağıtım olmayacağını düşündürüyor. Tam bugün, gnome ekibinin bir üyesi Devuan'ın posta listesi hakkında yorum yaptı (çok beceriksiz olsa da), bu bana göre Devuan'ın ilgi uyandırdığını ve bir şekilde diyalog kurmak istediğini gösteriyor.

        Neyse, iyi haftasonları.

      2.    SynFlag dijo

        @rol

        Videonun kandırılabileceğini veya yazılımın tam bir yanlışlık ve hakaret olduğunu söylemek için, PU ** hayatımda bir efsane yaratmak için bir şeyi kandırdım, asla, bu başarısızlığı hilelerimle değil kendi imkanımla görmüş olmakla övünüyorum. Hepsi *****'dan çok **** 'a gidiyorlar ve sistemli tartışmalara daha fazlasını koymayacağım çünkü tamamen osuruk için, kimse bir şey anlamak istemiyor ve hepsi bir düşme gibi, ki, Nefret ediyorum, çünkü her şey inanç dogması gereğidir. Systemd ile mutlu olun.

      3.    rolo dijo

        @SynFlag şiddeti yalan söylüyor

        Bu videonun gösterdiği şey, systemd modüllerinden biri bozulursa, systemd'nin çökmesine neden olur, çünkü açıkça, videonuzun olmadığını gösterdiği şeyden xddddd ve derginin kök olarak çalıştığı şekilde, bu nedenle, eğer bir üçüncü şahıs günlük günlük ikili dosyasına girip kötü niyetle bozarsa, systemd konusunda endişelenmem, bunun yerine bilgisayarınızın güvenliği konusunda endişelenmem. xdddddd. Son olarak video konusunda, nano ile düzenlerken gösterileni /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal dosyasını kopyalayın ve yeniden başlattığınızda yeni bir system.journal ve @@ 24f02f5b2b16758 @ @ 820f6f751bXNUMXbXNUMX. Bozuk ikili olan günlük.

        Başka bir deyişle, günlük dosyanın bozuk olduğunu fark eder, bu nedenle yeniden adlandırmaz ve yeniden yeni bir tane oluşturur, bunda sorunun ne olduğunu anlamıyorum.

        Bir onaltılık düzenleyiciyle düz bir metin günlük dosyasını mahvedersem ne olacağını merak ediyorum, tabii ki biri dosyanın bozulduğunu fark edene kadar tüm veriler yok olacaktı Oo

        Systemd'nin en yaygın eleştirilerinden biri olan Journal'dan biraz bahsedelim.
        Journal, Syslog mesajlarını, çekirdek günlük mesajlarını, RAM ve ilk önyükleme mesajlarının yanı sıra STDOUT / TDERR'de yazılan mesajları yakalayan ve tüm bu bilgileri kullanıcıya sunan çok önemli bir systemd bileşenidir.

        Ancak en önemlisi, günlük paralel olarak veya rsyslog veya syslog-ng gibi geleneksel bir syslog arka plan programının yerine kullanılabilir, bu nedenle dikkatli bir sysadmin, günlük kayıtlarını dönüştürmenin yanı sıra ikinci bir sorgu aracı olarak rsyslog veya syslog-ng'ye sahip olabilir. ikili dosyanın bozulması durumunda düz metne

        Journal ile ilgili bir diğer önemli gerçek de, / var / log / journal klasörü oluşturulmazsa, bilgilerin yalnızca geçici olarak kaydedilmesidir ve her yeniden başlatmada kaybolur.
        örneğin, debian'a systemd'yi girdiğimde günlüğün kalıcılığı aktif değildi, bu yüzden günlük klasörünü manuel olarak oluşturmak zorunda kaldım

        http://0pointer.net/blog/projects/journalctl.html

  25.   anonim dijo

    İngilizce bilenler, devuan geliştiricileri, jaromil dimkr max2344 ve diğerleri arasında freenode IRC kanalı # devuan'da yapılan görüşmeleri kaçıramaz.
    Bulaşmak (gereksiz bağımlılıklar yaratmak) amacıyla kasıtlı olarak yaydıkları için sistem kodu araştırmalarını okumak çok eğlenceli.

  26.   sircacaroto dijo

    Systemd beni rahatsız ediyor… tam önden… zor. Çok az belge ne de lanet ince sadece KDM veya gdm çalıştırmaz ve ben ince lxdm istediğim hafif bir sistemde onu desteklemez veya derlemez… .. Cidden, daha önce bile… Onlarla mutluydum. Aslında gentoo'da söyledikleri gibi openrc kullanmaya başladım ve yardımcı oldu…. Çok

  27.   eş bayrağı dijo

    @rol

    Bunu söylemek için küstah ve haberi kötüleyen birisiniz. Bana yalan söylediğimi ya da verileri tahrif ettiğimi söylemeniz en kötü hakarettir, benim gibi ciddi PoC yapan insanlara bir şeyi savunmak için nasıl saldırdığınız beni gerçekten tiksindiriyor. Günlük bozulur, sistem çöker, hizmeti yeniden başlatmak işe yaramaz, bu nedenle saldırıya uğramış bir sunucudaki en iyi şey olmayan makineyi yeniden başlatmaktan başka seçenek yoktur, bana güvenlik tehlikeye atılırsa en iyisinin olduğunu söyleyeceksiniz. şey yeniden başlatmak veya yeniden yüklemek ve bu, sistemin kendilerini mazur görmesini ve NE OLDUĞUNU sıcak bir analizini yapmamasını söylediği için endişelenmem gereken tek şey budur? o noktaya ulaşmak için? Açıkçası, ubuntu kullanılarak yükseltilen ve bilgisayarınızda bir DOS 5.0 güvenliği olan bir sisteme ulaşırsanız, yeni sistem yöneticisinin bir ürününüz daha olursunuz, bu yüzden onu kimden alıyorum derseniz, sizi rahatsız ediyor. Ayrıca şüphe duyan sensin, aynı işletim sistemine O günün güncellemelerini yanıtladın mı? Kesinlikle hayır, öyleyse başka bir yalancı dene. Ne kadar kapasite eksikliğiniz var, bundan daha fazlası için taksi şoförü olarak işe gidin, size vereceğinden şüpheliyim, linux ile oynamayı bırakın ve pr0n bakmaya devam edin

    1.    rolo dijo

      Güvercini görelim (synflag), baba, bilgisayarı yeniden başlatmak zorunda kalmadan ikili günlük günlük dosyamız bozulduktan sonra günlüğün nasıl çalışmaya devam edeceğini size gösterecek.

      Bu örnekte debian 8 jessie'nin temel kurulumundan başlıyoruz.

      Varsayılan olarak, systemd-journal.service "storage = auto" işleviyle birlikte gelir, bu nedenle günlüklerin kalıcı bir kaydına sahip olmak için, dosyayı / var / log / journal / dizininde oluşturmak gerekir.

      # mkdir -p / var / log / journal /

      Günlüğün günlükleri yazmaya başlaması için bilgisayarı yeniden başlatmanız GEREKMEZ, sadece şunları yapın:

      # systemctl yeniden yükle systemd-journal.service
      o
      # systemctl zorla yeniden yükle systemd-journal.service

      ### şimdi derginin ikili günlüğünün bozuk olduğunu simüle edeceğiz ###

      # cd / var / log / günlük
      #ls
      24f02f5b2b19808b820ea0a980ed6efb
      # cd 24f02f5b2b19808b820ea0a980ed6efb
      # nano sistem.dergi
      ### şimdi bozuk olduğunu simüle etmek için dosyanın bir satırını değiştiriyoruz
      # günlükctl
      ### beklendiği gibi hiçbir şey olmuyor
      #### günlüğün yeni bir ikili program oluşturması için bilgisayarın yeniden başlatılması gerekiyor mu? HAYIR
      # systemctl zorla yeniden yükle systemd-journal.service
      #ls
      system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
      sistem.dergi
      # günlükctl
      ### Gördüğümüz gibi, günlük yeni bir ikili günlük dosyası oluşturur ve artık herhangi bir zamanda bilgisayarı yeniden başlatmak zorunda kalmadan bilgilere tekrar erişebiliriz

      https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be

      sonuç: sinflag veya cahilsiniz veya bir harikasınız
      O sonlu garue seni

      1.    rolo dijo

        yazma hatası ve kopyala ve yapıştırın kötüye kullanılması için systemd-journal.service yazdım, gerçekte bu hizmetin adı systemd-journald.service

      2.    SynFlag dijo

        Pichon?, ... ne kadar zayıfsın, cidden .. Bunu zaten biliyordum, ne dediğini görmek için kırmızı şapkalı hatayı rapor et, cevabı tutacağım, bak bakalım yakalarsan:

        Çıktı dosyasını kaldırırsanız veya dosyanın bazı kısımlarının üzerine yazarsanız, arka plan programı bu konuda gerçekten hiçbir şey yapamaz: eğer bir saldırgan çıktı dosyasını değiştirme iznine sahipse, zaten kazanmıştır. Arka plan programı bunlardan bazılarını kontrol edebilir, ancak bu oldukça verimsiz olur ve hiçbir şey için gerçekten yararlı olmaz. İsterseniz, 'journalctl –setup-keys' ile periyodik bir kriptografik imza oluşturabilirsiniz. Journalctl man sayfasına bakın.

        Journalctl, rsyslog'a bağlıdır, logda bir hata olması durumunda kendini yeniden başlatmaz, rsyslog'a ihtiyaç duymaz, toplam, rsyslog göndermek için fordward kullanmanız gerekir ve bu şekilde her şeye rağmen yazılır ve günlük kaydı yeniden oluşturulur, journald'daki bir tasarım hatası, görmek istemiyorsan, uçur beni.

      3.    anonim dijo

        @rol

        Videoda (siz mi yaptınız bilmiyorum) 2:11 dakikada ls kullanıldığını ve system.journal dosyasının orijinal boyutunun görülebilmesini sağlayan ls -l'nin kullanılmadığını görüyorum, sonra onu düzenliyorlar. nano ile ve Boş satırlar ekleyin, servisi elle yeniden başlatın ve 3: 15'te tekrar yaparlar ve ls -l'yi değil, 3: 20'de journalctl ile günlüğü görürler, bu da geçerli olan günlüğü gösterir.

        Şimdi sorularıma gel:
        1 - ls -l değil ls kullanıldığından, günlüğün düzenlenmeden önce sahip olduğu orijinal boyutu görebilmek için
        2 - eski günlüğe ne oldu? systemd onu bozuk ikili günlüğe nereye koydu?
        3 - silmemeniz gereken bozuk ikili günlüğünüzü hangi systemd komutuyla onarabilirsiniz?

        selamlar

      4.    rolo dijo

        @anonim

        Şimdi sorularıma gel:
        1 - ls -l değil ls kullanıldığından, günlüğün düzenlenmeden önce sahip olduğu orijinal boyutu görebilmek için
        2 - eski günlüğe ne oldu? systemd onu bozuk ikili günlüğe nereye koydu?
        3 - silmemeniz gereken bozuk ikili günlüğünüzü hangi systemd komutuyla onarabilirsiniz?

        1 Bunu düşünmediğim gerçeği, dizinde hangi dosyaların olduğunu görmek için ls'yi kullanın, ancak ilgileniyorsanız onu çoğaltabilirsiniz, prosedür ayrıntılıdır ve bunu sanal kutuda yapıyorum (bir debian tabanı kurmak Çok kolay)
        2 eski günlük aynı dizinde kalır, yalnızca systemd onu bir grup sayı ve harfle yeniden adlandırır (videoda gösterilir)
        3 Her durumda, üçüncü taraf uygulamaları kullanmayı deneyebilirsiniz (sanırım bazı onaltılık düzenleyiciler), çünkü systemd bozuk dosyayı onarabilirse, yeniden adlandırmaz veya yeni bir tane oluşturmaz. Her durumda ve bu yazıda daha önce de bahsettiğim gibi, temkinli bir sysadmin, ikili dosyanın bozulması durumunda günlük kayıtlarını düz metne dönüştürmek dışında ikinci bir sorgu aracı olarak rsyslog veya syslog-ng kullanabilir.

        Demek istediğim, kimseyi systemd kullanmaya ikna etme fikri değil (Debian yükleyicide int'i seçme olasılığı olmasını bile isterdim). ama sistemd hakkında yalanları tekrarlayan cahil ya da müthiş okuduğumda, bir blog var olduğu için, bu sözlerin gerçeklikle örtüşmediğini gördüğümde sessiz kalmayacağım. ve Aristoteles'in dediği gibi, tek gerçek gerçektir 😉

  28.   anonim dijo

    @rol

    Videoya tekrar baktım ve eğer orada listelenmişse, sadece sayısal adı o kadar uzundu ki onu gördüm, dizin olduğunu düşündüm… Egemen isim.
    İkili dosyayı onarmakla ilgili olarak, evet, mantıklı bir şey söylüyorsun ... eğer onu tamir edebilseydim, yeni bir tane yaratmam.
    Sonunda bunun bir ikili olmaması gerektiğine inandım ki bu gerçekleşmesin ve bunu özel araçlar olmadan Journalctl ile görebilmek ... Hala onu ikili format kullanmaya neyin yol açtığını anlamıyorum.

    Selamlar ve cevap verdiğiniz için teşekkürler

    1.    SynFlag dijo

      Rolo, kendini başka bir şeye adayın:

      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393

      Bunu bilmeden biliyordum…. Bir şeyler deneyen ve sadece osuruk videoları yapan biri arasındaki farkı nasıl fark edersiniz?

  29.   SynFlag dijo

    Ocote de Rolo'yu kapatmaya geldim, PoC'mde görülen hata bildirildi, bu yüzden ocote pichon'u kapatın:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393

  30.   rolo dijo

    Muhteşem görmek için:
    1 Günlüğün sorunu çözmesi için bilgisayarı TAMAMEN YANLIŞ pencerelerinde olduğu gibi yeniden başlatması gerektiğini belirttiniz.
    Size bunun bir yalan olduğunu gösterdim ve yaptığınız videoda hiçbir zaman systemctl force-reload systemd-journald.service komutunu kullanmıyorsunuz çünkü eğer bunu kullanırsanız argümanınız çöküyordu (veya komutu bilmiyordunuz) cahil olduğunuzu veya kasıtlı olarak kullanmadığınızı gösterir, bu da sizin bir hikaye anlatıcısı olduğunuzu gösterir)

    2 Hata raporları olduğunu söylüyorsunuz, bir yandan bu tamamen alakasızdır çünkü genellikle insanlar birçok saçmalığı hata olarak rapor eder (böylece her hata raporunun gerçek bir hata olmadığını anlarsınız), hatta bana sizin fikrinizi verir. kendin de aynı şekilde bildirdi. Öte yandan, tüm programlarda hatalar var (sysvinit'te rapor edilen kaç hata var (yaklaşık 20 yıllık bir program)) ve raporun iyi yanı, geliştiricilerin sorunları keşfetmelerine ve çözmelerine yardımcı olması (bazıları daha hızlı , diğerleri daha yavaş)

    3 Journal'da oluşturduğunuz hatayla, systemd'yi yeniden başlattığınızda çöktüğünü söylüyorsunuz çünkü videoda sanal kutuyu zorla yeniden başlatmanız gerektiğini görebilirsiniz. TAMAMEN YANLIŞ
    Gerçek şu ki, sistem mükemmel bir şekilde başladığında systemd çökmez (eğer sistem başlamazsa, size bir çekirdek paniği verir ve kurtarma moduna girmeniz gerekir)
    Size olan şey, bir metin düzenleyiciyle bir ikili düzenlemeye çalıştığınızda sistemin kontrol edilmesidir ve ayrılan bellek, işletim sisteminin durumu gibi faktörler çok olabilir (videoda sistem uzun zaman alır 0'ın temiz bir yüklemesi olmadığını öneren şeyi (bu tür bir durum için önerilir) önyüklemek ve kapatmak için. Size sadece yaklaşık 10 veya 20 kez düzenlediğim ikili dosyanın hiç kontrol edilmediğini söyleyebilirim. Bu aynı zamanda cahil veya hikaye anlatıcısı olduğunuzu da gösterir.

    4 Şimdi günlüğün rsyslog'a bağlı olduğunu söylüyorsunuz TAMAMEN YANLIŞ, gerçek şu ki, herkes rsyslog'u yükleyerek veya kaldırarak ve günlüğün mükemmel çalıştığını görerek onu doğrulayabilir.

    Bana bu sağlıksız takıntıyı bırakırsan çok memnun olurum, cahil ya da muhteşem olman benim hatam değil

    Sonuç:
    Systemd'yi kullanmak istemiyorsunuz, bence harika, anti-systemd haçlı seferlerinize taraftarlar edinmek için artık yalanlarla terörü yaymanıza gerek yok. Özgür yazılım dünyasında herkes için bir yer olduğunu yaşadım ve yaşamasına izin verdim 😉

    1.    rolo dijo

      3. noktadaki bir açıklama, birisi bana systemd'nin pid1'de olduğu için bir çarpmanın o sistem kaskını ima edeceğini söyleyebilirdi. İlk olarak burada belirtilen iki şey, dergi arızası nedeniyle sistemin çöktüğüdür, ancak gerçekte bir metin editörü ile (gerçek zamanlı olarak kullanılan) bir ikili girme kontrolü vardır, ayrıca şunu da açıklığa kavuşturuyorum. Yaptığım testler sanal makineyi hiç kontrol etmedi. İkincisi, aklı başında hiç kimse linux'un xddd olarak etiketlenmediğini iddia edemez,

    2.    SynFlag dijo

      Harika?, Sıska, biraz geri çekil, muhteşem yaşlı kadınına bir sopayla dokunmadığımda lastiği attığımı söyleyen, saygıya geri dönüyorum:

      1.- İdeal olmayan servisi yeniden başlatmalı veya yeniden başlatmaya zorlamalısınız ve CentOS 7'de servisin yeniden başlatılmasını denediğimde hiçbir şey yapmadım, bunun yeni 208 veya 217 değil 216 sürümü olduğunu unutmayın. Fedora.

      2.- Alakasız ve böcek bildirenler? ... sen bir aptalsın, sana cevap bile vermiyorum

      3.- UNHAPPY, videonun o gün denediğim versiyonu, görebildiğiniz, tüm işletim sistemi çöktü, neden orto mutsuz yalan olduğunu düşünüyorsunuz? Ben yalancı bir maymun değilim, cindor pajero almaya gidin.

      4.- Kendini yenilemeye bağlıdır, kendi başına yapmaz aslında sistem geliştiricilere bir özellik olarak önerdim, hizmet yeniden başlatılmadıkça günlüğe kaydetmeyi durdurmadan kendini yeniler, eklemek için, bu yüzden sikimi em ve porno izlerken işbirliği yaptığın için teşekkür ederim baba.

      Chau sıska, maymunlarla konuşmaktan yoruldum, bu yüzden hayvanat bahçesine gitmeyi tercih ediyorum, anüsümün seviyesindeyken sohbet ediyoruz.

      1.    rolo dijo

        @SynFlag Özür dilerim, hasta olduğunu bilmiyordum, gerçekten harika ve cahil olduğunu düşünmüştüm ama az önce yazdıklarınla ​​aslında hayal olduğunu anladım.

        iyi hiçbir şey, umarım ilaçlarınızı daha iyi bitirirsiniz ve gerçeğe geri dönersiniz, kuvvet! yapabilirsiniz!!!

  31.   pedro dijo

    Okudum, okudum ve tekrar okudum ama hiçbir şey anlamıyorum, sadece Xubuntu 14.04.1 çıktığından beri dizüstü bilgisayarımla veya hp 1102 lazer yazıcımla herhangi bir sorun yaşamadığımı biliyorum, bilmiyorum herhangi bir şey, ben bir kullanıcıyım ve systemd'nin daha kötü olup olmadığını veya init için uygun olup olmadığını bilmiyorum, ancak xubuntu ile herhangi bir sorunum olmadığını tekrarlıyorum. 🙂

  32.   Gerçek dijo

    Okudum, okudum ve tekrar okudum ve sadece eski bir konuyu yeniden yaşadığımı biliyorum. XD