Wychodząca niedługo Fedora 9 będzie pierwszą dużą dystrybucją Linuksa, która pozwoli na obsługę trybów graficznych bezpośrednio w jądrze. Serwis Phoronix pokazał pierwsze testy przedstawiające tę funkcję w akcji.
Ponieważ jej API nie zostało jeszcze ustabilizowane, można ją zaobserwować tylko przy podaniu specjalnego parametru rozruchu jądra “i915.modeset=1”. Ta nazwa oznacza, że na razie test mogą powtórzyć tylko posiadacze kart Intela. Kolejny będzie zapewne sterownik do Radeonów.
Bardzo fajna funkcja – dobrze wygląda. Może też okazać się bardzo użyteczna, bo prawdopodobnie pozwoli na rezygnację X'a z praw administratora 🙂 (z tego co wiem, to właśnie do wykrywania ustawień karty graficznej X potrzebuje uprawnień root'a)
Niestety na razie tylko dla kart Intela – czekam na wsparcie ze strony sterowników nv czy nouveau.
nv to juz historia, ztcw nouveau jest nie tylko aktywniej wspierany, ale i bardziej funkcjonalny.
fakt – ide o zaklad ze to nouveau bedzie kolejnym po intelu sterownikiem toto obslugujacym 😉
Swoja droga, OpenBSD od dosyc dawna ma mechanizm umozliwiajacy xserwerowi dzialanie bez praw roota – root jest "zrzucany" po zainicjalizowaniu sprzetu.
Dziwne troche, ze nikt tego pod Linuksa nie przeportowal.
Hej, ale na serio, czy blefujesz?? Trochę mnie to śmieszy(nie ty, ale sam fakt).
A co będzie, jeżeli będziemy przełączali się między kilkoma X serwerami lub X serwerem i konsolą? Wtedy X serwer ponownie musi ustawić odpowiadający mu tryb graficzny. I jeszcze jedno: co z emulacja?
Nie jestem żadnym guru informatyki. Zaciekawiłem się tym. Mógłbyś wskazać na jakieś tksty na ten temat 😉 .
No, troche (nieswiadomie) uproscilem.
.
"Privilege separation has been implemented in the X server. The privileged child process is responsible for the operations that cannot be done after the main process has switched to a non-privileged user. This greatly reduces the potential damage that could be caused by malicious X clients, in case of bugs in the X server."
.
http://www.billswrite.com/bsd/openbsdnews.html
Co tam Windows, to nawet w Linuksie jest. Tyle, ze tutaj chodzi o wykorzystanie tego po to, aby xserwer nie dzialal na prawach roota. W OpenBSD jest, w Linuksie nie.
osobiscie wyczekuje na ta wlasnie funkcje, jak i na poprawienie drivera do i965 (poki co nie obsluguje np. xvmc na ktorym mi dosc zalezy, a i po powrocie z uspienia, konsola zle sie inicjuje sie…)
pytanie kiedy to w innych driverach rowniez zostanie zaimplementowane… 95% ze nastepne bedzie nouveau…
Nie zwolnil, zarówno oryginalny radeon, jak i radeonhd aktywnie się rozwijają, aż miło przeglądać repozytorium gita ;).
Największy brak to póki co to dokumentacja akceleracji 3D dla chipów R600, reszta w zasadzie już jest.
Niestety upstart 0.3 jeszcze nie jest tym czego byśmy wszyscy chcieli – nie obsługuje bardziej skomplikowanych zależności między zdarzeniami np. "start on started foo and bar" oraz nie posiada możliwości eksportowania zmiennych ze skryptów. Na szczęście upstart 0.5 będzie miał już wszystko co potrzeba i będę mógł przepisać bootscript F9.
To co jest w bootchart-parallel to tylko mała zapowiedź tego (zrobione na prostych wrapperach na skrypty sysvinit) co chcę osiągnąć przepisując bootscript – rc.sysinit też będzie równoległe 😉
Ale ja na Ubuntu z upstartem (skrypty wykonujące polecenia z /etc/init.d) osiągam czasy nieco ponad 20s. Wystarczyło trochę podłubać i ściągnąć gotową paczkę ze skryptami.
Gdybyś nie zauważył, to w moich testach używałem prawie wszystkich usług jakie są w domyślnej instalacji F9 – duża część z nich jest domyślnie wyłączona.
Napisałem też, że użyłem wrapperów które wyglądają mniej więcej tak
start on started rsyslog
start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6
console output
script
/etc/init.d/acpid start
end script
pre-stop script
/etc/init.d/acpid stop
end script
Czyli są używane standardowe skrypty sysvinit, tylko są uruchamiane prawie równolegle – z powodu nieobsługiwania przez upstart 0.3 bardziej skomplikowanych zależności.
Jeśli używasz skryptów korzystających z dobrodziejstw upstart, to są one oczywiście wykonywane trochę szybciej niż skrypty sysvinit.
W F10 prawdopodobnie znajdzie się już nowy bootscript – przepisany pod upstart 0.5 – celem jest wystartowanie dystrybucji z domyślnymi usługami w czasie poniżej 30 sekund 😉
Nie wiem, w zasadzie nie używałem, ale swego czasu jak się mu przyglądałm to dość szybko wstawał – a, że później już ta różwo nie jest, no… to już inna bajka ;).
Celem? BulletproofX pozwala na wystartowanie X.orga przy złym xorg.conf, na minimalnej rozdzielczości, albo skonfigurowanie go z okienka jeszcze przed logowaniem, a to to ma umożliwić płynniejsze przejścia pomiędzy trybami (terminalami), w dodatku ulepszyć obsługę sprzętu i zredukować objętość Xserwera.
W praktyce będzie jak zawsze – nVidia dopisze po 2 miesiącach, Intel będzie kulał przez pół roku, na ATI/AMD nie będzie przed 2010. W desktopie mam GF, w notebooku i965GM i na poprawną obsługę EXA przyjdzie mi czekać do jesieni b.r. (na TTM). Na chwilę obecną wolałbym mieć jednak GF.
Z obsluga sprzetu to dziala w obie strony. Jakis czas temu, na przyklad (jakis czas, bo od pewnego czasu na zabawy ze sprawdzaniem wsparcia dla roznego sprzetu nie mam czasu ani ochoty) z obsluga IDE (w sensie, ATA) pod FreeBSD bylo mniej problemow niz w Linuksie. Teraz tak samo (afaik) wyglada sytuacja z WiFi.
Zgoda, że nie wszystkie sterowniki robi się dla Linuksa – a potem dopiero "portuje" do xBSD. Ale, tak prawdę mówiąc, to jednak Linuksowi deweloperzy znacznie bardziej wyczuleni są na zgłaszane błędy – w xBSD trzeba być przygotowanym na podejście typu: "to stary sprzęt, to już nam się do tego wracać nie chce", albo: "to ochotniczy projekt – i tak nie płacisz, to nie zawracaj głowy" (dosłownie). Oczywiście, że "nie płacę" – pełna zgoda – ale przecież za Linuksa też nie płacę, prawda? A może być i humorystyczniej; można czasem dostać w odpowiedzi: "masz dostępne `źródła', to sam se napraw. Jak skończysz – patcha `zapodaj' ". Taki drobny detal, że jakbym mógł zrobić to sam, tobym nie zawracał nikomu d… – jakoś umyka uwagi takiego dowcipnisia. 😀
Tak więc, skoro w świecie Linuksowym podejście do usuwania niedostatków jest wyraźnie solidniejsze, to wspomniana "sytuacja z WiFi" z całą pewnością jest czysto przejściowa.
@Z: Szczerze powiem, ze mam doswiadczenia dokladnie odwrotne – w dodatku taki RedHat potrafi olewac zgloszony problem mimo wykupienia supportu. Z FreeBSD mialem troche problemow (ostatnio z if_bridge, na przyklad), ale po zgloszeniu byly dosyc szybko rozwiazywane. Kwestia tego, na kogo konkretnie trafisz. Podobnie zreszta jak z Linuksem.
Szczerze powiem, ze mam doswiadczenia dokladnie odwrotne – w dodatku taki RedHat potrafi olewac zgloszony problem mimo wykupienia supportu.
Nie mam w ogóle żadnych doświadczeń z RedHat-em (nie używam) – ale co do sterowników, to raczej należało na kernel-list.
Z FreeBSD mialem troche problemow (ostatnio z if_bridge, na przyklad), ale po zgloszeniu byly dosyc szybko rozwiazywane.
No, jeśli chodzi o "fejczery" takie "bardziej na czasie", to zawsze łatwiej jest kogoś zainteresować. Ale spróbuj zgłosić potrzebę poprawki czegoś, czym tam akurat deweloperzy już dłuższy czas temu przestali się bawić, uznając za ostatecznie ukończone.
Podejście, jakie zauważyłem, jest z grubsza takie, jakby to mieli za darmo robić wyłącznie dla Ciebie – a nie również dla 10 tysięcy innych właścicieli tego samego sprzętu, z których – powiedzmy – dwustu, być może, zainteresowałoby się xBSD, gdyby im toto chciało działać. A przecież w masie użytkowników Ci, którzy zgłaszają błędy, to też nieliczna grupka. I raczej na pewno nie dotyczy to tych, którzy dopiero "przymierzają się": ot, wrzucą instalkę, stwierdzą "co za badziew" – i przez najbliższe parę lat do tematu nie wrócą.
Kwestia tego, na kogo konkretnie trafisz.
To na pewno; problem w tym, że nie zawsze jest wybór, jeśli – na przykład – w jakiejś sprawie decyzje podejmuje akurat jedna-jedyna osoba, wtedy i tak wszystko do niej wraca.
OSX kuleje i jakoś zainteresowanie nim zaczęło coraz bardziej spadać :D. Jeśli porównujesz prekonfigurowany system (macosx) pod konkretny sprzęt do Linuksa, którego sam musisz skonfigurować to tak. Ale trzeba przyznać, że to trochę głupie. Jaką funkcjonalność masz na myśli? Chyba nie możliwości jądra, środowisk, aplikacji? 😀
Hmm… A jeszcze mi gdzieś tam po głowie się kołacze kilka artykułów w których hackerzy jajka lamentowali nad obsługą grafiki w jądrze Windows. Że może to i szybsze, ale jakże destabilizuje jądro i w ogóle… Widać, punkt siedzenia się nieco zmienił 😉
Ale tu zupełnie nie o to chodzi. W tej chwili obsługą sprzętu zajmuje się X, a tymczasem jest to działka kernela. Tak więc chce się przenieść nie całą grafikę do jądra, tylko tą część iksów odpowiedzialną za sprzęt. Nie destabilizuje to jądra bardziej niż obsługa, dajmy na to, dźwięku czy sieci w jądrze.
W Windows jest zupełnie inna bajka. Cały kod obsługujący GUI jest w jądrze – jeśli silić się na porównania, to tak jakby chcieć przenieść GTK+ i Qt do jądra.
I tez to niczego (w Windows) nie destabilizuje. Kiedy ostatni raz miales bluescreen spowodowany przez win32k.sys, ktory nie wynikal z uszkodzonego (albo przetaktowanego, na jedno wychodzi) sprzetu?
.
Owszem, byl taki okres, zaraz po tym, jak to wrzucili do kernela. Gdzies w okolicach wczesnego NT4.
Goto ma swoje zastosowania i w okreslonych sytuacjach zwieksza czytelnosc kodu. Oczywiscie w _niektorych_ sytuacjach. Dobrze opisal to Linus gdzies kiedys, piszac o zwalnianiu zasobow w razie bledu.
.
Poza tym nie powiedzialbym, aby grafika w jadrze byla jakos specjalnie brzydka. Ladniejsze to, niz na przyklad poryty sposob bootowania Linuksa – szopki z initrd itd, spowodowane tym, ze badziewny bootloader nie umie kernelowi modulow podladowac.
Za to sytuacje, w których całe windowsowe GUI stoi przez kilkadziesiąt sekund (sic!) bo akurat się zblokowało na jakiejś operacji I/O są naprawdę denerwujące. Jak ktoś używa aplikacji przenośnych na flashu, wie o czym mówię.
Ale ja nie mówię, że to destabilizuje. Nie destabilizuje dlatego, że kiedy GUI zostało wprowadzone do jądra NT, to GUI miało już kilka(naście? nie wiem dokładnie) lat, i było na tyle dobrze przetestowane, że nie destabilizuje niczego.
Co nie zmienia faktu, że w ogólnym przypadku nie uważam tego za dobry pomysł;)
nadal grafika nie bedzie obslugiwana na poziomie jadra – chodzi tylko o ustawianie odpowiednich trybow graficznych, a w przyszlosci – tzw. "prymitywow" – czyli podstawowych operacji typu blit, alokacja pamieci dla tekstury i takie tam…
Well this kind of details is in fact worth looking for, good information for readers and obviously shows high quality writing. Its cool to have these kinds of posts about to help keep the details flow. Helping those who truly get pleasure from this, wonderful perform! Thanks once again for taking the time to place this online. I unquestionably liked every portion of it.
Dodaj komentarz