W dniu 07.05.2011 20:22, Sebastian Biały pisze:
> Ale fat to same problemy: co można żądać od systemu plików który ma coś
> koło 30 lat i jest napisany jako klon fs z CP/M a potem wykupiony przez
> firmę piszącą głównie BASICe na 8-bitów i obarczony jakimiś kretyńskimi
> problemami prawnymi z patentami? Niestety historia informatyki to
> głównie wybieranie debilnych rozwiązań i zabetonowaniaa ich potem jako
> "standardy przemysłowe"... a MS całkiem nieźle żyje z faktu że nikt nie
> implementuje nic innego w urządzeniach.
>
> Dobra, wracam do obmyślania SeboFS for EEPROM :P

Jeśli potrzebny jest tylko sekwencyjny odczyt i zapis bez częstego
używania seek, to może coś w stylu uproszczonego systemu plików z
ATARI800XL ? Nie było tam tablicy alokacji zbiorów, tylko prosta lista
jednokierunkowa. W pozycji katalogu był wskaźnik na pierwszy sektor
pliku, a ostatnie dwa bajty każdego sektora były wskaźnikiem następnego
sektora. Ostatni sektor miał wskaźnik 0xffff. Rozwiązanie proste jak
budowa cepa :-) Zalety: mała ilość zasobów (nie trzeba pamiętać sektora
FAT), przy małych zasobach prędkość odczytu trochę szybsza niż przy FAT.
Wady: Przy zapisie wolny sektor musi być poszukiwany sekwencyjnie na
podstawie ostatnich bajtów 0x0000 (w ATARI była dodatkowa bitowa mapa
zajętości sektorów). Wykonanie seek do przodu wymaga w zasadzie
sekwencyjnego odczytania kolejnych sektorów pliku aż dojdziemy do
zadanej pozycji wskaźnika pliku. Seek do tyłu wymaga wycofania się do
pierwszego sektora pliku i dalej jak w przypadku seek do przodu.
Skasowanie pliku wymaga wyzerowania wskaźników we wszystkich sektorach
należących do pliku (czyli trwa ponad dwa razy dłużej niż przeczytanie
całego pliku).

Pozdrawiam
Grzegorz

do góry

On 2011-05-07 21:01, Grzegorz Kurczyk wrote:
>> Dobra, wracam do obmyślania SeboFS for EEPROM :P
> Jeśli potrzebny jest tylko sekwencyjny odczyt i zapis bez częstego
> używania seek, to może coś w stylu uproszczonego systemu plików z
> ATARI800XL ?

Zastanawiam się nad FS który nie musi być ani szybki ani wypasiony.
Potrzebuje trzymać konfiguracje pewnego urządzenia i nie przejmować się
zmianami firmware. To tylko taka wartwa abstrakcji. Więc każde
rozwiązanie będzie dobre. Rzecz jednak w tym, że jesli już je zrobie to
było by miło mieć "driver" do testowania pracujacy na normalnym, dużym
OS (a więc np. fuse). Może pomyśle i coś naskrobie w LGPL w przyszłości.
Rozwiązanie z listą jedno/dwu kierunkową jest ok i zapewne będę wlaśnie
coś w tym guście implementował.

do góry

On Sat, 07 May 2011 21:00:51 +0200, Sebastian Biały wrote:
>On 2011-05-07 20:49, J.F. wrote:
>> Trudno wymagac od klienta zeby sobie zainstalowal malego linuxa do
>> transferu plikow :-)
>Za to bardzo łatwo żeby zainstalował dużego windowsa do transferu plików
>... ;) Świat jest przedziwny ...

Klient go juz ma i uzywa, nawet chetnie :-)

>> Czesc "FAT" jest w miare przyzwoita, kretynskie jest tylko doklejenie
>> dlugich nazw plikow.
>A np przezabawna rozdzielczość 2 sekund?

Normalna inzynierska robota. Rozdzielczosc jakas i tak musi byc - cos
jest zlego w dwusekundowej ?
A ile KB ma pod unixem funkcja konwertujaca date na date .. czytalna
dla czlowieka ? :-)

>W czasie kiedy MS wciskał swój
>prymitywny klon CP/M do IBMów świat wiedział już coś o np. koncepcji
>security choćby z Unixa. To nie było przyzwoite tylko pojechanie po
>bandzie najmniejszej lini oporu. Prawa dostepu?

No fakt - nie pomysleli. Aczkolwiek .. to jednak komputer _osobisty_.

