Lassulhat a Linux kernel fejlesztése
2005. április 7. 12:30, csütörtök
A Linux kernel fejlesztéséhez használt Bitkeeper készítője bejelentette, hogy megszünteti a program nyílt forráskódú változatát, és teljesen az üzleti alapú szoftverre áll át - Linus Torvalds egyelőre nem döntött a szoftver további alkalmazásáról.

Hirdetés

Larry McVoy, a Bitkeeper tulajdonosa bejelentette, hogy fokozatosan leépíti a program nyílt forráskódú változatának fejlesztését, és tervei szerint júliusra teljesen az üzleti alapú szoftverre áll át. McVoy azzal indokolta döntését, hogy az üzleti alapú változat iránt jóval többen érdeklődnek, és csak úgy maradhat talpon a versenyben, ha minden erőforrást erre a vonalra irányít át.

A szakemberek szerint döntés nagyban befolyásolja a Linux kernel fejlesztésén dolgozó programozók és különböző csoportok munkáját, akik nagyrészt a program nyílt forráskódú változatát használták. A végső döntést azonban Linus Torvalds hozza majd meg, aki egyelőre kitért ez elől, és bejelentette, hogy egy hétig távol tartja magát az internettől. A Linux atyja elárulta, hogy aktívan tanulmányozza az esetleges alternatívákat, de a Bitkeeper nélküli világ jelenleg szürkének és borúsnak tűnik számára.


Torvalds közel három évvel ezelőtt döntött a program alkalmazása mellett, amely az elmúlt években nagy segítségére volt a fejlesztőknek, és jelentős mértékben felgyorsította a Linux kernel fejlesztését. A diákként híressé vált programozó azonban most fontos válaszút elé került: vagy ragaszkodik a program használatához - és ezzel belenyugszik abba, hogy a nyílt forráskódú operációs rendszer kernelének kibővítését üzleti alapú szoftveren végezzék - vagy egyéb fejlesztői eszközök után néz, és megpróbálja a lehető leggyorsabban végrehajtani a váltást.

Amennyiben az első változat mellett dönt, Torvalds valószínűleg kiváltja majd a fejlesztők ellenérzését, és megingathatja saját posztját is, míg a második esetben a kernel fejlesztésének lelassulásával kell számolnia, ami viszont a felhasználók körében válthat ki felzúdulást. A döntés azonban nem várathat magára, és Torvaldsnak az elkövetkezendő hetekben választ kell adnia arra kérdésre, hogy melyik úton haladjanak tovább.
Kapcsolódó linkek
Megosztás
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
 

IT/Tech, Hardver
Tudomány, Mobil, Film, Játék
King Arthur II - The Role-playing Wargame Kiadó: Paradox Interactive Fejlesztő: Neocore Games Honlap Rendszerkövetelmények: Minimum: Dual Core E2180 2,0 GHz-es processzor, 1,5 GB RAM, GeForce 8800 GTS vagy Radeon HD 3850 X2 grafikus kártya, 16 GB szabad hely a merevlemezen Ajánlott: Core 2 Quad Q6600 2,4 GHz-es processzor, 2 GB RAM, GeForce GTX 460 SE vagy Radeon HD 5830 grafikus kártya, 16 GB szabad hely a merevlemezen Hasonló játékok: King Arthur, King Arthur: The Druids, King Arthur: The Saxons, Total War-sorozat Kategória: stratégia A játékosok közül bizonyára nagyon sokan emlékeznek még 2009 zimankós novemberére, amikor a magyar játékfejlesztés történelemkönyvébe egy újabb fontos fejezetet írt a hazai Neocore Games csapata.Harmadára csökkentették a Sigma SD1 árátA Sigma gyártástechnológiai változtatásokra hivatkozva radikálisan átalakította csúcskategóriás készüléke, az SD1-es árazását.LG Optimus Vu és Miracle, új Nokia Egyszerre három új okostelefonról futott be hír a napokban, bár ezek közül csak kettőről tudjuk, hogy nagyjából mire is számíthatunk.Félmillió állás az appfejlesztésben Csak a tengerentúlon majdnem félmillió új állást köszönhetnek az okostelefonra és tábla PC-re fejlesztett appok megjelenésének és immár széleskörű alkalmazásának, bár ez a terület gyorsan változik.Élet Julian Assange árnyékábanJacob Appelbaum pontosan tudja, hogy milyen az, ha valakit megfigyelnek.
Hirdetés



