Longene wchodzi do Linuksa?
- Dodano: 11 lutego 2010
- Wprowadził: spy000yps
- Komentarze: 94
Pojawiło się nowe drzewo w repozytorium kernel.org zatytułowane „Longene (UnifiedKernel Project)’s kernel module, for linux-next merge”. Dlaczego fakt pojawienia się 150 drzewa jest wart odnotowania? Longene to projekt, który ma na celu wprowadzenie do jądra Linux kodu ukompatybilniającego go binarnie z systemem Windows.
Wprawdzie wrzucenie drzewa na kernel.org, to dopiero jeden z pierwszych etapów jaki będzie musiał przebyć ten kod zanim użytkownicy będą mogli się cieszyć binarną kompatybilnością (pewnie nigdy 100%) Linuksa z systemem Microsoftu, jednak należy mieć nadzieję, że projekt “chwyci” wśród deweloperów i zajmie się nim więcej ludzi. Jeśli szybko uda się spełnić wszystkie standardy (wcięcia!!! – za cztery spacje polecą gromy 
), to być może już wkrótce kod wejdzie do głównego drzewa jądra.
Więcej informacji: http://git.kernel.org/?p=linux/kernel/gi...eads/expri
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
94 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Ale o co chodzi?
Co autorze rozumiesz pod mglistym pojęciem "ukompatybilnienie binarne z systemem Windows"? Czy chodzi o ABI? Czy o API? Czy może będzie to "merge" Wine do jajka? A może to o drivery z Windows chodzi?
Po wtóre, "Jeśli szybko uda się spełnić wszystkie standardy (…) to być może już wkrótce kod wejdzie do głównego drzewa jądra.". Czymkolwiek toto ukompatybilnienie jest to na pewno nie da się tego szybko zrobić, szczególnie, że oni dopiero repozytorium zrobili. No chyba, że szybko dla autora to np. 2-3 lata.
O ile dobrze rozumiem, to jądro Linux ma się zachowywać dla Windowsowych programów jak jądro Windows. W wine musi być do tego jakaś warstwa, teraz to będzie robione już na poziomie jądra.
API/ABI "wyższego poziomu" będzie nadal na poziomie wine.
"oni dopiero repozytorium zrobili"
Eeee… to jest repo, które będą chcieli wrzucać do -next. Jeśli zamierzają wrzucać do -next, to oznacza, że raczej działa (nie używałem, więc nie wiem na 100%). Gdyby nie działało, to by wrzucali do -staging
.
Z repo masz rację – projekt wystartował rok temu. Nota bene rok to i tak dość młody projekt, szczególnie, że rozmawiamy o open-source.
To zależy czy komuś się opłacało opłacić devów na pełnym etacie
a Wine może się takim zainteresowaniem poszczycić 
Mnie się wydaje, że chodzi jedynie o pamięć współdzieloną, a także komunikację między procesami. Obecnie na Linuksie mamy DBus + pseudosieć. W Windows komunikacja między procesami odbywa się inaczej, a także mamy jakieś nie znane mi do końca mechanizmy. Obecnie za pamięć współdzieloną odpowiada w sporym stopniu wineserver, który chyba kopiuje pamięć z jednego procesu do innego
.
Innymi sprawami będą systemy plików.
Czyli jak sie prg.exe wywali to mamy BSOD'a pod Linuxem?
Jakoś trudno mi sobie wyobrazić (poza błędem drivera) sytuację by zwykły userlandowy program wywalił jądro jakiegokolwiek dojrzałego systemu
Poszukałem i sam sobie i może innym odpowiem.
To jest takie przerobienie Linuksa żeby był ReactOSem
Albo inaczej, wciągnięcie wineservera do jądra. Ma toto cudo być zgodne binarnie zarówno z driverami jak i aplikacjami. Cały userland używają z Wine i/lub ReactOSa.
Ja osobiście jednak popieram bardziej Tanenbauma, jak coś może pracować w userlandzie to powinno tam pracować – wolę Wine.
To nie tylko wine-server. Zobacz co jest w repo.
Jak tam zaglądałeś to się podziel informacjami. Nie każdy umie obsługiwać gita!! a już na pewno nie każdy pozwoli sobie na ściągnięcie ~~ 250MB tylko, żeby popatrzeć na źródełka z których i tak nic nie zrozumie
Więc jak coś wiesz to się podziel !!
W gitwebie jest taki magiczny link "tree" dzięki któremu można sobie przeglądać zawartość repo przez przeglądarkę. Tam jest wrzucone coś typu API do jądra NT oraz ntdll.dll (system plików, kolejki komunikatów, zarządzanie pamięcią i inne typowo Windowsowe rzeczy, które powinny działać po stronie jądra). Nawet są loadery do PE EXE oraz winowych ELF "EXE".
"Jak tam zaglądałeś to się podziel informacjami. Nie każdy umie obsługiwać gita!!"
Oh… i Ty masz się niby zajmować programowaniem Linuksa…
"a już na pewno nie każdy pozwoli sobie na ściągnięcie ~~ 250MB tylko, żeby popatrzeć na źródełka z których i tak nic nie zrozumie"
Repo przeglądałem bez ściągania.
"W gitwebie jest taki magiczny link “tree” dzięki któremu można sobie przeglądać zawartość repo przez przeglądarkę. "
Właśnie
"Tam jest wrzucone coś typu API do jądra NT oraz ntdll.dll"
Właśnie tak mi się wydaje, że to jest coś takiego. Ale nie uruchamiałem i nie czytłem, więc nie wiem na 100%.
właśnie o to chodzi, że nie chcą dodać wine-servera do jądra, a pozbyć się całkiem wine-servera, poprzez implementację funkcji wine-serwera w jądrze. Trochę to pokręcone, ale zobaczymy co przyniesie wersja 0.2.5
Zaraz, zaraz… do moje układy logiczne w mózgu właśnie zawiodły. Jaka jest logiczna (nie techniczna) różnica pomiędzy dodaniem wineservera do jądra a implementacją (funkcji) wineservera w jądrze?
Nikt tych funkcji w jądrze nie będzie nazywał Wine server ?!?
A tak na serio to Wine nie umożliwia instalacji sterowników
A longene może temu zaradzić
Wineserver emuluje część funkcji jądra NT w userlandzie, twórcy UK dążąc do pełnej kompatybilności chcą zaimplementować wszystkie, posiłkując się przy tym zarówno kodem Wineservera jak i ReactOS.
@s logiczna różnica jest taka sama jak między writerem i ms wordem, niby to samo (te same funkcje), a jednak inne.
Twórcy Linuksa to zaakceptowali? Po co? Przecież nikt z projektu, który miał stworzyć jądro, będące kompatybilne z jądrem Windows, nie narzekał!
PS: Pamiętacie, jak się skończyła binarna kompatybilność Linuksa z DOS-em? Z 3-4 lata temu, ktoś ogłosił, że wydał pierwszego wirusa, na nierozwijanego już ówczas, kernela z serii 2.2(czy coś w ten deseń). Podejrzewam, że praca nad kompatybilnością Linuksa z Windows się zakończy podobnie. Przecież żaden z programistów jądra nie będzie dokładnie testować tego kodu, bo ma ważniejsze sprawy na głowie niż kompatybilność z Windows.
"Twórcy Linuksa to zaakceptowali?"
Jeszcze pewnie o tym nie flejmowali.
"Po co?"
Żebyś się pytał.
Widocznie uznali to za pomysł wart rozważenia. To że będzie hostowany na kernel.org nie znaczy przecież że na pewno wejdzie kiedyś do oficjalnego jajka
Mam nadzieję, że ten moduł nigdy nie trafi do vanilli.
Czemu nie? Moduł to moduł, zawsze można go wyłączyć. Gdzieś tam były testy tego ustrojstwa i wychodziło na to że programy windowsowe chodziły znaaaaaacznie lepiej niż tradycyjnie przez wine.
Chociaż chińczykom bym nie ufał
"Czemu nie?"
Bo Sławkowi się nie podoba. Wystarczający powód, dla którego deweloperzy Linuksa nawet nie powinni na to patrzyć a deweloperzy rozwijający Longene powinni porzucić projekt
Niech developerzy tego projektu nadal to rozwijają.
@tomacaster : Masz rację – moduł, to moduł. Jednak proszę nie wprowadzać zmian do rdzenia jądra, by móc go uruchomić!
Mimo wszystko, to nadal nie rozumiem, po co to w Vanilli. Dla modułów tego typu nie powinno być problemów przy uruchamianiu go w nowszym jajku. Jądro ma dosyć stałą listę eksportów dla modułów. Minusem będzie natomiast to, że może on pochłonąć czas developerów jądra. Niech rozwija się to osobno, a twórcy dystrybucji najwyżej to wrzucą.
Programy Windowsowe będą chodzić znacznie szybciej niż pod kontrolą winesever – zgadza się. W dodatku twórcy Wine nie będą musieć się głowić nad obsługą wielu sesji w Wine. I tutaj też jest pies pogrzebany. O ile w przypadku Wine nie ma problemów z bezpieczeństwem systemu, to o tyle błąd w czymś załadowanym do jądra utworzy dodatkowe furtki. Aplikacja załadowana przez zwykłego użytkownika być może będzie móc stać się superużytkownikiem.
Jak ktoś nie stawia serwera, to raczej to olewa…
IMO i tak wszystko zależy bardziej od twórców dystrybucji, nie kernela. Jeżeli projekt ich zainteresuje, to trafi do dystrybucji, nawet nie będąc w vanilii. Jeżeli nie, to nawet główne drzewo jądra mu nie pomoże, bo będą go uparcie kastrować przed załadowaniem do repo
Wprowadzenie obsługi dodatkowego formatu plików wykonywalnych do jajka, to nie będzie taka prosta sprawa.
@Sławek: Byla prosta w BSD – natywna obsluga plikow wykonywalnych w formacie PE zdazyla sie pojawic i, kilka lat pozniej, wyleciec.
Zeby tu tylko o format plikow wykonywalnych chodzilo…
Chodzi przecież o całkiem inne mapowanie pamięci.
@Sławek: Na czym polega jego innosc?
(REPOST, bo komentarze gina.)
@Sławek: Niby czym sie to mapowanie rozni?
@sławek: W Fedorze jest daemon, który umożliwia uruchamianie plików exe jak zwykłych binarek. Nie jestem pewien jak działa, ale wydaje mi się (tak to wygląda w skrypcie startowym), że rejestruje właśnie dodatkowy typ bibliotek, który jest uruchamiany przez wine. Nie jest to co prawda natywna obsługa, niemniej jednak dla zwykłego użytkownika wygląda to tak, jakby była
.
$ apt-cache show binfmt-support
The binfmt_misc kernel module, contained in versions 2.1.43 and later of the
Linux kernel, allows system administrators to register interpreters for
various binary formats based on a magic number or their file extension, and
cause the appropriate interpreter to be invoked whenever a matching file is
executed. Think of it as a more flexible version of the #! executable
interpreter mechanism.
Ten pakiet jest w Ubuntu jedną z zależności wine.
Za obsługę tego odpowiada zapewne pliczek /proc/sys/fs/binfmt_misc.
Być może o to Ci chodzi? Tylko nie wiem, czy daemon ku temu potrzebny.
Rzeczywiście, używa tej metody. Nie pamiętałem dokładnie jak to działa bo dość dawno zaglądałem do tego pliku. dla zainteresowanych sam skrypt (wyciągnięty z paczki dla f12 i386):
http://wklej.org/id/278349/
Ech… Kiedy będzie można edytować własne komentarze? "dla" miało być z dużej litery…
Support do tego jest chyba we wszystkich distrach trzymających Wine w repo: Fedora, Mandriva, SUSE, Ubuntu…
(REPOST – administracjo strony, kup sobie porzadny system moderacji.)
@Sławek: We FreeBSD byla prosta – obsluga plikow wykonywalnych PE zdazyla juz wejsc do kernela i, kilka lat pozniej, z niego wyleciec.
To co chca drivery Windowsowe?
LUK czerpie z ndiswrappera miedzy innymi.
Oraz z ReactOS
Co złego w czterech spacjach?
Brak tabulatora.
Tabulatora? LoL, kto używa tabulatora do formatowania kodu? Każdy edytor to inaczej wyświetla.
Właśnie. U każdego wygląda tak jak ON to chce. Używając spację wymuszasz na innych taką a nie inną szerokość. Szczególnie mnie to boli, bo w ruby standardowo używa się 2 spacji, HEREZJA.
Groszek, poczytaj sobie:
http://www.jspwiki.org/Wiki.jsp?page=WhyTabsAreEv…
I wiele, wiele, wiele podobnych.
Jeśli kilka osób wspólnie maltretuje jakiś kawałek kodu, to dobrze by było żeby u wszystkich wyglądał podobnie.
Jeśli ktoś chce wyrazić swoją osobowość i pochwalić się swoim wspaniałym gustem, lepiej niech zajmie się malowaniem, składaniem origami i takimi tam.
Racja, powinniśmy też pisać HTML tak żeby wygenerowana strona pasowała na jedną konkretną rozdzielczość ekranu i dla jednej konkretnej przeglądarki… Wtedy u każdego będzie wyglądać podobnie, a całe zamieszanie ze standardami mamy z głowy!
Zupełnie nie trafiony przykład. Co do tego ma rozdzielczość?
Wstawiaj sobie tabulatory w tym swoim php gdzie chcesz…
kekek: Jeśli lubisz 4 spacje, to ustawiasz swój edytor by taby tak pokazywał. I masz 4 spacje! Masz taką szerokość! Natomiast kto inny może chcieć 8 spacji – też ma. Bez mielenia kodu osobnym programem, co jest kretynizmem. I zarzut html jest dokładnie trafiony w to co jest opisane w 1 punkcie podlinkowanej strony.
Normalnie nic, ale
"Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3."
Jak widzisz, ludzie akceptujący kod do jądra Linux mają jedną filozofię – ich droga i żadna inna.
Ten zupełnie nie merytoryczny problem będzie powodem zmiany wcięcia w każdej linijce kodu jeśli będą chcieli, żeby został włączony do jądra.
Ale spoko – tym się już zajmą odpowiednie hieny, które rzucają się na każdą białą spację w kodzie czy wyrównują komentarze do prawej
Chodzi o yo, ze jak juz raz zdecydowali sıe na takie a nie inne wciecia, to powinni byc w tym konsekwentni. İnaczej robı sie balagan i tyle.
Hmm. indent i po sprawie. Styl kodowania w jednym projekcie powinien być taki sam ale są do tego odpowiednie narzędzia.
Próbowałeś kiedyś znaleźć zmiany w czyimś kodzie?
Szczególnie gdy przy okazji wpadł na pomysł prze-formatowania całości „bo będzie ładniej”?
są ludzie którzy używają diffa…
"są ludzie którzy używają diffa…"
Wiesz, akurat w tym wypadku wystarczy git annotate.
Ale fakt, że przeforamatowywanie kodu tylko śmieci. Mogli przed importem do repo przepuścić źródła przez Lindent.
Cały ten problem mógłby załatwić indent (taki program), gdyby ktoś się nad nim zlitował i go dopracował.
Każdy większy projekt ma swoje wytyczne dotyczące formatowania kodu.
Bez tego miał byś po roku taki bajzel że nie sposób było by cokolwiek czytać
Chyba każde IDE ma ficzery reformatujące kod. Sztandarowym przykładem jest dla mnie NetBeans, w którym ilość parametrów dostosowujących to formatowanie przyprawia o zawrót głowy (btw, jednym z dostarczonych stylów predefiniowanych jest bodajże 'Linux')
last change Wed, 10 Jun 2009 03:05:27 +0000
Hmmmmmm
Eee przecież z LUKa można już korzystać od jakiegoś czasu. Są nawet paczki dla ubuntu i fedory.
http://www.longene.org/en/index.php http://en.wikipedia.org/wiki/Linux_Unified_Kernel
Ale to byl kernel z patchami zrobiony przez ekipe LUKa a nie oficjalnie dostepna galaz.
no, ale działa, a niektórym się wydaje, że będzie działać za 5 lat
taa „Longene (UnifiedKernel Project)’s kernel module, for linux-next merge” a bazuje na jądrze 2.6.30.
Patrząc na ich stronę to projekt wydaje się całkowicie martwy. Krótko mówiąc czym się podniecać? I tak nie ma on żadnych szans na wejście do głównego jajka
Z resztą. Spróbujcie ściągnąć źródła z ich oficjalnej strony. Wszędzie jest błąd 404
Błąd 404 pewnie bierze się stąd, że projekt tworzony jest w Chinach
. Rząd musi przepuścić każdy zasób, by sprawdzić, czy nie zawiera ukrytych informacji dla USA/Polski/etc. 
To byłby conajwyżej 403…
Mam pytanie… dlaczego pytasz się czy Longene "wchodzi" do Linuxa… Czy styl pisania z wielkich portali przesiąka już do linuxnews ?
Ten projekt może zmienić kompletnie cel linuxa , fakt wielu nowym użytkownikom ułatwi on życie ale czy nie zatraci swojego pierwotnego celu ? Alternatywnego systemu pozbawionego wad windowsa , wydanego na wolnej licencji i jednocześnie konkurującego z Unixami ?
to samo można powiedzieć o WINE, a jakoś nikt na istnienie WINE nie narzeka.
Wine to api które można łatwo odinstalować z LUK ie będzie tak prosto
Z tego co zrozumiałem z komentarzy powyżej, ma być co najwyżej modułem/zestawem modułów. W razie czego – rmmod i po kłopocie
WINE instaluje ten, kto chce go używać.
A jak emulator Windows trafi do jądra, to np. na serwerze też będę musiał trzymać kilka MB potencjalnie niebezpiecznego kodu.
Jeszcze gorzej jak nie będzie można go wyłączyć – wtedy będę musiał szczególnie uważać na windowsowe wirusy.
A co to, jądra się nie da samemu skompilować? Na desktopach to może być fajne rozwiązanie, na serwerach raczej to nie ma większych szans mieć zastosowania – jak i wine – ponieważ wątpliwe by został wystarczająco stabilny/pewny.
Pamiętajcie: to Linux, nie Windows, będą warianty spełniające różne potrzeby, na serwerze przecież też nie instalujecie tego samego co na desktopie.
Wystarczy nie kompilować modułu. Nie wyobrażam sobie żeby stanDardowo dystrybucje takie jak Debian, RHEL czy SLES miały to włączone… o Gentoo nie wspomnę, bo tam trzeba ręcznie…
Uwierz, znam osoby które narzekają na istnienie Wine … na szczęście nie mają one żadnego wpływu na rozwój tego projektu
@krzabr – Według ciebie, jakich to wad windowsa jest pozbawiony linux?
No bo według mnie to linuxowi bardzo dużo braknie do windowsa.
Linux miał swoją szansę kilka lat temu i jej nie wykorzystał.
Na dzień dzisiejszy brakuje na linuxa nowoczesnego oprogramowania które by potrafiło z wielordzeniowego
komputera wyposażonego w wydajną kartę graficzną wycisnąć
przysłowiowe siódme poty.
W takiej sytuacji jaki sens ma instalowanie linuxa na
nowoczesnym komputerze?
Och, bo Linux jest wolny.
Przy okazji, jakie znasz przysłowie o siódmych potach?
Głównie posiada mniej luk , jądro jest stabilniejsze i umożliwia łatwe kompilowanie programów ze źródeł
http://www.ubucentrum.net/2010/01/najszybszy-supe… ta, nie potrafi korzystać z procesorów wielordzeniowych i kart graficznych :/
Jest to bardzo niewygodne – traci się np. automatyczne aktualizacje przez apt-get, yum czy inny manager pakietów.
Poza tym na niektórych komputerach po kilku sekundach od wpisania make pojawi się komunikat "out of memory" – nie każdy ma 256 MB pamięci potrzebne do skompilowania jądra.
No to pozstają dystrybucje które nie będą kompilować Longene alb pod wersje jądra które nie uznają.
Co do 256MB ram – można zawsze użyć innej maszyny, nie wierzę, by znalazły się osoby których najmocniejszy komp do którego mają dostęp miał poniżej 256MB ram. No i pytanie, czy jeżeli jest on taki leciwy, to czy potrzebuje co tydzień nowych aktualizacji.
IMO mądre dystrybucje dostarczą moduły LUK w osobnych paczkach, bo ich twórcy będą zdawać sobie sprawę zarówno z zalet jak i wad tego projektu.
Wiesz, jak ktoś stawia serwer i tak się strasznie martwi o jego bezpieczeństwo, to raczej poświęci te parę chwil na kompilację.
Desktopowy linux się już wypalił i widać że chyli się ku upadkowi. Obecny LUK to kernel zintegrowany z wine 1.0
tak więc żadnych rewelacji tu bym nie oczekiwał.
Taki LUK może i miałby szansę postawić linuxa na nogi ale musiałby być oparty na naprawdę dopracowanej wersji wine, a
taka wersja wine nigdy pewnie nie powstanie.
ach, ci eksperci….
@wini
Wyspiański, czy Kossak powiedział swojemu uczniowi:
"Takie obrazy, będziesz mógł malować, kiedy będziesz już uznany i sławny. Teraz musisz malować dobre."
Takie opinie będziesz mógł wygłaszać, kiedy będziesz już uznanym autorytetem z dyplomem i 150MB dolarów na koncie. I to tylko w wywiadach.
Teraz gadaj z sensem.
I nie troluj. To żałosne.
Imo niestety linux jest bliższy unixom anieżeli Windowsom z tego powodu powinna nastać większa unifikacja dystrybucji i systemów pakietów przez odpowiednie specyfikacje oraz narzędzia wydawane równolegle z jądrem
@No bo według mnie to linuxowi bardzo dużo braknie do windowsa.
Oj ja bym się nie zgodził. Zauważmy, że coraz więcej "projektów" (wybaczcie za takie wpadki z okresleniami – nie jestem specem a zwykłym userem) jest portowanych na Windows. Od niedawna można sobie korzystać z KDE na windzie, KADU również jest wydawane pod ten system. Dla mnie wygląda to tak, że coraz więcej projektów OS jest portowane na M$ Windows – czy dobrze? Niech to każdy sam oceni.
Do tematu newsa.
Pierwsza myśl – o fajnie wreszcie będzie można sobie na Linuxie odpalić ulubione programy z Windy.
Druga myśl – tylko czy jest mi jeszcze to potrzebne? Przecież mamy tak wiele wspaniałych i niejednokrotnie lepszych zastępców
Trzecia myśl – skoro będzie mniejszy problem z działaniem programów więc i wirusy będą działać. Czyż nie dla bezpieczeństwa zmieniłem system?
Tak poza durnymi myślami. Projekt jest dobrym pomysłem chociaż wydaje mi się, że szanujące się dystrybucje jak Debian/Gentoo/RHLE/…(dopisać sobie braki) raczej nie za szybko z tego skorzystają. Zapewne pojawi się masa dystrybucji korzystające z Longene – pozwoli to na zdobycie wielu nowych użytkowników, którzy z produktem M$ nie chcą się rozstać ze względu na brak działania ulubionych gier/programów na Linuxie. Ale pamiętajmy że to jest OpenSource
różnorodność jest tak ogromna, że każdy znajdzie coś dla siebie.
Tak na boku kolejna głupia myśl. Fajnie gdyby powstała dystrybucja, która wykorzystywałaby Longene ale przez dłuższy czas była jedyną – można by ocenić jak sprawuje się to wszystko. Gdyby taka dystrybucja była dobrze kontrolowana można by uzyskać naprawdę userfriendly system dla przeciętnego użytkownika.
Na jednym się zastanawiam, co w sytuacji posiadania systemu 64 bitowego? Raczej nie da radę wcisnąć do jądra 64 bitowego, moduł 32 bitowy (przynajmniej ja sobie tego nie wyobrażam). Jest co prawda wine64, ale ono jest raczej bezużyteczne (ile mam tych programów 64 bitowych pod Win, nie wspominają już o grach).
A dlaczego nie? Wydaje mi się że da się to zrobić na podobniej zasadzie jak uruchamianie aplikacji x86 na x86_64 w userlandzie. No, chyba że ktoś zna przyczyny dla których nie jest to możliwe
Aplikacja a moduł w jądrze to co innego, np. ndiswrapper na systemie 64 bitowym, może korzystać tylko z sterowników po Windows 64 bitowego, w przypadku użycia sterownika 32 bitowego po 64 bitowym system wywala odpowiedni error. Wydaje mi się że w tej sytuacji to może wyglądać podobnie.
To w najgorszym razie, użytkownicy Linuksa 64-bit będą w tej samej sytuacji co Windowsa 64-bit
A poza tym śmiem sądzić że napisanie infrastruktury pozwalającej uruchamiać sterowniki 32-bitowe w jądrze 64-bitowym jest jak najbardziej możliwe (kwestia tylko, ile to zajmie czasu).
Jest coś, czego nie rozumiem. Z jednej strony developerzy kernela bronią się jak mogą przed zewnętrzym/binarnym kodem argumentując to, że jeśli mają zapewnić stabilność systemu, to tylko jeśli będą mieć kontrolę nad kodem modułów. Tymczasem teraz chcą zrobić jedną wielką wyrwę na wszelkiej maści sterowniki? Nie pojmuję.
Dodatkowo jestem pełen obaw, czy to nie zemści się na tworzeniu natywnych sterowników do linuxa. Obecnie Nvidia i ATI muszą kombinować ze swoimi sterownikami i co dla poniektórych robią to już nawet łamiąc licencję GPL. Producenci urządzeń USB są w jeszcze gorszej sytuacji… API USB w kernelu pozbawia ich możliwości takiego rozwiązania jakie stosuje Nvidia i ATI. Nie chcę dyskutować na tym, czy developerzy kernela słusznie utrudniają życie producentom sprzętu (zwłaszcza USB), ale jeśli LUK powiedzie sie, to pożegnamy się z natywnymi sterownikami do linuxa nawet do tych urządzeń co już są obsługiwane.
Chyba po raz pierwszy złożę takie życzenie twórcom opensource: obyw wam się niepowiodło.
Przychodzi mi na mysl takie cos – MS robi tak samo przez ich WHQL i podobne wynalazki, do tego biora za to kase.
Spytam przewrotnie – a co w tym złego? Jeżeli zostanie to sklecone porządnie (tzn. uzyska odpowiednią funkcjonalność i stabilność) i sterowniki windowsowe będą działać bez przeszkód, to IMO należy się tylko z tego cieszyć. Na pewno wpłynie to pozytywnie na stan "desktopowego Linuksa" (tak, ja nadal w niego wierzę).
I co ma oznaczać określenie "natywny" driver pod Linuksa? Jeżeli windowsowy interfejs będzie wewnętrznym elementem kernela, to sterowniki NT automagicznie staną się dla Linuksa natywnymi. Bonusowo, problem o którym wspomniałeś (rzekome "utrudnianie" życia programistom sprzętu) zniknie sam. Tylko się cieszyć
No i oczywiście życzę powodzenia twórcom
Od paru dni kusi mnie aby zajrzeć im w kod, chyba się przełamię w końcu…
Nie chodzi o dodanie WINE do jądra.
Chodzi o dodanie obsługi polików wykonywalnych windows przez jądro.
obecnie Linux korzysta z formatu a.out [wykonywalny, binarny], natomiast Windows – PE [portable executable - też binarny i wykonywalny]
Dodanie obsługi .exe nic nie da, bo każdy program odwołuje się do zewnętrznych bibliotek [user32.dll itd], ale obsługa .dll [przez jądro będą traktowane na równi z .so] to duży plus [mogę wtedy linkować do zamkniętych bibliotek [kodeków itd]
Dopó