Pan J.F. napisał:

>> Z tego co pamiętam, w trakcie tworzenia obrazu, pojawiają się
>> ostrzeżenia, że jakaś ścieżka zbyt długa, czy cóś. W tym czasie
>> tworzony jest obraz. Więc gdyby nie plik pośredni, już byłby
>> częściowo wypalony na płycie.
>
> To w swiecie unix, Nero sprawdzal na poczatku.

No to musiał dodatkowo przelecieć po plikach na początku. Unix jak
widac zbyt leniwy na to.

> ale swoja droga - gdzie ten program tworzacy obraz to zapamietuje ?
> Jesli w pamieci ... to grozi brak pamieci i kolejny powod, zeby
> zrobic image.

ISO9660 to strumień. Program go tworzy i może cały czas dopisywć
do pliku, przechowywać w pamięci lub od razu wypalać.

> Hm, ale czy na pewno w swiecie unix tak jest ?
> Moze te ostrzezenia to zanim jeszcze wypluje pierwsze dane ...

Nie, pojawiają się na bieżąco przy braniu kolejnych plików
i dopisywania ich do obrazu.

> a cel widac jakis backupowy - lepiej nagrac dane pod inną nazwą,
> niz nie nagrac wcale :-)

To nawet nie jest tak, że nagra się pod inną nazwą. Ostrzeżenie
dotyczy tego, że gdzieś może zostać źle odczytane. Nie pamiętam
szczegółów, ale w płytologii stosowanej zawsze był niezły bałagan.

--
Jarek

do góry

On Thu, 16 Jul 2020 10:44:24 +0200, Silver Dream !
<s...@n...net> wrote:
> późniejszych, kiedy proces nadal był niewygodny ale przynajmniej
> nie tak

Co jest niewygodne w użyciu mkisofs/path/root |cdrecord?

--
Marek

do góry

On Thu, 16 Jul 2020 11:56:54 +0200, Jarosław
Sokołowski<j...@l...waw.pl> wrote:
> Mam wrażenie, że niektórym w ogóle umykają realia tamtych czasów.
> Żeby nagrać płytę, trzeba było stworzyć jej obraz. A ten obraz

Nie trzeba bylo, zawsze używałem pipe mksisofs| cdrecord

--
Marek

do góry

On Thu, 16 Jul 2020 12:38:26 +0200, "J.F."
<j...@p...onet.pl> wrote:
> Nie pamietam ... nie bylo programow, co nagrywaly bez tego obrazu ?

Oczywiście że były, cdrecord, cdrdao.

--
Marek

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>> Z tego co pamiętam, w trakcie tworzenia obrazu, pojawiają się
>>> ostrzeżenia, że jakaś ścieżka zbyt długa, czy cóś. W tym czasie
>>> tworzony jest obraz. Więc gdyby nie plik pośredni, już byłby
>>> częściowo wypalony na płycie.
>
>> To w swiecie unix, Nero sprawdzal na poczatku.

>No to musiał dodatkowo przelecieć po plikach na początku. Unix jak
>widac zbyt leniwy na to.

Chyba warto, zeby choc powiedziec - sorry, za duzo plikow, nie
zmieszcza sie.

>> ale swoja droga - gdzie ten program tworzacy obraz to zapamietuje ?
>> Jesli w pamieci ... to grozi brak pamieci i kolejny powod, zeby
>> zrobic image.

>ISO9660 to strumień. Program go tworzy i może cały czas dopisywć
>do pliku, przechowywać w pamięci lub od razu wypalać.

Nie ma tam jakiejs tabeli wszystkich plikow ?

Nigdy sie nie wczytywalem, ale tak na szybko
https://web.archive.org/web/20110717142714/http://al
umnus.caltech.edu/~pje/iso9660.html

-jest "Path Table" na poczatku, jakies takie ... nieobowiazkowe ? Ale
jesli ma byc, to trzeba dane przygotowac i zapisac, a chyba nie da sie
tego tak calkiem strumieniowo,

-sa Directory ... jak rozumiem - podobnie jak w unixie niby ciagly
plik z danymi, ale ma sektory poczatkowe tych plikow.
czyli musze odczytac pliki z systemu, zapisac katalog podajac
przyszle miejsce pliku. Niby mozna to zrobic na biezaco, po jednym
pliku ... ale niech sie cos zmieni w katalogach na dysku.
chyba lepiej zapamietac calosc i potem czytac dane z plikow zgodnie
z tym co zapamietane.
To tylko w jednym katalogu ... ale w unixie moze byc duzo plikow w
katalogu.

-taki root Directory ... tam zapisujemy lokalizacje podkatalogow, to
chyba musze wiedziec ile mi taki podkatatalog zajmie, zeby moc
wiedziec gdzie bedą umieszczone nastepne.
to samo dotyczy zreszta kolejnych poziomow.
czyli jakies pierwsze skanowanie, i potem zapis danych - i znow -
dobrze byloby zapamietac dane katalogow, zeby zmiany na dysku nie
wywalily nam calego procesu.


