J.F. pisze:

>> 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 ?

Polecam zacząć lekturę tutaj:
http://msdn.microsoft.com/en-us/library/ms791699.asp
x

A o sterownikach USB do Visty:
http://msdn.microsoft.com/en-us/library/aa476431.asp
x

Linuksiarzom daleko jeszcze brakuje do dokumentacji chociażby takiej jak
udostępnia Microsoft o systemach Windows. Pomimo że wiele mechanizmów w
Linuxie wcale nie jest dużo prostszych, a napisanie sterownika do
jakiejś pośredniej warstwy wymaga przekopania źródeł kernela, demonów i
pobocznych procesów. No ale w końcu nie ma się co dziwić: pracownikom
Microsoftu zapewne płaci się za pisanie dokumentacji.

>> 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 ?

Prawda, już 22 października premiera siódemki. :)
A na razie olewając powyższy system i wszystkie wersje 64-bitowe (XP i
Vistę) traci się na większości rynków conajwyżej kilka procent klientów.

>> 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 :-)

Mimo to zbyt blisko współpracujące z wieloma demonami, aby o nich też
można byłoby zapomnieć. No a do tego w istocie niełatwo prześledzić na
podstawie samych źródeł, co się właściwie dzieje w systemie po
przykładowym podłączeniu urządzenia USB. Przez wiele plików trzeba się
przekopać i to bez gwarancji sukcesu. Lepsze byłoby zdebugowanie
zachowania kernela krok po kroku, chociażby w środowisku wirtualnym. Ale
jakich do tego użyć narzędzi?

>> 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 ?

Od lat Microsoft próbuje wciskać taki kit ale to nie nam. Pierwszy z
brzegu instalator małej aplikacji zrobiony przy pomocy np. NSIS jest 3x
mniejszy niż pakiet .msi.

>> 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.

Taa. Jak skompiluję u mnie - to na innym komputerze nie zadziała bo
cośtam. A to też Linux na 32-bitowym x86. W Windows rzecz niespotykana,
trzeba bardzo się starać aby skorzystać z funkcji API dostępnej tylko
np. w Viście.

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

Heh, w komercji właśnie o to chodzi, aby nie rozdawać źródeł.
Spojrzałem właśnie do "gotowców" pod Linuxa: instalka Firefoxa jest w
formacie .tar.bz2 (czyli żadne tam binaria tylko zwykłe archiwum),
Thunderbird podobnie (.tar.gz), Adobe Reader pod Linuxa - pełen wybór
(.bin, .tar.gz, .rpm, .tar.bz2, .deb), Eagle - do pobrania skrypt
wspomagający instalację (sic!). Raczej nie chodziło mi o to, abym musiał
dla Linuxa generować kilka różnych instalatorów.

Chyba z tego wszystkiego zacznę pisać w Javie - jeden uniwersalny format
instalek (.jar) i binariów, a pójdzie tak samo pod każdym systemem. Oby
się tylko trzymać najnowszej wersji JRE.

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

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