A Sun komolyan gondolta a Solaris - HP-UX egyesítést

Sun Microsystems

Gyakran lehet hangzatos dolgokat hallani a Sun-tól. A múlt héten például azt, hogy szívesen látnák, ha egyesülne a Solaris operációs rendszerük a HP UNIX-szával, a HP-UX-szel.
Gondolom ennek a kijelentésnek a hatására többek érezték úgy, hogy rosszul "hallanak"... talán a ComputerWire is, aki biztos ami biztos rákérdezett...

John Loiacono, a Sun vezető szoftver alelnöke azt nyilatkozta, hogy teljesen komolyan gondolták a dolgot. Kérdés, hogy a HP mit szól az ötlethez...

A cikk itt.

( rigidus | 2006. 03. 11., szo – 17:27 )

Fene tudja, en meg mindig idegenkedem a gondolattol. Annyiszor szo esett mar ilyen probalkozasokrol regebben es mindegyik kudarcot vallott.

[off]
A linkelt oldalon eleg tre az a nagy telibenyomott animacio a cikk kozepen, maga a cikk meg nadszal vekony.

Vannak akik kepesek naponta ilyen ocskan szedett oldalakat olvasni?
[/off]
---------------------
Ригидус а бетегадьбол

Valaminek apránként történnie kell a kereskedelmi UNIXok környékén, a nagy visszaesésüket nem a Windows-ÜbertuttiTurbo2017ProfessionalServerEdition-nek köszönhetik hanem a Linuxnak. Két út áll előttük, a nyitás az opensource felé illetve az egyesülés és megmaradás a kereskedelmi pályán.

A lényeg az, hogy mozgolódás van.:-)

Hat igen. Vegulis a leghosszabb lepcso is az elso lepcsofokkal kezdodik. :)

"Két út áll előttük, a nyitás az opensource felé illetve az egyesülés és megmaradás a kereskedelmi pályán."

Az elso utat jarhatobbnak tartom, a masodik felol mar ketelyeim vannak. Egy ilyen fuzional a masodikkal 3 gond lenne. Az egyik az, hogy csak rovid-/kozeptavon lenne kiut, a masik, hogy ki harapja a nagyobb szeletet a kenyerbol, valamint amire most nagy szukseg lenne: az ido. Az egyezkedes pedig felzabalja azt. Az meg mint tudjuk keves van es mindig csak fogy.
---------------------
Ригидус а бетегадьбол

Sajnos a ker. unixokat nem csak a linux üti, hanem a windows is. Nem egy helyet ismerek, ahol a HP-UX-os környezetet nem Linux-ra, hanem bizony Windows-ra cserélték. Szok, occó. A megbízhatóság meg nem érdekes. Végülis, egy mai átlagos számítástechnikus számára a reboot az elsődleges hibajavítási megoldás. Az pedig PC-n sokkal gyorsabb mint rendes számítógépen. :-(

Ave, Saabi.
ps: tisztelet a kivételnek, a fenti véleményem a való életben tapasztaltak alapján alakult ki.

( snq- | 2006. 03. 11., szo – 19:00 )

>> A Sun komolyan gondolta a Solaris - HP-UX egyesítést
"Addig röhögtünk a főnök viccén, amíg megértettük, hogy az a mai feladat"

( bra | 2006. 03. 11., szo – 19:07 )

Lehet, hogy csak én vagyok ilyen korlátolt, de nem igazán tudom elképzelni ezt a Solaris-HP-UX kombót.

Úgy érted, hogy Solaris és HP-UX külön?
Azt sem tudom elképzelni, hogy a HP a közeljövőben dobja a saját OS-eit a Solaris kedvéért. Bár az a cég, amelyik ezt képes volt megtenni a Tru64-gyel és az alphával, erre is képes lehet. :)

Hogy röhögnék az OpenVMS-t és HP-UX-ot futtató itaniumos csókákon... Az tuti, hogy drasztikusan nőne az öngyilkosságok száma. =)

Főleg mert a VMS nem Unix származék. Ráadásul szerintem a VMS-nek semmi szüksége a Sun-ra és a Solaris-ra. Mondjuk szerintem a HP-UX-nak sincs rá szüksége, nem látom mivel tud többet a Solaris. Lehet azért, mert nem ismerem a Solarist.

A HP-UX ugyan a PA-RISC megszüntetésével csak egy platformon lesz használható, Itanium-on, de az Itanium megjelenése elött is csak egyetlen platformon futott, PA-RISC-en, ez mégse okozott problémát.

Ave, Saabi.

Már elkezdtem, a polcomon ott figyel egy SPARC-os és egy x86-os, 10-es Solaris régi kollegáim szíves közreműködésével. Mostmár csak egy olyan gépet kéne találnom, amire feltehetem. De sajnos főleg PA-RISC-es és Itanium-os gépeink vannak. Meg Alpha-sak. :-D
Sebaj, majd keresek egy PC-t, vagy marad a VMWare. Bár ezek olyan játék dolgok... :-D

Ave, Saabi.

Ki tudja, lehet, hogy valamikor, valaki majd portolja (újra) a (Open)Solarist Itaniumra.
Akkor aztán megismerheted a Solaris igazi erejét. :)

Egyébként a HP-UX szerintem sok tekintetben el van maradva a Solaristól. Ha lenne valami jó kis timeline a két rendszer fejlődéséről, valószínűleg a solarisos oszlop bizonyos bejegyzéseit csak évekkel később találnád meg a HP-UX-os oszlopban, ha egyáltalán.
Persze biztos van ilyen fordítva is, de gyanítom kevesebb.

Skálázhatóságban, meg a "limitek" oszlopban is tuti lenne némi lemaradás.

Ezt már mástól is hallottam, főleg amikor a kernel fordításról van szó. Márminthogy a Solarisban ilyen nincs, a HP-UX-ban meg még akad. Persze egyre kevesebb, a 11iv2-ben sok a dinamikusan betölthető modul, dinamikusan változtatható illetve boot-kor automatikusan beálló paraméter.
Mondjuk az azért egyszerűbbé teszi a konfigurálást, hogy - kollegák szerint - a Sun sokkal homogénebb gépparkkal dolgozik.
De tényleg kiváncsi volnék arra, hogy mit tud a Solaris, amit a HP-UX nem és fordítva. Sajnos én - ezt megismétlem - nem ismerem a Solaris-t, tehát nem tudok előállni ilyen listával.

Ave, Saabi.
ps: viszont a kedvenc HP-UX parancsommal - ioscan - még sehol máshol nem találkoztam. Azonos funkciójúval se, bár az lspci, lsusb kezd hasonlítani.

ps: viszont a kedvenc HP-UX parancsommal - ioscan - még sehol máshol nem találkoztam. Azonos funkciójúval se, bár az lspci, lsusb kezd hasonlítani.

http://www.computing.net/unix/wwwboard/forum/6779.html
He-he...:-)

I can't use ioscan on my RedHat, is that any command I can use on my RedHat to display the same info when I do a ioscan on a HPUX?

Hát ez harmat. Mint írtam, hasonló létezik. A példádban is csak az ioscan egy-két funkcióját helyettesítő megoldást találni. De annyira részletes HW map-et még semmiből nem sikerült kicsikarnom mint az ioscan-ből. Na, talán az Everest (AIDA) ilyen, de az meg Windows-on fut.

Ave, Saabi.

