A legfontosabb nyílt forráskódú alkalmazások szerintem

Szoftver

gcc
0% (0 szavazat)
perl
0% (0 szavazat)
php
0% (0 szavazat)
apache
0% (0 szavazat)
mysql
0% (0 szavazat)
postgresql
0% (0 szavazat)
openoffice.org
0% (0 szavazat)
mozilla firefox
0% (0 szavazat)
samba
0% (0 szavazat)
openssl & openssh
0% (0 szavazat)
Egyéb, leírom a hozászólásomban
0% (0 szavazat)
Csak az eredmény érdekel
0% (0 szavazat)
Összes szavazat: 0

( trey | 2007. 08. 16., cs – 08:04 )

Egyértelmű, hogy a GCC. A többi kiváltható alternatív fordítókkal. A GCC pedig még a BSD-nek sem sikerült, pedig nagyon szeretnék.

--
trey @ gépház

Kiváncsi vagyok különben hogyan fognak viszonyulni a > 4.2.1 GCC verziókhoz a BSD-k, mert azok ugye már GPLv3 alatt licenszelődnek.

Egyébként gondolkoztam rajta , hogy a GCC-t kihagyom, de nem lett volna fair.

Én úgy nézem ezt a szavazást, hogy melyik az a program, ami nélkül úgy általában szegényebb lenne a világ.

Az apache-ot nehéz űberelni....

Üdv
Godot

NetBSD:

"We don't think that the switch of GNU programs from GPL v2 to GPLv3 will affect NetBSD or its users much, since we are not in violation of the additional provisions that GPL v3 stipulates. It is a long term goal of NetBSD to become GPL free, but the potential change in license will not affect the scheduling of that goal. Furthermore, the GPL programs in NetBSD are clearly separated from the rest of the source so one can easily distribute a GPL-free NetBSD system (with missing functionality specially in the toolchain parts)." -- Martin Husemann of the NetBSD Foundation"

OpenBSD:

Az OpenBSD vagy újraírja OpenCC néven, vagy forkolja a még GPLv2-es verziót. ;)

FreeBSD:

"Thank you for your interest in the FreeBSD Project. As you know, the FreeBSD Project has a long history of producing open source under the liberal BSD open source license. This license allows unlimited open and closed-source reuse of our software. We do rely on some GPL components-- most critically the gcc development tool suite--but it is a core goal of our work that FreeBSD be complete operating system with BSD-licensed kernel, system libraries, services, and command line tools. Because GPLv3 has not yet been finalized, it would be premature to draw conclusions about how it will affect our project; obviously, we will follow events closely as they unfold." -- FreeBSD core team

--

"Én úgy nézem ezt a szavazást, hogy melyik az a program, ami nélkül úgy általában szegényebb lenne a világ."

Itt mindenkinek jó szavazást nem tudsz csinálni. Ilyenkor szoktam említeni a "Szerinted? Zöld. Piros." szavazást, amit egyszer csináltam. Azon is összevesztek.

--
trey @ gépház

( freeoli v | 2007. 08. 16., cs – 08:27 )

php/apache/mysql nélkül az internet ma nem így nézne ki ... piaci szereplés alapján az összesnek hatalmas jelentőssége van ...

( tamaas | 2007. 08. 16., cs – 08:59 )

Java

Ugye újabban az is nyílt forrású...

( emberk | 2007. 08. 16., cs – 08:59 )

Szerintem minde fontos minél több van annál jobb, és fontosabb ezért választottam az egyebet.

( Tyra3l | 2007. 08. 16., cs – 09:16 )

gcc-t kar volt belerakni, igy aki jozan itelokepesseggel probal szavazni, nem jelolhet mast (mivel gcc nelkul a tobbi se nagyon johetett volna letre).
Amugy postgresre szavaztam volna.
viszont azt sajnalom, hogy perl nem kapott meg szavazatot, mig a php mar 4et is.

Tyrael

( kmm | 2007. 08. 16., cs – 09:23 )

Az itt felsoroltak többsége fontos.
Van ami a másik nélkül nem létezhetne (pl a gcc sokmindenhez kell),
de attol még nem fontosabb mint pl a postgresql nekem...

( hege | 2007. 08. 16., cs – 09:28 )

