Re: W czym Windows 8 jest lepszy?

Autor: R.e.m.e.K <go_at_dev.null>
Data: Tue, 13 Nov 2012 19:36:51 +0100
Message-ID: <k7u408$jij$1@news.icm.edu.pl>
Content-Type: text/plain; charset="utf-8"

Dnia Tue, 13 Nov 2012 18:49:52 +0100, Rados艂aw Sok贸艂 napisa艂(a):

>> Analiza i przetwarzanie danych kontra zwykly user = walkower, zwykly user
>> nie dotarl.
>
> Rozwi艅 prosz臋, bo jaki inny program ma wykonywa膰 d艂ugotrwa艂e
> operacje dyskowe ni偶 co艣, co analizuje/przetwarza du偶y zbi贸r
> danych?

Serwer dlna, torrent, defragmentator dysku pracujacy w tle, antywirus
skanujacy dysk, indeksacja systemowa, cos by tam sie jeszcze znalazlo.
Niemniej i tak chodzilo mi o to programowanie przez usera, 99% userow i tak
nie bedzie programowac, bo mimo tego, ze komputer z definicji to urzadzenie
do programowania to role juz dawno zostaly podzielone, sa programisci i sa
uzytkownicy. I to sie nie zmieni.
 
>> ...chyba zapominasz o drobnym szczegole. Otoz producenci softwaru uzywaja
>> kompilatorow i bibliotek pisanych przez firmy trzecie. I tak sie dziwnie
>> sklada, ze co rok kompilowane Hello World jest wieksze. Kiedys kilka KiB,
>> teraz kilka MiB. Co producent softu ma z tym zrobic? Pisac w assemblerze czy
>> wlasny kompilator tworzyc? A moze kompilowac kompilatorem z lat '80?
>
> To sta艂y narzut. Poza tym przesadzasz, Hello World wci膮偶 zaj-
> muje kilkana艣cie KiB, nawet w najnowszych kompilatorach.
> Pisz臋 du偶o program贸w, wi臋c mam w tym akurat mocne rozeznanie
> (zreszt膮 moje najwi臋ksze programy po skompilowaniu maj膮 zaz-
> wyczaj po 200-300 KiB -- gdzie im do tych Twoich kilku MiB
> na samo Hello World?!?).

No widzisz, Twoje mocne rozeznanie Cie moze zawiesc. Ja tez akurat
programuje i tez co nieco wiem. Moim srodowiskiem pracy jest kompilator
Delphi. Kiedys produkowal exeki wielkosci kilkudziesieciu KiB. Teraz pusta
aplikacja konsolowa ma 900KiB, pusta aplikacja z GUI ma 2,1MiB. I co im
zrobisz? Do tego jesli pisze sie aplikacje korzystajace z bibliotek
dodatkowych, a ponadto te aplikacje maja po kilkaset okien to robi sie,
delikatnie mowiac, sporo stuffu do zapisania w exe.
Oczywiscie mozesz pisac, ze to do bani jezyk/srodowisko/cokolwiek, ale tak
nie jest. I akurat dla mnie jest zrozumiale, ze im wieksze mozliwosci
jezyka, im bogatsza biblioteka standardowa tym rozmiar bedzie wiekszy. Same
tylko generyki powoduja, ze kazda klasa z nich wywiedziona jest de facto
klonem klasy bazowej w sensie odrebnosci na poziomie zrodla (samym mnozeniem
bytow zajmuje sie juz kompilator w trakcie kompilacji). I takich mechanizmow
wplywajacych na wielkosc exe jest wiele. A te wszystkie animacje i grafiki,
ktore pietnujesz, tez gdzies byc musza i sa: w zasobach. Zobacz ile zajmuja
zasoby w systemowym calc.exe w Win7, polowe wielkosci pliku. Itd.
 
>> Jak widzisz nie. Wiekszosc tych potrzeb to cena postepu. W latach 90-93
>> mialem w systemie jeden proces, potem kilkanascie, teraz 150. Nie sadzisz,
>> ze to MUSI wymagac "mocniejszego" sprzetu?
>
> Sk膮d to 150?

Z potrzeby, niedawno mnie na te okolicznosc maglowal PK na grupie
pl.comp.pecet.

Message-ID: <k79d29$u0n$1_at_news.task.gda.pl>
 
> Pod Windows wci膮偶 liczba proces贸w jest wzgl臋dnie sensowna.
> W Vi艣cie zazwyczaj mam 20-30 (na swoim koncie; plus mo偶e
> drugie tyle jako SYSTEM i inne konta wbudowane). Faktycznie,
> pod Linuksem jedna sesja u偶ytkownika potrafi wytworzy膰 200
> proces贸w, ale to jest skutek dziwnej architektury pow艂oki
> (pisz臋 o GNOME), a nie przejaw tego, 偶e tak ma by膰 normalnie.
>
> Gdy jeden program tworzy jeden proces - a tak jest i powin-
> no by膰 zazwyczaj - trudno jest mie膰 uruchomionych jednocze艣-
> nie 100 program贸w.

Nie kazdy program to aplikacja z GUI.
 
>> Mylisz sie, miales w killfile kogos innego, jestes kolejna osoba
>> zakladajaca, ze jedno imie przypisane moze byc do jednej osoby.
>
> Mia艂em stworzony wpis po mailu.

Nie przypominam sobie bysmy sie "scieli", zasadniczo czytam Twoje posty z
przyjemnoscia i na pewno Cie nie obrazalem. Chyba, ze wywaliles mnie
profilaktycznie, bo niestety sunie za mna cien innego remka, ktorego polowa
usenetu ma w killfile :/

-- 
pozdro
R.e.m.e.K
Received on Tue 13 Nov 2012 - 19:40:02 MET

To archiwum zosta硂 wygenerowane przez hypermail 2.2.0 : Tue 13 Nov 2012 - 19:42:01 MET