Hozzászólások
A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
2005. ápr. 09. 02:10 | válasz | #43
Ez a hír még mindig nem igaz, akármilyen jó is a C. Szánalmas, hogy egyesek úgy fordítanak, hogy közük sincs a nyelvhez. Nekem ilyen tanáraim vannak..... és azt merik állítani, hogy tudnak angolul. :(
2005. ápr. 08. 21:26 | válasz | #42
OK, most nem értem mi a gond? Mert én is kb. ugyanezt mondtam, kivéve, hogy a C teljesítményelőnye nem nyelvi, hanem programozási szokásokból ered, de tény, hogy C-ben álltalában gyorsabb kódot írnak.
2005. ápr. 08. 21:21 | válasz | #41
Elirtam, "nem irjak C++ -ban"
2005. ápr. 08. 20:19 | válasz | #40
Hanyszor mondjam meg, hogy DE, ELVI PERFORMANCE okok miatt nem irjak a lowlevel eszkozkeloket, drivereket, kernel modulokat C-ben. Ez teljesen egyseges unix es win alatt. Nem is varhato a jovoben, es magam is szakmailag hibas dontesnek tartanek magasabb szintu eszkozokkel operalo nyelvben kernelszintu kodok irasat.
CAD  
2005. ápr. 08. 17:18 | válasz | #39
Egyetertek.

"szerintem a Linux és a többi UNIX-ok (AIX, Solaris...) és a Windows annyira uralják és uralni fogják a közeljövőben is az OS piacot, hogy nem igen hiszem, hogy hamarossan látni fogunk valami komolyabb kernelt ami nem C-ben van. Persze sokszor már gondolkodtam rajta, hogy nem lenne rossz ha valaki leülne és a mai tudást alkalmazva alapossan átvizsgálná a meglévő OS-eket és ezek alapján egy új modern de magassan kompatibilis kernelt írna... de hát ez csupán egy ostoba utópia..." - igen sajna ez utopia, egyszeruen vagy bele sem kezdenenek, vagy ki sem derulne, azaz nem tudna teret nyerni maganak a sok nagy mellett.
2005. ápr. 08. 17:13 | válasz | #38
"milyen Brian?"
bocs, elgépeltem... Bjarne

továbbá, azt hiszem, hogy egyetértünk abban, hogy nem a C++-ban van a hiba, hanem abban, hogy általában a forítóban és abban, hogy a programozók C++-ban hajlandóbbak a fordítóra támaszkodni, míg C-ben inkább maguk optimizálnak...

szerintem a Linux és a többi UNIX-ok (AIX, Solaris...) és a Windows annyira uralják és uralni fogják a közeljövőben is az OS piacot, hogy nem igen hiszem, hogy hamarossan látni fogunk valami komolyabb kernelt ami nem C-ben van. Persze sokszor már gondolkodtam rajta, hogy nem lenne rossz ha valaki leülne és a mai tudást alkalmazva alapossan átvizsgálná a meglévő OS-eket és ezek alapján egy új modern de magassan kompatibilis kernelt írna... de hát ez csupán egy ostoba utópia...
CAD  
2005. ápr. 08. 16:36 | válasz | #37
"de akkor kérlek magyarázd el nekem, hogy miért van a UNIX történelmi kernelén "

Nos ebbe nem latok bele, nem sok ember fejleszt kernelt ugy hiszem - szoval ezt amolyan koltoi kerdesnek ertekelem. Mindenesetre ket okot konnyeden tudnek mondani: 98 ig a C++ nem rendelkezett ISO szabvannyal es szamos dolog modosult az eltelt ido alatt – ergo kozel sem volt stabil, tovabba a forditok is csak igen nagy kesessel tudtak kovetni a valtozasokat. Masik pedig az, hogy gyakorlatilag minden eddigi kod C-ben volt irva, igy elkepzelheto, hogy nem lett volna tul koltseghatekony atalni C++-ra…


"hogy egy kernelnek nincs szüksége az OO dolgokra"

Azt hiszem ezen nem veszunk ossze, de mint leirtam a C++ csak egy resze az oo tamogatas... kicsit tobb ettol az a stuff.

"nem Brian az aki az elhangzottakat elmondta" - milyen Brian?



"nagyon sok igazságot is lehet benne találni... ha nem hiszed el, akkor vagy nem dolgoztál C-ben, vagy nem dolgoztál C++-ban " - elnezest, de nem emlexem hogy a tartalmaval kapcsolatba mondtam volna valamit... igy teljesen felesleges ilyen nagy arcal lenni.

“sokszor nem implementálják tökéletessen a C++-“ legjobb tudomasom szerint egyedul a Commo fordito olyan, amely magat szabvanyosnak mondja.



“Termeszetesen hatkonysagi, optimalizacios okokbol irnak ma minden kernel modult win es lin alatt egyarant C-ben. Es ez igy is fog maradni meg legalabb ot evig.” – en erre nem vennek merget, C++ is lehet olyan hatekonyan kezelni mint egy C-t… altalanossagba nem hinnem, hogy igaz lenne.


Ha viszont a hatekonysag a minden, akkor irjunk Fortranba mert az meg a C-nel is hatekonyabb kodot general talan, vagy ASM… vagy gepi kod :). Szoval mas szempontok is vannak, es elkepzelheto, hogy az aranykozep utnak jo ideig a C szamitott… de nem hiszem, hogy ez egy betonstabil torveny lenne.
2005. ápr. 08. 15:47 | válasz | #36
Nem! A C-ben álltalában gyorsabb kódot irnak, mert a programozók kicsit gépközelebbről figyelik a dolgokat, C++-ban viszont már objekt orientált szemmel figyelik a dolgokat és ezért lasabb kódot írnak (persze ez nem mindég van így), viszont a C++ fordítók álltalában sokkal kevésbé optimizálnak és sokszor nem implementálják tökéletessen a C++-t. Ez valószínűleg maga a C++ összetettsége miatt van (a C-hez képest), de azért nem mondható a C-re, hogy gyorsabb, csak az mondható, hogy C-ben a programozótól függ, míg C++-ban sokszor a fordítótól.
2005. ápr. 08. 15:02 | válasz | #35
A C sokkal gyorsabb mint a C++, bár az utóbbiban gyorsabb és átláthatóbb a fejlesztés.
2005. ápr. 08. 12:23 | válasz | #34
Es persze a drivereket is.
2005. ápr. 08. 12:22 | válasz | #33
Termeszetesen hatkonysagi, optimalizacios okokbol irnak ma minden kernel modult win es lin alatt egyarant C-ben. Es ez igy is fog maradni meg legalabb ot evig.
2005. ápr. 08. 11:26 | válasz | #32
OK, legyen úgy, de akkor kérlek magyarázd el nekem, hogy miért van a UNIX történelmi kernelén kívül pl. a Linux (amikor Linus elkezdte irni, akkor én már régen nyomtam a Borland C++-t, tehát volt, de volt g++ is...), de ez szintén elmondható a Windows NT kernelre is, meg a még később született WindowsCE-re, de szintén C-ben van a HURD is, meg pl. a Plan9 microkernele... és sorolhatnám, de most semmiképpen sem jut eszembe egy OS kernel sem amely esetleg C++-ban lenne...
Na nem kell mérgelődni, mert a C++ szerintem és sok más fejlesztő szerint is szuper nyelv, hatékony és stb. de itt azok a dolgok mellett érvelek (a szerintem jelzővel), hogy egy kernelnek nincs szüksége az OO dolgokra, inkább maximálissan gépközeli kell, hogy legyen, a C az megfelel, de jobban szeretném ha a kernel sima gépi nyelven lenne irva, csak sajnos akkor dög nehéz lenne a portolás, ezért jött be a C, amelyet sokan portabilis gépi nyelvnek is hívnak, nem véletlenül...
Ja a kamu interview-et, meg már évek óta ismerem, csak most érdekesnek tartottam, hogy ide hozzam (hátha valaki nem ismeri), és azon kívül, hogy kamu, vagyis, hogy nem Brian az aki az elhangzottakat elmondta, nagyon sok igazságot is lehet benne találni... ha nem hiszed el, akkor vagy nem dolgoztál C-ben, vagy nem dolgoztál C++-ban (vagy nagyon keveset).