openssl nélkül is izzadtabb lenne jópár fejlesztőcsapat...

( sj | 2007. 08. 16., cs – 09:33 )

oo.org+firefox nelkul meg a desktop lenne felkaru orias, openssh nelkul meg a remote access lenne izzados

ASK Me No Questions, I'll Tell You No Lies

Szerintem mivel kicsit evolúciósan működik a dolog, nyilván, ha valamelyik nem létezne, akkor az igény a második számú versenytársat hozta volna fel annyira, hogy most az lenne a de-facto szabvány. (He-he például ha a Netscape megnyeri a böngészőversenyt, akkor az Explorert nyitják ki és most az lenne az opensource böngésző :-))
Amúgy én a desktop miatt a firefoxot jelöltem. Az az, amit még a megröngzött windowsosoknál is lehet látni néha.
A gcc történetéről nem tudok sokat. Volt másik komoly nyílt C-C++ fordító projekt? Ami ha nem lenne gcc, akkor átvette volna a helyét?

( Polesz v | 2007. 08. 16., cs – 09:51 )

Az összes felsorolt együtt fontos, nem tudnék legfontosabbat kiemelni.

--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!

( hrgy84 | 2007. 08. 16., cs – 10:01 )

A saját favorizációimat írom le, ne vessetek meg érte:

- python
- perl
- apache
- mysql
- openldap
- svn

Nekem ezek a legfontosabbak. És köszönet illeti a GCC-t mely mindezek használatát lehetővé teszi, de sajnos ettől ő nem lett a szívem csücske.

( biboka v | 2007. 08. 16., cs – 10:02 )

Azért sztem a PHP nem üti meg a Perl szintjét tudásban, egyszerűen csak elterjedtebb.

Volt, de eddig még csak mások két évvel ezelőtti véleményét olvastam majdnem mindenkitől, és a mástól lopott vélemény is erős tanubizonyságot tett a PHP rejtelmeinek nem ismeretéről. Ráadásul két év alatt elég sokat fejlődött a PHP, főleg az 5.2 széria környéke érdekes. Megjelentek pédául az erősen enterspájz ízű kiegészítők, funkciók, libek, framework-ök.
(Bocs, de az általad linkelt oldalak is elmaradottak, főleg hogy a Perl 6 már egy egészen eltérő konstrukciót fog hozni és a Parrot is egész jól sikerült - így még Perl-re sem lesz nemsokára igaz a soksok vád ami a második linken olvasható)
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

Hogy elterjedtebb, az az oldalak többségét elnézve nem vonható kétségbe.
Hogy miben veri a PHP-t? _Szerintem_:
1) Modulok, azok frissíthetősége
2) Sebesség, legalábbis nálam valahogy gyorsabb.
Pl 10e "Hello world":
Perl: 

real    0m1.588s
user    0m0.002s
sys     0m0.001s

PHP: 

real    0m3.184s
user    0m0.036s
sys     0m0.018s

3) Funkcionalitás, ismét csak a modulok miatt
4) Könnyű portolhatóság webre, paranccsorra, GUI-ra (hallottam vmi ilyesmit PHP-ról is, de hegeszteni kellett hozzá, ha jól emlékszem)

És ha már valaki egyszer a PHP-t megtanulta, akkor semmibe sem kerül áttanulni. A szintaxisa is nagyon hasonló, alap programnál volt hogy kb csak a 

<?php ?>

-t cseréltem le #!/usr/bin/perl-re :)

1) Modulok, azok frissíthetősége
Szerintem a Perl CPAN-jánál kuszább dolog nem létezik. Naív kezdő Perl-esként próbálj keresni CPAN modult mondjuk TCP szerver implementációhoz. Találsz vagy 20-at, meg persze mindenféle Layer 7/7.5 implementációból vagy 2-3 félét. Arról már ne is beszéljünk hogy nagymértékben kileng a minőségük is. (Ez PHP-ra is igaz, de szerintem minden bővíthető openszósz progira)
PHP-ban modulkezelésre, de extensionkezelésre ott van a pear. Kiváló eszköz, hogyha megtanulod használni. Nekem van olyan PHP megoldásom vállalati tűzfalon belül, ahol cron+bash+pear+phing segítségével megy az upgrade. Ez magában foglal patch-elést, új modulokat, verziófüggések kezelését, RDBMS frissítését, szerverfürt-szinkron ellenőrzését.
Szóval ha nem is jobb a PHP ebben a kérdésben, de semmiképpen nem rosszabb szerintem. (Vagy valamit félreértettem?)

