Dlaczego musimy montować na Linuksie?

67

Rozumiem, co jest montowane w Linuksie i rozumiem pliki urządzeń. Jednak nie rozumiem DLACZEGO musimy montować.

Na przykład, jak wyjaśniono w zaakceptowanej odpowiedzi na to pytanie , za pomocą tego polecenia:

mount /dev/cdrom /media/cdrom

montujemy urządzenie CDROM /media/cdromi ostatecznie możemy uzyskać dostęp do plików CDROM za pomocą następującego polecenia

ls /media/cdrom

która wyświetli zawartość CDROM-u.

Dlaczego nie pominąć całkowicie montażu i wykonać następujące czynności?

ls /dev/cdrom

I umieść na liście zawartość CDROM. Spodziewam się, że jedną z odpowiedzi będzie: „ Tak właśnie zaprojektowano Linuksa ”. Ale jeśli tak, to dlaczego zostało tak zaprojektowane? Dlaczego nie uzyskać /dev/cdrombezpośredniego dostępu do katalogu? Jaki jest prawdziwy cel montażu?

Greeso
źródło
2
Być może zainteresują Cię również kłopoty ze zrozumieniem koncepcji montażu
PM 2Ring
23
Zauważ, że prawie wszystkie systemy operacyjne „montują”. W większości przypadków jest po prostu przezroczysty. Kiedy w Windows wybierasz „bezpieczne usunięcie” dla pendrive'a, faktycznie wykonujesz umount, po tym jak został on automatycznie zamontowany przez system. Linux po prostu nie izoluje użytkownika tak daleko od procesu, więc możesz go bardziej „dostosować” - powiedzmy, partycja umsdos nie różni się w żaden widoczny sposób od vfata, ale jeśli użyjesz go mount -t umsdosdo zamontowania, masz wszystkie uprawnienia do systemu Linux, prawa własności, specjalne pliki, fifos itp. Jeśli mount -t vfatzachowuje się jak zwykła partycja Windows.
SF.
7
„Rozumiem, co jest montowane w systemie Linux i rozumiem pliki urządzeń”. Najwyraźniej nie;)
Lekkość ściga się na orbicie
5
Why not access the /dev/cdrom directory directly?Ponieważ to nie jest katalog.
Brandon

Odpowiedzi:

67

Jednym z powodów jest to, że dostęp na poziomie bloku jest nieco niższy niż lsbyłby w stanie pracować. /dev/cdrom, lub dev/sda1może być odpowiednio napędem CD ROM i partycją 1 dysku twardego, ale nie implementują one ISO 9660 / ext4 - to tylko wskaźniki RAW dla urządzeń zwanych plikami urządzeń .

Jedną z rzeczy, które określa mount, jest JAK używać tego surowego dostępu - jakie moduły logiki / sterownika / jądra systemu plików będą zarządzać odczytami / zapisami lub tłumaczyć, ls /mnt/cdromw których blokach należy czytać, i jak interpretować ich zawartość blokuje na rzeczy takie jak file.txt.

Innym razem ten dostęp na niskim poziomie może być wystarczająco dobry; Właśnie czytałem i zapisałem na porty szeregowe, urządzenia USB, terminale tty i inne stosunkowo proste urządzenia. Nigdy nie próbowałbym ręcznie czytać / pisać z / dev / sda1, powiedzmy, edytować pliku tekstowego, ponieważ w zasadzie musiałbym ponownie zaimplementować logikę ext4, która może obejmować między innymi: wyszukiwanie i-węzłów pliku, znajdowanie bloki pamięci, przeczytaj cały blok, dokonaj moich zmian, napisz pełne bloki, a następnie zaktualizuj i-węzeł (być może) lub zamiast tego napisz to wszystko do dziennika - o wiele za trudne.

Jednym ze sposobów, aby to sprawdzić, jest wypróbowanie:

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devto katalog, w którym możesz cdi lswszystko, co lubisz. /dev/sda1nie jest katalogiem; jest to specjalny typ pliku, który jądro oferuje jako „uchwyt” dla tego urządzenia.