Lásd milyen vagyok, ime a HP9000 K460 serverünk ioscan -fn kimenete:
---
Class I H/W Path Driver S/W State H/W Type Description
==================================================
bc 0 root CLAIMED BUS_NEXUS
bc 1 8 ccio CLAIMED BUS_NEXUS I/O Adapter
fc 2 8/0 fcT1 CLAIMED INTERFACE HP Fibre Channel Mass Storage Adapter
lan 3 8/0.5 fcT1_cntl CLAIMED INTERFACE HP Fibre Channel Mass Storage Cntl
/dev/fcms3
fcp 2 8/0.8 fcp CLAIMED INTERFACE FCP Protocol Adapter
ext_bus 18 8/0.8.0.0.0 fcparray CLAIMED INTERFACE FCP Array Interface
target 0 8/0.8.0.0.0.0 tgt CLAIMED DEVICE
disk 126 8/0.8.0.0.0.0.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t0d0 /dev/rdsk/c18t0d0
disk 127 8/0.8.0.0.0.0.1 sdisk CLAIMED DEVICE HP OPEN-9*19
/dev/dsk/c18t0d1 /dev/rdsk/c18t0d1
disk 128 8/0.8.0.0.0.0.2 sdisk CLAIMED DEVICE HP OPEN-9*19
/dev/dsk/c18t0d2 /dev/rdsk/c18t0d2
disk 129 8/0.8.0.0.0.0.3 sdisk CLAIMED DEVICE HP OPEN-9*19
/dev/dsk/c18t0d3 /dev/rdsk/c18t0d3
disk 130 8/0.8.0.0.0.0.4 sdisk CLAIMED DEVICE HP OPEN-9*19
/dev/dsk/c18t0d4 /dev/rdsk/c18t0d4
target 1 8/0.8.0.0.0.1 tgt CLAIMED DEVICE
disk 131 8/0.8.0.0.0.1.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t1d0 /dev/rdsk/c18t1d0
target 2 8/0.8.0.0.0.2 tgt CLAIMED DEVICE
disk 132 8/0.8.0.0.0.2.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t2d0 /dev/rdsk/c18t2d0
target 3 8/0.8.0.0.0.3 tgt CLAIMED DEVICE
disk 94 8/0.8.0.0.0.3.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t3d0 /dev/rdsk/c18t3d0
target 4 8/0.8.0.0.0.4 tgt CLAIMED DEVICE
disk 95 8/0.8.0.0.0.4.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t4d0 /dev/rdsk/c18t4d0
target 5 8/0.8.0.0.0.5 tgt CLAIMED DEVICE
disk 96 8/0.8.0.0.0.5.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t5d0 /dev/rdsk/c18t5d0
target 6 8/0.8.0.0.0.6 tgt CLAIMED DEVICE
disk 97 8/0.8.0.0.0.6.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t6d0 /dev/rdsk/c18t6d0
target 7 8/0.8.0.0.0.7 tgt CLAIMED DEVICE
disk 133 8/0.8.0.0.0.7.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t7d0 /dev/rdsk/c18t7d0
target 8 8/0.8.0.0.0.8 tgt CLAIMED DEVICE
disk 134 8/0.8.0.0.0.8.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t8d0 /dev/rdsk/c18t8d0
target 9 8/0.8.0.0.0.9 tgt CLAIMED DEVICE
disk 135 8/0.8.0.0.0.9.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t9d0 /dev/rdsk/c18t9d0
target 10 8/0.8.0.0.0.10 tgt CLAIMED DEVICE
disk 136 8/0.8.0.0.0.10.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t10d0 /dev/rdsk/c18t10d0
target 11 8/0.8.0.0.0.11 tgt CLAIMED DEVICE
disk 137 8/0.8.0.0.0.11.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t11d0 /dev/rdsk/c18t11d0
target 12 8/0.8.0.0.0.12 tgt CLAIMED DEVICE
disk 98 8/0.8.0.0.0.12.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t12d0 /dev/rdsk/c18t12d0
target 13 8/0.8.0.0.0.13 tgt CLAIMED DEVICE
disk 99 8/0.8.0.0.0.13.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t13d0 /dev/rdsk/c18t13d0
target 14 8/0.8.0.0.0.14 tgt CLAIMED DEVICE
disk 100 8/0.8.0.0.0.14.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c18t14d0 /dev/rdsk/c18t14d0
ext_bus 22 8/0.8.0.255.0 fcpdev CLAIMED INTERFACE FCP Device Interface
target 15 8/0.8.0.255.0.0 tgt CLAIMED DEVICE
ctl 15 8/0.8.0.255.0.0.0 sctl CLAIMED DEVICE HP OPEN-XP256
/dev/rscsi/c22t0d0
fc 1 8/4 fcT1 CLAIMED INTERFACE HP Fibre Channel Mass Storage Adapter
lan 2 8/4.5 fcT1_cntl CLAIMED INTERFACE HP Fibre Channel Mass Storage Cntl
/dev/fcms2
fcp 1 8/4.8 fcp CLAIMED INTERFACE FCP Protocol Adapter
ext_bus 8 8/4.8.0.0.0 fcparray CLAIMED INTERFACE FCP Array Interface
target 16 8/4.8.0.0.0.0 tgt CLAIMED DEVICE
disk 75 8/4.8.0.0.0.0.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t0d0 /dev/rdsk/c8t0d0
disk 90 8/4.8.0.0.0.0.1 sdisk CLAIMED DEVICE HP OPEN-9*19
/dev/dsk/c8t0d1 /dev/rdsk/c8t0d1
disk 91 8/4.8.0.0.0.0.2 sdisk CLAIMED DEVICE HP OPEN-9*19
/dev/dsk/c8t0d2 /dev/rdsk/c8t0d2
disk 92 8/4.8.0.0.0.0.3 sdisk CLAIMED DEVICE HP OPEN-9*19
/dev/dsk/c8t0d3 /dev/rdsk/c8t0d3
disk 93 8/4.8.0.0.0.0.4 sdisk CLAIMED DEVICE HP OPEN-9*19
/dev/dsk/c8t0d4 /dev/rdsk/c8t0d4
target 17 8/4.8.0.0.0.1 tgt CLAIMED DEVICE
disk 76 8/4.8.0.0.0.1.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t1d0 /dev/rdsk/c8t1d0
target 18 8/4.8.0.0.0.2 tgt CLAIMED DEVICE
disk 77 8/4.8.0.0.0.2.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t2d0 /dev/rdsk/c8t2d0
target 19 8/4.8.0.0.0.3 tgt CLAIMED DEVICE
disk 78 8/4.8.0.0.0.3.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t3d0 /dev/rdsk/c8t3d0
target 20 8/4.8.0.0.0.4 tgt CLAIMED DEVICE
disk 79 8/4.8.0.0.0.4.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t4d0 /dev/rdsk/c8t4d0
target 21 8/4.8.0.0.0.5 tgt CLAIMED DEVICE
disk 80 8/4.8.0.0.0.5.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t5d0 /dev/rdsk/c8t5d0
target 22 8/4.8.0.0.0.6 tgt CLAIMED DEVICE
disk 81 8/4.8.0.0.0.6.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t6d0 /dev/rdsk/c8t6d0
target 23 8/4.8.0.0.0.7 tgt CLAIMED DEVICE
disk 82 8/4.8.0.0.0.7.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t7d0 /dev/rdsk/c8t7d0
target 24 8/4.8.0.0.0.8 tgt CLAIMED DEVICE
disk 83 8/4.8.0.0.0.8.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t8d0 /dev/rdsk/c8t8d0
target 25 8/4.8.0.0.0.9 tgt CLAIMED DEVICE
disk 84 8/4.8.0.0.0.9.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t9d0 /dev/rdsk/c8t9d0
target 26 8/4.8.0.0.0.10 tgt CLAIMED DEVICE
disk 85 8/4.8.0.0.0.10.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t10d0 /dev/rdsk/c8t10d0
target 27 8/4.8.0.0.0.11 tgt CLAIMED DEVICE
disk 86 8/4.8.0.0.0.11.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t11d0 /dev/rdsk/c8t11d0
target 28 8/4.8.0.0.0.12 tgt CLAIMED DEVICE
disk 87 8/4.8.0.0.0.12.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t12d0 /dev/rdsk/c8t12d0
target 29 8/4.8.0.0.0.13 tgt CLAIMED DEVICE
disk 88 8/4.8.0.0.0.13.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t13d0 /dev/rdsk/c8t13d0
target 30 8/4.8.0.0.0.14 tgt CLAIMED DEVICE
disk 89 8/4.8.0.0.0.14.0 sdisk CLAIMED DEVICE HP DISK-SUBSYSTEM
/dev/dsk/c8t14d0 /dev/rdsk/c8t14d0
ext_bus 17 8/4.8.0.255.0 fcpdev CLAIMED INTERFACE FCP Device Interface
target 31 8/4.8.0.255.0.0 tgt CLAIMED DEVICE
ctl 10 8/4.8.0.255.0.0.0 sctl CLAIMED DEVICE HP OPEN-XP256
/dev/rscsi/c17t0d0
ba 0 8/8 GSCtoPCI CLAIMED BUS_NEXUS GSCtoPCI Bridge
lan 0 8/8/1/0 btlan CLAIMED INTERFACE HSC 10/100Base-TX K-Class
/dev/diag/lan0 /dev/ether0 /dev/lan0
lan 1 8/8/2/0 btlan CLAIMED INTERFACE HSC 10/100Base-TX K-Class
/dev/diag/lan1 /dev/ether1 /dev/lan1
bc 2 10 ccio CLAIMED BUS_NEXUS I/O Adapter
ext_bus 0 10/0 c720 CLAIMED INTERFACE GSC built-in Fast/Wide SCSI Interface
target 32 10/0.3 tgt CLAIMED DEVICE
disk 0 10/0.3.0 sdisk CLAIMED DEVICE SEAGATE ST39173WC
/dev/dsk/c0t3d0 /dev/rdsk/c0t3d0
target 33 10/0.4 tgt CLAIMED DEVICE
disk 1 10/0.4.0 sdisk CLAIMED DEVICE SEAGATE ST39173WC
/dev/dsk/c0t4d0 /dev/rdsk/c0t4d0
target 34 10/0.5 tgt CLAIMED DEVICE
disk 2 10/0.5.0 sdisk CLAIMED DEVICE SEAGATE ST39173WC
/dev/dsk/c0t5d0 /dev/rdsk/c0t5d0
target 37 10/0.6 tgt CLAIMED DEVICE
disk 3 10/0.6.0 sdisk CLAIMED DEVICE SEAGATE ST39173WC
/dev/dsk/c0t6d0 /dev/rdsk/c0t6d0
target 38 10/0.7 tgt CLAIMED DEVICE
ctl 0 10/0.7.0 sctl CLAIMED DEVICE Initiator
/dev/rscsi/c0t7d0
target 48 10/0.15 tgt NO_HW DEVICE
disk 66 10/0.15.0 sdisk NO_HW DEVICE SEAGATE ST118273WC
/dev/dsk/c0t15d0 /dev/rdsk/c0t15d0
bc 3 10/4 bc CLAIMED BUS_NEXUS Bus Converter
tty 0 10/4/0 mux2 CLAIMED INTERFACE MUX
/dev/diag/mux0 /dev/diag/tty0p1 /dev/mux0 /dev/tty0p1
/dev/diag/tty0p0 /dev/diag/tty0p7 /dev/tty0p0 /dev/tty0p7
ext_bus 14 10/4/4 scsi3 CLAIMED INTERFACE HP 28696A - Wide SCSI ID=7
target 35 10/4/4.6 target CLAIMED DEVICE
disk 46 10/4/4.6.0 disc3 CLAIMED DEVICE DGC C2300WDR5
/dev/dsk/c14t6d0 /dev/floppy/c14t6d0 /dev/rdsk/c14t6d0 /dev/rfloppy/c14t6d0
disk 48 10/4/4.6.1 disc3 CLAIMED DEVICE DGC C2300WDR5
/dev/dsk/c14t6d1 /dev/floppy/c14t6d1 /dev/rdsk/c14t6d1 /dev/rfloppy/c14t6d1
disk 49 10/4/4.6.2 disc3 CLAIMED DEVICE DGC C2300WDR5
/dev/dsk/c14t6d2 /dev/floppy/c14t6d2 /dev/rdsk/c14t6d2 /dev/rfloppy/c14t6d2
disk 50 10/4/4.6.3 disc3 CLAIMED DEVICE DGC C2300WDR5
/dev/dsk/c14t6d3 /dev/floppy/c14t6d3 /dev/rdsk/c14t6d3 /dev/rfloppy/c14t6d3
ext_bus 1 10/4/8 scsi1 CLAIMED INTERFACE HP 28655A - SE SCSI ID=7
ext_bus 2 10/4/9 lpr2 CLAIMED INTERFACE HP 28655A - Parallel Interface
/dev/c2t0d0_lp /dev/diag/c2t0d0_lp
ext_bus 15 10/4/12 scsi3 CLAIMED INTERFACE HP 28696A - Wide SCSI ID=7
target 36 10/4/12.6 target CLAIMED DEVICE
disk 47 10/4/12.6.0 disc3 CLAIMED DEVICE DGC C2300WDR5
/dev/dsk/c15t6d0 /dev/floppy/c15t6d0 /dev/rdsk/c15t6d0 /dev/rfloppy/c15t6d0
disk 51 10/4/12.6.1 disc3 CLAIMED DEVICE DGC C2300WDR5
/dev/dsk/c15t6d1 /dev/floppy/c15t6d1 /dev/rdsk/c15t6d1 /dev/rfloppy/c15t6d1
disk 52 10/4/12.6.2 disc3 CLAIMED DEVICE DGC C2300WDR5
/dev/dsk/c15t6d2 /dev/floppy/c15t6d2 /dev/rdsk/c15t6d2 /dev/rfloppy/c15t6d2
disk 53 10/4/12.6.3 disc3 CLAIMED DEVICE DGC C2300WDR5
/dev/dsk/c15t6d3 /dev/floppy/c15t6d3 /dev/rdsk/c15t6d3 /dev/rfloppy/c15t6d3
ext_bus 3 10/4/16 scsi1 CLAIMED INTERFACE HP 28655A - SE SCSI ID=7
ext_bus 4 10/4/17 lpr2 CLAIMED INTERFACE HP 28655A - Parallel Interface
/dev/c4t0d0_lp /dev/diag/c4t0d0_lp
ext_bus 5 10/8 c720 CLAIMED INTERFACE GSC add-on Fast/Wide SCSI Interface
target 39 10/8.3 tgt CLAIMED DEVICE
disk 5 10/8.3.0 sdisk CLAIMED DEVICE SEAGATE ST39236LC
/dev/dsk/c5t3d0 /dev/rdsk/c5t3d0
target 40 10/8.4 tgt NO_HW DEVICE
disk 6 10/8.4.0 sdisk NO_HW DEVICE SEAGATE ST39236LC
/dev/dsk/c5t4d0 /dev/rdsk/c5t4d0
target 42 10/8.5 tgt CLAIMED DEVICE
disk 7 10/8.5.0 sdisk CLAIMED DEVICE SEAGATE ST39236LC
/dev/dsk/c5t5d0 /dev/rdsk/c5t5d0
target 47 10/8.6 tgt CLAIMED DEVICE
disk 16 10/8.6.0 sdisk CLAIMED DEVICE SEAGATE ST39173WC
/dev/dsk/c5t6d0 /dev/rdsk/c5t6d0
target 43 10/8.7 tgt CLAIMED DEVICE
ctl 1 10/8.7.0 sctl CLAIMED DEVICE Initiator
/dev/rscsi/c5t7d0
ba 1 10/12 bus_adapter CLAIMED BUS_NEXUS Core I/O Adapter
ext_bus 7 10/12/0 CentIf CLAIMED INTERFACE Built-in Parallel Interface
/dev/c7t0d0_lp
ext_bus 6 10/12/5 c720 CLAIMED INTERFACE Built-in SCSI
target 44 10/12/5.0 tgt CLAIMED DEVICE
tape 0 10/12/5.0.0 stape CLAIMED DEVICE HP C1537A
/dev/rmt/100m /dev/rmt/100mnb /dev/rmt/c6t0d0BESTn /dev/rmt/c6t0d0DDSb
/dev/rmt/100mb /dev/rmt/c6t0d0BEST /dev/rmt/c6t0d0BESTnb /dev/rmt/c6t0d0DDSn
/dev/rmt/100mn /dev/rmt/c6t0d0BESTb /dev/rmt/c6t0d0DDS /dev/rmt/c6t0d0DDSnb
target 45 10/12/5.2 tgt CLAIMED DEVICE
disk 4 10/12/5.2.0 sdisk CLAIMED DEVICE HP DVD-ROM 6x/32x
/dev/dsk/c6t2d0 /dev/rdsk/c6t2d0
target 46 10/12/5.7 tgt CLAIMED DEVICE
ctl 2 10/12/5.7.0 sctl CLAIMED DEVICE Initiator
/dev/rscsi/c6t7d0
lan 4 10/12/6 lan2 CLAIMED INTERFACE Built-in LAN
/dev/diag/lan4 /dev/ether4 /dev/lan4
ps2 0 10/12/7 ps2 CLAIMED INTERFACE Built-in Keyboard/Mouse
/dev/ps2_0 /dev/ps2_1 /dev/ps2kbd /dev/ps2mouse
processor 0 32 processor CLAIMED PROCESSOR Processor
processor 1 34 processor CLAIMED PROCESSOR Processor
processor 2 36 processor CLAIMED PROCESSOR Processor
processor 3 38 processor CLAIMED PROCESSOR Processor
memory 0 49 memory CLAIMED MEMORY Memory
---

