Linux uygulamaları neden sıklıkla yazıldığı dili özete koyuyor?

Uygulamaları gösterirken, Windows ve Mac çoğunlukla özellikler hakkında konuşur. Öte yandan Linux uygulamaları, özelliklerden ziyade dili (ve beraberindeki kütüphaneleri) yazmak için kullanılan dil hakkında daha fazla ayrıntıya sahiptir. Neden?

Sadece masaüstü entegrasyon gereksinimleri nedeniyle bir fark yaratan GTK + karşı QT arasındaki farkı bilmek anlayabiliyordum, ancak C vs C ++ vs Python vs Assembly vs? Gerçekten mi?

Örneğin: foo, C / GTK + ile yazılmış basit bir falan filan.

Geleneksel Linux kullanıcısı (sistemi kendiliğinden yükleyen bir inek tamircisi) bu tür bilgileri önemsiyor (bu aracın arkasında hangi teknoloji var?). Ben de, örneğin, sevmediğim bazı teknolojileri kullandığından, bir paket kurmaktan ve kullanmaktan kaçınacak olan geeky adamlarından biriyim. Bazıları bu tür davranışlara elbette din diyor. Aptal değil mi?

Neyse iki nedenden dolayı düşünebilirim:

• Paketleyiciler de bu Linux kullanıcılarından daha fazla (daha fazla değilse), bu yüzden böyle bir bilgi eklemek için iyi bir fikir buldular.

• Bence bu paketleyiciler bu tür bilgileri paket açıklamalarına koyduklarında, büyük olasılıkla bir çeşit tanıtım olarak yapıyorlar. Bazen çalışıyor (bana birkaç kez çalıştı).

Bu sadece bir tahmin.

Bence bu dört yazılım özgürlüğünün ikincisiyle ilgili :

Programın nasıl çalıştığını inceleme ve istediğiniz şeyi yapmak için programı değiştirme özgürlüğü (özgürlük 1). Kaynak koduna erişim bunun için bir önkoşuldur.

Dili (veya diğer teknik özellikleri) tanıtmak insanların seçme yeteneğini destekler ve bu dillerde yetkin kişilerin projelere katılımını teşvik eder.

Bu kısmen tarihsel olabilir. Çok uzak olmayan bir geçmişte bile, bireysel sistem yöneticilerinin sistemlerinde çalışan her şeyi kurmaları ve kurmaları normaldi.

Bir aracı uygulamak için hangi dilin ve kitaplıkların kullanıldığına dair notlar, yöneticiye bu işlemin kendi sistemi için ne kadar çalışacağı hakkında bir ipucu verir .

Her yerde bulunan ve çok geniş kapsamlı paket yönetim araçlarında bu biraz anakronizm, ancak unix kültürü, işe yarıyor gibi görünen şeyleri dışarı atmamak anlamında muhafazakar, bu yüzden alışkanlık ölmeden önce biraz zaman alacak.

Ek binasında jasonwryans' cevabı :

Yazıldığı dili isimlendirirseniz, alan kişi bir düzeltme eki sağlamanın veya bazı bilgiler edinmenin veya programı genişletmenin ne kadar zor olacağını tahmin edebilir.

Tabii ki bu sadece bir programcıysanız mantıklı.

Özetleri nerede gördün? Bir depoda mı yoksa .deb veya .rpm gibi bir pakette mi?

Kaynaktan derlerseniz, başka şeyler (compliler, kütüphaneler, derleme araçları) yüklemeniz gerekip gerekmediğini belirlemek için bilgiler yardımcı olabilir.

Unix ve şimdi LInux ve BSD'ler her zaman gerçekten kırık bir yazılım tabanına sahipti ve yakın geçmişte çok daha çeşitli bir donanım tabanı vardı. Bazı yazılımların sisteminizde bulunan tamsayılarda çalıştığını veya kaynak kodunu derleyebileceğinizi bilmek önemlidir. Bir Ortak Lisp yorumcunuz veya bir Tcl yorumcunuz ya da başka bir yorumcunuz yoksa, yalnızca çalıştıramayacağınızı öğrenmek için kaynak indirmeyi rahatsız etmek istemediniz.

Bir şeyin hangi dilde olduğunu açıklamak çok zaman kaybetti.

“Bu şey nedir?” Sorulduğunda, bir geliştirici işlevini değil, kaynak koduna bağlı olan doğasını tanımlama eğilimindedir. Birisi umarım bir paketi bitirmeden önce daha kullanıcı merkezli olacak şekilde açıklamayı yeniden yazacaktır, ancak dilden bahsetmek, örneğin genişletilebilirlik ve yazılabilirlik ile ilgili olabilir veya katkıda bulunanları çekme fırsatı için yararlı olabilir.