>Multithreading?

Ale to chyba nie zarzut do czesci dyskowej ? FAT jak najbardziej
pozwala .. po odpowiednim poblokowaniu w systemie.

>E Panie,
>to tylko nastepny klon CP/M przepisywany przez specjalistów od BASICa.

Taki mial byc. Jesli mam pretensje to dopiero od wersji 3.0 -
faktycznie mogliby juz lepiej pomyslec.

>>> Dobra, wracam do obmyślania SeboFS for EEPROM :P
>> Duzy ruch w danych ? Moze CD ?
>ISO jest read-only

po stronie czytajacego. Po stronie zapisujacego mozna pomyslec.
Zalezy od specyfiki urzadzenia.

J.

do góry

On 2011-05-07 21:15, J.F. wrote:
>> A np przezabawna rozdzielczość 2 sekund?
> Normalna inzynierska robota. Rozdzielczosc jakas i tak musi byc - cos
> jest zlego w dwusekundowej ?

FAT chyba wspierał 10ms ale nie wiem czy oprogramowanie miało dostęp tak
po prostu. A upierdliwośc polega na tym ze kompilując plik nie wiadomo
czy powstał z tego źrodła czy nie.

> Prawa dostepu?
> No fakt - nie pomysleli. Aczkolwiek .. to jednak komputer _osobisty_.

To charakterystyczny brak wyobraźni. 4 lata później Amiga miala system z
preemptive multitaskingiem, gui i masą innowacji (acz fakt, bez praw
dostepu). A "profesjonaliści" dalej kopiowali pliki z lewego na prawy
panel na niebieskim tle czując że tak własnie *musi* być, bo jak by
mialo byc inaczej?

>> Multithreading?
> Ale to chyba nie zarzut do czesci dyskowej ? FAT jak najbardziej
> pozwala .. po odpowiednim poblokowaniu w systemie.

Stop-the-world multithreading to jest rozwiązanie którym da się wszystko
załatać. Cooperative/Mutexed multitasking to żaden multitasking tylko
workaround ...

do góry

On Sat, 07 May 2011 21:01:48 +0200, Grzegorz Kurczyk wrote:
>Jeśli potrzebny jest tylko sekwencyjny odczyt i zapis bez częstego
>używania seek, to może coś w stylu uproszczonego systemu plików z
>ATARI800XL ? Nie było tam tablicy alokacji zbiorów, tylko prosta lista
>jednokierunkowa. W pozycji katalogu był wskaźnik na pierwszy sektor
>pliku, a ostatnie dwa bajty każdego sektora były wskaźnikiem następnego
>sektora.

Trzy bajty ? Tak mi sie cos kojarzy.

>Wykonanie seek do przodu wymaga w zasadzie
>sekwencyjnego odczytania kolejnych sektorów pliku aż dojdziemy do
>zadanej pozycji wskaźnika pliku. Seek do tyłu wymaga wycofania się do
>pierwszego sektora pliku i dalej jak w przypadku seek do przodu.

chcialem jeszcze dodac ze wymaga dzielenia przez 126 czy 125 ..
ale w sumie nie - jak juz czytamy po jednym sektorze, to mozna i
odejmowac.

podobny blad ma w sumie i fat - lista tez jest liniowa i trzeba
liniowo przeszukiwac. Tylko troche mniej czytania z dysku.
Ale jak ktos ma baze na kilkaset GB w jednym pliku na fat32 ..
niewesolo, jesli system sobie z tym nie radzi.
Unix jakos jednak lepiej przemyslany.

A swoja droga .. jesli to eeprom przylaczony magistralowo, to w sumie
zadna roznica czy czytac dwa ostatnie bajty z kazdego "sektora" czy z
"sektora FAT"

>Skasowanie pliku wymaga wyzerowania wskaźników we wszystkich sektorach
>należących do pliku (czyli trwa ponad dwa razy dłużej niż przeczytanie
>całego pliku).

no nie - wystarczy tylko poprawic te bitowa mape alokacji.
Ale .. trzeba wszystko przeczytac, zeby ustalic zwalniane sektory :-)

J.

do góry

Pan Sebastian Biały profesjonalnie opisał historię komputerów:

>> Prawa dostepu?
>> No fakt - nie pomysleli. Aczkolwiek .. to jednak komputer _osobisty_.
>
> To charakterystyczny brak wyobraźni. 4 lata później Amiga miala system
> z preemptive multitaskingiem, gui i masą innowacji (acz fakt, bez praw
> dostepu).