Zobacz wpis wikipedii na urządzeniu plików, aby uzyskać bardziej szczegółowe leczenie.

Ehryk
źródło
4
Zastanawiam się nad niektórymi szczegółami, ponieważ myślę, że coś złego się stanie, jeśli zaczniesz pisać do danych przechowywanych na / dev / sda1, i dlatego zakładam, że istnieją pewne środki zapobiegawcze lub abstrakcja, które powstrzymałyby cię od nadpisywania rzeczy. Ale podsumowując, jeśli dokładnie wiesz, jak i gdzie zapisać na dysk, możesz to zrobić ręcznie /dev/sda1. Uwaga: niektóre narzędzia NIE działają bezpośrednio z dyskami surowymi, takimi jak swapon/swapoffi dd.
Ehryk
4
Aby dodać nieco więcej, montowanie inicjuje system plików, a tym samym aktywuje całą warstwę automatycznej obsługi operacji wejścia / wyjścia, która jest przezroczysta dla użytkownika (np. Buforowanie plików w pamięci RAM, kolejkowanie operacji, przechowywanie stanów otwartych plików i tak dalej). Dlatego też musisz poprawnie odmontować system plików, aby uniknąć uszkodzenia (lub przynajmniej zsynchronizować go). Montaż jest obecny na wszystkich powszechnie używanych platformach, nie tylko na Linuksie. Jeśli montaż jest automatycznie obsługiwany przez środowisko pulpitu (KDE lub gnome), jest tak samo ukryty, jak w MS Windows.
orion
6
@Ehryk (3 komentarze w górę) jedynym środkiem zapobiegawczym w typowym systemie Linux są uprawnienia do systemu plików - innymi słowy, musisz użyć konta root do zapisu w pliku urządzenia. Jeśli to zrobisz, możesz zrobić to cat >/dev/sda1z całego serca, a Linux cię nie powstrzyma. (Nie trzeba dodawać, że spowodowałoby to całkowite uszkodzenie systemu plików).
David Z
5
@psusi Nie można tego zrobić w systemie Windows 95, prawda. Ale był obecny (i dobrze ukryty) w MS DOS i Windows NT. Twój nowoczesny system Windows oparty na NT z pewnością pozwala na montowanie i odmontowywanie partycji do woli (nawet do folderów na innych partycjach, a nawet do wielu folderów jednocześnie) - zwykle po prostu montuje wszystkie nieznane partycje, aby domyślnie napędzać litery. Możesz również uzyskać dostęp do urządzenia bez montowania go, używając pełnej ścieżki (bardzo podobnej do unixowej), ale tylko wtedy, gdy nie jest zablokowane - co oczywiście jest, jeśli jest aktualnie zamontowane.
Luaan
3
@Luaan & psusi Psusi ma do tego prawo. Ale dla prawie wszystkich celów i celów efekt wywołujący Win32 API jest w zasadzie identyczny. (Dla zgodności z Posix istnieje emulacja semantyki montowania). Win9x faktycznie ma koncepcję montowania, ponieważ nadal działa na DOS. Obsługa FAT została wbudowana w DOS jako natywny moduł obsługi, nieco podobny do sposobu, w jaki obsługuje go jądro NT. Ale CDROM i sieciowe systemy plików musiały być zamontowane. (Zapamiętaj MSCDEX dla CD. Dostarczyło to obsługi systemu plików ISO / RockRidge i zamontowało go na literę dysku).
Tonny
20

Zasadniczo i, mówiąc prosto, system operacyjny musi wiedzieć, jak uzyskać dostęp do plików na tym urządzeniu.

mount nie tylko „daje ci dostęp do plików”, ale informuje system operacyjny o tym, jaki system plików ma napęd, jeśli jest to tylko odczyt lub dostęp do odczytu / zapisu itp.

