A Microsoft bejelentette a Windows Server 2008 és a Windows Vista SP1 megjelenését

Microsoft, Windows

"A mai napon a Microsoft kiadta a Windows Vista első javítócsomagjának (SP1) kiadásra jelölt változatát. [...] A Windows Vista SP 1 bejelentésével egy időben a Windows Server 2008 RTM is elérhetővé válik."

"Azok az ügyfelek, akik aktív Software Assurance vagy Enterprise Agreement keretén belül jogosultak az új kódok használatára, február 27-től tölthetik le a termékeket a Microsoft oldalairól a Microsoft SQL Server 2008 és Visual Studio 2008 bejelentésével közösen tartott Heroes Happen Here elnevezésű rendezvény részeként. Ez a dátum a Los Angeles-i bejelentés időpontja, és ehhez igazították a megjelenést is. A szélesebb vásárlói kör részére a Windows Server 2008 március 1-től lesz elérhető az árlistákon."

Bővebben a Microsoft Magyarország oldalán.

( apal v | 2008. 02. 05., k – 21:05 )

"[...] amiről már egy korábbi karikatúra hírlevélben olvashatott a nagyközönség"
Aranyos. Milyen lehet az a "karikatura hirlevel"? :) Ez olyan mint a dvd-jatekos?

nem, hanem a következők:
WS08 #8: Aki nem lép egyszerre... - csoportmunka

WS08 #7: Erőkagyló - Powershell

WS08 #6: IIS7 - granulálok! - IIS modularitása

WS08 #5: A legegyszerűbb alkalmazásdisztribúció - az új terminal service

WS08 #4: Látszólag - MS virtualizáció

WS08 #3 A hálózat és annak védelme - NAP funkció

WS08 #2: A parancssor meglódul - Server Core - magáért beszél

WS08 #1: Read-Only Domain Controllere - ezt sem érdemes magyarázni

egyszerűbb nyelven megfogalmazva a Windows Server 2008 funkciói. Ha minden igaz minden csütörtökön jelenik meg egy újabb iromány...
B10

"Those who don't understand UNIX are condemned to reinvent it, poorly"

Az agyam eldobom akkor amikor a windows 20 év után bevezet egy olyan dolgot amit több mint 40 éve ismernek és használnak, majd nagy csinadrattával közli hogy ő (mármint az MS) milyen fasza gyerek, hogy ezt kitalálta és beépítette az oprendszerébe.

"Az agyam eldobom akkor amikor a windows 20 év után bevezet egy olyan dolgot amit több mint 40 éve ismernek"

Ez részben így van, részben pedig a PowerShell esetében sokkal többről van szó, hiszen igaz ugyan, hogy kell hozzá a .NET keretrendszer, de nekem úgy tűnik, hogy azon keresztül tényleg meg is lehet vele csinálni mindent a parancssorból.

Az tény, hogy aliasként megvan benne az összes "közismert" UNIX parancs, de ott is vannak plusz szolgáltatásai. Ha például egy parancs kiköp egy listát, akkor azt nem egyszerű szövegként teszi, hanem .NET objektumként, amiből metódusokkal meg kapcsolókkal tudod például kiszedni a mezőket, nem kell hozzá awk.

---
Science for fun...

"Ha például egy parancs kiköp egy listát, akkor azt nem egyszerű szövegként teszi, hanem .NET objektumként, amiből metódusokkal meg kapcsolókkal tudod például kiszedni a mezőket, nem kell hozzá awk."

És akkor ez most miben több mint az awk/GNU alapprogramok? Pont erről beszélek. Most újra feltalálták a kereket, örülhetnek.

Abban, pl. hogy a shell scripted, ami dátumokat vesz ki és dolgoz fel egy "ls -l" kimenetéből awk-val, nem biztos, hogy helyesen fog futni japán, indiai és magyar környezetben is. Az awk csak egy programozható szűrő, karakterfolyamokat fogad és próbál értelmezni, más-más locale beállításoknál más-más sikerrel. Powershell-ben objektumok mozognak a pipe-ban működő programok között, a maguk metódusaival.

