Użytkownik "Marek" napisał w wiadomości grup
On Sun, 21 Sep 2014 14:13:27 +0200, Alf/red/ <f...@u...waw.pl>
>> No to przyznaję: jeśli nie odróżniasz wczytania startu maszyny (z
>> czegokolwiek) od zapisywalnych filesystemów do pracy (na
czymkolwiek
>> innym: pamięć, dysk sieciowy, inne dyski), to faktycznie na
tasiemce nie
>> można zainstalować systemu operacyjnego. Ale to błędne
ograniczenie. W

>Wywód nie na temat bo NIE dysjutujemy o boot'cie systemu. Enel.
>pisząc "instalacja na tasiemce" zasugerował używanie takiej
>instalacji jako fs, o ile teoretycznie można by przez fuse zrobić
>translacje dla VFSa i zamontować taki fs, to implementacja
>fopen/fseek byłaby absurdalnie wolna i słabo użyteczna. Jeśli windows
>ti potrafi to gratuluję postępu.

Jesli NIE potrafi, to znak ze w systemie sa zawarte bzdurne
ograniczenia.

Wspolczesny system wymaga urzadzenia blokowego ze swobodnym dostepem,
ale jak juz takie zorganizujemy, to nie widze powodu aby mial cos
sprawdzac i odmawiac pracy. Mniejsza o absurdalna szybkosc -
uzytkownik tak zrobil, to widac tak chce.

Natomiast wspolczesny naped tasmy chyba tego nie umozliwia, nie mozna
tak sobie w srodku zapisu danych zmodyfikowac.
Moze jakby tak kazdy sektor jako osobny plik na tasmie ... moze nawet
nie sektor tylko blok np o dlugosci 1MB...

J.

do góry

J.F. wrote:


> Natomiast wspolczesny naped tasmy chyba tego nie umozliwia, nie mozna
> tak sobie w srodku zapisu danych zmodyfikowac.
> Moze jakby tak kazdy sektor jako osobny plik na tasmie ... moze nawet
> nie sektor tylko blok np o dlugosci 1MB...
>
możnaby przy modyfikacji kasować sektor i zapisywać nową wersję na
końcu :)

--
mst <at> gazeta <.> pl
"-Mam lęk gruntu! -Chyba wysokości?
-Wiem co mówię. To grunt zabija!" T.Pratchett

do góry

"J.F." 541fe37f$0$26836$6...@n...neostrada.pl

> Jesli NIE potrafi, to znak ze w systemie
> sa zawarte bzdurne ograniczenia.

Niby tak, ale żaden system aż taki nie
jest -- masa bakapów była (może nawet
jest nadal) budowana na jednym pliku,
choćby na taśmach.

> Wspolczesny system wymaga urzadzenia blokowego ze swobodnym dostepem, ale jak juz
takie zorganizujemy, to nie widze powodu aby
> mial cos sprawdzac i odmawiac pracy. Mniejsza o absurdalna szybkosc - uzytkownik
tak zrobil, to widac tak chce.

System może być jednoczęściowy -- wrzucamy go do RAMki, gdzie
robimy z nim to, co chcemy. Czy jakikolwiek system pracujący
w RAMce organizuje tę RAMkę jako FS? Oczywiście nie -- FS
jest potrzebny dla jusera, nie dla systemu. W szczególności
mamy jeden plik ze SWAPem, nie zaś FS. Mamy masę innych plików,
podobnego zastosowania. ,,Nowe'' wydanie OE (chyba od Wiśty)
nie buduje ,,baz danych'' DeBeiXów, ale każdy m@il traktuje
jak osobny plik; wcześniej OE bazował na DeBeiXach; ale i tak
każdy program buduje własne struktury -- własne quasiFSy.

W szczególności mamy jeden plik ISO z instalką WinZgrozy.
Jeden, co nie znaczy zhomogenizowany. ;)

Możemy to odpalić z penflaszki czy krążka i ,,zainstalować''
WinZgrozę na FSie zbudowanym w RAMce (w RAMdysku) i stamtąd
ów WZ odpalić -- aby WZ przeładował się, gubiąc zupełnie FS
w swych strukturach, jako że FS dla systemu niekoniecznie
jest szczęśliwym rozwiązaniem.

