Pan Zbych napisał:

>> Mam przeczucie, że celem było wyważenie otwartych drzwi. Plików
>> skojarzonych z urządzeniem może być wiele, można je wytwarzać
>> (np. pleceniem mknod) w dowolnych ilościac, z dowolnymi nazwami
>> w dowolnych katalogach, nie tylko w /dev. System udev może za
>> każdym razem po podłączeniu kabla tego telefonu tworzyć np. plik
>> /dev/motorola. Podłączenie innego telefonu spowoduje stworzenie
>> pliku /dev/siemens. Specyficzne programy przeznaczone do kontaktu
>> z jakimś konkretnym urządzeniem nie muszą się wiecznie zastanawiać
>> "a co to tym razem podłączono jako /dev/ttyACM0", tylko śledzą swój
>> własny plik.
>
> Celem było po pierwsze stworzenie listy urządzeń "szeregowych" (porty
> rs-232, przejściówki RS-USB, telefony pracujące w klasie cdc/acm), a po
> drugie dodanie do nich opisu (tak żeby użytkownik nie musiał zgadywać
> czy ttyUSB0 to przejściówka RS-USB, czy może telefon). Ideałem byłaby
> biblioteka c (libudev?).

Ideałem (tak żeby użytkownik nie musiał zgadywać czy ttyUSB0 to
przejściówka RS-USB, czy może telefon) byłoby używanie znaczących
nazw dla urządzeń takich jak telefon, a nie korzystanie z nazw
przeznaczonych dla portów (np. ttyUSB). Żeby to osiągnąć, nie trzeba
nawet "grzebać w plikach". Wystarczy, że wrzuci się w trakcie
instalacji kilkulinijkowy plik dostarczony przez producenta urządzenia
do katalogu /etc/udev. Przeszkodą jest tylko to, że producenci urządzeń
tych plików nie dostarczają, tak jak robią to z windowsowymi plikami INF.
Tutaj najbardziej prawdopodobnym wytłumaczeniem stanu rzeczy wydaje
mi się lenistwo.

--
Jarek

do góry

Jarosław Sokołowski pisze:

> Ideałem (tak żeby użytkownik nie musiał zgadywać czy ttyUSB0 to
> przejściówka RS-USB, czy może telefon) byłoby używanie znaczących
> nazw dla urządzeń takich jak telefon,

Sam podałeś sposób na odczytanie nazwy, nie wiem jeszcze tylko jak
stworzyć listę urządzeń "szeregowych". Do tej pory wydawało mi się, że
wystarczy wylistować ttyS*, ttyUSB* i ttyACM*, ale skoro nazwa może być
dowolna to jest to za mało. Odczyt katalogu /sys/bus/usb-serial/devices/
daje tylko informację o urządzeniach podłączanych przez usb. Skąd
jeszcze można wydobyć potrzebne informacje?

> Przeszkodą jest tylko to, że producenci urządzeń
> tych plików nie dostarczają, tak jak robią to z windowsowymi plikami INF.
> Tutaj najbardziej prawdopodobnym wytłumaczeniem stanu rzeczy wydaje
> mi się lenistwo.

Ja bym stawiał raczej na 1% udział linuksa w rynku systemów "biurkowych".

--
przeciez moje rozumowanie bylo bez skazy,
no sam bym wskoczyl do tego wulkanu,
ale kto by tak pieknie gwizdal...

do góry

Pan Zbych napisał:

>> Ideałem (tak żeby użytkownik nie musiał zgadywać czy ttyUSB0 to
>> przejściówka RS-USB, czy może telefon) byłoby używanie znaczących
>> nazw dla urządzeń takich jak telefon,
>
> Sam podałeś sposób na odczytanie nazwy, nie wiem jeszcze tylko jak
> stworzyć listę urządzeń "szeregowych". Do tej pory wydawało mi się,
> że wystarczy wylistować ttyS*, ttyUSB* i ttyACM*, ale skoro nazwa
> może być dowolna to jest to za mało.

Za mało albo za dużo, zależy jak na to patrzeć. Wszystkich plików
związanych z urządzeniami i tak się nie znajdzie, bo by trzeba
było przeczesać cały system plików, a to mogą być terabajty.
Z drugiej strony katalog /dev może zawierać setki "martwych" plików
urządzeń, takich które zostały stworzone, ale nie stoi za nimi żaden
realny sprzęt. Tak jest w "klasycznych" instalacjach, niekorzystających
z dynamicznego tworzenia plików.

> Odczyt katalogu /sys/bus/usb-serial/devices/ daje tylko informację
> o urządzeniach podłączanych przez usb. Skąd jeszcze można wydobyć
> potrzebne informacje?

