- A hozzászóláshoz be kell jelentkezni
- 3251 megtekintés
Hozzászólások
Nem figyeltem anno ezt az SCO-s dolgot. Van valami kézzelfogható? Kódrészletek, algoritmusok? Vagy ez is ugyanolyan mint az MS-féle "a Linux kernel csillió szabadalmat sért, de nem mondjuk meg, hogy mik azok!"?
- A hozzászóláshoz be kell jelentkezni
innen megtudsz sokmindent.
- A hozzászóláshoz be kell jelentkezni
Köszi.
- A hozzászóláshoz be kell jelentkezni
"Vagy ez is" forog fenn. És egyetlen betűt sem tudtak igazolni a vádaskodásaikból.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Kar, hogy csak ennyi a buntetes, meg jo lenne mashol is. Kicsit undorito volt a modszer, hogy a SCO csodkozelbe jutasanal azt talaltak ki, hogy majd zsarolassal/hazugsagokkal fogjak fenntartani az uzletet, szereznek penzt. Remelem, ha egyszer bebizonyosodik, hogy nem volt igazuk, akkor vissza kell fizetniuk minden penzt, amit vedelmi penzkent beszedtek, plusz az okozott karert (mondjuk ezt nehez szamszerusiteni) is jol lehuzzak oket, a per koltsegek kifezeteserol nem is beszelve. Bar imho mindig lesz valaki, aki ugy gondolja, hogy ad nekik penzt, mert valami penzt ki lehet sajtolni igy mas cegekbol, szoval "befekteto" penzember mindig akad, kerdes meddig lehet ez huzni, es mikor lesz vegleg lezarva mindenhol az ugy. Eleve az egesz nevetseges, annyira allitottak, hogy bizonyitek van rengeteg, de ha jol tudom azota se tudtak (tobb ev alatt) felhozni semm erdemlegeset, ez a jogrendszer csodje, hogy megis el tudtak huzni ilyen sokaig (bar USA-ban olyasmikert is lehet perelni, es penzt szerezni is, ami tobb mint nevetseges).
- A hozzászóláshoz be kell jelentkezni
magyarországon ilyen módszerekkel szokás hatalomra kerülni, majd ott maradni. mindezt persze lehetővé teszi a magyar jogrendszer. én nem szidnám a usa jogrendszerét, bárcsak olyan problémák lennének magyarországon mint amerikában.
- A hozzászóláshoz be kell jelentkezni
Inkabb ne, van ott sok mas problema is.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
lehet pluszegyezni, de nézd meg mi lett amerikában Nixonnal, miután hazugságon kapták és mi lett a hazugságaival lebukó magyar miniszterelnökkel.
vagy, hogy személyesebb oldalról nézzük. mekkora kosárral lépsz ki amerikában a walmartból ha USD100al léptél be, és mekkorával ha EUR100nak megfelelő forinttal a tescoból. nemcsak a kosár kisebb magyarországon, de a minőség is gyatrább. ráadásul USD100 < EUR100nál.
- A hozzászóláshoz be kell jelentkezni
SCO Unixware 7.1 -et adminisztrálok és túl sok jót nem tudok mondani róla... (oké, hogy stabil [aránylag], de nagyon hiányzik pár eszköz, ami a Linux disztrókban megvan... arról nem is beszélve, hogy nincs support a rendszerre és pl. IBM LTO3 -as eszközt nem támogat, LTO2 -est meg már nem lehet kapni... szóval ha a mentési egység megfő, akkor oprendszert is kell cserélni)
Szerintem sohasem tudták bizonyítani, hogy akár egyetlen sor Linux kód is származik a (SCO) Unix -ból... annyit tudtak bizonyítani emlékeim szerint, hogy a forráskódok összehasonlításakor találtak kommenteket a kódban, amelyek szó szerint megegyeztek, viszont a kód más volt...
- A hozzászóláshoz be kell jelentkezni
Az nem járható út, hogy fájlba teszed a mentést, és utána másik gépen backupolsz az LTO-ra?
- A hozzászóláshoz be kell jelentkezni
Sajna nem, több okból:
1. a teljes fájlrendszert kell menteni minden nap és ehhez kevés a tárhely (kb. 70 GB adatot kell menteni naponta, kb. 10 GB szabad hely van)
2. lassú hálózat (kb. 15 éves átlagéletkorú hálózati eszközök és kábelek, a sebesség kb. 1-2 Mbit/sec [max])
3. policy (így van megírva a szerződés, így kell végrehajtani...)
Mivel az egyik SCO Unixware -es szerver alól döglődik kifelé az LTO2 -es drive, ezért kénytelenek vagyunk beszerezni egy LTO3 -ast és azt betenni egy másik szerverünk alá (Win2k3), ami kezelni tudja... annak a használt LTO2 -esét meg berakjuk a döglődő helyébe... :)
De hosszabb távon már tervbe van véve Linux -ra (SUSE Enterprise) való migrálása a SCO Unixware -es szervereknek, csak az nem túl egyszerű jelen esetben...
- A hozzászóláshoz be kell jelentkezni
Ez milyen server? Megeri meg egyaltalan uzemeltetni? Mondjuk igaz, hogy server, de egy 15 eves gepet ma mar egy (vagy a megbizhatosag miatt mondjuk 2-3) geppel valoszinuleg ki lehet valtani, nem?
----
'Give us seeds so that we may live and not die' (Gen 47:19)
Wow! Quoting the bible worked! -Eremal, piratebay
honlapkészítés
- A hozzászóláshoz be kell jelentkezni
Gondolom ez nem gazdasagi problema, hanem hogy ez egy fontos szerver, mely nem eshet ki akarmikor, meg kell tervezni, hogy mikor lesz downtime szamara es meddig.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Így igaz. Vállalatirányítási rendszer megy rajta (MAX a neve)... azért is kényes, mert a vállalatirányítási rendszerhez rengeteg Unix specifikus szkriptet írtak (felhasználók felvételétől kezdve minden bash szkripttel van megoldva), amelyek nagy része Linux -on nem fut...
A gép maga nem túl régi, elég gyors is, a hálózati eszközök (switchek, routerek) régiek és lassúak.
A leváltása úgy van betervezve, hogy valamikor majd virtuális szerverre lesz migrálva. De az említett nagymértékű integráció miatt nem mertek még a migrációba belekezdeni. Ez nem rajtam múlik, meg nem is igazából szakmai kérdés... csak az ügyfél döntésétől függ. Az ő döntése meg attól, hogy mi milyen árat mondunk. Az első ajánlatunknál ők egy nagyságrenddel kisebb árat reméltek :D
- A hozzászóláshoz be kell jelentkezni
A SCO-t belerámolni valami virtualizált környezetbe? Izé... Sok szerencsét hozzá, tippelem, hogy nem lesz egyszerű menet... Vagy ha Linuxra tolod át magát az alkalmazást, az sem...
- A hozzászóláshoz be kell jelentkezni
Az elképzelés az, hogy megveszik a vállalatirányítási rendszer új verzióját, amit Windows -ra fejlesztettek... így virtuális környezetben futna egy Win2k3 és azon a MAX. Viszont jelenleg Informix SQL -t használ a MAX, a Windows -os verziója meg MSSQL -t... van Linux -os verziója is (az is újabb), az meg MySQL -t használ.
Az ügyfél nem tudja elképzelni, hogyan lehet átmigrálni az elmúlt kb. 10-12 év adatait Informix SQL -ből MS ill. My SQL -be... de végülis az adatok migrálása már az ügyfél dolga. :)
- A hozzászóláshoz be kell jelentkezni
Ha van migrációs eszköz, akkor azzal el lehet kezdeni kísérletezni, azonban sokszor jobban járnak a párhuzamos működéssel(!) azaz a historikus adatok a régi rendszerben, a törzsadatok migrálva az újba, és adott dátumtól kezdve már csak az új rendszerben történik mindenféle művelet, a régi átmegy csak olvashatóba. Sz...r dolog, tudom, de ez még a kevésbé fájdalmas megoldás. (Üzemeltettem én historikus adatok elérhetősége miatt életben tartott SAP-t, bár az gyakorlatban csak egy HR modult vitt... Két szerver, közös, duplikált storage, hetente legfeljebb egy-két keresés -- olyan, amit egyébként az irattárba lebattyogva, papír alapon is meg lehetett volna találni...)
- A hozzászóláshoz be kell jelentkezni
jellemző SCO féle megoldás, a userland fele shell script-ben van megírva.
- A hozzászóláshoz be kell jelentkezni
Jellemző Linuxos megoldás, hogy a scriptek/tool-ok jelentős része Linux-only megoldásokkal van telehányva. (Mert az elkövetőik még véletlenül sem láttak közelről mást...)
- A hozzászóláshoz be kell jelentkezni
Vagy nem akarnak mást.
- A hozzászóláshoz be kell jelentkezni
Tapasztalat az, hogy nem is tudnak mást... Tisztelet a kivételnek.
- A hozzászóláshoz be kell jelentkezni
ki beszél itt linux-ról?
- A hozzászóláshoz be kell jelentkezni
Te fröccsentettél oda az SCO-s megoldásokkal kapcsolatban, hogy ott SCO-only megoldásokat használnak. Igen, mert megtehették, mint gyártó, pláne, hogy épkézláb pécés UNIX nem nagyon volt anno... Én meg csak megemlítettem, hogy a legtöbb linuxhuszárnál is egyértelmű, hogy nem lát tovább a pingvinjének a csőrénél...
- A hozzászóláshoz be kell jelentkezni
hát igen, a hasonlat jogos, biztos nem figyeltem. btw a cucc körül a közösségtől biztos lehet sokat tanulni, az evolúció során a vacak megoldások jó eséllyel kikopnak. Ettől függetlenül én még azt gondolom, hogy ha szarul meg lehet csinálni valamit, és szarul csinálják meg, akkor az szar. Asszem ez netto mindenre igaz.
- A hozzászóláshoz be kell jelentkezni
A sz...r mindenütt az, és sajnos minden rendszerben sok van belőle -- az okok persze szerteágazóak: van, ahol szándékos az inkompatibilitás, van, ahol meg rövidlátó magatartás okozza. A gond ott kezdődik, hogy bár sok dolgot meg lehet csinálni sz...ul is, meg picivel több odafigyeléssel jól/jobban is, de a legtöbb esetben az előbbi győz, lustaságból, nemtörődömségből, vagy egyszerűen csak tudatlanságból... Jó példa erre az, amikor egy webes, php-s cuccot megírnak a MySQL igényei/tudása (tudás... no mindegy.) alapján, aztán csinálnak hozzá pl. Oracle vagy más izmosabb DB-re is adatbázis-backendet, ami jó esetben csak a táblák tárolását jelenti, semmiféle adatbázisra optimálást nem.
- A hozzászóláshoz be kell jelentkezni
ja, aránylag stabil, szó se róla, hónapokig elmegy, ha hagyjak, de tényleg rémálom. Egy relatív új lib-et képtelenség leforgatni rá, ezzel be is csuktad magad előtt az ajtót, abból kell főzni, ami van. Ha nem tudod upgrade-elni (pl. egy 3rd-party sw miatt, amit specifikus rilizhez kötnek), akkor jön a lassulás (időben). Mondjuk a skunkware jó, hogy van, de az is kb. 5 évvel ezelőtti tech szintet tükröz (itt nem feltétlen a bash-ra gondolok, jó az a ksh úgy, ahogy van). Doksit túrni kell hozzá, a gyári az lufi, ha belefutsz egy valamilyen problémába, abból vagy úgy jössz ki, hogy reboot és megjavul, vagy hátha találsz valamit neten, amiből el lehet indulni.
Volt szerencsénk (majd jön kolléga és megerősít :) még a 7.1 előtt is találkozni vele (2.1.1, juhhé), na az volt a kaland. Mondjuk az is elketyegett hónapokig, ha nem baszkurálták. Röviden: NSFW.
- A hozzászóláshoz be kell jelentkezni
Mondjuk pár hónapja vagyok itt, azóta aug 20 -án volt először leállítva a szerver... aztán 21 -én az újraindítás után csak néztem körbe magamon, hogy miért nem futnak a cron job -ok. A drágaszágom nem indította el a cron -t. :)
(engem, mint debian 3.1, majd ubuntu server 7.10 -en nevelkedett embert ez meglepett... ott alapból indult a cron)
- A hozzászóláshoz be kell jelentkezni
Kérdem én, a rendszergazda mi a francért nem állítja be, hogy fusson az aminek kell, és ne fusson az, aminek nem kell? (*) Nem (volt) rossz az az SCO, bár nem mindegy, hogy az újabb Novell-féle, vagy a régebbi ODT. A maga korában hasznos jószág volt, most is van rendszer, ami nem jobb, csak mostanra több gyerek azon nődögél föl.
(*) Nekem amúgy egy szerveren ne fusson alapból az sshd-n kívül más. Majd én beállítom, ha kell.
- A hozzászóláshoz be kell jelentkezni
Mondom, én most láttam először ilyet, hogy a cron nem indult el "alapból". Furcsa volt, de mostmár ezt is tudom. :)
- A hozzászóláshoz be kell jelentkezni