[Linux] Waar is de programmamap?

[Verwijderd]

Erg pietluttig om hier een topic voor te moeten openen, maar ook na zoeken via Google ben ik er nog niet achter gekomen:

In welke mappen bevinden zich de geïnstalleerde programma's en dus de bijbehorende "exe" bestanden (het zijn geen exe's ik weet het )

Ik ben nu bv. op zoek naar de "exe" van Azureus maar die kan ik niet vinden, ook niet in /usr/bin of /bin.

[Jaap-Jan]

Probeer eens 'which azureus' of 'whereis azureus'. Linux executables zijn overal te vinden: /bin /usr/bin, /usr/bin, /usr/local/bin, /usr/local/sbin, /sbin ~/bin, /opt en ga zo maar even door .

[ Voor 13% gewijzigd door Jaap-Jan op 06-09-2007 22:23 ]

[Verwijderd]

wat is de reden hiervan precies? waarom niet (zoals in windows) één map met alle files van één programma?

is er een makkelijke manier om te achterhalen waar welk programma welke files dumpt? (en dan vooral waar de "exe's" staan)

ps. hoe noem je een 'exe' in linux?

[ Voor 16% gewijzigd door Verwijderd op 06-09-2007 22:24 ]

[Verwijderd]

Verwijderd schreef op donderdag 06 september 2007 @ 22:23:
wat is de reden hiervan precies? waarom niet (zoals in windows) één map met alle files van één programma?

is er een makkelijke manier om te achterhalen waar welk programma welke files dumpt?

Nee. Maar als je een fatsoenlijke distributie gebruikt met een goede package manager, wordt alles toch wel enigszins gestuctureerd bijgehouden. En de reden waarom er dan bijvoorbeeld databestanden, documentatie, manuals, executables en libraries op verschillende plaatsen worden opgeslagen: dit maakt het makkelijker bepaalde dingen op verschillende partities te zetten, met elk hun eigen optimalisatie. Maar het is vooral zo dat bij Linux sowieso alles wel overal zou kunnen staan, en dat de makers van een distributie kiezen voor een bepaalde strategie. Ik zou je aan willen raden eens te kijken naar FHS.

[edit]
Een "exe" file hoeft in Linux sowieso niet een bepaalde extensie te hebben (wel de executable flag), en heet executable. Meestal zijn dat binaries: gecompileerde programmacode, maar het kan ook ongecompileerde code zijn, zoals Perl scripts.

[ Voor 11% gewijzigd door Verwijderd op 06-09-2007 22:29 ]

[killercow]

Verwijderd schreef op donderdag 06 september 2007 @ 22:23:
wat is de reden hiervan precies? waarom niet (zoals in windows) één map met alle files van één programma?

is er een makkelijke manier om te achterhalen waar welk programma welke files dumpt? (en dan vooral waar de "exe's" staan)

ps. hoe noem je een 'exe' in linux?

Linux gebruikt een wirwar van kleine prgramma's en tooltjes,
De grote programma die jij bedoeld staan dan ook op plaatsen waar ze opgedeeld i stukjes thuis horen.

DE /usr/sbin bestanden zijn executables voor de super user, /usb/bin voor de normale users,
in /opt/share kom je nog wel eens extra files tegen van grote programmas die zelf niet executable zijn, maar wel aangeroepen worden (openoffice meuk, mozilla spul), en dan heb je ook nog je eigen bin mapje waar je zelf executables in kunt gooien die alleen voor jouw geinstalleerd zijn.

meestal kun je met je package manager het manifest van een package wel bekijken, maar ik zou me er niet druk om maken,

hou je home netjes schoon, daar woon je, de rest is het domein van je tools en OS.

[Exirion]

Verwijderd schreef op donderdag 06 september 2007 @ 22:23:
wat is de reden hiervan precies? waarom niet (zoals in windows) één map met alle files van één programma?

is er een makkelijke manier om te achterhalen waar welk programma welke files dumpt? (en dan vooral waar de "exe's" staan)

ps. hoe noem je een 'exe' in linux?

