🚀 go-pugleaf

W dniu 2011-09-15 00:03, Grzegorz Staniak pisze:
> ... czyli opowiadanie bajek o przewadze GUI nad CLI na
> serwerach:
>
> http://www.itworld.com/virtualization/203199/windows-server-8-highlights-upcoming-server-os
>
> [...]
> "In Windows Server 8, literally everything seems to be manageable
> using PowerShell scripting. Most features shown to us at the
> reviewers workshop were built to be managed by PowerShell first and
> UI second."
>
> Chłopaki myślą, starają się, jeszcze trochę i wymyślą uniksa.


Przecież w sensie filozofii to Windows jest systemem uniksowatym. Nie 
jest Uniksem, bo nie implementuje natywnie POSIX-a, ale ZTCW to POSIX w 
Linuksie też trochę kuleje.

Przez filozofię mam na myśli to, że zarówno Windows jak i typowe Uniksy 
trzymają informacje w plikach, które są przez użytkownika obrabiane 
aplikacjami. Bo takie szczegóły jak to, że Uniksach jest /, a Windowsach 
dysk:\ to są mało istotne pierdoły.

begin o nicku Grzegorz Staniak napisał(a) na pl.comp.os.advocacy następujące
bzdety:

> ... czyli opowiadanie bajek o przewadze GUI nad CLI na
> serwerach:
No zaraz, to ja się latami zmuszałem do kombinowania z jakimiś okienkowymi
narzędziami, żeby koledzy od Windowsów nie uważali mnie za prymitywa, a
teraz to wszystko nieważne? Protestuję. ;)
 
> Chłopaki myślą, starają się, jeszcze trochę i wymyślą uniksa.
No na razie, według screenów, to na mój gust wymyślili coś w rodzaju MeeGo.

-- 
Maciek
I spend my time wasting yours.

 Dzieki, Tomasz, za post o tresci: 
> Przez filozofię mam na myśli to, że zarówno Windows jak i typowe Uniksy 
> trzymają informacje w plikach, które są przez użytkownika obrabiane 
> aplikacjami. Bo takie szczegóły jak to, że Uniksach jest /, a Windowsach 
> dysk:\ to są mało istotne pierdoły.

  Gdzie na Windows jest plik odpowiadające /dev/sda1?
Jakie API pozwala na obsługę timerów i sygnałów przez deskryptor pliku?

-- 
Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
xmpp: zdzichubg@chrome.pl     Your routes will be aggreggated. -- Alex Yuriev

On 14.09.2011, Tomasz Wójtowicz <SPAMMERS_GO_AWAY@SPAMMERS.COM> wroted:

>> "In Windows Server 8, literally everything seems to be manageable
>> using PowerShell scripting. Most features shown to us at the
>> reviewers workshop were built to be managed by PowerShell first and
>> UI second."
>>
>> Chłopaki myślą, starają się, jeszcze trochę i wymyślą uniksa.
>
>
> Przecież w sensie filozofii to Windows jest systemem uniksowatym. Nie 
> jest Uniksem, bo nie implementuje natywnie POSIX-a, ale ZTCW to POSIX w 
> Linuksie też trochę kuleje.
>
> Przez filozofię mam na myśli to, że zarówno Windows jak i typowe Uniksy 
> trzymają informacje w plikach, które są przez użytkownika obrabiane 
> aplikacjami.

Mhm. A ludzie to słonie, bo też mają cztery kończyny.

GS
-- 
Grzegorz Staniak   <gstaniak _at_ gmail [dot] com>

On 2011-09-14, Tomasz Wójtowicz <SPAMMERS_GO_AWAY@SPAMMERS.COM> wrote:
> W dniu 2011-09-15 00:03, Grzegorz Staniak pisze:
[...]
>> Chłopaki myślą, starają się, jeszcze trochę i wymyślą uniksa.
>
>
> Przecież w sensie filozofii to Windows jest systemem uniksowatym. Nie 
> jest Uniksem, bo nie implementuje natywnie POSIX-a, ale ZTCW to POSIX w 
> Linuksie też trochę kuleje.
>
> Przez filozofię mam na myśli to, że zarówno Windows jak i typowe Uniksy 
> trzymają informacje w plikach, które są przez użytkownika obrabiane 
> aplikacjami. Bo takie szczegóły jak to, że Uniksach jest /, a Windowsach 
> dysk:\ to są mało istotne pierdoły.

Trochę przywaliłeś... ;-)

Informację w plikach trzymają praktycznie wszystkie systemy.  W uniksach
"everything was a file", czyli np. cały sprzęt też z punktu widzenia
systemu był zbiorem plików a wynik działania jakiegoś programu był
"plikiem" nawet bez konieczności zapisywania go na dysku.

Z tego drugiego wynika kolejna cecha charakterystyczna filozofii
uniksów, czyli że są one agregatem stosunkowo wąsko wyspecjalizowanych,
małych programów, bo dzięki pipe'om można było realizować przy ich
pomocy bardziej złożone operacje.  

Trzecia istotna cecha uniksów to "grzebalność".  Uniksy tradycyjnie
zawsze przychodziły z kompilatorem, a dawniej również z kodem źródłowym,
żeby użytkownik mógł samodzielnie naprawić co bardziej irytujące błędy.

Windows miało dokładnie odwrotne podejście, choć obecnie trochę się
zuniksowało, a uniksy zwindowsiały na starość.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

W dniu 2011-09-15 09:45, Tomasz Torcz pisze:
>   Dzieki, Tomasz, za post o tresci:
>> Przez filozofię mam na myśli to, że zarówno Windows jak i typowe Uniksy
>> trzymają informacje w plikach, które są przez użytkownika obrabiane
>> aplikacjami. Bo takie szczegóły jak to, że Uniksach jest /, a Windowsach
>> dysk:\ to są mało istotne pierdoły.
>
>    Gdzie na Windows jest plik odpowiadające /dev/sda1?
> Jakie API pozwala na obsługę timerów i sygnałów przez deskryptor pliku?
>

No i kompletnie mnie nie zrozumiałeś. Właśnie o tym piszę, że różnice w 
API to drugorzędna sprawa. Pewnie że te różnice utrudniają przenoszenie 
oprogramowania, a programista może odczuć, że na jednym systemie pisze 
się łatwiej niż na drugim, ale mimo wszystko na obydwu systemach DA SIĘ 
to samo.

 Dzieki, Tomasz, za post o tresci: 
> W dniu 2011-09-15 09:45, Tomasz Torcz pisze:
>>   Dzieki, Tomasz, za post o tresci:
>>> Przez filozofię mam na myśli to, że zarówno Windows jak i typowe Uniksy
>>> trzymają informacje w plikach, które są przez użytkownika obrabiane
>>> aplikacjami. Bo takie szczegóły jak to, że Uniksach jest /, a Windowsach
>>> dysk:\ to są mało istotne pierdoły.
>>
>>    Gdzie na Windows jest plik odpowiadające /dev/sda1?
>> Jakie API pozwala na obsługę timerów i sygnałów przez deskryptor pliku?
>>
>
> No i kompletnie mnie nie zrozumiałeś. Właśnie o tym piszę, że różnice w 
> API to drugorzędna sprawa. Pewnie że te różnice utrudniają przenoszenie 
> oprogramowania, a programista może odczuć, że na jednym systemie pisze 
> się łatwiej niż na drugim, ale mimo wszystko na obydwu systemach DA SIĘ 
> to samo.

 Pisałeś o filozofii.  "Plikowość" filozofii Uniksa objawia się właśnie w API.
