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

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

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

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.

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

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.

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

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.

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.

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

Ale wydaje mi sie że taki program nie zadziała jeżeli będzie wymagać bibliotek innych niż administrator zainstalował w /lib.
Bo program pewnie ich tam będzie szukać
Nie sprawdzałem tego :hmm:

Terotetycznie w OS X tez mozna ladowac do ~/Applications, ale nie znam nikogo kto tak robi.

@pali - nie ma Xterm, jest X11 :-P. Jako skladnik systemu. Do Tigera bodajze przy instalacji, w Leo i Snow Leo do wybrania podczas instalacji a od Liona do sciagniecia za friko poprzez klikniecie w ikone X11 ;-).

Hipsterzy to mnie moga :-P. Uzywam nano jesli potrzebuje pewnosci (np. Edytuje systemowy plist i potrzebuje wymusic zapis przez sudo), ale na ogol z lenistwa... TextEdit :-P

Tak przy okazji, jak sie kiedys bawilem w Ubuntu - bardzo wkurza mnie w Linuxie, ze uzytkownik nie moze zaczynac sie z duzej litery. Kwestia estetyczna, ale dobrze wiecie jak bardzo zwracam na to uwage...

ja używam najczęściej.... mcedit. Taka pozostałość po czasach DOSa i 386DX/40 ...
albo graficznie Pluma (gedit). Jestem leniwy i nigdy nie chciało mi się uczyć vima.

Za jakiś czas X11 będzie też opcjonalnym komponentem Linuksa.
Na horyzoncie Wayland 1.0.
Ze dwa lata miną przynajmniej zanim go wdrożą, ale plany są wielkie a rozwój bardzo szybki.

Gdyby w razie ktoś nie zauważył, temat brzmi "Jakie polecacie programy do Visty?".

Dlatego się podłącze do tematu,wcześniej było o programach do wypalania płyt,na chwilę chcę powrócić do tego tematu. Kupiłem dwie płyty CD-R Sony, zainstalowałem Ashampoo -prędkość wypalania max,pliki WMA, no i bum.Ten program nie wypala płyty na audio CD;)nie wiem może coś trzeba pogrzebać w ustawieniach,więc wypaliłem z MP3 na tym programie .Zainstalowałem Nero 6(Ver.6.6.0.19b)-tylko same Nero Express,prędkość max,pliki WMA i gitara-Nero wypala te pliki.Obie Sony odtworzyłem w odtwarzaczu kompaktowym - płyta wypalona na Ashampoo - trzeszczy;) a ta na Nero - jest okey. Ponowiłem to drugi raz, i to samo.??? ;)