Torchlight - Diablo I ?

W dniu dzisiejszym odpaliłem grę Torchlight. Niby kiepska grafika i nic innowacyjnego. Interfejs też niezbyt czytelny. Jednak ta gra ma kilka zalet:
- Nowe Diablo I
- Muzyka jak w Diablo I
- Miodność
- RPG
- Troszkę zapożyczeń z WoW
Jak i wad:
- Brak możliwości obracania kamery
- Wątpliwa czytelność interfejsu
- Brak realizmu... ale może to zaleta?
Ogólnie - polecam. Chyba sobie ją kupię - na razie gram w demko ze steam'a :)

Windows 7 RC1

Dzisiaj wrzucę na ruszt windowsa 7. Zapewne w necie znajduje się więcej informacji na ten temat (jak również obrazki :D ).
Zalety Windows 7:
- jądro podobne do visty
- poprawiona obsługa sterowników względem visty
- poprawiona kontrola bezpieczeństwa (UAC) - ale nadal dalego do ideału (takim ideałem był dla mnie zawsze program Tiny Personal Firewall)
- w końcu Microsoft pomyślał o użytkownikach i poprawił interfejs użytkownika zamiast marnować czas na ładny jego wygląd
Wady Windows 7:
- większe wymagania niż XP (kwestia sporna)
- zapewne cena
- ikonki w tray'u doprowadzają mnie do wściekłości

Czy warto? TAK :)

Dobra rada

Czytając dzisiaj dokumentację wpadłem na proste stwierdzenie - proste, ale bardzo wartościowe:
Jeśli spodziewasz się wyjątku - obsłuż przyczynę a nie wyjątek.

Co mnie wkurza w systemie plików

Witam,

Dzisiaj chciałbym napisać, co mi nie odpowiada w popularnych systemach plików - mam tutaj na myśli te, z którymi się na co dzień spotykam (windows, solaris, linux - przeważnie fat,ntfs,ext2/3,reiserfs). Z tego co się orientuję, to ograniczenie leży po stronie systemu, a raczej logiki systemu plików.

Otóż chciałbym stworzyć jakąś aplikację - kod źródłowy miałby leżeć w /src. Plik główny miałby się nazywać main.src. Ale kod miałby się odwoływać do deklaracji a implementacje byłyby położone w main.src/implementacja.src.

Otóż popełniam w mojej logice 2 poważne błędy:

1) Nazwa pliku... czym ona jest?

2) Jeśli mówimy, że coś jest w jakimś większym kontenerze to jest to plik w katalogu.

Moim zdaniem dostęp logiczny do obiektu odbywający się po jego nazwie jest błędny (dobrym rozwiązaniem jest HTML, gdzie obiekty mają swoją nieunikalną nazwę i unikalny ID). To jest błąd leżący w założeniach tego, jak wyglądają systemy plików.

Błędem jest również założenie, że mogę mieć plik i katalog o tej samej nazwie - tego zrobić nie mogę. Dostęp odbywa się po nazwie (nie po ID) więc otwierając c:\windows otwieram.... no właśnie... obiekt o nazwie c:\windows.

Jak ja to widzę...

System plików powinien się składać z fizycznych "grup danych" zawierających wiele jednostek logicznych powiązanych ze sobą w jakiś użyteczny sposób. Wewnątrz takiej grupy powinny istnieć obiekty logiczne posiadające własne unikalne identyfikatory (unikalność powinna być zapewniona w obrębie jednego systemu plików, t.j. w obrębie partycji logicznej, lub też w obrębie grupy danych). Niezależnie od tego powinna istnieć struktura logiczna opisująca nasze obiekty logiczne. Powinna zawierać grupy obiektów określając je po ich identyfikatorach. Problem: Jak identyfikować grupy obiektów? Najlepiej chyba aby miały formę "tagów" przypisywanych do obiektów logicznych (tyle, że atrybut nie byłby przypisany do pliku ale plik do atrybutu).

Problem: Oznaczałoby to zupełnie nowe podejście do plików - odwołanie do kontenera danych odbywałoby się poprzez podanie unikalnego identyfikatora systemu plików(obiektów?)+identyfikatora obiektu (który jest unikalny w obrębie systemu plików). Alternatywnie możnaby się odwoływać do jakiejś grupy obiektów w celu otrzymania ich listy.

Do tego dorzućmy ochronę - system un*xowy się sprawdził - więc można tego użyć.

Zaleta: Możnaby tworzyć kilka obiektów o tych samych nazwach.

Wada: Duża ilość grup.

Wada: Nazwa obiektu musiałaby być gdzieś osobno trzymana.

Wada: Nie wspomniałem o fizycznych danych - to byłaby oddzielna warstwa.

Podsumowując:

Widzę system danych jako 3 warstwy: warstwa fizyczna (zbliżona do obecnej), warstwa logiczna trzymająca dane oraz warstwa logiczna opisująca dane.

Warstwa fizyczna:

Bloki, cylindry, sektory, itd. pogrupowane w większe grupy fizyczne. Grupowanie możnaby np. wykonać względem szybkości dostępu do danych i ryzyka utraty danych. Odwołanie do danych może się odbywać poprzez podanie ID grupy+numeru jednostki alokacji.

Warstwa logiczna odpowiedzialna za trzymanie danych:

Zależna od warstwy fizycznej.

Każdy obiekt logiczny posiada rodzica. Każdy obiekt logiczny może posiadać dzieci. Tak oto załatwiliśmy strawę kontenerów obiektów (katalogów/folderów).

Każdy obiekt posiada właściciela.

Każdy obiekt posiada opis uprawnień dla właściciela (niech to będzie x bitów).

Możnaby jeszcze dodać standardowe atrybuty trzymane w tej warstwie - chociaż to już jest ryzykowne.

Warstwa logiczna opisu danych:

Zawiera grupy z ich nazwami, właścicielami oraz uprawnieniami (x bitów). Właściciel powinien tutaj stanowić grupę użytkowników.

Zawiera listę ID obiektów logicznych powiązanych z daną grupą.

Tagi możnaby podzielić na konfigurowalne przez użytkownika oraz przypisane na stałe do obiektów (to już niestety odejście od standardowego podejścia do plików).

Potencjalne problemy:

Dane dzielone między 2 i więcej bloki logiczne/fizyczne.

Przykładowy dostęp do plików gry XYZ:

Pobierz pliki posiadające tag XYZ => lista ID.

Pobierz pliki posiadające tag 'grafika' pomiędzy otrzymanymi ID.

Pobierz zależności rodzic/dziecko obiektów i pobierz dalej dane jak w standardowo używanych systemach plików.

Przykładowe wyszukanie dokumentów przez użytkownika:

Wyszukaj pliki które są moje i które zostały ściągnięte aplikacją "przeglądarka".

Dodatkowo szukaj plików o jakiejś nazwie.

Jeśli ktoś przypadkiem to czyta to jestem ciekaw czy będą do tej wizji jakieś uwagi :)