[Compileren] Een zegen of een vloek?

[saviour]

Wat vinden jullie eigenlijk?

Het is natuurlijk hartstikke gaaf om zelf een programma te compileren, je kan het zelf helemaal aanpassen.

Ik moet zeggen dat ik het zelf ook leuk vind om te doen, maar soms duurt het zo lang!

Als ik het dan bekijk (mijn newbie visie):

Je compileert iets (ik had net bijvoorbeeld de QT libraries gecompileerd, daar heb ik 3 uur over gedaan! Het werkt daarna allemaal hartstikke goed, geen probleem.. maar 3 uur!

Als je iets onder windows installeert duurt het geen 3 uur, maar kan je ook (haast) niets aanpassen wanneer het verkeerd gaat.

Dus daarom vroeg ik mij af wat jullie vinden, compileren: een zegen of een vloek?

[Verwijderd]

Ja serieus hee......... compilen heerst natuurlijk, dat vindt elke coder met ook maar 1 100% functionerende hersencel in z'n botte kop.

Wat wilde je anders, de hele tyfbende interpreteren?

Dat kost je dus 3 uur per executie onderhand...




_{Ik stem ervoor dat KeurigVentje wordt ge-unbanned in http://www.scaresoft.nl/vb/showthread.php?s=ac1025634e1fd806942a8eee9686b67e&threadid=7919&pagenumber=4}

[blaataaps]

apt-get install $app
dat roeleert compilen de pan uit. Behalve als je bepaalde exotische eisen hebt, scheelt dat een hoop tijd en moeite.

* blaataaps promoot debian maar weer eens.

[Insanergy]

Compileren neemt erg veel tijd in beslag, zeker als je dingen moet gaan uitzoeken... Leer je weer wel van

De laatste tijd gebruik ik eigenlijk alleen maar rpm.
Dependencies uitzoeken kost misschien ook wel wat tijd maar 't is zo makkelijk!

[saviour]

Hmm, Opera loopt hier te fokken Maarre, wat bedoel je hiermee?

Wat wilde je anders, de hele tyfbende interpreteren?
Dat kost je dus 3 uur per executie onderhand...

Overigens, wat heeft KeurigVentje met mij te maken? Om even duidelijk te zijn, ik ben dat dus niet..

Trouwens, wat is je nick daar? Of ben jij dat juist?

[Verwijderd]

Op woensdag 13 februari 2002 01:42 schreef saviour het volgende:
Hmm, Opera loopt hier te fokken Maarre, wat bedoel je hiermee?
[..]

Overigens, wat heeft KeurigVentje met mij te maken? Om even duidelijk te zijn, ik ben dat dus niet..

Trouwens, wat is je nick daar? Of ben jij dat juist?

Don't look at me

Ik volg het alleen maar


[edit]

Oh en wat ik ermee bedoelde:

Als er geen compilers zouden zijn, dan moesten we al onze programma's laten interpreteren. En da's fucking traaaaaaaaaaaaag. Way trager dan het runnen van machineinstructies die door een compiler zijn uitgepoept na het parsen van een sourcecode.

Sim-pel.

[Ronald]

Je hoeft niet te compileren natuurlijk, apt roelt best wel en is dan even snel als een windhoos installertje.
mijn ervaring is dat een volledig (linuxfromscratch) systeem wat vlotter loopt. Bij mij iig loopt lfs wat soepeler nog dan debian. Mischien maar eens source.deps proberen

[Verwijderd]

Dit misverstand zal wel gaan over programma's in eenomgeving als BASIC versus gecompileerde code. Ik denk niet dat dat wordt bedoeld met dit topic.
Compileren biedt meer. Meer keuze, meer werk, meer problemen, meer performance. Dus graag beide: compileren en het gemak van een packagemanager. Gentoo heeft dat goed begrepen. Een package manager downloadt de source en aan de hand van al aanwezige buildscripts wordt je package gecompileerd en geinstalleerd.

[Verwijderd]

rofl QT 3 uur.
bij mij staat het nu al zeker 6+ uur te pruttelen

maar over het algemeen is dat compilen zo klaar.
QT is zo i zo al het grootste/langste wat ik tot nu toe ge compiled heb.

en compilen roelt over RPM.
want als RPM zegt dat ik BLAAT.so nodig heb
moet ik weer gaan uitzoeken waar die .so dan weer
bijhoort.
en als je een progje hebt met een goede config file
dan zegt hij gewoon meteen wat je nodig hebt.

[blaataaps]

apt-get kan ook de sourcepackage downloaden en vervolgens compilen.

[saviour]

Op woensdag 13 februari 2002 01:57 schreef blaataaps het volgende:
apt-get kan ook de sourcepackage downloaden en vervolgens compilen.

Dat weet ik, maar het gaat zo moeilijk op een RedHat bak

Bedankt trouwens dat je me eraan helpt herinneren dat ik de server moet laten apt-getten

Zoals ik al zei vind ik zelf compileren wel gaaf, maar een rpm-etje op zijn tijd is ook lekker.. of nog beter, idd apt-get

Ik had alleen vanmiddag bijvoorbeeld, ik wilde licq installeren met een rpm en dat wilde maar niet, dus toen zelf gecompileerd en dat ging weer wel!

Maarja, moet er toch weer af want volgens mij komt er geen enkel bericht aan

[blaataaps]

Op woensdag 13 februari 2002 02:03 schreef saviour het volgende:

[..]

Dat weet ik, maar het gaat zo moeilijk op een RedHat bak

Dat is ook de reden dat ik geen redhat bakken heb, maar wel debian bakken (naast diverse andere redenen).

[saviour]

Op woensdag 13 februari 2002 02:06 schreef blaataaps het volgende:

[..]

Dat is ook de reden dat ik geen redhat bakken heb, maar wel debian bakken (naast diverse andere redenen).

Ik heb dus Debian op mijn servertje, het stond eerst ook op deze laptop maar ik kreeg Xfree gewoon niet aan de praat onder Debian. Onder RedHat dus wel..

[deadinspace]

Op woensdag 13 februari 2002 01:55 schreef StratoS_V2.0 het volgende:
en compilen roelt over RPM.
want als RPM zegt dat ik BLAAT.so nodig heb
moet ik weer gaan uitzoeken waar die .so dan weer
bijhoort.

Dat is een hinderlijk ""feature"" van RPM: dependancies op files. Ophangen mogen ze het van mij.
Het is een van de grootste redenen dat het bij Debian zoveel beter werkt; .deb/dpkg kent alleen dependancies op andere packages.
Dat is niet alleen makkelijker (je hoeft niet te zoeken in welke packages de files zitten die je nodig hebt), maar het is ook hetgene wat apt mogelijk maakt; in de package staat welke andere packages nodig zijn, dus apt kan die opzoeken en downloaden en installeren. Automagisch.

Bijvoorbeeld, je wilt konqueror. Daar heb je bepaalde KDE blaat voor nodig. Dat gaat dan als volgt:

code:

[root@nothing root]# apt-get install konqueror
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  kdebase-libs kdelibs3 kdelibs3-bin libfam0 libkonq3 libxslt1 
The following NEW packages will be installed:
  kdebase-libs kdelibs3 kdelibs3-bin konqueror libfam0 libkonq3 libxslt1 
0 packages upgraded, 7 newly installed, 0 to remove and 0  not upgraded.
Need to get 10.6MB of archives. After unpacking 36.4MB will be used.
Do you want to continue? [Y/n] n
Abort.

Als ik 'y' had gedaan, dan had hij de packages in kwestie gedownload en geinstalled. *dat* is hoe een package manager hoort te werken.

De mogelijkheid tot zelf compilen is in ieder geval een hele belangrijke vrijheid, daar zal wel niemand het mee on-eens zijn.

Alles zelf compilen is ook mooi, maar als je zelf al 6 systemen moet onderhouden, plus nog een aantal systemen die niet van jou zijn, dan wil je toch heeeel snel iets anders dan alles zelf compilen.

[Verwijderd]

nu we toch apt-get aan het vereren zijn.

is debian een beetje snel?
heb nu een SuSe 7.0 draaien. (met alles ge update (bijna alles))

maar dat apt-get klinkt wel verdomde verleidelijk?

en heeft slack trouwens ook niet zo'n soort apt-get.
slack-get ofzo?

[Verwijderd]

Er zijn wel tools voor Slackware om het downloaden van packages eenvoudiger te maken. Slaktool is een naam die me te binnen schiet, maar er zijn er meer.
Gentoo heeft wel een leuke tool die veel kan wat apt-get ook kan maar dan vanaf source gecompileerd. Maar voor Slackware zijn er nogal wat minder packages beschikbaar dan voor Debian.

[Thc_Nbl]

apt-get RULLES>.


ook voor newbees erg fijn..

ik gebruik apt-get install pakket
apt-get update
apt-get dist-upgrade
dselect en gnome-apt

echt werelds dat DEBIAN....

enne ook ik ben nog een newbee... +)

[Verwijderd]

compileren is wel zo handig, maar sommige mensen hebben nauwelijks door wat het nut ervan is. Argumenten als "het wordt sneller" zijn maar voor zeer weinig pakketen aan de orde. Als je XFree zelf compileert met handmatige optimalisaties zal het sneller worden. Echter, de meeste autotools pakketjes (bijna elk softwarepakket dus) zal net zo snel zijn als je het zelf compileert als wanneer je een RPM/deb neemt.....

Compileren is leuk, maar eigenlijk niet echt nuttig voor Jan-met-de-pet

[offtopic]
overigens, apt/deb/dpkg vs. RPM: als je zelf eens geprobeerd hebt RPMs/debs te maken zul je snappen waarom RPM de standaard is volgens linux-base. debs maken is een kutwerk, RPMs werkt imho veel makkelijker het RPM installatiesysteem zuigt overigens weer maar dat heeft iedereen hierboven al gezegd

[active2]

Dat compileren hangt tot zekere hoogte ook af van je cpu vermogen!!!

Maar kerneltje compilen wat ik dus meestal wel doe duurt bij mij 5 minuten (900Mhz) (640MB) dus... ik heb niks te klagen!

En zeker apt-get install <applicate> rulet natuurlijk!

[wzzrd]

Op woensdag 13 februari 2002 01:29 schreef saviour het volgende:
Wat vinden jullie eigenlijk?

Het is natuurlijk hartstikke gaaf om zelf een programma te compileren, je kan het zelf helemaal aanpassen.

Ik moet zeggen dat ik het zelf ook leuk vind om te doen, maar soms duurt het zo lang!

Als ik het dan bekijk (mijn newbie visie):

Je compileert iets (ik had net bijvoorbeeld de QT libraries gecompileerd, daar heb ik 3 uur over gedaan! Het werkt daarna allemaal hartstikke goed, geen probleem.. maar 3 uur!

Als je iets onder windows installeert duurt het geen 3 uur, maar kan je ook (haast) niets aanpassen wanneer het verkeerd gaat.

Dus daarom vroeg ik mij af wat jullie vinden, compileren: een zegen of een vloek?

Compileren is niet te vergelijken met het doen van een install onder windows. Om een vergelijking te maken zou je een wat programma's onder windows moeten compileren: duurt net zo lang. Je kunt beter debs of rpm met een windows installer vergelijken.
Ik heb onderhand 6 of 7 distro's geprobeerd, die gebruik maakten van rpm's of deb's. Mijn meest recente experiment heet Sorcerer GNU/Linux. Dat is een source gebaseerde distro. Iedereen die hier zo loopt te geilen op debian zou eigenlijk verplicht eens met SGL moeten spelen. Het is niet alleen sneller en meer up-to-date dan debian, maar het is zelfs eenvoudiger!

Het notoir traag opstartende mozilla start op mijn SGL gnome desktop nu net zo snel als IE onder windows. Zonder pre-loaded libs e.d.

Nee, mensen, rpm is leuk, apt is best cool, maar voor het snelste systeem zul je toch écht zelf binaries moeten bakken

Overigens duurt het compileren van programma's onder SGL door een min-of-meer verplichte grote swapfile (samen met RAM minimaal 1GB, klein nadeeltje ) niet eens zo gek lang. Maar het is een feit dat het compileren van X en Mozilla e.d. erg lang duren...

[blouweKip]

Als je iets onder windows installeert duurt het geen 3 uur, maar kan je ook (haast) niets aanpassen wanneer het verkeerd gaat.

Duh, als je iets onder windows compiled dan duurt dat toch ook langer?

Compilen doe ik alleen als ik iets sneller wil laten draaien dan met de i386 packages die ik via apt binnenhaal, mplayer bijvoorbeeld..

Ik heb net weer ff achter mandrake 7.2 gezeten (stond nog op een bak die ik nog had staan) en het updaten van software was weer vanouds een hel..

Als je eenmaal apt hebt geprobeerd zul je niet zo snel terug gaan..

[deadinspace]

Op woensdag 13 februari 2002 09:55 schreef wzzrd het volgende:
Het is niet alleen sneller en meer up-to-date dan debian, maar het is zelfs eenvoudiger!

Meer up-to-date? Waar baseer je dat op? Behalve XFree 4.2.0 heb ik in SGL geen nieuwere versies gezien dan in Debian, maar wel oudere versies... Lijkt dus gewoon niet waar te zijn.

[_JGC_]

apt-get source -b doe ik wel eens ja, maar de laatste keer was dus op een Dual Pentium 100 met 2.4.18-pre9, waar ik dat voor BIND9 deed. Tegelijk was ik nog MySQL, Cyrus-imap en wat dingen voor Apache aan't compileren.
BIND en MySQL hebben me zo'n 3 uren gekost op die machine, doe ik dus niet weer

[jvreuls]

Compilen is wel leuk en handig als de RPM's van RedHat weer eeuwen achterlopen

RPM werkt soms best wel frustrerend met die dependencies. Wilde laatst de nieuwe Samba installeren via RPM, maar dat ging niet omdat die gebouwd was voor RedHat 7.2 (heb 7.1). Ik had de verkeerde versie van libreadline. Die ook proberen te installeren, ging ook niet omdat andere progjes precies die versie wilden hebben

Ga binnenkort overstappen omdat dat RPM dus voor geen meter werkt. Het wordt dus Debian met apt-get

[Verwijderd]

Volgens mij is de reden dat de source meegeleverd wordt omdat een programma dan gecompileerd kan worden op *elk* OS en computer van *elk* type. Je moet dan wel een fatsoenlijke compiler hebben voor dat OS.

Verder is het erg handig dat je *kunt* compilen... Maar het is zeker niet noodzakelijk. Ik zal ook niet zo snel beginnen aan het compilen van heel KDE of Gnome... Dat duurt imho veel te lang.

En ik wil blaataaps nog een steunen in zijn Debian promotion tour. Debian met zijn apt-get systeem is gewoon erg goed.

Overigens is er ook apt voor RPM... Maar volgens mij werkt dat niet echt bijzonder goed...

[saviour]

Ik wilde eerst Debian op deze laptop zetten, maar dat ging dus niet ivm XFree. Toen heb ik RH geinstalleerd en X daaronder geconfigureerd. Daarna werd ik RH weer zo zat met zijn RPM's dat ik Debian maar weer geinstalleerd heb en het werkt met de config files van RH

Nu apt-get ik natuurlijk wel alles ipv source

[Treenaks]

Waarom vergeet iedereen toch 'apt-get source'?

Dat is "best of both worlds" - zelf compileren én apt in een. apt kan ook build-dependancies oplossen voor je, zodat je niet moeilijk hoeft te doen om uit te zoeken welke libs je allemaal nodig hebt om een package te compileren.

(ja, ik ben zo iemand die kernel-package gebruikt voor zn kernels -- dan kan je ze ook mooi met dselect managen)

[banaan-X]

Op woensdag 13 februari 2002 17:49 schreef saviour het volgende:
Ik wilde eerst Debian op deze laptop zetten, maar dat ging dus niet ivm XFree. Toen heb ik RH geinstalleerd en X daaronder geconfigureerd. Daarna werd ik RH weer zo zat met zijn RPM's dat ik Debian maar weer geinstalleerd heb en het werkt met de config files van RH

Nu apt-get ik natuurlijk wel alles ipv source

Ah, en doet Unreal het al op Debian dan inmiddels ?

Maar waarom zou het trouwens sneller zijn als je het zelf compileerd? Die debs enzo zijn toch gewoon voorgecompileerde paketten (die iemand anders heeft gecomileerd en in een deb heeft gestopt)? Dus waarom zouden die dan trager zijn?
(ja ik weet wel Dat het zo is, maar Waarom?)

[odysseus]

Op woensdag 13 februari 2002 19:02 schreef banaan-X het volgende:
Maar waarom zou het trouwens sneller zijn als je het zelf compileerd? Die debs enzo zijn toch gewoon voorgecompileerde paketten (die iemand anders heeft gecomileerd en in een deb heeft gestopt)? Dus waarom zouden die dan trager zijn?
(ja ik weet wel Dat het zo is, maar Waarom?)

Stel dat die developer een P3 800 heeft. Hij zou dus best willen optimaliseren voor de P3, maar dat kan hij niet doen. Want: andere gebruikers kunnen best een 386 hebben en daar moet het ook op draaien. Dus je kunt alleen zo compileren dat iedereen de software kan gebruiken. Als enkele eindgebruiker heb je natuurlijk geen last van het probleem dat de developer wel heeft, want niemand hoeft jouw compilaties op zijn pc te kunnen draaien. Daarom kun jij zelf bijvoorbeeld gaan optimaliseren op processorarchitectuur of op andere dingen. Daar kun je voordeel mee halen. Hoeveel dat is verschilt sterk per programma, maar bij sommige loont het inderdaad (mplayer is daar een goed voorbeeld van).

[dude123]

wat ook een voordeel van compilen is dat je het kunt porten naar andere machines.
Vooral veel met linux e.d. gedaan

[deadinspace]

Ik denk dat we het er allemaal wel over eens zijn dat het een goede zaak is dat je zelf *kunt* compilen, met andere woorden dat de software opensource is. Dit heeft goede gevolgen voor de openheid, portability en het feit dat je het zelf kunt compilen en in de code hacken (nuttig of om van te leren).

Maar ik denk dat de vraag die de topicstarter wilde stellen niet is of het een goede zaak is dat dat kan, maar of het zelf doen ervan zo prettig/geschikt is voor de gewoone mensch.

[wzzrd]

Op donderdag 14 februari 2002 03:13 schreef deadinspace het volgende:
Ik denk dat we het er allemaal wel over eens zijn dat het een goede zaak is dat je zelf *kunt* compilen, met andere woorden dat de software opensource is. Dit heeft goede gevolgen voor de openheid, portability en het feit dat je het zelf kunt compilen en in de code hacken (nuttig of om van te leren).

Maar ik denk dat de vraag die de topicstarter wilde stellen niet is of het een goede zaak is dat dat kan, maar of het zelf doen ervan zo prettig/geschikt is voor de gewoone mensch.

Ik geloof niet dat

code:

./configure 
make
make test
make install

héél veel moeilijker is dan

code:

RPM -Ivh blablalba.i386.rpm
RPM -e --force blablalba1
RPM -Uvh --nodeps blablalba2.i386.rpm

Toch?

[balk]

hehe, zelf compileren? Ja! anders doet mijn processor niet voldoende. Bovendien zou mijn download/installeer ratio te hoog zijn (casema)

ohja, een XP1700+ gaat best rap. Ik ben nu trouwens glibc aan het binnen emergen en zometeen compilen.....

[deadinspace]

Op donderdag 14 februari 2002 07:33 schreef wzzrd het volgende:
Ik geloof niet dat

[compile]

héél veel moeilijker is dan

[rpm]

Toch?

En ik vind

code:

apt-get install blablabla

nog makkelijker

Maar zelf compilen brengt veel issues met zich mee, oa:
• Uninstallatie?
• Wil het wel compilen? Zo niet, waarom niet?
• Waar pleurt make install zijn zooi neer? (en gaat je package manager daarvan over de zeik?)
• Veel development libs nodig
• Veel RAM en CPU nodig

Tamelijk goed georganiseerde source-gerichte distributies als SGL en Gentoo lossen een aantal van deze problemen ver op, dat wel. Maar dan is het meer een SGL/Gentoo vs andere distro's discussie.

[Verwijderd]

Een vraagje, en wellicht offtopic in NOS, maar gezien dit draadje kan ik 'm denk ik het beste hier kwijt :

Zit er tussen Intel- en AMD-processoren nog een groot verschil als het om het compileren van source gaat ?
Ik wil binnenkort weer 'ns gaan upgraden en aangezien ik veel bezig met LFS zou het fijn als de processor die ik aanschaf ook goed presteert op gebied van compiling.

Het is overigens niet mijn bedoeling om hier een "Intel-is-pas-echt-cool"- of "Neeh-Man-AMD-rules"-flamewar te starten, dus mocht de vraag hier ontopic zijn dan ook je antwoord graag onderbouwen

[odysseus]

Ik meen me te herinneren (weet het dus niet zeker!) dat AMD's over het algemeen iets sneller zijn in het compileren dan Intel-processoren. Intel blinkt meer uit in allerlei extra foefjes, AMD is iets meer brute kracht. Ik weet dat er ook op verschillende plaatsen benchmarks staan van kernelcompilaties, kijk eens op Anandtech of THG voor dergelijke dingen. Overigens denk ik dat het verschil dusdanig klein is dat je je er niet druk over hoeft te maken en veel meer aan andere dingen aandacht kunt schenken: prijs, stabiliteit, beschikbaarheid, etc. Als je echt veel wilt compileren dan is een dual-proc setup aan te raden, maar dan praten we ook over een extra hoeveelheid geld die veel mensen niet over hebben om iets sneller een binary uit hun systeem te zien rollen...

[wzzrd]

Op donderdag 14 februari 2002 19:05 schreef deadinspace het volgende:

[..]

En ik vind

code:

apt-get install blablabla

nog makkelijker

Maar zelf compilen brengt veel issues met zich mee, oa:
• Uninstallatie?
• Wil het wel compilen? Zo niet, waarom niet?
• Waar pleurt make install zijn zooi neer? (en gaat je package manager daarvan over de zeik?)
• Veel development libs nodig
• Veel RAM en CPU nodig

Tamelijk goed georganiseerde source-gerichte distributies als SGL en Gentoo lossen een aantal van deze problemen ver op, dat wel. Maar dan is het meer een SGL/Gentoo vs andere distro's discussie.

Noem me maar een nerd, maar ik vind dat apt-getten eigenlijk een beetje het kiezen van de makkelijke weg. Je wil toch ook iets leren?

[odysseus]

Op donderdag 14 februari 2002 20:17 schreef wzzrd het volgende:
Noem me maar een nerd, maar ik vind dat apt-getten eigenlijk een beetje het kiezen van de makkelijke weg. Je wil toch ook iets leren?

Ik kan je verzekeren dat er _heel_ wat meer te leren valt aan apt-get dan je je waarschijnlijk kunt voorstellen. Of heb jij wel eens met apt-get een complete Debian-installatie van de grond af gecompileerd, met packages gemixt uit verschillende versies van Debian, volledig geoptimaliseerd voor je eigen systeem en met elke willekeurige commandline-optie die je maar wilt? Om dan nog niet te spreken over het zelf maken van deb-packages. Het doel van elke systeembeheerder is niet om zoveel mogelijk te leren, maar ook om zijn systeem netjes te houden. Dat kan beter met packages dan wanneer je alles zelf compileert. Om maar niet te spreken van de andere voorbeelden. En je verliest er echt weinig flexibiliteit mee: dpkg en consorten kunnen veel meer dan de meeste mensen denken.

[deadinspace]

Op donderdag 14 februari 2002 20:17 schreef wzzrd het volgende:
Noem me maar een nerd, maar ik vind dat apt-getten eigenlijk een beetje het kiezen van de makkelijke weg. Je wil toch ook iets leren?

Leren en gebruiken kunnen ook gescheiden zijn

Het is op zich wel prettig dat apt-get enzo werkt als je het nodig hebt, zodat je een andere keer kunt leren.
En leer jij zoveel van './configure; make; make install' dan ?

Los daarvan hoef je niet bang te zijn dat ik niet kan compilen (ik compile wel eens wat zelf, ik schrijf mijn eigen C progs en bijbehorende makefiles en ik heb wel eens in de Linux kernelsource gepoked) of dat ik niet kan leren (als je niets wilt leren kun je beter blijven gebruiken wat je kent en wat kende ik? Juist ja - Windows ).

[Verwijderd]

Op donderdag 14 februari 2002 19:05 schreef deadinspace het volgende:
Maar zelf compilen brengt veel issues met zich mee, oa:
• Uninstallatie?

Make uninstall

En eventueel kun je het handmatig verwijderen, 99% van de applicaties gooit zijn data in $PREFIX/share/<appname>/*, $PREFIX/lib/lib<appname>.*, $PREFIX/bin/<appname> en $PREFIX/include/<appname>/*. Met een 'locate <appname>' kun je de laatste achtergbleven documentjes verwijderen en dan ben je er weer vanaf Superlogisch

• Wil het wel compilen? Zo niet, waarom niet?

Tuurlijk, hoe wil je anders aan apt-get binaries komen

• Waar pleurt make install zijn zooi neer? (en gaat je package manager daarvan over de zeik?)

./configure --prefix=$PREFIX

• Veel development libs nodig

Als je alles van source compilet ( ) heb je dat probleem uberhaupt niet

• Veel RAM en CPU nodig

Mwoh, gaat al anderhalf jaar uitstekend op mijn miezerige P-II 400-tje

[deadinspace]

Op vrijdag 15 februari 2002 09:54 schreef beelzebubu het volgende:
Make uninstall

En eventueel kun je het handmatig verwijderen, 99% van de applicaties gooit zijn data in $PREFIX/share/<appname>/*, $PREFIX/lib/lib<appname>.*, $PREFIX/bin/<appname> en $PREFIX/include/<appname>/*. Met een 'locate <appname>' kun je de laatste achtergbleven documentjes verwijderen en dan ben je er weer vanaf Superlogisch
<snip>
./configure --prefix=$PREFIX

Je geeft zelf al aan dat makefiles dat meestal kunnen, maar dus niet altijd. Ikzelf vind het logischer dat een package manager zulke zaken netjes in de gaten houdt.

Tuurlijk, hoe wil je anders aan apt-get binaries komen

Duh, tuurlijk zal het ooit gecompiled moeten worden, maar we (of iig ik) hebben het hier over *zelf* compilen.

De .debs die ik gebruik zijn ook gecompiled, maar 99% ervan niet door mij.

Als je alles van source compilet ( ) heb je dat probleem uberhaupt niet

Jawel, dan heb je nog veel meer development libraries nodig

Mwoh, gaat al anderhalf jaar uitstekend op mijn miezerige P-II 400-tje

Dingen als X, Qt en Mozilla duren toch erg lang hoor...
* deadinspace 's main desktop is een miezerige pII 400, overgeclockt tot een miezerige 448 MHz

[saviour]

Wat ik mij trouwens nog afvroeg over compileren.

Downloaden jullie alles naar /usr/src en laten jullie het daar dan ook staan voor een make uninstall?

Ik download het altijd gewoon naar mijn homedir en verwijder het na het compileren eigenlijk weer..

[wzzrd]

* Waar pleurt make install zijn zooi neer? (en gaat je package manager daarvan over de zeik?)

*Package* *Manager*

Wat ik mij trouwens nog afvroeg over compileren.

Downloaden jullie alles naar /usr/src en laten jullie het daar dan ook staan voor een make uninstall?

Ik download het altijd gewoon naar mijn homedir en verwijder het na het compileren eigenlijk weer..

Okay, ik geef het toe, SGL is eigenlijk een mietjes distro, want die download alles voor me

Jongens, deze discussie lijkt een beetje op welles-nietes, het gebruiken van binaries of source is een kwestie van smaak. Bijna iederen die linux thuis voor zijn of haar lol gebruikt (zoals ik, en een behoorlijk groot deel van de mensen hier denk ik), zullen dat doen omdat het een bepaalde vorm van uitdaging biedt. Ieder een uitdaging op zijn niveau, ieder de uitdaging van zijn gading. Het maakt niet uit. Als het maar leuk is.

Anyway, linux 0wnz

[deadinspace]

Op vrijdag 15 februari 2002 20:50 schreef saviour het volgende:
Ik download het altijd gewoon naar mijn homedir en verwijder het na het compileren eigenlijk weer..

Ik ook, maar ik install zelfgecompiled spul dan ook altijd in /usr/local, waar de package manager niks te zoeken heeft, zodat die twee elkaar niet in de weg kunnen lopen. Ook blijven er zo geen resten achter; het is alleen een kwestie van /usr/local uitkammen.

[deadinspace]

Op vrijdag 15 februari 2002 21:10 schreef wzzrd het volgende:
*Package* *Manager*

Op donderdag 14 februari 2002 19:05 schreef deadinspace het volgende:
Tamelijk goed georganiseerde source-gerichte distributies als SGL en Gentoo lossen een aantal van deze problemen ver op, dat wel. Maar dan is het meer een SGL/Gentoo vs andere distro's discussie.