DragonFly BSD 1.4

ha valak _valojaban_ hasznal DragonFly BSD elarulhatna miert is erdemes hasznalni.

>A NetBSD-s pkgsrc lett a csomagkezelő a FreeBSD-s ports helyett

eddig meg jot nem hallottam a NetBSD pkgsrc-rol. rosszat ellenben sokat. miben is jobb, mint a FreeBSD ports???

>- gcc 3.4 az alapértelmezett fordító.

en jelenleg:

gcc version 4.0.3 20060104

hasznalok alapertelmezett forditokent, es mar honapok ota 4.x sorozatot

>bemutatkozik a DNTPD, a DragonFly saját NTP daemon-a.

eszement fontos, hogy sajat time daemonja legyen az eddigi x db. helyett.

> Zsír új PAM infrastruktúta.

miert is volt rossz a regi? mibenis nyujt tobbet az uj?

egyszeru parasztvakitas a szoveg. valaki kicserelt egy for ciklust while-ra es "brand new pam infrastructure" lett belole.

Meg nem birom erteni, miert erdemes sok munkakat bealdoznie gy zillionadik *BSD/Linux oprendszerbe/disztroba.

miert nem mukodik ez nagy disztro derivativjakent (Pl:Kubuntu/Edubuntu)

a kulonbseg lathato, es nem kell feltalalni 20x-szor a melegvizet.

Elnézést kérek Matthew Dillon nevében is, andrej mester. :(

Mindazonáltal visszakérdeznék, hogy milyen rossz dolgot hallott a NetBSD pkgsrc-ról? Talán gsuveg és lego is kiváncsian olvasná... ;)

A gcc4 production környezetben való használatára sok sikert kívánok. Azért furcsa, hogy mennyi 'buta' ember használ még mindig inkább 3-as verziót (és nem kevesen továbbra is 2.9x-et).

Az NTP daemon lehet, hogy azért eszement fontos, mert a többi alternatíva vagy nem elég free vagy nem tud eleget. Esetleg talán netán mondjuk például azokat a kernel hívásokat nem támogatják, amelyek a Dragonfly BSD-ben bevezetésre kerültek az NTP-hez.

A többihez pedig már hozzá se tudok szólni... Parasztvakítás az egész!

gcc4-re vonatkozolag:

1) csak cben kodolsz es nemhasznalsz pl. anon unionokat, okes, akkor neked eleg 2.95 is

persze a nemsajat programjaid mar nembiztos, h fordulnak, de minek magadnak forditani a dolgokat

2) altalanossagban 1 univerzalis c forditora van szukseged - ebben a kategoriaban valszeg gcc3 nyer

3) erdekel pl a leforditott c++ programok teljesitmenye is, egyebek - egyertelmuen gcc4

ha vmi nemfodul vele / lassabb, az 90%ban a program hibaja

Azért nem kellene úgy beállítani a dolgot, mintha 2.9x gcc-vel már semmi sem fordulna... Persze kivétel az agyon istenitett legújabb Linux kernel, mert abból kivették a támogatást, hisz minek is forduljon akármilyen fordítóval egy kernel? Felesleges baromság lenne.

Egyébként meg aki verzióbuzi az használja nyugodtan a legújabbat. Bizonyára a Debian és a legtöbb disztribúció fejlesztői is mindd hülyék, hogy nem nyomják mindenből a legújabb snapshotot a stabil ágban.

>bemutatkozik a DNTPD, a DragonFly saját NTP daemon-a.

eszement fontos, hogy sajat time daemonja legyen az eddigi x db. helyett.

Idézem a changelogból:

Greatly simplify and demystify the NTP kernel interface. Convert most aspects of the interface over to sysctls.

Hát talán ezért csinálták...

gcc version 4.0.3 20060104

hasznalok alapertelmezett forditokent, es mar honapok ota 4.x sorozatot

