Valve pracuje nad uniwersalnym instalatorem Steam dla Linuksa

Na Gentoo wystarczy ebuild z kategorii virtual.

Albo niech wrzuca wszystko do /opt i po ptokach.

sciągasz plik "bin" ze strony na przysłowiowy pulpit -> dwuklik na pliku -> podajesz hasło -> instalator pobiera wszystkie pliki i biblioteki do /opt/steam i umieszcza skróty. Fajnie by było jak instalator by miał wszystkie wymagane bibioteki do swego działania statycznie polinkowane. Starsze instalatory z gier linuksowych, miewają niekiedy problemy z uruchomieniem na nowszych distrach bo brakuje starszych bibliotek w systemie.

Lepiej nie bin, a zwykły skrypt sh (prosty skrypt zawierający w sobie plik tar.bz2 (lub inna kompresja (gunzip?) ogólnodostępna pod linuxem), który sam rozpakuje instalator uruchomi go (czy będzie on konsolowy czy okienkowy to już dla mnie nie ma znaczenia, ale raczej wybiorą instalację okienkową i instalator będzie wyglądał podobnie do Windowsowych gdzie na początku zdecydujesz czy ma zainstalować w systemie (podajesz hasło i program wrzucony jest do /usr/share lub /opt i podlinkowany do home)) itp lub lokalnie na użytkownika to w ~/.valve się zainstaluje i program zostanie dodany do lokalnego menu uruchomieniowego).
Ot rozwiązanie – tak robi każdy zamknięty czy komercyjny soft – nawet narzędzia programistyczne czy sterowniki (przykładowo CUDA czy sterowniki do kart Nvidii).
Nic lepszego nie wymyślą (może komuś się nie podobać, że nie wykorzystają bibliotek systemowych, że duplikacja danych itp. ale znacznie łatwiej w ten sposób zapanować nad różnymi wersjami bibliotek, wymaganiami ich pod różnymi dystrybucjami itp.).

Tak, o ile ze steama korzysta tylko jeden użytkownik to katalog domowy jest świetnym rozwiązaniem. Na marginesie wspomnę że czas chyba by developerzy pomyśleli nad uporządkowaniem struktury katalogu domowego, bo jest tam syf straszny.

Coraz więcej developerów umieszcza configi w katalogu .config, co trochę poprawia sytuację ;)

Problem w tym, że konfiguracja to mało znacząca sprawa – pliki tymczasowe, historia, autobackup, pluginy, rozszerzenia itp, trzeba gdzieś trzymać… to i konfigurację trzyma się razem. Rozwiązaniem problemu byłoby zarządzenie projektowe o wykorzystywaniu katalogu .appdata/.apps/.userdata… czy jak tam sobie to nazwą i tam umieszczać katalogi odpowiednich programów (czytaj jeden ukryty katalog w domowym zamiast całej masy).
Katalogi .config czy .local tak na prawdę to nic nie załatwiają, a jedynie jeszcze bardziej rozpraszają wszystko.
Tylko, że sposób rozwiązania problemu w dobry sposób trzeba narzucić z góry… ale nikt nie ma za bardzo władzy do narzucania takich norm w wypadku otwartych systemów.

Wtedy narusza się ideę katalogów w Linuksie. Jeżeli mamy binarki w /usr/bin, biblioteki w /usr/lib, a configi systemowe w /etc, to analogicznie powinno się trzymać dane w katalogu użytkownika – configi w ~/.config, cache w ~/.cache, pluginy w ~/.plugins, a pliki tymczasowe, wyjątkowo, w /tmp (bo niektórzy mają zamontowane /tmp np. w ramie). I wtedy też jest porządek.

No, niezły porządek, jak aplikacja A ładuje pluginy aplikacji B, bo wszystkie są w katalogu .plugins :D Linux zawsze będzie miał burdel z takimi rzeczami, bo sama filozofia wielu dystrybucji i brak konkretnych ram działania do tego prowadzi.

Źle mnie zrozumiałeś.
Aplikacja A: ~/.plugins/A/
Aplikacja B: ~/.plugins/B/

Taka idea katalogów istnieje w katalogach systemowych i nie jest to idea linuksowa, a uniksowa i linux od unixa przejął też ukryte katalogi programów w katalogach domowych. Wprowadzanie ~/.[config,local,cache…] to błąd (już pomijając, że katalog .plugins wcale nie istnieje i nikt takiego nie używa)… to są substytuty rozwiązania, dobrego czyli jednego katalogu na wszystko (a to, czy już rozrzuci się tam po katalogach ~/.apps/ katalogi: etc, cache, plugins, backups… (ile by nie wymyślił to i tak będzie mało, bo różnorodność plików przechowywanych jest olbrzymia, dlatego do domowego wybrano katalogi z nazwami programów) czy katalogi programów to jest rzecz wtórna).