De reden is dat in Linux alles wat stricter geordend is. Zo heb je te maken met users, groups, admin users, etc. Per directory en file kun je instellen wat voor rechten een bepaalde (groep) gebruikers heeft. Zo heb je ook executables die bij het core systeem horen, algemene executables, en ook executables die door users aan het systeem worden toegevoegd met losse installaties, etc.

Een executable heeft geen aparte extensie. Je kunt 'm wel herkennen aan de file attributen (x). Verder kun je met dpkg (apt-get) of rpm (synaptic) opvragen waar van een bepaalde package (applicatie) de files geplaatst zijn. Dat zal vaak /usr/bin of /usr/local/bin zijn.

Zoek eens een boekje over Linux want dit is wel de basis die je moet beheersen

[Ultraman]

Een 'exe' in linux? Gewoon een file die executable is, meer niet.
Maar programma's vind je doorgaans in /usr, en daar verschillende mappen in, of /opt
En meer systeem gerelateerde progsels in /bin en /sbin.

Locaties van de files staat doorgaans toch gewoon in de man-pages?

[user109731]

Verwijderd schreef op donderdag 06 september 2007 @ 22:23:
wat is de reden hiervan precies? waarom niet (zoals in windows) één map met alle files van één programma?

Het heeft ook wel weer voordelen om bijvoorbeeld log bestanden apart te zetten (/var/log), gedeelde libraries bij elkaar (/lib, /usr/lib/, etc.), instellingen (~, /etc/, etc.)...

ps. hoe noem je een 'exe' in linux?

Een executable ofzo? Onder windows is een bestand executable wanneer het bijvoorbeeld de extensie .exe heeft. Onder Linux kun je elk bestand executable maken (chmod +x). /usr/bin/azureus is eigenlijk gewoon een scriptje (tekstbestand) bij mij onder Ubuntu Gutsy, maar je kunt 'm hierdoor dus gewoon uitvoeren alsof het een binary is...

[ Voor 10% gewijzigd door user109731 op 06-09-2007 22:33 ]

[Verwijderd]

Dat kan je meestal wel zien via de package manager... welke distributie gebruik je?

[Jaap-Jan]

Verwijderd schreef op donderdag 06 september 2007 @ 22:23:
wat is de reden hiervan precies? waarom niet (zoals in windows) één map met alle files van één programma?