----------------------------------------

During the recent discussion, when it was suggested that perhaps the kernel is written in C simply because "we've always done it that way...", Linux creator Linus Torvalds joined in to explain:

"In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

"The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

és én nem hiszem, hogy Linus-nak problémája lehetnek... nem hiszem, hogy egy olyan ember mint ő FUD lenne.

Persze sok mindenhez jobb a C++, de sok komoly kernelfejlesztő szerint a kernelhez nem... amint már sokszor mondtam a ONE SIZE FIT ALL filozófia egyrészt sohasem igaz, ha pedig erőszakolják akkor káros...
h4x0r  
2005. ápr. 08. 10:53 | galéria | válasz | #31
"Egyébként mivel tud többet ez a BitKeeper, mint ha CVS-t használnának?"

A CVS sokak szerint a bugware iskolapeldaja. Van egy valagnyi hianyossaga es sebezhetosege. Az SVN egy kicsit jobb, de van az OS verziokezeloknek nehany hianyossaguk, ami (Linus szerint) elengedhetetlen a Linux fejleszteseben, pl.:
- A bekuldott patch-eket tetszes szerint kombinalhassuk. Ez CVS/SVN-ben bonyolult.
- Elosztott repriosityk (tehat a projekteket elosztva tarolja)

Kb. ez a ketto jut eszembe.
2005. ápr. 08. 10:52 | válasz | #30
Ha tudnál angolul akkor nem ugatnál le. Ez úgy volt, hogy a BitMover a BitKeepert Open Source projectek részére ingyen adta. És ez szűnt meg. És egy nyílt forrású klienst adtak helyette.