Jak już pisałem -- FS jest dobry dla jusera, jest kompromisem
pomiędzy tym, czego potrzebuje juser i tym, co akceptuje system
operacyjny. Gdyby nie juser -- FS by nie był potrzebny, w każdym
razie nie byłby potrzebny FS w wydaniach stosowanych na co dzień.

> Natomiast wspolczesny naped tasmy chyba tego nie umozliwia, nie mozna

Widziałem niekończące się taśmy zorganizowane jako FS z klastrami.

> tak sobie w srodku zapisu danych zmodyfikowac.
> Moze jakby tak kazdy sektor jako osobny plik na tasmie ... moze nawet nie sektor
tylko blok np o dlugosci 1MB...


Dla OSa lepsze jest gmeranie w ,,pliku'' niż budowanie nowego
pliku przy okazji edytowania. FS rzadko ;) umożliwia edytowanie
gotowego pliku; raczej zezwala na zapisanie wersji poprawiOnej
z ,,jednoczesnym'' skasowaniem wersji poprawiAnej. Dla pracy
OSów -- FS nie jest rozwiązaniem miłym; staje się rozwiązaniem
koniecznym, gdy w grę wchodzi interakcja z juserem.

-=-

Kończyć warto te jałowe dyskusje. Aby udowodnić realność czegoś,
warto czasami zbudować pracujący model tego czegoś -- w tym
wypadku taki model nie miałby przed sobą przyszłości, czyli
praca nad nim dawałaby raczej ;) tylko stratę czasu.

-=-

Co z tego, że WinZgroza instalując się, zapisuje swą pracę
w plikach FS? Instalujemy na FS, po czym robimy jednoczęściowy
obrazek tej kompilacji i bootlołdera ;) ładującego ów zapis
do RAMki komputera. Czy aż trzeba budować to coś, aby wykazać
realność tego czegoś?

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

On Mon, 22 Sep 2014 15:42:52 +0200, "Eneuel Leszek Ciszewski"
<p...@c...fontem.lucida.console> wrote:
> System może być jednoczęściowy -- wrzucamy go do RAMki, gdzie
> robimy z nim to, co chcemy. Czy jakikolwiek system pracujący
> w RAMce organizuje tę RAMkę jako FS? Oczywiście nie -- FS

Tak, fs na dynamicznyn ramdysku, /dev/shm tak dziala. Nowoczesny os
nie potrzebuje hdd, wszystko może być w ram.

> jest potrzebny dla jusera, nie dla systemu.
Zależy, VFS jako abstrakcja jest dostępny dla systemu.

--
Marek

do góry

Użytkownik "Marek" napisał w wiadomości
On Mon, 22 Sep 2014 15:42:52 +0200, "Eneuel Leszek Ciszewski"
>> System może być jednoczęściowy -- wrzucamy go do RAMki, gdzie
>> robimy z nim to, co chcemy. Czy jakikolwiek system pracujący
>> w RAMce organizuje tę RAMkę jako FS? Oczywiście nie -- FS

>Tak, fs na dynamicznyn ramdysku, /dev/shm tak dziala. Nowoczesny os
>nie potrzebuje hdd, wszystko może być w ram.

Ja bym tam rzekl ze nowoczesny system wspoldziala z plikami na dysku.
Oczywiscie nie musi byc to fizyczny HDD, moze byc chocby ramdysk.

Ale moze ja jestem starej daty, moze nowoczesny system nie chce
zadnych plikow, tylko sie laczy z obiektami w chmurze ...

J.

do góry

"J.F." 54203f8b$0$14114$6...@n...neostrada.pl

> Ja bym tam rzekl ze nowoczesny system wspoldziala z plikami na dysku.
> Oczywiscie nie musi byc to fizyczny HDD, moze byc chocby ramdysk.

System operacyjny potrafi dogadać się z FSem.