Sebesség, legalábbis nálam valahogy gyorsabb.
Tény, hogy így lassabb, de kevéssé érdekes ez szerintem, mert egyrészt bytekódra fordítható és optimalizálható a PHP kód (speciel ezt kihagyni egy normális portálnál öngyilkosság), másrészt ez nem a nyelv gyengesége, hanem a fordítóprogramé és a bytecode interpreteré. Például itt van a Quercus, ami határozottan odab*sz teljesítményben ;)

Funkcionalitás, ismét csak a modulok miatt
Ezzel nem értek egyet, könnyen bővíthető a funkcionalitás, kicsit lentebb össze is szedtem a képességeket, amik flexibilissé teszik.

Könnyű portolhatóság webre, paranccsorra, GUI-ra (hallottam vmi ilyesmit PHP-ról is, de hegeszteni kellett hozzá, ha jól emlékszem)
Nem releváns, a PHP egy webfejlesztésre kitalált nyelv, mást elvárni tőle nem korrekt. Lásd lentebbi hozzászólásom.

És ha már valaki egyszer a PHP-t megtanulta, akkor semmibe sem kerül áttanulni. A szintaxisa is nagyon hasonló, alap programnál volt hogy kb csak a <?php ?>-t cseréltem le #!/usr/bin/perl-re :)
Majd talán Perl 6-nál ;)
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

Azért én a CPAN-t megvédeném, ha nem baj.

Én kezdőként úgy használtam a CPAN-t, hogy kerestem, találtam 20 csomagot, és átnézegettem az API-jukat (elég yól dokumentált minden csomag). Ami egyszerűbbnek tűnt, letöltöttem, felraktam, használtam, örültem. Kb. ennyi. Kezdőként.

Hmmm. Én ugyanezt csináltam PHP-val a php.net-en és nekem is minden simán ment. A PHP kiegészítései vannak legalább olyan jól dokumentáltak, mint a CPAN-os modulok. Csak nyilván tudni kell hol keresni. (Mindemellett egyik dokumentációs szintjével sem vagyok elégedett)

--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

( tolmi | 2007. 08. 16., cs – 10:04 )

Bár valóban a gcc-t tartom a legfontosabbnak, itt lenne az ideje hogy valami lecserélje mert így kb azok tudnak hozzányúlni a kódjához, akik 40 éve gcc-t fejlesztenek és ott voltak a kezdeténél. Egyszerűen egy ilyen szoftvernél meglátszik a soksok év és a nem alapos, vezényelt kivitelezés. Annak mondjuk örülnék ha az Intel az ICC-t szabaddá tenné, de egy Sun C fordító sem lenne rossz GPL alatt.

Perl/PHP: Nem értem hogy a Perl lovagok miért fanyalognak a PHP-n, amikor a Perl legalább annyi hiányossággal küzd ezeken az új platformokon(embedded, web), mint a PHP. Sőt, PHP-ban egy viszonylag kezdő is tud biztonságos programot fejleszteni kevés tanulással, míg Perl-re ez soha nem volt igaz és hála Larry két szabályának, soha nem is lesz.
Lényegében senki véleménye nem számít a kérdésben és mindenkié számít egy kicsit. A trend most a PHP(Python, Ruby, ...) és nem a Perl. Oka? Szerintem a Zend Technologies Ltd. A Perl mögött nincs komoly üzleti háttér. Ami kevés van(ActiveState), annak meg jól megy Perl fronton is. Szóval nincs más hátra, mint hogy valaki soksok tőkével céges fronton is erőszakolja a Perl-t és akkor új reneszánszát fogja élni. Hogy a Perl üzleti kisajátítása mennyire fog tetszeni Larry bácsinak és a Perl közösségnek, azt már ne vitassuk :)

--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