Gdzie jest jakieś podobieństwo w WinRT?

-- 
Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
xmpp: zdzichubg@chrome.pl     Your routes will be aggreggated. -- Alex Yuriev

W dniu 2011-09-15 10:02, Andrzej Rosa pisze:
> Trochę przywaliłeś... ;-)
>
> Informację w plikach trzymają praktycznie wszystkie systemy.  W uniksach
> "everything was a file", czyli np. cały sprzęt też z punktu widzenia
> systemu był zbiorem plików a wynik działania jakiegoś programu był
> "plikiem" nawet bez konieczności zapisywania go na dysku.
>
> Z tego drugiego wynika kolejna cecha charakterystyczna filozofii
> uniksów, czyli że są one agregatem stosunkowo wąsko wyspecjalizowanych,
> małych programów, bo dzięki pipe'om można było realizować przy ich
> pomocy bardziej złożone operacje.

To co miałem na myśli przez pliki, to jest to, że czy w Windowsie czy 
Uniksie pliki to są tyko strumienie znaków. Z Pipe'ami jest to samo - 
transmisja strumieni znaków, a co z nimi zrobić, to już problem 
programu. Tak naprawdę to ogranicza elastyczność tej ideologii 
Uniksowej, bo zmusza użytkownika do myślenia i to wcale nie łatwego, czy 
dany program przyjmie taki strumień znaków, czy nie.

Alteratywna byłaby filozofia obiektów. Np. program zwraca wynik w formie 
tabelki, która jest formatem systemowym. Kolejny program bierze tą 
tabelkę i coś z nią robi, a w końcu tabelka ląduje przed oczami 
użytkownika w arkuszu kalkulacyjnym. Gdyby przez pomyłkę użytkownik 
wysłał tabelkę nie do tego programu, gdzie trzeba, program by 
odpowiedział: Sorry, ale ja tabelek nie robię. W uniksie jest taki 
format tabelek, mianowicie: CSV... no comments.

A teraz zauważ, że tabelką też mógłby być obraz - w końcu piksele są 
poukładane w wiersze i kolumny. Więc program który normalnie służy do 
obróbki danych statystycznych, za chwilę mógłby być użyty do policzenia 
średniej luminancji pikseli w jakimś obszarze. To się nazywa 
elastyczność oprogramowania.

Podsumowując, chodzi mi o to, że pomiędzy warstwą plików fizycznych 
(czyli strumieni znaków) a warstwą aplikacji brakuje jeszcze takiej 
systemowej warstwy prezentacji, gdzie wszystkie dane byłyby widoczne 
jako określone obiekty z możliwością łatwej reinterpretacji na inne 
obiekty, jak np. obiekt graficzny staje się arkuszem kalkulacyjnym, albo 
odwrotnie itd.

Wówczas warstwa, którą by widział użytkownik to byłaby warstwa tych 
obiektów i nie musiałby w ogóle się zastanawiać, jak to jest trzymane na 
niskim poziomie, tj. w plikach, BLOB-ach czy innych postaciach.

W dniu 2011-09-15 11:52, Tomasz Torcz pisze:
>   Dzieki, Tomasz, za post o tresci:
>> W dniu 2011-09-15 09:45, Tomasz Torcz pisze:
>>>    Dzieki, Tomasz, za post o tresci:
>>>> Przez filozofię mam na myśli to, że zarówno Windows jak i typowe Uniksy
>>>> trzymają informacje w plikach, które są przez użytkownika obrabiane
>>>> aplikacjami. Bo takie szczegóły jak to, że Uniksach jest /, a Windowsach
>>>> dysk:\ to są mało istotne pierdoły.
>>>
>>>     Gdzie na Windows jest plik odpowiadające /dev/sda1?
>>> Jakie API pozwala na obsługę timerów i sygnałów przez deskryptor pliku?
>>>
>>
>> No i kompletnie mnie nie zrozumiałeś. Właśnie o tym piszę, że różnice w
>> API to drugorzędna sprawa. Pewnie że te różnice utrudniają przenoszenie
>> oprogramowania, a programista może odczuć, że na jednym systemie pisze
>> się łatwiej niż na drugim, ale mimo wszystko na obydwu systemach DA SIĘ
>> to samo.
>
>   Pisałeś o filozofii.  "Plikowość" filozofii Uniksa objawia się właśnie w API.
> Gdzie jest jakieś podobieństwo w WinRT?
>
Czytaj mój post poniżej, chodzi mi o zastąpienie filozofii strumieni 
znaków filozofią obiektów.

On 2011-09-15, Tomasz Wójtowicz <SPAMMERS_GO_AWAY@SPAMMERS.COM> wrote:
> W dniu 2011-09-15 10:02, Andrzej Rosa pisze:
>> Trochę przywaliłeś... ;-)
>>
>> Informację w plikach trzymają praktycznie wszystkie systemy.  W uniksach
>> "everything was a file", czyli np. cały sprzęt też z punktu widzenia
>> systemu był zbiorem plików a wynik działania jakiegoś programu był
>> "plikiem" nawet bez konieczności zapisywania go na dysku.
>>
>> Z tego drugiego wynika kolejna cecha charakterystyczna filozofii
>> uniksów, czyli że są one agregatem stosunkowo wąsko wyspecjalizowanych,
>> małych programów, bo dzięki pipe'om można było realizować przy ich
>> pomocy bardziej złożone operacje.
>
> To co miałem na myśli przez pliki, to jest to, że czy w Windowsie czy 
> Uniksie pliki to są tyko strumienie znaków. 

W uniksach tak, bo to wynika z ich filozofii.  Unix zakłada, że output
dowolnego programu może być inputem kolejnego, stąd nacisk na proste
pliki tekstowe.  W windows tak nie było.  Windows tradycyjnie
preferowało kryptyczne pliki binarne, często o zamkniętych formatach.
Windows preferowało kombajny zamiast agregatu prostych programików.
Windows *nie* zakładało, że output dowolnego programu ma stanowić input
dowolnego programu.

http://www.faqs.org/docs/artu/ch01s06.html

(ii) Expect the output of every program to become the input to another, as yet
unknown, program. Don't clutter output with extraneous information. Avoid
stringently columnar or binary input formats. Don't insist on interactive
input.

Dokładnie odwrotnie do Windows.  Programy windowsowe są pisane do
współpracy z ludźmi, nie z innymi programami.  Bardzo odmienna
filozofia. 

> Z Pipe'ami jest to samo - 
> transmisja strumieni znaków, a co z nimi zrobić, to już problem 
> programu. Tak naprawdę to ogranicza elastyczność tej ideologii 
> Uniksowej, bo zmusza użytkownika do myślenia i to wcale nie łatwego, czy 
> dany program przyjmie taki strumień znaków, czy nie.

"Unix is simple. It just takes a genius to understand its simplicity." –
Dennis Ritchie

[...]
> Podsumowując, chodzi mi o to, że pomiędzy warstwą plików fizycznych 
> (czyli strumieni znaków) a warstwą aplikacji brakuje jeszcze takiej 
> systemowej warstwy prezentacji, gdzie wszystkie dane byłyby widoczne 
> jako określone obiekty z możliwością łatwej reinterpretacji na inne 
> obiekty, jak np. obiekt graficzny staje się arkuszem kalkulacyjnym, albo 
> odwrotnie itd.