Kicsit szétesett. :-(
De talán kivehető.

Ave, Saabi.

A Solarisban is lehet modulokat betölteni, azokat egész intelligensen paraméterezni (konfig fájlból), illetve egyre több paraméter állítható nem csak bootkor, de menet közben is.

A Sunnál hol homogénebb a géppark? Több (igaz, egymással részben kompatibilis, de azért némileg más) generációs SPARC processzorok, rendszerek, Intel x86, AMD64. Utóbbiakon azért koránt sem tökéletes a kompatibilitás, de azért sokszor megbízhatóbb még így is az OS, mint mondjuk a Linux.

Egy dolog biztos van, amit a HP-UX nem tud, ez a dtrace.

A Solarishoz képest úgy tudom a HP-UX-ban elég későn jelent meg az SMP, az NFS(v3, TCP, mondjuk ez talán érthető is :), a threadek, hasonlók.

A HP-UX pedig valószínűleg a volume menedzsmentben volt jobb, a Veritas kötődés miatt, illetve a clusteres képességek terén is talán előrébb volt/van, mint a Solaris (de itt talán a VMS, vagy a Tru64 megelőzi).

Gyanítom nem sokan vannak, akik töviről-hegyire ismernek egynél több unixot, de úgy általában bármilyen OS-t, bár egy felületesebb összehasonlításhoz talán nem is kell.

Ami a HP-UX-ban úgy tudom még mindig "gyerekcipőben" jár, az a nagyobb fájlrendszerek használata (pld. FreeBSD alatt bármikor csinálok több száz TB-os fájlokat és fájlrendszereket, Solaris alatt pedig ugyanezt PB-os méretekben is össze lehet hozni, főleg ZFS-sel), vagy talán a késői threadesítés miatt a kernel megfelelő MP skálázódásában.
A nagyobb Sun gépekben (és az Opteronokban) lévő beépített memóriakontroller és a különféle interconnectek miatt nagy szerepet kap az OS NUMA képessége is, tehát, hogy megfelelően tudja a processzeket ütemezni, a hozzájuk tartozó memóriát és IO-t allokálni, stb. Nem ismerem a HP gépek architektúráját, de egy bizonyos szint felett az Itanium is el kell, hogy veszítse az SMP jellegét, az újabb PA-RISC-ekben pedig szintén a CPU-ban van a kontroller, tehát ott egy két processzoros gép már rögtön NUMA, nem pedig SMP. Ehhez hogy viszonyul a HP-UX?

Nem tudom mennyire jellemző itt a dinamikus gépbővítés, processzorok, processzor boardok ki, és behelyezésével, velük együtt memória csökkentés, növelés, illetve azonos rendszeren belül eltérő típusú processzor és memóriaboardok használata, menet közbeni IO bővítés.

Azt tudom, hogy VMS-ben clusteren belül ezt akár kevert architektúrákkal (pld. alpha-itanium) is meg lehet játszani, de az nem HP-UX. :)