A baj csak az, hogy a három P-s nyelv közül a PHP az, aminél kevés a non-web bindingek száma. Yó-yó, van gtk binding, ha kereesgélnék, tuti találnék Qt bindinget is, talán még kde bindinget is, de így ennyi. Nagyon sok libet nem tud elkezelni, és a PHP-t objektumorientáltan programozni, megbocsáss, de elég nehéz, és ráadásul nem is annyira yó.
Szóval nem csak a Perl-nek vna szüksége nyomásra, hanem biza a PHP alá is alá kéne nyúlni, hogy legyenek bindingek; és az a kevés ami van, nézzen ki normálisan, legyen dokumentálva, ilyesmi.
Kedvenc példáim a ncp és a cups bindingek: alig tudni róluk valamit. A ncp-nek van valami homályos, pársoros doksija, de attól csak sírni lehet maximum.

A baj csak az, hogy a három P-s nyelv közül a PHP az, aminél kevés a non-web bindingek száma.

Szerintem nem annyira kevés a non-web bindingek száma. Sőt, szerintem túl sok (az ideális a 0 db lenne). A PHP rövidítés kifejtése PHP Hypertext Preprocesszor. Ez a nyelv direkt webfejlesztésre készült. Nem is értem hogy miért kell olyan elvárásokat támasztanunk a PHP-val szemben, amiket írtál. Mindenre van eszköz. Gyakran többféle is. A PHP nem való desktop vagy szerver fejlesztésre(ettől persze lehet, csak nem szerencsés). Period.

Nagyon sok libet nem tud elkezelni,...

Öööö. Na lássuk csak:

  • Van natív Java binding, így az összes Java-s libet és funkciót tudja kezelni
  • Van natív .NET bridge-e(oké még experimental, de lesz), így minden Windows-os COM interfészhez hozzáférhet
  • Extension segítségével több, mint 200 natív C-s libet támogat(GD2,libxml,libpam,libcairo,stb.,stb....)
  • Ha esetleg nem támogatna valamilyen lib-et, végtelenül, hihetetlenül egyszerű hozzá wrapper-t fejleszteni(csináltam is már, és elsőre működött, csak kissebb hibák voltak)

a PHP-t objektumorientáltan programozni, megbocsáss, de elég nehéz, és ráadásul nem is annyira yó.

A OOP PHP egyetlen hiányossága a nem létező namespacing, de ezt PHP 6 megoldja (és a natív Unicode stringkezelést is). Mindemellett szerintem nemhogy nem nehéz a PHP5 OOP szolgáltatásait kihasználni, de egyenesen könnyebb, mint C++ vagy Java. Sokkal rugalmasabb. Olyannyira, hogy nyelvi vagy extension támogatás nélkül meg lehetett valósítani az aspektusorientált programozási paradigmákat vagy az annotation feldolgozást. Java-ban még sehol nem voltak a bytecode augmentorok, amikor a PHP erre képes volt. Nem mondom, tény hogy a nyelv nem támogatja, de legalább meg lehetett csinálni(más kérdés, hogy extensionban ki fognak jönni ezek a megoldások)! C++-ról meg ne is beszéljünk. a kőbe vésett OOP-jával.
Szívesen adok konkrét példát hogy sokkal kényelmesebb PHP-ban az OOP, ha mondasz olyan feladatot, amit szerinted nehézkes implementálni ezen a nyelven.

...legyen dokumentálva, ...

Ebben nincs mese, igazat kell adnom. A doksik minőségét növelni kell. Ez tény.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

>> Van natív Java binding, így az összes Java-s libet és funkciót tudja kezelni
ezt ugye nem próbálad?

>> Van natív .NET bridge-e(oké még experimental, de lesz), így minden Windows-os COM interfészhez hozzáférhet
mi az összefüggés?

>> több, mint 200 natív C-s libet támogat
sajnos

>> hihetetlenül egyszerű hozzá wrapper-t fejleszteni
agreed

>> A OOP PHP egyetlen hiányossága a nem létező namespacing
persze, minden relatív

>> PHP 6 megoldja [...] a natív Unicode stringkezelést
oh teh hilarity

>> Van natív Java binding, így az összes Java-s libet és funkciót tudja kezelni
ezt ugye nem próbálad?
Igen, jelenleg is használom és kiválóan máködik. Ráadásul gyors is. Azt hittem lassú lesz és így kellemes meglepetés ért.