/dev/cdromjest urządzeniem niskiego poziomu, funkcje systemu operacyjnego nie wiedziałyby, jak uzyskać do nich dostęp ... wyobraź sobie, że umieściłeś w nim dziwnie sformatowany cdrom (nawet audio CD), jak lspowiedzieć, które pliki (jeśli w ogóle) są na cd-rom bez „montowania” go najpierw?

Zauważ, że dzieje się to automatycznie w wielu systemach operacyjnych (nawet Linux w niektórych dystrybucjach i interfejsach graficznych), ale to nie znaczy, że inne systemy nie „montują” napędów.

Jcl
źródło
8

Dla spójności

Wyobraź sobie, że masz partycje na pierwszym dysku twardym w systemie. Na przykład /dev/sda2. Później decydujesz, że dysk nie jest wystarczająco duży, więc kupujesz drugi i dodajesz go do systemu. Nagle tak się dzieje /dev/sdai staje się obecny napęd /dev/sdb. Twoja partycja jest teraz /dev/sdb2.

Korzystając z proponowanego systemu, musisz zmienić wszystkie skrypty, aplikacje, ustawienia itp., Które uzyskują dostęp do danych na starej partycji, aby odzwierciedlić tę zmianę nazw.

Jednak montaż pozwala nadal używać tego samego punktu montowania dla tego przemienionego napędu. Trzeba by edytować, /etc/fstababy powiedzieć systemowi, że (na przykład) /media/backupjest teraz /dev/sdb2zamiast tego, ale to tylko jedna zmiana.

Pamiętaj, że współczesne systemy są jeszcze łatwiejsze. Zamiast odwoływać się do urządzenia jako /dev/sda2lub /dev/sdb2mają UUIDS, które wyglądają podobnie c5845b43-fe98-499a-bf31-4eccae14261blub mogą otrzymać bardziej przyjazne etykiety, na przykład takie, backupktóre mogą być użyte do odniesienia urządzenia podczas montażu. W ten sposób nazwa urządzenia nie zmienia się podczas dodawania nowego urządzenia, co sprawia, że ​​administracja jest jeszcze prostsza:

# mount LABEL="backup" /media/backup

Dla bezpieczeństwa

Wymagając zamontowania urządzenia, administrator może kontrolować dostęp do urządzenia. Urządzenie można usunąć po odmontowaniu, ale nie w trakcie użytkowania (chyba że chcesz utracić dane). Jeśli jesteś (byłeś) użytkownikiem systemu Windows, pamiętasz małą zieloną ikonę w obszarze powiadomień, która informuje, że możesz bezpiecznie usunąć pamięć USB? To znaczy montowanie i odmontowywanie pendrive'a za ciebie. Więc zasada nie jest tylko Uniksem / Linuksem.

garethTheRed
źródło
Uniwersalne identyfikatory są w rzeczywistości identyfikatorami UUID, a nie identyfikatorami GUID firmy Microsoft.
Ruslan
@ Ruslan - więc są! Miałem wtedy moją stwardnienie rozsiane głowę. Wielkie dzięki - zmieniłem to.
garethTheRed
6

Nazwałbym to historycznymi powodami. Nie chodzi o to, że inne odpowiedzi są błędne, ale w tej historii jest coś więcej.

Porównaj system Windows: system Windows został uruchomiony jako system operacyjny dla jednego komputera i dla jednego użytkownika. Ten pojedynczy komputer prawdopodobnie miał jeden napęd dyskietek i jeden dysk twardy, bez połączenia sieciowego, bez USB, bez niczego. (Windows 3.11 miał natywne możliwości sieciowe; Windows 3.1 nie .)

Sposób, w jaki narodził się Windows, był tak prosty, że nie trzeba było być fantazyjnym: po prostu zamontuj wszystko (wszystkie dwa urządzenia) automatycznie za każdym razem, nie ma (nie było) wielu rzeczy, które mogłyby pójść nie tak.

Natomiast Unix został stworzony do pracy w sieciach serwerów z wieloma użytkownikami od samego początku.