Ejj, de jó is lenne mindentudónak lenni.

Nekem hozzáértő kollegák mondták, hogy a Sun gépparkja ugyanazokból az alkotóelemekből épül fel. Ugyanaz a rendszerbusz, memória, CPU...

Mi az a dtrace?

Az biztos, hogy a thread-ek későiek, a HP-UX 10.20 még csak valami workaround szinten tudta. ( azaz nem ;-) ). Az SMP-ben nem vagyok biztos, persze az is igaz hogy én csak tíz éve foglalkozom HP-UX-szal, hogy azelött mi volt, nem tudom.

Nem tudom a Veritas-nak mennyi köze van az LVM-hez. Tudtommal az HP fejlesztés. A Vertias-tól a VxVM meg a VxFS van. A VxVM lett volna a HP-UX 11iv2 alapértelmezett volume management software-e, de valamiért mégis maradt az LVM. A VxFS viszont valóban jelenleg _A_ file-rendszer HP-UX alatt. Hogy a Tru64 AdvFS-e jobb-e mint a HP-UX-nál az LVM-VxFS páros, nem tudom, lehet. Nekem valahogy nem tetszik ha a volume management és a filesystem egy termékkel van megoldva, de ez erősen szubjektív vélemény. Viszont az AdvFS tudtommal a VxVM-ből származik. Az meg van HP-UX alá, ha valakinek ez kell. :-)

Ami a filerendszereket illeti igazságod vagyon, 32 TByte v2-n és 2 TByte v1-en. Mondjuk nekem még ennyire se volt szükségem. :-D

Ha közepes vagy nagy server-ekről beszélünk, tehát ahol megjelenik a hardware partíció, ott óhatatlan NUMA rendszerről beszélünk, hisz a cellákban lévő memória más távolságban van a saját és más távolságban az egyéb cellákban lévő CPU-któl.

A menet közbeni IO bővítés ill. csere nem probléma. CPU ill. memória csere vagy bővítés tudtommal még nem lehetséges. Kivéve a partícionálható rendszereket, ott elég a szerelés alatt álló partíciót leállítani. Persze ehhez a használt OS-nek semmi köze.

Ave, Saabi.

A DTrace (Dynamic Tracing Framework) a Solaris 10-ben jelent meg először hivatalosan (Solaris Express-en keresztül már kb. 2004. eleje óta használható volt), azóta a Solaris fejlesztők és adminisztrátorok csodafegyvere. Egy debug és tuning keretrendszer (egyesek szerint még ennél is több).

--
trey @ gépház

Azok a hozzáértő kollegák valamit félrenézhettek. Eleve nem lehet ugyanabból a CPU-ból és memóriából, hiszen még most is minimum két, de inkább több CPU (USIII és USIV, illetve most már a T1 és ezek különféle verziói) van forgalomban és ezek között alapvető különbségek vannak.
Az USIV például kétmagos, de a beépített memóriavezérlővel rendelkezik. A nagyobb gépeknél pedig már CPU és IO boardok vannak, amelyek közötti hierarchiát is figyelembe veszi az OS az ütemezéskor.

A dtrace-t Trey leírta. Ha megtanulod, tényleg csodafegyver, ha alkalmazást kell hangolnod, tuningolnod. Nagyon sok mindent meg lehet vele nézni, amit egyébként csak sokkal nehezebben, vagy sehogy sem tudnál elemezni.

Tíz évnél én sem tudom jobban áttekinteni, úgyhogy határozottan az utóbbi max. 10 évről van szó. :)

Ami érdekes, hogy ahány ismerősöm van, mindegyik inkább Tru64 "rajongó", nem pedig HP-UX. Én magam ez utóbbit sosem használtam, de az előbbi annyira nem volt elviselhetetlen.