Masz rację, pierwowzorem był Unix. Katalogu ~/.plugins nie ma, ale – wg mnie – lepiej by było, gdyby np. (wzięte z mojego katalogu) zamiast ~/.mozilla/plugins/ i ~/.vim/plugins/ były ~/.plugins/mozilla/ i ~/.plugins/vim/. Wtedy od razu wiesz, czego szukać.
Na Windowsach, wbrew pozorom, też nie ma czegoś takiego jak jednolita struktura katalogów. Prawie każda aplikacja trzyma swoje dane gdzie popadnie.
Abstrahując do tego, wydaje mi się, że akurat trzymanie danych użytkownika to najmniejszy problem dla Steama – wystarczy zrobić ~/.steam, jak to zrobił minecraft i po sprawie. Problem jest z wersjami różnych bibliotek, przede wszystkim glibca. Ale w takim wypadku wystarczy po prostu wypisać wymagania, umieścić na stronie internetowej i po sprawie.

Nie – zazwyczaj wiesz, że szukasz czegoś w danym programie, ale bywa, że nie wiesz czego – jak co nazwali, często nie wiesz czy szukasz pluginu, skryptu czy addona. Dlatego lepsze jest przechodzenie "program" -> "co z niego szukamy". Struktura uniksowa dla katalogów systemowych nie jest tak rozproszona dla czytelności (tu działa wręcz odwrotnie), a tylko dlatego, aby nie kopiować kodu – aby programy korzystały ze wspólnych bibliotek, a nie każdy miał swoje (co w wypadku niekompatybilnych wersji bibliotek jest jednak bolesne).

Nigdzie nie pisałem, że Windows ma jednolitą strukturę, ani dobrze przemyślaną – moje odczucia są wręcz przeciwne (nie ma nawet wyszczególnionego katalogu z programami – ma namiastkę w postaci program files, ale jest to słabo zarządzane i słabo wymagane na twórcach aplikacji).

Co do glibc to mogą problem zupełnie olać – ABI jest stabilne (ostatnia poważniejsza zmiana ABI to kilkanaście lat temu). Wystarczy libc.so.6 – do zmiany ABI i libc.so.7 daleko – mniejsze zmiany dla zamkniętych programów nie są istotne (dalej mi działają programy kompilowane 5 lat temu, mimo aktualnego glibc 2.17). Problemem są biblioteki szeroko używane, ale zmieniające ABI co chwilę (jak libpng i masa innych które co chwilę wydają wersję niekompatybilne ze sobą).

Ale, na przykład, wszystkie pliki systemowe (globalne) są trzymane właśnie w ten sposób – binarki w /usr/bin, biblioteki w /usr/lib, a pliki konfiguracyjne w /etc (oczywiście to tylko przykłady). Dzięki temu po pierwsze nie potrzebujemy powielać tych samych bibliotek wraz z każdym programem (jak to ma miejsce w przypadku Windowsów czy MacOSów, gdzie pisząc program np. pod Qt, musimy dołączać wszystkie potrzebne biblioteki, QtCore, QtGui, etc etc), a po drugie szukając danego elementu, wiemy od razu gdzie szukać – i nie musimy się zastanawiać nad strukturą katalogów każdego innego programu.

Tak – brak powielania kodu jest fajny dopóki żyjemy w idealnym świecie i ABI zmienia się bardzo rzadko… w świecie w którym żyjemy bezpieczniej jest zabrać cały zestaw ze sobą i tak go dystrybuować. W wypadku stosowania /apps/NAZWA/ i tu katalogi wymagania katalogów etc, lib, bin… dają Ci znajomą strukturę z dużo przyjemniejszym opakowaniu (wiesz, że w etc znajdziesz konfigurację tylko tego programu i nie pomylisz z innymi plikami). Jedyny minus to brak współdzielenia kodu (co pod linuksem w wypadku większości aplikacji byłaby wadą, ale w wypadku zamkniętych już niekoniecznie, przez niestabilności ABI w bibliotekach).

