Deweloperzy Dystrybucji AuroraUX, której główne narzędzia są pisane w Adzie, językiem skryptowym FalconPL, a całość skompilowana w Clangu, poinformowali o zmianie jądra z OpenSolarisa na DragonFly BSD .
Deweloperzy Dystrybucji tłumaczą tę zmianę kilkoma przyczynami :
- Niejasnymi planami rozwoju OpenSolarisa po przejęciu Suna Przez Oracle
- Mała możliwość współpracy z dostawca kernela;
- Nadal zamkniętej sporej części kodu OpenSolarisa
- Środowisko do kompilacji całego kodu powstało na potrzeby wewnętrznego użytku przez firmę Sun, a modyfikacja tego systemu w celu dodania obsługi programów napisanych w Adzie lub ewentualna jego zamiana na inne rozwiązanie kosztowałaby zbyt wiele czasu, który preferujemy lepiej spożytkować.
- Kwestiami Licencyjnymi
Dodatkowo Deweloperzy Wskazują Korzyści z przeniesienia na jądro DragonFly BSD:
- Współpraca z developerami jest bardziej otwarta, co może przynieść korzyści po obydwu stronach;
- HAMMER jest godnym następcą ZFS;
- Jądro DragonFly BSD jest możliwe do kompilacji w całości za pomocą clang.
Warto dodać że na temat przyszłości AuroryUX odbyła się już dyskusja na OSnews.
Strona Główna Projektu AuroraUX
Ostatni Build Oparty Na OpenSolarisie Wersja Alpha
Proszę o edycję bo nie wyszło ponownie z linkami 🙂
Poprawione. Masz też już uprawnienia, żeby poprawiać samemu. Jak nie wychodzi z edytorem graficznym to polecam edytor HTMLowy (jedna z ikonek zmieni formularz dodawania niusa na HTMLowy).
Problem w tym że jak pisałem o contikios za pomocą NVU to też miałem problemy , ale teraz mogę edytować do skutku 🙂
Ech chciałem zapoznać się z tym systemem a tu strona tymczasowo nie dostępna :/
osnews effect? 😛
Problemy z serwerem zaczęły się dzisiaj w nocy.
Osoba, która odpowiada za niego jest w trakcie przeprowadzki do Australii. Serwer fizycznie znajduje się w Londynie, więc przywrócenie go do życia może zająć trochę czasu. Niefortunny zbieg okoliczności 🙁
Trasz: jest jakiś plan zastosowania metody Kopiego-Pasta w celu przeniesienia Hammera do FreeBSD? Czy zostajecie dalej twardo przy ZFS?
@kj: Nic mi o tym nie wiadomo. Zreszta z tego co wiem, to na razie HAMMER jest mniej wiecej na takim etapie rozwoju jak Btrfs – czyli ledwo dziala. ZFS dziala calkiem niezle i jest w wielu miejscach uzywany produkcyjnie.
Brak obsługi ZFS po iSCSI i NFSv4 (chyba sam na tym pracujesz z tego co widziałem?) w FreeBSD-release, świadczy moim zdaniem o czym innym. FreeBSD 8.1 ma podobno przynieść zmiany w tym temacie?
Jeśli chodzi o system plików HAMMER to najbardziej brakuje menadżera woluminów (być może implementacja LVM z NetBSD zostanie skopiowana) i tworzenia kopii migawek przy użyciu wielu "masterów".
HAMMER mocno wyróżnia się względem ZFS czy Btrfs m.in. ze względu na reblocking, który następuje za pomocą demona przez crona.
Przeniesienie HAMMERa na inny system może być problematyczne, ponieważ ten system plików jest mocno zintegrowany z systemem. Locking w DragonFly BSD jest dosyć nietypowy m.in. ze względu na brak Muteksa (minimalne jego wykorzystanie).
Wyszedł mi trochę "polskawy" news, ponieważ ciężko znaleźć odpowiedniki anglojęzycznych zwrotów. Przepraszam za to wszystkich purystów językowych.
@blinkkin: Zarowno obsluga ZFS po iSCSI, jak i NFSv4 sa we FreeBSD od bardzo dawna. Brakuje natomiast kernelowego serwera iSCSI, ktory w Solarisie jest bardzo ladnie z ZFS zintegrowany. Do niedawna nie bylo obslugi ACL-i typu NFSv4 – ale w Linuksie nie ma jej w ogole i wiekszosci ludzi nie przeszkadza to w ogole, wiec hu kers. 😉
Dzięki za sprostowanie, jak widać mam zaległości w tym temacie 😉
Prawdo mówiąc sam miałem zabrać się za tego newsa, ale krzabr był szybszy 😉 Gdyby nie zabawy ze śniegiem – odśnieżanie dachów…
Co do ostatniego builda to zespół AuroraUX zrezygnował z dystrybucji binarek – nowsze wersje można było zbudować używając paczki zawierającej wszystkie potrzebne źródełka.
Do ciekawszych informacji należy planowany audyt bezpieczeństwa, o którym można była przeczytać w newsletterze. Zapewne zostanie wykorzystany w tym celu OpenBSM.
Na współpracy może zyskać też pkgsrc – Clang/LLVM i GNAT zapewne zostaną zaktualizowane. Podobno trwają też rozmowy nad zmianą licencji GNAT z GPL na BSD.
Czytając grupę dyskusyjną DragonFly BSD można natrafić na pierwsze efekty współpracy. Chodzi głównie o poprawki, błędy znalezione w ACPI i AHCI. Zespół AuroraUX ma też swój udział w proponowanych projektach GSoC 2010.
Więcej informacji zapewne mógłby udzielić mulander, który bezpośrednio jest zaangażowany w cały projekt.
@blinkkin: GNAT na GPL? Jakoś nie wierzę, ale pewnie pogadać można.
Miało być "GNAT na BSD" a nie "GNAT na GPL"- przepraszam.
Sprawa z licencjonowaniem GNAT jest dosyć skomplikowana. Nie wiadomo do końca, kto jest właścicielem oryginalnego kodu: AdaCore, FSF czy Siły Powietrzne USA. Co tego dochodzi kilka różnych wersji samego GNAT: gnat-gpl, gnat-gcc i gnat-pro.
Żeby było śmieszniej to użycie biblioteki RTL (Run-time library) w przypadku Ady, może doprowadzić do "zainfekowania" kodu licencją GPL.
Sensowne by było udostępnienie frontendu do LLVM na licencji BSD – takie jest moje osobiste zdanie.
Ale iso można spokojnie ściągnąć 🙂
Zawsze możecie pisać na freenode kanał auroraux , osoby z tego kanału są uprzejme i szybko objaśniają nurtujące pytania .
Jakim sposobem całość może być kompilowana Clangiem, skoro to frontend wyłącznie języka C?
Prawdopodobnie chodzi o skompilowanie nim jądra i głównych narzędzi .
http://clang.llvm.org/
Ale Ady tu nie widzę 😉
Właśnie jednym z celów projektu jest wypuszczenie kompilatora ady dla LLVM .
Na pewno jednak nie będzie nim clang. Jak dla mnie pierwsze zdanie samo sobie przeczy.
@Reddie w przypadku kompilacji Ady, zdecydowanie wykorzystywany będzie GNAT-LLVM.
Niefortunnie, w newsie znalazło się stwierdzenie o kompilacji 'całości' clangiem. Cytat jaki zamieściłem ze strony projektu clang dotyczył twojej wypowiedzi informującej, że jest on jedynie front endem kompilatora C – Wskazywałem, że dotyczy również C++, Obj-C, chociaż teraz po namyśle, jestem skłonny zrozumieć, że mogłeś to potraktować jako jedną 'rodzinę'.
'Nadal zamkniętej sporej części kodu OpenSolarisa'
@trsh
Coś kiedyś mówiłeś że OpenSolaris jest w pełni otwarty. Więc o co chozi tym panom powyżej ?
@ak47
http://hub.opensolaris.org/bin/view/Project+emanc…
http://hub.opensolaris.org/bin/view/Main/no_sourc…
Prawdopodobnie chodzi o toolchain OpenSolarisa. Sun Studio jest darmowe, ale źródła nie są udostępnianie. Stąd początkowa decyzja o przejściu na LLVM, która okazała się bardziej skomplikowana niż początkowo zamierzano.
W przypadku DragonFly BSD możliwa jest kompilacja jądra za pomocą GCC lub Clang/LLVM. Przy odrobinie pracy zapewne dałoby się go także skompilować za pomocą PCC.
Inny przykład LDoms które otwarto ledwie 1,5 miesiąca temu .
Proszę wytłumaczyć niewtajemniczonemu co daje, czym się różni proces tworzenia:"…główne narzędzia są pisane w Adzie, językiem skryptowym FalconPL, a całość skompilowana w Clangu…" od typowej dystrybucji? Tak z ciekawości pytam, jeśliby ktoś miał ochotę łopatologicznie wyjaśnić to bardzo chętnie przeczytam
Ada to współbieżny język nastawiony na defensywne programowanie – co przekłada się na bardzo dobrą obsługę wielu procesorów i zapewne mniejszą ilość błędów w kodzie.
Wiele projektów systemów operacyjnych upadło, bo zaczynało od tworzenia jądra. AuroraUX moim zdaniem poszła w dobrym kierunku zaczynając od userlandu. Niektóre narzędzia zapewne zostaną przeniesione także na inne OSy.
Co do FalconPL to osobiście nie rozumiem tego wyboru. Jest to mało znany język, co oznacza małe wsparcie. AuroraUX z tego co wyczytałem nastawia się na licencję BSD, tym bardziej wybór FalconPL dziwi (licencja GPL).
Nie wiem czy jako język skryptowy nie lepiej sprawdziłaby się Lua, która rozprowadzana jest na licencji MIT. Świetnie integruje się z praktycznie każdym znanym językiem, w tym z Adą.
Wsparcie jest dosyć duże, podstawowy interpretator Lua niewielki. Z czasem zapewne możliwe by było przepisanie Lua w Adzie. Co ciekawe istnieją takie projekty jak LuaJIT, co można uznać za spory atut.
Wiesz, projekt GNU to też tylko „kraina użytkowników”. Do dziś nie ukończono jądra. Zamiast spójnego, wolnego systemu operacyjnego, po internecie krążą niezliczone kombinacje narzędzi GNU i (zazwyczaj) Linuksa, z których większość nie nadaje się do niczego.
Podobnie będzie z AuroraUX. Do niedawna działał na OpenSolarisie, teraz na DragonflyBSD, w przyszłości powstaną pewnie inne warianty. Założę się, że ostatecznie użyją Linuksa, bo jako jedyne wolne jądro obsługuje ilość sprzętu wystarczającą, by wcisnąć go bez większych wyrzutów sumienia domowym użytkonikom. Zresztą co za różnica, i tak będzie tylko zabawką dla pasjonatów.
Oczami wyobraźni widzę na OSnews spam gównianych systemów nowej generacji, dla których fanatycy będą gotówi umrzeć, czy raczej pozabijać tych, którzy śmią mieć ważniejsze sprawy od ratowania świata przed krwiożerczymi binarkami bez kodu źródłowego.
Poza licencją BSD, reszta założeń jest kompletnie bez sensu.
– Język Ada, którego mało kto zna, a większość tych co zna, nie uczyła się go po to, by zajmować się pierdołami.
– Do mniej poważnych zastosowań skorzystano z Falcona, który też jest mało popularny. To już nie lepiej było wziąć np. Pythona, którego zna znacznie więcej ludzi, którzy z chęcią zabiliby czas pisząc skypciki do nowego, fantastycznego systemu spod znaku… ważki?
Hmm… Króliczek, szop pracz, antylopa, pingwinek, ważka… Może otworzymy zoo dla miłośników open source? Tylko co zrobić z diabełkiem…
Co ciekawe w początkowej fazie projektu Hurd planowano użycie jądra 4.4BSD. Pomysł ten zarzucono, a w tym samym okresie Linus zaczął hackować jądro Miniksa. Torvalds wkrótce "wymienił" narzędzia Miniksowe na GNU. Chyba wiadomo jak to się dalej potoczyło.
Z niecierpliwością czekam na twoje newsy, skoro ten uważasz za gówniany.
Znowu lekcja historii. Kiedy wyszła Ada, znaczna większość programistów uważała, że będzie to następca C. Tak się nie stało m.in. z powodów licencyjnych o czym pisałem w poprzednim komentarzu. Popularność zyskało C++, które początkowo nie miało dobrej opinii.
Obecnie sprawa licencyjna Ady po części się rozwiązała. Mimo swojego wieku jest to dosyć nowoczesny język m.in. ze względu na współbieżność.
A czemu nie Perl, przecież jest nadal popularniejszy niż Python? FalconPL to w porównaniu z tymi językami zupełnie inna półka. Radziłbym poczytać czym są języki skryptowe.
Takie zoo już istnieje: <a href="http://www.oszoo.org” target=”_blank”>www.oszoo.org.
"Wiele projektów systemów operacyjnych upadło, bo zaczynało od tworzenia jądra. AuroraUX moim zdaniem poszła w dobrym kierunku zaczynając od userlandu. Niektóre narzędzia zapewne zostaną przeniesione także na inne OSy."
Zgadzam się z tym a ada ze względu na przenośność spowoduje że ten system może stać się niezależny i od architektury i od konkretnego jądra . Dobry wybór 😉
Chodzi o specyfikę języka .
Ada jest stworzona z myślą o przenośności , odporości na błędy , niezawodności i zastosowaniach czasu rzeczywistego powoduje to że główne narzędzia w systemie odziedziczą te cechy .
Natomiast falconpl jest językiem stworzonym aby był łatwy do zrozumienia dla osób nieprogramujących .
Po co to wszystko ? Ano developerzy tego distra mierzą wyżej niż stworzenie nowego distra opartego na *buntu/fedorze itd chcą stworzyć coś nowego do określonych celów .
Ooo i o takie wyjaśnienie chodziło, dziękuję. Jak prosty jest ten falconpl? Czy est on używa w jakichś popularnych/znanych aplikacjach linuksowych? Jeśli to takie proste jak skrypty w bashu to fajna rzecz, można by łatwo dostroić programy pod siebie.
http://www.falconpl.org/
Tu masz właściwie wszystko o falconiepl .
Blinkin o wyborze zadecydowało chyba to :
"Falcon is …
…an Open Source, simple, fast and powerful programming language, easy to learn and to feel comfortable with, and a scripting engine ready to empower mission-critical multithreaded applications."
Najwyżej zaproponuj luę na kanale 🙂
Rozmawiałem już o Lua na IRCu z kilkoma osobami związanymi z AuroraUX. Panowie nie lubią dynamicznego, słabego typowania. W sumie się nie dziwię, bo to przeciwieństwo Ady.
Tylko w takim razie pytanie, do czego potrzebny im język skryptowy?
btw. Istnieje LLVM-Lua, czyli zarazem JIT i kompilator.