A czy możemy założyć, że USB to jedyny dostępny podsystem "hotswap",
w którym mogą pojawiać się i znikać urządzenia szeregowe? Jest jeszcze
PCMCIA, ale tam też można odczytać katalog. W realnym pececie to już
chyba koniec. Wszystko inne musi być podłączone do magistrali PCI
(albo ISA) i wykryte przez startujący kernel albo moduł. Skoro tak,
to zostaje ślad w dmesg. Można więc przegrepować dmesg zaraz po starcie
systemu i być pewnym, że to się w czasie pracy nie zmieni.

Ale znowu najlepiej chyba zaufać systemowi udev i oprzeć się na tym,
że dla wszystkich wykrytych urządzeń stworzył właściwe pliki. Tylko nie
należy polegać na ich nazwach, lecz na ich właściwościach. Interesują
nas pliki urządzeń znakowych (character), a nie blokowych (block).
Polecenie "ls -l" pokazuje typ pliku. Pokazuje też "major number"
i "minor number" urządzenia. Po nich wnioskujemy, czy są to urządzenia,
które nas interesują (urządzenie szeregowe jest urządzeniem szeregowym
wtedy i tylko wtedy, gdy kernel kojarzy je z numerami zarezerwowanymi
dla urządzeń, które uzanjemy za urządzenia szeregowe).

>> Przeszkodą jest tylko to, że producenci urządzeń tych plików nie
>> dostarczają, tak jak robią to z windowsowymi plikami INF. Tutaj
>> najbardziej prawdopodobnym wytłumaczeniem stanu rzeczy wydaje mi
>> się lenistwo.
>
> Ja bym stawiał raczej na 1% udział linuksa w rynku systemów "biurkowych".

Kwestia udziału jest trochę z boku. Sterowniki linuksowe jednak powstają,
nie tylko w czynie społecznym, a producenci sprzętu coraz częściej
dołączają katalog "linux" do nośnika z oprogramowaniem. Tylko sposób
w jaki to robią, woła o pomstę do nieba. Wygląda to tak, jakby uważali,
że jak ktoś używa Linuksa (obojętnie czy na biurku czy gdzie indziej),
to o niczym innym nie marzy, jak tylko o edytowaniu emacsem plików
konfiguracyjnych i o tworzeniu diwajsów mknodem. Nie zauważają faktu,
że dostępne są w tym systemie metody [auto]konfiguracji urządzeń P'n'P
o wiele doskonalsze niż w Windows (taka jest przynajmniej moja opinia
wynikająca z obserwacji, a także z niniejszej dyskusji).

--
Jarek

do góry

Jarosław Sokołowski pisze:

>> Ja bym stawiał raczej na 1% udział linuksa w rynku systemów "biurkowych".
>
> Kwestia udziału jest trochę z boku. Sterowniki linuksowe jednak powstają,
> nie tylko w czynie społecznym, a producenci sprzętu coraz częściej
> dołączają katalog "linux" do nośnika z oprogramowaniem. Tylko sposób
> w jaki to robią, woła o pomstę do nieba. Wygląda to tak, jakby uważali,
> że jak ktoś używa Linuksa (obojętnie czy na biurku czy gdzie indziej),
> to o niczym innym nie marzy, jak tylko o edytowaniu emacsem plików
> konfiguracyjnych i o tworzeniu diwajsów mknodem. Nie zauważają faktu,
> że dostępne są w tym systemie metody [auto]konfiguracji urządzeń P'n'P
> o wiele doskonalsze niż w Windows (taka jest przynajmniej moja opinia
> wynikająca z obserwacji, a także z niniejszej dyskusji).

W każdej dystrybucji / kernelu? ;)
Problem z Linuksem (z punktu widzenia developera) polega na tym, że mało
co jest ustandaryzowane. W Windows dokładnie wiadomo, jak się zachowa
każda wersja systemu po podpięciu nowego urządzenia, np. na USB. Te
mechanizmy opisuje dość dokładnie Microsoft w dokumentacji MSDN. Obecnie
wystarczy wspierać trzy wersje systemu: Windows 2000, Windows XP i Vistę
- i to pokrywa zdecydowaną większość użytkowników Windows na świecie.
Dużo mechanizmów działa identycznie od lat więc i programy/sterowniki są
w pewnej mierze dość uniwersalne.