Wygląda mi na coś podobnego do OLE.

> Wówczas warstwa, którą by widział użytkownik to byłaby warstwa tych 
> obiektów i nie musiałby w ogóle się zastanawiać, jak to jest trzymane na 
> niskim poziomie, tj. w plikach, BLOB-ach czy innych postaciach.

I tak jest, w przypadku (udanego) Drag and Drop.  (Zresztą, tutaj też
widać odmienne podejścia.  X stosuje prosty protokół, który pozwala na
komunikację pomiędzy programami.  Po prostu pośredniczy.  W Windows jest
proprietarna specyfikacja, do której wszystkie klienty muszą się
dostosować, albo nie działa.)

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

Tomasz Wójtowicz wrote:

> A teraz zauważ, że tabelką też mógłby być obraz - w końcu piksele są
> poukładane w wiersze i kolumny. Więc program który normalnie służy do
> obróbki danych statystycznych, za chwilę mógłby być użyty do policzenia
> średniej luminancji pikseli w jakimś obszarze. To się nazywa
> elastyczność oprogramowania.

To jest elastyczność oprogramowania nie tam, gdzie jest potrzebna.

> Podsumowując, chodzi mi o to, że pomiędzy warstwą plików fizycznych
> (czyli strumieni znaków) a warstwą aplikacji brakuje jeszcze takiej
> systemowej warstwy prezentacji, gdzie wszystkie dane byłyby widoczne
> jako określone obiekty z możliwością łatwej reinterpretacji na inne
> obiekty, jak np. obiekt graficzny staje się arkuszem kalkulacyjnym, albo
> odwrotnie itd.

Trudno mi sobie wyobrazić zrobienie czegokolwiek użytecznego z obrazkiem w 
arkuszu kalkulacyjnym. Korzyści z przerobienia na obraz arkusza 
kalkulacyjnego - przykładowo - z wyliczeniami obowiązkowych składek 
płaconych państwu - też nie jestem w stanie dostrzec.
Poza tym, wyjątkowo interesującą koncepcją byłoby zapisywanie arkusza 
kalkulacyjnego z użyciem kompresji stratnej (obrazki JPEG).

> Wówczas warstwa, którą by widział użytkownik to byłaby warstwa tych
> obiektów i nie musiałby w ogóle się zastanawiać, jak to jest trzymane na
> niskim poziomie, tj. w plikach, BLOB-ach czy innych postaciach.

Powstałaby dodatkowa warstwa, która zwiększałaby komplikację systemu, 
natomiast w rzeczywistości niczego by nie ułatwiała.

Użytkownik Andrzej Rosa napisał:
>> Wówczas warstwa, którą by widział użytkownik to byłaby warstwa tych
>> obiektów i nie musiałby w ogóle się zastanawiać, jak to jest trzymane na
>> niskim poziomie, tj. w plikach, BLOB-ach czy innych postaciach.
>
> I tak jest, w przypadku (udanego) Drag and Drop.  (Zresztą, tutaj też
> widać odmienne podejścia.  X stosuje prosty protokół, który pozwala na
> komunikację pomiędzy programami.  Po prostu pośredniczy.  W Windows jest
> proprietarna specyfikacja, do której wszystkie klienty muszą się
> dostosować, albo nie działa.)
>

Bo do tego protokołu X-a programy nie muszą się stosować i będzie działać?

-- 
Piotr Borkowski

On 2011-09-15 00:03, Grzegorz Staniak wrote:
> "In Windows Server 8, literally everything seems to be manageable
> using PowerShell scripting.

cd na \\foo\bar będzie się dało zrobić czy to nie to stulecie jeszcze?

W dniu 2011-09-15 18:26, Wojciech Jaczewski pisze:
> Tomasz Wójtowicz wrote:
>
>> A teraz zauważ, że tabelką też mógłby być obraz - w końcu piksele są
>> poukładane w wiersze i kolumny. Więc program który normalnie służy do
>> obróbki danych statystycznych, za chwilę mógłby być użyty do policzenia
>> średniej luminancji pikseli w jakimś obszarze. To się nazywa
>> elastyczność oprogramowania.
>
> To jest elastyczność oprogramowania nie tam, gdzie jest potrzebna.
>

A pomyśl co by to było, gdyby Photoshop i Corel nie były takimi 
jednolitymi molochami programistycznymi, tylko każdy z nich był zbiorem 
małych programików, komunikujących się przez systemowy format "obraz". 
Wówczas można by Photoshopowego filtra użyć w Corelu, albo mieć grafikę 
wektorową jako warstwę w Photoshopie itd. Na poziomie odpowiednich API i 
odpowiednich BINARNYCH formatów danych to by się dało zrobić, ale 
robienie tego tekstowo wedle Uniksowej ideologii to byłby masochizm.

>> Podsumowując, chodzi mi o to, że pomiędzy warstwą plików fizycznych
>> (czyli strumieni znaków) a warstwą aplikacji brakuje jeszcze takiej
>> systemowej warstwy prezentacji, gdzie wszystkie dane byłyby widoczne
>> jako określone obiekty z możliwością łatwej reinterpretacji na inne
>> obiekty, jak np. obiekt graficzny staje się arkuszem kalkulacyjnym, albo
>> odwrotnie itd.
>
> Trudno mi sobie wyobrazić zrobienie czegokolwiek użytecznego z obrazkiem w
> arkuszu kalkulacyjnym.

Szkoda, że nie zajmujesz się pattern recognition, jak ja. Tam trzeba 
różne dziwne rzeczy z obrazkami robić. I tak szczęście, że mamy ImageJ, 
który pozwala pisać pluginy w Javie, kompilować i podłączać je w locie. 
Czasami testując jakiś algorytm robię kilka poprawek na minutę. Nie 
bardzo sobie wyobrażam takie tempo pracy na Photoshopie - kompilacja 
kodu do formatu Photoshopowego pluginu, RESTART Photoshopa, ponowne 
pootwieranie plików zamkniętych przy wyjściu z Photoshopa itd.

> Korzyści z przerobienia na obraz arkusza
> kalkulacyjnego - przykładowo - z wyliczeniami obowiązkowych składek
> płaconych państwu - też nie jestem w stanie dostrzec.

O wizualizacji danych liczbowych też nie słyszałeś?

> Poza tym, wyjątkowo interesującą koncepcją byłoby zapisywanie arkusza
> kalkulacyjnego z użyciem kompresji stratnej (obrazki JPEG).

Po prostu aplikacja określonej funkcji do określonych danych. Jeśli do 
czegoś Ci to potrzebne, to czemu nie. A jak niepotrzebne, no cóż - 
rubbish in, rubbish out.

>
>> Wówczas warstwa, którą by widział użytkownik to byłaby warstwa tych
>> obiektów i nie musiałby w ogóle się zastanawiać, jak to jest trzymane na
>> niskim poziomie, tj. w plikach, BLOB-ach czy innych postaciach.
>
> Powstałaby dodatkowa warstwa, która zwiększałaby komplikację systemu,
> natomiast w rzeczywistości niczego by nie ułatwiała.