>> Van natív .NET bridge-e(oké még experimental, de lesz), így minden Windows-os COM interfészhez hozzáférhet
mi az összefüggés?
Az, ami a Java bindingnél is összefüggés. Olyan funkcionalitáshoz férhet hozzá, ami .NET-en keresztül elérhető. Ez jórészt az összes Windows API-t és a COM-on elérhető objektumokat jelentheti a jövőben.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

Csak éppen nem feltétlen yó dolog unmanaged kódból managed kódon keresztül unmanaged kódhoz hozzáférni. Legalábbis sejtem, hogy a PHP-.NET bridge unmanaged kód. De ha managed, akkor se a legjobb dolog.
Hypertext Preprocessor... :) Ennyi erővel mondjuk a perl-re hogy scriptnyelv, és ki a franc akar benne oldalakat fejleszteni. Aztán mégis...

Lehet hoyg a PHP-huszárok nem feltétlen nézik yó szemmel a PHP el-desktoposodását és el-szkriptesedését, de mivel effektíve nem egy nehéz szintaxisú nyelv (oop excluded, nekem mindig is problémás volt), így ez várható volt.

Managed-unmanaged bridge kapcsán még mindíg nem látom, hogy miért "jó" vagy "nem jó" ez. Attól tartok hogy ez valami legenda lesz ismét...

PHP (és más nyelv) huszáraként állíthatom, hogy ki nem állhatom azokat az embereket, akik kalapáccsal a kezükben mindent szögnek néznek. Attól én (és jó páran mások is) még igyekszem a célnak megfelelően használni az eszközt.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

gcc+binutils koncepciója elég világos, jól átlátható, nem kell lecserélni.

Én Makefile/autotools cuccait dobnám ki és újra írnám, mert szinte mindig bugba ütközik az ember, ha cross -részt is elhiszi. szerintem teli van workaroundokkal amitöl még kuszább lessz. *host résznél kötelezővé tenném leghoszabb megadási módot, vagy szét darabolnám a *host ot (arch-vendor-OS-lib), ill. bináris forma megadását is kötelezővé tenném vagy jobban definiálnám melyik tagban kell szerepelnie. g++ (cross) a legnehezebben leforgatható programok egyike, főleg ,ha gcc vadhajtásaival is találkozott az ember. (TI DSP, wince)
SIMD utasításokra rosszul optimalizál, nem használja ki őket. Régen amikor néztem -mfpmath=387 gyorsabb volt némely esetben, mint sse holott lehetett volna sse -vel gyorsabb kódot hegeszteni szvsz.

Lazán kapcsolódva: van valahol configure.in referencia? Vagy mindent úgy kell összevadászni, hogy ha valami program használja ezt, akkor abból ki lehet nézni hogy hogyan ellenőrzi? Valami fenomenális, Qt-t meg C++-t tanulok mostanság, de ugye olyan projekt template hogy base Qt és nem Qt GUI olyan nincs nagyon, így a plain helloworld-ből kell kiinduljak.

Sajnos nincs sok szabadidőm hogy belenézzek a forrásukba(nem ismertem őket) és így véleményezni sincs sok értelme őket, de feljegyeztem magamnak mindkettőt. ;)
Az lcc azonban egyből kedvesebb a kicsi szívemnek, mert van róla egy könyv(!), ahogy az általad linkelt oldalon is írják. A sample chapter alapján pedig jó könyvnek néz ki. Kb. Tannenbaum: Az operációs rendszerek minőségnek tűnik, csak a fél könyv nem a forráskóddal van kitöltve. :D
Lényegében a könyv elolvasása után magam is elkezdhetném fejleszteni az lcc-t, míg ezt gcc-vel 10 könyv után sem merném megtenni. Bejön.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

( vyergas | 2007. 08. 16., cs – 10:05 )

A felsoroláson kívül még talán:
Python, LaTeX

( maniac | 2007. 08. 16., cs – 10:37 )

GCC. Enelkul az ingyenes fordito nelkul nem lenne semmi :).

( segabor | 2007. 08. 16., cs – 10:40 )

Általam preferáltak:
- ruby
- firefox
- svn
- webkit
- mysql

--
Kinek nem inge, ne vegye gatyára