A dla Linuksa jest wolna amerykanka. Kiedyś była książka "Linux hackers
guide", traktująca właśnie o pisaniu sterowników (jeszcze w erze kernela
2.2 i 2.4). Czy teraz wyszło coś nowszego? Konkretne pytanie: skąd
przeciętny developer ma czerpać obecnie informacje o niskopoziomowym
działaniu Linuxa (bez rozwiązania ostatecznego czyli czytania źródeł
kernela)? Czyli np. jak we własnym programie "zaczaić się" na
podłączenie urządzenia przez USB?

Druga sprawa to program instalacyjny; powiedzmy, że wydajemy
oprogramowanie komercyjne bez kodu źródłowego. Dla Windows wystarczy
jeden plik .exe instalatora i każdy będzie zadowolony. A Linux? Ile
dystrybucji tyle pomysłów - po co tak komplikować świat? Pliki .deb,
.rpm, do tego konieczność wspierania kilku wersji biblioteki glibc.

Czekam z utęskieniem, aż pozostaną na placu boju 2-3 dystrybucje
instalowane u 90% linuxiarzy. A może już teraz tak jest? Ubuntu, Fedora,
OpenSuse i dalej długo nic.

Ale zrobił się OT i NTG...

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

Pan Adam Dybkowski napisał:

>>> Ja bym stawiał raczej na 1% udział linuksa w rynku systemów "biurkowych".
>>
>> Kwestia udziału jest trochę z boku. Sterowniki linuksowe jednak powstają,
>> nie tylko w czynie społecznym, a producenci sprzętu coraz częściej
>> dołączają katalog "linux" do nośnika z oprogramowaniem. Tylko sposób
>> w jaki to robią, woła o pomstę do nieba. Wygląda to tak, jakby uważali,
>> że jak ktoś używa Linuksa (obojętnie czy na biurku czy gdzie indziej),
>> to o niczym innym nie marzy, jak tylko o edytowaniu emacsem plików
>> konfiguracyjnych i o tworzeniu diwajsów mknodem. Nie zauważają faktu,
>> że dostępne są w tym systemie metody [auto]konfiguracji urządzeń P'n'P
>> o wiele doskonalsze niż w Windows (taka jest przynajmniej moja opinia
>> wynikająca z obserwacji, a także z niniejszej dyskusji).
>
> W każdej dystrybucji / kernelu? ;)

To akurat nie było o kernelu. O udev było i o podobnych takich.

> Problem z Linuksem (z punktu widzenia developera) polega na tym, że mało
> co jest ustandaryzowane. W Windows dokładnie wiadomo, jak się zachowa
> każda wersja systemu po podpięciu nowego urządzenia, np. na USB. Te
> mechanizmy opisuje dość dokładnie Microsoft w dokumentacji MSDN. Obecnie
> wystarczy wspierać trzy wersje systemu: Windows 2000, Windows XP i Vistę
> - i to pokrywa zdecydowaną większość użytkowników Windows na świecie.
> Dużo mechanizmów działa identycznie od lat więc i programy/sterowniki są
> w pewnej mierze dość uniwersalne.

Bo jak są tylko trzy, to wystarczy wspierać trzy. Tym niemniej to
właśnie w Windows zdarzało mi się, że po zainstalowaniu sterownika
karty graficznej przestawał działać APM (komputer się nie wyłączał)
a po odinstalowaniu działał znowu. Takich przykładów można wymienić
więcej, ale nie chodzi o licytację (ja zresztą nie znam szczegółowo
innych, plotek powtarzać nie lubię, a ten jeden pamiętam ze swoich
nielicznych kontaktów z tym systemem).

> A dla Linuksa jest wolna amerykanka. Kiedyś była książka "Linux hackers
> guide", traktująca właśnie o pisaniu sterowników (jeszcze w erze kernela
> 2.2 i 2.4). Czy teraz wyszło coś nowszego? Konkretne pytanie: skąd
> przeciętny developer ma czerpać obecnie informacje o niskopoziomowym
> działaniu Linuxa (bez rozwiązania ostatecznego czyli czytania źródeł
> kernela)? Czyli np. jak we własnym programie "zaczaić się" na
> podłączenie urządzenia przez USB?

Gdy padło stwierdzenie na temat "dalekiej od doskonałości obsługi USB
w linuksie", spodziewałem się właśnie takiej argumentacji. Z tym to
ja mogę się nawet zgodzić. Nie ma sterowników? Nie ma, bo nikt nie
napisał. A nie napisał, bo mu się nie chciało, nie umiał, nie miał
książki o hakowaniu kernela 2.6, niedobry producent krzemowego szpeju
nie dał dokumentacji, itd. Tak rzeczywiście bywa, chociaż z drugiej
strony dawno już nie spotkałem się z problemem, że czegoś nie mogę
użyć pod linuksem, bo brakuje sterowników i absolutnie nikt
z konkurencji nie produkuje czegoś podobnego, co jest wspierane.