Komplikację systemu by zwiększała, ale aplikacje by upraszczała. Po 
prostu przesunięcie części kodu z aplikacji do systemu. Np. jeden 
systemowy algorytm odczytujący pliki JPEG i konwertujący je na obiekt 
"obraz". A nie tak jak dzisiaj - Photoshop ma swój algorytm, Corel swój, 
ACDSee swój itd. Niepotrzebne przepisywanie kodu, a potem i tak wychodzą 
kwiatki - egzotyczne JPEG-i otwierane przez ACDSee nie są otwierane 
przez Photoshopa, a Corel otwiera z błędami itp.

On 2011-09-15, Piotr B. (pb2004) <p_borkowski@nospamgazeta.pl> wrote:
> Użytkownik Andrzej Rosa napisał:
>>> Wówczas warstwa, którą by widział użytkownik to byłaby warstwa tych
>>> obiektów i nie musiałby w ogóle się zastanawiać, jak to jest trzymane na
>>> niskim poziomie, tj. w plikach, BLOB-ach czy innych postaciach.
>>
>> I tak jest, w przypadku (udanego) Drag and Drop.  (Zresztą, tutaj też
>> widać odmienne podejścia.  X stosuje prosty protokół, który pozwala na
>> komunikację pomiędzy programami.  Po prostu pośredniczy.  W Windows jest
>> proprietarna specyfikacja, do której wszystkie klienty muszą się
>> dostosować, albo nie działa.)
>
> Bo do tego protokołu X-a programy nie muszą się stosować i będzie działać?

W tym kontekście, nie muszą.  Tzn. nie muszą się stosować do bodajże
trzech wspieranych typów danych.  Źródło i cel mogą się dogadać między
sobą, jeśli wspierają coś bardziej złożonego.  Xdnd się nie wtrąca, on
tylko pośredniczy.

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 15.09.2011, Tomasz Wójtowicz <SPAMMERS_GO_AWAY@SPAMMERS.COM> wroted:

>> To jest elastyczność oprogramowania nie tam, gdzie jest potrzebna.
>
> A pomyśl co by to było, gdyby Photoshop i Corel nie były takimi 
> jednolitymi molochami programistycznymi, tylko każdy z nich był zbiorem 
> małych programików, komunikujących się przez systemowy format "obraz". 

Hm... Chodziłyby rząd wielkości wolniej?

GS
-- 
Grzegorz Staniak   <gstaniak _at_ gmail [dot] com>

On 15.09.2011, Sebastian Biały <heby@poczta.onet.pl> wroted:

>> "In Windows Server 8, literally everything seems to be manageable
>> using PowerShell scripting.
>
> cd na \\foo\bar będzie się dało zrobić czy to nie to stulecie jeszcze?

Nie mam pojęcia. Mam bardzo mało kontaktu z Windows. Ale ta nowa 
wersja serwerowa brzmi fajnie. Wypróbuję ją na pewno.

GS
-- 
Grzegorz Staniak   <gstaniak _at_ gmail [dot] com>

Użytkownik Andrzej Rosa napisał:
> On 2011-09-15, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>  wrote:
>> Użytkownik Andrzej Rosa napisał:
>>>> Wówczas warstwa, którą by widział użytkownik to byłaby warstwa tych
>>>> obiektów i nie musiałby w ogóle się zastanawiać, jak to jest trzymane na
>>>> niskim poziomie, tj. w plikach, BLOB-ach czy innych postaciach.
>>>
>>> I tak jest, w przypadku (udanego) Drag and Drop.  (Zresztą, tutaj też
>>> widać odmienne podejścia.  X stosuje prosty protokół, który pozwala na
>>> komunikację pomiędzy programami.  Po prostu pośredniczy.  W Windows jest
>>> proprietarna specyfikacja, do której wszystkie klienty muszą się
>>> dostosować, albo nie działa.)
>>
>> Bo do tego protokołu X-a programy nie muszą się stosować i będzie działać?
>
> W tym kontekście, nie muszą.  Tzn. nie muszą się stosować do bodajże
> trzech wspieranych typów danych.  Źródło i cel mogą się dogadać między
> sobą, jeśli wspierają coś bardziej złożonego.  Xdnd się nie wtrąca, on
> tylko pośredniczy.
>

Jak zwykle gdy piszesz o Windowsie napisałeś brednie. Może doczytaj o 
strukturze FORMATETC ze szczególnym uwzględnieniem pola cfFormat gdzie 
pisze m. in.:
„Private application formats understood only by the application offering 
the format, or by other applications offering similar features.”.

-- 
Piotr Borkowski

W dniu 2011-09-15 20:52, Grzegorz Staniak pisze:
> On 15.09.2011, Tomasz Wójtowicz<SPAMMERS_GO_AWAY@SPAMMERS.COM>  wroted:
>
>>> To jest elastyczność oprogramowania nie tam, gdzie jest potrzebna.
>>
>> A pomyśl co by to było, gdyby Photoshop i Corel nie były takimi
>> jednolitymi molochami programistycznymi, tylko każdy z nich był zbiorem
>> małych programików, komunikujących się przez systemowy format "obraz".
>
> Hm... Chodziłyby rząd wielkości wolniej?

Na komputerze rząd wielkości szybszym chodziłyby tak samo. I z uwagi na 
uzyskiwaną elastyczność nie byłaby to zmarnowana moc obliczeniowa.

Na przykład GUI na Atari ST wystarczała Motorola 68000 i 1MB ramu. 
Windows 7 domaga się P4, 1GB RAM i akceleratora k*rwa graficznego. Tylko 
po to, żeby GUI wyświetlać. To się nazywa zmarnowana moc obliczeniowa.

Dnia Thu, 15 Sep 2011 21:39:40 +0200, Tomasz Wójtowicz napisał(a):


> 
> Na przykład GUI na Atari ST wystarczała Motorola 68000 i 1MB ramu. 
> Windows 7 domaga się P4, 1GB RAM i akceleratora k*rwa graficznego.

Akceleratora, dodajmy, który ma każdy komputer.

> Tylko 
> po to, żeby GUI wyświetlać. To się nazywa zmarnowana moc obliczeniowa.

Swoją drogą ciekawe, że gdy w linuksowym świecie się pojawił compiz to
wtedy nie była to zmarnowana moc.

-- 
Andrzej Libiszewski; GG: 5289118
"It is not always the majestic concerns of Imperial ministers which
dictate the course of history, nor is it necessarily the
pontifications of priests which move the hands of God."

On 2011-09-15, Piotr B. (pb2004) <p_borkowski@nospamgazeta.pl> wrote:
> Użytkownik Andrzej Rosa napisał:
>> On 2011-09-15, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>  wrote:
>>>>
>>>> I tak jest, w przypadku (udanego) Drag and Drop.  (Zresztą, tutaj też
>>>> widać odmienne podejścia.  X stosuje prosty protokół, który pozwala na
>>>> komunikację pomiędzy programami.  Po prostu pośredniczy.  W Windows jest
>>>> proprietarna specyfikacja, do której wszystkie klienty muszą się
>>>> dostosować, albo nie działa.)
>>>
>>> Bo do tego protokołu X-a programy nie muszą się stosować i będzie działać?
>>
>> W tym kontekście, nie muszą.  Tzn. nie muszą się stosować do bodajże
>> trzech wspieranych typów danych.  Źródło i cel mogą się dogadać między
>> sobą, jeśli wspierają coś bardziej złożonego.  Xdnd się nie wtrąca, on
>> tylko pośredniczy.
>>
>
> Jak zwykle gdy piszesz o Windowsie napisałeś brednie. 