> Ale moze ja jestem starej daty, moze nowoczesny system nie chce zadnych plikow,
tylko sie laczy z obiektami w chmurze ...


"Marek" a...@n...neostrada.pl

> Tak, fs na dynamicznyn ramdysku, /dev/shm tak dziala. Nowoczesny os nie potrzebuje
hdd, wszystko może być w ram.

>> jest potrzebny dla jusera, nie dla systemu.
> Zależy, VFS jako abstrakcja jest dostępny dla systemu.



Chmurne obiekty także są (lub choćby mogą być) grupowane w pliki/fajle.
Weź sobie zrzut pamięci -- masz tam FS i podział na pliki?
CPU odwołuje się do pliku, do nazwy, do miejsca w FAT/MFT/itp.?
RAMka jest sklastrowana tak, że ostatni klaster pliku bywa
niepełny? Itd...

SO potrafi współpracować z FSami, które są miłe juserom.
To juser lubi nazwy plików takie jak: 'Bal_u_cioci.MTV'
i nazwy katalogów takie jak: 'Bale'. I juser chce znać
datę zapisu danego pliku.

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

On Sun, 21 Sep 2014 11:13:48 +0200, "Eneuel Leszek Ciszewski"
<p...@c...fontem.lucida.console> wrote:

>
>"Marek" a...@n...neostrada.pl
>
>> Nie o tym była dyskysja.
>
>Podyskutujcie raczej o tym, że za 3 dychy można mieć
>64 GB klasy 10 na mikroSD od Alibaby i 40 rozbójników.
>Widać wyraźnie, że tasiemka musiałaby być długa, na
>dodatek szybko by porwała się -

Maszyna Turinga nie ma problemow z tasma :)

A.L.

P.S. Widze ze Koledy nie widzieli nigdy tasmy papieowej na oczy

do góry

Użytkownik "masti" napisał w wiadomości grup
dyskusyjnych:lvoqot$mem$...@d...me...
J.F. wrote:
>> Natomiast wspolczesny naped tasmy chyba tego nie umozliwia, nie
>> mozna
>> tak sobie w srodku zapisu danych zmodyfikowac.
>> Moze jakby tak kazdy sektor jako osobny plik na tasmie ... moze
>> nawet
>> nie sektor tylko blok np o dlugosci 1MB...
>
>możnaby przy modyfikacji kasować sektor i zapisywać nową wersję na
>końcu :)

Moznaby, ale jak potem odszukac wlasciwy sektor - tablice alokacji
jakas na poczatku, czy numer sektora na jego poczatku i czytac
wszystkie po kolei ? :-)

W sumie to niekoniecznie sektor, mniejsze pliki mozna by w calosci
trzymac.

J.

do góry

"A.L." l...@4...com

>>dodatek szybko by porwała się -

> Maszyna Turinga nie ma problemow z tasma :)

Jak to mówią -- wszystko do czasu. ;)
(tu akurat do wyjaśnienia, czym jest ta maszyna)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

J.F. wrote:

> Użytkownik "masti" napisał w wiadomości grup
> dyskusyjnych:lvoqot$mem$...@d...me...
> J.F. wrote:
>>> Natomiast wspolczesny naped tasmy chyba tego nie umozliwia, nie
>>> mozna
>>> tak sobie w srodku zapisu danych zmodyfikowac.
>>> Moze jakby tak kazdy sektor jako osobny plik na tasmie ... moze
>>> nawet
>>> nie sektor tylko blok np o dlugosci 1MB...
>>
>>możnaby przy modyfikacji kasować sektor i zapisywać nową wersję na
>>końcu :)
>
> Moznaby, ale jak potem odszukac wlasciwy sektor - tablice alokacji
> jakas na poczatku, czy numer sektora na jego poczatku i czytac
> wszystkie po kolei ? :-)

czytać jak na tasiemkach magnetycznych.
sensu to nie ma ale w sumie byłaby fajna zabawa to zaimplementować :)


--
mst <at> gazeta <.> pl
"-Mam lęk gruntu! -Chyba wysokości?
-Wiem co mówię. To grunt zabija!" T.Pratchett

do góry