No i dzięki genialnej wyobraźni jej twórców Amiga podbiła światowe rynki.
A tak bardziej poważnie -- to jednak IBM wykazał się dobrą wyobraźnią
obstalowując taki a nie inny system do swojego hardware. Ja tam DOSa
lubiłem i cieszyłem się, że mogę robić ze sprzętem co tylko zechcę.

> A "profesjonaliści" dalej kopiowali pliki z lewego na prawy panel na
> niebieskim tle czując że tak własnie *musi* być, bo jak by mialo byc
> inaczej?

Dalej kopiowali? Norton Commander powstał dopiero *sześć lat później*.
I był jednym z lepszych wynalazków w zakresie interfejsu użytkownika.
Do dzisiaj używanym (choć jest tyle innych sposobów kopiowania).

--
Jarek

do góry

On 2011-05-07 21:45, Jarosław Sokołowski wrote:
> No i dzięki genialnej wyobraźni jej twórców Amiga podbiła światowe rynki.

Pomysły w niej zaimplementowane podbiły swiatowe rynki ... 10 lat
później razem z *innowacyjnym* Win95 (przypominam, ze mam na myśli
desktopy, jak by ktoś chciał sięgać kto pierwszy użył preemptive to
niewyluczone że sięgnie aż do misji Apollo ...).

> A tak bardziej poważnie -- to jednak IBM wykazał się dobrą wyobraźnią
> obstalowując taki a nie inny system do swojego hardware.

To raczej był ukłon w kierunku legacy-users którzy bez prompta CP/M nie
potrafili pracować i mieli swoje "najlepsze na swiecie" aplikacjie
"prawie dzialające na 8086 tylko trzeba je troche przepisać z 8080/z80".
Zaproponowali system tani, modularny i "prawie" zgodny z pierdyliardem
aplikacji. Kto by tego nie kupił?

>> A "profesjonaliści" dalej kopiowali pliki z lewego na prawy panel na
>> niebieskim tle czując że tak własnie *musi* być, bo jak by mialo byc
>> inaczej?

> Dalej kopiowali? Norton Commander powstał dopiero *sześć lat później*.
> I był jednym z lepszych wynalazków w zakresie interfejsu użytkownika.
> Do dzisiaj używanym (choć jest tyle innych sposobów kopiowania).

:) Przecież mam na mysli że jak reszta świata zajmowała się poważnymi
problemami to "profesjonaliści" dalej używali beznadziejnego klona CP/M
ktory po 10 latach ewolucji z kawalka kodu do obsługi FAT i lini poleceń
stal się kawalkiem kodu do obsługi FAT i lini poleceń o wyższym numerku
i kolorowym programem do kopiowania z lewej na prawą.

PS. Ciekawostka: do dzisiaj nawet w Win7 jest edlin ...

do góry

Pan Sebastian Biały napisał:

>> No i dzięki genialnej wyobraźni jej twórców Amiga podbiła światowe rynki.
>
> Pomysły w niej zaimplementowane podbiły swiatowe rynki ... 10 lat
> później razem z *innowacyjnym* Win95 (przypominam, ze mam na myśli
> desktopy, jak by ktoś chciał sięgać kto pierwszy użył preemptive to
> niewyluczone że sięgnie aż do misji Apollo ...).

Czy to "innowacyjnym" miało być ironią? Jeśli tak, to jakoś nie najmądrzej
wyszło. Rok 1995 to mniej więcej wtedy, kiedy rozwój techniki pozwolił na
sensowną realizację "takich pomysłów". Wcześniej to na desktopach można
było to traktować jako zabawkę (miałem z takim systemem do czynienia, nie
z Amigą, a z tym co przetrwał do dziś -- śmiechu warte).

>> A tak bardziej poważnie -- to jednak IBM wykazał się dobrą wyobraźnią
>> obstalowując taki a nie inny system do swojego hardware.
>
> To raczej był ukłon w kierunku legacy-users którzy bez prompta CP/M nie
> potrafili pracować i mieli swoje "najlepsze na swiecie" aplikacjie
> "prawie dzialające na 8086 tylko trzeba je troche przepisać z 8080/z80".
> Zaproponowali system tani, modularny i "prawie" zgodny z pierdyliardem
> aplikacji.