Gdzie konkretnie?

> Może doczytaj o 
> strukturze FORMATETC ze szczególnym uwzględnieniem pola cfFormat gdzie 
> pisze m. in.:
> „Private application formats understood only by the application offering 
> the format, or by other applications offering similar features.”.

"Those who don't understand UNIX are condemned to reinvent it, poorly."
– Henry Spencer

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 2011-09-15, Tomasz Wójtowicz <SPAMMERS_GO_AWAY@SPAMMERS.COM> wrote:
> W dniu 2011-09-15 18:26, Wojciech Jaczewski pisze:
>
>> To jest elastyczność oprogramowania nie tam, gdzie jest potrzebna.
>>
>
> A pomyśl co by to było, gdyby Photoshop i Corel nie były takimi 
> jednolitymi molochami programistycznymi, tylko każdy z nich był zbiorem 
> małych programików, komunikujących się przez systemowy format "obraz". 
> Wówczas można by Photoshopowego filtra użyć w Corelu, albo mieć grafikę 
> wektorową jako warstwę w Photoshopie itd. Na poziomie odpowiednich API i 
> odpowiednich BINARNYCH formatów danych to by się dało zrobić, ale 
> robienie tego tekstowo wedle Uniksowej ideologii to byłby masochizm.

Imagemagic jest pisany zgodnie z tą koncepcją.  Narzędzia convert i
mogrify są w stanie nakładać filtry.  Nie wiem czy Ci wystarczą, ale
obejrzeć można.   

BTW - prosty tekst do grafiki to raczej tylko w usenecie.  Uniksowa
ideologia jednak nie propaguje masochizmu. ;-)

>> Trudno mi sobie wyobrazić zrobienie czegokolwiek użytecznego z obrazkiem w
>> arkuszu kalkulacyjnym.
>
> Szkoda, że nie zajmujesz się pattern recognition, jak ja. Tam trzeba 
> różne dziwne rzeczy z obrazkami robić. I tak szczęście, że mamy ImageJ, 
> który pozwala pisać pluginy w Javie, kompilować i podłączać je w locie. 
> Czasami testując jakiś algorytm robię kilka poprawek na minutę. Nie 
> bardzo sobie wyobrażam takie tempo pracy na Photoshopie - kompilacja 
> kodu do formatu Photoshopowego pluginu, RESTART Photoshopa, ponowne 
> pootwieranie plików zamkniętych przy wyjściu z Photoshopa itd.

Oba podejścia (w sensie, windowsowe i uniksowe) są zasadne.  Z czasem
nawet MS to zaakceptował, od czego przecież zaczął się ten wątek.  Po
prostu zależy co się robi, kto to robi i jak często.

[...]
-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 2011-09-15, Andrzej Libiszewski <a.libiszewski@gazeta.usunto.pl> wrote:
> Dnia Thu, 15 Sep 2011 21:39:40 +0200, Tomasz Wójtowicz napisał(a):
[...]
>> Tylko 
>> po to, żeby GUI wyświetlać. To się nazywa zmarnowana moc obliczeniowa.
>
> Swoją drogą ciekawe, że gdy w linuksowym świecie się pojawił compiz to
> wtedy nie była to zmarnowana moc.

Pamiętam jak pierwszy raz uruchomiłem to coś.  Działało wręcz
błyskawicznie, pozwalało na bardzo szybkie mieszanie bardzo dużą ilością
okien z nietrywialną zawartością, co wcześniej wydawało się niemożliwe.
Nic dziwnego, że ludzie się na to rzucili.  

A że nic poza eye-candy z tego nie zostało?  Cóż.   

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

W dniu 2011-09-16 06:13, Andrzej Rosa pisze:
> On 2011-09-15, Tomasz Wójtowicz<SPAMMERS_GO_AWAY@SPAMMERS.COM>  wrote:
>> W dniu 2011-09-15 18:26, Wojciech Jaczewski pisze:
>>
>>> To jest elastyczność oprogramowania nie tam, gdzie jest potrzebna.
>>>
>>
>> A pomyśl co by to było, gdyby Photoshop i Corel nie były takimi
>> jednolitymi molochami programistycznymi, tylko każdy z nich był zbiorem
>> małych programików, komunikujących się przez systemowy format "obraz".
>> Wówczas można by Photoshopowego filtra użyć w Corelu, albo mieć grafikę
>> wektorową jako warstwę w Photoshopie itd. Na poziomie odpowiednich API i
>> odpowiednich BINARNYCH formatów danych to by się dało zrobić, ale
>> robienie tego tekstowo wedle Uniksowej ideologii to byłby masochizm.
>
> Imagemagic jest pisany zgodnie z tą koncepcją.  Narzędzia convert i
> mogrify są w stanie nakładać filtry.  Nie wiem czy Ci wystarczą, ale
> obejrzeć można.
>
> BTW - prosty tekst do grafiki to raczej tylko w usenecie.  Uniksowa
> ideologia jednak nie propaguje masochizmu. ;-)

Jest format tekstowy zapisu grafiki. Po prostu jest to plik CSV z 
zapisanymi dziesiętnie wartościami poszczególnych subpikseli. Coś jak 
BMP, tylko zamiast tego okropnego binarnego formatu, jest plik tekstowy 
błogosławiony przez uniksowe autorytety.

Użytkownik Andrzej Rosa napisał:
> On 2011-09-15, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>  wrote:
>> Użytkownik Andrzej Rosa napisał:
>>> On 2011-09-15, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>   wrote:
>>>>>
>>>>> I tak jest, w przypadku (udanego) Drag and Drop.  (Zresztą, tutaj też
>>>>> widać odmienne podejścia.  X stosuje prosty protokół, który pozwala na
>>>>> komunikację pomiędzy programami.  Po prostu pośredniczy.  W Windows jest
>>>>> proprietarna specyfikacja, do której wszystkie klienty muszą się
>>>>> dostosować, albo nie działa.)
>>>>
>>>> Bo do tego protokołu X-a programy nie muszą się stosować i będzie działać?
>>>
>>> W tym kontekście, nie muszą.  Tzn. nie muszą się stosować do bodajże
>>> trzech wspieranych typów danych.  Źródło i cel mogą się dogadać między
>>> sobą, jeśli wspierają coś bardziej złożonego.  Xdnd się nie wtrąca, on
>>> tylko pośredniczy.
>>>
>>
>> Jak zwykle gdy piszesz o Windowsie napisałeś brednie.
>
> Gdzie konkretnie?
>

Tym razem bzdurzyłeś tam gdzie pisałeś o drag&drop na Windowsach.

>> Może doczytaj o
>> strukturze FORMATETC ze szczególnym uwzględnieniem pola cfFormat gdzie
>> pisze m. in.:
>> „Private application formats understood only by the application offering
>> the format, or by other applications offering similar features.”.
>
> "Those who don't understand UNIX are condemned to reinvent it, poorly."
> – Henry Spencer
>

Nie tobie to oceniać skoro nie masz zielonego pojęcia jak działa d&d w 
obydwu systemach.

-- 
Piotr Borkowski