Dyskusja poszła jednak w inną stronę -- że niby linux po ponownym
włączeniu potrafi zamienić miejscami diwajsy, a taki Windows, to
on nigdy, przenigdy. Bzdura, bo jest przecież dokładnie odwrotnie.

> Druga sprawa to program instalacyjny; powiedzmy, że wydajemy
> oprogramowanie komercyjne bez kodu źródłowego. Dla Windows wystarczy
> jeden plik .exe instalatora i każdy będzie zadowolony. A Linux? Ile
> dystrybucji tyle pomysłów - po co tak komplikować świat? Pliki .deb,
> .rpm, do tego konieczność wspierania kilku wersji biblioteki glibc.

No ale przecież to i tak działa. I to całkem podobnie jak w Windows.
To znaczy może tak działać. Ci, co wydają programy bez źródeł (np.
AcrobatReader, GoogleEarth, drivery Nvidii etc) przeważnie robią
to w formie jednego uruchamialnego pliku, który robi to co trzeba.
Raczej nie słyszałem, by ktoś narzekał, że coś w związku z tym nie
działa. A że istnieją jeszcze systemy administracji pakietami? No
to fajnie, one się świetnie sprawdzają w praktyce, daleko lepiej
niż execowe instalatory w Windows.

> Czekam z utęskieniem, aż pozostaną na placu boju 2-3 dystrybucje
> instalowane u 90% linuxiarzy. A może już teraz tak jest? Ubuntu,
> Fedora, OpenSuse i dalej długo nic.

Może rzeczywiście już tak jest. A jeśli nie jest, to co to zmienia?
Jest sto pięćdziesiąt dystrybucji, ileś wersji kernela, modyfikowanych
i nie, glibców też trochę, programy kompiluje może 1% juzerów, reszta
instaluje binarki. I jakoś to działa, rzadko coś się ze sobą gryzie.
Ja mogę zapomnieć o tym APM i drajwerach do S3, mogę uznać, że jest
pod tym względem tak samo jak w Windows. Ale tam są tylko trzy niemal
identyczne mechanizmy działające od lat podobnie. To chyba bardzo
dobrze świadczy o podstawach systemu, który musi działać w dużo
trudniejszych warunkach.

> Ale zrobił się OT i NTG...

Ja tam mogę przestać w każdej chwili, ale nikt mi tego jeszcze
nie zasugerował (wiem, wiem, wszyscy mają mnie w killfajlu).

--
Jarek

do góry

On Fri, 07 Aug 2009 23:39:33 +0200, Adam Dybkowski wrote:
>Problem z Linuksem (z punktu widzenia developera) polega na tym, że mało
>co jest ustandaryzowane. W Windows dokładnie wiadomo, jak się zachowa
>każda wersja systemu po podpięciu nowego urządzenia, np. na USB. Te
>mechanizmy opisuje dość dokładnie Microsoft w dokumentacji MSDN.

ktory rozdzial ?

>Obecnie
>wystarczy wspierać trzy wersje systemu: Windows 2000, Windows XP i Vistę
>- i to pokrywa zdecydowaną większość użytkowników Windows na świecie.

I Windows 7 i wersje 64-bit ?

>Dużo mechanizmów działa identycznie od lat więc i programy/sterowniki są
>w pewnej mierze dość uniwersalne.
>
>A dla Linuksa jest wolna amerykanka. Kiedyś była książka "Linux hackers
>guide", traktująca właśnie o pisaniu sterowników (jeszcze w erze kernela
>2.2 i 2.4). Czy teraz wyszło coś nowszego? Konkretne pytanie: skąd
>przeciętny developer ma czerpać obecnie informacje o niskopoziomowym
>działaniu Linuxa (bez rozwiązania ostatecznego czyli czytania źródeł
>kernela)?

Ale to najpewniejsze zrodlo :-)

>Druga sprawa to program instalacyjny; powiedzmy, że wydajemy
>oprogramowanie komercyjne bez kodu źródłowego. Dla Windows wystarczy
>jeden plik .exe instalatora i każdy będzie zadowolony.

msi sie teraz chyba promuje ?

>A Linux? Ile
>dystrybucji tyle pomysłów - po co tak komplikować świat? Pliki .deb,
>.rpm, do tego konieczność wspierania kilku wersji biblioteki glibc.

W sumie to chyba tez mozesz jako "exe" dystrybuowac.

Czy nawet w spakowanych zrodlach - instalator rozpakuje, skompiluje i
zainstaluje :-)