Jedną z decyzji projektowych w systemie Unix było to, że system plików powinien wyglądać jako jednolity, jednolity byt dla użytkowników końcowych, bez względu na to, na ilu komputerach dyski fizyczne zostały rozmieszczone, bez względu na rodzaj dysku i bez względu na to, który z dziesiątek komputerów użytkownik miałby do niego dostęp. Logiczna ścieżka do plików użytkownika pozostałaby taka sama, nawet gdyby fizyczna lokalizacja tych plików zmieniła się z dnia na dzień, np. Z powodu konserwacji serwera.

Wydzielali logiczny system plików, ścieżki do plików, z fizycznych urządzeń, na których te pliki były przechowywane. Powiedzmy, że serwer A zwykle hostuje / home, ale serwer A wymaga konserwacji: wystarczy odmontować serwer A i zamontować serwer zapasowy B na / home, a nikt oprócz administratorów nawet by tego nie zauważył.
(W przeciwieństwie do konwencji systemu Windows nadawania różnych nazw różnym urządzeniom fizycznym - C :, D: itd. - co działa wbrew przejrzystości, o którą dążył Unix).

W takim otoczeniu nie można po prostu zamontować wszystkiego w zasięgu wzroku, nie chcąc,

W dużej sieci pojedyncze dyski i komputery są ciągle bez prowizji. Administratorzy potrzebują możliwości określenia, co jest zamontowane, gdzie i kiedy, np. W celu kontrolowanego wyłączenia jednego komputera, podczas gdy inny komputer przejmie hostowanie tych samych plików.

Dlatego z historycznego punktu widzenia: Windows i Unix pochodzą z różnych środowisk. Możesz to nazwać różnicą kulturową, jeśli chcesz:

  • Unix narodził się w środowisku, w którym administrator musiał kontrolować montowanie; z kilkudziesięciu urządzeń pamięci masowej w sieci administrator musi zdecydować, co zostanie zamontowane, gdzie i kiedy.
  • Windows narodził się w środowisku, w którym nie było administratora i tylko dwa urządzenia pamięci masowej, a użytkownik prawdopodobnie wiedziałby, czy ich plik znajduje się na dyskietce, czy na dysku twardym.
  • (Linux narodził się oczywiście jako system operacyjny na jednym komputerze, ale od samego początku został wyraźnie zaprojektowany tak, aby jak najbardziej naśladować Uniksa na komputerze domowym).

Ostatnio systemy operacyjne zbliżają się do siebie:

  • Linux dodał więcej rzeczy dla jednego komputera i dla jednego użytkownika (np. Automounting); ponieważ często był używany w ustawieniach jednego komputera.
  • Windows dodał więcej bezpieczeństwa, sieci, wsparcia dla wielu użytkowników itp .; sieci stały się coraz bardziej wszechobecne, a Microsoft zaczął tworzyć system operacyjny również dla serwerów.

Ale nadal łatwo powiedzieć, że oba są wynikiem różnych tradycji.

jg-faustus
źródło
1
To nie tylko to. Urządzenia to abstrakty niskiego poziomu, z których mogą korzystać sterowniki systemu plików (i ewentualnie inne oprogramowanie systemowe). Unix został zaprojektowany jako system operacyjny dla programistów systemów operacyjnych. Na przykład programiści tych sterowników systemu plików. Dlatego te abstrakcje niskiego poziomu są udostępniane użytkownikowi.
reinierpost
5

Obecne rozwiązanie ma kilka zalet. Można je pogrupować w zalety blokowych plików specjalnych i zalety punktów montowania.

Pliki specjalne to pliki reprezentujące urządzenia. Jednym z pomysłów, na których zbudowano uniks, jest to, że wszystko jest plikiem. Ułatwia to wiele rzeczy, na przykład interakcja użytkownika to po prostu odczyt i zapis pliku na urządzeniu tty, który jest plikiem specjalnym. podobnie sprawdzanie uszkodzonych bloków, partycjonowanie lub formatowanie dysku to tylko operacje na plikach. Nie ma znaczenia, czy dysk to mfm, ide, scsi, fiberchanel, czy coś innego to tylko plik.

