Windows 10 będzie potrzebował mniej miejsca
System Windows 10 będzie potrzebował nawet 2,6 gigabajta przestrzeni dyskowej mniej niż dotychczas, gdyż będzie kompresował własne pliki. Dodatkowe 4-12 gigabajtów zostanie zaoszczędzonych dzięki rezygnacji z obrazu potrzebnego do odzyskania systemu w razie awarii. Windows 10 został napisany tak, by radził sobie bez tego obrazu.
Dzięki skompresowaniu plików systemowych użytkownicy 32-bitowej wersji nowego OS-u zaoszczędzą 1,5 gigabajta, a użytkownicy wersji 64-bitowej – 2,6 GB. Producenci komputerów z preinstalowanym systemem nie będą już umieszczali na dysku obrazu OS-u. Użytkownicy będą mogli jednak skorzystać z własnego nośnika z kompletnym obrazem systemu oraz zainstalowanych programów i odzyskać z niego całe oprogramowanie w razie awarii. Taki nośnik przyda się, gdy system ulegnie na tyle poważnej awarii, że nie będzie w stanie sam siebie naprawić.
Komentarze (25)
Piotrus Pan, 19 marca 2015, 14:11
MS znowu kombinuje i znowu w złą stronę. Kompresja to spadek wydajności, poza tym HDD 1TB można już tanio kupić, więc posiadając 1TB co za różnicę mi zrobi zyskanie 2,6GB?
Nawet jak MS zakłada, że wszyscy już mają SSD, to czy kompresja nie wywołuje więcej okeracji dyskowych? Czyli szybciej wykańcza SSD?
Z nimi tak zawsze ... jeden krok do przodu i dwa do tyłu ...
wilk, 19 marca 2015, 18:14
Ciekawe jak się chodzi z HDD podpiętym do telefonu - pamiętaj, że Windows 10 ma być jeden na wszystkie platformy. Dlaczego ma być więcej operacji odczytu? Mniejszy plik - mniej komórek/sektorów zajmuje. Ponadto w przypadku SSD nie mamy problemu z fragmentacją. Jedyny problem, tak jak piszesz, to narzut na dekompresję. Ostatnio pojawiły się wyniki testu SSD wedle których najwytrwalszy model wytrzymał 2,4PB transferu: http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead
Astroboy, 19 marca 2015, 18:25
To mnie właśnie przeraża. Linuxa stawia się bez problemu na superkomputerze, komputerze domowym, telefonie, tunerze satelitarnym czy pralce od wielu lat, ale oczywiście noblesse oblige.
thikim, 19 marca 2015, 20:53
Z kompresją zależy jakie dane się kompresuje. Jak kompresujemy pliki rzadko używane i takie do których czas dostępu nie jest krytyczny to spadku wydajności systemu nie zauważymy.
Zresztą po prawdzie to wiele exeków to pliki skompresowane i jakoś nikomu to nie przeszkadza...
Niektóre pliki systemowe są skompresowane już od dawna w wielu windowsach i dopóki o tym nie napisali to nikomu spadek wydajności nie przeszkadzał
chwytajemocje, 19 marca 2015, 22:32
Dla mnie osobiście wszystkie systemy powyżej systemu windows Xp, dziadostwo. Mianowice dla tego że kupuje się system z mnóstwem niepotrzebnych nam rzeczy które zżerają tylko pamięć ram, procesor i zapychają dysk śmieciami. Po za tym gratuluję wszystkim firmom które wypuszczają kompy z systemem win 7 i dają 2 lub 3 giga ramu, na początku działa spoko ale pobierze parę aktualizacji i zainstaluje się kilka programów to już po jakimś czasie zaczyna nieco zamulać. Widocznie firmy które konfigurują ten sprzęt nie mają wiedzy o tym że win 7 w pełni wykorzystuje swoje zasoby dopiero przy 4 giga ramu.
Zwłaszcza gratuluję firmie NTT która wypuściła netbuki z systemem win 7 i jednym giga ramu, a żeby było tego mało to po dołożeniu 3 giga, system widzi tylko 2, rewelacja.
Pozdrawiam
Jarek Duda, 20 marca 2015, 09:36
Kompresja w locie wymaga szybkich/tanich kompresorów - i trochę się ostatnio zmieniło na tym polu.
Standardowo używamy np. gzipa - tutaj jest porównanie z kilkoma kompresorami które już przeszły z kodowania Huffmana lub Range coding na Asymmetric Numeral Systems (zhuff, lzturbo, LZA, ZSTD) z http://mattmahoney.net/dc/text.html :
kompresor, wielkość enwiki8 po skompresowaniu, czas kompresji, dekompresji (ns/bajt)
LZA 0.82b –mx9 –b7 –h7 26,396,613 449 9.7
lzturbo 1.2 –39 –b24 26,915,461 582 2.8
WinRAR 5.00 –ma5 –m5 27,835,431 1004 31
WinRAR 5.00 –ma5 –m2 29,758,785 228 30
lzturbo 1.2 –32 30,979,376 19 2.7
zhuff 0.97 –c2 34,907,478 24 3.5
gzip 1.3.5 –9 36,445,248 101 17
pkzip 2.0.4 –ex 36,556,552 171 50
ZSTD 0.0.1 40,024,854 7.7 3.8
WinRAR 5.00 –ma5 –m1 40,565,268 54 31
Czyli są rzędu 5 razy szybsze zarówno w kodowaniu jak i dekodowaniu od opartych na Huffmanie (rar, gzip, pkzip) dla podobnego stopnia kompresji.
Dekodowanie ~500MB/s na rdzeń procesora to teraz standard dla ANS ( https://github.com/Cyan4973/FiniteStateEntropy ) - przy takich prędkościach można sobie pozwolić na kompresję w biegu - zarówno żeby oszczędzić miejsce na dysku, ale także żeby przyśpieszyć transmisję.
wilk, 20 marca 2015, 13:13
Przyczyn może być wiele. Na początek sprawdź ile masz w BIOS-ie zarezerwowane na karty AGP. Możliwe, że masz wersję Starter, która więcej niż 2GB nie obsłuży nigdy. Moduły mogą się "gryźć" ze sobą. Spróbuj wkładać moduły w innej kolejności lub nie wszystkie naraz i odpalać system. Ostatecznie mogą być uszkodzone.
Hehe, dokładnie. Przy przetwarzaniu np. skompresowanych folderów z mnóstwem plików tekstowych wydajność jest minimalnie zauważalna, a oszczędność miejsca gigantyczna. Poza tym zapewne obrazy exe-ków byłyby utrzymywane w pamięci w postaci rozpakowanej już, więc ewentualny spadek wydajności byłby tylko przy pierwszym odwołaniu się do jakiejś biblioteki.
Jarek Duda, 20 marca 2015, 13:53
Szybka kompresja raczej poprawia wydajność dysków, których fizyczny transfer jest zwykle tym wąskim gardłem - dzięki kompresji wystarczy odczytać mniejszy plik.
Np. LZ4 ( https://code.google.com/p/lz4/ ), używany w dziesiątkach produktów, osiąga 2GB/s/rdzeń - dużo taniej zdekodować w locie niż przeczytać z dysku większy plik.
Tak samo kompresja w locie pozwala zmniejszyć wymagania transmisji (np. walka H.264 -> H.265) - przyszłość to trzymać wszystko skompresowane.
Niestety problem jest zwykle z dostępem wewnątrz takich danych, ale też idzie się w tą stronę: http://en.wikipedia.org/wiki/Compressed_data_structure
Astroboy, 20 marca 2015, 14:39
Ciekaw jestem, kiedy hardwarowe rozwiązania na stałe zagoszczą na płytach głównych. Ciekawostka:
http://www.academia.edu/3308033/On-board_Implementation_of_Fractal_Compression_of_Satellite_Images_using_Distributed_Networked_GPUs
Jarek Duda, 20 marca 2015, 15:01
Odnośnie kosztownych kompresorów, szczególnie wideo, pewnie masz ASIC w telefonie ...
Dla reszty chyba wystarczy procesor - dostając rzędu 2GB/s/rdzeń dla kiepskiej kompresji, czy rzędu 500MB/s/rdzeń dla przyzwoitej.
Ale jasne można też robić FPGA czy ASIC - tutaj ANS też poprawia sytuację bo ma prostą tanią inicjalizację, podczas gdy Huffman wymaga sortowania symboli - budowanie drzewa jest sprzętowo dość kosztowne.
Astroboy, 20 marca 2015, 20:55
Jasne:
"The Internet? We are not interested in it"
"640K ought to be enough for anybody"
Mam bardzo prosty telefon, którym można wbijać gwoździe i dzwonić/esemesować. Jakoś niczego więcej nie oczekuję od telefonu.
Jarek Duda, 20 marca 2015, 23:00
A jak przestanie obsługiwać nowe modele gwoździ...
Pewnie i tak ma sprzętową kompresję dźwięku.
Astroboy, 20 marca 2015, 23:10
Tu technologia nie odnosi takich sukcesów, ale przyznam, że nie testowałem tytanowych gwoździ. Prozaiczna sprawa – nie stać mnie na to.
Owszem. Jak sam zauważasz, hardware ma kolosalną przyszłość.
thikim, 20 marca 2015, 23:15
Nie chciało mi się pisać więcej bo myślałem że wystarczy to co napisałem.
Tu nie chodzi o kompresowanie dużych ilości danych i tworzenie dysku skompresowanego (co umożliwiał już bodajże Windows 95) ani o robienie paczek archiwów co robiono już od DOSa.
Tylko w takich wypadkach byłby obserwowany jakiś spadek szybkości.
Tu chodzi o to że kompresji możemy poddawać poszczególne pliki.
Jak sobie skompresujemy plik 10 MB do załóżmy 7 MB to jakie będą opóźnienia przy jego załadowaniu do pamięci i dekompresji?
Załadować to go nawet szybciej załadujemy a zdekompresowanie 10 MB zajmie ułamki sekund nie odczuwalne. Wiele plików będzie tutaj skompresowanych niezależnie. Plików które zapewne są rzadziej używane przez system.
A te częściej też można w zasadzie skompresować bo zostaną zdekompresowane raz w czasie uruchamiania systemu i przez cały czas jego pracy pozostaną w pamięci operacyjnej.
http://arstechnica.com/information-technology/2015/03/windows-10-shaves-off-gigabytes-with-selective-system-file-compression/
"To enable high performance decompression, Microsoft has added a number of new compression algorithms to the NTFS filesystem that are designed for compressing executable files. These all appear to be variants of algorithms already well used and tested in other Windows software; three are variants of the "Xpress" algorithm used for hibernation files, Windows Updates, and the Windows Imaging Format (WIM) files used by the Windows installer. The fourth algorithm, LZX, is used in Microsoft's CAB archives, and it's also an option for WIM. The different algorithms each offer different size/space trade-offs. These join the LZNT1 algorithm that's more suitable for general data compression."
Oczywiście najpierw napisałem jak jest a dopiero później poszukałem artykułu dla niedowiarków
Chodzi o kompresowanie wykonywalnych plików. Co wiele firm (i MS) i tak robiło wcześniej, tylko na poziomie tworzenia oprogramowania.
Jarek Duda, 20 marca 2015, 23:20
Przy szybkiej kompresji, nawet w RAMie może bardziej się opłacać trzymać skompresowane, jak w przypadku kompresji tekstur: http://en.wikipedia.org/wiki/Texture_compression
Szczególnie przy rozwoju sprzętowej - może warto kompresować nawet np. komunikację między CPU i GPU ...
Astroboy, 20 marca 2015, 23:32
Dla mnie to niezbyt rozsądny pomysł. Dlaczego niby system plików nie miałby odpowiadać za blokadę treści pornograficznych?
Uważam, że nie tędy droga. Jarku, ten pomysł nie przerzuca odpowiedzialności na procesory.
"Przy szybkiej kompresji, nawet w RAMie może bardziej się opłacać trzymać skompresowane. Szczególnie przy rozwoju sprzętowej."
Jarek, producenci procesorów przy takim podejściu już zacierają ręce.
Jarek Duda, 12 czerwca 2015, 10:00
Apple też się odchudza: http://thenextweb.com/apple/2015/06/09/app-thinning-in-ios-9-might-finally-mean-your-16gb-iphone-isnt-always-out-of-space/
obiecują zmniejszyć z 4.6 do 1.3 GB - dość ostro.
Jednym z czynników jest ich nowy kompresor: LZFSE, czyli Lempel Ziv Finite State Entropy, gdzie to FSE to już nie standardowy Huffman czy kodowanie arytmetyczne, tylko wspomniany ANS: https://github.com/Cyan4973/FiniteStateEntropy
Twierdzą że LZFSE jest 3x szybszy, dając lepszą kompresję od standardowego ZLIB. ANS niedługo spotkamy też w grach ( http://cbloomrants.blogspot.de/2015/05/05-09-15-oodle-lzna.html ), kompresji DNA (CRAM 3.0: http://www.ebi.ac.uk/ena/software/cram-toolkit ) i wielu innych miejscach (np. https://github.com/Cyan4973/zstd czy https://sites.google.com/site/powturbo/ ).
Astroboy, 12 czerwca 2015, 16:17
W tym konteście działający Linux (jądro) wygląda jakoś dziwnie; wciąż mieści się chyba na dyskietce.
Jajcenty, 12 czerwca 2015, 16:43
Nie. Od lat się już nie mieści. Oczywiście możesz sobie przykroić i pewnie da się zmieścić. Się składa, że właśnie od kolegów dostałem brand noje Debian:
Astroboy, 12 czerwca 2015, 16:56
Niech będzie, dwie dyskietki z hakiem…
Pewnie wpierdzielone elementy zewnętrznego sterownika "nv". 
Jajcenty, 12 czerwca 2015, 17:12
Nie umiem powiedzieć co tam jest. Od lat nie skompilowałem sobie jądra. Jednak branie pod uwagę tylko jądra bez modułów to trochę jak podawanie długości penisa z kręgosłupem
. Potrzebujemy też /bin oraz /usr/bin. Walka (Win vs Lin) na rozmiary będzie długa i wyniszczająca.
Astroboy, 12 czerwca 2015, 17:59
Niekoniecznie. Tuner satelitarny sąsiada (naprawiłem gadzinie
) chodzi pod Linuxem (całkiem sympatyczne OSD). Spróbuj tam postawić jakiegoś windowza. 
Edit: oczywiście, by nie wychodziło, że to, o czym pisze Jarek nie ma sensu (bo ma): vmlinuz to od giezzipowanego vmlinuxa, ale ma to już tyle lat, że szkoda gadać.
Jarek Duda, 13 czerwca 2015, 00:08
Owszem giezip to prehistoria (Huffman) - proponuję porównać sobie z czymś na ANS, np. (LZ+tANS jak LZFSE Apple) https://sites.google.com/site/powturbo/
Krzychoo, 13 czerwca 2015, 00:30
Jest jakiś kompresor ANS na winde?