J.

do góry

On 6 Sie, 08:12, "MaW" <m...@p...onet.nospam.pl> wrote:
> Użytkownik "dr Vito" <d...@p...onet.pl> napisał w
wiadomościnews:4d76cadd-215c-4271-b032-d7f144902392@
r38g2000yqn.googlegroups.com...
> Witam,
>
> Czy mozecie poradzic mi jakiś modem GSM, ktory moglbym podpiąć do
> serwera z systemem linux?
> Komunikacja po RS232 (serwer<>modem), najlepiej jakby sie dalo z
> jakims istniejącym oprogramowaniem (np. GNOKII).
>
> Od kilku lat używam z powodzeniem siemensa tc35i
> o taki:http://karczpolska.pl/modemy/modem_gsm_siemens_
tc35t.shtml
> zasilanie zewnetrzne wiec odpadają problemy z bateriami/ładowaniem - po
> prostu zasilacz podpinasz do UPSa do którego masz wpiety serwer, program do
> obsługi sam napisałem w jedno popołudnie - Perl + biblioteka Device-Gsm
zwww.cpan.org. U mnie to chodzi pod Solarisem i wysyła smsy z powiadomieniami
> w razie jakiejś awarii/przegrzewania serwerowni .
>
> MaW


Witam,

http://allegro.pl/item705562666_terminal_siemens_tc3
5.html

To dobra cena?

Pozdrawiam,
dr Vito

do góry

On Sat, 8 Aug 2009 00:15:08 -0700 (PDT), dr Vito wrote:
>> Od kilku lat używam z powodzeniem siemensa tc35i
>> o taki:http://karczpolska.pl/modemy/modem_gsm_siemens_
tc35t.shtml
>> zasilanie zewnetrzne wiec odpadają problemy z bateriami/ładowaniem - po
>> prostu zasilacz podpinasz do UPSa do którego masz wpiety serwer, program do
>> obsługi sam napisałem w jedno popołudnie - Perl + biblioteka Device-Gsm
zwww.cpan.org. U mnie to chodzi pod Solarisem i wysyła smsy z powiadomieniami
>> w razie jakiejś awarii/przegrzewania serwerowni .
>
>http://allegro.pl/item705562666_terminal_siemens_tc
35.html
>To dobra cena?

Nie lepiej kupic telefon C/M/S35 ? kosztuje jakies grosze, dziala
podobnie, tylko kabelek trzeba kombinowac bo dane i zasilanie na
jednym laczu ..

J.

do góry

On 8 Sie, 10:02, J.F. <j...@p...onet.pl> wrote:
> On Sat, 8 Aug 2009 00:15:08 -0700 (PDT),  dr Vito wrote:
> >> Od kilku lat używam z powodzeniem siemensa tc35i
> >> o taki:http://karczpolska.pl/modemy/modem_gsm_siemens_
tc35t.shtml
> >> zasilanie zewnetrzne wiec odpadają problemy z bateriami/ładowaniem - po
> >> prostu zasilacz podpinasz do UPSa do którego masz wpiety serwer, program do
> >> obsługi sam napisałem w jedno popołudnie - Perl + biblioteka Device-Gsm
zwww.cpan.org. U mnie to chodzi pod Solarisem i wysyła smsy z powiadomieniami
> >> w razie jakiejś awarii/przegrzewania serwerowni .
>
> >http://allegro.pl/item705562666_terminal_siemens_tc
35.html
> >To dobra cena?
>
> Nie lepiej kupic telefon C/M/S35 ? kosztuje jakies grosze, dziala
> podobnie, tylko kabelek trzeba kombinowac bo dane i zasilanie na
> jednym laczu ..
>
> J.

Wydaje mi się, ze nie lepiej. Powodem jest chociażby zasilanie.
Poza tym urządzenie ma być wykorzystane w profesjonalnym projekcie.

Pozdrawiam,
dr Vito

do góry

Jarosław Sokołowski pisze:

> Dyskusja poszła jednak w inną stronę -- że niby linux po ponownym
> włączeniu potrafi zamienić miejscami diwajsy, a taki Windows, to
> on nigdy, przenigdy. Bzdura, bo jest przecież dokładnie odwrotnie.

Masz rację, pewnie mi się wydawało jak karty dźwiękowe i telewizyjne
zamieniały się numeracją pod linuksem (bez fizycznej zmiany portu/gniazda).


--
przeciez moje rozumowanie bylo bez skazy,
no sam bym wskoczyl do tego wulkanu,
ale kto by tak pieknie gwizdal...

do góry