Raczej w stronę mainfrejmiarzy i podobnymch. Mnie tam średnio obchodziło,
czy tam wsadzili z80, 8080, 8088 czy jeszcze coś innego. Ważne, że można
było skompilować program tak samo jak na dużym sprzęcie. I jak komputer
miał 640kB RAMu, to znaczy, że tyle miał -- bo DOS zajmował niewiele.

> Kto by tego nie kupił?

No, kupowali przecież.

>>> A "profesjonaliści" dalej kopiowali pliki z lewego na prawy panel na
>>> niebieskim tle czując że tak własnie *musi* być, bo jak by mialo byc
>>> inaczej?
>
>> Dalej kopiowali? Norton Commander powstał dopiero *sześć lat później*.
>> I był jednym z lepszych wynalazków w zakresie interfejsu użytkownika.
>> Do dzisiaj używanym (choć jest tyle innych sposobów kopiowania).
>
>:) Przecież mam na mysli że jak reszta świata zajmowała się poważnymi
> problemami

Jakież to były poważne problemy reszty świata?

> to "profesjonaliści" dalej używali beznadziejnego klona CP/M ktory po
> 10 latach ewolucji z kawalka kodu do obsługi FAT i lini poleceń stal
> się kawalkiem kodu do obsługi FAT i lini poleceń o wyższym numerku

Co w tym złego?

> i kolorowym programem do kopiowania z lewej na prawą.

To przecież całkiem inny program.

> PS. Ciekawostka: do dzisiaj nawet w Win7 jest edlin ...

To też źle?

--
Jarek

do góry

On 2011-05-07 22:22, Jarosław Sokołowski wrote:
>> Pomysły w niej zaimplementowane podbiły swiatowe rynki ... 10 lat
>> później razem z *innowacyjnym* Win95 (przypominam, ze mam na myśli
>> desktopy, jak by ktoś chciał sięgać kto pierwszy użył preemptive to
>> niewyluczone że sięgnie aż do misji Apollo ...).

> Czy to "innowacyjnym" miało być ironią? Jeśli tak, to jakoś nie najmądrzej
> wyszło. Rok 1995 to mniej więcej wtedy, kiedy rozwój techniki pozwolił na
> sensowną realizację "takich pomysłów".

Możesz uzasadnić? Akurat to swierdzenie jest o tyle zabawne że np.
preemptive-multitasking działa całkiem sprawnie na 8 bitowych
mikrokontrolerach. Stwierdzenie że dopiero technologia z okolic Pentium
mogła to pociągnąć jest bzdurą na co jest masa przykładów historycznych
i współczesnych.

> Wcześniej to na desktopach można
> było to traktować jako zabawkę (miałem z takim systemem do czynienia, nie
> z Amigą, a z tym co przetrwał do dziś -- śmiechu warte).

Rzecz w tym że na Amidze działało to bardzo dobrze. Na tyle że częśc
ludzi zaczeła negować w ogóle ten ficzer, bo jak to, ich PC nie
potrafią? To pewno jakaś ściema ... Jak na pierwszy desktop z takim
ficzerem była to innowacja pełną gębą. Niestety nie miala CP/M prompt i
8 znaków na nazwę pliku więc nie była "profesjonalna". *Jedynym*
problemem Amigi w okolicy multitaskingu było brak MMU co powodowało
niestabilnośc systemu w przypadku uszkodzenia pamięci innego procesu,
ale był to problem sprzetowy i trudno winić OS. Takie czasy, takie CPU.

> było skompilować program tak samo jak na dużym sprzęcie. I jak komputer
> miał 640kB RAMu, to znaczy, że tyle miał -- bo DOS zajmował niewiele.

Ale jak miał 4MB RAMU to miał 640kB ramu, nie? MS-DOS przodował na rynku
systemów operacyjnych (a raczej api filesystemu z command line) które
nie potrafily nawet do końca wspierać takich prymitywów jak pamięć
skazując programy na rękodzieła i generując tym samym kilka rownoległych
"standardów".

>> :) Przecież mam na mysli że jak reszta świata zajmowała się poważnymi
>> problemami
> Jakież to były poważne problemy reszty świata?

Multitasking. GUI. Abstrakcja sprzetu. Security. Itd.

Natomiast "profesjonaliści" odkrywali kolejne funkcje kradzonych NC i TP ...

>> to "profesjonaliści" dalej używali beznadziejnego klona CP/M ktory po
>> 10 latach ewolucji z kawalka kodu do obsługi FAT i lini poleceń stal
>> się kawalkiem kodu do obsługi FAT i lini poleceń o wyższym numerku
> Co w tym złego?