Ale z drugiej strony możesz nie chcieć zajmować się całym dyskiem lub partycją tylko plikami, aw wielu przypadkach więcej plików zmieści się na dysku. Mamy więc punkty montowania. Punkt montowania pozwala na umieszczenie całego dysku (lub partycji) w katalogu. W moich czasach Slackware, gdy dysk twardy dobrej wielkości miał kilkaset MB, często używano CD jako / usr i dysku twardego dla /, / usr / local i swap. Lub możesz umieścić / na jednym dysku i / home na innym.

Teraz zauważyłem, że wspominałeś o montowaniu CD na / media / cdrom, co jest przydatne na komputerach z tylko jednym napędem cdrom, ale co jeśli masz więcej niż jeden? gdzie powinieneś zamontować drugi? czy trzeci? czy piętnasty? z pewnością możesz użyć / media / cdrom2 itp. Lub możesz zamontować go na / src / samba / resources / windows-install lub / var / www, lub gdziekolwiek ma to sens.

Hildred
źródło
Myślę, że OP oznaczało, dlaczego nie pominąć mountcałości i po prostu wejść w /dev/cd0, /dev/cd2, /dev/sda1, /dev/sda2bezpośrednią interakcję - każdy z nich ma już określony „katalog”.
Ehryk
1
Masz rację, ale czy naprawdę uważasz / dev / sdb9 / share / doc / package / README dobrą ścieżką? nawet d: / share / doc / package / README jest lepszy, ale / usr / share / doc / package / README ma semantykę! to jest wartość punktu montowania.
hildred
3
Podejrzewam, że użycie semantyczne pojawiło się później jako użyteczny produkt uboczny absolutnej konieczności „umieszczenia jakiegoś kodu między systemem katalogów a wskaźnikiem nieprzetworzonych plików na urządzeniu”, ponieważ użycie cd / ls / nano / wszystko inne jest znacznie łatwiejsze niż surowe pisze: nie dd if=/file of=/dev/sda2 bs=4096 skip=382765832 count=84756mówiąc już o aktualizacji powiązanego i-węzła / FAT / aktualizacji dziennika.
Ehryk
(niektórzy masochiści z Linuksa prawdopodobnie chcieliby / dev / sdb9 jako katalogi robocze, jestem pewien)
Ehryk
2
Mój pierwszy komputer działał cp / m na dyskietkach 2 8 ". W ogóle nie obsługiwał podkatalogów. Jeden katalog na dysk. Ścieżka wyglądała jak b: name.ext. Pomysł nazewnictwa semantycznego został już ustalony. Nawet systemy taśmowe używane nazwy plików. UNIX już odrzucił pomysł liter dysku dla punktów montowania. Nawiasem mówiąc, @Ehryk, czy wiesz, że możesz zamontować dysk w katalogu nie tylko w systemie Windows, ale w DOS? Zrobiłem to na MS-DOS 5 ... poza tym, kiedy szukam strony podręcznika, nie chcę pamiętać, który komputer jest na znacznie mniejszym dysku, na którym
jedzie
5

Tytuł pytania brzmi: Dlaczego musimy montować w systemie Linux?

Jeden ze sposobów interpretacji tego pytania: Dlaczego musimy wydawać jawne mountpolecenia, aby systemy plików były dostępne w systemie Linux?

Odpowiedź: my nie.

Nie musisz jawnie montować systemów plików, możesz ustawić, aby odbywało się to automatycznie, a dystrybucje Linuksa już to robią dla większości urządzeń, tak jak robią to Windows i Mac.

Więc prawdopodobnie nie o to chciałeś zapytać.

Druga interpretacja: dlaczego czasami musimy wydawać jawne mountpolecenia, aby udostępnić systemy plików w systemie Linux? Dlaczego nie sprawić, że system operacyjny zawsze zrobi to za nas i ukryje przed użytkownikiem?