A ceges warenk, ami gyonyoruen fordul egy rakat proprietary Unixon mindenfele kitudjamilyen C forditoval, mindenfele paccsek nelkul, szinten tokjol fut Linuxon GCC 2.95.3-al. GCC3-hoz mar kellett nehany workaround, a GCC4-nek pedig szimplan beletorik a foga. A lead programmerunk 2 het szopas utan kozolte, hogy reszerol inkabb viszatette a 3.4-et. Szeretjuk a GNU stuffokat. Eljen a fejlodes. Jo ez, csak az iranya kerdeses. IMHO.

On 2006-01-08, Mészáros András <andrej@initon.hu> wrote:
>
> ha valak _valojaban_ hasznal DragonFly BSD elarulhatna miert is erdemes
> hasznalni.

Otletes, tiszta a kodja. End-user akceptalhato okok *egyelore* nincsenek.
(De majd ha lesz hozza ZFS szupport...)

>>A NetBSD-s pkgsrc lett a csomagkezel? a FreeBSD-s ports helyett
>
> eddig meg jot nem hallottam a NetBSD pkgsrc-rol. rosszat ellenben sokat.
> miben is jobb, mint a FreeBSD ports???

A pkgsrc, mint keretrendszer, barmilyen *nix-on hasznalhato. Hogy
aktualisan melyiket mennyire tamogatja, az azon mulik, hogy a rendszeren
dolgozo arcok mennyit fektetnek feccolnek az integraciojaba.

Linuxon, amikor hasznalni probaltam "as is", eleg fajdalmas volt.
NetBSD-n gondolom kevesbe az. Es feltehetoleg Dfly-on is egyre
olajozottabban mukodik.

Nemigen volt mas alternativajuk. A FreeBSD portshoz ugy all hozza a
FreeBSD projekt, hogy az a FreeBSD csomagkeszitesi infrastrukturaja.
A pkgsrc-hez ugy all hozza a NetBSD projekt, hogy az egy altalanos
csomagkeszitesi keretrendszer. Mas ilyen nem nagyon van. (A Gentoo
portage probalkozik, de azert sztem eleg messze van meg attol, hogy
komolyan lehessen venni sajat hazatajan kivul...)

>>- gcc 3.4 az alapértelmezett fordító.
>
> en jelenleg:
> gcc version 4.0.3 20060104
> hasznalok alapertelmezett forditokent, es mar honapok ota 4.x sorozatot

De most mer' erdekes, hogy "te jelenleg"? Vagy egy sajatfejlesztesu
OS-rol beszelsz?

Dfly-on van az alapbuildben gcc 3.4 meg 4.0 is, de defaultnak a
mar tobbet teszteltet tettek be, mit kell ezen ertetlenkedni?

> Meg nem birom erteni, miert erdemes sok munkakat bealdoznie gy zillionadik
> *BSD/Linux oprendszerbe/disztroba.

Mer' meg se probalod. Mer' talan megsem azert kulon oprendszer,
hogy sajat ntp daemonja lehessen.

> miert nem mukodik ez nagy disztro derivativjakent (Pl:Kubuntu/Edubuntu)

FreeBSD derivativ. Van is kodcsere (kozte, meg az egyeb BSD-k kozott).

Ellenben hogy jon ide az *ubuntu? Azok nem kulon OS-ek, csak mas van az
ISO-ra pakolva.

> a kulonbseg lathato, es nem kell feltalalni 20x-szor a melegvizet.

A Dragonfly nem epp a melegviz ujrafeltalalgatasarol szol. De
trollkodassal nem fogsz tobbet megtudni rola.

Es pontosan milyen kulonbseget latsz te? The Great Edubuntu vs. Dfly
Countdown?

Cs.

azert netevessz ossze anrrel akinek 5napos snapshotja van :)

de az teny, h nagyobb c++ appoknal mindenfele kodmodositas nelkul a jelenleg nalam futo 4.0.2 erezhetoen gyorsabb kodot fordit mint a 3.x

