Uściślę: user może sobie instalować czy tworzyć programy w swoim ~ (choć zazwyczaj nie ma dostępu do głównego managera pakietów rpm/deb/inne - ale może go sobie jakoś zainstalować w swoim home)

$ cd ~
$ pwd
/home/user/max
$ touch program
$ vi program bla bla bla
$ chmod 500 program
$ ./program

a to gdzie są zainstalowane programy, jakie są do nich ścieżki, w ogólności definiuje POSIX, ale gdzieniegdzie widać zaszłości z UNIX Wars - starej historii jak się System V rozdzielił.


Mi podoba się traktowanie userów jak programy:
/usr/people/max
:D

Programy nie są trzymane w /home. Tak jak napisałem system jest oddzielony od uzytkownika i można profil użytkownika wywalić - a programy zostaną.
Programy może oficjalnie instalować tylko administrator i binarki są zazwyczaj w
/usr/bin
albo
/usr/sbin (programy dostępne tylko dla administratora).

Wyszukiwane są tak jak pali napisał poprzez PATH. Niewazne w którym katalogu jesteś - możesz zazwyczaj odpalić dowolny program z dowolnego miejsca wpisując jedynie nazwę binarki.
Oczywiście nie ma problemu aby użytkownik przemycił jakąś binarkę do swojego katalogu home i ją tam uruchomił. Musi być jednak zgodna z resztą systemu (bibliotekami w /lib itd).

A ustawienia są faktycznie ukryte, bo przecież nie ma potrzeby ich zazwyczaj oglądać z managera plików.

Kropka ukrywa, ale to nie ma nic do rzeczy.

Masz zmienną PATH, która zawiera ścieżki do binariów.
Możesz dopisać swoją ścieżkę do PATH albo:

$ cd /home/user/max
$ pwd
/home/user/max
$ ls -la
.bar r-x------
foo r-x------
iga_wyrwal.jpg r--------
$ ./foo
$ ./.bar

Wyboldowane istotne - tak uruchamiasz program w bieżącym katalogu, którego nie ma w PATH: ./
W OS X jest xterm?
Wiesz, że warszawskie hipstery używają vi? ;)
Masz go zainstalowanego; przynajmniej był we wcześniejszych wersjach OS X, nowszych nie widziałem.

Zaraz, zaraz.... A czy przypadkiem pliki/foldery zaczynajace sie odk ropki nie sa w UNIXach defaultowo ukrywane? Jesli tak to jak uruchomic program, skoro jego dane so w /home/user/ ukryte? Chyba ze uruchamia sie go jeszcze inaczej...?

Moze ktos wydzielic? Bo sie fajna dyskusja o UNIXach wywiazala...

Czyli jest to rozwiązanie podobne jak w PC-BSD (pakiety pbi).

Odpowiednikiem linuksowym jest pakiet, który jednak nie zawiera bibliotek a jedynie ich listę. I program jest rozsiany po całym systemie (binarka ląduje do /usr/bin, grafiki do /usr/share , biblioteki do /lib itd).
Śmietnika nie ma bo pakiet trzyma całą listę plików, ale można go zrobić instalując/kompilując programy ze źródeł - bo jest to robione poza managerem pakietów i nie wiadomo co gdzie poleciało.

Generalnie widzę że rozwiązanie w OSX jest bardzo fajne :taktak:

Co do ustawień to w linuksie są dość przemyślane i logiczne, ale z innego punktu widzenia (to system dla wielu użytkowników).

/etc - ustawienia systemowe (wspólne dla wszystkich - moze je modyfikować admin)
/home (gconf też jest w home) - ustawienia dla danego usera

Ustawienia i profile użytkowników w /home mozna wywalić bez żadnej szkody dla działania systemu.

Niestety już w /home panuje pewna dowolność, choć większość programów na szczęście trzyma się zasad.
/home/user/.config/nazwaprogramu (konfiguracja)
/home/user/.cache/nazwaprogramu (cache)
/home/user/.nazwaprogramu (dane)
Ale to nie jest w żaden sposób wymagane. Np Firefox ma profil który ma jednocześnie ustawienia i dane i trzyma to w /home/.mozilla, a cache tam gdzie trzeba.

gconf jest odpowiednikiem rejestru ale tak naprawde są to też pliki w /home/.gconf. Można to potraktować jako ustawienia środowiska danego użytkownika.