init();

Egy text alapú láncban az a forrásból érkező szöveges adatok valamilyen úton-módon szűröd a lánc egyes elemein. Egyes elemek legjobb esetben is csak azt tudják tovább adni, amit kaptak és "megértettek".
Egy objektum alapú láncban az egyes elemek át tudnak adni olyan adatot is, amit ők történetesen nem értettek meg.

például, ha veszünk egy könyvtárlistázást, amiből ki akarjuk válogatni azokat a file-okat, amelyek két adott dátum között készültek, a válogató eszköz csak akkor képes ezt elvégezni, ha elötte kapott egy listát, amiben ezek az adatok szerepelnek. De ha ezt a listát egy olyan forrásból kapom, amelyik nem értelmezi a file-ok esetében a létrehozás dátumát, akkor az nyilván nem képes azt kilistázni sem, tehát a válogató rutin sem kapja meg ezeket az adatokat. Objektum átadás esetén ezzel nincsen probléma, mert a forrás komplett objektumot ad át, amelyek elvégezte a maga munkáját (pl. kiválogatta a "j" betűvel kezdődőket) majd a következő eszköz válogathat dátumok szerint (anélkül akár, hogy tudná hogy a file-oknak vannak neveik)

Ez nem kicsit eröltetett példa, de most jobb nem jut eszembe, mivel nem vagyok power-powershell felhasználó.
:-D

Ave, Saabi.

Egy text alapú láncban az a forrásból érkező szöveges adatok valamilyen úton-módon szűröd a lánc egyes elemein. Egyes elemek legjobb esetben is csak azt tudják tovább adni, amit kaptak és "megértettek".

Nem igaz. A unix szovegfeldolgozo eszkozoket (grep, awk, etc.) ugy terveztek hogy egy sor=egy rekord, a legjobb pelda talan a passwd file. Ezek az eszkozok siman tudnak szurni egy adott mezore, es aztan az egesz objektumot tovabbadni, semmi problema.

A problema ott van, hogy az egy sor=egy rekord modszer mar nem mukodik, egyszeruen azert mert sokkal bonyolultabbak a rekordok amikkel az ember manapsag dolgozik. En orulnek neki hogy ha Linuxra implementalna valaki olyan szuruket, ill. szuresi rendszert ami tavabbviszi a hagyomanyokat valamilyen szinten, pl. nem kell elfelejtenem amit az awk-rol, grep-rol tanultam, de megis hatekonyabban kezeli a bonyolultabb objektumokat. Vagy van mar ilyen? Persze ehhez az is kell hogy az egyes programok ugyanazt az "objektum formatumot" hasznaljak.

Nem igaz. A unix szovegfeldolgozo eszkozoket (grep, awk, etc.) ugy terveztek hogy egy sor=egy rekord, a legjobb pelda talan a passwd file. Ezek az eszkozok siman tudnak szurni egy adott mezore, es aztan az egesz objektumot tovabbadni, semmi problema.

Akkor egy hülye példa, te talán érthetőbb lesz. Az ls parancs képes _színes_ kimenetet adni, nem? Az általad említett szövegfeldolgozók ellenben nem kezelnek színeket. Amennyiben ezeken küldöd át az ls színes kimenetét, a feladatukon túl még a színeket is leveszik, mert azt nem értik. Ha ezután a lánc végére illesztesz egy olyan megjelenítőt, ami ismét ismeri a színeket, az mégis monochrome kimenetet fog produkálni, mivel az elötte lévők ezt az információt elvetették mint számukra feldolgozhatatlant. Ha szeretnéd, hogy a kimeneted mégis színes legyen, a feldolgozási lánc összes elemét át kell írnod, hogy képesek legyenek értelmezni a szövegben a színeket.

A powershell objektum alapú feldolgozásánál nem probléma, ha a lánc egyes elemei nem értik minden tulajdonságát a feldolgozandó objektumnak. Az általuk értett információ alapján elvégzik a maguk munkáját és a következő már foglalkozhat olyan szempontokkal is, amelyek az elötte lévőnek érthetetlenek voltak. Magyarán míg a első csak a kezdőbetű alapján válogat és nem is tud mást értelmezni egy objektumból mint annak a nevét, a második már osztályozhat szín alapján, mégha a szövegértés nem képessége.

