RSSOwl 2.oM9 Public Preview
jak w temacie… dostępna wersja określona jako 'na tyle stabilna aby oficjalnie nazwać ją publiczną’ (;
korzystam z night buildów od dłuższego czasu i nie mam specjalnie problemów. z ważniejszych poprawek w public preview zauważyłem lepszą obsługę tabów. za największe zalety uważam – olbrzymią konfigrowalność aka kastomizacja [którekolwiek by nie było bardziej po polskiemu q: ], żabisty search – naprawdę szybki i obsługuje wildcardy, szybkość, możliwość konfiguracji filtrów na newsy… uch – multum dodatków dla uzależnionych od newsów (;
tips: przykład jak szybko znaleźć informacje na interesujący temat. tworzy się nowy bookmark i podczas wpisywania nie trzeba znać żadnego linka – podaje się słowo klucz. na następnym ekranie jest do wyboru kilka silników wyszukiwarek – m.in. google news search. i tak w kilka kliknięć tworzy się własny widok z informacjami na interesujący temat. dodając do tego możliwość tworzenia 'zbiorów’ w których mogą znajdować się newsy z różnych źródeł – można mieć posortowane po zawartości a nie pochodzeniu.
MISTRZ (:
czemu winda zjada tyle miejsca na dysq?
bardzo często w argumentacji przeciw windowsom pada oskarżenie o to, że windows jest potwornie zasobożerny co do RAM i HDD. o pamięci było już jakiś czas temu – a więc czas na obalenie kolejnego mitu – pochłanianie miejsca na dysq.
na blogu ekipy windows 7 pojawił się świetny art poświęcony w całości tematowi miejsca na dysq: disk space – i zaliczam go do serii „lektura obowiązkowa”. zastanawiam się czy go przetłumaczyć na polski – co o tym sądzicie?
w skrócie co tam można znaleźć:
najczęstszym wytłumaczeniem ilości miejsca zajmowanego przez windę jest text w stylu 'przecież jest nowa era i dobie 1T dysków nie trzeba się martwić’. takie sformułowanie nie pada w tym arcie – co od razu daje wielkiego plusa i wytrąca broń z ręki zaciętych geeków, którzy będą walczyć do ostatniego niepotrzebnie zajętego bajta na dysq. osobiście o ile zgadzam się z takim stwierdzeniem, o tyle również uważam, że jako argument trąci lamerstwem.
w zamian znajdzie się tam tabelka pokazująca który komponent ile na dysq zajmuje:
jest też ciekawy opis funkcji katalogu WinSxS, który raportowany jest przez system jako wielo-gigabajtowy folder [u mnie np. ~6GB]. w rzeczywistości jest on pełen hardlinków, a więc de facto zajmuje koło 4ooMB. na temat samego offline patchingu trzeba by kiedyś skrobnąć – tym bardziej, że jak widzę nie łatwo to wygooglać.
bardzo fajny tips, o którym nie wiedziałem: zainstalowałeś SP1? nie będziesz odinstalowywał? uruchom vsp1cln.exe – który czyści backup z przed SP. mi zaoszczędził prawie 9ooMB.
na koniec można znaleźć informacje na temat tego, czego można spodziewać się w w7 – i tak inżynierowie obiecują zmianę modelu instalacji sterowników [prawie 1GB to sterowniki drukarek!] – sugeruje się aby większość była tylko on-line co imho jest dobrym posunięciem… o ile będzie opcja instalacji w stylu 'add all drivers offline’ – czy to na samej płycie, czy możliwość zassania takiej paczki i instalacji. mimo wszystko nie wszyscy mają pełny dostęp do netu. pojawiają się informacje o zmianie sposobu przechowywania hiberfil.sys oraz lepszy interfejs do zarządzania zajętością miejsca przez restore pointy.
brzmi smacznie.
btw: o ile sprawdzałem, standardowe instalacje najpopularniejszych dystrybucji linuxowych – ubuntum, fedora czy openSUSE – zajmują na dzień-dobry więcej miejsca niż vista. podstawową różnicą jest fakt, że linux pozwala na bardzo granularny wybór instalowanych ficzerów. odinstalowanie z visty niemal wszystkiego w 'programs and features’ nie spowoduje, że system stanie się malutki i leciutki. ale jeśli ktoś uważa się za geeka i prawdziwego twardziela – może skorzystać z aplikacji odchudzających, które przede-wszystkim wycinają sterowniki, i wyłączyć restore pointy – to powinno zmniejszyć footprint o jakieś 5o%.
btw2: w jednym z projektów dla klienta zostałem poproszony o odchudzenie obrazu. pierwszym miejscem w jakie sięgnąłem był vLite. problem polega na tym że przy instalacji pojawia się info „non for commercial use”. napisałem do twórcy i napisał, że emes nie wspiera tego rozwiązania i w zasadzie jego stosowanie łamie licencję. upewniłem się w emesach – i faktycznie przy zastosowaniu produkcyjnym, jak to się ładnie określa „nie jest wspierany” – co przy takich projektach oznacza po prostu „nie używać”. ręczne wyrzucenie sterowników – a więc de facto zrobienie tego, co m.in. robi vLite – nie jest takie trywialne. imho – emes mógłby qpić vLite i dołączyć go oficjalnie do pakietu MDOP.