Hozzászólások
-
Bejegyzés
-
Az elsőnél egy ISO8859-2 kódolású rendszerhez fel van telepítve egy UTF-8 kódolású csomag. A másodiknál mintha fordítva lenne. Melyik Suse disztribet használod?
„Photoshop, ACD See,CorelDRAW, 3D Studio Max, Reason, Cubase, MS Office, Visual Basic,SoulSeek, Winamp, Nero, stb.”
Ha jól értem, akkor azért sírsz mert a „nagy” linux alapból nem tudja ugyanazt, mint a nagyjából egy millió forint értékű feltételezhetőleg lopott szoftvereid.
„Az OpenGL messze elmarad a D3D-től”
Az OpenGL jobb, mint a DirectX, csak az összes 3D-s alkalmazást fejlesztő cég megijedt amikor a kedves Microsoft bejelentette, a Vista csak félig szoftveres gányolással (DX wrapper) fogja támogatni az OpenGL-t.„A Wine meg olyan mintha a kisöcsém írta vna”
A wine egy Microsoft nélküli Windows. Ingyenes és legális. Sok minden gond nélkül fut rajta, sok minden meg nem.Melyikre lennél büszkébb, egy általad épített játékautóra, vagy egy lopott BMW-re?
„Photoshop, ACD See,CorelDRAW, 3D Studio Max, Reason, Cubase, MS Office, Visual Basic,SoulSeek, Winamp, Nero, stb.”
Ha jól értem, akkor azért sírsz mert a „nagy” linux alapból nem tudja ugyanazt, mint a nagyjából egy millió forint értékű feltételezhetőleg lopott szoftvereid.
„Az OpenGL messze elmarad a D3D-től”
Az OpenGL jobb, mint a DirectX, csak az összes 3D-s alkalmazást fejlesztő cég megijedt amikor a kedves Microsoft bejelentette, a Vista csak félig szoftveres gányolással (DX wrapper) fogja támogatni az OpenGL-t.„A Wine meg olyan mintha a kisöcsém írta vna”
A wine egy Microsoft nélküli Windows. Ingyenes és legális. Sok minden gond nélkül fut rajta, sok minden meg nem.Melyikre lennél büszkébb, egy általad épített játékautóra, vagy egy lopott BMW-re?
Nagyjából igen. De egy kód emiatt sohasem lesz ettől LGPL-es, csak nem sérül az LGPL licenc (az LGPL nem fertőző). A fejlécben levő anyagot csak akkor másolhatod be a forráskódba, ha egyértelműen fel van tüntetve, hogy a kódrészletre eltérő licenc vonatkozik, és a forráskód a tárgykód melléklete (nyílt forrású). Ugyanis az LGPL előírja, hogy a tárgykóddal együtt az LGPL-es forráskódot is mellékelni kell, ezért a kevert kód nagyon problémás.
Szintén összefoglalnám, csak egy kicsit más megközelítésből.
1. Ha alkalmazásra kerül egy LGPL licenc alá tartozó és 10 sornál hosszabb makró, sablon vagy beépülő funkció (vagy egyéb a kitételben nem szereplő elem), akkor az adott állományban jól láthatóan fel kell tüntetni a felhasználás tényét.
2. Mellékelni kell a forráskódhoz és az összes tárgykódhoz a teljes LGPL licenc-et (idehaza nem érvényesek a kivételek).
3. A teljes LGPL-es forráskód bemásolható egy külön könyvtárba, és a forráskóddal együtt kezelhető (opcionális).
4. Az LGPL-es forráskód módosítható, de össze nem fésülhető a nem GPL kompatibilis kóddal.
5. A módosított , ha nem az akkor az eredeti LGPL-es forráskódot kötelező a tárgykóddal együtt elérhetővé tenni (csak ha az LGPL-es tárgykód együtt kerül terjesztésre).
6. A végfelhasználói szerződésben nem kötelező feltüntetni az LGPL felhasználását (pl. az XFree86 licenc esetében fel kell, meg mást is).Nagyjából igen. De egy kód emiatt sohasem lesz ettől LGPL-es, csak nem sérül az LGPL licenc (az LGPL nem fertőző). A fejlécben levő anyagot csak akkor másolhatod be a forráskódba, ha egyértelműen fel van tüntetve, hogy a kódrészletre eltérő licenc vonatkozik, és a forráskód a tárgykód melléklete (nyílt forrású). Ugyanis az LGPL előírja, hogy a tárgykóddal együtt az LGPL-es forráskódot is mellékelni kell, ezért a kevert kód nagyon problémás.
Szintén összefoglalnám, csak egy kicsit más megközelítésből.
1. Ha alkalmazásra kerül egy LGPL licenc alá tartozó és 10 sornál hosszabb makró, sablon vagy beépülő funkció (vagy egyéb a kitételben nem szereplő elem), akkor az adott állományban jól láthatóan fel kell tüntetni a felhasználás tényét.
2. Mellékelni kell a forráskódhoz és az összes tárgykódhoz a teljes LGPL licenc-et (idehaza nem érvényesek a kivételek).
3. A teljes LGPL-es forráskód bemásolható egy külön könyvtárba, és a forráskóddal együtt kezelhető (opcionális).
4. Az LGPL-es forráskód módosítható, de össze nem fésülhető a nem GPL kompatibilis kóddal.
5. A módosított , ha nem az akkor az eredeti LGPL-es forráskódot kötelező a tárgykóddal együtt elérhetővé tenni (csak ha az LGPL-es tárgykód együtt kerül terjesztésre).
6. A végfelhasználói szerződésben nem kötelező feltüntetni az LGPL felhasználását (pl. az XFree86 licenc esetében fel kell, meg mást is).vizsla wrote:Tehát úgy értelmezed, hogy, ha pl. a gtk.h-ban (egymagában, nem együtt) 10 sornál hosszabb pl. inline függvény van, akkor alkalmazni kell az a.) pontot?Pontosan. A nem GPL kód minden egyes gtk.h-s inline fügvényt használó állományába jól látható helyre be kell szúrni egy megjegyzést (általában az elejére), hogy pl. „A GTK+ könyvtár XXX függvényének beépülő implementációjára az LGPL licenc vonatkozik.”.
vizsla wrote:Akkor pedig nem mindkettőt?…both of the following…
Azt hittem egyértelmű. A b.) pont azt írja elő, hogy csatolnod kell az LGPL teljes szövegét a forráskód és a tárgykód mellé. De ettől még a nem GPL kompatiblis alkalmazás nem lesz LGPL-es, hanem vegyes licenc-ű. Pánikra semmi ok, azon kívül hogy fel kell tüntetni a licenc szövegét és a programkönyvtár nevét, nincs más kötelezettség. Itt a C++ STL jobb példa, mivel pl. az std::vector sablon implementációja nem az LGPL-es libstdc++.so-ban van (lesz), hanem a sablont alkalmazó tárgykódban (ami most nem GPL kompatibilis). Ezért kell külön csatolni az LGPL teljes szövegét, ami a végleges kód nagyon kis részére vonatkozik.
vizsla wrote:Tehát úgy értelmezed, hogy, ha pl. a gtk.h-ban (egymagában, nem együtt) 10 sornál hosszabb pl. inline függvény van, akkor alkalmazni kell az a.) pontot?Pontosan. A nem GPL kód minden egyes gtk.h-s inline fügvényt használó állományába jól látható helyre be kell szúrni egy megjegyzést (általában az elejére), hogy pl. „A GTK+ könyvtár XXX függvényének beépülő implementációjára az LGPL licenc vonatkozik.”.
vizsla wrote:Akkor pedig nem mindkettőt?…both of the following…
Azt hittem egyértelmű. A b.) pont azt írja elő, hogy csatolnod kell az LGPL teljes szövegét a forráskód és a tárgykód mellé. De ettől még a nem GPL kompatiblis alkalmazás nem lesz LGPL-es, hanem vegyes licenc-ű. Pánikra semmi ok, azon kívül hogy fel kell tüntetni a licenc szövegét és a programkönyvtár nevét, nincs más kötelezettség. Itt a C++ STL jobb példa, mivel pl. az std::vector sablon implementációja nem az LGPL-es libstdc++.so-ban van (lesz), hanem a sablont alkalmazó tárgykódban (ami most nem GPL kompatibilis). Ezért kell külön csatolni az LGPL teljes szövegét, ami a végleges kód nagyon kis részére vonatkozik.
vizsla wrote:Lehet, hogy rossz részletet „vettem elő”.A részlet jó, azt gondoltam speciálisan csak speciálisan a részletre kérdezel rá.
vizsla wrote:mi van, ha egy nem gpl kompatibilis libet, akarsz összehozni egy lgpl libbel.Csak úgy lehet, ha az LGPL-es lib külön osztott objektumként megmarad, és a nem GPL kompatibilis lib csak hivatkozik rá.
vizsla wrote:Ugyanis az lgpl ezt elvileg megengedi, viszont nem gpl kompatibilis tárgykód, ugye nem tartalmazhatja az lgpl tárgykódját, mert akkor a (l)gpl hatálya alá kerülne.Van egy speciális korlát, forráskód szintjén valóban nem tartalmazhatja, viszont a programkód igen, ha betartod az idézett részlet a.) pontját, vagy az LGPL-es kód 10 sornál rövidebb.
vizsla wrote:A headert viszont legalább egy include + függvényhívások ereéig tartalmaznia kell.Így van. Az include a nem GPL kódhoz tartozik, a használatára nincs semmilyen korlátozás. A függvényhívás szintén a nem GPL kód része, és a fordító párosítja össze az LGPL implementációval. Most erre nem találok konkrét licenc részletet.
vizsla wrote:Jó, persze van kiskapu, hisz csinálsz egy olyan headert, ami mindkét licencet elfogadja, de ez „marhaság”… és a gpl problémát is megoldaná. Akkor minek az lgpl.Pontosan ez a kiskapu az LGPL, ami a GPL komtatibilis kódot köt(het)i össze a nem GPL kompatibilis kóddal.
Talán így világosabb (GTK+ kód):
Code:// ok, hivatkozás egy fejlécre (itt nem számít mi konkrétan a tartalma)
#includevoid create_gtk_gui ()
{
// ok, data structure layout
GtkWidget *app;// függvény hívás
gtk_init ();/* „app =”: ok, data structure access
„gtk_window_new()”: ok, függvény hívás
„GTK_WINDOW_TOPLEVEL”: ok, numerical parameter
*/
app = gtk_window_new ( GTK_WINDOW_TOPLEVEL );(…)
}
A fenti példa szerintem teljesen rendben van, még megjegyzés sem kell. Akkor kellene kötelezően alkalmazni az a.) pontot, ha 10 sornál nagyobb makró, sablon, vagy beépülő funkció (inline function) van az LGPL-es fejlécben. Tehát az LGPL értelmében minden nem GPL kompatibilis C++ kódnál kötelezően alkalmazandó az a.) pont, ha a C++ STL bármely része alkalmazva van a kódban (pl. std::string deklaráció).
Mivel licenc-ről van szó, a tévedés jogát fenntartom. 🙂
vizsla wrote:Lehet, hogy rossz részletet „vettem elő”.A részlet jó, azt gondoltam speciálisan csak speciálisan a részletre kérdezel rá.
vizsla wrote:mi van, ha egy nem gpl kompatibilis libet, akarsz összehozni egy lgpl libbel.Csak úgy lehet, ha az LGPL-es lib külön osztott objektumként megmarad, és a nem GPL kompatibilis lib csak hivatkozik rá.
vizsla wrote:Ugyanis az lgpl ezt elvileg megengedi, viszont nem gpl kompatibilis tárgykód, ugye nem tartalmazhatja az lgpl tárgykódját, mert akkor a (l)gpl hatálya alá kerülne.Van egy speciális korlát, forráskód szintjén valóban nem tartalmazhatja, viszont a programkód igen, ha betartod az idézett részlet a.) pontját, vagy az LGPL-es kód 10 sornál rövidebb.
vizsla wrote:A headert viszont legalább egy include + függvényhívások ereéig tartalmaznia kell.Így van. Az include a nem GPL kódhoz tartozik, a használatára nincs semmilyen korlátozás. A függvényhívás szintén a nem GPL kód része, és a fordító párosítja össze az LGPL implementációval. Most erre nem találok konkrét licenc részletet.
vizsla wrote:Jó, persze van kiskapu, hisz csinálsz egy olyan headert, ami mindkét licencet elfogadja, de ez „marhaság”… és a gpl problémát is megoldaná. Akkor minek az lgpl.Pontosan ez a kiskapu az LGPL, ami a GPL komtatibilis kódot köt(het)i össze a nem GPL kompatibilis kóddal.
Talán így világosabb (GTK+ kód):
Code:// ok, hivatkozás egy fejlécre (itt nem számít mi konkrétan a tartalma)
#includevoid create_gtk_gui ()
{
// ok, data structure layout
GtkWidget *app;// függvény hívás
gtk_init ();/* „app =”: ok, data structure access
„gtk_window_new()”: ok, függvény hívás
„GTK_WINDOW_TOPLEVEL”: ok, numerical parameter
*/
app = gtk_window_new ( GTK_WINDOW_TOPLEVEL );(…)
}
A fenti példa szerintem teljesen rendben van, még megjegyzés sem kell. Akkor kellene kötelezően alkalmazni az a.) pontot, ha 10 sornál nagyobb makró, sablon, vagy beépülő funkció (inline function) van az LGPL-es fejlécben. Tehát az LGPL értelmében minden nem GPL kompatibilis C++ kódnál kötelezően alkalmazandó az a.) pont, ha a C++ STL bármely része alkalmazva van a kódban (pl. std::string deklaráció).
Mivel licenc-ről van szó, a tévedés jogát fenntartom. 🙂
vizsla wrote:1) Két jobboldali operandust kívánó kifejezésnél egyébként sem praktikus, ha a függvény tag (legfeljebb barát lehet). Gondolj csak bele egy ilyen kifejezésre v3d operator* ( float, v3d ), vagy akár v3d operator* ( v3d , v3d ). Ezeknél a típusú kifejezéseknél gond van, akár definiálsz egy const visszatérési értéket, akár egy const konvertálást hajtasz végre.Mind igaz, de a konkrét példa nem tartalmaz sablont, így számomra nem volt lényeges a fenti probléma. Mivel a 3D-s alkalmazások 99,9%-a nem használ mást csak a float típust koordináták esetében, nincs is értelme sablonként megvalósítani a v3d osztályt.
vizsla wrote:2) Persze nem kell dinamikusan létrehozni. (Bár ez szabad memória kérdése.)
Szerintem a legpraktikusabb paraméterként is referencia pointert használni. (Az operátor miatt itt nem „lehet”.)Szerintem meg a legpraktikusabb a D nyelv garbage collector képességének használata. 🙂 Így a kódot sem kell különösebben portolni.
http://www.digitalmars.com/d/vizsla wrote:3) Egy statikus adat miatt nem kell felmondani a szálbiztos működést. Csak kell egy statikus jelző bit.A statikus jelzőbittel nem használhatsz két szálnál többet, mert a jelzőbit módosításakor nem kívánt versengés léphet fel.
Code:if ( pthread_spinlock_trylock ( …::guard_bit ) != 0 ) {
/* Most nem férek hozzá… várni kell!*/
} {
pthread_spinlock_lock (…::guard_bit ); // most a többiek várnak
/* … */
pthread_spinlock_unlock ( …::guard_bit ); // most már szabad az út
}
legutóbbi hsz