Juz tlumacze.

W OS X mamy application.app, ktory w rzeczywistosci jest folderem i zawiera w sobie (w duzym uproszczeniu):
- Program
- Ikone, jaka ma sie prezentowac w /Applications i w docku
- Ustawienia lokalizacji dzialajace automatycznie w zaleznosci od ustawionej wersji jezykowej systemu
- Niezbedne zasoby, czyli grafiki, dzwieki, biblioteki, obiekty itd.

Po pierwszym uruchomieniu zakladany jest plik (JEDEN!) z ustawieniami danego programu (w zaleznosci od tego czy tylko dany uzytkownik czy tez wszyscy beda z niego korzystac - w ~/Library/Application Support lub w /Library/Application Support).

Od Liona dochodzi jeszcze generowany dla kazdej aplikacji na biezacoplik SavedState (nie ma funkcji "Zapisz" - wszystkie zmiany zapamietywane sa na biezaco, automatycznie).

Instalacji, czyli rozpanoszenia sie po systemie, wymagaja najczesciej jedynie programy korzystajace z tzw. rozszerzen jadra (KEXT = Kernel Extension), a spotkalem takich w zyciu raptem kilka - Parallels Desktop, ktory jako VM instaluje wirtualne interfejsy; DisplayPad, ktory robi z iPada dodatkowy monitor (wiec w sumie tez wirtualne wyjscie) czy Soundflower.

Zgodnie z regilaminem Mac App Store KAZDY program musi dzialac w "piaskownicy" i ZADEN z nich nie moze korzystac z zewnetrznych rozszerzen jadra. Wiec albo sie chlopaki poprawia, albo nigdy do MAS nie trafia...

M@X, co dokładnie masz na myśli mówiąc "ini, rejestr i DLL Hell".
Uzywałem Windows wiele lat i się z tym ostatnim nie spotkałem.
Ini i rejestr to norma, linuks wcale nie jest lepszy, a nawet ma jeszcze gorzej.
Ustawienia mogą być w:

/etc
/home/.config
/home/nazwa_programu
gconf (to taki rejestr, zależy jakiego środowiska używamy. gconf jest dla gnome, inne środowiska mają swoje)

a może nawet jeszcze gdzieś. A "dll-hell" przy "dependency hell" to raj.

A biblioteka moze być w linuksie w jednej wersji, o ile wersja nie jest nazwą pakietu/pliku. Np libavcodec53 i libavcoded54 mogą współistnieć, ale już glibc jest obowiązkowo w jednej wersji.
Ale w obrębie libavcodec53 też są wersję, więc wcale nie jest tak różowo. Jeżeli programowi nie odpowiada - to nalezy go przekompilować :/ A nie zawsze sie da - czasem trzeba wprowadzić poprawki w źródle. Stare wersje pakietów wypadają z repozytorium. Dla developera to masakra. Wyobraźmy sobie Adobe wydające darmowe update każdej nowej i starej wersji co pół roku i dla każdej dystrybucji.

Drzewa zależności załatwiają większość sprawy. Ale nie wszystko. Nie zawsze są dobrze ułożone. Czasem spełnienie zależności nie jest możliwe np. ze względu na konflikt z innym programem. Czasem wywalenie pakietu nie będącego w zależnościach może uwalić program, czasem program instaluje syf którego wcale nie potrzebuje (to jest zgłaszane jako bugi).
I zostaje problem starych pakietów, powiedzmy libavcodec51 które już nie są używane, ale zostały kiedyś zainstalowane (są programy do ich wynajdywania, ale nie zawsze ich usuwanie jest bezpieczne).

Co do OSX to nie wiem dokładnie jak działa, ale być może tak jak PCBSD - wszystkie wymagane biblioteki są instalowane do katalogu z programem w wersjach które ten program wymaga. Oznacza to że możemy mieć w systemie 50 wersji tej samej biblioteki, ale to poniekąd strata miejsca i stare programy nie skorzystają z nowych (np szybszych).
Windows wprowadził cos takiego jak WinSxS. W tym katalogu trzymane są właśnie m.in biblioteki w różnych wersjach.

Problem z rozwiązaniem PCBSD to też np. licencja. Nie wolno załączać kodu będącego własnością innej firmy do swojego programu.