Ha olcsóbb lenne az Itanium, vennék egyet kísérletezgetni. Most már elég sok OS megy rajta (Windows, Linux, FreeBSD :), OpenVMS, HP-UX). Megérjük még talán a (Open)Solarist is, a Tru64 sajnos elveszett, pedig a HP egy időben nagyon integrálni akarta a HP-UX-ba. (na ennyit a HP-UX-Solaris házasságról)

2TB ma már otthon sem mondható soknak. A 32TB pedig még valóban elég lehet a jövő év végéig pár helyen, máshol pedig már 5 évvel ezelőtt is kevés volt. Viszont ezek fájlrendszer méretek, ha jól sejtem és a max. fájlméret a v2-ben is 4TB, nem? Más kérdés, hogy nem túl gyakori ekkora fájlokkal dolgozni, ez igaz.

Az OK, hogy NUMA-ról beszélünk, de vajon mennyire képes kihasználni ezt az OS? Marhára nem mindegy, hogy ezeket a tulajdonságokat figyelmen kívül hagyja és az össze-vissza ütemezéssel szétterheli az interconnecteket, vagy pedig ésszel csinálja és takarékoskodik ezekkel a forgalmakkal. Szívesen olvasnék némi mélyebb technikai leírást, tudsz esetleg ilyenről?

Ami számomra még kérdéses az a PA-RISC-Itanium váltás. Az Itanium más filozófiájú processzor, mint az elődök (bár a PA-RISC-et annyira nem ismerem, de a RISC elég árulkodó a nevében :). Kérdés, hogy mennyire vették ezt figyelembe. Nekem van egy olyan gyanúm, hogy megcsinálták rá a portot, de a többivel nem foglalkoztak, így az Itanium képességeit a kernel (és a rajta futó szoftverek egy része is) kevésbé használja ki.

Na, akkor például egy dolog, amit a Solaris már régóta tud, a HP-UX pedig ezek szerint nem. :)
Az OS-nek pedig igenis köze kell, hogy legyen ahhoz, hogy a használt memóriát fel tudja szabadítani és az érintett (eltávolítandó) processzorokra ne ütemezzen új feladatokat, illetve ha új erőforrásokat kap, akkor azokat elkezdje használni.

Én sose dolgoztam Tru64-el, szóval nem tudom azt se összehasonlítani semmivel. Amikor elkezdtem ismerkedni vele, mindenféle licencek kellettek egy alapszinten működő rendszerhez is, itt feladtam.

Azért irigyellek, hogy neked otthon a 2T természetes. :-) Én már öreg vagyok - maholnap 33 éves -, számomra a terrabyte-os fileméret irrealitás.

A NUMA-s kérdésedre nem tudok válaszolni. Első lépésben javasolnám hogy nézz körül a docs.hp.com-on. Ha ennél jobban érdekel a dolog, körülnézhetek benn is, ha van valami nem "confidental" info.

Hogy az Itanium képességeit az OS mennyire használja ki, nem tudom. De már pár éve faragják, a 11.23-om, azaz a 11iv2 már a harmadik HP-UX verzió ami Itaniumra készült, nem hiszem hogy csak úgy összecsapták volna.

Félreértettél. Az nPar gépek részenkénti leállítására állítottam hogy az OS-nek nincs hozzá köze. Ugyanis az nPar gépeknek az a lényege, hogy a partíciók egymástól szinte teljesen függetlenek. OS szinten mindenképp, egy nPar gépen egymástól különböző OS-ek is lehetnek.

A HP-UX - Tru64 integrálásról sokat nem tudok, csak annyit hogy a TruCluster-t akarták elsősorban belepakolni, de aztán inkább a Veritas megoldását választották.

Ave, Saabi.

Nem természetes, mert nincs szükségem ennyi helyre. De őszintén. 2TB 4 darab 500 GB-os diszk. Csak azért nincsenek ekkora méretek, mert a szerverekben még mindig a kisebb, de "pörgősebb" 73 és 146 GB-os 15kRPM-es diszkek vannak. A 300GB-os 10k-sak is csak nemrég jelentek meg és sebességbeli megfontolások (illetve tartósság) miatt még kevesen használják őket.

Értettem a partíciós dolgot, az teljesen rendben is van. De a Sun megoldása azért más, amikor menet közben bővíthető a gép. Más kérdés, hogy olyan sokan azért talán nem használják.

Anno volt a nagy szerverkonszolidációs időszak (olcsó PC-k helyett használjon mindenki E15-20-25k-t), azzal jött a Sun, hogy milyen jó lesz, ha egy ügyfélnek belassul a gépe, beletolja a rendszergazda az x processzort tartalmazó kártyát és már gyors is, ha pedig nem kell, kiveszi.

Hát, tipikusan ilyenek vannak a magyar ISP-knél. :)

> Viszont az AdvFS tudtommal a VxVM-ből származik.

Rosszul tudod. A Tru64-ben meglevő dolgok közül nem az AdvFS az, aminek a Veritas-hoz köze van, hanem az LSM (az LVM digitalos megoldása, am: Logical Storage Manager). Javaslom összevetni az LSM parancsait az általad is ismert VxVM-es parancsokkal (többségükre igaz, hogy ha a parancs vol-lal kezdődik, akkor ez Tru64/LSM, és úgy kapod meg a VxVM-es parancsot, h ezt kicseréled vx-re):

Tru64/LSM - HP-UX/VxVM

volprint - vxprint ;
voldisk - vxdisk ;
volsd - vxsd ;
volplex - vxplex ;
volume - vxvol (ez itt a kakukktojás) ;
stb, a folytatáshoz ajánlott olvasmány a FreeBSD oldaláról elérhető onlány man nézegető, amiben többek között HP-UX és Tru64 man-okat is lehet nézegetni ( http://www.freebsd.org/cgi/man.cgi )

Szóval ne a melletted ülő kollegát kérdezd, ő úgy se ért semmihez, hanem a szemed irányában kb 2-3-4 sorral arrébb ülőket. Mondjuk az én volt (és a te mostani) kollegám pl. már látott közelről Tru64-et is, meg HP-UX-ot is (ez utóbbit ugyan nem bíznám rá, de ez mindegy); Kris pedig van olyan művelt, h lehet tőle ilyeneket is kérdezni :-) - még akkor is, ha Tru64-ben utazik.

Úgy gondolod ideje azt is mélyebben megérteni? Nem gond, az itthoni vas Elric szerint alkalmas a futtatására (települni tudott rajta, sőt egy kicsit futkrászott is), két család nélküli 7vége, és megvagyok :-D Ja, és mivel van Solarisos oktatási anyagom, így fel tudok belőle készülni.

Nalunk fel evnel fiatalabb gepben halt be a videocard. Made in USA :-) A szervizes viszont direkt hangsulyozta tobbszor is, hogy ha a HP telefonal felmeres celjabol, hogy mennyire voltunk elegedettek es milyen volt a szolgaltatas, akkor ne azt mondjuk, hogy jo, hanem hogy kivalo.
Sajat cipojevel kellett volna agyonverni...

Termeszetesen erdekelne, mi ennek az oka, de terjunk a lenyegre.
Az irrealisan draga geppel sem voltam elegedett, egy fostubus manli vagy eagle kartya is tovabb birja, mint az, amit ki kellett cserelni. A szerviz szolgaltatassal sem voltam elegedett: toprenges, hogyan is kell szetszedni a gepet (a munkafolyamat soran tobbszor is), es kozben a folyamatos pofazas latrina-szajszaggal sulyosbitva (biztos nem volt ideje fogat mosni). Mivel ezek lehet, hogy csak nekem szamitanak zavaronak, ne is vegyuk figyelembe, de az, hogy vagy 5x elmondja, hogy kivalo minositest adjunk, ne csak azt mondjuk, hogy jo, igencsak felidegesitett.
Adjanak egy listat, es mondja azt, hogy figyu oreg, ha hivnak a cegtol, ebbol a listabol valaszd ki, mennyire voltal elegedett es faxold el vagy scanneld be es kuldd el a cegnek. Pl:

"A szervizmernok szakmai felkeszultsegevel, stb, stb mennyire volt elegedett? Valasszon az alabbi listabol:

1. Chuck Norris vegezte volna a javitast, de mire kozelebe ert a cegnek, mar megjavult a device.
2. Kivalo.
3. Jo.
4. Elfogadhato.
5. Botrany.
6. Le kellett loni, hogy ne szenvedjen."

Nekem is volt hp-s ugyem. Szar volt az uj laptop tapcsatija, a gep 2 honapot volt szervizben, miutan hosszas konyorges utan nekilattak. De olyan "josagosak" voltak velem, es kicsereltek a gep alaplapjat, (a franc se kerte) most mar az oraja is megall ha kikapcsolom, elotte jo volt. Ja, a tapcsati? Nehany het mulva az uj alaplapon levo is bekakkantott. Gari lejart, szal szetkaptam, beforrasztottam normalisan mivel mar csak egy sovany onturha fogta oda hogy el ne vesszen. Aztan szetneztem az alaplapon es talaltam meg 21 forrasztasi pontot ahol a csatikat szinten csak a takony tartotta.

Mindegy. A kivitelezes es a support KIVALLO. ;-) (tobbet az eletben nem veszek toluk semmit)
---------------------
Ригидус а бетегадьбол

Jópár éve nekem is volt egy HP supportos esetem. Alaplapot cseréltek egy béna PC szerverükben (alaplap: made by ASUS :).
A gép működött, de pár nap/hét múlva mindig lerohadt (Linux volt rajta, de akkor emiatt még nem gyanakodtam =).
Felkészültem előre arra, hogy magyarázkodnom kell, meg hasonlók.

Nem kellett, szó nélkül cseréltek mindent (a biztonság kedvéért még processzort és memóriát is :).

Utána pár nappal egy külföldi (talán angol) számról hívtak. Beköszöntem, mire egy csak magyarul hadarva (jól begyakorolt szövege volt) megkérdezte, hogy mi volt a véleményem a kollega munkájáról.

Mondtam neki, hogy mióta itt volt, folyamatosan csillog a seggem és nagyon tiszta érzés. :)

Kérte, hogy egy szóval értékeljem a munkáját. Azt mondtam, hogy kiváló.

Na ezek szerint jót mondtam. A különbség annyi, hogy én így is gondoltam, illetve senki meg sem említette, hogy telefonon később megkérdezik a véleményem.

( anr | 2006. 03. 11., szo – 19:14 )

Az egesz a penzrol szol. Talan Bruce Perens szamolta ugy, hogy egy kereskedelmi UNIX eves "fenntartasi" koltsege $200mill. $100mill-el no cegenkent az eves profit, ha felesben csinaljak:)

Anr - http://andrej.initon.hu

Viszont más oldalon pedig drasztikusan csökkenne. Azok, akik a PC-nél komolyabb hardvert használnak egy ilyen akció után tényleg át kellene, hogy álljanak a Sun cuccokra (vagy próbálkozhatnának Linuxszal, LOL :), ez pedig elég érzékenyen érintené a HP-t.
Ki tudja. Sok extrém hírből lett már igazság. :)

Húha, látom a flameljük a Linuxot topicba érkeztem :) Azt OK, hogy nagy-nagy-nagy rendszerekre egyelőre jobbak a kereskedelmi Unixok (tudom Bra, a FreeBSD is :)), de azt vegyük figyelembe, hogy a legjobban teljesíteni és minden lehetőséget kihasználni a saját vasukon tudnak. De pl érdemes megnézni az IBM belépő szintű Power cuccait (710-es és 720-as) amik azért tükröznek egy másfajta lehetőséget is és biztató jövőt mutatnak. Szerintem a Linuxban oriási tartalékok vannak és a magasabb szintű rendszereken is meg fog jelenni. Eddig mindig sikerült továbblépni, miért ne sikerülne most is??

A FreeBSD nagy-nagy-nagy rendszerekre? Dehogy. Messze van az attól. :)
A Linuxszal kapcsolatban nekem leginkább a következetlenség és a mérhetetlen káosz fáj. Néha kapkodnak és gyakran olyan dolgokat raknak össze, amikben nincs rendszerszemlélet, csak kis szigetek a kernelen belül.
Aztán meg más szemére vetik, ha ő is így ír kódot.

Szerintem jót tenne a Linuxnak, ha néha átgondolnának, megterveznének dolgokat és csak ezután kezdenének el vadul fejleszteni. Nem azt mondom, hogy a kereskedelmi Unixokban, vagy a BSD-kben ez feltétlenül teljesül, de sokkal összeszedettebnek látom, azt, ami ott van.

A Linuxnak ebből olyan előnye van, hogy bizonyos területeken sokkal gyorsabban fejlődik bármi másnál, viszont kérdéses, hogy ez a fejlesztési modell meddig képes jól működni.

>Szerintem jót tenne a Linuxnak, ha néha átgondolnának, megterveznének dolgokat és csak ezután kezdenének el vadul fejleszteni.
a legcsekelyebb mertekben sem ertek egyet veled. azert jutott el a Linux oda ahol most van (es _NEM_ a *BSD, *UNIX!!!!), mert Linus _megengedi_, hogy a kernelbe keruljenek kulonfele dolgok, ha a kod minosege megut egy altala meghatarozott szintet (pl a ggi vagy 10 even keresztul nem utotte ezt meg). A *BSD,*UNIX filozofia, hogy csak azt engedjuk, amit a kurvaokosnagyfonok(TM) megenged pontosan ott hibas, hogy nem erthet egyetlen ember mindenhez(!).
linux fut a 10 legnagyobb szupercomputerbol 9-en, es egy nagy rakat embedded rendszeren, alkalmas desktopnak, grafikai munkaallomasnak, rendererfarmnak, 10240-3xxx quake kliensnek, es meg ki tudja minek.
A M$,*BSD,*UNIX ezeknek csak kis reszere hasznalhato! ez nem veletlen.
Ketsegkivul ha _valsztasz_ egy specialis reszteruletet _ODA_ tervezhetsz egy linuxnal jobb/optimalisabb rendszert, de _buksz_ egy rakat mas lehetoseget.
A linux a bazar fejlesztesi modellrol szol, nem a _GPL_-rol.
bazar rulez.
a *BSD, *UNIX, Solaris nem tunik bazarnak.

Anr - http://andrej.initon.hu

>> azert jutott el a Linux oda ahol most van [...] mert Linus _megengedi_, hogy [...]

vö.

>> A *BSD,*UNIX filozofia, hogy csak azt engedjuk, amit a kurvaokosnagyfonok(TM) megenged [...]

--

>> Ketsegkivul ha _valsztasz_ egy specialis reszteruletet _ODA_ tervezhetsz egy linuxnal jobb/optimalisabb rendszert, de _buksz_ egy rakat mas lehetoseget.

tehát ha valaki _tudja_ mire akarja használni a rendszerét, akkor megengeded neki, hogy ne linuxot válasszon hozzá? :)

;)
mindenki azt csinal amit akar. ha van kedved implementald ujra a win32 API-t;) azmiro en beszelek, az a _szerintem_ kovetendo optimum. semmi bajom azokkal, akik szamara ez drasztikusan mast jelent.

az *BSD *UNIX-al kapcsolatban is azt mondtam, hogy tulsagosan zartak. kizarnak rengeteg dolgot, mert a nagyfonoknek nem tetszik. ezt nem tartom hosszutavon kifizetodonek. de majd meglatjuk;)

aki meg pontosan tudja, hogy mire hasznalja/fogja hasznalni elete vegeig a rendszeret, az nyilvan tud matematikailag optimalis rendszert valasztani. fuggetlenul a jovobeli fejlesztesektol.
kb. a vadaszgepek/cirkaloraketak oprendzere ilyen.;))