"As part of this focus, BitMover has replaced the free version of BitKeeper with the recently released open source BitKeeper client."

Ez a mondat az általad megemlített linkben van. Nem szoktam fikázni a levegőbe, csak rámutatok arra, amikor a cikk írójnak gőze nincs, hogy mi van angolul leírva. (És ez rengeteg esetben előfordul itt.) A nyílt forrású kliens új dolog, nemrég jelentették be, szóval az nem szűnhet meg. Másrészt a nyílt forráskódot nem lehet megszüntetni, hisen mindenkié.
CAD  
2005. ápr. 08. 09:13 | válasz | #29
Ahogy yeti is irta, ez mar egy nagyon regi szakallas kamu...

"Szerintem" pedig az ilyen "szerintem erdemesebb kernelt C-ben irni" beszolasokat nem erdemes nagyon nagy dobra verni, mert ott kicsit tobb erv szol egyik es masik mellett mint a "szerintem"...

Amugy "szerintem" a legfontosabb ok tortenelmi, es nem feltetlenul hatekonysagra vezetheto vissza...

Yeti: a C++ nem OOP nyelv, a C++ multiparadigmas nyelv, melyben vannak eszkozok strukturalt, oo, generikus/generativ/aspektus orinetalt... sot a templateknek koszonhetoen meg funkcionalis nyelvi eszkozszerusegeket hasznalatara.

