stali – [Sta]tyczny [Li]nux
14 listopada 2009, blinkkin
Programiści związani z suckless.org pracują nad stworzeniem własnej dystrybucji Linuksa, w której większość aplikacji ma być skompilowana statycznie.
Stali ma być nową dystrybucją Linuksa z ręcznie dobranym zestawem najlepszych programów do każdego zadania i statycznie łączonymi (włączając w to niektóre klienty X jak xterm, surf, dwm, dmenu, mplayer).
Celem jest także redukcja wielkości plików binarnych poprzez nieobecność glibc i innych zbloatowanych bibliotek GNU, jeśli to możliwe (wczesne doświadczenia wykazały, że statycznie dowiązane pliki binarne są zazwyczaj mniejsze niż ich dynamicznie powiązane z glibc odpowiedniki).
Z powodu ubocznego efektu jakim jest szybsze uruchamianie się statycznych binarek, dystrybucja koncentruje się także na uzyskaniu większej wydajności.
Przewiduje się, że pierwsza działająca wersja zostanie wydana w listopadzie 2009 roku.
Główne założenia projektu:
- Pliki binarne są głównym priorytetem, każdy plik wykonawczy jest statycznie łączony. Potencjalnie inny format wywołań niż ELF, ponieważ ELF został stworzony głównie z myślą o dynamicznych powiązaniach.
- Jądro jest pojedyńczym monolitem bazującym na Linuksie, standardowo jądro nie obsługuje modułów
- Program rozruchowy to lilo (twórcy stali zastanawiają się nad rozwojem lilo)
- Początkowo brak initrd
- Być może ładowanie całego systemu do pamięci RAM?
- Inicjalizacja systemu powinna opierać się tylko o jeden skrypt /etc/rc.{start,stop}
Wygląd systemu plików:
Katalog /usr zostanie usunięty, ponieważ według twórców jest bezużyteczny, aplikacje niezwiązane z podstawowym systemem być może znajdą się w katalogu /local.
- /bin – wszystkie pliki wykonawcze
- /bin/kernel – jądro Linuksa
- /dev – urządzenia, być może z pominięciem udev i innych rozwiazań używanych obecnie w Linuksie, im prościej tym lepiej
- /etc – konfiguracja systemu, aplikacji, sieci, użytkowników
- /etc/rc.{start,stop} – skrypt startowy
- /home/root – katalog roota
- /home/* – katalogi użytkowników
- /include
- /lib – biblioteki używane na platformie deweloperskiej, potencjalnie statyczne
- /local – być może?
- /mnt
- /proc – procesy
- /share – strony podręcznika man, lokalizacje
- /sys
- /tmp – pliki tymczasowe
- /var – cache, logi, spool i run
- /usr -> / (prawdopodobnie miękkie dowiązanie z powodu niedziałających aplikacji)
Aktualizacja systemu polega na synchronizacji przez rsync z serwerem dystrybucji.
Typowy system końcowego użytkownika:
[anselm@x200s rootfs]$ tree
.
|-- bin
|-- dev
|-- etc
|-- home
| `-- root
|-- mnt
|-- proc
|-- sys
|-- tmp
`-- var
Notatka: Na hoście końcowego użytkownika nie znajdziesz katalogów /lib, /include etc. Potrzebuje on tylko tego co naprawdę jest wymagane i nic poza tym.
Rozwój:
Postępy prac nad stali można śledzić pobierając najnowsze źródła używając komendy:
git clone git://sta.li/stali
Wielkość ok. 1,2 GB.
Warto też zapoznać się z najczęściej zadawanymi pytaniami, niektóre odpowiedzi wyjaśniają decyzję podjęte przez twórców stali.
Po stworzeniu przeglądarki surf, panowie z suckless postanowili stworzyć własną dystrybucję. Stali będzie prawdopodbnie opierać się głównie o ich pozostałe projekty i aplikacje zgodne z ich założeniami.
Co ciekawe grupa suckless.org pracuje obecnie nad nowym klientem poczty, na liście mailingowej była też mowa o edytorze dokumentów, organizerze i kilku innych narzędziach. Większość aplikacji w dystrybucji będzie zapewne spod znaku CLI.
Projekt mnie zainteresował, bo większość pomysłów jest przeciwne względem głównego nurtu. Pozostaje trzymać kciuki i czekać na owocne mam nadzieję wyniki.
btw. Wyszedł mi ciut długi artykuł, być może po dopieszczeniu bardziej nadawałby się na stronę jakilinux.org niż linuxnews.pl.
Zapomniałem wspomnieć też o zależnościach, które w wielu przypadkach po prostu znikną. Wersji poszczególnych elementów systemu też prawdopodobnie nie trzeba będzie pilnować – teoretycznie nic nie stoi na przeszkodzie, żeby korzystać z kilkuletniej binarki na świeżo postawionym systemie.
Z tych powodów większość możliwości oferowanych przez menedżery pakietów jest zbędna. Być może stali nie będzie miała żadnego lub będzie on bardzo prosty.
Usunięcie instytucji managera pakietów, to podejście trochę windowsiowe. Nawet, jeżeli nie będzie potrzeby dbania o zależności, to instalacja wszystkiego z jednego miejsca jest zwyczajnie wygodniejsza niż szukanie osobno każdego programu, z którego będzie się korzystać. Szczególnie, jeżeli mając managera pakietów można wyszukać w dostępnym zbiorze oprogramowania zdolnego do (…)
Przydałby się menedżer, który by kompilował ze źródeł program do wersji statycznej. Jeżeli założeniem jest udostępnienie tylko przygotowanych aplikacji to projekt się nie uda.
Ciekawe. Zobaczymy jak wyjdzie.
Pewnie będzie grube.. Zamiast 2GB będzie 10GB w imię windows-like statyczności. Użytkownik innej dystrybucji zainstaluje i będzie się dziwił co tu tyle zajmuje miejsca. ;D
pliki sa wykonawcze, czy wynonywalne?..
A cholera go wie? Ostatnio rzadko czytam fachową literaturę w języku polskim. Wiele rzeczy bym prawdopodobnie nie tłumaczył, bo “zazwyczaj myślę po angielsku”, jeśli chodzi o żargon informatyczny.
Wolę zostawić tę sprawę polonistom (może się tutaj jakiś znajdzie) i dostać opierdziel, jeśli popełniłem jakiś błąd. Sens przekazanej treści chyba pozostał, więc nie jest źle.
nie bardzo. mi sie wydaje, ze executive to wykonawczy,
executable — wykonywalny. poza tym, kto mowi o opierdzielu? ; )
wykonawcze- (wg mnie) cos jak włądza wykonawcza (dopowiedz sobie sam)
zaś wykonywalne to które można wykonać
ja nie musze sobie dopowiadac, po prostu razi mnie
dlatego zwrocilem uwage i zarobilem 3- : )
Pierwsza wielka innowacja od czasow GoboLinuksa.
Subiektywnie patrząć Tiny Core Linux wydaje mi się sporą innowacją, jeśli chodzi o świat Linuksa. Instalacja typu frugal została podniesiona do zupełnie nowego poziomu.
Zresztą TCL jest moim osobistym zdaniem pierwszą dystrybucją, w której instalacja frugal jest warta świeczki.
Wkradł mi się drobny błąd w tytule newsa. Początkowo miał on brzmieć “stali – dystrybucja [Sta]tycznego [Li]nuksa”, później to zmieniłem. Niestesty “ks” zamiast “x” zostało w nazwie Linux :/ (kolejny raz cicha prośba do redaktorów serwisu).
Odnośnik do suckless.org też ucieło – niepoprawny adres
Widocznie zbytnio spieszyłem się z publikacją tego newsa…
Słuchałem niedawno audycji lingwistów w dwójce (PR) i jak byk jest konsensus, że jest już prawidłowo odmieniać wyrazy z x-em zarówno przez “x” jak i przez “ks”. Przykro mi, że w ten sposób czepliwi (włącznie ze mną) będą mieli jeden powód mniej do mędzenia.
Ja tylko wplotę delikatny akcent humorystyczny: jeśli z nazwy Linux zabraliby jedną literkę więcej, to byłby:
Stalin
Fajnie by to brzmiało w newsie, przykładowo: Twórcy Stalina
Ciekawe czemu sam tego nie zauważyłem? W każdym razie wyszło całkiem zabawnie, chociaż słowo Stalin powinien kojarzyć się bardzo negatywnie. Może w logo umieszczą jakiś akcent – młot lub sierp?
Bierut: a tu mamy Pl. Zbawiciela
Stalin: o.. przesada..
Będąc przy kawałach.
Richard Stallman, Linus Torvalds, i Donald Knuth zaangażowali się w dyskusję, kto wywarł największy wpływ na informatykę.
Stallman: “Bóg mi powiedział, że stworzyłem najlepszy na świecie edytor!”
Torvalds: “Ano, Bóg mi powiedział, że stworzyłem najlepszy system operacyjny na świecie!”
Knuth: “Zaraz, zaraz, nigdy tego nie powiedziałem.”
Koniec OT.
Była dokładnie taka propozycja (stalin) w czasie dyskusji na #suckless o nazwie projektu. Na szczęście została zflame’owana i stanęło na stali. Później już okazało się, że domena sta.li jest wolna (wstępnie przeznaczona i zarezerwowana na projekt była stali.org, o ile pamiętam).
[a]
To jest prawdziwie ciekawy news
Do głównego wątku dorzuce że podobną drogę rozwoju wybrali twórcy – opensolaris for arm i AuroraUX . Czyżby ten system miałbyć celowany w urządzenia wbudowane ? TAM się nadają takie rozwiązania dające szybkość i stabilność , przy dodaniu zarządzania Real-Time to może być wręcz ideał do takiego typu urządzeń .
Więc czekam na dalszy rozwój tej dystrybucji
“Organizacja” suckless.org jest silnie związana z systemem http://plan9.bell-labs.com/plan9/ (narzędzia przez nich stworzone czerpią inspiracje garściami z tego systemu). Warto przejrzeć następujące strony:
Suck Less Manifest – zainteresowanym polecam też lekturę na temat menedżerów okienek
The Duct Tape Programmer
Harmful Stuff – bardziej szczegółowy opis niektórych “złych” aplikacji znajdziecie w menu po lewej stronie
Project Ideas for Future GSoCs – co panowie z suckless.org planują?
The Rise of “Worse is Better”
W większości pokrywa się to z filizofią tejże organizacji. Czego można się spodziewać po stali (prywatne przypuszczenia)?
Proste narzędzia, które spełniają jedną funkcję, czyli pozbycie się z systemu kobył.
Powolne usuwanie autohell – programiści z SL nienawidzą narzędzi automake i autoconf.
Kod systemu (przyp. userland) wolny od “ciężkich” obiektowych języków programowania, czyli pozostaje czyste C i Go*.
Brak “magików” i konfiguracji w postaci XML/SGML – konfiguracja w postaci czystego tekstu lub bezpośrednio w kodzie źródłowym
Dokumentacja w postaci stron podręcznika man.
Wymiana userlandu GNU na inne narzędzia (tcc zamiast gcc, ulibc/bionic zamiast glibc, pdksh/ash/dash zamiast basha etc).
Licencja MIT, gdzie to możliwe.
* Jeden z programistów przepisuje dwm w języku Go.
Co do dynamicznego linkowania to ludzi z SL uważają, że sposób jego użycia został wypaczony. Mówią tak dynamicznemu ładowaniu, ale pokazują wyraźną niechęć wobec współdzielenia bibliotek etc.
btw. Miałem zamiar opisać kafelkowe (tiling) menedżery okienek na przykładzie narzędzi stworzonych przez suckless.org: dwm, wmii, dmenu. Jest to bardzo ciekawy temat, bo coraz większe monitory i/lub kilka ich sztuk sprawiają, że prawo Fittsa przestaje działać. Jest to problem biorąc pod uwagę, że większość współczesnych interfejsów zostało stworzone w oparciu o tą tezę.
Po rzuceniu okiem na te linki wiem już, czemu Plan 9 to niszowy system
Poważnie, goście robią wrażenie pr0 którzy jako jedyni na świecie wiedzą jak to jest “doing it right”. Z linków które podałeś:
Czyli to co ONI napiszą jest “simple and elegant”, w przeciwieństwie do całej reszty z “over-ambitious features”. O ja niegodny.
Ale nie oni, oczywiście.
Najlepszy jest jednak ten spis software’u, że wymienię kilka “harmful things”: XML, C++, Qt (tu jako alternatywa widniało “textual interfaces”), SQL. I dopisek:
Oh yeah kid, you’re so fscking clever.
Plan 9 nie przyjął się z wielu powodów (licencja, słabe wsparcie i prawdopodbnie gorszy, ale sprawdzający się w swojej roli system – pochodne Uniksa). Jednak wiele z jego koncepcji zostało przeniesionych do innych systemów
Wszystkiego nie che mi się wymieniać, najświeższy przykład to język programowania od Google, czyli Go. Wystarczy spojrzeć kto go spłodził (Rob Pike, Ken Thompson), na jakiej platformie był początkowo rozwijany (Inferno) i czym był inspirowany (Limbo).
Projekty suckless nie każdemu odpowiadają, jednak mają swoich wiernych użytkowników. Każdego rusza co innego, jedna osoba zachwyci się efektami compiza/beryla, druga prostym skryptem powłoki.
Zapewne mam podbne podejście do całej filozofii GNU jak ty do zawartości odnośników, które podałem. Ot zwykłe poglądy na dany temat.
Wszystko jest dla ludzi. W domciu na lapku używam – dla wygody gnome. Jak jestem poza domem (czyli na baterii), odpalam system na innym inicie (wyłączona połowa usług “stacjonarnych” – np. cups, bluetooth), w konsoli używam dvtm a na nim fincha, moc, elinks. Jeśli potrzebuję środowiska graficznego – uruchamiam dwm. System zużywa mniej zasobów, a ja nie muszę męczyć się touchapadem, gdyż 90% czynności mogę wykonać z klawiatury (mógłbym 100% ale vimperator to nie moja półka
)
- “Powolne usuwanie autohell – programiści z SL nienawidzą narzędzi automake i autoconf.” – tylko jak na razie nie ma dobrej alternatywy – zazwyczaj czegos brakuje. Wiekszosc problemow zreszta wynika z niepoprawnego pisania skryptow
- “Kod systemu (przyp. userland) wolny od “ciężkich” obiektowych języków programowania, czyli pozostaje czyste C i Go*.” – hmm. Jesli nie ma powanych problemow z predkascia to nazwalbym to zlym nawykiem przy programowaniu..
- “Brak “magików” i konfiguracji w postaci XML/SGML – konfiguracja w postaci czystego tekstu lub bezpośrednio w kodzie źródłowym”. Jesli chodzi o XML/SGML to OK. Co jednak nalezy rozumiec przez “magika” – automatyczna konfiguracje? Jesli tak to IMHO jest to zle rozwiazanie
Pewnie wizardy.
Tzn. zamiast mi X11 ładnie wykrywać karte intela, mysz etc. (bez potrzeby posiadania /etc/X11/xorg.conf) mam wydawać X -configure czy podobnie? Rozumiem – automatyczna konfiguracje nalezy czasem poprawic ale jak ESR pisal – system powinien wykrywac to co da sie wykryc (“UNIX. Art of programming” rozdzial o plikach konfiguracyjnych).
To miłe. Zniknie upierdliwość pt. “jak chcesz mieć najnowszą wersję programu, to musisz zaktualizować 3/4 systemu jako zależności”.
Tak, tak, wiem, że dystrybucje kompilowane ze źródeł tego problemu nie mają, ale kompilowanie sobie np OpenOffice.org jest, hmmm, czerstwe.
Przecież od dawna jest instalator OpenOffice. Ja nie miałem problemu z nim, lecz tylko raz go testowałem. Wiele innych programów też ma swoje instalatory lub są udostępniane w wersji portable.
@Sławek: wiem, że jest
OO.o jest taką alegorią Dużego I Przeraźliwie Długo Się Kompilującego Programu. Możesz tam sobie wstawić dowolny duży program mający dużo zależności. Najlepiej coś zależącego od KDE.
Swoją drogą OO.o instaluje się podobnie jak to jest przyjęte na Makach — ma swoje zależności wpakowane w paczkę i już (o ile pamiętam w czasie instalacji go na gentoo kompilowała się jego własna kopia pythona i glibca, ale to było parę lat temu, więc może się coś zmieniło).
Z Gentoo staraja sie wyrzucac ‘wlasne wersje’ bo powoduja problemy przy updatach. Tzn. trzeba znalezc i zalatac wszystkie takie biblioteki a nie skopiowac ebuild. Jak jest w OOo to nie wiem.
No właśnie. Jeżeli pójdziemy drogą zbliżoną do Windows czy też(jak w tym wypadku) bardziej przesadną, to wywołamy ogromne problemy z aktualizacjami i nigdy nie będziemy mogli czuć się bezpiecznie.
Dodam jeszcze, że z tegóż powodu dystrybucja powinna mieć też menadżer paczek/pakietów i jakieś podstawowe biblioteki, jednak aplikacje dołączone z nią nie koniecznie muszą z tego korzystać.
PS:
Zastanawiam się dlaczego /usr/lib/nazwa_paczaki się nie przyjmie? System mógłby sam dociągać brakujące biblioteki, jednak pakować je do tamtego miejsca.
A ja z ciekawości spytam, czy taka statyczna binarka odpali się na każdym linuksie czy tylko na tym?
Jeśli chodzi o statyczne binarki ze stali to prawdopodobnie nie, ponieważ w tej dystrybucji zostanie zmieniona hierarchia katalogów i zostanie użyty inny system wywołań niż ELF (starusienki a.out?).
Natomiast z tego co mi wiadomo wiele mniejszych dystrybucji przepakowuje pakiety z Slackware’a. Powodów jest kilka – paczki nie są mocno rozdrobnione, są dosyć “czyste” (skompresowane archiwum bez zbędnych informacji) i zostały skompilowane bez udziwnionych flag. Kilka osób tworzyło w ten sposób rozszerzenia dystrybucji Tiny Core Linux, nie wiem czy tak jest nadal.
sama binarka sie odpali – to ze program moze potrzebowac costam z drzewa katalogow to juz inna sprawa. Wiele programow nie potrzebuje nic poza samym soba + bibliotekami (ktore w tym przypadku zawieraja sie w nim).
praktycznie tak, pod warunkiem zgodnosci architektury….
…oraz zgodności na poziomie sys-call’i. Nie pamiętam już kiedy, ale gdzieś tam po drodze przesiadka na nowszych kernel wymagała zmiany glibc’a (chyba przesiadka z serii 2.4.x na 2.6, ale nie jestem pewien). Tak czy inaczej, taka binarka jest zgodna z systemem tak długo, jak długo nie zmienia się interfejs samego kernela, czyż nie?
W sumie to nie do końca rozumiem całą inicjatywę. Biblioteki dzielone i dynamiczne linkowanie nie powstały przypadkiem. Binarki się szybciej ładują, no pięknie, ale każda binarka ciągnie za sobą swoją kopię tego samego kodu bibliotek, zamiast grzecznie dzielić z innymi strony pamięci z tymże kodem. Jak dla mnie pomysł statycznego linkowania wszystkiego jest przynajmniej dziwny.
Przypomina mi to zasadę na jakiej opiera się oprogramowanie na Windows. Tam wszystko jest statycznie kompilowane i chyba nie ma współdzielonych bibliotek itp.
Często zwolennicy Windowsa (i pewnie nie tylko) używają argumentu, że lepiej mieć wszystko kompilowane statycznie zamiast współdzielić biblioteki. Teraz będzie można porównać oba podejścia w miarę obiektywnie (ten sam system, te same programy) i zobaczyć co sprawdza się lepiej. Jeśli sprawdzi się Stali to pewnie więcej użytkowników przesiądzie się na ten system i to on stanie się “główną gałęzią” (ewolucja) a jeśli będzie odwrotnie to “linuksiarze” będą mieć jeszcze jeden argument przeciwko “windowsiarzom” i wybuchnie kolejny wielki flamewar. Tak czy inaczej będzie ciekawie
W windowsie też są przecież współdzielone biblioteki. To, że aplikacje dostarczają własne statycznie, bądź nie statycznie kompilowane biblioteki wynika z tego, że w windowsie nie mamy menadżera pakietów, który dbałby o zależności. Każdy program ma swój niezależny instalator. Więc fakt ten nie wynika z konstrukcji systemu, tylko raczej ze sposobu instalacji oprogramowania.
Ależ ma, tylko z reguły każdy program trzyma swoją kopię biblioteki (plik dll) we własnym katalogu. Co nie zmienia faktu, że linkuje do niej dynamicznie. Bibliotekę można też umieścić w %SystemRoot%\system32, wtedy będzie wspólna (i to jest różnica między Windowsem a UNIX-like, gdzie standardowe jest to drugie rozwiązanie).
Oczywiście występują też programy linkowane statycznie, ale żadna z tych platform takiego linkowania nie narzuca (ani też nie zabrania).
No właśnie, że w Windowsach nie za bardzo tak można i programy trzymają swoje kopie raczej z przymusu. Mianowicie w Windowsach brak jest menadżera pakietów, a jednym z największych problemów, kłopoty z kompatybilnością różnych wersji dll. Nie zawsze programy chcą chodzić na nowszej wersji dll i dochodziło do prawdziwych wojen aplikacji na podmienianie/przywracanie wersji dll i wynikające stąd “gryzienie” się aplikacji i omija się to umieszczając konfliktowe dll w katalogach własnych aplikacji… Oczywiście i w otwartych systemach są kłopoty z aplikacjami niedziałającymi na bibliotekach w nowszej wersji, ale z uwagi na otwarte źródła jest to szybciej usuwane, a z uwagi na sposób dystrybucji, łatwo pobrać aktualną wersję. Tymczasem komercyjne firmy po sprzedaży często klientów mają gdzieś (zwłaszcza w parę lat po zbyciu produktu) albo tak pozabezpieczają produkt przed kopiowaniem, że po zmianie wymagałby nowych kluczy sprzętowych czy płytek instalacyjnych i firmom nie uśmiecha się wysyłania tego na swój koszt do klientów. Dlatego własne kopie dll w Windows to często konieczność (ze wszystkimi wadami tego rozwiązania).
Dlatego napisałem “można”. Jakby nie patrzeć, możliwość taka jak najbardziej istnieje
@Artwi: “a z uwagi na sposób dystrybucji, łatwo pobrać aktualną wersję.” — drobne sprostowanie: nie aktualną wersję, tylko najnowszą, jaką opiekunowie Twojej ulubionej dystrybucji wpakowali do repozytorium. Często jest to wersja kilka numerków niższa, niż aktualna.
akurat jeśli chodzi o Windows, to tak wielkiego problemu z bibliotekami dynamicznymi już nie ma. Rozstrzał wersji bibliotek systemowych (siedzących w %windir%/system32) dla developera jest zazwyczaj zupełnie pomijalny. Do komercyjnych aplikacji na Windows dołączane są zazwyczaj w instalatorach ms-owe package z runtime-m C/C++ od konkretnej wersji VS, które są (o ile już ich nie ma)instalowane w systemie – ale nie nadpisują innych wersji – a instalowane są ’side by side’ – co w praktyce znaczy, że kilka wersji runtime’ów jest dostępne dla aplikacji – w pliku konfiguracyjnym linkera podajemy jaka nas wersja interesuje, lub robimy redirecta na inną konkretną/najnowszą.
@Artwi tylko, że w czasie gdy w Linuksie powstaje zazwyczaj 20 wersji nowszej biblioteki, w Windows powstaje jedna stabilna wersja. Jest po prostu mniej kolejnych wersji bibliotek. Poza tym autorzy bibliotek z reguły dbają o to, żeby nowa wersja była binarnie kompatybilna ze starą.
Problemem pod Linuksem jest brak ujednoliconej dla wszystkich dystrybucji listy stabilnych w danym momencie bibliotek.
koledze chodziło o mac os chyba
Że niby na Mac’u wszystko jest linkowane statycznie? Od kiedy?
nie tyle kompilowane statycznie co każdy zewnętrzny program korzysta ze swojej kopii bibliotek z którymi jest dostarczony, odpadają zależności, ale za to pliki instalacyjne są 2 razy większe. Czy są linkowane statycznie czy dynamicznie nie wnikam.
> Przypomina mi to zasadę na jakiej opiera się oprogramowanie na Windows.
> Tam wszystko jest statycznie kompilowane i chyba nie ma współdzielonych
> bibliotek itp.
Wiesz co piszesz, czy po prostu piszesz co wiesz?
Podoba mi sie idea statycznie skompilowanego distro: pojawia
sie bug w OpenSSL, zmiast podciagnac 100kB dynamicznej biblioteki
targam 50MB wszystkich pakietow ktore jej uzywaja.
z drugiej strony: dostarczam klientowi aplikację, czy ich zestaw. bazuje to to na openssl (czy jakiejkolwiek innej bibliotece). i co jak znajdą dziurę w tym openssl?
- trzeba zadbać, by system (a nie tylko moja aplikacja) była zgodna z nową wersją (!)
- jak sobie klient przeinstaluje system, to musi pamiętać, by wpierw zaktualizować tego openssl’a, bo moja aplikacja może nie działać ze starym (!)
czy statycznie, czy dynamicznie, to kwestia do czego tego chcesz stosować. dostarczam kilku klientom trochę softu i wszystko jest linkowane statycznie. to kwestia wygody – klient dostaje nową wersję binarki i nie musi sprawdzać, czy 1500 bibliotek jest w wersjach, z którymi zadziała.
w domowym kompie wolę (tak jak mówisz) zaktualizować jedną bibliotekę i zapomnieć. do klienta wolę nie jeździć za często na ‘awarie’ – bo to przede wszystkim __cholernie__źle__ wygląda z biznesowego punktu widzenia, jeśli z Twoim softem są jakiekolwiek problemy.
takie moje 0,02PLN
Najlepiej dostarczac klientowi zrodla + wsparcie.
Jesli naprawde masz tak duzo softu, na dodatek krytycznego – to zazwyczaj wsparciem obejmuje sie tez system na ktorym dziala. Nie wyobrazam sobie sytuacji w ktorej klient sam podejmuje sie konserwacji krytycznego systemu, czy jego aktualizacji. Jesli jestes producentem oprogramowania rozprowadzanego publicznie – musisz dbac o jego aktualizacje i zgodnosc z aktualnymi wersjami systemu na ktorym ma dzialac. Biblioteki dzielone nie sa zle same w sobie. Ulatwiaja zarzadzanie systemem, prace developerskie a przedewszystkim wykrywanie bledow i ich usuwanie. Te kilka procent wydajnosci, ktore zyskaja, maja sie nijak do nakladu pracy jakim sie obloza. Jesli tego chca, ich sprawa,
Z drugiej strony – jesli jestes producentem oprogramowania, nic nie stoi na przeszkodzie rozprowadzac go w postaci statycznej, z uwzglednieniem kilku wersji libc, architektur. Lepsze to, niz wymuszac na kliencie przejscie na stali.
System pakietowania oprogramowania jest z założenia przystosowany bardzej do softu Open Source niż komercyjnego. Programy OS są dostarczane zwykle przez producenta dystrybucji systemu i ma on pełną kontrolę nad wersjami pakietów u użytkowników – może więc zadbać o ich wzajemną kompatybilność. W przypadku softu komercyjnego (przy czym mam na myśli raczej oprogramowanie sprzedawane masowo niż tworzone na zlecenie), klient może go sobie zainstalować niemal na dowolnym systemie z niemal dowolnymi wersjami bibliotek. Dodatkowo, multum dystrybucji uniemożliwia stworzenie sensownych pakietów instalacyjnych.
Podsumowując: dla programów FLOSS system pakietów jest rozwiązaniem najlepszym, w dodatku sprawdzającym się od dawna. Producentom oprogramowania komercyjnego zostaje niestety linkowanie statyczne, własne instalatory oraz własny system aktualizacji. Czyli to samo co na Windzie :/.
Wniosek: dostarczanie zależności wraz z programem, własne instalatory oraz brak pakietów nie są wadą własną Windowsa, lecz wynikają z faktu komercyjnej dystrybucji oprogramowania.
@vshader: ślicznie ubrałeś to w słowa!
@y0g1: “Najlepiej dostarczac klientowi zrodla + wsparcie” – dlaczego najlepiej? dla kogo najlepiej? przy jakich ‘założeniach’?
to co proponujesz _nie_zawsze_ musi być najlepszym rozwiązaniem.
zgadzam się za to z tym co nazwałeś ’softem krytycznym’ – tutaj nikt poza mną nie może się dotknąć do kompa. ale istnieje też soft użytkowy, nad którym pieczę (czasem) ma klient. taki soft nie może (lub też: nie powinien) źle chodzić…
Cczy ja dobrze rozumiem? Załóżmy, że aplikacja X korzysta z biblioteki Y, kolejna aplikacja Z korzysta też z biblioteki Y, w takim razie biblioteka Y będzie w tej dystrybucji ładowana 2 razy przez obie te aplikacje, skoro jest linkowana statycznie? Tzn, większa wydajność kosztem większego zapotrzebowania na pamięć?
Proszę o sprostowanie jeśli się mylę.
Tak, jest dokładnie tak, jak piszesz. Oczywiście jak biblioteka jest dobrze napisana, to statycznie się zlinkują tylko jej używane fragmenty, bo resztę linker może wyciąć, więc narzut nie jest dokładnie x2.
Uzupełnienie. Biblioteki docelowo będą tylko potrzebne, jeśli zajdzie potrzeba skompilowania jakiejś aplikacji. Można tu mówić o środowisku deweloperskim.
Natomiast maszyny produkcyjne w założeniu będą działały bez katalogu /lib i /include. Nie ma takiej potrzeby ponieważ wszystko będzie kompilowane statycznie, czyli bez współdzielenia bibliotek.
Ciekawe ile zajmowałbym np. taki Amarok zrobiony w ten sposób. Plik wykonywalny 200MB? Pół Qt i KDE wkompilowane?
jeżeli wkompilowane są nie całe biblioteki, a jedynie części tych bibliotek wykorzystywane przez aplikację, to może nie było by tak źle.
Tylko należy to przemnożyć przez ilość aplikacji. Bo w koncu nie tylko Amarok jest w pamieci ale także Kwrite/Konsole/Kwin czy co tam jest w KDE/panel KDE/Agregator/Konqueror/Dolphin…
@blinkkin: tak dla scislosci: include/ nie sa potrzebne
do uruchamiania jakichkolwiek programow w jakiejkolwiek dystrybucji. Nie dlatego ze jakis program bedzie statyczny – tylko dlatego, ze nie ma potrzeby kompilowania czegokolwiek. Jak nie interesuje Cie zawartosc include/ – po prostu wykasuj. Czasami jednak przydaje sie tam zagladac. Podobnie z doc/ man/ icons/ fonts/ – w wiekszosci przypadkow wystarczy ich brak lub okrojony zestaw podstawowych czcionek, ikonek. By sysem odchudzic nie potrzeba tworzyc potworka stali. Tak, prowokacyjnie powiem potworka, bo moim zdaniem, jedyne co proponuja, to nalozenie ograniczen w wyborze w imie
pustej idei. Wszedzie mozna statycznie skompilowac kernel, nie korzystac z initrd, ude, hala. Kilka programow z jakich sie korzysta przekompilowac statycznie i zyska…. no wlasnie, co zyskac? Co, naprawde odkrywczego w stali proponuja? Co ciekawego w swiat informatyczny proponuja wniesc od siebie?
Swiat jest dynamiczny, systemy tez i wedlug mnie system dynamicznie linkowanych bibliotek jest wlasciwym jego odzwierceidleniem.
Jeszcze można zrobić “rm -rf /proc”
Naprawdę nie musisz mi tego tłumaczyć, katalogi /lib i /include podałem jako przykład. Co do /usr/include i /usr/local/include to w przypadku wielu binarnych dystrybucji można znaleźć tam sporo “śmieci”. Pomimto tego, że na takiej maszynie brak środowiska programistycznego. To w jakiej paczce znajdą się nagłówki często zależy od opiekuna.
Systemu raczej się nie odchudzi poprzez usunięcie /doc, /man, /icons, może tylko poprzez wywalenie czcionek o wysokiej rozdzielczości. Zresztą nie wyobrażam sobie korzystania z systemu bez stron podręcznika man, chociaż z drugiej strony w Linuksie są one zazwyczaj kiepsko przygotowane lub ich brak.
Bibliotek w systemie nie będzie w ogóle. Większe zapotrzebowanie na pamięć to też prawdopodbnie mit jeśli chodzi o małe programy. Kobyły pewnie nadal będą linkowane dynamicznie.
Natomiast małe programy rzadko używają wszystkich funkcji danej biblioteki, zazwyczaj tylko małej ich części. W FAQu znajdziesz odnośnik do ciekawego tekstu (pozwoliłem sobie na tłumaczenie – może zawierać błędy, robiłem to na szybkiego):
Mam nadzieję, że to rozświetliło sprawę.
> Kiedy Sun zdał raport na temat ich PIERWSZEJ IMPLEMENTACJI
> wpółdzielonych bibliotek
Opierasz sie na implementacjach sprzed okolo 20tu lat? Gratuluje.
Właśnie temu jestem ciekawy jak potoczą się losy tego projektu.
Nie. Sprwadziłem stronę suckless i opisali tam, że mają być wprowadzone zmiany (w jądrze?) które będą ładować poszczególne części tylko raz jeśli już istnieją. Więc kod z biblioteki Y (która w sumie już nie będzie biblioteką tylko częścią programów X i Z) będzie się ładował tylko raz.
Nie bardzo rozumiem jak miałoby się to odbywać. Mamy dwie binarki korzystające z tej samej biblioteki – co oznacza, że do ich segmentów kodu i danych (zainicjalizowanych) zostały dorzucone analogiczne z biblioteki (+/- eliminacja nieużywanych fragmentów), po czym linker dopisał odpowiednie relokacje. Jak mając teraz te dwie biarnki wyciągnąć część wspólną, nie wiem. No chyba że panowie chcą rozszerzyć format blików binarnych o jakieś metadane? Ale nadal nie wyobrażam sobie jak to robić w sensownym czasie.
Wystarczy wprowadzić sumy kontrolne dla kawałków kodu i dynamicznie sprawdzać, czy w pamięci systemu są kawałki o takiej samej sumie. Brak podziału na biblioteki nie musi oznaczać braku współdzielenia kodu.
“Wystarczy” to złe słowo – obawiam się, że overhead tego co proponujesz jest wysoki.
Zakładam tu oczywiście, że usuwanie martwego kodu odbywa się na poziomie całych sekcji pochodzących z plików .o (kiedyś myślałem że linker usuwa pojedyncze funkcje, ale tak nie jest, jeśli się nad tym zastanowić, to ma to sens).
Jaki tam wysoki overhead — jeśli da się w KSM (strony pamięci), to tym bardziej na poziomie struktury obiektów kodu (bo pliki .o to nic innego, jak obiekty).
@wujek_bogdan: Niekoniecznie. Pamietaj, ze wielkosc biblioteki w pamieci sklada sie z trzech rzeczy – kodu (‘tekstu’), danych i kawalkow modyfikowanych przez rtld. W przypadku linkowania dynamicznego dwa ostatnie nie sa wspoldzielone. Jedyne zuzycie pamieci to powielony tekst, ktory – w porownaniu z typowym rozmiarem pamieci operacyjnej – duzy nie jest.
Oczywiscie statyczne linkowanie ma inne wady, ktore powoduja, ze generalnie nie jest dobrym pomyslem. No, ale.
Większość (wszystkie?) dzisiejszych systemów implementuje copy-on-write, więc dane też mogą być dzielone w pamięci między procesy, dopóki jeden z nich nie wykona modyfikacji.
@Czajnik: W praktyce ogromna wiekszosc danych to zmienne globalne, ktore sa modyfikowane przez kazdy proces.
No w końcu nie kolejna dystrybucja Linuksowa i będę obserwował jego rozwój.
Panom z suckless ktoś powinien powiedzieć, że prima aprillis był pół roku temu.
Ludziom, którzy za cel stawiali sobie napisane klienta IRCa używając mniej niż 250 linijek kodu, ciężko odmówić zwariowania do pewnego stopnia.
Ależ to żaden problem, wystarczy wszystko wrzucić do jednego pliku, po czym usunąć większość zanków końca linii
Dowcip polega na tym że ten kod _jest_ ładny i czytelny : ) A klient działa, jaki by nie był.
W pythonie to by było coś w stylu:
import ircclient = irc.IRCClient()
client.start()
Mam wrażenie, że to krok wstecz:
- Biblioteki współdzielone to nie tylko oszczędność miejsca – to także możliwość poprawiania kodu w jednym miejscu. Choćby nie tak dawno w expat’cie był błąd naprawiony w późniejszej wersji – ale python i wiele innych programów nadal było niezabezpieczonych gdyż mialy własną wersję zbundlowaną. Tutaj naprawienie jednego, głupiego błędu w expat’cie będzie musiało się wiązać z wymianą prawie całego systemu – każda paczka linkująca do expata musi być przelinkowana i wymieniona (kilkaset MB na przeciętnym systemie).
- Jądro jako monolit – hmm. wstawanie z hibernacji będzie trwało wieki – moduły od początku siedzą w pamięci a przy monolitycznym jądrze najpierw wszystko musi się wczytać, zainicjalizować sprzęt etc. żeby przejść do poprzedniej konfiguracji. U mnie przejście ze statycznie kompilowanego jądra do modułów (ta sama konfiguracja, Gentoo) przyspieszyła start.
- lilo – czyli witaj z powrotem “ops. zapomniałem wydać komędę lilo przed restartem”? W grubie mam linię poleceń która nieraz ratowała system – w lilo jestem zdany na gorączkowe szukanie płyty z LiveCD. Dodatkowo, to może być przestrzała wiadomość, miał problemy z ‘dużymi’ jądrami typu większymi niż 0.5 MB. /boot/kernel, przekompilowany w większości modularnie więc tylko to co potrzebne do startu, zajmuje prawie 4 MB. Jeśli ma być statycznie kompilowane nie pod konkretny system to raczej sobie nie poradzi.
- system w pamięci RAM – dla nowszych komputerów albo bardzo minimalna dystrybucja
- /usr jako dowiązanie do / – wolę mieć 2 partycje – /usr i / gdyż jak coś się stanie to jest większa szansa że będę mógł naprawić /usr z /. Dodatkowo jak wygląda sprawa / na LVM bez initrd (bo tak to mogę mieć /usr na LVM i minimalny /)?
- Używanie rsync jako upgrade – czyli brak paczek. Wszyscy używają KDE lub GNOME albo każdy kompiluje sobie oddzielnie. Czyli w zasadzie po co mi ta dystrybucja skoro i tak o większość muszę się zatroszczyć sam?
PS. Zapomniałem dodać – na urządzeniach wbudowanych ma to więcej sensu:
1. Znana platforma więc można dostosować kernel
2. Wymagania typu mała pamięć etc. są relatywnie ważniejsze niż problem bezpieczeństwa
3. Nikomu nie przeszkadza że nie ma jego ulubionego WM
4. Wielkość libc ma znaczenie
5. Nikt nie będzie miał otwartych iluś programów naraz każdy z własną kopią webkita/gtk/qt/… etc.
PPS. Tak przeczytałem “Aren’t statically linked executables less secure?”. Jakoś bardziej przekonuje mnie SPOT.
Z tego co rozumiem cały system to obecność czy nieobecność tego kodu nic nie zmienia i dlatego może być wycięty (OK – problem jest jeśli jest “remote code execution” ale IMHO jest mała szana że to coś zmieni).
“we also focus on a small and maintainable userland, where only one tool for each task exists” -> Czyli inaczej mówiąc przyznają że dla większości zastosować to podejście zawodzi.
Co do exploitu z ldd – IMHO probelm tkwi w sposobie implementacji LDD a nie bibliotekach współdzielonych jako takich
“Imagine that the insecure library functions aren’t linked into the static executable and hence the executable is not affected at all (but it would be affected if we did link it dynamically).” – tak bo kod znajdujący się w pamięci od razu jest wykonywany
oba rozwiązania mają swoje wady i zalety, to jakie rozwiązanie wybierzemy zależne będzie od tego czego będziemy oczekiwać od dystrybucji.
projekt zapowiada się ciekawie, przede wszystkim z tego względu, że nie istnieją podobne dystrybucje. zanim rozwiązanie nie zostanie przetestowane w praktyce można opierać się jedynie na teorii i domysłach.
Panowie z suckless są dosyć ortodoksyjni, więc założenia początkowo mogą wydawać się archaiczne. Z pewnością nie będzie to system każdego użytkownika.
Jest to ładnie wyjaśnione w FAQu. stali ma być w założeniu zestawem małych programów, który wykonują tylko jedną czynność (jest to równoznaczne z mniejszą ilością zależności). Strata w postaci wolnego miejsca nie będzie zapewne wielka, nawet jeśli to w obecnych czasach nie gra to znaczącej roli (terabajtowe dyski etc).
Biblioteki współdzielone to miecz obusieczny. Często aplikacji korzystają tylko z części funkcji dostępnych w bibliotece. Jeśli błąd nie dotyczy funkcji zawartej w statycznej binarce, dziura go nie dotyczy. Natomiast w przypadku dynamicznego powiązania wszystkie aplikacje korzystające z takiej biblioteki są narażone, niezależne czy wykorzystują daną funkcję.
Wątpie, że twórcy stali wrzucą do podstawowego systemu expata czy nawet perla. Ich niechęć do tych narzędzi wyjaśniłem w innym komentarzu, który czeka na moderację (zapewne zbyt duża liczba odnośników – mam nadzieję, że nie poszło jako spam).
Być może suckless.org zajmie się rozwojem i wsparciem lilo o czym jest mowa w newsie.
Jest to tylko pomysł jak można przeczytać na oficjalnej stronie: “perhaps later whole system in ramdisk? will see (20h idea)”. Wszystko możliwe.
Systemy plików nowej generacji nie wymagają fizycznego podziału partycji – o rozmieszczenie plików z poszczególnych woluminów troszczy się zazwyczaj sam system plików. Cały czas mówi się o Btrfs i Tux3.
Co do initrd to w news zaznaczyłem, że dotyczy to prawdopodbnie początkowej fazy projektu.
Brak zależności co jest efektem ubocznym statycznego kompilowania (drugi komentarz od góry) sprawia, że większość możliwości oferowanych przez menedżery pakietów jest zbędna. Zapewne wystarczy spakowane archiwum z daną aplikacją i prosty skrypt przygotowany pod wget.
W każdym razie jak to mówią “pożyjemy zobaczymy”. Projekt ten traktuje bardziej jako eksperyment niż poważną dystrybucję.
W zasadzie nie bardzo widze dla kogo mialby ona byc. Serwery – nie (apache i spolka to nie sa male programy). Desktop – bez KDE/Gnome/XFCE/.. raczej trudno. Systemy wbudowane – lilo ogranicza do x86 a pozatym tam już sobie radza (a system i tak musi byc indywidualnie przycinany).
Male programy sa piekne – moga wykonac 90% czynnosci. Ale sa wykonywane przez mniej niz 10% czasu. Zajmnuja duzo mniej niz 10% pamieci – IMHO optymalizacja, szczegolnie tak radykalna ze nie bedzie praktycznie nigdzie indziej wykorzystana, to strata czasu.
Eh. Tutaj nie chodzi o konkretna paczke.
Na razie btrfs/tux3 są w fazie rozwoju. I nie bardzo widze jak mialyby pomoc w opisywanym scenariuszu (ale moge sie mylic).
Czyli bedzie cos bardziej skomplikowanego. Co do wget’a – problem bledow bezpieczenstwa.
Hmm. Nie bardzo widze sens takiego eksperymentu ale moze cos przeoczylem.
Dla pr0, którzy nie używają myszek a menedżer okien konfigurują w kodzie źródłowym (tak, piję do dwm
). W zasadzie ta definicja zawęża użytkowników do grupy niewiele większej od autorów.
> lilo ogranicza do x86
Waćpan najwyraźniej nie słyszał o SILO…
Statyczne linkowanie w Windows kiedyś mocno namieszało jak wykryto lukę bezpieczeństwa w GDI++, a wiele programów miało tą bibliotekę wlinkowaną statycznie do execów. Z tego co pamiętam Ms wypuścił wtedy narzędzie, które przeszukiwało dysk w poszukiwaniu takich plików exe i je naprawiało.
wręcz przeciwnie – gdi+ istniało tylko jako biblioteka dynamiczna i jako taka była przez developerów dołączana do aplikacji ze względu na to, że defaultowo posiadał ją tylko XP,a nie posiadały jej windy 2000 i 9x. Tool, o którym piszesz był do bani;-) przeszukiwał wszystkie HDD w poszukiwaniu wystąpień starszej wersji tej dll-ki i zastępowaniu jej nowszą.
> – lilo – czyli witaj z powrotem “ops. zapomniałem wydać komędę lilo
> przed restartem”? W grubie mam linię poleceń która nieraz ratowała
> system – w lilo jestem zdany na gorączkowe szukanie płyty z LiveCD.
Wystarczy przecież:
1. Pamiętać o wstukaniu “lilo”, tudzież…
2. …żeby zawsze mieć w pogotowiu “System Rescue CD”, oraz…
3. …pamiętać, że chodzi o komENdę, a nie “komędę”.
Nawet jeśli to nie będzie aż taki cios dla urządzeń wbudowanych .
Tam raz się wstawia system operacyjny z niezbędnym softem i rzadko kiedy go się aktualizuje . Takie rozwiązanie jest tam przyjęte na dobre , nie trzeba bawić się w dynamiczne linkowanie czy mega zależności i to jest to .
Tylko jak pisałem przyda im się dobra obsługa procesów czasu rzeczywistego .
To jedyne co by mi się w tym projekcie podobało. Pozostałe rzeczy to krok wstecz!
Przy aktualizacjach przez delty, to może to wypalić. Inaczej musielibyśmy aktualizować cały system w przypadku znalezienia jakiejś dziury w bezpieczeństwie. Z deltami – tylko różnice dla każdej paczki.
Ha(ck|r)cerstwo. Ale niech się bawią, może z ich zabawy wyniknie coś ciekawego (z dwm powstał awesome). Użyć tego raczej nie użyję.
a moze warto uzyc KSM do oszczedzenia pamieci zespalajace identyczne stronice pamieci:
http://lwn.net/Articles/329123/
a jesli chodzi o nieuzywanie initrd to na pewno start systemu bedzie szybszy:
http://lwn.net/Articles/299483/
to co jest lepsze w shared library model to to, ze instalacja 100kB poprawki bezpieczenstawa naprawia “n” aplikacji (openssl, expat, itp..)
KSM się nie nadaje bo: primo) będzie dopiero w 2.6.32, secundo) wymaga łatania źródeł (oczywiście autorzy mogą poprawiać każdy program — zdrowia życzę).
możesz podać jakieś źródło dot. wymogu łatania źródeł?
Katalog domowy roota w /home? A co to za idiotyczny pomysł?! Gdy skopie mi się partycja /home, nie mogę już się w ogóle zalogować do systemu i spróbować naprawić? Gratulacje.
Stalin? Oh well…
En wiki podaje troszke danych o TCC, ktorego tamci panowie pewnie wola od (harmful) GCC. Problem w tym, ze ich szybsze statyczne binarki nie beda szybsze, bo TCC produkuje wolny kod:
http://lists.gnu.org/archive/html/tinycc-devel/2005-09/msg00056.html
Moze i to stare dane, ale TCC od 2005 roku ruszyl sie z .23 do .25, totez pewnie rewolucja sie nie dokonala.
W ogole mam wrazenie, ze ich (lub wymieniony w liscie) cudowny soft ma 10% funkcjonalnosci tego harmful i innego bloated, i wtedy – rzeczywiscie – ma malo kodu i jest szybki. Ciekawe co bedzie, kiedy zrownaja sie funkcjonalnie…
(Tk i QT? *SQL i plain text?) Ponadto nie lubia tam chyba kobiet i dzieci. Z tym drugim to akurat dobrze, nie przekaza swoich aroganckich genow dalej.
Mi się wydaje, że nie osiągnie nigdy tej funkcjonalności. Wygląda na to, że ten projekt jest kierowany do REAL MEN ™, czyli ludzi, dla których X11 służy do tego, żeby mieć otwarte 10 xtermów.
Zaczynam rozumieć takie podejście. Zainstalowałem sobie Łubudubu Karmić Koala; niby wszystko pięknie ładnie ale po przyjrzeniu się z bliska desktop zawiera: mono, mysql server, buetooth, laptop-sraptop-foo, coś do PDA, Ruby i kilka innych dziwnych języków i niepotrzebnych programów. Jak bym chciał wszystkie te pakiety wypierdzielić w piz.. to dzięki niezwykle bogatym zależnościom pewnie nawet gruba by mi należało skasować
Apage: polecam slackware.
Gentoo można sobie dokładnie skroić (co jest IMHO znacznie wieksza zaleta niz szybsze o cale 0.01%
). Zgaduje ze dystrybucje ‘dla zaawansowanych’ (Arch, Slackware, Gentoo…) sa znacznie lzejsze.
PS. Osobiscie nie moglbym sobie poradzic z brakiem zaleznosci w Slackware.
To zainstaluj sobie coś z *BSD , OpenSolarisa lub Jakąś minimalistyczną dystrybucje Linuxa , w nich nie masz śmietnika zależności
wszystko fajnie ale nazwa kojarzy się ze Stalinem, bez obrazy dla nikogo :S
tow. Dzugaszwili zaakceptowal te niefortunna zbieznosc nazw.
a wy, konraddo, poczytajcie u gory, juz sobie z tego na
posiedzeniu zartowalismy. “siedzi na sali egzekutywa \\
tlusta, ogromna, i pot z niej splywa” : )
faktycznie, wybaczcie
nie chciało mi sie sprawdzić:S
no.. pamietajcie, wrog czuwa!
I tak powstanie nowa wresja debiana…
poczemu poprawiac cos co juz jest bardzo dobre ?
tak samo jak by poprawiaz michaela jordana….
Jeden security issue w podstawowej bibliotece i mamy pół systemu i oprogramowania do wymiany. (Nie mówiąc juz o marnowaniu pamięci i masie innych problemów.)
Dystrybucja dla paru geeków, która zdobędzie 0,0000000000000000000000000000000001% rynku Linuksów. Nie używam i nie mam ochoty używać żadnej z wymienionych na http://suckless.org/misc/cool_programs aplikacji… serwer Nostromo… większego zapomnianego i bezużytecznego antyku nie mogli wykopać? Ktoś produkcyjnie użyje Nostrocośtam a nie Nginxa, Apache, czy Lighttpd?
nie tędy droga. Nie z tak bezużytecznym softem (i co ze sterownikami nVidii do monolitycznego kernela?)
Cieszę się z tego, że ludzie z suckless zabrali się za własną dystrybucję. Czytając ich stronę/filozofię zawsze dziwiłem się jak w ogóle mogą używać linuksa. Raczej na pewno nie będę jej używał, ale to nie szkodzi; byleby skupienie się na niej nie odbiło się na możliwości wyświetlania 10 xtermów przez dwm