Oto pytanie, które czytam w tekście pytania, kiedy zadajesz:

Dlaczego nie pominąć całkowicie montażu i wykonać następujące czynności

ls /dev/cdrom

i czy na liście znajduje się zawartość płyty CD-ROM?

Prawdopodobnie masz na myśli: dlaczego po prostu nie masz tego polecenia

ls /media/cdrom

robi teraz?

W takim przypadku /dev/cdrombyłoby to drzewo katalogów, a nie plik urządzenia. Tak więc wydaje się, że Twoim prawdziwym pytaniem jest: po co plik urządzenia?

Chciałbym dodać odpowiedź do tych, które już zostały podane.

Dlaczego użytkownicy widzą pliki urządzeń?

Ilekroć korzystasz z dysku CD-ROM lub innego urządzenia do przechowywania plików, używane jest oprogramowanie, które interpretuje wszystko, co znajduje się na dysku CD-ROM, jako drzewo katalogów plików. Jest on wywoływany za każdym razem, gdy używasz lsinnego polecenia lub aplikacji, która uzyskuje dostęp do plików na dysku CD-ROM. To oprogramowanie jest sterownikiem systemu plików dla konkretnego systemu plików używanego do zapisywania plików na dysku CD-ROM. Ilekroć wyświetlasz, odczytujesz lub zapisujesz pliki w systemie plików, zadaniem tego oprogramowania jest upewnienie się, że odpowiednie operacje odczytu i zapisu na niskim poziomie są wykonywane na danym urządzeniu. Kiedykolwiek jesteś mountsystemem plików, mówisz systemowi, którego sterownika systemu plików użyć dla tego urządzenia. Czy robisz to jawnie za pomocąmountpolecenie lub pozostaw to systemowi operacyjnemu, aby wykonało się automatycznie, trzeba będzie to zrobić, i oczywiście oprogramowanie sterownika systemu plików będzie musiało tam być.

Jak działa sterownik systemu plików? Odpowiedź: robi to poprzez czytanie i zapisywanie do pliku urządzenia. Dlaczego? Odpowiedź, jak już wspomniałeś: Unix został zaprojektowany w ten sposób. W Uniksie pliki urządzeń są powszechną abstrakcją niskiego poziomu dla urządzeń. Naprawdę oprogramowanie specyficzne dla urządzenia (sterownik urządzenia) dla określonego urządzenia ma zaimplementować otwieranie, zamykanie, czytanie i zapisywanie na urządzeniu jako operacje na pliku urządzenia. W ten sposób oprogramowanie wyższego poziomu (takie jak sterownik systemu plików) nie musi wiedzieć tyle o wewnętrznym działaniu poszczególnych urządzeń. Niskopoziomowe sterowniki urządzeń i sterowniki systemu plików mogą być zapisywane osobno przez różne osoby, pod warunkiem, że uzgodnią wspólny sposób komunikowania się między sobą i do tego służą pliki urządzeń.

Tak więc sterowniki systemu plików potrzebują plików urządzeń.

Ale dlaczego my, zwykli użytkownicy, widzimy pliki urządzeń? Odpowiedź jest taka, że ​​Unix został zaprojektowany do użytku przez programistów systemów operacyjnych. Został zaprojektowany, aby umożliwić użytkownikom pisanie sterowników urządzeń i sterowników systemu plików. Tak właśnie się pisze.

To samo dotyczy Linuksa: możesz napisać własny sterownik systemu plików (lub sterownik urządzenia), zainstalować go, a następnie użyć. To sprawia, że ​​Linux (lub jakikolwiek inny wariant Uniksa) jest łatwo rozszerzalny (i to jest powód, dla którego Linux został uruchomiony): kiedy pojawia się jakiś nowy sprzęt lub pojawia się nowy, mądrzejszy sposób implementacji systemu plików , ktoś może napisać kod, aby go wesprzeć, sprawić, by działał i wniósł go do systemu Linux.