W braku ewolucji? Nic :) Krokodyle tez podobno już nie bardzo chcą
ewoluować. Osiągnęły *perfekcyjność*.

>> i kolorowym programem do kopiowania z lewej na prawą.
> To przecież całkiem inny program.

A potrafiłbyś pracować bez niego? Przecież MS-DOS nie oferował *nic* z
narzędzi poza przeraźliwie prymitywną linią poleceń wyrwaną z koszmaru
CP/M. Przecież MS-DOS to z grubsza tylko API prymitywnego filesystemu i
command.com.

>> PS. Ciekawostka: do dzisiaj nawet w Win7 jest edlin ...
> To też źle?

To tylko zabawny współcześnie kawalek historii pokazujący jak naprawdę
wyglądały początki DOSa i z jakim g... musieli się użerać ludzie
jedncześnie uważając to za jedyną drogę do przyszlości.

do góry

W dniu 07.05.2011 21:35, J.F. pisze:
> On Sat, 07 May 2011 21:01:48 +0200, Grzegorz Kurczyk wrote:
>> Jeśli potrzebny jest tylko sekwencyjny odczyt i zapis bez częstego
>> używania seek, to może coś w stylu uproszczonego systemu plików z
>> ATARI800XL ? Nie było tam tablicy alokacji zbiorów, tylko prosta lista
>> jednokierunkowa. W pozycji katalogu był wskaźnik na pierwszy sektor
>> pliku, a ostatnie dwa bajty każdego sektora były wskaźnikiem następnego
>> sektora.
>
> Trzy bajty ? Tak mi sie cos kojarzy.

Na dyskietce DD mieściło się coś kole 1500 sektorów więc dwubajtowy
wskaźnik wystarcza z duuuużym zapasem. Ale ma chyba Kolega rację z tym
trzecim bajtem, tyle że on służył do zapamiętywania ilości ważnych
bajtów w sektorze.

>
>> Wykonanie seek do przodu wymaga w zasadzie
>> sekwencyjnego odczytania kolejnych sektorów pliku aż dojdziemy do
>> zadanej pozycji wskaźnika pliku. Seek do tyłu wymaga wycofania się do
>> pierwszego sektora pliku i dalej jak w przypadku seek do przodu.
>
> chcialem jeszcze dodac ze wymaga dzielenia przez 126 czy 125 ..
> ale w sumie nie - jak juz czytamy po jednym sektorze, to mozna i
> odejmowac.
>
> podobny blad ma w sumie i fat - lista tez jest liniowa i trzeba
> liniowo przeszukiwac. Tylko troche mniej czytania z dysku.
> Ale jak ktos ma baze na kilkaset GB w jednym pliku na fat32 ..
> niewesolo, jesli system sobie z tym nie radzi.
> Unix jakos jednak lepiej przemyslany.
>
> A swoja droga .. jesli to eeprom przylaczony magistralowo, to w sumie
> zadna roznica czy czytac dwa ostatnie bajty z kazdego "sektora" czy z
> "sektora FAT"

Przy magistralowej w zasadzie żadna, bo możemy operować na pojedynczych
bajtach. W innym przypadku wypadałoby mieć dwa bufory lub wajhlować
miedzy FATem a danymi. Tyle, że jak mamy swobodny dostęp do każdego
bajtu pamięci masowej, to po co się bawić w system plików. To miało na
celu sensownie obsługiwać urządzenia blokowe.

>
>> Skasowanie pliku wymaga wyzerowania wskaźników we wszystkich sektorach
>> należących do pliku (czyli trwa ponad dwa razy dłużej niż przeczytanie
>> całego pliku).
>
> no nie - wystarczy tylko poprawic te bitowa mape alokacji.
> Ale .. trzeba wszystko przeczytac, zeby ustalic zwalniane sektory :-)

O mapie bitowej pisałem w nawiasie, bo tak było w systemie dyskowym
ATARI i tam wystarczało odznaczyć bity odpowiadające za sektory należące
do kasowanego pliku. Ale na bitach nie da się zrobić listy liniowej ;-)
a co za tym idzie i tak trzeba było przeczytać wszystkie sektory pliku
aby wiedzieć które sektory trzeba zwolnić w mapie bitowej. W
uproszczonej wersji systemu plików bez mapy bitowej trzeba zerować
wskaźniki w każdym sektorze.

Pozdrawiam
Grzegorz

do góry