Anr - http://andrej.initon.hu

Hát, én azt látom, hogy - bár volt az ellenkezőjére példa - a BSD rendszerek azért élnek csak még meg illetve azért fejlődtek tovább, mert volt Linuxos aktivitás. Ugyanis valaki megvcsinálta a linuxos drivert, open source, azt meg lehetett nézni és lehetett BSD-s kódot csinálni. Mivel látta, hogy miként működik a device, hogyan kell vezérelni. Aztán ezt kedvenc kerneléhez tudta igazítani, mondjuk FreeBSD kernelhez. Ez ugye nem palgizáció vagy kódlopás, mivel opensource a dolog, megteheted és licenc problémád sincs.
Aztán a cuccok jó részét még mindig linuxra fejlesztik - mondjuk pár személyes kedvencemet, pl. a postfixet FreeBSD-n :) -, de mivel a GNU userland és a GPL/LGPL/egyébopensourcelicenc "termékek" működnek BSD-n is, ezért használják még.
Egy cégnek ráadásul sokkal kedvezőbb LGPL vagy GPL alatt fejlsztenie, mint mondjuk BSD licenc alatt: kedvencem még mindig a Kerberos, ugye. Meg a teljes TCP stack 9X%-a NT4-ben és Win2k-ban, legalábbis a jól eldugott licenc noteok alapján.

Egyébként szeretem a FreeBSD-t, meg a többit is, semmi gond velük. Az igazság valahol a két fejlesztési modell között van. A linux kernel bazár jellege jó és hasznos, ezt egészítik ki a gyártók - RedHat, SUSE, Ubuntu, Debian, Gentoo stb. - a saját katedrális fejlesztéssel, amikor kiadásra formálnak egy adott kernel verziót és később követik a fejlesztést, biztonsági bejelentéseket stb. Ebből persze akadhatnak problémák, késések, pl. nekem is van olyan HP ML150G2-m, ami itt elhíresült a hup-on, mivel legendásan szar volt a támogatása minden rendszer alatt, ami más volt, mint Windows, ha nem a legújabb kernel.org-os kernelt használtad vagy nem patchelted meg a gyári kernel saját magad. Hivatalos kernel driverről ne beszéljünk, mivel gyártó köcsög módon nem verziókövette a kiadásokat.

"Röviden" ennyi.

> Hát, én azt látom, hogy - bár volt az ellenkezőjére példa - a BSD rendszerek azért élnek csak még meg illetve azért fejlődtek tovább, mert volt Linuxos aktivitás. Ugyanis valaki megvcsinálta a linuxos drivert, open source, azt meg lehetett nézni és lehetett BSD-s kódot csinálni.

Így van. Kivéve, amikor pont fordítva történt/történik, azaz hogy BSD-s kódot vesznek át, és csinálnak belőle Linux-kódot. Úgy gondolom, a nagyobb (jelenleg Free/Net/Open/DragonFly)BSD-k megéltek volna/megélnek még most is/ Linux nélkül, legfeljebb nem tartanának itt. Mint ahogy a Linuxok sem, ha a kezdet kezdetén _mindent_ előlről kellett volna megírni, nem lehetett volna lpd-t, bind-ot, netutilt, stb-t helyből használni. Mást ne mondjak, a disztribek többsége még mindig OpenSSH-t ad _alapból_, és még senki nem írt egy általánosan elterjedt GPL-es verziót.

> Egy cégnek ráadásul sokkal kedvezőbb LGPL vagy GPL alatt fejlsztenie, mint mondjuk BSD licenc alatt
No ez nem így van. He egy cégnek fejleszteni kell a _semmiből_ , akkor olyan licenc alatt fejleszt, ami jó neki (valszeg valami zárt cucc). Ha _átvesz_ valamit, akkor BSDL az igazán jó neki, ha pedig marketingfogásból (OK, tfh üzleti érdekből) kiadja a saját kódját, akkor valszeg a GPL jobb neki. A Kerberos azért tökéletes öngól példa, mert ugye nem cég fejlesztette. Amire te gondoltál, az az, hogy "A" cég átvette a BSD-s kódot, és gondosan nem publikálta a módosításokat.

> Aztán a cuccok jó részét még mindig linuxra fejlesztik - mondjuk pár személyes kedvencemet, pl. a postfixet FreeBSD-n

Akkor biztos vagy benne, hogy Linux_ra_ ? Nem lehet, h FreeBSD-re, csak éppen ellentétben kismillió szarfaszú Linuxra fejlesztővel, arra is odafigyel a fejlesztő(gárda), hogy más rendszeren is fusson? A tököm tele van azokkal az userland programokkal, amivel vért kell hugyozni a portoláskor, mert a tisztelt fejlesztő a saját szemétdombjánál nem lát tovább (pl: a kód nemhogy Linux specifikusan, de i386-Linux specifikus módon lett megírva; stb.).
Amúgy visszafele is igaz: A BSD userland kódok többsége is fut GNU/Linux környezetben. Természetesen lehet (sőt szinte biztos), hogy portolni kell.

Szépen sorban válaszolok :)

na, azt nem vitattam, hogy a *BSD nem élne meg, de nem tartana ott, ahol tart, az biztos. Az is biztos, hogy a Linux disztribek az elején meg sem tudtak volna mozdulni a sok más fejlesztés eredményei nélkül. Vagy később még hasznosabb funkciók jöttek át máshonnan, pl NSS, PAM a Solaris háza tájáról.

A BSD-s kódnál arra gondoltam, hogy ha én soha nem fejlesztenék BSD licenccel vagy fejlesztetnék. Az nekem mindegy volt, hogy cég vagy egyetem fejleszti, a lényeg, hogy BSD kódot legálisan le lehet nyúlni: hozzáfejlesztesz, majd nem adsz vissza semmit a közösségnek. Természetesen ezt megteheted GPL-es kóddal is, de akkor lehetnek jogi következményei.

Az, hogy vannak gagyi fejlesztők, akik nem tudnak portolható kódot írni, szomorú, de nem hiszem, hogy a valóban használható projekteknél ez nagy szám lenne. A postfixet freebsdn fejlesztik, ezt írtam fentebb is. De talán az apache-t is, ebben nem vagyok biztos.

OpenSSH helyett lehet dropbear-t használni. Kulcsos authentikáció stb.

Miért is ne? Ha abból indulunk ki, hogy az embereknek nyílt forrású OS kellett, akkor mondhatjuk, hogy ilyenből több is volt és ha nem lett volna Linux, egy másik lett volna hasonlóan népszerű.

Szerintem a GPL önző és nem is véletlen, hogy általában pont ezek a szavak kerülnek elő, ha a kettő összehasonlításáról van szó (lenyúlni, ellopni, bezárni, visszaélni, stb).

Más a megközelítés. Az egyik tábor (elméletileg) örül, ha a saját kis szarjaitól jobb lett a világ, még ha a fejlesztéseket nem is kapja vissza. A másik pedig inkább azt mondja, hogy a szabadságnak az a feltétele, hogy a változások visszajussanak.

Egyik sem jobb, más.

na, az utolsó mondattal egyetértek :) egyébként az a furcsa helyzet is kialakult, hogy az OpenBSD-sek jobban védik a drivert szabadságát, mint egyes linux felhasználók. Egyébként nem az a bajom, ha valaki kereskedelmi terméket fejleszt, de ha felhasznál valamit és abba belefejleszt amitől jobb lesz az eredeti nyílt forrású kód, akkor adja vissza a kódot. Ebből a szempontból az LGPL a legtisztább és általam legkedveltebb licenc.

Ago, három év FreeBSD CVS lista olvasásra kötelezlek. :)

Az, hogy Linuxra fejlesztenek dolgokat, sajnos sokszor meg is látszik a minőségen. Sok "fejlesztő" életében nem látott még unixot és azt hiszi, hogy a Linux az. Pedig nem, csak hasonlít rá. :)

