Zespół odpowiedzialny za wydania Debiana opublikował listę celów do zrealizowania przed wydaniem wersji 6.0, oznaczonej nazwą kodową „Squeeze”. Postanowił też zrewidować datę zamrożenia nadchodzącej edycji.
Pełna lista zaplanowanych zmian jest dość imponująca, z tych najważniejszych należy wymienić m.in.:
- obsługę wielu architektur, dla przykładu poprawiona ma zostać instalacja pakietów 32-bitowych na 64-bitowych maszynach
- obsługę jądra FreeBSD, wprowadzenie pierwszego nielinuksowego jądra do Debiana
- usprawnienie procesu uruchamiania systemu
- usprawnienie kontroli jakości
- pełną obsługę IPv6
W świetle przedstawionych planów, a także zważywszy na reakcje społeczności Debiana na początkowe ogłoszenia podczas tegorocznej konferencji w Cáceres, zespół odpowiedzialny za wydania postanowił zrewidować decyzję o zamrożeniu repozytorium w grudniu 2009 roku. Nowy harmonogram zostanie ogłoszony na początku września.
Po zamrożeniu Squeeze będzie nadal w fazie testing, a wersje pakietów nie będą aktualizowane. Więc jeśli dobrze rozumiem, żeby mieć dostęp do nowszych wersji pakietów, powinienem upgrade'ować do Sida, tak?
Przesiadłem się jakoś z 3 miesiące na Debiana i jeszcze nie przerabiałem zamrażania wersji 😉
> wersje pakietów nie będą aktualizowane
tam gdzie nie będzie to konieczne — nie
> żeby mieć dostęp do nowszych wersji pakietów, powinienem upgrade’ować do
> Sida, tak?
tak
> jeszcze nie przerabiałem zamrażania wersji
da się przeżyć 🙂
Podczas zamrożenia pakiety z unstable nie będą automatycznie przechodziły do testinga, ale celem uniknięcia dodatkowego zamieszania developerzy (przynajmniej teoretycznie) nie będą wprowadzali nowych wersji oprogramowania do Sida. Preferowaną metodą wprowadzania poprawek do testinga jest upload do unstable, przetestowanie i zmigrowanie pakietu do testing (developer wysyła do release teamu prośbę o odblokowanie migracji danej wersji pakietu). Unika się więc wprowadzania nowych wersji aplikacji, a w szczególności bibliotek (wtedy pakiety od nich zależące należałoby uploadować bezpośrednio do testinga).
Oczywiście w praktyce różnie to wygląda, ale generalnie większe i bardziej ryzykowne zmiany odkładane są do następnego wydania. Nowe wersje softu często zamiast w unstable lądują w experimentalu lub nieoficjalnych repo, więc jak zależy Ci na jakimś konkretnym programie, to często można go znaleźć. Tak było na przykład z KDE4 podczas ostatniego freeze.
warto jeszcze dodać, że po wydaniu stabilnej wersji debiana, sid przez jakiś czas wije się w konwulsjach z powodu ogromnej liczby zmian wprowadzanych równolegle przez developerów 🙂
Teraz obsługa IPv6 w Debianie jest więc…niepełna ?
szybki rzut klawiatury na wyszukiwarkę: http://ipv6.debian.net
"obsługę jądra FreeBSD, wprowadzenie pierwszego nielinuksowego jądra do Debiana"
A Debian GNU/Hurd?
a Hurd jest w którymkolwiek z oficjalnych wydań?
http://www.debian.org/ports/hurd/
wyglada dosc oficjalnie
"However, Debian GNU/Hurd is not officially released yet, and won't be for some time."
Podobnie port kFreeBSD. Był od jakiegoś czasu, teraz pierwszy raz ma się pojawić w wydaniu stabilnym.
Mam nadzieję, że będzie dostępna funkcja jail 🙂 Wydaje się być bardzo przydatna na serwery WWW ze współdzielonym hostingiem 🙂
Masz na myśli chroot? Przecież jego obsługa działa znakomicie.
Inna sprawa że z chroota łatwo wyjść.
Jail to taki rozbudowany chroot z BSD: http://www.freebsd.org/cgi/man.cgi?query=jail . W przypadku Linuksa najlepiej porównać go z vserverem/openvz, a z funkcji obecnych w standardowym jądrze z lguestem.
Ale nie jestem specem od BSD… jak jail może być przydatny w przypadku takiego współdzielonego hostingu na serwerach WWW?
A z chroota można łatwo wyjść tylko, jak się ma roota oraz system nie ma odpowiednich łatek (w rodzaju grsecurity).
home.pl intensywnie wykorzystuje funkcję jail w swoim hostingu. Istnieje darmowy okres testowy wynoszący 14 dni, więc można sobie w praktyce przetestować jak to działa.
Ja od siebie mogę dodać tylko to, że nie należy oczywiście takiej funkcji traktować jako antidotum dla bezpieczeństwa serwera, lecz bardziej jako dodatek w zwiększeniu poziomu jego zabezpieczeń.
Raczej odpowiednik OpenVZ.
Hosting współdzielony w jail/chroot? Halo, mamy rok 2009!
Powiedz to firmie home.pl 😉
Co rozumieć przez cyt. "obsługę wielu architektur, dla przykładu poprawiona ma zostać instalacja pakietów 32-bitowych na 64-bitowych maszynach" – co to oznacza, Debian ma się stać multilib jak Arch? Bo nie rozumiem.
Nie wiem, czym jest multilib, ale "obsługa wielu architektur" tutaj faktycznie jest trochę myląca. Chodzi o multiarch, czyli możliwość instalacji paczek z różnych architektur. Przykładowo: mamy system 64-bitowy, instalujemy kilka paczek 32-bitowych; mamy nowy port kFreeBSD, ale instalujemy kilka paczek dla Linuksa (FreeBSD potrafi uruchamiać binarki linuksowe), a nawet: mamy PowerPC, instalujemy paczki dla architektury ARM i uruchamiamy je (binfmt-misc) na qemu 😉
@Piotrek: Arch jest na jedną architekturę (x86) – nie ma go na amr, ppc, sparc, etc.
Drugą sprawą jest to że właśnie arch nie jest niestety multilib (co powoduje problem, że jak chcesz skompilować 32bitową aplikację na 64bitowym systemie musisz sobie zrobić środowisko chroot zamiast do gcc podać "-m32").
arm: http://archmobile.org/
ppc: http://archlinuxppc.org/
@hiciu: to są nieoficjalne porty – tak naprawdę to są inne dystrybucje
@pijaczek
może Piotrek miał na myśli, że w końcu w debianie pojawią się paczki optymalizowane nie tylko pod i386, ale tak jak w Archu pod i686.
btw, mamy 2009 rok i mógłby Debian się w końcu dorobić takich paczek. Rozumiem, że chcą zachować jak największą kompatybliność, ale czy wydajność nie jest ważniejsza? Ewentualnie, można by wydawać kilka wersji dla x86.
Masz jakieś benchmarki? 😉
Generalnie w większości przypadków wzrost wydajności jest w granicach błędu pomiarowego. Pojedyncze paczki (kernel, libc) są kompilowane w kilku wersjach, na kilka podarchitektur, ale w przypadku większości spowodowałoby to tylko niepotrzebne koszta. No i kompatybilność (na szczęście) jest dla Debiana ważna. (Zastrzeżenie: też nie robiłem benchmarków, przytoczyłem odpowiedź na podobne pytanie, którą gdzieś kiedyś przeczytałem).
BTW: Debian już nie daje się uruchomić na 386, minimalne wymagania to 486. Sufiks "386" w nazwach paczek został chyba głównie ze względów historycznych.
@wujek_bogdan
należy sobie postawić pytanie czy kompilowanie typowego oprogramowania na PC z 686 cokolwiek daje. Osobiście uważam, że nie (w najlepszym przypadku niewiele):
– co robi typowy program przez większość czasu? odpowiedź: śpi czekając na zasoby lub (jeśli jest interaktywny) na akcję użytkownika
– o rzędy wielkości większy wpływ na wydajność programu ma kompozycja algorytmu i struktur danych niż ewentualna optymalizacja z dodatkowymi instrukcjami dokonana przez kompilator
– krytyczne fragmenty kodu, gdzie wykorzystanie nowszych instrukcji procesora może dać wymierne efekty (np. biblioteka standardowa, kernel), są kompilowane również dla nowszych architektur (np. libc6, libc6-i686)
– obecnie zmiany w zestawach instrukcji dotyczą w zdecydowanej części instrukcji SIMD(3dnow!,SEE i nowsze), których wykorzystanie i tak musi odbywać się jawnie (ew. przy pomocy bibliotek w rodzaju libsimd oferujących operacje na typach wektorowych), poprzez np. 'inline assembly' i aplikacje, które faktycznie na SIMD zyskają robią to (np. ffmpeg,mplayer). Co prawda nowsze wersje gcc(i nie tylko) powoli potrafią robić użytek z automatycznej wektoryzacji(-ftree-vectorize) ale są to dopiero początki i proces wektoryzacji jest ściśle powiązany z konkretną wersją zestawu SIMD.
– rozdrobnienie architektury x86 na mniejsze dodaje pracy (na brak której developerzy debiana nie narzekają) i potencjalnych problemów np. VIA C3 Nehemiah jest zgodny z instrukcjami 686 ale już VIA C3 Ezra nie. Podobnie sprawa wygląda z instrukcjami SIMD, kolejne instrukcje SSE są dodawane nawet w obrębie 1 rodziny procesorów, co dodatkowo komplikuje sprawę.
To są moje przemyślenia i chętnie wszystko odszczekam jeżeli ktoś mi pokaże wyniki profilingu mówiące coś innego 🙂
> To są moje przemyślenia i chętnie wszystko odszczekam jeżeli ktoś
> mi pokaże wyniki profilingu mówiące coś innego 🙂
Daj spokoj, tylko dzieci sie podniecaja przekompilowaniem
/bin/ls z opcjami -O99 -march=686 i zyskiem 1% przy listowaniu
katalogu, a aplikacje dla ktorych takie rzeczy rzeczywiscie moga
miec zauwazalne znaczenie, zazwyczaj rozwiazuja to poprzez dynamiczne
wlaczanie optymalizowanych procedur, jako przyklad moze sluzyc menu
"cpu features" w VLC chociazby.
Takie rozwiazanie daje duze pokrycie obslugiwanego
sprzetu przy malym nakladzie na utrzymanie paczek.
@janc
dzięki za wyczerpującą odpowiedź.
@Compi
nie mam benchmarków przy sobie ;). gdzieś kiedyś jakiś widziałem i wynikało, że przekompilowanie pod i686 na szybkim sprzęcie daje, tak jak mówisz, mizerne efekty, natomiast im gorszy sprzęt, tym różnice są większe
Sugerowałem się tym, że Archlinux, gdzie paczki sa optymalizowane pod i686 w moim odczuciu działa wyraźnie szybciej niż inne dystrybucje, ale prawdopodobnie wzrost wydajności nie jest skutkiem kompilacji paczek pod i686, ale raczej tego, że Arch świeżo po instalacji jest "goły", bez zbędnych modułów, skryptów i deamonów.
No to lipa, wśród milionów linuksowych dystybucji akceptowałem tylko debiana ze względu na jego ciągłość, długi czas można było używać testing i mieć aktualne pakiety nie marnować życia na durne aktualizacje i reinstalacje sysa, a teraz kupa. Czy są jakieś inne distra które nie mają żadnego cyklu wydawniczego tylko po prostu cały czas aktualizują pakiety?
Archlinux jest najlepszy w tej kwestji.
Ciągłość zapewnia niestabilna wersja Debiana, czyli Sid. Aktualizacje są wstrzymywane jedynie na czas mrożenia wersji testing – Compi pisał już o tym wyżej.
> długi czas można było używać testing i mieć aktualne pakiety nie marnować
> życia na durne aktualizacje i reinstalacje sysa
nic się nie zmieniło w tej kwestii
Należy też nadmienić iż, takie nie inny sposób wydawania wybrano by terminy przyszłych letnich, konferencji DebConf, gdzie podejmuje się ważne tematy odnosnie przyszłości Debiana nie wypadały w czasie zamrażania systemu. Kiedy deweloperzy i programiści powinni skupiać się tylko na ustabilizowaniu dystrybucji i wyłapaniu błędów.
DebConfy w lecie, mrożenie w grudniu co dwa lata (również ze względu na to by dać czas na wprowadzenie założeń ustalonych na DebConfach) i wydanie stablinej wersji w pierwszej połowie roku, tworzą cały cykl bardziej przejrzystym.
Co do wydania Squeeze, będą jeszcze prowadzone rozmowy z programistami odnośnie zmian w harmonogramie by jakos dopasować to jedno wydanie.
Gentoo nie ma już wydań, lecz po instalacji zawsze można aktualizować do tego, co jest najnowsze. Na dwóch komputerach bez żadnych problemów (poza kilkoma czystosprzętowymi) używam ~amd64, co jest tłumaczone na unstable. Na trzecim używam amd64, co jest nazywane stable, też bez problemów.
Reinstalacja przydaje się tylko przy zmianie pomiędzy 32-bitowym a 64-bitowym systemem.
"Czy są jakieś inne distra które nie mają żadnego cyklu wydawniczego tylko po prostu cały czas aktualizują pakiety?"
Sidux (Sid z instalatorem i zmodyfikowanym kernelem na i686).
Jednak częstotliwość aktualizacji to szaleństwo 😉
A może PLD? Chłopaki ciągle aktualizują pakiety, a oficjalnych wersji jak na lekarstwo, ostatnia była w 2007 roku. A wszystkie pakiety w najnowszych, często jeszcze eksperymentalnych wersjach, mniam… A jak się coś sypnie podczas upgradu, zawsze można wygodnie wrócić do starszych rpmów.
Ostatnia była 1 marca 2009 ;P ..klik..
Czy Squeeze będzie obsługiwał ext4 ??
Tak. Obecnie dostępne migawki debian-installatora bez problemu podczas instalcji radzą sobie z ext4.
instalator owszem obsluguje ext4 ale standardowe jadro po instalacji netinstall testinga juz nie:(
aha, racja. ja instalowałem unstable, który ma teraz 2.6.30, a pewnie za tydzień będize .31
Do czasu wydania powinno wskoczyć jądro z unstable, które ma już ext4.
Widzę, że coraz częściej używa się słowa „odnośnie” (tym razem w tytule), więc chciałem zauważyć, że po Polsku mówi się „odnośnie do czegoś”, a nie „odnośnie czegoś”.
Szczegóły: http://pl.wiktionary.org/wiki/odnośnie_do_czegoś
Prawda, dziękuję.
Ściągnąłem niedawno Debiana kde4 CD, chcąc zainstalować, przetestować.
1. Brak sterowników do sieciówki atl2, oraz do wifi Broadcom (ani b43 ani ndiswrappera). Ciekawe jak mam dociągnąć i zainstalować cokolwiek? Paranoja z tą "wolnością" czy zwykła bezmyślność? Bo w innych distrach to chociaż ethernetówka działa od ręki.
2. Po instalacji uruchamiam kompa i co widzę…kernel error not syncing bla bla bla.
To chyba jednak wolę nawet to Ubuntu niż samego Debiana, bo takich cyrków to z żadną dystrybucją nie miałem, czy to Arch, PLD, Gentoo, Ubuntu i Opensuse. Słowem, żenada. Czekam na minusy od fanboyów Debiana. Im więcej będzie tym więcej będą przekonany, ze mam rację.
Miałem kiedyś podobny problem z programowym raidem (mdadm). Instalator tworzył wszystko jak powinien ale systemu nie dało się uruchomić…
Kiedy ja nie mam raida, zwykły dysk SATA w dwuletnim lapku Asusa. Taka nowość dla Debiana 😉
Przerabialem to. Bo ty byl pewnei fake raid. Taki RAID co wymaga sterownikow systemu. Da sie to odpalic ale troche roboty jest/bylo
Programowy to chyba nie fake. Fake to programowy, który udaje sprzętowy :]
A póki nie ma się naprawdę dobrego "tró-sprzętowego" RAIDa to nie ma co go używać i lepiej zrobić programowy mdadmem.
Skoro ma przyjść jądro freebsd to ciekawe czy z nim przyjdzie portowany system plików zfs , co prawda nie ma zgodności licencyjnej ale zaloze sie ze znajda sie chetni aby go skompilowac pod debianem , druga sprawa freebsd uzywa systemu pakietow ports jak wiec bedzie z obsluga pakietow deb jak uruchomimy debiana z jadrem freebsd ? jak wtedy beda dzialac linuxowe aplikacje przez emulacjie linuxa w jadrze freebsd ? czy inaczej ?
Ports to zupełnie niezależna rzecz od jądra, które jest jedynym elementem FreeBSD w Debian GNU/kFreeBSD. Debian (jak chyba każdy system operacyjny) używa ten sam format pakietów niezależnie od jądra.
Przy ZFS nie widzę problemów, jeżeli Debian nie będzie dystrybuować jądra z rzeczami na GPL. Emulacja Linuksa jest ciekawsza, bo wymaga bibliotek współdzielonych korzystających z wywołań systemowych tego jądra. Wystarczy z innymi ścieżkami dodać biblioteki z Debiana GNU/Linux.