Omdat je bijvoorbeeld programma's hebt voor de super- user, programma's specifiek voor één persoon (een gewone gebruiker kan niet schrijven naar /usr/bin en die directories. Zie de FHS waarom de bestanden staan waar ze staan. Het is echter wel aan individuele distro's om de bestanden op de juiste plaats te zetten, en niet iedere distro houdt zich niet even goed aan de FHS.

is er een makkelijke manier om te achterhalen waar welk programma welke files dumpt?

Via je package manager is dat vaak wel te achterhalen. Voor dpkg is dit bijvoorbeeld:

code:

-L|--listfiles <package> ...     List files `owned' by package(s).

edit:
Wow, dat gaat hard. Je typt even een stukje en je hebt gelijk al 5 andere posters die ook reageren

[ Voor 6% gewijzigd door Jaap-Jan op 06-09-2007 22:33 ]

[Emielio]

Als je linux wil begrijpen moet je het niet met windows vergelijken. De programma's zijn ao te vinden met:

code:

locate programma

Maar meestal kun je ook gewoon het programma starten met de naam. En verder hoef je je eigenlijk meestal niet te bemoeien met de bestandsstructuur buiten je /hom/pumba, linux regelt het allemaal netjes en houd dit ook netjes. Het is niet zoals in windows dat het os kan vervuilen buiten je /home/pumba.

[Verwijderd]

Emielio schreef op donderdag 06 september 2007 @ 22:41:

En verder hoef je je eigenlijk meestal niet te bemoeien met de bestandsstructuur buiten je /hom/pumba, linux regelt het allemaal netjes en houd dit ook netjes. Het is niet zoals in windows dat het os kan vervuilen buiten je /home/pumba.

Dit is dus echt onzin. Linux in handen van een prutser is net zo kwalijk als Windows in handen van een prutser. Linux is helemaal niet per definitie beter of veiliger. Het is alleen zo dat de meeste mensen die Linux gebruiken geen complete nitwits zijn. Als je als "gewone" gebruiker Windows gebruikt, kun je het ook niet zomaar even verkloten. De pest is dat de meeste mensen altijd administrator rechten hebben. Dat is een beetje de spreekwoordelijke olifant in de porseleinkast. Binnen Linux gebeurt dat net zo goed, alleen veel minder.

[ Voor 3% gewijzigd door Verwijderd op 06-09-2007 22:45 ]

[Verwijderd]

Emielio schreef op donderdag 06 september 2007 @ 22:41:
Als je linux wil begrijpen moet je het niet met windows vergelijken. De programma's zijn ao te vinden met:

code:

locate programma

Maar meestal kun je ook gewoon het programma starten met de naam. En verder hoef je je eigenlijk meestal niet te bemoeien met de bestandsstructuur buiten je /hom/pumba, linux regelt het allemaal netjes en houd dit ook netjes. Het is niet zoals in windows dat het os kan vervuilen buiten je /home/pumba.

vooral die laatste zin is boeiend... dit wist ik niet maar is wel goed nieuws in windows is het een ramp voor mensen die hun systeem netjes willen houden, vervuilde registry's, folders waar je niet van weet of ze nog nuttig zijn. Is er een goede site waarin dit princiepe wat uitgebreider uitgelegd staat? (dus hoe het 'softwaredistributieprotocol' werkt en hoe je hier in de praktijk mee om moet gaan) liefst voor ubuntu ?

Waarom ik vooral moet weten waar de executables staan is om een bestand met een bepaald programma te kunnen openen, wel een beetje lastig dat het per programma verschilt... azureus heb ik inmiddels toch gevonden in /usr/bin

[Emielio]

Verwijderd schreef op donderdag 06 september 2007 @ 22:44:
[...]

Dit is dus echt onzin. Linux in handen van een prutser is net zo kwalijk als Windows in handen van een prutser. Linux is helemaal niet per definitie beter of veiliger. Het is alleen zo dat de meeste mensen die Linux gebruiken geen complete nitwits zijn. Als je als "gewone" gebruiker Windows gebruikt, kun je het ook niet zomaar even verkloten. De pest is dat de meeste mensen altijd administrator rechten hebben. Dat is een beetje de spreekwoordelijke olifant in de porseleinkast. Binnen Linux gebeurt dat net zo goed, alleen veel minder.

Bij windows kan je pc buiten "mijn documenten" (even in relatie tot /home) vervuilen zonder dat je dat zelf doet, dit kan in linux niet, hoe je het ook wend of keert. Je moet in linux meer je best doen, je moet al als root inloggen, dit is bij meeste linux systemen niet standaard. En daarna moet je er in gaan kloten. Bij een windows systeem hoef je maar op een verkeerde website te komen met ie6 en activex en kan er al iets onwenselijks komen in je program files ofzo. Dus er zit toch wel degelijk een groot verschil.

Verwijderd schreef op donderdag 06 september 2007 @ 22:53:
[...]
Is er een goede site waarin dit princiepe wat uitgebreider uitgelegd staat? (dus hoe het 'softwaredistributieprotocol' werkt en hoe je hier in de praktijk mee om moet gaan) liefst voor ubuntu ?

https://help.ubuntu.com/7.04/add-applications/C/index.html

[ Voor 13% gewijzigd door Emielio op 06-09-2007 22:58 ]

[!GN!T!ON]

hier wil ik ook nog wel wat meer van weten

mischien iemand die weet waar je een uitleg kan krijgen van de directory structuur van linux?

heb wel eens gezocht hoe het een beetje opgebouwt is maar kan niet veel vinden

[Verwijderd]

Emielio schreef op donderdag 06 september 2007 @ 22:56:
[...]
https://help.ubuntu.com/7.04/add-applications/C/index.html

Dit is niet helemaal wat ik bedoel, ik bedoel meer hoe Ubuntu (of Linux) de software distributeert over de mappen en welk type informatie in welke mappen beland. Bijvoorbeeld welke functie alle verborgen bestanden in mijn /home/user folder hebben (om maar eens wat te noemen).

[ Voor 3% gewijzigd door Verwijderd op 06-09-2007 23:03 ]

[Verwijderd]

Emielio schreef op donderdag 06 september 2007 @ 22:56:

Bij windows kan je pc buiten "mijn documenten" (even in relatie tot /home) vervuilen zonder dat je dat zelf doet, dit kan in linux niet, hoe je het ook wend of keert.

Je mag jezelf best voor lul zetten, als je wilt, maar je kletst echt compleet uit je nek. Het probleem is toch echt in eerste instantie de beheerder. Met een incompetente beheerder ben je altijd verloren. Je kunt in Windows echt niet zomaar de boel overhoop halen als je geen administrator rechten hebt. Je kunt in Linux prima de boel slopen als je steevast je root account gebruikt voor alle taken.
Dat er "standaard" iets niet kan in Linux is onzin. Er zijn vele distributies, en elke heeft een andere benadering. De persoon die Linux installeert kan het zo instellen als hij wil, en dat kan de persoon die Windows installeert ook, voor zover het om gebruikers en toegevoegde software gaat.

Je moet in linux meer je best doen, je moet al als root inloggen, dit is bij meeste linux systemen niet standaard. En daarna moet je er in gaan kloten. Bij een windows systeem hoef je maar op een verkeerde website te komen met ie6 en activex en kan er al iets onwenselijks komen in je program files ofzo. Dus er zit toch wel degelijk een groot verschil.

Onzin. Met een goede up-to-date Windows machine gebeuren er helemaal geen gekke dingen als je niets raars instelt. ActiveX objecten toelaten iets te doen is natuurlijk gewoon lomp. En als je geen administrator rechten hebt gebeurt er niets met je Program Files directory.

Leer nou eens apart te zien wat er meestal fout gaat. De gebruiker moet de schuld krijgen, niet de OS fabrikant. En als de beheerder de gebruiker teveel mogelijkheden geeft, gaat het fout. Bijna gegarandeerd. Of het nu Windows is, of GNU/Linux, of FreeBSD of Mac OS X.

[Verwijderd]

Verwijderd schreef op donderdag 06 september 2007 @ 23:02:

Dit is niet helemaal wat ik bedoel, ik bedoel meer hoe Ubuntu (of Linux) de software distributeert over de mappen en welk type informatie in welke mappen beland. Bijvoorbeeld welke functie alle verborgen bestanden in mijn /home/user folder hebben (om maar eens wat te noemen).

Linux is in principe alleen de kernel. Ubuntu is een GNU/Linux distributie, gebaseerd op Debian. Haast alle documentatie over Debian is dus bruikbaar voor Ubuntu.

Verborgen bestanden in je home directory zijn meestal instellingen, profielen, dat soort zaken.

[Harm]

Verwijderd schreef op donderdag 06 september 2007 @ 23:02:
[...]

Dit is niet helemaal wat ik bedoel, ik bedoel meer hoe Ubuntu (of Linux) de software distributeert over de mappen en welk type informatie in welke mappen beland. Bijvoorbeeld welke functie alle verborgen bestanden in mijn /home/user folder hebben (om maar eens wat te noemen).

Dan moet je de http://www.pathname.com/fhs/pub/fhs-2.3.html eens doornemen, die Cheatah in zijn eerste reactie al noemde .

[ Voor 61% gewijzigd door Harm op 06-09-2007 23:07 ]

[!GN!T!ON]

Verwijderd schreef op donderdag 06 september 2007 @ 23:04:
with stupid ^^

ik heb een tijdje linux server gedraait en ik had het 3x compleet ver*****, zodat ik in al mijn onwetendheid maar een reinstall deed

edit:

bedankt harm, dat is nu precies wat ik zocht

[ Voor 9% gewijzigd door !GN!T!ON op 06-09-2007 23:11 ]

[Emielio]

Het is jammer dat je op een manier als deze:

Verwijderd schreef op donderdag 06 september 2007 @ 23:04:
Je mag jezelf best voor lul zetten,

Je gelijk wil halen. Het feit dat je op zo'n manier je reactie kracht probeert bij te zetten getuigt al van weinig vertrouwen in je eigen argumenten.

Maargoed:
In windows log je na installatie standaard als beheerder in, bij de meeste linux distro's niet.
In windows kun je standaard als (niet beheerder) gebruiker gewoon in alle directory's rommelen.

Als jij iemand bij een standaard windows installatie als gebruiker in laat loggen, kan hij nog makkelijke het systeem vernaggelen. Als jij dit met een linux installatie doet, moet hij of het root wachtwoord weten of weten hoe je met een andere init moet opstarten om het rootwachtwoord aan te passen. Dus is dus veel moeilijker, het is daarom veel moeilijker op gebruikersniveau (zonder root rechten) een linux installatie te vernaggelen dan onder windows.

[ Voor 0% gewijzigd door Emielio op 06-09-2007 23:59 . Reden: typo ]

[dion_b]

Of je iemand rootrechten/adminrechten geeft hangt nog steeds af van de admin. Het verschil tussen Windows en Linux (althans de meeste distro's), is dat Windows en z'n programmatuur er tot en met XP redelijk vanuit ging dat je dingen als admin zou doen, terwijl Linux-cultuur veel meer user-only is tenzij het echt niet anders kan. Maar zoals Cheetah zegt, dat is iets van cultuur en heeft niets te maken met de inherente stabiliteit of veiligheid van de platforms zelf.

* dion_b heeft af en toe eens Windows installs flink verneukt, maar nooit zo subtiel en grondig als die keer dat hij bij Gentoo ondanks alle waarschuwingen de CHOST variable in make.conf veranderde en de world probeerde te emergen...

[Sir Isaac]

Ik denk dat de topic starter weinig heeft aan het geflame hierboven. Hij wil begrijpen waar zijn programma's blijven, en dat is geen gekke vraag omdat dat inderdaad totaal anders is dan bij niet unix os-sen.
Killercow heeft een goed antwoord. Unix is van origine een set van losse tools, niet van grote pakketten. Omdat het geen zin heeft losse tools in eigen directories te zetten is gekozen om te sorteren per file type (executable, library, documentatie, configuratie files). Dit systeem werkt prima, maar heeft als gevolg dat ook de files files van een groot pakket (OO.org, gnome) verspreid worden. Een goed package manager houdt dit allemaal netjes onder controle.
De topicstarter zou er goed aan doen om "Running Linux" uit de serie van O'Reilly eens uit de bieb te halen. Dan leer je zien dat unix/iinux totaal anders van opzet is dan windows, maar wel logisch in elkaar zit.

[Skinkie]

De enige linux distro met echte programma mappen is GoboLinux. Het werkt op een zelfde manier als MacOSX. Je hebt een /Programs waarin je de package plaatst.

[Verwijderd]

Sir Isaac schreef op vrijdag 07 september 2007 @ 10:23:
Ik denk dat de topic starter weinig heeft aan het geflame hierboven. Hij wil begrijpen waar zijn programma's blijven, en dat is geen gekke vraag omdat dat inderdaad totaal anders is dan bij niet unix os-sen.
Killercow heeft een goed antwoord. Unix is van origine een set van losse tools, niet van grote pakketten. Omdat het geen zin heeft losse tools in eigen directories te zetten is gekozen om te sorteren per file type (executable, library, documentatie, configuratie files). Dit systeem werkt prima, maar heeft als gevolg dat ook de files files van een groot pakket (OO.org, gnome) verspreid worden. Een goed package manager houdt dit allemaal netjes onder controle.
De topicstarter zou er goed aan doen om "Running Linux" uit de serie van O'Reilly eens uit de bieb te halen. Dan leer je zien dat unix/iinux totaal anders van opzet is dan windows, maar wel logisch in elkaar zit.

Deze bedoel je?
http://books.google.nl/bo...890KDffoR-ysfJon5q6meLmqM

De link van cheetah is idd ook wat ik bedoel...

[MrBarBarian]

Er zit wel degelijk een zeer grote structuur in het linux-filesystem. Echter zit hier een grote historie aan, en zijn er meerdere producenten die hun eigen draai eraan hebben willen geven. Dat zorgt soms voor wat vreemde situaties...

Echter is dat ook in de Linux-wereld onderkent, en daarom is er bijv. de Linux Standard Base (ofwel LSB spec) uitgebracht. Hierin staat vrij strikt beschreven wat waar hoort, maar uiteraard worden er nog welke de nodige keuzes vrij gelaten (het is immers linux).

Dat het voor de (minder geoefende) gebruiker lijkt alsof er in Windows een sterkere/betere structuur is, is slechts bedrog/gebrek aan kennis. Niemand verplicht je ertoe alles in "program files" te zetten. Sterker nog, dat gebeurt ook regelmatig helemaal niet; er wordt ook een zooi zut geplaatst in de windows-dir.

Dat het toch nog georganiseerder overkomt komt doordat de namen vanzelfsprekender lijken, maar vooral omdat er 1 bedrijf achter zit (wat het veel makkelijker maakt om standaarden te handhaven

[ Voor 12% gewijzigd door MrBarBarian op 07-09-2007 10:38 ]

[Miki]

Novell heeft in haar handleiding over OpenSuse een mooi stukje geschreven over linux filesystem:

http://www.novell.com/doc...rtup/data/sec_new_fs.html

Zoals al eerder is gemeld doet iedere distro het op zijn eigen mannier maar het is wel een goede houvast om je bestanden te vinden. Daarnaast zijn de overige onderwerpen in Basics paragraaf van opgeven handleiding ook zeer interessant voor nieuwkomers.

[Verwijderd]

Hm toch weer een groot vraagteken bij het installeren: ik installeer hier net een .run bestand met

sh bestandsnaam.run

Hij 'uncompressed' en klaar.
Maar, wat nu? nergens een bestand te zien, ook niet in de usr/bin share/bin etc...

[icyx]

twee mogelijkheden: In de local dir staat een map met een binary erin ofzo, of hij doet niets omdat hij geen 'commands' afgevangen heeft. Wat voor *.run is het? En doe is sh $FILE.run --help?

[Verwijderd]

icyx schreef op donderdag 20 september 2007 @ 16:24:
twee mogelijkheden: In de local dir staat een map met een binary erin ofzo, of hij doet niets omdat hij geen 'commands' afgevangen heeft. Wat voor *.run is het? En doe is sh $FILE.run --help?

--info geeft dit:
Identification: Northland Demo
Target directory: Install
Uncompressed size: 79732 KB
Compression: gzip
Date of packaging: Fri Feb 3 15:16:53 GMT 2006
Built with Makeself version 2.1.5 on linux-gnu
Build command was: /Developer/loki/makeself/makeself.sh \
"./Install/" \
"NorthlandDemo.run" \
"Northland Demo" \
"./setup.sh"
Script run after extraction:
./setup.sh
Install will be removed after extraction


--help geeft dit:
1) Getting help or info about /home/user/Downloads/NorthlandDemo.run :
/home/user/Downloads/NorthlandDemo.run --help Print this message
/home/user/Downloads/NorthlandDemo.run --info Print embedded info : title, default target directory, embedded script ...
/home/user/Downloads/NorthlandDemo.run --lsm Print embedded lsm entry (or no LSM)
/home/user/Downloads/NorthlandDemo.run --list Print the list of files in the archive
/home/user/Downloads/NorthlandDemo.run --check Checks integrity of the archive

2) Running /home/user/Downloads/NorthlandDemo.run :
/home/user/Downloads/NorthlandDemo.run [options] [--] [additional arguments to embedded script]
with following options (in that order)
--confirm Ask before running embedded script
--noexec Do not run embedded script
--keep Do not erase target directory after running
the embedded script
--nox11 Do not spawn an xterm
--nochown Do not give the extracted files to the current user
--target NewDirectory Extract in NewDirectory
--tar arg1 [arg2 ...] Access the contents of the archive through the tar command
-- Following arguments will be passed to the embedded script

[Keiichi]

In lniux is het veelal op deze manier ingericht

/usr/bin /usr/local/bin om de executables in op te slaan
/usr/lib /usr/local/lib voor de shared libraries
/usr/share/%applicatie% /usr/local/share/%applicatie% voor applicatie specifieke bestanden

Dus er zit weldegelijk een soort van ordening in.

[ThunderNet]

MrBarBarian schreef op vrijdag 07 september 2007 @ 10:38:
Er zit wel degelijk een zeer grote structuur in het linux-filesystem. Echter zit hier een grote historie aan, en zijn er meerdere producenten die hun eigen draai eraan hebben willen geven. Dat zorgt soms voor wat vreemde situaties...

Echter is dat ook in de Linux-wereld onderkent, en daarom is er bijv. de Linux Standard Base (ofwel LSB spec) uitgebracht. Hierin staat vrij strikt beschreven wat waar hoort, maar uiteraard worden er nog welke de nodige keuzes vrij gelaten (het is immers linux).

Dat het voor de (minder geoefende) gebruiker lijkt alsof er in Windows een sterkere/betere structuur is, is slechts bedrog/gebrek aan kennis. Niemand verplicht je ertoe alles in "program files" te zetten. Sterker nog, dat gebeurt ook regelmatig helemaal niet; er wordt ook een zooi zut geplaatst in de windows-dir.

Dat het toch nog georganiseerder overkomt komt doordat de namen vanzelfsprekender lijken, maar vooral omdat er 1 bedrijf achter zit (wat het veel makkelijker maakt om standaarden te handhaven

Ik moet zeggen dat de structuur toch wel redelijk goed voor elkaar is inmiddels

C:\>dir /a
 Volume in drive C has no label.
 Volume Serial Number is DCF0-7551

 Directory of C:\

16-08-2007  13:35    <DIR>          Boot
02-11-2006  17:39    <JUNCTION>     Documents and Settings [C:\Users]
02-09-2007  16:25    <DIR>          Program Files
18-09-2007  11:03    <DIR>          Program Files (x86)
18-09-2007  10:58    <DIR>          ProgramData
11-06-2007  01:34    <DIR>          RECYCLER
20-09-2007  14:14    <DIR>          System Volume Information
22-04-2007  23:47    <DIR>          Users
18-09-2007  14:28    <DIR>          Windows
               9 File(s)        792.077 bytes
              17 Dir(s)   2.627.379.200 bytes free

C:\>

Grootste nadeel (en dat is ook bij Linux zo) is dat veel software ontwikkelaars, zich niet aan de richtlijnen van het os houden, en het dus een zooitje wordt

[daft_dutch]

De richtlijnen in Linux zijn zeer transparant.
Ook doordat de meeste grote distro's packages systemen hebben wordt dit beter af gedwongen.

configuratie /etc/
documentatie /usr/share/doc/<pakketnaam/
voorbeelden documentatie /usr/share/doc/<pakketnaam/examples/
opslag voor de programma's /var/cache/

core executables /(s)bin/
standaard applicaties /usr/(s)bin/
eigen programmas (of uitgepakt) /usr/local/(s)bin/

Ennzz

Het is inderdaad even wennen. Maar heeft veel voordelen.
Bijvoorbeeld kunnen libraries elkaar makkelijk vinden zonder een *kuch*Register*kuch*
Doordat alle executables staan op bekende plekken kan je ze altijd starten zonder het Path toe tevoegen.

indien je systeem gedeeltelijk gecorrupteerd is. heb je banaal alleen /etc/ /home en een lijst van geinstalleerde pakketten nodig om het hele systeem te herstellen

en nog veel meer voordelen. bv verschillende paritites en type.

[robbert]

ThunderNet schreef op donderdag 20 september 2007 @ 16:45:

02-11-2006  17:39    <JUNCTION>     Documents and Settings [C:\Users]

offtopic:
Is een junction een soort symlink onder Windows

[mithras]

robbert schreef op donderdag 20 september 2007 @ 17:47:
[...]

offtopic:
Is een junction een soort symlink onder Windows

Ja:

quote: http://www.microsoft.com/...FileAndDisk/Junction.mspx

Directory symbolic links are known as NTFS junctions in Windows.

Maar het lullige:

Unfortunately, Windows comes with no tools for creating junctions - you have to purchase the Win2K Resource Kit, which comes with the linkd program for creating junctions.

[robbert]

mithras schreef op donderdag 20 september 2007 @ 17:48:
[...]
Ja:

Het kan dus alleen symlinks maken naar directories? Ook handig? En zeker ook niet naar een ander filesystem?
Edit: Voortaan eerst maar lezen Het kan dus wel naar andere partities, maar niet naar remote shares..

Maar het lullige:

[...]

Dat is wel erg idioot.

[ Voor 16% gewijzigd door robbert op 20-09-2007 18:09 ]

[ThunderNet]

robbert schreef op donderdag 20 september 2007 @ 17:47:
[...]

offtopic:
Is een junction een soort symlink onder Windows

symlink onder NTFS. Zoals hierboven al ziet, ondersteund NTFS veel meer dingen, dan dat windows standaard tools voor meelevert. Weet niet meer welke site, maar deze tools zijn ook gewoon gratis te verkrijgen

Hoewel wikipedia zegt niets over dat soort tools
http://en.wikipedia.org/wiki/NTFS_symbolic_link
http://en.wikipedia.org/wiki/NTFS

[ Voor 14% gewijzigd door ThunderNet op 20-09-2007 19:13 ]

[Avalanchez]

om even ontopic een concreet antwoord te geven:

/bin
Hier worden alle essentiële user binaries geplaatst (bv commando's als ls, cat, more, sed, touch, ps, pwd,...). Hier maak je geen submappen aan.

/sbin
Hier worden alle systeem binaries gezet die van vitaal belang zijn voor systeemadministratie (bv fdisk, ipconfig, mkfs, grub,...). Als een gewone user (niet-root) dit niet zou mogen doen, dan hoort het hier.

/usr/bin
Hierin leven de meeste user binaries (usr staat voor unix system resources). Dit zijn binaries die niet nodig zijn voor single user mode. Dit zijn dingen zoals bv python, X11, xscreensaver, locate, symbolic links naar bins uit /bin (en ook omgekeerd, bv voor bash, tcl, perl etc),...

/usr/sbin
analoog
voorbeelden: smbd, tcpdump, alsactl,...

/opt
Dit zijn de optionele pakketten. Dit zijn meestal pakketten die je zelf installeert, of third party binaries. Aangezien je daarvan de code niet hebt kun je hier wel best een mapstructuur hebben (komen meestal ook met static libs).
Ikzelf heb hiervoor oa enkele java engines, Maple, Realplayer, Acrobat, skype, googleearth, ...

Overigens maakt het zelfs geen bal uit waar je een bin plaatst. Zolang de executable vlag is gezet kun je gewoon ./path/to/mybin gebruiken (bv voor even snel een scriptje uit te voeren).
Als je die ./ weg wil zet je je bin in een van de mappen hierboven gesproken, in dewelke je denkt het best te passen.

Probeer eens echo $PATH. Hier zie je welke mappen allemaal standaard doorzocht worden naar binaries. Je kan zelf een map toevoegen door bv export PATH=$PATH:/usr/bin/homecooked.

Meestal zet je package manager (distro specifiek) de binaries gewoon op de juiste logische plaats, dus hoef je hier zelf geen zorgen over te maken.

Ik hoop dat dit je wat meer inzicht geeft in hoe bestanden opgeslagen worden op een *nix-achtig systeem. Dit is ook volledig analoog voor alle /lib mappen (of: waar zet je je libs bij je programma).

[ Voor 6% gewijzigd door Avalanchez op 20-09-2007 19:36 ]

[Verwijderd]

Fijn dat je het allemaal nog een keer uit probeert te leggen. Mensen kunnen echter toch beter even iets over FHS lezen.

[Avalanchez]

Verwijderd schreef op donderdag 20 september 2007 @ 19:35:
Fijn dat je het allemaal nog een keer uit probeert te leggen. Mensen kunnen echter toch beter even iets over FHS lezen.

Die kende ik niet.

Mensen kunnen toch beter even iets FHS lezen.