Ez sem teljesen jó példa, de talán érthetőbb mint a korábbi próbálkozásom.

Persze ehhez az is kell hogy az egyes programok ugyanazt az "objektum formatumot" hasznaljak.

Feltételezem a powershell esetében a .Net pont ezt biztosítja.

Ave, Saabi.

En tokeletesen ertettem amit irtal, elsore is. Egyszeruen azt gondolom hogy nem igaz. Nincs _ELVI_ kulonbseg a unix szurok es a powershell szurok kozott (nem mintha utobbit annyira ismernem, de nekem ez jott le). Mind a ketto kepes tovabbadni olyan informaciot amit nem ert, HA az inputja a MEGTERVEZETT formatumnak megfelelo. Unix eseteben ez egyszeruen annyit jelent (kb.) hogy 1) szovegfile, 2) egy sor == egy rekord. Ebbe az ls szinei nem fernek bele, ez vilagos (illetve annyira nem, de mindegy).

Nyilvan van olyan pelda is ami meg a .NET objektumaiba nem fer be, annak ellenere hogy vilagos hogy ez a rendszer tobbre kepes. Vegul is 30 ev telt el a ket rendszer tervezese kozott, ez csak termeszetes, nem? Megjegyzem, szerintem egeszen fantasztikus az hogy a UNIX-fele szuroket 30 eve terveztek, es meg ma is viszonylag jol lehet oket hasznalni.

Egyebkent ami kellene kb. UNIX-ra az az hogy pl. az osszes konfig es egyeb file XML, es a szuro meg nem grep hanem xmlgrep. Pl. egeszen kivalo lenne ha a C kod is XML-ben lenne (persze a megfelelo editorokkal, nem kezzel szerkeszve az .xml filet!), es xmlgrep tudna szurni arra hogy egy fuggveny, vagy pl. egy integer valtozo elofordulasait keresed. SZVSZ.

Persze gondolom ezt valamilyen szinten mar meg is csinaltak csak en nem tudok rola...

A powershell (Monad) ereje a te példádon is megmutatkozik, de a napi sysadmin munkájában méginkább. Gyakorlatilag a teljes operációs rendszert, valamint a .net Frameworkban megtalálható milliárdnyi funkcionalitást el lehet érni parancssorból.

Pl. Registry-bejegyzések listázása:

Úgy lehet mászkálni a registryben mint egy FS-ben. De én szertném a PSPath, PSParentPath, PSChildname, PSDrive és a PSProvider értékeket szűrni. Nem kell mást tenni, mint a Get-ItemProperty kimenetét átküldeni egy Select filteren.
> Get-ItemProperty . | select * -exclude PSPath, PSParentPath, PSChildname, PSDrive, PSProvider

Egy kicsit elegánsabb beletenni az egészet egy functionba:
> new-item -path function: -name DirRegistry -value {Get-ItemProperty . | select * -exclude PSPath, PSParentPath, PSChildname, PSDrive, PSProvider}

Így most már kész DirRegistry

Csinálok neki egy aliast:

> Set-Alias dirr DirRegistry

Most már ha a registryben járok a dir a kulcsokat, a dirr-el meg az aktuális kulcs értékeit listázza.

> ...igaz ugyan, hogy kell hozzá a .NET keretrendszer...

Gratulálok. Talán el kéne gondolkodni rajta, hogy mire is való egy shell. Aztán megpróbálni csinálni egy boot-floppyt, amin működik, és esetleg lehet vele rendszereket menteni.

Gondoljunk csak bele: "Az új bash tök király lett, xml objektumokat kezel, igaz, hogy függősége az egész GTK."

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