Każdy kij ma dwa końce - Linuks zajmuje 4GB i programy zasuwają, bo zawsze maja najnowsze biblioteki skompilowane najnowszym kompilatorem (a gcc naprawde jest świetny i coraz lepszy pod względem wydajności), a Windows zajmuje 20GB i działa tak-sobie, bo odpalanie 10 letniego kodu na najnowszym procesorze nie jest optymalne. Ale za to nie ma dependency hell.

O działaniu OSX nie wiem praktycznie nic.

Nie mam pojęcia jak konkretnie zbudowany jest OS X, ale pewnie jest tam normalny dynamic linker, który ma ułatwione zadanie, bo działa wedle jednej spójnej specyfikacji. Mówiąc w uproszczeniu dynamic linker ma za zadanie odnaleźć potrzebne biblioteki (w trakcie wykonywania programu, a nie kompilacji - w trakcie kompilacji używany jest tzw. linker - to w uproszczeniu ten sam program, ale w innym trybie).

W linuksie jest pomieszanie pomysłów i specyfikacji, stąd czasami d. linker miewał (miewa?) problemy i takie przenoszenie plików wykonywalnych gdziekolwiek w inne miejsce może nie udać się, ale generalnie its work - wszystko jest portable, tylko manager pakietów sobie potem nie poradzi, o ile mu jakoś nie powiemy.

W sumie nie wiem, bo nie kłopoczę się tym. Ma działać, a jak nie to mail do admina :)

To prawda - w repozytoriach Linuxa mamy drzewa zaleznosci ktore zalatwiaja sprawe, a w OS X z definicji kazdy program jest "Portable" - kopiujesz go do katalogu z programami i dziala. Po prostu.

Microsoft zawalil kilkanascie lat temu. Teraz nie dadza juz rady wyjsc z plataniny INI, rejestru i "DLL-Hell".

Używanie programów portable daje ograniczoną kontrolę.

Taki program może korzystać z bibliotek dynamicznych (dll) w systemie, chyba że jest skompilowany statycznie. Nie mam pojęcia jak to sprawdzić w Win, ktoś wie?
BTW StarOffice był kiedyś kompilowany statycznie.

Nie wiemy też czy taki program czegoś gdzieś nie zapisuje, w systemie plików czy w specpliku zwanym rejestrem.

Portable w zasadzie dają nam tylko ograniczoną pewność, że instalator nie zapisał czegoś tu i tam. Tym powinien sterować porządny manager pakietów (jak manager rpm czy deb), którego w Windowsie brak i to jest Windowsa wielkim problemem.

Uruchamianie w piaskownicy pozbawione jest tych wad - wydostanie się z piaskownicy to wyższa szkoła jazdy. No ale wydajność etc

Ja stosowałem metodę:

Zainstalować na Virualboksie, skopiować sobie gotowy katalog.
W większości przypadków gdy aplikacja nie jest zbyt skomplikowana - działa.

Dlatego też warto szukać programów/aplikacji, których nie trzeba instalować. Sam się tak staram robić, i nawet jeśli jakiegoś programu nie ma w wersji "portable", to próbuję rozpakować instalator. Jeśli program nie ruszy, szukam zamiennika. Instaluję tylko w ostateczności. :)

No oczywiście, że się nada. Kwestia jeszcze prostoty obsługi ( dla początkującego usera) i polskiego, jsanego interfejsu.


Ja sie nię kocham. Nero to bardzo dobry program pod względem użytkowym (być może nawet najlepszy), jednak głębokość jego ingerencji w system jest dla mnie nie do przyjęcia. Nawet przy instalacji typu "custom" pozostawia w systemie jakieś kolosalne ilości śmieci, których nie można po prostu odinstalować i usunąć bez wielu godzin ciężkiej harówki. W dodatku drogi. Używałem, sprawdziłem - dziekuję - do widzenia bardzo!

Ja nie twierdze że Nero jest złe.
Aktualnie nic o nim nie twierdze, bo tyle mnie obchodzi co zeszłoroczny śnieg.

Nie mam go, bo mi się nie chce go kupować. Bo ... po co?
Nero 5.5 miałem oryginał dodany do spawarki LG.

Jedyne co bym chciał kupić to porządny program do authoringu płyt bluray.
Problem w tym, że wszystkie programy renomowanych firm jakie sprawdzałem to jakieś g...o.

Andy, ale jest wersja za darmo? Bo ja nie widzę, oprócz tych czasówek dodawanych do napędów.