Linux vagy NetBSD kernel kerülhet a SkyOS alá

Kernel

Márciusban számoltunk be arról, hogy az osztrák fejlesztő, Robert Szeleney által megalkotott, zárt forrású, kereskedelmi SkyOS fejlesztése leállt. A fejlesztő akkor arra hivatkozott, hogy a hardverek fejlődésének gyors ütemével már nem képes lépést tartani (hiányoznak a driver-ek), így felmerült egyéb lehetőségek mellett (pl. a forrás megnyitása) a SkyOS fejlesztésének befejezése is. Akkor a fejlesztő azt ígérte, hogy megvizsgálja a lehetőségeket és eldönti hogyan tovább. Most a fejlesztő azzal állt elő, hogy megvizsgálja a Linux vagy a NetBSD kernel alapként való felhasználásának lehetőségeit.

Szeleney arról ír, hogy Linux-szal és NetBSD kernellel kísérletezik és azt vizsgálja, hogy a SkyOS API-kat hogyan lehetne ezekre a nyílt forrású kernelekre ráültetni. Ezzel a felhasználók Sky OS "élményhez" juthatnának, miközben élvezhetnék a Linux vagy a NetBSD kernel nyújtotta drivertámogatás előnyeit.

Ez az út lehetővé tenné Szeleney számára, hogy az userland-del foglalkozhasson. A fejlesztő tervei közt szerepel a SkyOS kernelében helyet foglaló grafikus alrendszernek, a SkyGI-nek az userland-be portolása is.

A fejlesztő azt írta, hogy kísérletek eredménye segíthet eldönteni a SkyOS fejlesztésének jövőjét.

A részletek itt és az OSNews cikkében.

( strogg v | 2009. 06. 11., cs – 11:18 )

Nem lenne jobb megnyitni? Mert lehet ráugranaa közösség, és ipari mennyiség driver születne egy éven belül. Ráadásul tuti lesz aki linux kernelt, bsd kernelt farag alá, és több irányba indulhatna ez a -szerintem nagyon impresszív- projekt. Kár lenne érte.
--
A linux felhasználóbarát. mindössze megválogatja a barátait...

"és ipari mennyiség driver születne egy éven belül"

Vagy nem...

"és több irányba indulhatna ez a (..) projekt."

Minek? Miért kell mindenhova erőltetni ezt a forgácsoljuk kismillió irányba a fejlesztéseket, nehogy már egyvalami is elkészüljön elvet? Vannak, akik szeretnek kész*, működő szoftvereket is látni, nem csak egy folyamatosan változó valamit.

*kész: _stabil_ és _kitesztelt_ szoftver, amelynél napi használat során nem kell attól félni, hogy szanaszét hányja magát vagy hogy az x.0.a+1 verzióban áttúrnak valamit.

----------------
Lvl86 Troll

Akkor most mondd meg, hanyan hasznalnak AFS-t solarissal? Egyaltalan a vilagon.

Nyilvan vannak olyan szoftverek, amikkel gondok vannak egy verziofrissites soran, a kerdes itt nem is maga a teny, hanem ezen szoftverek szama. Minel nagyobb, annal rosszabb ez az oprendszerre nezve.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Licenselt Sorarist hanyan hasznalnak a vilagon nem Orcale , vagy Sun vendoru progikkal ? JAVA alapu programok ilyen szempontbol nem relevansak, mert azok minden rendszeren kvazi ugyan azt kompatibilitast adjak.
Solarison rendszerint certificalt programok futnak, certificalt Hardveren, ezek szama eleve nem tul nagy.

Elterjedtseg aranyosan nezve az ilyen problemakat megint erdekes kepet kapnank.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azt el tudod mondani, hogy ezt miert en kaptam?

Tisztazzuk:

- Onnan indult a szal, hogy kell olyan oprendszer, ami nem hanyja szet magat minden rezdulesedre.
- Erre mondta NagyZ a solaris-t
- Erre te belinkeltel egy AFS problemat
- Erre NagyZ kozolte, hogy ez huszadrangu problema
- Erre te "Csak azt, hogy van olyan ami nem kompatibilis egy korabbi verzioval."
- Erre irtam amit irtam.

Inenntol mar nagyon erdekel, hogy mi relevanciaja van annak, hogy vajon hanyan futtatnak solarist licensszel vagy nelkule.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Termeszetesen itt a Solarison egyebkent is futo cuccokra gondolok. Az a tema szempontjabol irrelevans, hogy amugy mennyien hasznalnak solarist. Az meg plane, hogy licenszelt-e, ugyanis a nem-licenszelt solaris szoftveresen megegyezik a siman letolthetovel.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igen.