Kicsit túloztam ezzel, hogy szemléltessem a tény abszurditását. Természetesen lehet CD vagy pendrive is, a lényeg az, hogy egy szimpla shellnek nem volna szabad ekkora és ilyen jellegű dolgoktól függnie.
Egy shelltől szerintem joggal várható el, hogy ha beüt a ménkő, és semmi sem működik, akkor még talán a shell elindul, és megmenthessük, ami menthető.

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

Az agyam eldobom akkor amikor a windows 20 év után bevezet egy olyan dolgot amit több mint 40 éve ismernek és használnak

Itt gondolom, nem kell emlegetnem olyan hatalmas újításokat, mint a filetaggelés a KDE4-ben. Igaz, az amikor bejelentették, még 10 éve se volt benne a másik asztalkörnyezetben. :-)
It doesn't matter if you like my song as long as you can hear me sing

Szerintem attól függ, hogy jelentik be. Beállíthatják úgy is, mint valami hatalmas innováció, ami még soha nem létezett, meg úgy is, mint egy az adott szoftverből még hiányzó újdonságot. Meg aztán ha valaki még csak windowst használt, annak a powershell maga lesz a csoda. (Persze csak ha tudja használni...) Míg egy unix (like) rendszereken felnőtt embernek ez az alap.

Nezd, konzolosan eddig is lehetett egesz jol menedzselni a windows rendszereket, netsh, reg, ldifde, stb. eddig is voltak, a powershell tehat ilyen szempontbol nem ujdonsag. Olyan szempontbol viszont az, hogy sokkal konnyebbe teszi bizonyos dolgok scripteleset, illetoleg viszonylag egyszeru bovito komponenst belerakni. Valamint a teljes .NET konyvtar hasznalhato a shellbol, amiben pl. nincs ekvivalens *nix-ba (nincs olyan shell, amibol pl. a Qt teljes konyvtarat tudnam hasznalni).

Ezzel nem is vitatkozom. Soha nem állítottam, hogy a PowerShell nem tartalmaz újdonságokat a unix-féle shellekhez képest. De eddig windowson csak dos-szerű parancssor volt, ami azért messze nem éri el a powershell, de még egy unix-szerű shell tudását sem. És ez nagy újdonság. De ha ezt a Microsoft úgy állítja be, mint valami új találmányt, akkor az csúsztatás. Ha azt mondja, hogy más rendszerekben megtalálható shellek modernizált, javított változata, az korrekt.

De eddig windowson csak dos-szerű parancssor volt, ami azért messze nem éri el a powershell, de még egy unix-szerű shell tudását sem.

Volt Windows Scripting Host is jscript és vbscript nyelveken scriptelésre. Mondjuk mulatságos, hogy pl. XP-ben (is) alapból benne van, de a dokumentációját már külön kellett letölteni a Microsofttól.

init();

( tombenko v | 2008. 02. 05., k – 21:24 )

Egy tanítványom pont tegnap mondta, hogy a Vistában már csak apróbb hibák vanna, amit majd egyszerű frissítéssel lehet javítani. :) Holnap első órában pont náluk helyettesítek informatikát. :)--
Fight / For The Freedom / Fighting With Steel

( mmark | 2008. 02. 05., k – 21:44 )

Hát nem is tudom, nemhiszem hogy az SP megoldja az oriasi gepigenyt, de majd kiderul. Bar ahogy az Apple 2006-s WWDC-n mondták, még mindig registryt használ, és a winfos nagy hibája.

Hát regisztry ügyben franctudja.

Előrebocsátom, hogy vista alatt nem tudom, ezek RÉGI XP-s kliens/w2ksrv/w2k3srv alapú tapasztalatok, tehát finoman szólva sem vagyok naprakész, én már csak felejtek :D...

Sz'tem előnye hogy egyes funkciók felhasználószintű jogosultságainak korlátozási lehetősége, biztonsági beállítása egyszerűbb /itt arra gondolok hogy linux alatt általában van egy db. config fájl, azon belül már nehezebb jogot állítani 1-1 funkcióra, bár vannak disztrók melyek szétszedik a config fájlokat több részre, ill. vannak cuccok, melyek "belső ACL-t" támogatnak könnyítendő a biztonsági testreszabást (tudok ám kifejezéseket gyártani :D).../, házirendszerkeztő támogatja. távolról is menedzselhető egyszerűen grafikusan is. Illetve ha egy konkrét globális beállítást keresünk, akkor egyszerűbb megtalálni, mint pl. az egész etc könyvtárat áttúrni.