On 16.09.2011 01:28, Andrzej Libiszewski wrote:
/../
> Swoją drogą ciekawe, że gdy w linuksowym świecie się pojawił compiz to
> wtedy nie była to zmarnowana moc.
>
Compiz nie ma takich wymagań i najpewniejszym sposobem jego wyłączenia 
jest odinstalowanie.

On 2011-09-16, Piotr B. (pb2004) <p_borkowski@nospamgazeta.pl> wrote:
> Użytkownik Andrzej Rosa napisał:
>> On 2011-09-15, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>  wrote:
>>> Użytkownik Andrzej Rosa napisał:
>>>> On 2011-09-15, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>   wrote:
>>>>>>
>>>>>> I tak jest, w przypadku (udanego) Drag and Drop.  (Zresztą, tutaj też
>>>>>> widać odmienne podejścia.  X stosuje prosty protokół, który pozwala na
>>>>>> komunikację pomiędzy programami.  Po prostu pośredniczy.  W Windows jest
>>>>>> proprietarna specyfikacja, do której wszystkie klienty muszą się
>>>>>> dostosować, albo nie działa.)
>>>>>
>>>>> Bo do tego protokołu X-a programy nie muszą się stosować i będzie działać?
>>>>
>>>> W tym kontekście, nie muszą.  Tzn. nie muszą się stosować do bodajże
>>>> trzech wspieranych typów danych.  Źródło i cel mogą się dogadać między
>>>> sobą, jeśli wspierają coś bardziej złożonego.  Xdnd się nie wtrąca, on
>>>> tylko pośredniczy.
>>>>
>>>
>>> Jak zwykle gdy piszesz o Windowsie napisałeś brednie.
>>
>> Gdzie konkretnie?
>>
>
> Tym razem bzdurzyłeś tam gdzie pisałeś o drag&drop na Windowsach.

Czyli nigdzie konkretnie?

>>> Może doczytaj o
>>> strukturze FORMATETC ze szczególnym uwzględnieniem pola cfFormat gdzie
>>> pisze m. in.:
>>> „Private application formats understood only by the application offering
>>> the format, or by other applications offering similar features.”.
>>
>> "Those who don't understand UNIX are condemned to reinvent it, poorly."
>> – Henry Spencer
>>
>
> Nie tobie to oceniać skoro nie masz zielonego pojęcia jak działa d&d w 
> obydwu systemach.

To nie tak.  Jakbyś wykazał, że np. d&d w Windows kładzie nacisk na
prostotę i współdziałanie (interoperatibility), a w X'ach jest to
zagmatwane ponad konieczność, to byś (na ten przykład) po prostu
pokazał, jak ja się na tym nie znam za to to przedpiśca miał po prostu
rację.

No bo bez czegoś w tym stylu, zastosowałeś banalnego adpersona, które
się po prostu zlewa, nie?

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

On 16.09.2011, Tomasz Wójtowicz <SPAMMERS_GO_AWAY@SPAMMERS.COM> wroted:

>> BTW - prosty tekst do grafiki to raczej tylko w usenecie.  Uniksowa
>> ideologia jednak nie propaguje masochizmu. ;-)
>
> Jest format tekstowy zapisu grafiki. Po prostu jest to plik CSV z 
> zapisanymi dziesiętnie wartościami poszczególnych subpikseli. Coś jak 
> BMP, tylko zamiast tego okropnego binarnego formatu, jest plik tekstowy 
> błogosławiony przez uniksowe autorytety.

To by znowu było cholernie niewydajne. Pakowanie wartości pikseli 
tekstowo do komórek CSV? Potrzebna byłaby kompresja, bo każdy większy
rozmiarami plik zajmowałby od cholery miejsca. Czyli wczytanie, 
dekompresja, odkodowywanie tekstu na binarne wartości dla danego 
modelu kolorów, upakowanie w odpowiednią strukturę, wysłanie do
sterownika sprzętu... Taki wyścig w kierunku "sprawimy, żeby twój
nowy cztery razy szybszy sprzęt mulił ci się tak samo jak bieżący,
a może i bardziej!".

GS
-- 
Grzegorz Staniak   <gstaniak _at_ gmail [dot] com>

Użytkownik Andrzej Rosa napisał:
> On 2011-09-16, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>  wrote:
>> Użytkownik Andrzej Rosa napisał:
>>> On 2011-09-15, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>   wrote:
>>>> Użytkownik Andrzej Rosa napisał:
>>>>> On 2011-09-15, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>    wrote:
>>>>>>>
>>>>>>> I tak jest, w przypadku (udanego) Drag and Drop.  (Zresztą, tutaj też
>>>>>>> widać odmienne podejścia.  X stosuje prosty protokół, który pozwala na
>>>>>>> komunikację pomiędzy programami.  Po prostu pośredniczy.  W Windows jest
>>>>>>> proprietarna specyfikacja, do której wszystkie klienty muszą się
>>>>>>> dostosować, albo nie działa.)
>>>>>>
>>>>>> Bo do tego protokołu X-a programy nie muszą się stosować i będzie działać?
>>>>>
>>>>> W tym kontekście, nie muszą.  Tzn. nie muszą się stosować do bodajże
>>>>> trzech wspieranych typów danych.  Źródło i cel mogą się dogadać między
>>>>> sobą, jeśli wspierają coś bardziej złożonego.  Xdnd się nie wtrąca, on
>>>>> tylko pośredniczy.
>>>>>
>>>>
>>>> Jak zwykle gdy piszesz o Windowsie napisałeś brednie.
>>>
>>> Gdzie konkretnie?
>>>
>>
>> Tym razem bzdurzyłeś tam gdzie pisałeś o drag&drop na Windowsach.
>
> Czyli nigdzie konkretnie?
>

Konkretnie tam gdzie bzdurzyłeś o narzucanych trzech typach danych i 
dostosowywaniu się do prioprietarnej implementacji.

>>>> Może doczytaj o
>>>> strukturze FORMATETC ze szczególnym uwzględnieniem pola cfFormat gdzie
>>>> pisze m. in.:
>>>> „Private application formats understood only by the application offering
>>>> the format, or by other applications offering similar features.”.
>>>
>>> "Those who don't understand UNIX are condemned to reinvent it, poorly."
>>> – Henry Spencer
>>>
>>
>> Nie tobie to oceniać skoro nie masz zielonego pojęcia jak działa d&d w
>> obydwu systemach.
>
> To nie tak.  Jakbyś wykazał, że np. d&d w Windows kładzie nacisk na
> prostotę i współdziałanie (interoperatibility), a w X'ach jest to
> zagmatwane ponad konieczność, to byś (na ten przykład) po prostu
> pokazał, jak ja się na tym nie znam za to to przedpiśca miał po prostu
> rację.

Co mnie obchodzi jak jest w X-ach. Pokazałem że bzdurzyłeś o d&d w 
Windowsach. Nie ma żadnego narzucania prioprietarnej implementacji tylko 
jest określone api tak jak w przypadku Xów, nie ma także żadnego 
ograniczenia do trzech typów danych. Tak samo system pośredniczy a jakie 
dane są przekazywane i w jaki sposób uzgadniają między sobą programy.

>
> No bo bez czegoś w tym stylu, zastosowałeś banalnego adpersona, które
> się po prostu zlewa, nie?
>