Ha a megadott specifikációknak eleget tévő környezetben (értsd: minimális gépigény, további szükséges esetleg 3rd party komponensek jelen vannak a rendszerben, magyarán minden adott ahhoz, hogy fusson) elég kis valószínűséggel fog hibába ütközni a felhasználó, akkor én nem félek a kezébe adni egy szoftvert.

----------------
Lvl86 Troll

Hat ez igy ebben a formaban csak felig igaz. A mai napig jonnek ki fixek magahoz a platformhoz is, csak uj verziot nem adnak ki. Amire te gondolsz egyebkent az az NDS/eDirectory, es semmi koze a Netware platformhoz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Amire én gondolok, az a Novell szerint "Just like Netware, Only better", vagyis a Novell Open Enterprise Server. Ami ha akarsz Linux alapon, ha akarsz Netware alapon telepítesz :)

Nyilván tisztában vagyok vele, hogy mi a különbség, ezért tettem a Netware-t idézőjelek közé.

--
trey @ gépház

Szerintem nem a fejlesztési modellel van baj, hanem azzal, hogy nem tudod elképzelni, hogy ezt a fejlesztési modellt is lehet keretek között tartani. Símán csak nincsen meg hozzá a tudásod és a tapasztalatod, hogy erre milyen eszközök és lehetőségek vannak. Ez nem baj. Tanulható képesség. ;) Tanulj! :D

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

+1
Ezért tervezem a Linux rohadtgyors leváltását. Az évek alatt amíg használtam, sokmindent csinált, de kész, az nem lett. 5 éve még volt türelmem várni hogy a 0.0.5beta libek meg felhasználói programok "beérnek", ez a türelem elfogyott, mert azóta sem volt előrelépés (kb kiadták a 0.5.0beta-t), sőt desktopon még sokkal szarabb is lett (serveren használható).
Nem hiszem hogy arről kéne szóljon az opensource, hogy minden erőforrást szétforgácsolnak, és/vagy csak az újításokat tolják a termékbe, teszteletlenül, hibáktól hemzsegve, összehányva.

"a 0.0.5beta libek meg felhasználói programok "beérnek"" ez most is így van, vagy megírod magadnak a libet és akkor várhatod amíg beérik, vagy valaki más írja meg te meg csak használod, és akkor megint csak várhatod, a felhasználó programok terén viszont vannak kiforrott programok nem akarok példálózni mert nem akarok hitvitát ebből.

Pont itt van a gond. Hiaba vannak nagyon jo, sot kivalo programok, ha egyszeruen az alaprendszerben (es itt nem csak a kernelre, hanem a userlandre is gondolok) inkabb az otletszeru fejlesztes a jellemzo, semmint a stabil termekkent torteno pozicionalasra. Ami Linuxot kulonbozo disztributorok arulnak, az nem egy stabil termek, csak a rendszer egy-egy olyan allapota, amikor epp stabil volt (akarom mondani, kezelheto mennyisegu bug volt benne). Nincsenek egyseges tervek, jol felepitett standardok, amihez mindenki igazodna. Es igazabol nincs is eszkoz a kezedben arra, hogy a fejlesztoket erre ravedd, mert a tobbseguk hobbybol csinalja amit csinal, es a maga reszerol nem szivesen veszi a rendreutasitast. Ha szetnezel magad korul, te is talalsz rengeteg ilyen projektet.

Jo a bazar modell, nagyon sok elonye van neki, de mara a bazar ledontotte a falakat, es mar mindenutt csak zsibongas van, nem lehet ertelmesen gondolkodni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Minek? Miért kell mindenhova erőltetni ezt a forgácsoljuk kismillió irányba a fejlesztéseket, nehogy már egyvalami is elkészüljön elvet? "

Attól még, hogy egy rendszer alkotó részeit más rendszerekre is átviszik, még lehet együttműködni.

" Vannak, akik szeretnek kész*, működő szoftvereket is látni, nem csak egy folyamatosan változó valamit."

Nyilván. De ők nem SkyOS-t használnak. Igaz én még nem is nagyon láttam- az összes találkozásom vele egy bootoláskori fagyással végetért - úgyhogy lehet kijavítani, de az összes hozzászólás amit olvastam róla Osnews-on, itt-ott amott mindig kiemelte, hogy mennyire bugos.
Stabilnak hívott kiadása sem volt már egy jó ideje.