Pliki urządzeń ułatwiają to.

reinierpost
źródło
1
bardzo dobrze wyjaśnione
Shailendra
4

Wiele silników baz danych może pracować bezpośrednio z surowymi dyskami lub partycjami. Na przykład MySQL:

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

Pozwala to uniknąć narzutu związanego ze przeglądaniem sterowników systemu plików, gdy wszystko, czego tak naprawdę potrzebuje silnik DB, to jeden ogromny plik, który wypełnia dysk.

Tom Robinson
źródło
3

Ponieważ /dev/cdromjest urządzeniem, podczas gdy /media/cdromjest systemem plików . Musisz zamontować ten pierwszy na drugim, aby uzyskać dostęp do plików na CD-ROM.

Twój system operacyjny już automatycznie instaluje systemy plików root i użytkownika z fizycznego urządzenia dysku twardego podczas uruchamiania komputera. To tylko dodaje więcej systemów plików do użycia.

Wszystkie systemy operacyjne to robią - jednak niektóre (takie jak Windows, kiedy montuje dysk CD-ROM D:) robią to w sposób transparentny. Linux pozostawia to tobie, abyś miał większą kontrolę nad procesem.

Lekkość Wyścigi na orbicie
źródło
2
Nie mogę się zgodzić co do twojego sformułowania. /dev/cdromto plik urządzenia (który ma specjalne możliwości umożliwiające nam łatwą komunikację we / wy z / do powiązanego urządzenia). /media/cdromjest katalogiem, ale zasadniczo jest to inny plik (pamiętaj, że w Linuksie wszystko jest plikiem, łącznie z katalogami). Teraz, kiedy skończymy, mountmamy specjalną możliwość przeglądania zawartości pliku urządzenia jako systemu plików. Moje niezrozumienie ostatniego zdania polega na przeczytaniu powyższych odpowiedzi.
Greeso,
@Greeso: Trzymam się mojej odpowiedzi.
Wyścigi lekkości na orbicie
0

Dzieje się tak, ponieważ w przypadku wielu multimediów dla interfejsów użytkownika komputerów stacjonarnych i laptopów niejednoznaczność co do tego, co zrobić, gdy nośnik jest włożony, ponieważ intuicja użytkownika polega na tym, że włożenie dysku do fizycznego pudełka, z którym użytkownik wchodzi w interakcje, nie różni się, powiedzmy, , wkładając go do urządzenia obok komputera, który ma połączenie sieciowe.

Dlatego w podstawowym znaczeniu interfejs użytkownika dla mediów musi traktować dwa rodzaje potencjalnych zdarzeń montowania w podobny sposób, a komputery nie mogą obsługiwać montowań sieciowych w tak intuicyjny sposób, jak to możliwe dla montowań sieciowych z innymi interfejsami użytkownika na komputerach, takich jak smartfony, tablety i komputery do noszenia, które nie mają możliwości wstawienia fizycznych nośników do urządzenia. (Zwróć uwagę, jak straszny jest interfejs iPhone'a do przełączania kart SIM, do których włożono jeden rodzaj fizycznych urządzeń z iOS.

Należy również zauważyć, że inne popularne podejścia do interfejsów użytkownika dla tego typu fizycznych urządzeń (na przykład Windows 98, Windows 8, Mac OS X 10.2 (Jaguar) i Mac OS X 10.9 (Mavericks)) mają takie same problemy i użyj dodatkowych okien dialogowych z interfejsem GUI, aby rozwiązać potencjalne zamieszanie (na przykład system Windows 8 jest zwykle skonfigurowany tak, aby pytać o każdą nową włożoną płytę CD, czy powinien być zamontowany jako system plików, nośnik muzyczny lub, w razie potrzeby, kolekcja filmów MP4 ). Nie ma powodu, dla którego żadne z tych okien dialogowych użytkownika nie może być używane z Linuksem lub innymi systemami UNIX.

Charles Stewart
źródło