" wystarczy zrobić ~/.steam, jak to zrobił minecraft i po sprawie. "
No przecież cała dyskusja polegała na tym, żeby zrobić z tym jakiś porządek, a nie każda aplikacja będzie robić swój katalog w katalogu użytkownika domowego. Mniejsza już o to jak to byłoby rozwiązane, ważne, żeby ktoś w końcu zrobił porządek. Mam chyba z 50 takich katalogów. Dobrze byłoby trochę zhierarchizować tę strukturę.

@marcinsud: Pod linuksem program nie szuka bibliotek w katalogu z aplikacją (to nie windows z ich dll który tak się zachowuje) i szuka ich w zdefiniowanych przez dystrybucje katalogach systemowych. Pod Linuksem program musi mieć skrypt startowy, który modyfikuje zmienną środowiskową LD_LIBRARY_PATH i podaje katalog w którym ma szukać przed systemowymi (wystarczy usunąć ten katalog lub podlinkować ten katalog do katalogu systemowego (pamiętając wcześniej o skopiowaniu bibliotek na zamkniętych licencjach których w systemie nie ma) jeśli chce się używać systemowych bibliotek (tzn o ile ma się odwagę tak robić, bo nikt nie daje gwarancji zgodności z daną wersją biblioteki, nikt nie daje gwarancji, że biblioteka była tak samo skompilowana (przykładowo jedna flaga inna przy kompilacji biblioteki może spowodować wywalanie się programu), a nawet jeśli działa i się nie wywala to zawsze mogą być błędy, artefakty, i niestabilność aplikacji – znanie zwiększona jest podatność na to, bo Valve nie będzie rekompilował programu przy każdej aktualizacji którejś z bibliotek i to dla każdej dystrybucji… jak to robią opiekunowie pakietów w dystrybucjach)… co więcej jedna gra może wymagać biblioteki w wersji X, a gra 2 może wymagać biblioteki w wersji Y z niekompatybilnym ABI, więc nie tylko Steam powinien dubliować biblioteki i nie powinno się tego zmieniać, a i każda gra będzie tak robić).

Po co ukrywać katalogi ? Myślę że np. katalog ~/Aplikacje i ~/Konfiguracja czy coś w takim stylu by rozwiązało sprawę.

W sumie może i sam katalog ~/Aplikacje by wystarczył.

W tedy można by rozprowadzać aplikacje jako archiwum lub np. obraz "ISO" i montować dwuklikiem np. w gnome. Wtedy jedyną rzęczą jaką musiał by zrobić użytkownik to zamontować i przenieść znajdujący się tam katalog "steam" czy jak go nazwiemy do katalogu ~/Aplikacje. Prosto.

Rotfl.

Bo to nie są pliki, które chcesz oglądać co dzień tylko raz na jakiś czas – dlatego powinno być to ukryte… i dlatego to jest ukryte dziś.

Racja jak pisałem nie byłem pewien, bo ostatni raz miałem problem z bibliotekami jakieś 5 lat temu i z tego co pamiętam musiałem usunąć je z katalogu jakiejś gry. W każdym razie posiadanie 2 wersji biblioteki też nie jest problemem wystarczy zobaczyć jak to wygląda w /usr/lib/ kwestia tego, czy gra bedzie wołać lib.so czy lib.1.so, lib.2.so etc.

Problemem jest w tym, że dystrybucje utrzymują tylko jedną wersję bibliotek (bo zmiany ABI ich nie dotyczą – wystarczy przebudować zależne aplikacje z nową wersją biblioteki, a źródła i opiekunowie mają się o to martwić, nie twórcy programów) – w wypadku zamkniętej aplikacji nie można na to liczyć (tym bardziej aplikacji przeznaczonej na wiele dystrybucji – musi brać ze sobą jak najwięcej i nie liczyć na to co może być w systemie, a może nie być).

Co do tego o czym piszesz to niby tak jest, ale niektóre biblioteki zmieniają ABI nie zmieniając numerów głównych przez co trzymanie 2ch wersji jest kłopotliwe. Programy linkują do lib.so lub lib.so.Pierwsza_liczba_wersji, a podczas gdy biblioteki zmieniają ABI nawet pomiędzy wersjami takimi jak przykładowo 2.0 do 2.1 (czyli oba mają lib.so.2), więc nie da się ich ze sobą pogodzić w systemie. To o czym mówisz miało rozwiązać problem i w wielu przypadkach wyeliminowało (w bibliotekach trzymających się nowe ABI == nowa wersja). Jednak w praktyce na to liczyć nie możesz i tworząc zamknięty soft musisz biblioteki zabierać ze sobą (lub linkować je statycznie do pliku wykonywalnego).