Nazwij to jak chcesz ale kolejny raz palnąłeś w temacie Windows jak łysy 
grzywką o beton.

-- 
Piotr Borkowski

W dniu 2011-09-16 13:35, Smok Eustachy pisze:
> On 16.09.2011 01:28, Andrzej Libiszewski wrote:
> /../
>> Swoją drogą ciekawe, że gdy w linuksowym świecie się pojawił compiz to
>> wtedy nie była to zmarnowana moc.
>>
> Compiz nie ma takich wymagań i najpewniejszym sposobem jego wyłączenia
> jest odinstalowanie.

A ktoś broni wyłączyć efekty graficzne w Win?


-- 
Andrzej Libiszewski; GG: 5289118
"Have you any idea why a raven is like a writing desk?"

On 16.09.2011 15:59, Andrzej Libiszewski wrote:
/.../
> A ktoś broni wyłączyć efekty graficzne w Win?
>
Ponoć ciężko.

W dniu 2011-09-16 16:02, Smok Eustachy pisze:
> On 16.09.2011 15:59, Andrzej Libiszewski wrote:
> /.../
>> A ktoś broni wyłączyć efekty graficzne w Win?
>>
> Ponoć ciężko.
>

Ee tam.

-- 
Andrzej Libiszewski; GG: 5289118
"Have you any idea why a raven is like a writing desk?"

Andrzej Libiszewski <a.libiszewski@gazeta.usunto.pl> wrote:
> > Tylko 
> > po to, żeby GUI wyświetlać. To się nazywa zmarnowana moc obliczeniowa.
> 
> Swoją drogą ciekawe, że gdy w linuksowym świecie się pojawił compiz to
> wtedy nie była to zmarnowana moc.
> 
... tylko uptime. Nieźle znajdował błędy w sterownikach kart
graficznych.


Pozdrawiam

-- 
Radosław Gancarz                             r a d e k g @ h e l l . p l
http://bugs.from.hell.pl/

On 16.09.2011 16:53, Andrzej Libiszewski wrote:
/.../
>> Ponoć ciężko.
>>
>
> Ee tam.
>
Znając tylko nazwę "Compiz" jestem w stanie łatwo to wywalić. Pod 
Windows to przezroczystość wywaliłem i się gubię w sumie.

On 2011-09-16, Piotr B. (pb2004) <p_borkowski@nospamgazeta.pl> wrote:
> Użytkownik Andrzej Rosa napisał:
>> On 2011-09-16, Piotr B. (pb2004)<p_borkowski@nospamgazeta.pl>  wrote:
>>
>>>>>> W tym kontekście, nie muszą.  Tzn. nie muszą się stosować do bodajże
>>>>>> trzech wspieranych typów danych.  Źródło i cel mogą się dogadać między
>>>>>> sobą, jeśli wspierają coś bardziej złożonego.  Xdnd się nie wtrąca, on
>>>>>> tylko pośredniczy.
>>>>>>
>>>>>
>>>>> Jak zwykle gdy piszesz o Windowsie napisałeś brednie.
>>>>
>>>> Gdzie konkretnie?
>>>>
>>>
>>> Tym razem bzdurzyłeś tam gdzie pisałeś o drag&drop na Windowsach.
>>
>> Czyli nigdzie konkretnie?
>
> Konkretnie tam gdzie bzdurzyłeś o narzucanych trzech typach danych

To było o Xdnd.  Napisałem "bodajże", ale chyba dobrze pamiętałem.

http://www.newplanetsoftware.com/xdnd/

Step 2:

The target receives XdndEnter.

The ClientMessage only has space for three data types, so if the source
supports more than this, the target must retrieve the property
XdndTypeList from the source window in order to get the list of
available types. (2)


> i dostosowywaniu się do prioprietarnej implementacji.

Owszem.  Może nie pamiętasz, ale OLE było jedną z dźwigni, która
wysadziła WordPerfecta z siodła.

http://www.novell.com/news/press/archive/2004/11/complaint.pdf

[...]
>> No bo bez czegoś w tym stylu, zastosowałeś banalnego adpersona, które
>> się po prostu zlewa, nie?
>>
>
> Nazwij to jak chcesz ale kolejny raz palnąłeś w temacie Windows jak łysy 
> grzywką o beton.

A może by tak zapytać o doprecyzowanie i ewentualnie dopiero potem się
zapienić?

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.

Użytkownik Andrzej Rosa napisał:
>
> To było o Xdnd.  Napisałem "bodajże", ale chyba dobrze pamiętałem.
>
> http://www.newplanetsoftware.com/xdnd/
>
> Step 2:
>
> The target receives XdndEnter.
>
> The ClientMessage only has space for three data types, so if the source
> supports more than this, the target must retrieve the property
> XdndTypeList from the source window in order to get the list of
> available types. (2)
>

To nic dziwnego że się nie zrozumieliśmy. Xdnd nie ma żadnego 
ograniczenia do 3 typów, do którego aplikacje nie muszą się stosować. 
Tutaj tylko jest mowa w jaki sposób według protokołu przesłać informacje 
o większej liczbie obsługiwanych typów danych i aplikacje muszą się do 
tego stosować. Przy okazji zagmatwane jest te Xowe dnd.

>
>> i dostosowywaniu się do prioprietarnej implementacji.
>
> Owszem.  Może nie pamiętasz, ale OLE było jedną z dźwigni, która
> wysadziła WordPerfecta z siodła.
>
> http://www.novell.com/news/press/archive/2004/11/complaint.pdf
>
> [...]

Bzdurny pozew. Równie dobrze mogli zarzucać Microsoftowi że aby utworzyć 
okno aplikacji trzeba użyć funkcji CreateWindow. Tyle samo to miałoby 
sensu. Chcieli używać OpenDoc to trzeba było tak ten framework napisać 
aby korzystał z api systemowych i był kompatybilny z mechanizmami 
systemowymi. Nie jest winą Microsoftu że mieli developerów tkwiących 
ciągle w epoce DOS.

-- 
Piotr Borkowski

Dnia Sat, 17 Sep 2011 00:06:33 +0200, Smok Eustachy napisał(a):

> On 16.09.2011 16:53, Andrzej Libiszewski wrote:
> /.../
>>> Ponoć ciężko.
>>>
>>
>> Ee tam.
>>
> Znając tylko nazwę "Compiz" jestem w stanie łatwo to wywalić. Pod 
> Windows to przezroczystość wywaliłem i się gubię w sumie.

Compiz był nakładką. Manager okien w Win jest integralną częścią systemu.


-- 
Andrzej Libiszewski; GG: 5289118
"I try to believe in as many as six impossible things before breakfast.
Count them, Alice. One, there are drinks that make you shrink. Two,
there are foods that make you grow. Three, animals can talk. Four, cats
can disappear. Five, there is a place called Underland.
Six, I can slay the Jabberwocky."

On 18.09.2011 20:32, Andrzej Libiszewski wrote:
/.../
> Compiz był nakładką. Manager okien w Win jest integralną częścią systemu.
>
No i to moja wina czy ich?

Dnia Sun, 18 Sep 2011 20:47:23 +0200, Smok Eustachy napisał(a):

> On 18.09.2011 20:32, Andrzej Libiszewski wrote:
> /.../
>> Compiz był nakładką. Manager okien w Win jest integralną częścią systemu.
>>
> No i to moja wina czy ich?