"*kész: _stabil_ és _kitesztelt_ szoftver, amelynél napi használat során nem kell attól félni, hogy szanaszét hányja magát vagy hogy az x.0.a+1 verzióban áttúrnak valamit."

Ez a fejlesztő gárda hozzáállásától függ és nem attól, hogy nyílt vagy zárt a kód.

Most így lepereg a szemem előtt, hogy a halálra ítélt "one man show" szétforgácsolódik... Itt arról van szó, hogy vagy lesz _valami_ vagy ha nem, akkor ennek konyec... Az utóbbinál az általad említett "szétforgácsolódás" - jelentsen bármit is - jobb, mert benne van a _lehet bármi még belőle_ lehetősége.

--
trey @ gépház

Igen, ez benne is van a "Katedralis es a bazar" c. muben: Ha mar nincs idod a projekttel foglalkozni, vagy elvesztetted az erdeklodesedet iranta, az utolso kotelesseged, hogy atadod egy megfelelo utod kezebe.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

nekem az perget le, hogy majd zamboriz tovabbfejleszti linux alapokon, a forradalmi sajat fejlesztesu bufferkodjat beleolvasztva, denes meg majd felgyorsitja sparc asm betetekkel es netbook piacon terde kenyszeritik a microsoftot vele

nagyon szorakoztato gondolatkiserlet volt

--
When in doubt, use brute force.

Mivel nem azt írtad, de nyílván az én hibám, hogy ha valaki a stabil, letesztelt szoftverekről áradozik akkor nem értem a mögöttes mondanivalót.
De mivel te sem vagy túl jó szövegértésből ezért leírom neked egyszerűbben:
1. az, hogy valami nyílt forrású még nem biztos, hogy szétforgácsolódik, akármit is jelentsen az.
2. a SkyOS jelenleg halott. Ennél csak jobb lehet, beleértve a szétforgácsolódást (majd ráérő idődben írd le, hogy nálad ez mit jelent) is.

A Haikura sincs "ipari mennyiségű" driver, pedig kezdettől fogva, évek óta van körülötte egy kicsi, de erős közösség... ha a SkyOS-t megnyitnák, semmi garancia nem lenne arra, hogy odaözönlenek az emberek fejleszteni. Sőt a valószínűsége is kicsi :(

Istenigazából a driverhiány túlélhető, ha gondolsz egy merészet, és az OS-hez rakod össze a gépet. Itt persze az asztali gépekre gondolok, mert a laptopoknál meg vagy lőve. (mint én a haiku+eeepc párossal) A haiku a közésségét főleg örökölte a BeOS-tól, bár vannak új arcok, ez tény. A SkyOS -nál éppen úgy nem lenne garancia semmire, mint ami jellemző az összes nem gyártók által tolt projecktekre. Az elvitathatalan tény, hogy egy m$, vagy ibm, sun ha csinál valamit, akkor gyakorlatilag végig viszi, és igyekszik kulcsra készen az asztalodra tenni. De messze nincsen kész. Az én meglátásom az, hogy soha, semmilyen szoftver termék nem lehet "kész". Vagy fejlesztik, vagy már nem fejlesztik, de kész sosem lesz. Még a windows sincsen sosem készen, állandóak a patch hegyek, service pack-ok, amik egy idő után elapadnak, és jön egy másik windows. sosem lesz készen, csak már nem fejlesztik az X kiadást, csak az Y kiadást. Ez kivált képpen igaz a nyílt forrású szoftverekre. Én úgy látom, hogy ha valaki kijelenti, hogy a linux készen van, akkor az semmi mást nem jelent, mint azt, hogy már nem fogják tovább fejleszteni :)))) (akkor meg azon menne a sírás :))) Azért támogatnám a skyos megnyitását, mert ezzel lenne esélye a további fejlődésre (garancia persze nincsen) így viszont ha egy gyártó nem vásárolja fel, hogy majd ő "befejezi" akkor egyszerűen elhal az egész a semmibe. Átmeneti megoldásként tudnám javasolni (kitapogatni, hogy melyiknek lenne jövője) ha nem nyitnának forrást, hanem mindössze fél évig letölthető lenne a legutolsó build, és akinek van kedve megsasolná. Még azt is el tudom képzelni, hogy nem is kell forrást nyitni, csak a 100e letöltés hozna 30 olyan figurát, aki szívesen beszállna a fejlesztésbe, és menne tovább a projeckt.

--
A linux felhasználóbarát. mindössze megválogatja a barátait...