On 2006-01-09, VMiklos <vmiklos@frugalware.org> wrote:
> de az teny, h nagyobb c++ appoknal mindenfele kodmodositas nelkul a
> jelenleg nalam futo 4.0.2 erezhetoen gyorsabb kodot fordit mint a 3.x

Heh, ez a "teny, hogy erezhetoen..." jo duma...

Mint amikor bementem a TO-ra...

- Csokolom, benn van X. tanar ur?
- Nincs.
- Es lehet, hogy delutan benn lesz?
- Nem tudom.
- Akkor *lehet*, nem?
- Nem tudom, mondtam mar.
- "Lehet" kerdesre nem lehet nem tudommal valaszolni.
- Ne szemtelenkedjen.
- Elnezest, eszem agaban sincs -- de ha nem tetszik tudni, akkor
kizarni se tudja, tehat lehetseges, azaz a "lehet" kerdesre igenlo
a helyes valasz...
- Jajj, hagyjon mar beken, gozom sincs.
- Koszonom, ertem. Csokolom.

Cs.

Érezthetőbben gyorsabb... Placebo?

Csináltam benchmarkot mindenféle gcc-vel (3.x-ből többféle, 4.x-ből szintén) és icc-vel fordított bind9-cel, mindenféle optimalizációs kapcsolóval.

A 4-es gcc-vel fordított bind volt a leglassabb, utána a 3.4-snapshot, majd icc és a többi 3.x.

Neked az érezhetően gyorsabb miből jött ki? Leültél a gép elé és az agyadba épített mikroszekundumos időmérő jelzett? :)

"nagyobb c++ appoknal"

simca wrote:
> "nagyobb c++ appoknal"
Korán keltem. :)

/me egyetért. Nekem sincs éles környezetben DFly-om. Nem is hiszem, hogy perpill. oda szánják. Van olyan arc, aki használja élesben, de ritka. Ezt inkább fogd fel úgy, hogy ez most kutatási projekt. Annyi vadinyú technológiát pakolnak bele, hogy a Linux elbújhat. És még egy darabig folytatni fogják, amíg ki nem forr legalább alapjaiban.

Már most pofára ejti bármelyik BSD-t, Linuxot pölö hálózati teljesítményben és SMP-ben. Egyszerűen mert modern algoritmusokat implementáltak és nem a régi sz*rt foltozgaták. Szóval anr semmi baj sztem a te szempontjaiddal, csupán azt felejtetted el/nem vetted észre, hogy elsősorban nem végfelhasználóknak szól még a rendszer. Idővel azonban.... ;)

Pont most ment errol egy thread ha jol emlekszem FBSD-currenten, hogy nyers halozati teljesitmenyben a DFlyt egyelore nagyon kemenyen odab*ssza a FBSD, foleg AO jelenlegi is folyo projektjenek ( itt [people.freebsd.org]) eredmenyekent (valami 2-2.5x kulonbseg volt pps-ben merve az atvitelben). MD meg erre nagyon keszsegesen elismerte, hogy egyelore koncepciojuk beigazolasan dolgoznak, a teljesitmeny-hangolas majd csak ezutan jon.

IMHO azert az, hogy hasznalhatsz anonymous unionokat/structokat meg egy kicsit keves ahhoz, hogy eles helyen egy kiprobalt forditokornyezetet lecserelj. GCC4-re azoknak eri meg atallni, akik C++-t vagy objective C-t hasznalnak (ezeknek a tamogatasa allitolag sokat fejlodott), vagy pl sokat dobhat a kodjukon az uj auto-vectorization kepesseg (ami nem valami kiforrott jelenleg, nalam igen konnyen elszall PPC-n).

jah, azt neis emlitsuk, h igazan 3.4-tol van rendes amd64 tamogatas, ami szinten eleg sok embert erint