A driver kérdésben és a miért maradt életben résszel nem értek egyet. Valóban van, amikor belekukkantanak a fejlesztők a linuxos driverbe, de szerintem ez viszonylag ritka. Az meg, hogy a linuxos driverből kell kibogarászni egy eszköz működését szánalmas.

Az életben maradásnak pedig szerintem nem sok köze van a Linuxhoz. Inkább azokhoz a cégekhez, akik használták és fejlesztőket pénzeltek, vagy megengedték nekik, hogy munkaidőben ezen dolgozzanak.

Ami számomra a Linuxból hiányzik, az az átgondoltság. Kedvenc példám a FreeBSD-s camcontrol és maga a CAM. Az egy kitalált dolog, ahol helye van a target és initiator módnak is, egy parancs *bármilyen* CAM rendszerű (SCSI) adapteren megtalálni a változásokat (busz rescan) és ez persze működik ugyanúgy FC-n is (miért is ne, hiszen az is SCSI).

Hol van ilyen a Linuxban? Hol van bármiféle CAM-hoz hasonló keret? Sehol.

De mondhatnék mást is. Hogy is állítasz Linuxban minden olyan ethernet interfészen duplexitást és sebességet, amely támogatja azt?

A Linuxban külön van a user és a kernelspace. Emiatt (is) fejlődnek olyan csökevények, mint akár az mii-tool is. A kernel fejlesztők nem foglalkoznak egy egységes interfész, API kialakításával, vagy ha már csináltak valami kezdeményt, mindig ott a dilemma (na ezen nem sokat gondolkoznak), hogy hát nehéz lesz a változást végigvezetni a userspace toolokon, vagy kompatibilitási varázslatokat kell beletenni.

A furcsa, hogy ennek ellenére nem látszik jele annak, hogy átgondolt API-kat csinálnának, ennek legjobb példája mikor egy minor verziószám változás után máshogy néz ki valami, majd a következő minor verzióban megint máshogy.

Szerintem kapkodnak a srácok és amit csinálnak, az minden, csak nem átgondolt tervezés és fejlesztés eredménye. Pontosabban a tervezést egyáltalán nem is látom. Na még egy mondat: ha jól emlékszem valamelyik nagy linuxos arc (talán Linus? Lehet, hogy tévedek) mondta a hogyan legyél Linux-fejlesztő minihowtojában, hogy ha kitalálsz valamit, ne írj róla 50 oldalas akadémiai székfoglalót, mert senki sem fogja elolvasni és ezzel rögtön elveszted az esélyét annak, hogy a kódod bekerüljön.

Na ehhez képest nézd meg, hány postscript doksi van mondjuk a FreeBSD bizonyos részeiről, amelyeket különféle előadásokon (kevésbé részletes), vagy egyéb módon publikáltak (inkább részletesebb).

Hi,

Bra, azért ne sértegessük egymást azzal, hogy szánalmas dolog, ha az eszközök működését a driverből kell visszanézni. Volt már példa rá. És arra is, hogy FreeBSD-s fejlesztő anyázott arra, hogy láthatóan az ő kódja alapján készítették el a linuxos drivert. És volt viszont is valami, emlékszem, de én az ilyen dolgokat nem tartom annyira veszélyesnek, open source - open source. A kernelek fejlesztőinek egója persze más lapra tartozik :)

A CVS listákat megnézem, de cserébe ajánlom a linux symposium doksikat :) http://www.linuxsymposium.org/ Ha nem is székfoglalók, de azért szerintem elég alapos leírások vnanak benne, ami ismerteti a fejlesztési irányokat (nem csak kernel szinten) Lehet persze kiragadni példákat, de nem gondoltam volna, hogy pont tőled hallom :( Elég nagy merészség kijelenteni, hogy csak úgy kódolgatnak. Van ott is irány. A *BSD-k cégszerűbben működnek.
Az, hogy vannak olyan f**k, akik nem tudnak fejleszteni, nos, szomorú, de nem egyedi. Én pl nem tudok kernel drivert írni, soha nem foglalkoztatott és nem is érdekel a dolog. A Linux kernelben azért nem hiszem, hogy fejetlenség lenne. Más a modell. A stabilizálásnál valóban van amikor hatékonyabb tud lenni az, ha katedrális a modell. De erre írtam, hogy a gyártók ezt csinálják és ezt csinálták már jóval Linus bejelentése előtt is (nevezetesen, hogy a kernel.org-os fejlesztésből kell stabilizálnia a disztribúcióknak). Egyébként ellent mond sok kijelentésnek az, hogy a kernel fejlesztők nagy része RedHat/SUSE (bocs Novell) alkalmazott. Ettől persze a kernel.org-os lehet mindig változó. Bár ezzel nem értek egyet én sem, de ez mellékes. Az API változásért többen is anyáztak, de mond, a FreeBSD különböző verziói között nem változik az API? (ez utóbbi tényleg kérdés, nem tudom, nem foglalkoztatott a kérdés) OK, tudom mi jön: a 2.6-os kernelen belül is változik a dolog. Ez szomorú. De én úgy vagyok vele - az alkalmazkodás után -, hogy FreeBSD megfelelő verziói a RedHat, Ubuntu stb verziói.

CAM: na, ennyire nem mélyedtem bele. Arra emlékszem, hogy a promise GPL-esített drivere CAM-ot használt a SATA cuccaihoz - ami ugye SCSI - de a többi résznél valóban nincs egy egységes CAM alrendszer. De érdemes elolvasni a linux-os scsi listát, hogy mi miért történik. Az már olyan hosszú lenne, hogy a hétvégi túlórámat nem tudnám befejezni. Majd szóban máskor :) vagy küldök linket. Amúgy is kell majd beszélnünk más dologgal kapcsolatban, most írom, hogy írj majd, mert el fogom felejteni, hogy holnap hívjalak, mit intéztem reggel.

Pedig szánalmas dolog. A gyártónak alapvető érdeke kellene, hogy legyen a szarjaihoz kiadni a dokumentációt. AZ alapján kellene drivert írni, nem pedig a másik OS-ben lévő megoldásokból kihalászni, hogy mi, hogy működik.
De ha már a szánalmasnál tartunk, itt az eset, amire szerintem gondolsz:
http://bsd.slashdot.org/article.pl?sid=01/09/24/1432223
és amiért a FreeBSD-s fejlesztő anyázott.
Igen, a linuxos kollegák még a BSD-s kódot is képesek ellopni, úgy, hogy kiveszik a copyright információt és a sajátjukként tüntetik fel.
Ez nem az egóról, hanem a BSD licenszről szólt. Nem mondhatni, hogy sok megkötés van benne, de ez az ürge még azt is megszegte.

Az összevissza fejlesztés a magánvéleményem és saját tapasztalat. Mit tegyek, biztos az én hibám, hogy következetlenségnek tartom, hogy a kernel STABIL (ami sokak véleményével ellentétben -elvileg- nem azért stabil, mert megbízhatóan működik, hanem azért, mert az API nem szabadna, hogy változzon) ágában jelentős változások vannak. A FreeBSD listákon sűrűn olvashatod azt, hogy POLA. Nem véletlenül.

Az API-s kérdést megválaszoltad. :)

ja, az tényleg szánalmas, hogy a balfasz cuccaikhoz nem képesek használható drivert vagy gyártani vagy a speckót kiadni. A legjobb az lenne, ha kiadnk a speckót és egy első implementációt a driverükből.

És igen, megválaszoltam az API-t :) Nekem sem tetszik ám sok minden a kernel fejlesztése körül, de ha belenéznék más projektbe akkor ott is több dolog nem tetszene valszeg. Az API változás azért kétértelmű, de ezt már túlragozom :) Egyrészt boisszantó, hogy közben változik és driverek jó részét kell újraírni esetleg, de örömteli is, hogy mondjuk a fél évvel később talán egy jobb API-t és drivert látok, ha a disztrib frissíti a kernelét és visszahozza ezeket a változásokat is a saját kiadásába. (Pl. RH-nál van/volt erre példa)