Hátránya, hogy borzasztóan megnöveli az NTFS alatt amúgy is eléggé gázos fájlrendszertöredezettséget, lassítja a rendszert, és gond esetén helyileg macerás az operációs rendszeren kívülről belenyúlni (vmilyen offline registry editor kell, de ez szép halál :-) ), az egész registry-rendszer kb. összességében átláthatatlan (egy config fájlról egyszerűen ki tudod deríteni kihez tartozik, de egy registry kulcsról már lehet hogy csak baromi nehezen), és külső rendszerszintű alkalmazások hibái miatt (driverek, tűzfalak, stb.), a windows kijelentkezéskor nem mindig tudja a "felh. regisztrijét" (jó ronda szó :D), kitölteni a memóirából.

És általában ezen alkalmazások eltávolítása után rengeteg szemét marad vissza. Az átláthatatlanság miatt potenciálisan alkalmas mindenfélre károkozók adatainak kvázi "észrevehetetlen" tárolására. Míg linux alatt egyszerűen törlöd a config fájlokat és kész.Könnyebb kiszúrni egy config fájlban a szintaktikai hibákat, míg a registryben egy HKCR/{******-******-*****-*****}alkulcsban már kevésbé.

Valamint bizonyos esetekben teljesen rugalmatlan, és feleslegesen túlbonyolít.Pl. ha DCOM hozzáférési probléma támad egy kulcsnál, akkor az eseménynaplóban levő "hivatkozási kulcsot" előszőr a regisztryben kell keresni.Akkor kapsz egy másik "kulcsot", ami jó esetben van a dcomconfigban, rossz esetben nincs. és utóbbi esetre sosem találtam megoldást, de az érintett alkalmazás sosem működött rendesen, és az egész DCOM probléma általában különféle hotfixek telepítése után keletkezett. :-)

-------

Nem a zsömle kicsi, a pofátok nagy...

Nem egészen erre gondoltam szerintem. hanem pl. arra, hogy amikor linux alól egy ipv4 paramétert, vagy egy kernelmodulbeállítást a /proc-ban vagy a /sys-ben állítasz, addig win alatt ez (is) a regisryben van ált. a HKLM/System alatt.Utóbbi jelentősen rugalmatlan esetben időnként újraindítás is kell...

Pl. nehezen tudom elképzelni pl. HKLM/System féle megoldással az rtc-wakealarm működtetését, vagyis hogy megadott időben felélessze a gépet akár ACPI S5 kikapcsolt állapotból is, anélkül hogy újraindítanád a gépet, és a BIOS ból beállítanád az ALARM timet.

de mondom vista-hoz nem volt szerencsém, tehát lehet nyitott kapukat döngetek.

De egyébként szép a cucc azt meg kell hagyni. vajon a firefox pref.js féle megoldását támogatja ? :))

------------

Nem a zsömle kicsi, a pofátok nagy...

> amikor linux alól egy ipv4 paramétert, vagy egy kernelmodulbeállítást a /proc-ban vagy a /sys-ben állítasz

Nekem az a véleményem, hogy ami úgy viselkedik, mint egy fájlrendszer, az legyen fájlrendszer(ként implementálva).

> de mondom vista-hoz nem volt szerencsém,

Nálam is kimaradt, úgy mint a Windows Millenium Edition vagy mi. :-)))

> De egyébként szép a cucc azt meg kell hagyni.

Pár évvel ezelőtt vettem észre, akkor még "linux registry"-nek hívták. Azóta se néztem. Gondoltam ha jó, akkor majd sorban átállnak a programok erre. De nem álltak át.

( mmark | 2008. 02. 05., k – 22:00 )

Windows Vista Online kipróbálható. Természetesen nem működik :D