za to widze jakies identyfikatory woluminow ... moze Unix sie nie bawi
w ograniczanie rozmiaru, zapisze na tylu plytach, ilu trzeba :-)
Tylko amatorzy uzywaja nagrywarki bez zmieniarki ? :-)

>>> Hm, ale czy na pewno w swiecie unix tak jest ?
>>> Moze te ostrzezenia to zanim jeszcze wypluje pierwsze dane ...

>Nie, pojawiają się na bieżąco przy braniu kolejnych plików
>i dopisywania ich do obrazu.

>> a cel widac jakis backupowy - lepiej nagrac dane pod inną nazwą,
>> niz nie nagrac wcale :-)

>To nawet nie jest tak, że nagra się pod inną nazwą. Ostrzeżenie
>dotyczy tego, że gdzieś może zostać źle odczytane. Nie pamiętam
>szczegółów, ale w płytologii stosowanej zawsze był niezły bałagan.

Az sobie odswiezylem informacje - tych rozszerzen odnosnie nazw bylo
kilka, ale podstawa to z DOS 8+3.
Ale zaraz - gdzie te 8+3 wystepuje ?

Chyba i tak musi jakos pozmieniac nazwy, jesli sa problematyczne.

J.

do góry

On Thu, 16 Jul 2020 17:26:30 +0200, "J.F."
<j...@p...onet.pl> wrote:
> Hm, ale czy na pewno w swiecie unix tak jest ?

J. S. jak zwykle głupoty wypisuje. Oczywiście że mkisofs/mkhybrid
przed wygenerowaniem pierwszych bajtów obrazu sprawdzał strukturę
wejściową czy jest zgodna z wybranymi parametrami generowanego
obrazu.

--
Marek

do góry

