sslug-teknik team mailing list archive

[Emil S Hansen <laven.data@xxxxxxxx>]

Okay okay, vi nærmer os religionskrig, så det her er nok den sidste mail
fra mig i denne tråd :)

Troels Arvin wrote: 
> > En ordentlig admin (Som ikke regner med at blive til sine dages ende)
> > sørger altid for at dokumentere, det arbejde han laver, meget godt og
> > grundigt!
> Den er god med dig; virkelighedens verden er ofte ikke så ideel, og
> derfor gælder det om at have systemer til minimere behovet for
> dokumentation.

Enig, men det er sk* alfa og omega at man dokumentere alt hvad man laver
af ændringer på systemet, ellers burde man sku ikke være ansat som
admin. (IMHO)

> > Nu skulle man jo helst have mulighed for med Open Source hurtigt at se
> > hvilken fil der høre til hvor... (Makefile fra gamle versioner, evt.
> > hele sourcen)
> Dette er vist et eksempel på, hvordan Open Source begrebet bliver
> tillagt værdier/formål, som er helt i skoven.

Nu er jeg ikke helt med? Hvad er der galt i det? Det jeg referre til er
at du altid kan finde sourcen til gamle versioner af Open Source
projekter, ergo kan du også finde sourcen til den (gamle) version du har
installeret nu, ergo kan du finde Makefilen.
 
> > Ang. et stort /usr/local, jaa, så findes der jo det her
> > lille trix 'CFLAGS=-O3 ./configure --prefix=/usr'.
> Nu bliver det efter min mening først _helt_ galt: Hvis man ikke
> adskiller operativsystemets bundlede software (/usr) fra det, man selv
> har hacket sammen (/usr/local eller /opt), ja så har man for alvor et
> galt administreret system.

Hvad er forskellen på en .rpm pakke som du har hentet fra nettet og en
.tar.gz fil som du selv har kompillert? Ikke andet end at .rpm ender i
/usr og .tar.gz i /usr/local. Det er bla. også en af mine anker mod
.rpm, filerne ender som standard i /usr i stedet for /usr/local lige
meget om det er en (uautorisert) pakke fra nettet, elelr en (officiel)
pakke fra installationen.
 
> > Og det med mange rare
> > faciliteter, hmm, jaaa, det er da vist kun Debians pakke system der
> > endnu har imponeret mig, .RPM har jeg ikke meget til overs for.
> Det lyder efter min mening lidt religiøst. Men lad os da bare tage
> udgangspunkt i .deb-pakker.

Religiøst, hmm, jow måske en smule :) Men okay, FreeBSD ports collection
er også en meget sej fisk syntes jeg.
 
> > Det skulle ikke være svært at lave et lille script
> Den filosofi med "jamen man kan jo bare skrive et lille script" er
> fundamental GAL: Målet for et godt stykke software må være, at det er
> lettest muligt at installere, så man hurtigt kan komme i gang med det,
> som er formålet - nemlig at få løst nogle opgaver. Og nogle gange er det
> _ikke_ særlig let at skrive et ordentligt init-script; visse
> programpakker skal startes på ret ejendommelige måder. Det med at skulle
> sidde og sammensætte små scripts skulle gerne være undtagelsen, ikke
> reglen.

Hmm, her er vi fundementalt uenige, jeg har det sådan at jeg MEGET gerne
vil vide hvordan programmet bliver konfiguret, startet op, kørt osv.
osv. I og med at jeg selv lige skal kigge i README/INSTALL/man for at
finde ud af de options programmet skal have er chancen stor for at [1]
Jeg lære noget [2] Jeg falder over en option som måske ikke ville være i
en .rpm men som er meget brugbar i mit setup. Og man lære altså en del
mere ved selv at skulle sætte en konfigurationsfil sammen (ud fra et
eks.) end hvis man bare lige laver en apt-get/what ever. Der ud over får
jeg den personlige fordel at jeg kan skifte dist/OS og STÆDIGVÆK sætte
de samme programmer op uden ret meget tilvænning, hvor i mod en der kun
har brugt .rpm vil få det MEGET svært på en Slackware/ROCK Linux/*BSD.

Og så er der jo lige det med compiletime options, hvor vil du finde en
.rpm til php3 som har support for gd, imap, ftp, pop3 men IKKE MySQL?
Eller en hver anden kombination?

Det tager måske 30-60 mins længere at kompillere en .tar.gz pakke, men
man er meget bedre informeret om softwares muligheder og begrænsninger
bag efter.

Mvh.

	Emil S Hansen