Şimdi Ara

Milli işletim sistemi Pardus tekrar ayağa kaldırıldı (7. sayfa)

Daha Fazla
Bu Konudaki Kullanıcılar: Daha Az
2 Misafir (1 Mobil) - 1 Masaüstü1 Mobil
5 sn
152
Cevap
1
Favori
8.866
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
1 oy
Öne Çıkar
Sayfa: önceki 45678
Sayfaya Git
Git
sonraki
Giriş
Mesaj
  • başlangıç olarak geçilsin , nereden dönersen kardır
  • drjacob kullanıcısına yanıt
    Ufak bir çalışma yaptım.https://github.com/torvalds/linux/raw/master/CREDITS sayfasında Linux projesine katkıda bulunan kişiler ve ne katkıda bulundukları listeli. Listede Hintli, Japon, Brezilyalı, İsrailli, alman, ingiliz, italyan, vs her bir ülkeden isim var türkiye'den hiçbir isim yok!



    Liste aşağıda, isteyen kontrol edebilir. Yazılım alanında SIFIRIZ derken boşuna demiyorum, belgesi ile diyorum. Milli proje, yerli üretim vs. propaganda yapanların araştırması gereken cok şey var. Türkiye'deki yazılım sektörü 'ekonomimiz şaha kalkıyor' haberlerine bakılarak değerlendirilemez. Sahaya ineceksin, gerçekleri göreceksin sonra konuşacaksın. Katkımızın SIFIR olduğu Linux 'u alıp bir paket yöneticisi eklemişler adına Milli Proje demişler, dertleri de 'nasıl daha milli oluruz' olmuş, üstüne bir de bu konuda bize akıl vermeye başlamışlar.



    Linux projesine katkıda bulunanlar:



    Matt Mackal, Matti Aarnio, Thomas Abraham, Dragos Acostachioaie, Mark Adler, Monalisa Agrawal, Dave Airlie, Tigran A. Aivazian, Werner Almesberger, Tim Alpaerts, Anton Altaparmakov, C. Scott Ananian, Erik Andersen, Michael Ang, H. Peter Anvin, Andrea Arcangeli, Derek Atkins, Michel Aubry, Jens Axboe, John Aycock, Miles Bader, Ralf Baechle, Krishna Balasubramanian, Chris Ball, Dario Ballabio, Paul Bame, Arindam Banerji, Greg Banks, James Banks, Krzysztof G. Baranowski, Fred Barnes, Paul Barton-Davis, Carlos Henrique Bauer, Peter Bauer, Fred Baumgarten, Donald Becker, Adam Belay, Daniele Bellucci, Krzysztof Benedyczak, Randolph Bentson, Muli Ben-Yehuda, Johannes Berg, Stephen R. van den Berg (AKA BuGless), Peter Berger, Hennus Bergman, Tomas Berndtsson, Ross Biro, Anton Blanchard, Hugh Blemings, Philip Blundell, Thomas Bogend÷rfer, Bill Bogstad, Axel Boldt, Erik Inge Bols°, Andreas E. Bombe, Al Borchers, Marc Boucher, Zoltßn B÷sz÷rmÚnyi, John Boyd, Peter Braam, Ryan Bradetich, Dirk J. Brandewie, Derrick J. Brashear, Dag Brattli, Lars Brinkhoff, Paul Bristow, Stefano Brivio, Dominik Brodowski, Andries Brouwer, NeilBrown, Zach Brown, David Brownell, Gary Brubaker, Matthias Bruestle, Adrian Bunk, Ray Burr, Lennert Buytenhek, Michael Callahan, Luiz Fernando N. Capitulino, Remy Card, Ulf Carlsson, Ed Carp, Florent Chabaud, Gordon Chaffee, Chih-Jen Chang, Reinette Chatre, Michael Elizabeth Chastain, Mauro Carvalho Chehab, Raymond Chen, Chris Cheney, Stuart Cheshire, Carlos Chinea, Randolph Chung, Juan Jose Ciarlante, Steven P. Cole, Hamish Coleman, Neil Conway, Kees Cook, Robin Cornelius, Mark Corner, Michael Cornwell, Luis Correia, Alan Cox, Cristian Mihail Craciunescu, Laurence Culhane, Massimo Dal Zotto, Uwe Dannowski, Ray Dassen, David Davies, Frank Davis, Wayne Davison, Terry Dawson, Helge Deller, Jean Delvare, Peter Denison, Todd J. Derr, Martin Devera, Alex deVries, Jeff Dike, Matt Domsch, Mattia Dongili, Ben Dooks, Ivo van Doorn, John G Dorsey, Eddie C. Dost, Cort Dougan, Daniel Drake, Oleg Drokin, Walt Drummond, Bruno Ducrot, Don Dugger, Thomas Dunbar, Randy Dunlap, Bob Dunlop, Cyrus Durgin, Torsten Duwe, Tom Dyas, Drew Eckhardt, Hans-Christian Noren Egtvedt, Heiko Eifeldt, Bjorn Ekwall, Pekka Enberg, David Engebretsen, Michael Engel, Paal-Kristian Engstad, Stephane Eranian, Johannes Erdfelt, Dmitry Eremin-Solenikov, Doug Evans, Riccardo Facchetti, Nils Faerber, Rik Faith, Jßnos Farkas, Ben Fennema, J³rgen Fischer, Jeremy Fitzhardinge, Ralf Flaxa, Lawrence Foard, Karl Fogel, Daniel J. Frasnelli, Jim Freeman, Bob Frey, Adam Fritzler, Fernando Fuganti, Oded Gabbay, Kumar Gala, Nigel Gamble, Jeff Garzik, Jacques Gelinas, David Gentzel, Kai Germaschewski, Philip Gladstone, Jan-Benedict Glaw, Thomas Gleixner, Richard E. Gooch, Carlos E. Gorges , Dmitry S. Gorodchanin, Paul Gortmaker, Masanori GOTO, John E. Gotts, Wolfgang Grandegger, William Greathouse, Tristan Greaves, Michael A. Griffith, Hans Grobler, Grant Grundler, Grant Guenther, Richard G³nther, Justin Guyett, Danny ter Haar, Enver Haase, Bruno Haible, Jack Hammer, Greg Hankins, Brad Hards, Angelo Haritsis, Jan Harkes, Kai Harrekilde-Petersen, Bart Hartgers, Oliver Hartkopp, Andrew Haylett, Andre Hedrick, Jochen Hein, Christoph Hellwig, Richard Henderson, Benjamin Herrenschmidt, Andreas Herrmann, Sebastian Hetze, David Hinds, Michael Hipp, Richard Hirst, Jauder Ho, James Hogan, Tim Hockin, Mark M. Hoffman, Dirk Hohndel, Kenji Hollis, Nick Holloway, Ron Holt, Marcel Holtmann, Rob W. W. Hooft, Christopher Horn, Harald Hoyer, Jan Hubicka, David Huggins-Daines, Gareth Hughes, Kenn Humborg, Michael Hunold, Miguel de Icaza Amozurrutia, Ian Jackson, Andreas Jaeger, Mike Jagdis, Dave Jeffery, Jakub Jelinek, Niels Kristian Bech Jensen, Michael K. Johnson, Dave Jones, Martin Josfsson, Ani Joshi, Jesper Juhl, Jozsef Kadlecsik, Bernhard Kaindl, Mitsuru Kanda, Jan Kara, Jan "Yenya" Kasprzak, Jakob Kemi, Fred N. van Kempen, Martin Kepplinger, Karl Keyte, Marko Kiiskila, Russell King, Olaf Kirch, Avi Kivity, Andi Kleen, Ian Kluft, Thorsten Knabe, Alain L. Knaff, Gerd Knorr, Hans J. Koch, Harald Koenig, Rudolf Koenig, Andreas Koensgen, Harald Koerfgen, Willy Konynenberg, Goran Koruga, Jiri Kosina, Gene Kozin, Maxim Krasnyansky, Andreas S. Krebs, Greg Kroah-Hartman, Russell Kroll, Denis O. Kropp, Andrzej M. Krzysztofowicz, Gero Kuhlmann, Markus Kuhn, Jaya Kumar, Mohit Kumar, Gabor Kuti, Jaroslav Kysela, Bas Laarhoven, Ashley Lai, Savio Lam, Christoph Lameter, Paul Laufer, Jonathan Layes, Tom Lees, David van Leeuwen, Volker Lendecke, Kevin Lentin, Hans Lermen, Colin Leroy, Achim Leubner, Phil Lewis, Stephan Linz, Christophe Lizzi, Siegfried "Frieder" Loeffler (dg1sek), Jamie Lokier, Mark Lord, Warner Losh, Robert M. Love, Martin von L÷wis, H.J. Lu, Yanir Lubetkin, Michal Ludvig, Tuomas J. Lukka, Daniel J. Maas, Hamish Macdonald, Peter MacDonald, Pavel Machek, Paul Mackerras, Pat Mackinlay, James B. MacLean, Kai Mõkisara, Asit Mallick, Petko Manolov, Martin Mares, John A. Martin, Kevin E. Martin, John S. Marvin, Torben Mathiasen, Claudio S. Matsuoka, Heinz Mauelshagen, Mark W. McClelland, Ian McDonald, Patrick McHardy, Paul E. McKenney, Mike McLagan, Bradley McLean, Kyle McMartin, Dirk Melchers, Arnaldo Carvalho de Melo, Karsten Merker, Michael Meskes, Nigel Metheringham, Craig Metz, William (Bill) Metzenthen, Pauline Middelink, David S. Miller, Rick Miller, Harald Milz, Ron Minnich, Corey Minyard, Kazunori Miyazawa, Patrick Mochel, Eberhard M÷nkeberg, Thomas Molina, Paul Moore, James Morris, David Mosberger-Tang, Sam Mosel, Wolfgang Muees, Paul Mundt, Ian A. Murdock, Scott Murray, Zwane Mwaikambo, Trond Myklebust, Johan Myreen, Matija Nalis, Jonathan Naylor, Ian S. Nelson, Russell Nelson, Dave Neuer, Michael Neuffer, Gustavo Niemeyer, David C. Niemi, Fredrik Noring, Michael O'Reilly, Miguel Ojeda Sandonis, Peter Oruba, Jens Osterkamp, Gadi Oxman, Greg Page, Venkatesh Pallipadi (Venki), David Parsons, Ivan Passos, Mikulas Patocka, Vojtech Pavlik, Rick Payne, Barak A. Pearlmutter, Avery Pennarun, Inaky Perez-Gonzalez, Yuri Per, Inaky Perez-Gonzalez, Gordon Peters, Johnnie Peters, Kirk Petersen, Martin Kasper Petersen, Mikael Pettersson, Reed H. Petty, Kai Petzke, Emanuel Pirker, Nicolas Pitre, Ken Pizzini, Stelian Pop, Pete Popov, Matt Porter, Frederic Potter , Rui Prior, Stefan Probst, Giuliano Procida, Richard Purdie, Daniel Quinlan, Juan Quintela, Augusto Cesar Radtke, Goutham Rao, Anil Ravindranath, Eric S. Raymond, Stefan Reinauer, Thomas Renninger, Joerg Reuter, Ricardo Ribalda Delgado, Francois-Rene Rideau, Rik van Riel, Pekka Riikonen, Tobias Ringstr÷m, Luca Risolia, William E. Roadcap, Andrew J. Robinson, Florian La Roche, Christoph Rohland, Thiago Berlitz Rondon, Stephen Rothwell, Gerard Roudier, Sebastien Rougeaux, Aristeu Sergio Rozanski Filho, Alessandro Rubini, Philipp Rumpf, Paul `Rusty' Russell, Richard Russon (FlatCap), Bill Ryder, Sampo Saaristo, Thomas Sailer, Manuel Estrada Sainz, Wayne Salamon, Robert Sanders, Duncan Sands, Aleksa Sarai, Dipankar Sarma, Hannu Savolainen, Deepak Saxena, Eric Schenk, Henning P. Schmiedehausen, Michael Schmitz, Peter De Schrijver, Martin Schulze, Robert Schwebel, Marcel Selhorst, Darren Senn, Stas Sergeev, Simon Shapiro, Mike Shaver, John Shifflett, Robert Siemer, James Simmons , Jaspreet Singh, Haavard Skinnemoen, Rick Sladkey, Craig Small, Stephen Smalley, Chris Smith, Christopher Smith, Mark Smith, Miquel van Smoorenburg, Scott Snyder, Leo Spiekman, Manfred Spraul, Andrew Stanley-Jones, Michael Still, Henrik Storner, Drew Sullivan, Adam Sulmicki, Adrian Sun, Eugene Surovegin, Corey Thomas, Doug Thompson, Tommy Thorn, Urs Thuermann, Jon Tombs, Linus Torvalds, Marcelo Tosatti, Stefan Traby, Jeff Tranter, Andrew Tridgell, Josh Triplett, Winfried Tr³mper, Tsu-Sheng Tsao, Theodore Ts'o, Simmule Turner, Stephen Tweedie, Thomas Uhl, Jason Uhlenkott, Greg Ungerer, Jeffrey A. Uphoff, Matthias Urlichs, Geert Uytterhoeven, Chris Vance, Petr Vandrovec, Thibaut Varene, Heikki Vatiainen, Andrew Veliath, Dirk Verworner, Andrew Victor, Riku Voipio, Patrick Volkerding, Jos Vos, Jeroen Vreeken, Mark Wallis, Peter Shaobo Wang, Tim Waugh, Juergen Weigert, David Weinehall, Matt Welsh, Harald Welte, Bill Wendling, Mike Westall, Greg Wettstein, Steven Whitehouse, Hans-Joachim Widmaier, Urban Widmark, Marco van Wieringen, Matthew Wilcox, G\"unter Windau, Ulrich Windl, Gertjan van Wingerde, Lars Wirzenius, Jonathan Woithe, Clifford Wolf, Roger E. Wolff, Thomas Woller, David Woodhouse, Chris Wright, Michal Wronski, Frank Xia, Li Yang, Victor Yodaiken, Hiroshi YOKOTA, Hideaki YOSHIFUJI, Eric Youngdale, Niibe Yutaka, James R. Van Zandt, Orest Zborowski, Richard Zidlicky, Werner Zimmermann, Roman Zippel, Leonard N. Zubkoff, Alessandro Zummo, Marc Zyngier TOPLAM GELİŞTİRİCİ SAYISI: 547



    Yukardaki liste şu betik ile (Perl) çıkarılmıştır:



    quote:



    use LWP::Simple;



    my $URL = "https://github.com/torvalds/linux/raw/master/CREDITS";



    @katkilar = split "\n", get($URL);



    my @aus;



    for my $line (@katkilar) {

    push @aus, "$line, " if ($line =~ s/N:\s(.+)$/$1/g);

    }



    print @aus;

    print "TOPLAM LİNUX GELİŞTİRİCİ SAYISI: " . @aus . "\n";


    < Bu ileti mini sürüm kullanılarak atıldı >




  • Milli olma ifadesi siyasi bir unsur barındırdığını sanmamakla birlikte, bir dağıtıma milli sıfatı eklemek gayet mantıksız. Pardus'un kullanılmasını yaygınlaştırmak için kullanılan kullanılan basit bir makyaj ifade sadece. İyi niyetle kullanılmış olsa bile, esas kullanılması gereken sıfat yerel olmalı. Bu GNU felsefesini yeterince anlamamakla alakalı bir durum.

    Aslında Pardus'a bir dağıtımdan ziyade, kamuda özgür/açık kaynak kullanımına geçiş projesi olarak bakılsa taşlar yerine oturur. Zira asıl amacı kamuda (ya da kurumsal ortamlarda) kullanılacak bir dağıtım oluşturmaktır. Zaten ilk Pardus'taki yetersiz paket sayısı (daha doğrusu hedeflediği ortam için yeterli gerekli paketleri barındırması), taban değişikliği sonrasındaki Pardus'un ise azalan bakım yüküne rağmen son kullanıcı için uygun hale getirilmemesi (var olanla yetinilmesi ya da herhangi bir hedef içinde olmaması), yine mevcut Pardus'un özgün bir dağıtım haline getirilmesi için çaba sarfedilmesi yerine, kamu ve kurumsal ortamlarda kullanılacak araçlara önem verilmesinden bu sonuca ulaşmak zor değil. Mesela aşağıdaki projeler bu hedefi tamamlayıcı nitelikte güzel çalışmalar. Uygulamaları kullanmadım, açıklamalar dağıtımın kendi sayfasından alıntıdır.

    Ahtapot : Ahtapot, Pardus işletim sistemi üzerinde açık kaynak kodlu siber güvenlik bileşenlerinin entegre edildiği, bir merkezden yönetilebilecek, derinlemesine siber güvenlik çözümü oluşturmayı hedefleyen bir projedir.


    Engerek:Kamu kurumları, üniversiteler, büyük ticari kurumlarda genel olarak, BT sistemlerindeki kullanıcı hesaplarının yönetilmesi, sistemlerdeki yetki-rollerin doğru ve zamanında tanımlanması, emeklilik, ayrılma, tayin-terfi durumlarında hesapların kapatılması veya eski yetkilerin kaldırılması, şifrelerin yöneticiler tarafından belirlenmesi ve bilinmesi, yetkilerin ve hesaplar üzerindeki hareketlerin denetlenemez olması gibi ciddi sorunlar yaşanmaktadır. Bu tarz durumlar, ciddi veri sızıntılarına yol açabilmektedir. Kimlik Yönetim sistemi ile kullanıcı hesaplarının yönetimi, merkezi ve daha güvenli hale getirilerek güvenliğin artırılması, yukarıdaki sorunların çözümlenmesi, zaman ve iş gücü maliyetlerinin azaltılması mümkün olmaktadır.




    Lider Ahenk: Kurumsal ağ üzerindeki, sınırsız sayıda farklı sistemi ve kullanıcılarını tek merkezden yönetebilmeyi, izlemeyi ve denetlemeyi sağlayan, TÜBİTAK ULAKBİM tarafından geliştirilen açık kaynaklı bir yazılım sistemidir.
    Küresel dünyada kurumsal bilgi işlem merkezlerinin, sürekli genişleyen ve değişen bilişim araçları üzerindeki kurumsal politikalarını, güvenlik gereksinimlerini, etkin, esnek ve düşük maliyetlerle karşılamak üzere geliştirilmiştir.
    Lider sunucu ve Ahenk çekirdekleri ile LDAP sunucusunun oluşturduğu benzersiz çözüm altyapısı çevresinde kurumsal ihtiyaçlara göre özelleşmiş otuzdan fazla eklenti içerir.

    Her ölçekte, merkezi ya da dağıtık organizasyonlara göre ölçeklenebilir. Gereksinimlere göre uyarlanabilir. Mevcut kurumsal yazılım ve çözüm sistemlerine kolayca entegre olabilir.



    Ulakbüs: ULAKBÜS, Ulusal Açık Kaynaklı Bütünleşik Üniversite Sistemi Projesi, üniversitelerin kaynaklarının optimum düzeyde kullanılabilmesi ve tek çatı altında çözüm bulmak üzere geliştirilmektedir. ULAKBÜS, üniversitelerin hem akademik hem de idari ihtiyaçlarının tamamını karşılamak üzere, 360 derece tüm hizmetleri kapsayacak şekilde tümleşik bir yapı olarak tasarlanmıştır.



    ETAP: Pardus Etkileşimli Tahta Arayüzü eğitim kurumlarında kullanılmakta olan etkileşimli tahtalarda kullanılmak üzere özel olarak tasarlandı. Tasarım ve eklenen yeni özellikler dokunmatik ekranlı bir cihazın daha kolay ve etkili kullanımını sağlaması düşünülerek geliştirildi.



    Farklı projeler varsa bilgi sahibi arkadaşlar bilgilendirebilir.

    Yine eski Pardus döneminde Pisi paket yöneticisi ve Müdür oldukça yenilikçiydi. Bu tip yazılımların geliştirilmesinde katkıda bulunanların emeğini görmemek olmaz. Ama hala yavrusunu pamuğum diye seven kirpilerde aramızda yok değil. Aslında eleştirilmesi gereken durum da bu değil, ya da yerel bir dağıtımın çekirdeğe destek vermemesi de çok mühim değil. Zaten güzel yerlere gelmiş bir çok dağıtımın geliştiricileri, Linux çekirdeğine destek vermiyor. Zira odaklanmaları beklenen hususlar bunlar değil.

    Pardus'un odaklanması gereken husus, özgür yazılım ve açık kaynak uygulamaların bir an önce kamuda yaygınlığının sağlanması ve süreci geciktiren tüm engellerin kaldırılmasıdır. Bu açıdan bakıldığında Pardus'a milli bir proje demek yanlış olmaz, ama kaynağı özgür yazılım olan bir dağıtımı Milli OS olarak nitelendirmek en basitinden algı eksikliğidir.

    Kamuda özgür yazılım ve açık kaynak uygulamalara geçişi bir maliyet unsuru olarak görmekte gayet abes. Bu kamusal ortamdaki hedeflerin belirlenmesine de etki eden olumsuz bir husus olacaktır. Bununla birlikte kamu için üretilen bir projeden ve projeyi yöneten ve katkı verenlerin tümünden özgür yazılım felsefesini özümsemelerini beklemekte saf dillilik olur. Peki önemsenecek husus nedir, öncelikle özgür yazılım ve açık kaynak uygulamaların güven güvenirliliğinin ön plana çıkarılması gerekiyor. Açık kaynak olmayan OS ve yazılımların ne tür sorunlara sebep olacağının detaylı bir risk analizinin yapılması gerekiyor. Kaynak kodlarını bilmediğimiz böylesi OS ve yazılımların kamusal alanda kullanılması ciddi bir güvenlik tehdididir, neden böyle olduğunu açık olarak belirtmeye de gerek yok zaten.

    Benzer durum uluslarası/global piyasalara at koşturan, belirli bir statüdeki tüm ulusal firmalarımız için de geçerli. Bu firmaların, apaçık bir tehdit olan kapalı kaynak kodlu OS ve yazılımları kullanmasının uluslararası rekabette ne dezavantajlar doğuracağının risk analizini de yine bu proje başındaki yetkililer yapmalı ve bu kurumları uyararak, geçiş için gerekli tedbir ve yol haritalarını belirlemeliler. Günümüzde ekonomik değerlere sahip bu ulusal firmalarımız, ülkemiz ekonomisi için bir belkemiği niteliğinde ve tür alandan gelecek saldırılara karşı gerçekten savunmasız durumdadırlar. Zira kapalı olan bu kaynak kodları arasındaki arka kapılar (var olup olmadığını dahi tartışmaya gerek yok) ciddiyetin ötesinde bir risk unsuru içermekte. Buradan gelebilecek saldırılara hazırlıksız kurumları (istedikleri kadar hazırlansalar boş aslında), bu kaynak ile elde edilecek verilerle global piyasada zor duruma düşürmek çok zorlayıcı bir senaryo olmasa gerek.

    Durum buyken, Pardus projesinin arkasında duranların, bu dağıtımı sadece kamusal alan ihtiyaçlarına yetecek bir dağıtım olarak görmemeleri gerekir. Böyle bir bakış açışı durumun ciddiyetinin farkında olmamaktır. Son zamanlarda yaşadığımız ekonomik zorluklar sonrasında, sırf maliyet ve parmak sallama amaçlı tavırlar, algılayışın bunun ötesinde olmadığının bir göstergesi sayılabilir.

    Algının değişmesi ile yapılacak güven ve güvenlik odaklı analizler sonrasında, ortaya konabilecek eylemler neticesinde, özgür ve açık kaynak yazılımların yaygınlığı sağlanabilirse, ülke genelinde yazılım dünyasına katkı sağlayacak büyük bir sinerji ortaya çıkabilecektir.

    Bu noktalara ulaşmak amacıyla, orada burada Pardus kullanarak katkıda bulunun demekte, durumun farkında olmamanın bir sonucudur. Zira Pardus kullanarak ve geri bildirim yapılarak bu hedeflere ulaşılamaz. Böylece bir kaç bug (hatanın) kapatılmasını sağlarsınız o kadar. Böylesine ciddi bir meselenin böylesine ciddiyetsiz yaklaşımlara heba edilmesi gerçekten üzüntü verici.

    Burada yazdıklarım kimseye cevap yetiştirme amaçlı değildir, sadece kendimce durumu ortaya koymak istedim.

    Selametle, iyi bayramlar ve iyi geceler diliyorum.



    < Bu mesaj bu kişi tarafından değiştirildi kelebekx3 -- 23 Ağustos 2018; 0:22:38 >




  • Burada enterrsan olan başka bir şey ise. Bu haberi yapan site kendisini bu konuda bilgili olarak tanımlayan bu konularda haber yapan bir site. Milli diyerek haber başlığı açıyor. Ah be dh nerelere düştün.



    Bu site yönetimi bize doğru bilgi vereceğine nasıl inanacağız

    < Bu ileti mobil sürüm kullanılarak atıldı >
  • oktayakgoz kullanıcısına yanıt
    kelebekx3 kullanıcısına yanıt
    Haberin giriş paragrafıdır: "Arif Ergin, 2011-2013 döneminde FETÖ tarafından çökertilen Pardus yapılanmasının Recep Tayyip Erdoğan'ın talimatıyla yeniden ayağa kaldırıldığını söyledi. Başka söze ve yoruma gerek yok. Haberin Linux, yazılım sektörü ve bilhassa Türkiye'nin yazılım alanındaki vahim sorunları ile hiçbir ilgisi yok. "Pardus Yapılanması" ? Seçilen kelimeler dahi siyasi yönelimli. Bu kişilerin yazılım gerçekleri ile ilgisi yok.



    @kelebekx3 Linux sürümü yapan firmaların Linux kernel desteği vermesi veya kernel geliştiriciliği yapması tabi ki beklenmez. örneğin Red Hat çekirdek geliştirmez. Fakat bu konu 'MİLLİ' olmakla ilgili olduğu için Linux kernel 'e katkıda bulunan kaç "milli" geliştirici var diye bakılır. Nitekim baktık ve sıfır cıktı. red hat'ın ülkesi Amerika'da Linux kernel'e katkıda bulunan 100+, almanya'da 100+ geliştirici var. bu ülkelerin Linux'u milli yapmak gibi bir kaygıları olmaz cunku zaten linux'u onlar yapıyor :)

    < Bu ileti mini sürüm kullanılarak atıldı >




  • Selam vede hayırlı bayramlar bende bu milli kelimesine takıldım zira önceki pardustan şimdiki debian tabanlı pardusa tamam debian tabanlı surum geliştiren şu an benim bildiğim 2 işletim sistemi var benim bildiğim Ubuntu ve linux mint ama adamlarda ARGE den bir olay var adamlar sürekli geliştiriyor yuzlerce linux dağıtımın arasında kopyaya yapıştırma yerli olunmaz bu olay nere kadar gider bilmiyorum bence linux değilde bsd tabanlı olsa dağıtım bsd üzerinde geliştirilse çok güzel olurdu freebsd tabanlı şu an benim bildiğim son kullanıcı için 2 tane seçenek var trueos ve ghost bsd keşke bu iki işletim sisteminin yanına Pardus da eklense ben en iyisi (Felsefe) kullanıcını şu yazısını paylaşalım ( Sıklıkla Linux dağıtımları ile *BSD işletim sistemi ailesi pek sık kıyaslanmaz ama genelde yarpılan karşılaştırmalar da "lisans" daha öteye gitmez. Temel olarak Linux dağıtımları ile *BSD işletim sistemi ailesinin ortak noktası kullanıcılara güvenli, kararlı ve kullanışlı bir işletim sistemi sunmayı amaçlamalarıdır. Öte yandan *BSD işletim sistemi ailesi ile Linux dağıtımları arasında önemli farklar bulunmaktadır.Lisans: Linux dağıtımları GPL lisansı kullanır. GPL esas amacı kapalı kaynak kodlu yazılımların diğer yazılımlar ile birlikte kullanılmasını önlemek ve aynı zamanda kaynak kodun açık ve erişilebilir olmasını amaçlar. GPL lisansı genelde derlenmiş ve kaynak kod olarak dağıtılmayan uygulamaları önlemek için hazırlanmıştır. BSD lisansı ise daha az kısıtlayıcıdır. Hatta derlenmiş olarak yazılaımların dağıtılmasına da izin verir. İki lisans arasındaki temel fark ise GPL lisansının yazılıma ait kaynak kodlarında derlenmiş yazılım ile birlikte verilmesini öngörürken, BSD lisansında kaynak kodların dağıtılmasında zorunluluk yoktur. Buna kaynak kodunuzda değişiklik yaparak, farklı bir yazılım üreten kişi veya kişilerin de değişiklik yapılmış olan kaynak kodu dağıtmalarını zorunlu kılan bir hüküm içermez.Kontrol: *BSD işletim sisteminin kaynak kodları herhangi bir kurum veya kişi tarafından kontrol edilmez. Bunun aksine olarak Linux çekirdeği tek bir kişi tarafından Linus Torvalds tarafından kontrol edilir. *BSD  sisteme eklenecek olan bileşenlerin neler olacağına ve olmayacağına "çekirdek ekip" olarak adlandırılan ve belirli bir süre için bu görevi üstlenen geliştiriciler tarafından karar verilir. Bu çekirdek ekip projenin geleceğine yön verir. Dolayısıyla Linux dağıtımlarında tek bir geliştirici bulunurken *BSD işletim sisteminde birden çok geliştirici bulunur.Çekirdek ve İşletim Sistemi: *BSD işletim sistemi ailesinde geliştiriciler tüm bir işletim sistemini geliştirir. Bu işletim sisteminde derleyiciler, kütüphanler, kılavuz sayfaları, kabuklar ve bir UNIX sistemdebulunması zorunlu olan tüm bileşenler yer alır. Linux ise sadece ve sadece çekirdek-kernel olarak geliştirilir. Bir Linux dağıtımı aslında *BSD işletim sistemi ile aynı uygulamaları barındırsalar da sistemi oluşturma süreçleri farklılık göstermektedir.UNIX Türevi: Eski bir bilgisayar özdeyişi şöyledir: "*BSD, bir grup UNIX hacker'ın oturup UNIX sistemi PC aktardıklarında ortaya çıkandır. Linux ise bir grup PC hacker'ın oturup PC için bir UNIX yazmaya çalışmalarının sonucudur. Bu özdeyiş aradaki farkı gayet güzel özetler. *BSD işletim sistemi Linux dağıtımları ile karşılaştırıldığında daha UNIX'varidir. Zira *BSD işletim sisteminin kökleri doğrudan UNIX'e dayanır. Linux ise bir UNIX benzeri olan MINIX esas alınarak geliştirilmiştir.Temel Sistem: *BSD işletim sistemi ile Linux dağıtımları arasındaki farkı kayvrayabilmek için temel sistem kavramının anlaşılması önemlidir. Bir linux dağıtımı için temel sistem olarak tanımlanacak bir şey yoktur. Linux dağıtımları aslında bir çok farklı uygulmanın ve Linux çekirdeğinin bir araya getirilmesi ile ortaya çıkar. Bir çok kişi için ise temel sistem Linux çekirdeği-kernel'dir. Temel sorun ise bir çekirdeğin-kernel'in kullanılabilir uygulamalar olmadan bir işe yaramamasıdır. *BSD işletim sistemlerinde ise temel sistem çekirdek ve uygulamalar olarak bir bütündür ve bu bütün temel sistem olarak sunulur. *BSD sistemde temel sistem ile bir UNIX sistemde çalışabildiğiniz gibi çalışabilirsiniz.Ağırlıklı Olarak Kaynak Kod Kullanımı: *BSD sistemlerin geliştirme sürecinin etkisi olarak *BSD işletim sisteminde uygulamalar port ve pksrc yararlanılarak kaynak kod kullanılarak kurulur.  Hem ports hemde pkgsrc için derlenmiş ve hazır paketlerin oluşturulması olanaklı olsa da yaygın oalrak kaynak koddan kurulum yapılır. Bunun olumlu ve olumsuz yanları kullanıcının tercihine göre değişir. Eğer "kullanıcı dostu" olan sistemleri tercih edenlerdenseniz, ve özellikle de yeni kullanıcılar söz konusu olduğunda caydırıcı olacaktır. Öte yandan kaynak koddan derleme yaparak kurulumu gerçekleştirmek kütüphaneler, paketler ve sisteme özel yapılandırma gibi özellikleri hazır derlenmiş paketlştre göre dahacazip kılmaktadır.Terfiler ve Güncellemeler: *BSD sistemlerin geliştirme sürecini dikkat aldığımıda (Bkz: Madde 5) teme lsisteminizi kolaylıkla kaynak koddan derleyerek en güncel sürüme terfi edebilirsiniz. Bunun içinm de bir kaç komut kullanmak yeterli olacaktır. Bu durumda temel sistemi güncellemiş olursunuz. Diğer biileşenlerin ise ayrıca güncellenmesi gerekebilir. Linux için ise dağıtım ile sunulan paket yönetim sisteminin kullanılması gerekecektir. Böylelikle tüm paketler bir üst sürüme terfi edilmiş olacaktır. Bu durumda Linux'un paket yönetim sisteminin daha iyi olduğu ileri sürülebilir ama teoride olması gerektiği ileri sürülse de pratikte olmadığına, sistemin yeni sürümün sıfırdan kurulduğuna sıklıkla tanık olduğum iöçin *BSD işletim sistmelrinin güncellenemsi ve terfi edilmesi bana daha kolay gelmektedir. freeBSD 6.3'den bu güne dek terfi edilerek gelen bir FreeBSD-8.1 sistem kullanıyorum :)En Son Sürüm Yazılımlar: Bir *BSD işletim sistemini kullanırken bir çok yazılımın en son sürümünün kullanıldığına pek rastlamazsınız. Eğer bozuk değilse, bırak öyle kalsın diyenlerdenseniz *BSD işletim sistemi ailesi sizin için ideldir. Öte yandan esn son çıkan yazılımları kullanmayı tercih ediyorsanız bu tercihinize uyan bir çok Linux dağıtımı bulabilirsiniz.Donanım Desteği: Genel olarak bakıldığında Linux donanım desteği açısından *BSD ailesi ile karşılaştırıldığında daha üsütün durudmadır. Bu *BSD işletim sistemi ialesinin Linux dağıtımları kadar çok donanım desteklmediği anlamına gelmez. tersine Linux donanımları *BSD ailesinden daha önce desteklemeye başlayacaktır. Dolayısıyla daha dün piyasaya sürüne donanımları kullanan hzılı kullanıcılardan iseniz Linux sizin için öncelikli olmalıdır.Kullanıcı Profili: Bilgisayar kullanıcıları arasında bir genelleme yapmak ve sınıflandırmak kolaya kaçmak olsa da aslında istisnaları çıkardığınızda yanılgı payınız son derece düşük olacaktır. Aşağıdaokuyacağınız sıralama kişisel deneyimlerime ve gözlemlerime dayanmaktadır. Sıralamadan en solda sadece tıklayan ve en sağda ise sistemi en iyi bilen ve kontro leden kullanıcılar ye almaktadır. Bu sıralamda Linux dağıtımlarının kullanıcılaro ortaya yakın ve BSD kullanıcıları daha sağ tarafta yer almaktadır. Kullanıcıların profilleri ile tercih ettikleri işletim sistemleri göz önüne alındığında genellemenin doğruluğu ortaya çıkmaktadır.
    Mac -> Windows -> Linux -> BSD -> UNIX ) KAYANAK: http://bsd-tr.org/discussion/1/bsd-ve-linux-arasindaki-farklar

    < Bu ileti DH mobil uygulamasından atıldı >




  • quote:

    Orijinalden alıntı: lussio

    quote:

    Orijinalden alıntı: asau

    Yav arkadaş, milli işletim sistemi demeyin şuna. Linux ne zamandan beri milli oldu da haberimiz yok. Şunu doğru dürüst tanımlayın. Linux üzerinde yapılan bir çalışma bu. Milli işletim sistemi demek, Winows, Linux, Ios, Android gibi ayrı bir işletim sistemi geliştirmek demektir.

    Çalışmayı desteklemek lazım, ama tanımı yanlış. Milli işletim sistemi yanıltıcı bir tanım. Linux işletim sistemidir adı. Pardus, işletim sistemi değildir. Linux üzerinde yerelleştirilmiş, özelleştirilmiş bir çalışmadır. Yani işletim sistemi Linuxdur, Pardus değil.

    Linux işletim sistemi değil işletim sisteminin çekirdeğidir. Pardus tam manasıyla bir işletim sistemidir. Sizin İos dediğiniz işletim sisteminin çekirdeğide linux. Komik olmayın

    Alıntıları Göster
    ios derken mac os x i kast ettin sanırım




  • WhoiS_AttaCK W kullanıcısına yanıt
    Orada iOS da dese OSX de dese, farketmez, yanlış bilgi cunku iOS ve OSX'in cekirdeği XNU 'dur ve o da Carneige Mellon üniversitesinin geliştirdiğii Mach kernel + BSD kernelin birleştirilmiş versiyonudur , yani Linux gibi açık kaynak kodludur fakat her halukarda Linux'tan farklıdır ve dahası Linux'un ilk ortaya cıktığı 1991'den yıllar önce (BDS kernel 1978, Mach 1985) de ortaya cıkmıştır. fakat arkadaş iOS'un cekirdeği Linux'tur diyor. Ayrıca Pardus'a tam işletim sistemi diyor, orada Pardus'a sıfırdan geliştirilmiş sistem demek istiyorsa o da yanlış cunku Pardus Gentoo ve muhtemelen LFS kullanılarak (t)üretilmiş bir Gentoo türevi, alt sınıf bir sistemdir. Nitekim o şekilde versiyon güncellemek cok teknik bilgi ve zaman gerektirdiği için 2010'lardan itibaren tamamen Debian sistemine geçti, yani bir Debian alt sürümü oldu. Bugün sen benden Debian temelinde yeni bir sürüm iste, yarın sana hazırlayabilirim, ben onu hazırladım diye Milli birşey yaptım diyemem, der isem bu hem milletimi komik duruma düşürmek olur, yapamam. Fakat bazı kişiler sırf siyasi reklam ve propaganda amaçlı yapıyor, teknoloji bu değil, sistem geliştirmek bu değil.

    < Bu ileti mini sürüm kullanılarak atıldı >




  • Pisilinux 2.0 bundan daha bin katlı daha stabil.

    < Bu ileti mini sürüm kullanılarak atıldı >
  • quote:

    Orijinalden alıntı: ddsmurat

    Pisilinux 2.0 bundan daha bin katlı daha stabil.
    windowsa para kazandırmaya devam etmek için pardus gelişimi durduruldu zamanında bir ara çok sevinmiştik ama aynı geliştirici arkadaşlar toplanıp tekrardan pisi linux sistemini geliştirdiler pardus projesi tekrardan ayaga kalkarsa gereksiz yere windowsa abd ye yılda miilyonlarca dolar para kazandırmaktansa ben pardusa geliştirici olarak gönüllü katılırım karşılık bile beklemem yeterki vatanımızın adına olsun it köpek kazanmasın
  • Yerli bir arama motoru vardı ne oldu iş tabi çakma idi değil mi ulan varya
  • pardus wallpaperli windowstur o..pardus olsa duramazsin

    < Bu ileti tablet sürüm kullanılarak atıldı >
  • quote:

    Orijinalden alıntı: ibrahimyldrm

    windowsa para kazandırmaya devam etmek için pardus gelişimi durduruldu zamanında bir ara çok sevinmiştik ama aynı geliştirici arkadaşlar toplanıp tekrardan pisi linux sistemini geliştirdiler pardus projesi tekrardan ayaga kalkarsa gereksiz yere windowsa abd ye yılda miilyonlarca dolar para kazandırmaktansa ben pardusa geliştirici olarak gönüllü katılırım karşılık bile beklemem yeterki vatanımızın adına olsun it köpek kazanmasın

    Alıntıları Göster
    

    2005'te Pardus bir Linux sürümü olan Gentoo kullanılarak yapılmıştır yani Pardus aynen Chrome OS gibi bir Gentoo alt sürümüdür, fakat sıfırdan yapılmış orjinal Linux sürümü olarak tanıtılmıştır. Gentoo ile yapılan bir Linux sürümü orjinal olaral tanıtılabilir yani bugün ben Gentoo ile kendi ihtiyaçlarıma göre bir Linux sürümü yapsam yarın onu 100% orjinal/yeni Linux sürümü olarak tanıtabilirim ve kimse anlayamaz cunku Gentoo ile yapmaktan kaynaklanan biz iz klmıyor yeni sürümde. 2005 Pardus ekibi tam olarak bunu yapmıştır, Gentoo temelli bir Linux sürümü yaparak bunu orjinal işletim sistemi diye tanıtmıştır. Gentoo Temmuz 2000 'de yayınlanmıştr yani Pardus'tan 5 yıl önce, 5 yıldır biliniyor ve kullanılıyordu. Orjinal işletim sistemi yapmak zaten bir Tübitak desteği ile olacak şey değildir, cok daha ötesini gerektirir. Fakat 2011'de Pardus işletim sistemi tasfiye edilip, Debian temelli Pardus'a geçildi neden? Cunku Gentoo ile orjinal görünümli sistem yapmak kolay olsa dahi, Gentoo'yu kullanmak orta üstü / ileri teknik bilgi gerektiriyordu ve 2011 itibarıyla o profile sahip eleman yoktu. Debian'dan yapmak ise cok daha kolaydır. O yüzden eski Pardus sistemini bırakıp Debian'a geçtiler.



    Pardus'un Windows'a para kazandırmak için durdurulduğunu düşünmeniz bu hususları bilmemenizden kaynaklı. 2005'teki Pardus Gentoo kökenli bir Gentoo alt-sürümü olmasına ragmen onu dahi yapabilecek profilde kişi olmadığından, proje sürdürülebilir olmadığından bırakıldı. ABD'ye para kazandırmamak için Pardus, Pisi bunlara zaten gerek yok. herhangi bir Debian sürümünü alın, Türkçe ayarını seçin işte size Türkçe Debian. LibreOffice, Firefox vs tüm kullanıcı programlarının zaten Türkçe desteği var. Önemli olan böyle Tübitak'tan destek kredisi koparma amaçlı şeylerle Pardus Mardus yapmak değil, debian veya başka bir Linux sürümünü gerçekten kullanmak, insanlar onu yapmadğı için Windows ve ABD kazanmaya devam ediyor. Bu bağlamda 2005 Pardus ekibi Gentoo ile insanları ve kurumları kandırmak yerine, insanlar ve kurumların debian linux'u Türkçe olarak kullanmaya teşvik edecek çalışmalar yapsalardı, şu anda belki milyonlarca kişi Linux kullanıyor olur ve Windows 'a bu kadar para gitmiyor olurdu. ancak pardus ekibi, çakma kahraman olmayı ve tübitaktan para kaldırmayı seçti. o yüzden şu anda Windows 'a para kazandırmaya devam ediyor

    < Bu ileti mini sürüm kullanılarak atıldı >




  • paket yoneticisini tekrar pisi yaparlarsa kullanirim belki, onun disinda herhangi bir debian tabanli isletim sisteminden farki yok
  • AngryGamer kullanıcısına yanıt
    

    Gerçek bir Unix kullanıcısı paket yönetici olmadan istediği yazılımı kurabilmeli. Örneğin ben Raspberry Pi'de paket yöneticisi olmadan Nginx web sunucu, pure-ftpd FTP sunucu, PHP'yi paket yöneticisi olmadan kaynak dosyalarından derleyerek kuruyorum. Unix'in asıl esprisi de budur zaten, istediğiniz özelliklerde yazılımı derleyip kurmak.



    Paket yöneticisi ile başkasının derlediği bir şeyi kurmuş oluyorsunuz ki o da gereksiz özelliklerin eklenmesi ile boyutu şişmiş bir yazılım anlamına geliyor ayrıca paket repertuarında çoğu kez istediğiniz ekstra/custom özellikler olmuyor. Power user iseniz eninde sonunda yazılımı kendiniz derlemek zorunda kalabiliyorsunuz.



    Ben şu anda istesem Raspberry Pi 'de çalışacak şekilde Firefox'u bile derleyebilirim, masaüstü Ubuntu sistemimde Firefox 'u Rasppian ARM host-system olacak şekilde cross-compile ile derleyerek (cunku 256MB RAM'li Raspberry'de Firefox derlemeye yetecek güç yok :)



    macOS 'de Homebrew adlı paket yöneticisi cok popüler fakat macOS 'de istediğiniz yazılımı kurabilmek için Homebrew tabi ki şart değil. Benim Mac bilgisayarlarda birçok yazılım Homebrew kullanmadan derleyerek kuruyorum. Unix bu işler için cok uygun. pisi veya başka paket yöneticilerine bu kadar bağlanmak gereksiz.

    < Bu ileti mini sürüm kullanılarak atıldı >




  • Çok az insan var hocam listede sanırım ufak tefek katkıları yazmamışlar yoksa linux cekirdegine 1991 den beri on binlerce kişi katkıda bulunmuştur belki de.

    < Bu ileti mobil sürüm kullanılarak atıldı >
  • Toriko kullanıcısına yanıt
    547 kişilik liste Linux cekirdeğine geçmişte de katkıda bulunanları kapsıyor. Katkıda bulunmak derken gerçek bir ihtiyacı çözen, kod yapısını sadeleştiren, ilerde gerekecek kodları şimdiden oluşturan, kolay çözülemeyen bir sorun veya bir bug'ı çözmek gibi anlamlı şeyler yapan o listeye giriyor ve tahminen o listeyi Linux Torvalds, aynen kod repertuarın eklenecek yeni kodları onayladığı gibi onlaylıyor.



    Linus Torvalds'ın zaten en başarılı yanı bir OS çekirdeği yazmaktan coklişti, bunu yüzlerce kişi ile yapabilmek ve o yüzlerce kişinin kodlarını koordine edebilmek. Nitekim Git 2005'de Linus Torvalds tarafından tasarlanmıştır. Yerli ve milli kampanyası şenliğini kutlayan büyük / küçük şenlikçiler bu ayrıntılarla ilgilenmez onlar sadece şovlarla coşmak ister fakat Linux işinin büyük kısmı Git repertuarına kod eklemek, yama yapmak, değiştirmek, refactor yapmak, kodu test etmek, bug gidermek....bunun gibi şeylerden bihaberdardır şov meraklıları.

    < Bu ileti mini sürüm kullanılarak atıldı >




  • Pardus su an ubuntu debian dan derleme. Orijinal pardus kendi basina bir dagitimdi, yerli isletim sistemi terimini cooook coook daha fazla hak ediyordu ve gayet basarili bir dagitimdi... Ama hic yoktan iyidir su anki hali bile...



    < Bu mesaj bu kişi tarafından değiştirildi OnTEC -- 13 Eylül 2018; 21:14:39 >
    < Bu ileti mobil sürüm kullanılarak atıldı >
  • Ya bırak ya

    < Bu ileti mini sürüm kullanılarak atıldı >
  • quote:

    Orijinalden alıntı: OnTEC

    Pardus su an ubuntu debian dan derleme. Orijinal pardus kendi basina bir dagitimdi, yerli isletim sistemi terimini cooook coook daha fazla hak ediyordu ve gayet basarili bir dagitimdi... Ama hic yoktan iyidir su anki hali bile...
    Alttaki tutorial Gentoo, Linux From Scratch ve Puppy Linux gibi "altyapı" Linux dağıtımlarını kullanarak kendi "ORJİNAL" dağıtımını nasıl yapabileceğini gösteriyor.Sözkonusu dağıtımlar 1999,2000 ve 2003'te yani Pardus'un ortaya çıktığı 2005'ten cok önce cıktı.



    Pardus ekibi bu yöntemi biliyordu. Gentoo, Linux From Scratch ve Puppy Linux ile mecazi anlamda bir gecede bir Linux dağıtımı yaptılar ve bunu aylarca yıllarca çalışıp gerçekten orjinal bir dağıtım yapmış gibi pazarladılar, Tübitak'tan destek kredilerini cebe indirdiler, sonra ödül törenleri için devlet kasasında gezdiler tozdular. Tabi 2005'li yıllarda Internet yeni, Linux 'un adını bile kimse bilmiyor, herkese orjinal Linux yaptık diye yutturdular. 2011'de orjinal denilen Pardus'u bu sekilde Gentoo, Linux From Scratch, Puppy Linux kullanarak güncellemek hem zor olacak hem de ekibin foyası meydana çıkacağı için Debian'a geçtik dediler.



    Buyurun tutorial burada. İngilizce. Ocak 2008'de yazılmış. Bu tutorial'ı Türkçeye cevirip güncellersem, bu tutorial'ı uygulayan herkes kendi orjinal Linux dağıtımını yayınlayabilir, bir bakmışsın yarın 100.000 tane birbirinden farklı Pardus dağıtımı var, Türkiye orjinal Linux dağıtımlarında rekor kıran ülke olmuş!





    How To Roll Your Own Linux - 23.01.2008






    Whether you want to customize Knoppix, re-spin an existing distribution of the open-source operating system,

    like Puppy Linux, or are intent on creating your own package from scratch, we'll walk you through the process.



    DIY: Do It Yourself. That's how Linux got started. A group of volunteers,

    inspired and led by Linus Torvalds, created the greatest DIY operating

    system the world has ever seen. You, too, can create your own Linux

    distribution. Here's how.



    It sounds daunting, and there's a lot that's definitely not for

    beginners. But in terms of what you can learn along the way and what you

    end up with, it's on a par with building your own PC from scratch.

    Granted, as with building a PC from scratch, there are still plenty of

    reasons to buy something off the shelf -- or to grab an existing

    distribution and simply use that. That said, there are a few solid

    rationales for rolling your own distro:



    For education. Sometimes the best way to get to know something

    is just to stick your hands under the hood and get 'em dirty -- with a

    little guidance, of course. There's no guarantee that you'll get to know

    everything, but you will gain a fearlessness about the process of

    learning and a sense of where to go to get answers about something (and

    how to get those answers) that you may not get by simply installing a

    populist's distribution and getting quotidian work done.



    For specific problem-solving or filling a gap. If there's some

    oddball hardware configuration that you want to work with, for instance,

    you can create a customization of a given distribution to work well

    with that hardware. This might be something as simple as adding

    kernel-level support for a given device, or something more elaborate. Or

    maybe you want to create a distribution that fills a very specific

    need. (A while back, I wrote about Hikarunix, a sadly-now-discontinued distribution devoted to Go players; it doesn't get more specialized than that.)



    For fun. I call this the "why not?" rule. Linux exists to be

    tinkered with, so tinker with it, and have a blast. Obviously you won't

    want to trust any production data to a system you're doing such work

    with, but that's no reason you can't have fun with it. And if something

    gets messed up, you can always wipe the slate clean and start over.

    (After all, you're not doing any of this in a production environment,

    right?)





    Caveats



    A few things are worth keeping in mind before you dive in and start rolling.



    Learn a little something about Linux first. Before you attempt

    to create your own custom distro, make yourself at least moderately

    familiar with Linux if you haven't done so already. In short: use it at

    least a little bit. If you don't know the basics, there's little point

    in trying to create a custom distro.



    Have patience and pay attention. Any project of this scope,

    even when automated to some degree, is likely to be long and

    frustrating. Don't expect to get it all done in a day, and be prepared

    to take notes as to what everything does and why.



    Tweak at your own risk. Be mindful that any modifications you

    make could have unexpected repercussions. For instance, if you decide to

    disable kernel support for PC Card devices (perhaps because you're not

    using your custom build on a notebook and don't want to include those

    modules), you'll want to document that in the event anyone who uses a

    notebook and depends on such devices won't be stuck if they use your

    custom build. Even if you don't plan on distributing the resulting

    build, it's still a good idea to document any major functional changes.

    You'd be amazed at what you can forget further on down the line.

    Go with stable over speedy. One of the possibilities you might

    discover along the way is the possibility of using

    compiler optimizations

    to speed things up. This means compiling the source code for your

    distribution's kernel or tool chain to use instructions implemented on a

    specific variety of processor, such as the multimedia MMX / SSE / 3Dnow

    extensions. The bad news is that implementing these optimizations can

    be a flaky affair, and sometimes you don't find out just how flaky until

    you've gone fairly far down into the build process. The default

    compiler flags should work just fine for beginners. As Jim Gifford says

    in the above-linked document, "The fact that I don't have any problems

    compiling everything with [a certain instruction set] doesn't mean you

    won't have any problems either."



    Don't eat your own dog food -- yet. The term "eating your own

    dog food" means using what you create in a quotidian fashion to test how

    good it is. The roll-your-own-Linux version of this sentiment would be

    to use the system you've created as your daily, production system.

    Unless you're working on copies and not original data, this is not the

    hottest idea on the world. Existing, publicly vetted distributions

    already have been given a thorough shakedown by the community and are

    less likely to have showstopper issues. Creating your own distribution

    comes with far less of an assurance that you'll get a given level of

    stability or feature completeness. But sometimes running into such walls

    headlong is a way to learn about them firsthand, if you have the time

    and inclination for it.



    Respin An Existing Distribution



    There are three basic ways to roll your own distribution, depending on

    the scope of what you want to accomplish and the level of technical

    expertise you have to bring to the project. The first, easiest, and

    possibly the most immediately useful to most people, is remastering an

    existing distribution.



    Remastering, or respinning, involves installing a given distribution,

    customizing it, and then recompiling the distribution, modifications and

    all, back into an image file (typically an .ISO). In the last couple of

    years this approach has become much easier thanks to collections of

    community-created tools and scripts to automate the process, so it's

    something that is rapidly becoming a native function for many

    distributions. If you're just getting your feet wet with Linux and want

    to try your hand at creating a modified distribution, this is the best

    place to start.



    One of my most personally beloved distributions, Puppy Linux,

    can be remastered in this fashion in a number of different ways. The

    most basic way to do this is through the built-in Puppy Simple CD

    Remaster script, which recompiles everything in the current live file

    system to a CD. The script will pause and prompt you as it goes along,

    letting you know when and where to make any changes you'd like to apply

    -- e.g., adding hardware customizations to the /etc directory. (Tip:

    Puppy's default file manager (ROX-Filer) lets you explore an .ISO file

    like a read-only directory, so you can peek manually at the results once

    you're done.)





    The Simple Remaster script in Puppy Linux lets you take an existing installation and respin the results out to an ISO file.



    Note that if you want to do this with a hard-drive-based install of

    Puppy, your best bet is to create a "frugal" install of Puppy on the

    hard drive, make whatever changes you want, and then respin that. The

    "frugal" install allows Puppy to coexist with other operating systems on

    the same partition (mainly other Linux installations). It stores the

    entire contents of the Puppy install as five big files, one of them an

    image file that represents Puppy's filesystem. This is as opposed to the

    "full" installation, where Puppy requires a whole partition unto itself

    and writes out all the files conventionally. The Simple CD Remaster

    script will not work properly as-is if you have a full installation,

    although allegedly it can be forced to do so.



    The Simple CD Remaster script is probably the best place to get your

    feet wet, since it gives you some exposure to how all this works in a

    fairly controlled fashion. A more complicated but technically advanced

    approach is the third-party HackyRemaster script. This script takes the

    contents of the Puppy CD or .ISO file, expands it to a working folder

    (which can be hosted anywhere), and lets you make any changes you like

    directly to the file system. Once finished, the whole thing can be

    recompressed and remastered back to an .ISO file.



    Puppy Unleashed

    involves taking a large (1.5 GB) archive of all the available packages

    for Puppy and using that to build a custom distribution. Obviously, the

    downside to this approach is that it requires that you download the

    whole package archive and know a fair amount about what you're tinkering

    with. Another possible starting point with Puppy is

    Empty Crust,

    a heavily stripped down version of Puppy Linux 1.0.7. It's admittedly

    several revisions behind the current version of Puppy when you take it

    out of the box, but still useful for this sort of work.



    I've used Puppy as the major example for remastering/respinning Linux

    because it's one of the simplest, but there are many other major

    distributions that have similar functions. The ever-useful

    Knoppix, the live-CD distribution

    from which many others are commonly built, has a

    walk through

    that describes how to customize Knoppix quite thoroughly, from adding

    or removing packages to customizing the look-and-feel of the system. And

    Ubuntu, too, has a

    method

    for customizing its install CDs, although the tutorial in question

    isn't very automatic -- there are, however, community-written scripts to

    make the job that much easier.



    As a side note, I should mention a clever online tool I encountered for creating your

    own custom distribution: the Custom NimbleX CD builder,

    which generates a custom-assembled .ISO of the tiny-but-useful

    NimbleX distribution.

    It's not as flexible as actually assembling a distribution by hand, but it's still quite useful.



    Linux From Scratch



    The next step up for those who are a little more ambitious about rolling

    their own distribution is Linux From Scratch.



    LFS (as I'll abbreviate it herein) is both a distribution and an online guidebook

    for creating your own Linux distribution.

    The LFS LiveCD,

    which gives you a thoroughly spec'd-out environment for building your

    own Linux installation, includes a full copy of the book itself on the

    CD, and contains the sources you'll need to perform all the builds. It's

    to Linux what Heathkit was to radios and early personal computers.



    LFS assumes that you already have a fair amount of working knowledge of

    Linux. At the very least, you should be able to find your way around the

    command line and follow directions. That said, one of the beauties of

    the LFS approach is that every single command you use to build the whole

    distribution is documented from the inside out, so you aren't just

    blindly following a set of instructions. The implications of everything

    you're doing -- every command, every syntax switch -- are made clear to

    you all along.



    The actual creation of the new LFS Linux system is done by using an

    existing Linux installation, a "host," as an environment in which to do

    the work. Most of the time, you can just grab the LFS Live CD and use

    that, since it includes an environment that's been specifically tailored

    of work and reduces the number of variables that might

    crop up.



    There' some parallels between erecting a building from scratch and using

    LFS to build a Linux distribution, and since it's a metaphor that the

    LFS authors also have employed throughout their book I'll also use that

    as a metaphor when it’s convenient.



    1. Preliminaries. The first several steps are sort of like

    breaking ground and pouring the foundation for a new building. You'll be

    walked through setting up a file system (4 GB or so -- I'd say devote 8 GB or more; space is cheap), grabbing the basic set of packages

    needed to get things running, and setting up a few other prefatory bits

    like the user account you'll be using for most of the LFS work.



    2. The Temporary System. The temp system is a little like the

    scaffolding for the building you're putting up -- it's not the building

    itself, but is essential to erecting it, and it will be removed when we

    no longer need it. The temp system consists mainly of the tool chain

    -- a set of utilities that you build that will in turn be used to build

    the distribution proper, such as the GCC compiler. The tools in the

    tool chain are themselves compiled from source -- a nice way to get some

    crash-course exposure to the concept of compiling from source, which is

    pretty indispensable when dealing with Linux and open-source software

    as a whole.



    3. Building And Booting The System Itself. Here we actually get to begin constructing the distribution proper -- i.e., raising the building. As before, all this work -- like creating the directories

    most commonly used by the system -- will be done "by hand," with

    details along the way about what everything is and why it's implemented

    in this particular fashion. Then comes creating the boot scripts, which

    control the system startup process, making the system bootable, and

    (finally!) starting up your newly created LFS system.



    The project doesn't end there, either. There are several other entries in the LFS "family"

    of distribution-building projects, which you can use as the next step

    up. First and most likely is the appropriately named Beyond Linux From Scratch,

    which delves into the nitty-gritty of customizing just about every

    aspect of your newly created Linux distribution. This is where you want

    to go if you either have ambitions to turn your Linux distribution into

    something more upscale and usable by others, or if you just want to

    learn all the more about what goes into your typical Linux distribution

    (the various X servers, the different command-line shells, etc.)



    Hardened Linux From Scratch

    lets you create a security-conscious version of Linux from the ground

    up, although the project is still somewhat in flux (in their words,

    "This book may be broken in some places, but less broken than before.") Cross Linux From Scratch

    lets you perform the LFS build process using cross-compilation: to

    quote their example, you could build a Sparc toolchain on an x86

    machine, and then use that toolchain on the Sparc to build a Linux

    distribution entirely from source there. This is probably the most

    advanced of the LFS projects, and also the one with the narrowest scope

    of appeal, but still fascinating in its own right and useful if you're

    trying to build a Linux distribution for some exotic brand of hardware.



    Yet another approach to the original LFS construction process is Automated Linux From Scratch,which gives you a high degree of automation for the LFS build process.

    The way this is done deserves some kind of Nobel Prize for cleverness:

    the entire LFS book itself is downloaded, and the script commands in the

    text are extracted and run automatically. This way, it works directly

    from the most recent version of the book, whatever it may be, and can be

    used to build any of the LFS projects listed above. Note that this is

    not a substitute for reading the book; you still need to perform a

    certain amount of work to prepare the system, and have an understanding

    d process to begin with.







    Preparing a Linux From Scratch session via one of the automation

    scripts. This isn't a substitute for knowing how to build a

    distribution in LFS; you still need to know how to conduct the build

    process from beginning to end.



    Gentoo



    No discussion of creating your own distribution from scratch would be complete without at least some discussion of Gentoo.

    Like LFS, Gentoo is built from the ground up using source code, not

    just during the initial setup process but later on down the line:

    packages can be obtained as source and compiled specifically for your

    machine's architecture, on-demand. And because of this, pretty much

    every aspect of the entire system -- the packages used, the

    optimizations used to compile them, and all the rest -- are at your

    disposal.



    That's both the good news and the bad news. Yes, it means you have the

    power to configure the entire system from top to bottom, to make it

    yours in a way almost no other distribution can be fine-tuned -- a

    perfect tool for rolling your own. It also means you have the power to

    totally mess things up, or at the very least get stuck at any number of

    points along the way. Gentoo is definitely for experts only. As a friend

    once put it, "If you have to ask how hard it is, you probably shouldn't

    try it." That said, Gentoo can, and is, used as a production

    environment by the careful and knowledgeable.



    The process for creating a Gentoo system is fairly similar to creating

    an LFS system. First, you obtain one of several possible installation

    CDs, depending on the machine architecture you're working with. The

    32-bit x86 version of Gentoo, for instance, comes on a different CD than

    the 64-bit edition. (Note that the links from here are to the x86

    version of the documentation for Gentoo; you will need to look in a

    different place for other architectures.)







    Starting a Gentoo installation process with the Gentoo Live CD. The

    regular command-line version of Gentoo's install CD will work just fine

    as well, but some people may be more comfortable with a GUI.



    After booting the CD and configuring the network and installation

    partitions, you then download what's called a stage3 archive or stage3

    tarball. The name "stage3" comes from the fact that earlier versions of

    Gentoo required that you go through up to two earlier stages of the

    installation -- bootstrapping the buildchain.

    The stage3 archive contains everything you need to get started as

    quickly as possible for your particular machine architecture without

    having to go through those first two stages.



    The next step involves making use of Gentoo's

    Portage

    package system to assemble the rest of the pieces and bring the system

    up to date. Because Gentoo revolves around source code as closely as

    possible, Portage doesn't grab precompiled packages from a repository --

    it downloads the most recent source code for a given package, compiles

    it "on demand" for the platform you're running on, and then adds it to

    your system. Because compiling can be slow, especially if you're

    compiling a whole system's complement of A-list programs, some major

    applications (Firefox, for instance) are available in a precompiled

    package.



    At this stage you also have the option of tweaking how Portage compiles

    packages, such as what optimizations are applied, although you'll

    generally want to keep this minimal the first time out. A similar amount

    of tweaking can be applied to building the kernel itself, so that

    features like multiprocessor/multicore or PC Card support can be enabled

    or disabled. Again, be warned that trying to tweak everything the first

    time out may only make things worse -- save it for when you've run

    through this whole process at least once with as close to a stock

    s you're planning to use.



    Once you've created the system proper, one of the other key elements you

    may work with to further shape Gentoo is USE flags. These flags, set in

    an environment variable, are used in conjunction with building packages

    -- they let you include or exclude support for specific features from

    various packages as a way to streamline or expand your Gentoo build. For

    ou're creating a system that doesn't need support for X11

    (like a headless server that you're only administering from a command

    line), you can use the -X flag to negate compiling in support for X11.



    To create a system that you will actually be distributing to others, you need to get some experience with a Gentoo tool named Catalyst,

    which is designed specifically for building components of a released

    Linux distribution. The stage3 tarball you installed by hand earlier is

    one of the things you build with Catalyst. It's also possible to

    build a live CD

    using Catalyst as one of the tools to accomplish that

    (or build one from scratch without Catalyst, which allegedly has slightly more flexibility).





    Share And Share Alike



    So what's the next step after creating a distribution of your very own?

    Aside from "eating your own dog food," as described above, you might

    want to share the love: release it to the public.



    It's an optional step, but a hugely useful one, and you may realize that

    the microdistribution you cobbled together has an audience after all.

    If your audience is thoughtful, you'll get valuable feedback on what

    works and what doesn't. And even if you have no intention of releasing

    the distribution broadly, you may learn things that help you improve

    what you're trying to do.



    There's a few ways to get a distribution out there. One of the most common is to submit mention of it to

    DistroWatch,

    probably the single most well-trafficked site that deals with the

    panopoly of Linux distributions out there. As I write this, its

    submissions form is offline pending some reworking, but DistroWatch can

    be contracted via e-mail; also note that it doesn't accept submissions

    for certain types of distributions at all (such as those hosted within

    Windows).



    Actual hosting space for a distribution is another story. SourceForge

    generally doesn't accept hosting for Linux distributions due to the size

    involved, although it can be used to host the bug-tracking or

    discussion lists for such a project as long as the data itself is kept

    somewhere else. Fortunately, Web space has become amazingly cheap as of

    late, although to make the distribution a little less onerous you may

    want to use BitTorrent as a way to offset the bandwidth burden.



    Remember to distribute the source tree as well. I'm assuming for the

    sake of argument that the distribution you'll be creating, and its

    component packages, are GPLed, so remember to also distribute the source

    code. The source doesn't have to be provided in the same package as the

    binaries, especially since the source tree can be quite large; several

    gigabytes isn't unheard of. What matters is that you make it available

    and document that fact, especially if you end up making any changes to

    the source.



    Finally, speaking of documentation, that's something else you may want

    to provide with your new distribution. Whether it's just a simple set of

    README pages or a full wiki, you'll want to take the time to talk about

    what's special about your distro -- quirks you've noticed, things to

    try (or not try!), and ideas for where you're going with it in future

    builds. A distribution is, after all, always a work in progress.

    < Bu ileti mini sürüm kullanılarak atıldı >




  • 
Sayfa: önceki 45678
Sayfaya Git
Git
sonraki
- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.