W dniu 16.07.2020 o 16:59, Jarosław Sokołowski pisze:
> Pan Dariusz Dorochowicz napisał:
>
>>> Albo zapisywał gdzieś na boku. K3B (graficzna nakładka na uniksowe
>>
>> A to zależało od ustawień. Wprawdzie pliki tymczasowe były tworzone,
>> ale nie było to aż tak wielkie jak ISO do nagrania. No chyba że się
>> ustawiło żeby je i tak utworzył.
>
> Tworzenie obrazu w pliku dzisiaj nic nie kosztuje. A potem się przydaje,
> gdy trzeba nagrać kilka egzemplarzy. Nie dalej jak wczoraj dzwinił
> do mnie zrozpaczony znajomy, bo firma, która ma mu wyprodukować 600
> egzemplarzy płyty, zażyczyła sobie obrazu iso i sumy md5. A on nie wie
> co to jest, ani jaki program do robienia tych obrazów i sum ma kupić,
> żeby działał pod MacOS.

Ba, jak odnosić "kiedyś" do "dzisiaj" no to wyjdą różne dziwne rzeczy.

>>> Była jakiaś niejednoltość wśród nagrywarek? Z poziomu Linuksa nie
>>> zauważyłem. Ale jak podłączałem pierwszy CD-ROM, to musiałem do
>>> tego kompilować kernel. Apotem drugi raz, gdy przestawiłem jakieś
>>> karty i się numery przerwań zmieniły.
>>
>> Była. Drivery wpisywane w config.sys (ktoś to jeszcze pamięta?)
>> sprawdzały identyfikatory napędów i innych nie obsługiwały. Niektóre
>> dawało się przekonać że potrafią, aż w końcu pojawił się driver bodaj
>> Mitsumi czy jakoś tak który to olewał i wszystko na nim działało.
>> A jak ktoś miał kilka napędów i do każdego ładował inny driver, to była
>> zabawa. Nawet bywało tak że napędy tej samej firmy miały inne drivery.
>
> No ale po to właśnie są drivery, żeby potem już działało zawsze tak
> samo. Jak już ten kernel przekompilowałem, to CDROM (Mitsumi właśnie)
> działał jak każdy inny. Czy w Windows bywa(ło) tak, że program, dajmy
> na to wspomniany Neron, odmawia działania, bo ma mapend Sony, a nie
> Mitsui?

Jak zobaczyłem jak to w Linuksie działa od razu zacząłem podejrzewać co
jest na rzeczy. Przy czym to dotyczy napędów ATAPI. Z drukarkami jest
(raczej było) podobnie - nowa wersja ma identyfikator który nie jest
wpisany do plików konfiguracyjnych nagranych na płytce/dyskietce i
klapa. A wystarczyło wpisać dodatkowe identyfikatory i działało.

Nero to już Windows 95. Tu jest mowa o innym programie, ale jak widać
sam system załatwiał sprawę:

https://www.computerworld.pl/news/Przeglad-testowany
ch-nagrywarek-CD-RW,284500,2.html

Ale to musiałem sobie przypomnieć jednak. Przy czym żeby bez grafiki
mieć dostęp trzeba było mieć driver w config.sys (ignorowany po starcie
grafiki).
Kontroler dysku musiał być znany Windows. Tu z Linuksem tak samo. Masz
driver - jest OK. Nie masz- spadaj.

Pozdrawiam

DD

do góry

Pan Dariusz Dorochowicz napisał:

> Ale to musiałem sobie przypomnieć jednak. Przy czym żeby bez grafiki
> mieć dostęp trzeba było mieć driver w config.sys (ignorowany po starcie
> grafiki).

Dla mnie zawsze to było jednym z większych dziwactw Windows -- bez grafiki
nic nie da się zrobić, nawet w wersji "server". Z tym że tu chyba o co
innego chodzi -- to "bez grafiki" to po prostu DOS.

> Kontroler dysku musiał być znany Windows. Tu z Linuksem tak samo. Masz
> driver - jest OK. Nie masz- spadaj.

Z uniksami chyba jednak znacznie bardziej. Tu jest twardo powiedzine --
kernel nie zna tego sprzętu, więc spadaj. Żadne zewnętrzne drivery nie
pomogą. W Windows (chyba) da sie robić różne szwindle i dogadywać się
ze sprzętem niezbyt oficjalną drogą.

--
Jarek

do góry

W dniu 16.07.2020 o 22:07, Jarosław Sokołowski pisze:
> Pan Dariusz Dorochowicz napisał:
>
>> Ale to musiałem sobie przypomnieć jednak. Przy czym żeby bez grafiki
>> mieć dostęp trzeba było mieć driver w config.sys (ignorowany po starcie
>> grafiki).
>
> Dla mnie zawsze to było jednym z większych dziwactw Windows -- bez grafiki
> nic nie da się zrobić, nawet w wersji "server". Z tym że tu chyba o co
> innego chodzi -- to "bez grafiki" to po prostu DOS.

No to się wiele w międzyczasie pozmieniało. Najpierw zniknął DOS, potem
środowisko zyskało jeszcze jedną warstwę. I oprócz celowego robienia
dziur ich łatanie na różne sposoby. Ale to tam takie rozważania.
Windows 95 to już nie był tylko nakładka graficzna na DOS - to był
"system operacyjny" który miał własną obsługę urządzeń i DOS był tylko
środowiskiem startowym. Ale możesz też odpalić serwer bez grafiki - nie
ma problemu. Nawet chyba odrobinę tańszy jest.

>> Kontroler dysku musiał być znany Windows. Tu z Linuksem tak samo. Masz
>> driver - jest OK. Nie masz- spadaj.
>
> Z uniksami chyba jednak znacznie bardziej. Tu jest twardo powiedzine --
> kernel nie zna tego sprzętu, więc spadaj. Żadne zewnętrzne drivery nie
> pomogą. W Windows (chyba) da sie robić różne szwindle i dogadywać się
> ze sprzętem niezbyt oficjalną drogą.

Czy ja wiem? Po prostu inaczej. Modprobe potrafi załadować różne rzeczy,
również obsługę napędów. Wydaje mi się ze nawet były moduły po prostu
pod konkretne wersje kernela i nie trzeba było kompilować systemu. Byle
kernel potrafił daną kategorię urządzeń obsługiwać, cokolwiek by to nie
znaczyło. Z takich ostatnio rozgryzanych to chyba różne karty sieciowe,
ale po prawdzie to dawno się tak nie bawiłem. Pamiętam że coś tam było z
obsługą driverów windowsowych, ale i bez tego można nowe karty obsłużyć.
Może niedługo jakiś fajny serwer mi w ręce trafi to kto może będzie czas
żeby popróbować?
A Windows to bardzo różne systemy i różne rzeczy można w nich robić. W
nowych to żeby się dostać do plików użytkowników to prościej jakąś
dystrybucję live odpalić niż kombinować jak by tu... No bo jak tłumaczyć
użytkownikom że muszą.... to już prościej samemu. Knoppix na szybkim
pendrajwie fajny jest i wiele nie trzeba kombinować.

Pozdrawiam

DD

do góry

On 16/07/2020 22:07, Jarosław Sokołowski wrote:
> Z uniksami chyba jednak znacznie bardziej. Tu jest twardo powiedzine --
> kernel nie zna tego sprzętu, więc spadaj. Żadne zewnętrzne drivery nie
> pomogą.

Ale w przypadku Linuxa zewnętrzne drivery są w powszchnym użyciu, polega
to na kompilacji w środowisku docelowym modułu i jego załadowaniu do
jądra. Działa tak bardzo dużo współczesnych sterowników do karta
graficznych. Ponieważ API modułów silnie zależy od kernela, to
kompilacja, przynajmniej cześci wciskanej w jądro, jest wymagana na
docelowej maszynie, choć dla stockowych wersji kernela robi to czasem
autorzy dystrybucji. To jest dokładnie odpowiednik driverów z windowsa,
róznica jest taka że w widnowsie jest stabilne API i znana achitektura
wiec łatwiej dostarczyć binarną wersję.

Dodatkowo w niektórych przypadkach (libusb) możliwe jest gadanie z
urządzeniami *bez* sterowników z poziomu userspace i implementacja
"sterownika" w kodzie programu (na przykład wiele programatorów układów
scalonych preferuje takie podejście, zamiast sterowanika w kernelu).

do góry