"De messze nincsen kész. Az én meglátásom az, hogy soha, semmilyen szoftver termék nem lehet "kész"."

Akkor definiáljuk a kész szoftvert. Én így szoktam:

Kész az a szoftver, amely az előírt funkcionalitásban teljes, nem remdelkezik semmilyen ismert, megakasztó vagy súlyos hibával.

Javítás, vagy javító kiadás: olyan, a már kész szoftverhez készült kiadás, amely a kész szoftverben a kiadás óta kiderült hibákat javítja úgy, hogy annak funkcionalitása nem változik.

Előírt funkcionalitás: adott release-ra tervezett összes feature.

----------------
Lvl86 Troll

a szoftver sosincs kész. a _szoftver_. nem egy milestone, nem egy release.

"amely az előírt funkcionalitásban teljes"

legjobb tudomásunk szerint.

"nem remdelkezik semmilyen ismert, megakasztó vagy súlyos hibával"

ATM.

aztán jön új követelmény, új hiba, új környezet, stb. never ending story. (nyilván olyan szoftverről beszélünk, amit használnak is)

"aztán jön új követelmény, új hiba, új környezet, stb. never ending story. "

Az már a következő verzió, az egy külön történet. Az egyáltalán nem jelenti azt, hogy bele kell pancsolni az új funkciót a régibe és átvariálni gyökerestül, mikor a régi verzióban teszem azt csak egy hibát kell javítani.

----------------
Lvl86 Troll

"Az már a következő verzió, az egy külön történet."

még szerencse, hogy direkt leírtam, "a szoftver sosincs kész. a _szoftver_. nem egy milestone, nem egy release."

"Az egyáltalán nem jelenti azt, hogy bele kell pancsolni az új funkciót a régibe és átvariálni gyökerestül, mikor a régi verzióban teszem azt csak egy hibát kell javítani."

ki mondott ilyet? csupán arról volt szó, hogy sosincs kész, és ez még akkor is így van, ha fölöslegesen végletekbe esel ("pancsolni", "átvariálni gyökerestül")

Viszont kulonbseg van a szoftver, mint fogalom, es a kiadott verzio, mint fogalom kozott. Amirol te vegig beszelsz, az egy adott kiadott verziora vonatkozik.

Vagy, ha erkezik egy uj feature-request, akkor uj szoftvert gyartotok? Vagy inkabb a meglevonek egy ujabb verziojat? Na errol van itt szo.

Es akkor helyesen:
Egy szoftver sosincs keszen, hiszen mindig vannak uj igenyek, uj problemak. Egy adott szoftver _verzio_ akkor van keszen, ha megfelel az _eppen aktualis_ kovetelmenyspecifikacionak, es nincsenek benne ismert problemak.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igazad van, jobb lenne a kiadás vagy a [szoftver]termék kifejezés.

"Vagy, ha erkezik egy uj feature-request, akkor uj szoftvert gyartotok?"

Alapvetően annál a projektnél, amin most dolgozok, van egy 1.0.x-s ág, amibe mennek a karbantartások, javítások és van egy 1.1.-s ág, amibe mennek az új feature requestek. Mindezt azért, mert ha jelentősen nem is, de fog változni itt-ott működésben a rendszer: nem ugyanaz a szoftver, mint az előző verzió.

----------------
Lvl86 Troll

Nyilvan vannak kulonbsegek, azonban szamomra az uj szoftver ott kezodik, amikor strukturalisan, kinezetben, kezelesben teljesen mas programot gyartunk. Ahol nincsenek ilyen nagymervu valtozasok, ott nincs sok ertelme uj szoftverrol beszelni, maximum megujultrol.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( numen v | 2009. 06. 11., cs – 12:12 )

Szerintem semmiképpen se nyissa meg. Annyi munka van benne, jó lenne, ha eladható lenne – és jelen esetben a szokásos nyílt forrásos árutámogatással való bevételgenerálás a kis méret miatt nem működne.

Örülnék neki, ha a srác megkapná a munkájáért, amit elvár. (jól sejtem btw, hogy a cucc csak NetBSD kernellel maradhat zárt?)

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Ohatatlanul lesznek dolgok, amihez az atveendo kernel kodjanak piszkalasara van szukseg, Viszont, mivel ezek SkyOS specifikus modositasok, logikus oka nincs neki, hogy visszakuldje az upstreambe, hiszen a SkyOS _nem nyilt_, es mas valoszinuleg nem profital belole.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( prygme | 2009. 06. 11., cs – 17:46 )

ma akkora divat a virtualizáció. akár ez is lehetne a megoldás.