A dlaczego musisz to postrzegać w katetegoriach winy?

-- 
Andrzej Libiszewski; GG: 5289118
"It is not always the majestic concerns of Imperial ministers which
dictate the course of history, nor is it necessarily the
pontifications of priests which move the hands of God."

On 18.09.2011 22:52, Andrzej Libiszewski wrote:
/../
>> No i to moja wina czy ich?
>
> A dlaczego musisz to postrzegać w katetegoriach winy?
>
A co to jest?
To co skutkuje niemożnością wywalenia

Dnia Sun, 18 Sep 2011 23:06:18 +0200, Smok Eustachy napisał(a):

> On 18.09.2011 22:52, Andrzej Libiszewski wrote:
> /../
>>> No i to moja wina czy ich?
>>
>> A dlaczego musisz to postrzegać w katetegoriach winy?
>>
> A co to jest?
> To co skutkuje niemożnością wywalenia

wywalenie =/= wyłączenie

-- 
Andrzej Libiszewski; GG: 5289118
God created Arrakis to train the faithful.

Tomasz Wójtowicz <SPAMMERS_GO_AWAY@spammers.com> wrote:
> W dniu 2011-09-15 09:45, Tomasz Torcz pisze:
>>   Dzieki, Tomasz, za post o tresci:
>>> Przez filozofię mam na myśli to, że zarówno Windows jak i typowe Uniksy
>>> trzymają informacje w plikach, które są przez użytkownika obrabiane
>>> aplikacjami. Bo takie szczegóły jak to, że Uniksach jest /, a Windowsach
>>> dysk:\ to są mało istotne pierdoły.
>>
>>    Gdzie na Windows jest plik odpowiadające /dev/sda1?
>> Jakie API pozwala na obsługę timerów i sygnałów przez deskryptor pliku?
>>
> 
> No i kompletnie mnie nie zrozumiałeś. Właśnie o tym piszę, że różnice w 
> API to drugorzędna sprawa. Pewnie że te różnice utrudniają przenoszenie 
> oprogramowania, a programista może odczuć, że na jednym systemie pisze 
> się łatwiej niż na drugim, ale mimo wszystko na obydwu systemach DA SIĘ 
> to samo.
	... i tak i nie. Linux powoli zmierza w strone systemu RT,
juz osiagnal cos co okresla sie jako soft-RT. Samo wykonanie oprogramowania
to nie wszystko. Czasami wymagane jest jednak stosowanie sie do pewnego
rezimu wykonania. Z powazaniem
								Adam Przybyla

On 15 Wrz, 00:03, Grzegorz Staniak <gstan...@gmail.com> wrote:
> ... czyli opowiadanie bajek o przewadze GUI nad CLI na
> serwerach:
>
> http://www.itworld.com/virtualization/203199/windows-server-8-highlig...
>
> [...]
> "In Windows Server 8, literally everything seems to be manageable
> using PowerShell scripting. Most features shown to us at the
> reviewers workshop were built to be managed by PowerShell first and
> UI second."
>
> Chłopaki myślą, starają się, jeszcze trochę i wymyślą uniksa.

Po prostu im  się nie chce. IMO stworzenie takiego wszechmocnego GUI
wymaga znacznie więcej nakładu niż CLI do którego jak w przypadku
PowerShella po prostu tworzą dodatkowe moduły z cmdletami i tyle. O
niebo wolę zarządzanie MS SQLem w GUI niż OpenEdgem w CLI, choć GUI MS
SQL'a ostatnimi czasy mocno się zaciemniło, ale jednak większość
operacji wykonuje się o niebo szybciej.

--
Tomasz

On 15 Wrz, 20:23, Sebastian Biały <h...@poczta.onet.pl> wrote:
> On 2011-09-15 00:03, Grzegorz Staniak wrote:
>
> > "In Windows Server 8, literally everything seems to be manageable
> > using PowerShell scripting.
>
> cd na \\foo\bar będzie się dało zrobić czy to nie to stulecie jeszcze?

Chodzi Ci o wsparcie UNC w linii poleceń? W PS działa od zawsze.

--
Tomasz

On 20.09.2011, Tomek <tomasz.szkudlarek@gmail.com> wroted:

>> http://www.itworld.com/virtualization/203199/windows-server-8-highlig...
>>
>> [...]
>> "In Windows Server 8, literally everything seems to be manageable
>> using PowerShell scripting. Most features shown to us at the
>> reviewers workshop were built to be managed by PowerShell first and
>> UI second."
>>
>> Chłopaki myślą, starają się, jeszcze trochę i wymyślą uniksa.
>
> Po prostu im  się nie chce. IMO stworzenie takiego wszechmocnego GUI
> wymaga znacznie więcej nakładu niż CLI 

Powiem więcej: to jest po prostu niemożliwe.

> do którego jak w przypadku PowerShella po prostu tworzą dodatkowe
> moduły z cmdletami i tyle. O niebo wolę zarządzanie MS SQLem 
> w GUI niż OpenEdgem w CLI

W szzególności środowiska GUI świetnie się skryptuje i integruje.

GS
-- 
Grzegorz Staniak   <gstaniak _at_ gmail [dot] com>

On 21 Wrz, 00:51, Grzegorz Staniak <gstan...@gmail.com> wrote:
> On 20.09.2011, Tomek <tomasz.szkudla...@gmail.com> wroted:
>
> >>http://www.itworld.com/virtualization/203199/windows-server-8-highlig...
>
> >> [...]
> >> "In Windows Server 8, literally everything seems to be manageable
> >> using PowerShell scripting. Most features shown to us at the
> >> reviewers workshop were built to be managed by PowerShell first and
> >> UI second."
>
> >> Chłopaki myślą, starają się, jeszcze trochę i wymyślą uniksa.
>
> > Po prostu im  się nie chce. IMO stworzenie takiego wszechmocnego GUI
> > wymaga znacznie więcej nakładu niż CLI
>
> Powiem więcej: to jest po prostu niemożliwe.

Tak, ale taka hybryda jest wystarczająca :)

> > do którego jak w przypadku PowerShella po prostu tworzą dodatkowe
> > moduły z cmdletami i tyle. O niebo wolę zarządzanie MS SQLem
> > w GUI niż OpenEdgem w CLI
>
> W szzególności środowiska GUI świetnie się skryptuje i integruje.

A po co je skryptować? Albo inaczej - w przykładowym środowisku SQL (w
wersjach Standard i wyżej) nie ma potrzeby pisania żadnego skryptu. W
wersji Express już niestety tak, bo niedostępnych jest wiele narzędzi
z komercyjnych wersji.

Albo taki cron - kurcze "Zaplanowane Zadania" w wersji 2008 mają
piękny interface i przeszły prawdziwą rewolucję - za pomocą paru
kliknięć można zdefiniować zdarzenia reagujące na pojawienie się
konkretnych zdarzeń (eventów) systemowych czy np. na logowanie się
użytkownika, etc. Oskryptuj to w cronie. Da się, pewnie, tylko jakim
kosztem czasu i pracy. Nawet zdarzenia czasowe mają więcej możliwości
OOB niż te z crona.

Fakt, czasem się sięga (w Exchange 2010 to nawet mus) do PowerShella
czy WSH, dlatego uwielbiam środowiska hybrydowe.

--
Tomasz