Tovabba fontos megjegyezni, hogy a Cpp reszhalmaza a C nyelv, igy pl gcc legjobb tudomasom szerint a g++ egy specialisan paramterezett valtozata... remelem vilagos, hogy mire akartam celozni.
2005. ápr. 08. 08:55 | válasz | #28
Utalom az olyan hireket ill. cikkeket amik cime felteteles modban van vagy kerdojel van a vegen.
"Lehet h minden windows felhasznalo meleg?"
"Csokkenhet az sg olvasottsaga."
"Hulyithetok az emberek buta hirek cimeivel?"
"Az oralis szex jo a fogszuvasodasra?"

Heh... "Lassulhat a Linux kernel fejlesztése" Miert? Mert egy verzio kezelo, szoftverfejlesztest segito program fizetos lesz? Nevetseges. Van egy tonna alternativa. A regi verziot meg nem lehet fizetosse tenni, ha eddig jo volt, akkor hasznalhatjak tovabbra is.
Version Control (479 projects)
Version Control (304 projects)
Persze atfedes lehet, de egybol azzal jonni h 'Lassulhat a Linux kernel fejlesztése'....
Ez kicsit FUD szvsz.
-Orgi-
Yeti  
2005. ápr. 08. 01:54 | válasz | #27
Haha, ez az interview már nagyon régóta kering az interneten, elég érdekes is, csak annyi a baj vele, hogy kamu. De mindegy.
Egyébként tényleg igaz, kernelt jobb nem objektum orientált nyelven írni, mivel gyorsabb egy C ben írt kód. Viszont sokkal nehezebb és lassabb is C ben programozni. Meg egyébként is Unixoknál tényleg C-ben írnak szinte mindent.

Egyébként mivel tud többet ez a BitKeeper, mint ha CVS-t használnának? CVS-hez meg létezik baromisok kliens... Vagy ha az nemjó, nem hiszem, hogy néhány hét alatt nem tudnának összedobni maguknak valami BitKeeper szerűséget GPLesen. Nahmindegy, csak nemértem, hogy hol van itt az a hatalmas katasztrófa.
2005. ápr. 08. 01:27 | válasz | #26
http://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html

egy érdekes link...

itt most nem akarok a C++ ellen beszélni, hisz sok mindenhez jobb a C-nél, de szerintem is a Kernelt C-ben a legjobb irni...
Cat  
2005. ápr. 08. 00:50 | galéria | válasz | #25
fikázás helyett csak a cikkben lévő legelső linkre kellett volna kattintanod:

"BitMover announces accelerated commercial development strategy and migration plan for Open Source users"
2005. ápr. 08. 00:32 | válasz | #24
Ahogy én olvastam a hírt másutt. A freeware változat szűnik meg, és az opensource kliens marad. Szerintem már megint kevertek az SGsek.....
h4x0r  
2005. ápr. 07. 18:57 | galéria | válasz | #23
"a képen is c van. ugye, ugye, nem mindenre jó a c++, meg a java."

A UN*Xok nyelve a C. A Java, C++, stb. pedig nem igazan fernenek bele a kernel "modelljebe" :-)
CAD  
2005. ápr. 07. 18:56 | válasz | #22
Ezt most miert irtad? :D Remelem erzed, hogy hulyeseg amit irtal...
2005. ápr. 07. 17:56 | válasz | #21
Az én igényeimnek túlságossan gyenge, inkább egy duál G5-öt de nem MacOSX-el hanem Linuxal...
Equ  
2005. ápr. 07. 17:38 | válasz | #20
"valszeg a szerver értékesítésben nincs olyan nagy hányada a winnek."

Blackrose megelőzött konkrét adatokkal, én csak annyit tudtam, hogy winből többet adnak el, mint az összes többiből összesen, tehát nagyon nem reprezentativ, hogy te milyen ibm szerverekkel találkoztál :)
2005. ápr. 07. 17:35 | válasz | #19
Mac mini sztem egész elfogadható áron kapható.
2005. ápr. 07. 17:21 | válasz | #18
Az IBM szerverértékesítése a 2004 harmadik negyedévében a következő:

UNIX = 1.05 billion
Linux = 219 million
Windows = 2.13 billion

mint láthatod a Windows jól tartsa magát az IBM-nél, mert a kis és középvállalkozások piacán a blade x86 szerverek nagyon keresettek és álltalában Windows-al veszik őket (ezért is virágzik a MS szerver részlege).

A Linuxnak nagy a betörése (pl. az említett időszakban 42.6%-al lett nagyobb, míg a Windowsnál ez 13.3% plusz, a UNIX-ok meg sajnos az IBM-nél 2% plusz, de ha az egéssz piacot nézzük akkor 2.3% minusz volt az elöző időszakhoz képest)

Ott ahol a Linux viszont verhetetlen az a custom szerver piacon, kis szerverek 1 CPU-val és nem is szerver CPU-val, itt nagy előnye éppen azért mert free. A fenti NAGY szerverpiacon ugyanis a Red Hat Enterprise az urlkodó kb. 60% piaci részesedéssel, aztán jön a SUSE Enterprise a többiekre meg nem igen jut semmi. A custom szerverek piacán viszont van minden fajta Linuxból jocskán.

Persze nem tudom most ennek mi köze a Linux Kernelhez, de ami az IBM-et illeti így áll a bál.

Az IBM gőzerővel dolgozik a POWER elterjesztésén, és remélem sikeressek lesznek ebben, mert amióta volt alkalmam POWER-rel is dolgozni mondhatom, hogy nagyon szuper, mindegy, hogy Linux vagy AIX fut rajta (az AIX jelenleg fényévekkel jobb OS, de a Linux napról napra fejlődik...)

Nem tudom, hogy sikerül e ez nekik, de mindenesetre én azon töröm a fejem, hogy az asztalomra dobjak egy Power alapú gépet... csak ne lenne olyan drága...
yy   "Rest in Peace yy" 
2005. ápr. 07. 16:50 | válasz | #17
a képen is c van. ugye, ugye, nem mindenre jó a c++, meg a java.
strogg  
2005. ápr. 07. 16:25 | válasz | #16
:))
Tényleg nem találkoztam még wines ibm szerverrel.
valszeg a szerver értékesítésben nincs olyan nagy hányada a winnek.
Equ  
2005. ápr. 07. 16:06 | válasz | #15
ez az azért jó erős önbizalomra vall... :)

strogg  
2005. ápr. 07. 16:04 | válasz | #14
Equ:

Lehet tévedtem valóban.
Mindössze sosem futottam még össze wint futtató ibm szerverrel, innen vettem az infot.
strogg  
2005. ápr. 07. 16:02 | válasz | #13
neeeem. Nem katasztrófális.
A linux ennél nagyobb kihívásokakl is szembenézett már,és legyűrte.
Én pl nagyon féltettem, amikor az SCO elkezdett pampogni.
Mert egy fejlesztői program hiányát lehet pótolni. De amikor a nyílt forrást helyezik törvényen kívül a linux által, (talán nem kell mondanom, hogy a linux halála a nyílt forrás halála lenne) az végzetes csapás, kikerülhetelen probléma.Olyan mint kés a nyakba.
De túlélte. (Gondolom redmondban most ismét külön kamion járat szállítja a fejfájás csillapítót)
Szóval én nem aggódom.

A másik véleményem pedig az, hogy linus inkább ülljön a kérdésen még vagy 2 hetet, és a kernel team által közösen alaposan megtárgyalt megoldást publikáljon. Nem mondom, hogy rosszul döntött, de én még ültem volna rajta kicsit:)
Equ  
2005. ápr. 07. 16:00 | válasz | #12
"Ha figyelmesen olvastad a hírdetést észreveszed, hogy ez a kliens gépekre él."

Tényleg? Én meg már azt hittem az XP-t a szerverekre rakják. Te jó ég...

"Az IBM nem szállít szervert winnel. (tudtommal.)"