( Csigaa | 2007. 08. 16., cs – 11:11 )

Többet miért nem lehet bejelölni?

Mint fejlebb írták, a GCC egyértelmű. Akkor meg vagy ez legyen az egyetlen választási lehetőség, vagy legyen új szavazás "a GCC mellett legfontosabb" címmel, mert ez így "bunda".

OFF:
ha godotnak elérhető lenne a forrása, lehet hogy találnánk benne egy darabka rejtett gcc-ultimate-fun.blob -ot is valamiféle titkos záradékként amit még a suliban injekcióztak belé a tbc kontroll oltással :)
:FFO

igaz, az se lett volna túl szép ha kimarad.

A szavazás jó, köszi!

Ja ezen oknál fogva nem szavaztam Én magam sem inkább leírom:
A felsorolt szoftverek közül nagyon sok szimbiózisban él.
Nem lenne apache gcc nélkül(igaz ez mindegyik felsorolt sw-re), de lenne ekkora sikere(elterjedtsége) a nyilt szoftvereknek apache/perl|php/mysql|pgsql nélkül.
Vagy a samba kicsit ki lóg az előbbi sorból, de mindenképpen a gcc alatt kellene lenni.
Kb. az egész olyan mint egy fa: kell hozzá gyökér(gcc)
kell törzs Linux/BSD....
levelek(samba/apache/postfix|sendmail.../akármi)
...
Nekem a fa a fontos nem egy db levél vagy csak a gyökér - az egész.

Mar ne haragudj, de tudod hogy mit beszelsz? Nezz utana hogyan lehet leforditani az apache-ot windows-on! Miert is ne letezne az apache gcc nelkul? A gcc-n kivul van meg mas fordito is.Azert mert te linux/bsd-t hasznalsz,attol meg miert kell a gcc-t a kozeppontba allitani? Nyilt forrasu progi nem lehet windows-on, vagy solaris-on?
Virtualdub? Tudod hogy mi az? Nyilt forrasu es GPL-es, es csak windows-ra van.

( nsuperbus (nem ellenőrzött) | 2007. 08. 16., cs – 11:34 )

Szerintem ennek ilyen formaban nincs ertelme,mert mindegyik a maga teruleten fontos, nem lehet kiemelni kozuluk egyet. A felsoroltakon kivul meg sok nyilt forrasu progi van ami nem kerult be a szavazasba pl: mc,mplayer stb... Hogyan valasszak e ketto kozott,amikor mindegyik a maga teruleten ugyanolyan fontos.

( Vudumen | 2007. 08. 16., cs – 11:51 )

"A legfontosabb nyílt forráskódú alkalmazások szerintem"

A kerdes tobbesszamra vonatkozik es megis csak 1 valasz jelolheto meg.

( siposa v | 2007. 08. 16., cs – 12:02 )

Legszívesebben mindent bejelölném, a maga területén mindegyik fontos.

( E-Medve v | 2007. 08. 16., cs – 12:58 )

A gcc egyértelmű, de ha nem lett volna benne, akkor a LAMP - vagy a LAPP - és az openss[lh].

Ja meg ha az OpenOffice benne van, akkor érdemes lett volna mondjuk egy GIMP-et is beledobni.

> a Firefox megelőzi az OpenSSH-t

Milyen értelemben?

(Gyorsan lejátszuk:

be - a csík hosszának mértékében
zz - és az (a hossz) mit jelent?
be - nem tudom
zz - akkor "milyen értelemben?"
be - nem tudom, csak be akartam szólni
zz - ma jó napom van: meg van bocsátva

és megy mindenki a dolgára. :-)))))

( Morzel | 2007. 08. 16., cs – 13:08 )

Csak egy pillanatra jutottam most géphez, úgyhogy nem volt időm elolvasni a hozzászólásokat, de lenne egy kérdésem:
A firefoxnak hol tudom letölteni a forráskódját?

Morzel

( uid_6846 | 2007. 08. 16., cs – 14:45 )

Kimaradt a CrossOver Office.
__________
U-Bantu©

( Nyizsa v | 2007. 08. 16., cs – 15:13 )