Benim bakış açımdan, bu tür bilgiler yeni katkıda bulunanları cezbetmek ve potansiyel kullanıcılara uygulamayı sistemlerine entegre etmenin ne kadar iş gerektirebileceğine dair hemen bir fikir vermek için gereklidir.

• Genel bir özellik, uygulamayı çalıştırırken kullanılan kütüphanelerdir .

Bazı kurulumlar GTK + gibi seçilmiş birkaç araç setiyle sınırlıdır, ancak QT değil ya da tam tersi. Bir sistemi koruyan ve bileşenlerini uzun süre düzenli olarak güncelleyen bir yönetici için, bu sadece pratik bir soru olabilir, dini bir soru olmayabilir.

• Diğer bir özellik, kullanılan kütüphaneler ve uygulamayı derlemek için gerekli önkoşullardır .

Yani, kaynak tabanlı bir Linux dağıtımının kullanıcıları için, bir uygulamanın C veya Objective-C'de yazılmış olması büyük bir fark yaratır, çünkü derleyicilerinin dili ilk etapta desteklemesi gerekir. Diğer diller büyük bir kütüphane yığını kurmayı gerekli kılabilir. Bu durumda soru, yine, bu uygulamayı derlemek için ne kadar işi kabul etmek istediğinizdir.

• Farklı bir yön, katkıda bulunanları cezbetme niyetidir.

Çoğu geliştiricinin az sayıda dil tercihi vardır veya başka diller konusunda deneyimsiz olabilir. Çok sayıda insanın bir uygulamaya katkıda bulunmasına izin vermek için, bazı projeler kaynaklarını iki farklı dile ayırmıştır (Wesnoth, Vega Strike, Naev gibi, sadece birkaçını belirtmek için). Bunlardan biri çekirdek uygulama için (C veya C ++ gibi), diğeri kolay değişiklik için (Python veya Lua gibi). Wesnoth'ta bunun nasıl ve neden yapıldığını anlatan "Açık Kaynak Uygulama Mimarisi" başlıklı bir bağlantı .

• Son olarak, bazı diller için çok fazla önyargı ve önyargı var.

Sadece herhangi bir dilde yazılmış çok verimsiz bir yazılım gördüğümü söyleyeceğim. Bana sorarsanız, verimlilik için, uygulamanın kod kalitesi yazıldığı dilden çok daha önemlidir.

Bence bunların çoğu performans reklamlarıyla ilgili. Derlenmiş bir dilde yazılmış bir uygulama (C, C ++, ...) bir betik dilinde yazılmış olandan (perl, python, ...) çok daha iyi bir heck gerçekleştirecektir.

Ancak uyumluluğa da bağlanır. Komut dosyası dilinde yazılmış bir uygulamanın, çok az değişiklikle veya hiç değişiklik yapmadan mimariler ve işletim sistemleri arasında daha taşınabilir olması muhtemeldir.

Günümüzün masaüstü / sunucu sistemlerinde bu kadar alakalı olmayabilir, ancak gömülü sistemlerden SSD netbook'larına ve tabletlere kadar daha küçük sistemler için, bir program tarafından kullanılan diller veya kütüphaneler hem boyut hem de taşınabilirlik hususları.

Boyutla ilgili olarak: Tüm standart modüller ve tipik olarak kullanılan eklenti modülleriyle birlikte ek bir dil için bir tercüman eklemek, depolama gereksinimlerine kolayca yüz megabayt ekleyebilir. Aynı şey kütüphane aileleri, özellikle Gnome ve KDE gibi büyük masaüstü ortamlarıyla ilişkili olanlar için de geçerlidir. Daha da kötüsü, çalışmasını gidiş niçin n+1Perl programlarının bellek çok şey paylaşılabilir beri, bellek kullanımı gereksinimleri için çok eklemek, ama gidiş olmayabilir nPerl programları ve 0 Python programlarındanPerl programları ve 1 Python programı bellek kullanımında önemli bir artışa neden olur. Bu her aptal özgür yazılım yazma kendi favori komut dosyası / radtool dili programlamak istedikleri olduğunda daha da bir sorun haline gelir ... Perl, Python, PHP, Ruby, JavaScript, Bourne kabuğu, Bash, Csh, ....

Taşınabilirlik ile ilgili olarak: Birçok yorumlanmış dil (kitaplık çerçevelerinin yanı sıra), büyük Linux masaüstü / sunucu sistemlerinde bulunabilen ancak daha küçük / gömülü / MMU'suz sistemlerde bulunmayan özellikleri yoğun şekilde kullanır. Çalışma .sozamanında dinamik modül yüklemesine bağımlılık akla geliyor ...