Hát rosszul tudod... Az entry level serverektől (microsoft small business serverrel) egészen a datacenter server-ig az összes microsoft server termékkel árulja a szervereit az ibm...

Csak egy apró példa: http://www-1.ibm.com/servers/eserver/xseries/windows/index.html
Laci73  
2005. ápr. 07. 15:41 | galéria | válasz | #11
Ez a hír, ha igaznak bizonyul, katasztrófális.
2005. ápr. 07. 15:29 | válasz | #10
Linus már döntött...

http://marc.theaimsgroup.com/?l=linux-kernel&m=111280216717070&w=2
pemga  
2005. ápr. 07. 15:29 | válasz | #9
Nem, még csak nem is opensource. Voltak tervek, hogy megírják GPL-esen nulláról: KitBeeper :), de végülis nem tudom mi lett vele. Lehet, hogy most újra előkerül ez a kérdés.

Másrészt nem _visszavenni_ akarják a progit, hanem a free felhasználásra szánt részét nem feljesztik tovább.
pemga  
2005. ápr. 07. 15:21 | válasz | #8
Ez igaz, de a BitKeeper nem GPL-es. Volt is ebből morgolódás, amikor elkezdték használni. Most úgy tűnik, hogy szívnak is ezzel a döntéssel most...
strogg  
2005. ápr. 07. 14:20 | válasz | #7
Csatlakozom az elöttem szólóshoz:)
Alap dolgokat felejtettek el beleírnia cikkbe.
1. ami egyszer nyílt forrású volt, és GPL alatt aadták ki, azt nem lehet visszavonni. A valami 1.0 licensze az is marad. Majd a valami 2.0 lehet az új licensz alatt. (az SCO per egyik legnagyobb melléfogása, hogy ehhez nem így álltak hozzá)
2. linus nem azért vonult vissza a kérdéstől, mert kattognak a fogai a félelemtől, hogy jajj mi lesz, hanem megvizsgálja a kérdést. Kiváltható-e, van-e értelme a "régit" használni, az új lincenszű verzióra kb: meddig halogatható az átállás.
Equ.
Ha figyelmesen olvastad a hírdetést észreveszed, hogy ez a kliens gépekre él. Az IBM nem szállít szervert winnel. (tudtommal.)
2005. ápr. 07. 13:49 | galéria | válasz | #6
Amit egyszer Free-ként leszedtek , azt nem lehet visszakérni :]

Ráadásul úgyis nyílt forrású a program , nem ? De. Akkor meg majd keresnek pár lelkes fejlesztőt hozzá és meg van oldva... tehát vagy valami fontos info hiányzik a cikkből, ami meggátolja az általam felvázolt alternatíva keresztülvihetőségét, vagy csupán egy semmitmondó hírről van szó ..
smv  
2005. ápr. 07. 13:30 | válasz | #5
Hm. De ha fizetőssé válik, akkor a régi verziókat sem használhatják freenek?
Equ  
2005. ápr. 07. 13:11 | válasz | #4
szépen meglovagolták a linux hype-ot, előnyre tettek szert vele, és mostmár arra koncentrálnak amiből meg is lehet élni...
De nem kell meglepődni ugyanezt csinálja az ibm, novell, sun és a többi nagy "linux támogató" is, kihasználja a sok szemellenzőst aki elhiszi, hogy ezek a cégek a linuxnak jót akarnak... Közben meg megy a hvg-ben minden számban a 2 oldalas ibm hirdetés, amiben az "ibm vállalati környezetbe a windows xp-t ajánlja" LOL :))
2005. ápr. 07. 13:11 | válasz | #3
"A végső döntést azonban Linux Torvalds hozza majd meg"

Nem inkabb Linus Torvalds?
2005. ápr. 07. 13:10 | válasz | #2
A régi free verzióval még simán fejleszthetnek egy darabig és más eszközre való áttérésig így nyerhetnek egy-két évet.
2005. ápr. 07. 12:35 | válasz | #1
és ezt így hogy?