Az egyebet ixeltem be, mert szerintem sincsenek teljesen átgondolva az opciók. Az egy jó szempont, hogy gcc nélkül nem lenne open source, legalábbis nem ilyen, mint most. A többi opció közül viszont a legtöbb valamilyen fizetős program open source megfelelője, illetve a sok hasonló program közül kiragadott példák.
Számomra a legfontosabb nyílt forráskódú alkalmazás az Octave.

--
Debian - The "What?!" starts not!

( poliverzum | 2007. 08. 16., cs – 19:00 )

Szar a szavazás, mert nem lehet egyszerre többre szavazni, holott a kérdés is többesszámban van feltéve.

Mindazonáltal az összesnek a gcc az alapja. Ez nyilvánvaló. Emellett azonban nagyon fontos a Firefox és az OpenOffice is. Ezt a hármat jelöltem volna be, ha lehetne egyszerre többet.

No most a gcc mint írtam mindennek az alapja, de egy átlaguser ebből nem sokat lát ha nem progranyozik és nem forrásalapú disztrót használ. Nekik tehát a másik kettő a legfontosabb.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

>> Mindazonáltal az összesnek a gcc az alapja. Ez nyilvánvaló.
talán nem vagyok egyedül azzal a véleményemmel, hogy ez korántsem nyilvánvaló, sőt: nem is igaz

>> No most a gcc mint írtam mindennek az alapja
olyannira pl, mint bármely editor, amiben a forrását meg lehet nyitni editálásra

>> Mindazonáltal az összesnek a gcc az alapja. Ez nyilvánvaló.
> talán nem vagyok egyedül azzal a véleményemmel, hogy ez korántsem nyilvánvaló, sőt: nem is igaz

A listában felsoroltak közül ( == "az összesnek" ) melyik nem fordítható le gcc-vel?

Ha pedig mindegyik lefordítható gcc-vel, akkor "az összesnek a gcc az alapja".

Még ha neked más is a véleményed.

> akkor hogy lehetne az alapja *egy bizonyos* fordító?

Ha a kód fejlesztésekor figyelembe vették az egyes fordítók igényeit/lehetőségeit, akkor ezek (az információk) a fejlesztés alapjául szolgáltak.

Ha a kód fejlesztésekor figyelembe vették a GCC igényeit/lehetőségeit, akkor a GCC a fejlesztés (egyik) alapjául szolgált.

"Mindazonáltal az összesnek a gcc az alapja. Ez nyilvánvaló."

És tényleg. :-)

Lentebb írtad, hogy gcc függő dolgot keresel akkor mondok egyet:
Attributes
Ez csak gcc -hez van AFIK, ha nem gcc -vel forgatsz ilyen kódot, akkor egy macroval lenyeletheted az __attribute__ -ket.

MS cuccnál meg valmi __declspec(dllexport)és tesói ami nem standard. mingw -gcc egyrészét megrágja windowson. Körbe kell macrózni a progit, hogy minden platformon/fordítón azt tegye amit szeretnél.

interface fentartott szó van -e C++ szerinted ?

Melyik headerben van hálózat kezeléshez szükséges headerek (listen,bind,accept ..etc.) ?
Kell intcializálni explicite a hálózati alrendszert , mielőtt a fenti utasításokat kiadhatod ?

mintha nem ugyanazt a hozzaszolast olvasnank (vagy csak szelektiv a latasod?):
----------------------------------------------
Szerző: Replaced
igazad van, a gcc nagy ujitasa az volt, hogy bebizonyitotta: c-ben is lehet konnyen platformfuggo kodot irni
----------------------------------------------
Szerző: Turul16
Sorold.
Én tudok pár példát (és megoldást) kiváncsi vagyok te tudsz -e ?
----------------------------------------------
Szerző: Replaced
na, ez erdekelne
milyen peldakra gondolsz?
----------------------------------------------
Szerző: turul16
Lentebb írtad, hogy gcc függő dolgot keresel akkor mondok egyet:
Attributes
Ez csak gcc -hez van AFIK, ha nem gcc -vel forgatsz ilyen kódot, akkor egy macroval lenyeletheted az __attribute__ -ket.

MS cuccnál meg valmi __declspec(dllexport)és tesói ami nem standard. mingw -gcc egyrészét megrágja windowson. Körbe kell macrózni a progit, hogy minden platformon/fordítón azt tegye amit szeretnél.

interface fentartott szó van -e C++ szerinted ?

Melyik headerben van hálózat kezeléshez szükséges headerek (listen,bind,accept ..etc.) ?
Kell intcializálni explicite a hálózati alrendszert , mielőtt a fenti utasításokat kiadhatod ?
-----------------------------------------------
Tehat ahogy en latom: Replaced elkezdte szidni a gcc-t, merthogy mennyire nem szabvanykoveto.
Turul16 megkerdezte tud-e konkret peldat, mert hogy o igen.
Replaced tette a hulyet, Turul erre leirt mind linux, mind windows vonalon 1-1 peldat ami miatt egymas kodjait viszonylag korulmenyes leforditani, majd kerdezett 3 dolgot Replacedtol, aki azota nem nagyon irt ide.
Nekem ebbol az jott le, hogy amig csak flamelni kell, addig partner Replaced, ha meg tenyeket, vagy tudast kene villantani, akkor meg otthagyja a threadet.
Kerlek javits ki ha tevedek, viszont ha te is csak flamelni jottel, akkor eleg az is, ha nem valaszolsz erre a hozzaszolasra.

Tyrael

...bebizonyitotta: c-ben is lehet konnyen platformfuggo kodot irni...

Bocs, hogy beleszólok, de én a szakirodalomban azt olvastam az ANSI C-vel - annak szabványosításával - kapcsolatban, hogy (idézem):

"* A létező C nyelvű programok lefordíthatóak maradjanak a szabványos C nyelvet megvalósító fordítóval. A nem szabványos megoldásokra figyelmeztetés hívja fel a programozó figyelmét.
* A C forráskód legyen hordozható.
* A C forráskód lehet nem hordozható is. (A szabványos C bővíthető géptől és operációs rendszertől függő megoldásokkal.)"

Ha az utóbbi két pont igaz, akkor tökéletesen irreleváns, hogy a gcc megalkotói milyen egyedi, vagy platformfüggő megoldásokat alkalmaztak. A gcc nem attól jó, vagy éppen rossz C fordító, hogy platformfüggő vagy platformfüggetlen kódot lehet benne írni.

init();

Szerintem az gcc nélkül is kiderült volna előbb-utóbb. Szvsz nem csak a gcc-nél van olyan, ami platformfüggő, hozhatjuk a MSVCC-t is példának, meg biztos van még kalap másik.
Amúgy a platformfüggetlenség kétélű dolog. Nem csak a fordítónak kell annak lennie, hanem a fordítandó program által használt libeknek is platformfüggetlennek kell lenniük (gyk.: létezniük kell az összes létező platformra). Ha ez nem áll fenn, akkor a program platformfüggő.

igazad van

az a vicc, hogy gcc verziok kozott sem mindig fordulnak a programok
mondjuk ez inkabb a programozok hibaja, de hat ha a kornyezet engedi, akkor sokkal valoszinubb, hogy szar kodot csinalnak (lasd php)
bar 4-es szeria most szigorubb lett halistennek

--
I think the major good idea in Unix was its clean and simple interface: open, close, read, and write.

( jupiter2005ster v | 2007. 08. 16., cs – 23:00 )

szerintem mind nagyon fontos.

forever linux
Egyre több informatikusnak van nemi élete. Hígul a szakma...

( DirtY_iCE | 2007. 08. 17., p – 10:05 )

egyéb: az összes :p

I hate myself, because I'm not open-source.

( Lory | 2007. 08. 17., p – 10:36 )

TeX/LaTeX szeretném felhívni a figyelmet, hogy a tudományos közösség jó része ezt használja.

( lazly | 2007. 08. 20., h – 15:25 )

annak ellenere, hogy Gnomeot hasznalok, megis a kteatimeot tartom a legjelentosegteljesebb projectnek.

( vik1984 | 2007. 08. 20., h – 20:46 )

gcc nelkul a tobbi nem is letezne talan :)

"i pensieri stretti & il viso sciolto." -- Sir Henry Wootton

( portage | 2007. 08. 22., sze – 07:10 )

GCC a felsoroltak közül, hiszen attól fordul a gentoo. :)

-------------------
2.6.22-gentoo-r2