mboost-dp1
unknown
Jeg har stadig ikke helt forstået Linux's træstruktur. Så jeg tror på at en omrokering af strukturen vil hjælpe Linux meget på desktop markedet. Jeg skal helt sikkert have et kig på GoboLinux =)
Er der nogen som allerede har prøvet det ?
Er der nogen som allerede har prøvet det ?
Tja...
Ideen er god, og jeg synes det er en fin ide at lade sig inspirere af MacOS, dog skal man nok overveje om man vil bryde med Unix Standarden, med de komplikationer der kan komme der..
Ideen er god, og jeg synes det er en fin ide at lade sig inspirere af MacOS, dog skal man nok overveje om man vil bryde med Unix Standarden, med de komplikationer der kan komme der..
Jeg har længe ment at det optimale OS vil være et med:
Configurerings muligheder som i linux
Filsystem som i mac
og brugervenlighed som i windows
så måske vi nærmer os noget her - skal da helt sikkert undersøges nærmere
Configurerings muligheder som i linux
Filsystem som i mac
og brugervenlighed som i windows
så måske vi nærmer os noget her - skal da helt sikkert undersøges nærmere
Hmm mener nu at filstrukturen i linux er udemærket, Linux er bygger på Unix, og den struktur burde den at beholde.
kan godt se det kan virker forvierende for M$ folk der for første gang prøver en *nix variant, MEN så snart man har vendet sig til den ÆLSKER man den :)
hvor let kan det være, man kan reinstalle hele systemet uden at ens confik filer og ens home mapper bliver slettet blodt ved at man smider dem på en anden partion.
kan godt se det kan virker forvierende for M$ folk der for første gang prøver en *nix variant, MEN så snart man har vendet sig til den ÆLSKER man den :)
hvor let kan det være, man kan reinstalle hele systemet uden at ens confik filer og ens home mapper bliver slettet blodt ved at man smider dem på en anden partion.
#5 Kan du jo også med den nye struktur, endda nemmere.
UNIX/Linux's filstruktur er rodet og ikke-intuitivt - OSX's version af en struktur er langt langt bedre og da man jo i UNIX benytter makefiles, ser jeg ikke nogen problemer med at man ændre strukturen mht. applikations-installering.
UNIX/Linux's filstruktur er rodet og ikke-intuitivt - OSX's version af en struktur er langt langt bedre og da man jo i UNIX benytter makefiles, ser jeg ikke nogen problemer med at man ændre strukturen mht. applikations-installering.
Med den "almindelige" filstruktur i linux, kan det være svært at afinstallere programmer, hvis ikke de er installeret med distributionens pakkesystem. Det ungår man vel med gobolinux?
Men sådan er det vel også med en windows. der smider programmerne også .dll filer til højre og venstre. Reg. databasen er jo heller ikke let at rydde op i.
I sidste ende handler det vel om hvad men bedst kan li'. Personligt synes jeg man skulle holde sig til: http://www.pathname.com/fhs/
mvh
Brian
Men sådan er det vel også med en windows. der smider programmerne også .dll filer til højre og venstre. Reg. databasen er jo heller ikke let at rydde op i.
I sidste ende handler det vel om hvad men bedst kan li'. Personligt synes jeg man skulle holde sig til: http://www.pathname.com/fhs/
mvh
Brian
#1:
Well - imho burde det ikke være nødvendigt at kende noget som helst til fil strukturen som hr. og fru. jensen!
Så et eller andet sted synes jeg det er fjollet at fokusere på en ændring af filsystemet, istedet for at løse de basale usability issues!
#5:
Det kunne være rart hvis du argumenterede med HVORFOR du mener man skal beholde den... :)
Det argument du kommer med ang. backup gør sig jo stadig gældende for det nye layout!
Og hvis du mener at det er så fantastisk og dejligt, så kom lige med en beskrivende forklaring på hvor jeg skal lægge mozilla: I /bin, /usr/bin, /usr/local/mozilla, /usr/share/mozilla eller /opt/mozilla
Ja - det nuværende filsystem er sandelig let og overskueligt... ;o)
Well - imho burde det ikke være nødvendigt at kende noget som helst til fil strukturen som hr. og fru. jensen!
Så et eller andet sted synes jeg det er fjollet at fokusere på en ændring af filsystemet, istedet for at løse de basale usability issues!
#5:
Det kunne være rart hvis du argumenterede med HVORFOR du mener man skal beholde den... :)
Det argument du kommer med ang. backup gør sig jo stadig gældende for det nye layout!
Og hvis du mener at det er så fantastisk og dejligt, så kom lige med en beskrivende forklaring på hvor jeg skal lægge mozilla: I /bin, /usr/bin, /usr/local/mozilla, /usr/share/mozilla eller /opt/mozilla
Ja - det nuværende filsystem er sandelig let og overskueligt... ;o)
"hvor let kan det være, man kan reinstalle hele systemet uden at ens confik filer og ens home mapper bliver slettet blodt ved at man smider dem på en anden partion."
Jeps, det var også min største overvejelse, men jeg må så også indrømme at filsystemet trænger til at blive set igennem, f.ex. har jeg aldrig helt forstået pointen med /opt, den bruges flittigt af kommercielle programmer, men ellers synes jeg den er til at overse.
Og noget andet der generer mig er at de forskellige distros ikke kan komme med en fælles standard for hvor programmerne skal ligge, ex. /usr/local eller /usr ... Det er en plage at skulle vælge prefix hver gang man skal compile i de tilfælde hvor programmet ikke kan detecte ens programstruktur... Eller når ens KDE bibliotek hedder KDE3.1 istedet for KDE.
Men ellers er jeg egentligt glad for filstrukturen.
Jeps, det var også min største overvejelse, men jeg må så også indrømme at filsystemet trænger til at blive set igennem, f.ex. har jeg aldrig helt forstået pointen med /opt, den bruges flittigt af kommercielle programmer, men ellers synes jeg den er til at overse.
Og noget andet der generer mig er at de forskellige distros ikke kan komme med en fælles standard for hvor programmerne skal ligge, ex. /usr/local eller /usr ... Det er en plage at skulle vælge prefix hver gang man skal compile i de tilfælde hvor programmet ikke kan detecte ens programstruktur... Eller når ens KDE bibliotek hedder KDE3.1 istedet for KDE.
Men ellers er jeg egentligt glad for filstrukturen.
Well.
Jeg syns det lugter.
Det blir da et helvede at sidde og hakke
/Programs/Networking Applications/Mozilla
ind istedet for bare
/usr/bin/mozilla
(overdrivelse, but u get the idea)
... men det er jo nok bare mig.
But if it ain't b0rken ..
Jeg syns det lugter.
Det blir da et helvede at sidde og hakke
/Programs/Networking Applications/Mozilla
ind istedet for bare
/usr/bin/mozilla
(overdrivelse, but u get the idea)
... men det er jo nok bare mig.
But if it ain't b0rken ..
-> #9
Enig. Men der er også lavet et forsøg på en standard. Så skal den jo bare overholdes >> http://www.pathname.com/fhs/
Enig. Men der er også lavet et forsøg på en standard. Så skal den jo bare overholdes >> http://www.pathname.com/fhs/
Tjaa, jeg synes den nuværende installations procedure er god nok.
Programmer der kommer med distroen kommer i /usr
Programmer der kommer fra tredje part kommer i /usr/local.
Det er rigtigt at der kommer nogen i /opt, men det er jo obskure tredje parts firmaer...
Men som andre har sagt, så skal brugeren aldrig se filstrukturen.
Computere er lavet for at virke, ikke for at man skal suse rundt i det underliggende system. (Jeg er blevet hjernevasket af GNOME programmører).
Hvis der var nogen der ville lave et godt pakkesystem ville jeg dog være den første der sprang på vognen.
Det skal kunne:
Fuldstændig adskillelse af pakken og installationsprogrammet.
DVS SCRIPTS i pakken skal være banlyst.
Pakken må kun kunne lave konfigurationsindstillinger som er fast defineret i pakkesystemet.
Hvis der skal lave konfigurationer kan pakken henvise til hvad der skal køres, men programmet skal altid kunne installeres uden at køre script filer.
Dette gør at der kan være 3 typer sikkerhedsnivauer.
Der er en_driver_ der bliver installeret og det kan slette hele computeren og kræver genstart.
Eller at nu er det et program der kræver root adgang, og kan slette hele computeren.
Eller at det er et standard program, som kun kan slette brugerdata som kører det.
Lige nu kan rpm eller deb eller alle andre former for installationer slette hele computeren, selvom det måske kun er et program til at vise PDF filer som root aldrig selv vil køre.
En anden vigtig ting er:
Pakken skal være programmet. Dvs at man bare ligger pakken over i sit installations direktur og så er programmet installeret.
(Husk at linux både understøtter FAM og symlinks).
DVS at systemet automatisk laver symlinks fra alle filer i pakkerne. Hvis man vil give programmet til andre, kan man bare kopiere pakken over hvor man vil.
Desuden kan forskellige pakker aldrig overskrive filer fra andre installerede programmer. Det kan højst være en genvej der bliver slettet.
Det giver også fordelen at selvom hele ens registrering af pakkesystemet bliver slettet kan man nemt gendanne denne registrering da alle pakker er inde.
Pakker skal kunne installeres på brugerbasis.
Pakker skal kunne indeholde flere programmer og libs.
Installationsværktøjet kan derved installere en del af en programpakke, og alle dependencies kan følge med programmet.
Der skal være mulighed for netinstallation.
Man kan lave metapakker som henter filer fra nettet (eller andre steder). Disse filer skal være signet af udbyderen af metapakken.
Dette kan også gøres installerede pakker, så man nemt kan lave en 'dist-upgrade' af hele systemet (eller specifikt program).
Der skal være mulighed for simpel (XML) information i pakken. DVS at man kan få vist et billede under installationen, beskrivelse af pakken og nogle default installationsmuligheder som udbyderen har lavet.
Da selve pakken ikke indeholder scripts, er det op til installationsværktøjet at vise disse informationer.
(Det ville ikke give mening for et ncurses installationsværktøj at vise billeder.)
De absolut vigtigste ting er (for mig) dog at pakken ikke må kunne køre scriptfiler og at programmer skal kunne installeres på brugerbasis.
Programmer der kommer med distroen kommer i /usr
Programmer der kommer fra tredje part kommer i /usr/local.
Det er rigtigt at der kommer nogen i /opt, men det er jo obskure tredje parts firmaer...
Men som andre har sagt, så skal brugeren aldrig se filstrukturen.
Computere er lavet for at virke, ikke for at man skal suse rundt i det underliggende system. (Jeg er blevet hjernevasket af GNOME programmører).
Hvis der var nogen der ville lave et godt pakkesystem ville jeg dog være den første der sprang på vognen.
Det skal kunne:
Fuldstændig adskillelse af pakken og installationsprogrammet.
DVS SCRIPTS i pakken skal være banlyst.
Pakken må kun kunne lave konfigurationsindstillinger som er fast defineret i pakkesystemet.
Hvis der skal lave konfigurationer kan pakken henvise til hvad der skal køres, men programmet skal altid kunne installeres uden at køre script filer.
Dette gør at der kan være 3 typer sikkerhedsnivauer.
Der er en_driver_ der bliver installeret og det kan slette hele computeren og kræver genstart.
Eller at nu er det et program der kræver root adgang, og kan slette hele computeren.
Eller at det er et standard program, som kun kan slette brugerdata som kører det.
Lige nu kan rpm eller deb eller alle andre former for installationer slette hele computeren, selvom det måske kun er et program til at vise PDF filer som root aldrig selv vil køre.
En anden vigtig ting er:
Pakken skal være programmet. Dvs at man bare ligger pakken over i sit installations direktur og så er programmet installeret.
(Husk at linux både understøtter FAM og symlinks).
DVS at systemet automatisk laver symlinks fra alle filer i pakkerne. Hvis man vil give programmet til andre, kan man bare kopiere pakken over hvor man vil.
Desuden kan forskellige pakker aldrig overskrive filer fra andre installerede programmer. Det kan højst være en genvej der bliver slettet.
Det giver også fordelen at selvom hele ens registrering af pakkesystemet bliver slettet kan man nemt gendanne denne registrering da alle pakker er inde.
Pakker skal kunne installeres på brugerbasis.
Pakker skal kunne indeholde flere programmer og libs.
Installationsværktøjet kan derved installere en del af en programpakke, og alle dependencies kan følge med programmet.
Der skal være mulighed for netinstallation.
Man kan lave metapakker som henter filer fra nettet (eller andre steder). Disse filer skal være signet af udbyderen af metapakken.
Dette kan også gøres installerede pakker, så man nemt kan lave en 'dist-upgrade' af hele systemet (eller specifikt program).
Der skal være mulighed for simpel (XML) information i pakken. DVS at man kan få vist et billede under installationen, beskrivelse af pakken og nogle default installationsmuligheder som udbyderen har lavet.
Da selve pakken ikke indeholder scripts, er det op til installationsværktøjet at vise disse informationer.
(Det ville ikke give mening for et ncurses installationsværktøj at vise billeder.)
De absolut vigtigste ting er (for mig) dog at pakken ikke må kunne køre scriptfiler og at programmer skal kunne installeres på brugerbasis.
#12
Scriptløst bliver svær..
Der er allerede forsøg www.autopackage.org
men det er ikke scriptløst, tilgengæld er det distroneutralt...
Scriptløst bliver svær..
Der er allerede forsøg www.autopackage.org
men det er ikke scriptløst, tilgengæld er det distroneutralt...
#13
Det ser interessant ud. Jeg kan huske et pakkesystem som kun består af .tar.gz og en _meget_ simpel konfigurations fil.
Genialt imho
Det kan godt være at det er svært at lave scriptløse pakker,men da dette ikke er _umuligt_ mener jeg at det er op til programmørerne at designe programmer til at kunne installere uden scripts.
Jeg mener at dette er et meget vigtigt mål, da jeg har det dårligt med at jeg skal køre alskens mærkelig kode på mit system som root, for at installere programmer som kun brugere skal bruge.
Virkelig et sikkerhedshul til viruser og fejl.
#14
I share direktoriet kommer ting som bliver delt af flere programmer (doh ;).
Sikkert nogle ikoner og ordbøger og sådden.
Det ser interessant ud. Jeg kan huske et pakkesystem som kun består af .tar.gz og en _meget_ simpel konfigurations fil.
Genialt imho
Det kan godt være at det er svært at lave scriptløse pakker,men da dette ikke er _umuligt_ mener jeg at det er op til programmørerne at designe programmer til at kunne installere uden scripts.
Jeg mener at dette er et meget vigtigt mål, da jeg har det dårligt med at jeg skal køre alskens mærkelig kode på mit system som root, for at installere programmer som kun brugere skal bruge.
Virkelig et sikkerhedshul til viruser og fejl.
#14
I share direktoriet kommer ting som bliver delt af flere programmer (doh ;).
Sikkert nogle ikoner og ordbøger og sådden.
#4
og brugervenlighed som i windows
Så brugervenligt er windows nu heller ikke.
eksempel:
Programmet har udført en ulovlig handling kontakt forhandleren?
tema ændring i windows XP
Hvad angår linux og .conf filer er det rart at de er i tekst, men træls at strukturen i de forskellige conf filer ALTID er forskellig :-/ altid man program.conf
(flueknepperi)
Vi snakker filstruktur og ikke filsystem :)
Windows NTFS ACL filrettigheder på deres system mangler linux desværre stadig :-/ Det ville være rart at kunne tilføjere flere brugere på den samme fil, eller flere root accounts...
#8
Så vidt jeg kan se skal du ligge mozilla /usr/local eller /opt/
Jeg tror dog jeg foretrækker linux filstrukturen som den er i stedet for en total modering af det. Nu er man så småt ved at lære det, og med http://www.pathname.com/fhs/ er det lidt nemmere.
/usr/share bruges til system independent data, hvor jeg forstår det som fx java programmet etc.
Nej logisk er det måske ikke alt sammen :-/
og brugervenlighed som i windows
Så brugervenligt er windows nu heller ikke.
eksempel:
Programmet har udført en ulovlig handling kontakt forhandleren?
tema ændring i windows XP
Hvad angår linux og .conf filer er det rart at de er i tekst, men træls at strukturen i de forskellige conf filer ALTID er forskellig :-/ altid man program.conf
(flueknepperi)
Vi snakker filstruktur og ikke filsystem :)
Windows NTFS ACL filrettigheder på deres system mangler linux desværre stadig :-/ Det ville være rart at kunne tilføjere flere brugere på den samme fil, eller flere root accounts...
#8
Så vidt jeg kan se skal du ligge mozilla /usr/local eller /opt/
Jeg tror dog jeg foretrækker linux filstrukturen som den er i stedet for en total modering af det. Nu er man så småt ved at lære det, og med http://www.pathname.com/fhs/ er det lidt nemmere.
/usr/share bruges til system independent data, hvor jeg forstår det som fx java programmet etc.
Nej logisk er det måske ikke alt sammen :-/
#16, #8
Mozilla er et af de programmer du kan lægge hvor du vil.
Apple style. Det har alle dependencies med. Kast det ind i ~/Applications hvis du vil.
Dog giver mozilla ikke muligheden for ikoner og 'genvej' fra consol til bare at skrive mozilla.
alle bin og sbin direktorierne indeholder kun programnavnet. Ikke nogen libraries og ikke nogen datafiler.
Så det mest 'normale' ville være at udpakke mozilla i /usr/local.
Stort set alle (commercielle) spil på Linux bliver installeret af et script som lægger en ikon genvej ind til gnome/KDE/(andre?) og et link til exe filen fra /usr/local/bin
Hele spillet ligger så i /usr/local/games/navn
Mozilla er et af de programmer du kan lægge hvor du vil.
Apple style. Det har alle dependencies med. Kast det ind i ~/Applications hvis du vil.
Dog giver mozilla ikke muligheden for ikoner og 'genvej' fra consol til bare at skrive mozilla.
alle bin og sbin direktorierne indeholder kun programnavnet. Ikke nogen libraries og ikke nogen datafiler.
Så det mest 'normale' ville være at udpakke mozilla i /usr/local.
Stort set alle (commercielle) spil på Linux bliver installeret af et script som lægger en ikon genvej ind til gnome/KDE/(andre?) og et link til exe filen fra /usr/local/bin
Hele spillet ligger så i /usr/local/games/navn
#17:
Ja, jeg ved godt at mozilla er ligeglad med hvor det ligger, men det var udfra et sysadministrations aspekt - hvis jeg sætter mig ned ved en fremmed maskine for at opdatere mozilla på systemet, skal jeg lige lede en håndfuld steder først!
Og hvis vi nu skal gøre det rigtigt sjovt - hvor mon pluginsne til mozilla ligger? :)
Problemet er at der er alt for stor forskel - i en windows maskine ligger programmerne i 99% af tilfældende i c:\Program Files(localized), på en linux maskine er det et åbent spørgsmål! :)
Men som #16 iøvrigt nævner - ja, lad os lige give mulighed for at give rettigheder til flere enkeltbrugere - det synes jeg personligt er mere frustrerende end filstrukturen! :)
Ja, jeg ved godt at mozilla er ligeglad med hvor det ligger, men det var udfra et sysadministrations aspekt - hvis jeg sætter mig ned ved en fremmed maskine for at opdatere mozilla på systemet, skal jeg lige lede en håndfuld steder først!
Og hvis vi nu skal gøre det rigtigt sjovt - hvor mon pluginsne til mozilla ligger? :)
Problemet er at der er alt for stor forskel - i en windows maskine ligger programmerne i 99% af tilfældende i c:\Program Files(localized), på en linux maskine er det et åbent spørgsmål! :)
Men som #16 iøvrigt nævner - ja, lad os lige give mulighed for at give rettigheder til flere enkeltbrugere - det synes jeg personligt er mere frustrerende end filstrukturen! :)
Jeg tror nu jeg foretrækker at beholde min filstruktur som det er. Hvis Unix måden er så dårlig hvordan kan de så være at der først er begyndt at blive lavet ændringer nu ? Hvis folk gad overholde de regler der er for Unix filsystemets layout ville der heller ikke være nogen problemer. Men der skal jo selvfølgelig nok dukke nogle mennesker og der mener at de er meget klogere end alle andre Unix folk igennem de sidste 30 år.
Indrømmet jeg har set mange lede efter deres homedir i /usr, så lige det navn var måske ikke så heldigt valgt.
GoboLinux hjælper ikke, de forvirre. Man skal ikke ændre i den slags ting uden at får alle andre distributioner med. Og hvad er ideen med uppercase bogstaver i directory navne? Det er selvfølgelig en smart måde af fast holde folk i Gobo. Det er bare lidt usmart, når vi nu har en struktur der er ens på så mange forskellige platforme, det gør det altså noget nemmere for folk at gå væk fra Linux når filstrukturen er ens på alle platforme (Med undtagelse af Mac og Windows).
Jeg synes nu også jeg hører nogle mennesker råbe lidt for højt om MacOSX. Hvis jeg husker rigtigt bruger de NetInfo i stedet for nemt forståelige tekst filer ? Den tilgang har vi vidst set i Windows registrerings database og den er da ikke for heldig. Jeg nægter at tror på nogen finder registrerings database nemmere at arbejde med en tekst filer, endnu et brugervenlighed point til Linux / Unix.
Men okay, vil Gobo flytte rundt på ting der ellers virker unden problemer for hovedparten så er det jo deres begravelse.
Indrømmet jeg har set mange lede efter deres homedir i /usr, så lige det navn var måske ikke så heldigt valgt.
GoboLinux hjælper ikke, de forvirre. Man skal ikke ændre i den slags ting uden at får alle andre distributioner med. Og hvad er ideen med uppercase bogstaver i directory navne? Det er selvfølgelig en smart måde af fast holde folk i Gobo. Det er bare lidt usmart, når vi nu har en struktur der er ens på så mange forskellige platforme, det gør det altså noget nemmere for folk at gå væk fra Linux når filstrukturen er ens på alle platforme (Med undtagelse af Mac og Windows).
Jeg synes nu også jeg hører nogle mennesker råbe lidt for højt om MacOSX. Hvis jeg husker rigtigt bruger de NetInfo i stedet for nemt forståelige tekst filer ? Den tilgang har vi vidst set i Windows registrerings database og den er da ikke for heldig. Jeg nægter at tror på nogen finder registrerings database nemmere at arbejde med en tekst filer, endnu et brugervenlighed point til Linux / Unix.
Men okay, vil Gobo flytte rundt på ting der ellers virker unden problemer for hovedparten så er det jo deres begravelse.
#19:
Jeg tror du forveksler effektivt med brugerveligt!
Tekstfiler er IKKE brugervenlige - men meget effektive for os der forstår hvad der forgår!
Men som jeg iøvrigt siger i mit første indlæg - directorystrukturen er fløjtende ligegyldig - altd uden for /home/seahawk skal der kun være adgang til via diverse konfigurations værktøjer! Dvs. at man som almindelig bruger aldrig vil se resten af filsystemet!
#21:
De ændrer det vel fordi de IKKE synes det er fint som det er? :)
Husk nu mantraet når folk brokker sig over at xxx ikke kan yyy: Du had adgang til sourcen - lav det selv hvis du er utilfreds!
Det er jo dybest set bare hvad disse folk har gjort, så hvis man ikke er tilfreds med det synes jeg egentlig bare man skal fortsætte med sin nuværende distro!
(Ah ja, og så er *nixfolk jo nok de mest religiøse og konservative der overhovedet findes - du finder jo ikke mange windowsfolk der har vænnet sig til at tingene er som de er i 10-20 år :))
Jeg tror du forveksler effektivt med brugerveligt!
Tekstfiler er IKKE brugervenlige - men meget effektive for os der forstår hvad der forgår!
Men som jeg iøvrigt siger i mit første indlæg - directorystrukturen er fløjtende ligegyldig - altd uden for /home/seahawk skal der kun være adgang til via diverse konfigurations værktøjer! Dvs. at man som almindelig bruger aldrig vil se resten af filsystemet!
#21:
De ændrer det vel fordi de IKKE synes det er fint som det er? :)
Husk nu mantraet når folk brokker sig over at xxx ikke kan yyy: Du had adgang til sourcen - lav det selv hvis du er utilfreds!
Det er jo dybest set bare hvad disse folk har gjort, så hvis man ikke er tilfreds med det synes jeg egentlig bare man skal fortsætte med sin nuværende distro!
(Ah ja, og så er *nixfolk jo nok de mest religiøse og konservative der overhovedet findes - du finder jo ikke mange windowsfolk der har vænnet sig til at tingene er som de er i 10-20 år :))
#18 - `which mozilla` :)
#20 - Yup. Men jeg har ikke mine dokumenter i min Path. Fx.
Udover det, som sagt - If it ain't broken, why fix it ?
Hvorfor skal alting iøvrigt altid reduceres til laveste fællesnævner ?
Hvis du ikke ved hvad /usr er fx, er det jo nok oxo bedst hvis du holder pølserne væk :)
#21 - Yup =)
Linux is userfriendly .. its just picky about its friends.
#20 - Yup. Men jeg har ikke mine dokumenter i min Path. Fx.
Udover det, som sagt - If it ain't broken, why fix it ?
Hvorfor skal alting iøvrigt altid reduceres til laveste fællesnævner ?
Hvis du ikke ved hvad /usr er fx, er det jo nok oxo bedst hvis du holder pølserne væk :)
#21 - Yup =)
Linux is userfriendly .. its just picky about its friends.
#22 Jeg forveklser ikke noget. En tekst filer er nemmere at forstå end en registrerings database. Der findes ting in Windows du kan ændre uden at skulle ret direkte i registrerings databasen og den er altså ikke så nem at forstå som en tekst fil. Der hvor du kan rette ting fra et eller andet GUI har du selvfølgelig nogenlunde ret. Jeg mener da det er vigtigt at brugervenlig ikke altid blive tolket om "Store fede ikoner med mange farver". Linux er brugervenlig, det er ikke øjebliklig brugervelig, men på længere sigt mener jeg at det er nemmere at bruge Linux. Mange mennesker oplever aldrig at Linux er nemt fordi de ikke bruger deres computer særligt ofte og det er da helt i orden med mig. Det jeg har et problem med er når man forsøger at gøre ting nemmere for Hr. og Fru Jensen og ødelægger de elementer der gør mig i stand til at arbejde hurtigere.
#24:
Registrerings databasen er heller ikke noget det er meningen man skal rette i manuelt... :)
Men dit sidste argument kan jeg kun give dig ret i, og det mener jeg er grunden til at linux ALDRIG vil blive et OS folk bruger på samme måde de bruger Windows!
One size doesn't fit all! :)
(En helt anden ting er at jeg mener den slags altomfattende OS stort set vil uddø i løbet af 12-15 år - men det er en anden snak...)
Registrerings databasen er heller ikke noget det er meningen man skal rette i manuelt... :)
Men dit sidste argument kan jeg kun give dig ret i, og det mener jeg er grunden til at linux ALDRIG vil blive et OS folk bruger på samme måde de bruger Windows!
One size doesn't fit all! :)
(En helt anden ting er at jeg mener den slags altomfattende OS stort set vil uddø i løbet af 12-15 år - men det er en anden snak...)
#15
Det skal så lige siges, at det eneste den bruger scripts til er at løse dependencies, idet der ikke skal være en database, men den derimod skal analysere harddisken efter det...Ideen er så at man udvikler scripts lavet til at detecte de software komponenter og laver et arkiv, og så kan folk bare indsætte de scripts i pakken som der er dependencies til og det bliver nemt og EFFEKTIVT, dvs. INGEN STATIC LINKING
Det du snakker om er et installationssystem i stil med NeXT som MacOSX kører med, det er genialt idet at man bare har et bibliotek der indeholder HELE programmet. Problemet er bare at Linux består af flere tusinde programdele, og de kan være forskellige fra distro til distro, compiled med forskellige flags, og det SKAL et pakkesystem tage højde for. Læs evt. FAQ på "www.autopackage.org" de beskriver det bedre end jeg gør...
Det skal så lige siges, at det eneste den bruger scripts til er at løse dependencies, idet der ikke skal være en database, men den derimod skal analysere harddisken efter det...Ideen er så at man udvikler scripts lavet til at detecte de software komponenter og laver et arkiv, og så kan folk bare indsætte de scripts i pakken som der er dependencies til og det bliver nemt og EFFEKTIVT, dvs. INGEN STATIC LINKING
Det du snakker om er et installationssystem i stil med NeXT som MacOSX kører med, det er genialt idet at man bare har et bibliotek der indeholder HELE programmet. Problemet er bare at Linux består af flere tusinde programdele, og de kan være forskellige fra distro til distro, compiled med forskellige flags, og det SKAL et pakkesystem tage højde for. Læs evt. FAQ på "www.autopackage.org" de beskriver det bedre end jeg gør...
#29
Ja okay, der er et lille skript som en del af pakken der ekserkverer dem, så ja det har du vel ret i...
Men arkitekturen er distroneutral og så fungerer den uden en app database, så det er jo smart nok...Hvis du skulle lave et pakkesystem som det du omtaler ville du jo være nødt til at bruge static linking til næsten alt, medmindre du altså vil gøre det non-distroneutralt
Ja okay, der er et lille skript som en del af pakken der ekserkverer dem, så ja det har du vel ret i...
Men arkitekturen er distroneutral og så fungerer den uden en app database, så det er jo smart nok...Hvis du skulle lave et pakkesystem som det du omtaler ville du jo være nødt til at bruge static linking til næsten alt, medmindre du altså vil gøre det non-distroneutralt
noget jeg ikke fatter, det betyder jo ikke en skid at man laver om i standarden for hvordan et OS er installeret, de fleste lever med det de får, resten kan sikkert finde ud af at ændre i konfigurationen selv...
Dog findes der en milliard windows applikationer som har afhængigheder til div filer som typisk bliver kopieret til windows system folder !!, DET ER LAMT...
Ok, det kan betyde nogle flere MB hvis de skal ligge sammen med programmet, men jeg er ret sikker på at med de diske vi har i dag, vil den alm. bruger blive super glad for det i længden. mest fordi når man køber et nyt prog som installere en nyere version af nogle *.dll filer som ikke har 100% samme funktioner, så er det gamle program fucked... hvis nu udviklere valgte at gøre deres programmer lidt smartere ville de *.dll filer kunne placeres i en mappe sammen med programmet, og alt som ellers bliver stoppet i registry kunne man så gemme i en *.cfg eller noget, så ville programmet kunne tåle at man sletter sit OS og installere det igen... SEJT SEJT. ALLE ved at det er relativt let for udviklere at gøre det sådan, men hvorfor er der så ingen der gør det ????, jeg fatter det ikke.
Måske noget med at de ikke vil vise hvor stor afhængighed programmet har ????
Jeg tror ikke på at det vil fordyre applikationer hvis de lavede det som en option at man enten kunne vælge en *applikations_folder*/systemfiles eller en *OS*/system files for at spare plads....
Dog findes der en milliard windows applikationer som har afhængigheder til div filer som typisk bliver kopieret til windows system folder !!, DET ER LAMT...
Ok, det kan betyde nogle flere MB hvis de skal ligge sammen med programmet, men jeg er ret sikker på at med de diske vi har i dag, vil den alm. bruger blive super glad for det i længden. mest fordi når man køber et nyt prog som installere en nyere version af nogle *.dll filer som ikke har 100% samme funktioner, så er det gamle program fucked... hvis nu udviklere valgte at gøre deres programmer lidt smartere ville de *.dll filer kunne placeres i en mappe sammen med programmet, og alt som ellers bliver stoppet i registry kunne man så gemme i en *.cfg eller noget, så ville programmet kunne tåle at man sletter sit OS og installere det igen... SEJT SEJT. ALLE ved at det er relativt let for udviklere at gøre det sådan, men hvorfor er der så ingen der gør det ????, jeg fatter det ikke.
Måske noget med at de ikke vil vise hvor stor afhængighed programmet har ????
Jeg tror ikke på at det vil fordyre applikationer hvis de lavede det som en option at man enten kunne vælge en *applikations_folder*/systemfiles eller en *OS*/system files for at spare plads....
#30
Yep, det er ret lækkert. Men den bruger nu en central database (dog ikke til dependencies), den kan checke for dependencies på flere måder, dels ved at se om pakken ligger i samme direktur, om de konkrete filer er installeret, og endelig kan den gå på nettet og downloade.
Jeg synes helt klart at det er et projekt der er værd at bygge videre på.
Software kan sagtens udvikle sig som evolution i stedet for revolution.
#31
Tjaa, det er rart at nøjes med at gemme /home og /usr/local når man installerer nyt system.
Desværre bliver genvejene i startmenuen slettet når man installerer igen :/
Yep, det er ret lækkert. Men den bruger nu en central database (dog ikke til dependencies), den kan checke for dependencies på flere måder, dels ved at se om pakken ligger i samme direktur, om de konkrete filer er installeret, og endelig kan den gå på nettet og downloade.
Jeg synes helt klart at det er et projekt der er værd at bygge videre på.
Software kan sagtens udvikle sig som evolution i stedet for revolution.
#31
Tjaa, det er rart at nøjes med at gemme /home og /usr/local når man installerer nyt system.
Desværre bliver genvejene i startmenuen slettet når man installerer igen :/
Okay - jeg får nok helt vildt smæk når jeg nævner det her.
Men hold k*ft hvor kan jeg nogen gange godt savne den lethed der var forbundet med at administrere sin software på Amigaen.
Jeg er ikke specielt nostalgisk eller fanatisk - men der var f*nme mange ting der var gennemtænkte i Amiga OS. Ting var nemme at finde, nemme at administrere og man kunne sjældent f*cke tingene fuldstændigt op (hvilket jo til dels skyldes at Kickstarten, men alligevel).
Det tætteste jeg synes jeg er kommet på Amigaens elegance er Mac OS X. Jeg har brugt Win i lang tid og også høvlet en smule rundt i Mandrake, RedHat o.l. Men det er kr*ftstejlme lækkert let i OS X.
Men hold k*ft hvor kan jeg nogen gange godt savne den lethed der var forbundet med at administrere sin software på Amigaen.
Jeg er ikke specielt nostalgisk eller fanatisk - men der var f*nme mange ting der var gennemtænkte i Amiga OS. Ting var nemme at finde, nemme at administrere og man kunne sjældent f*cke tingene fuldstændigt op (hvilket jo til dels skyldes at Kickstarten, men alligevel).
Det tætteste jeg synes jeg er kommet på Amigaens elegance er Mac OS X. Jeg har brugt Win i lang tid og også høvlet en smule rundt i Mandrake, RedHat o.l. Men det er kr*ftstejlme lækkert let i OS X.
#31
"Dog findes der en milliard windows applikationer som har afhængigheder til div filer som typisk bliver kopieret til windows system folder !!, DET ER LAMT... "
Uhhh, for min skyld må i meget gerne gøre det i windows, det er jeg sådanset ligeglad med, men linux, NEJ. Det er det man kalder for static linking og det er intet problem hvad angår harddisk, men når det gælder hastighed så er det tit, ikke altid, men der er mange tilfælde hvor det er ABSOLUT nødvendigt med dynamisk linking.
Et godt eksempel er opengl, opengl's specificationsfil hedder såvidt jeg husker opengl32.dll(.o), denne fil fortæller programmet hvad det skal gøre med forskellige opengl opkald, disse opkald bliver i høj grad optimeret efter grafikkort, (når du downloader en driver følger der somregel en optimeret opengl32.dll fil med), denne fil sørger for at disse opengl kald bliver mapped til de rigtige features i dit grafikkort, dvs. hvis der er særlige moduler i grafikkortet der er lavet til at udføre specifikke beregninger så bliver de mapped korrekt.
Hvis man skulle static linke alt, ville alle disse optimeringer være mere eller mindre værdiløse, og man skulle enten leve uden dem, eller evt. udelukke en brugergruppe. Og det er meget større end det, MMX, og SSE(2) er også eksempler på kodespecifikke optimeringer der kræver specifikke dll filer. Disse filer bliver derfor holdt dynamiske, og sålænge man sørger for at de indeholder de sammen funktioner, men bare mapper dem på en anden måde, så fungerer det hele fint. Tro mig, hvis du skulle køre static linking så ville du miste 20-30% performance på moderne maskiner, medmindre programmet er optimeret til en moderne arkitektur, hvilket udelukker gamle, derfor er DLL og .o mareridtet desværre ikke bare en ting der kan fejes af banen uden alvorlige tab i performance.
Håber sørme ikke kun du troede det var diskplads det handlede om...
"Dog findes der en milliard windows applikationer som har afhængigheder til div filer som typisk bliver kopieret til windows system folder !!, DET ER LAMT... "
Uhhh, for min skyld må i meget gerne gøre det i windows, det er jeg sådanset ligeglad med, men linux, NEJ. Det er det man kalder for static linking og det er intet problem hvad angår harddisk, men når det gælder hastighed så er det tit, ikke altid, men der er mange tilfælde hvor det er ABSOLUT nødvendigt med dynamisk linking.
Et godt eksempel er opengl, opengl's specificationsfil hedder såvidt jeg husker opengl32.dll(.o), denne fil fortæller programmet hvad det skal gøre med forskellige opengl opkald, disse opkald bliver i høj grad optimeret efter grafikkort, (når du downloader en driver følger der somregel en optimeret opengl32.dll fil med), denne fil sørger for at disse opengl kald bliver mapped til de rigtige features i dit grafikkort, dvs. hvis der er særlige moduler i grafikkortet der er lavet til at udføre specifikke beregninger så bliver de mapped korrekt.
Hvis man skulle static linke alt, ville alle disse optimeringer være mere eller mindre værdiløse, og man skulle enten leve uden dem, eller evt. udelukke en brugergruppe. Og det er meget større end det, MMX, og SSE(2) er også eksempler på kodespecifikke optimeringer der kræver specifikke dll filer. Disse filer bliver derfor holdt dynamiske, og sålænge man sørger for at de indeholder de sammen funktioner, men bare mapper dem på en anden måde, så fungerer det hele fint. Tro mig, hvis du skulle køre static linking så ville du miste 20-30% performance på moderne maskiner, medmindre programmet er optimeret til en moderne arkitektur, hvilket udelukker gamle, derfor er DLL og .o mareridtet desværre ikke bare en ting der kan fejes af banen uden alvorlige tab i performance.
Håber sørme ikke kun du troede det var diskplads det handlede om...
#12 man er nødt til at have en eller anden form for detektion og generering af symlinks i instalations proceduren men man kan ve godt standardisere denne proccess så man slipper for at eksekvere vilkårlige shell-scrips med root privilegier.
Iøvrigt ligger meget af det du beskriver i slackware's tgz pakker.
#16 du skal passe på med at sige at linux mangler bare fordi det ikke er i std konfigurationen :-)
Jeg Mener faktisk at have set acl til linux det kommer vist også an på valgte filsystem.
#31 hvis man laver duplikater af system biblioteker bliver de jo så godt som umuglige at opgradere fordi man så er oppe i noget der minder om en reinstalation af alt.
/opt er vist et lævn fra komesiel unix(solaris HP-UX m.f.) men det er egentligt smart nok at have komersielle ting samme sted.
Iøvrigt ligger meget af det du beskriver i slackware's tgz pakker.
#16 du skal passe på med at sige at linux mangler bare fordi det ikke er i std konfigurationen :-)
Jeg Mener faktisk at have set acl til linux det kommer vist også an på valgte filsystem.
#31 hvis man laver duplikater af system biblioteker bliver de jo så godt som umuglige at opgradere fordi man så er oppe i noget der minder om en reinstalation af alt.
/opt er vist et lævn fra komesiel unix(solaris HP-UX m.f.) men det er egentligt smart nok at have komersielle ting samme sted.
#35:
Ja, ACL er med i næste kerne version... Men hvis du kører server, hvor ACL er det eneste sted hvor det vil være interessant, vil jeg ikke vælge at køre noget experimental. Det må gerne lige være lidt stable og testet inden.
Beta versioner på ens filsystem har jeg ikke lyst til :)
Ja, ACL er med i næste kerne version... Men hvis du kører server, hvor ACL er det eneste sted hvor det vil være interessant, vil jeg ikke vælge at køre noget experimental. Det må gerne lige være lidt stable og testet inden.
Beta versioner på ens filsystem har jeg ikke lyst til :)
#36 du skal som jeg siger passe på med at sige linux == linus's standard kernel.
Der findes patches uvidelser og versioner der er stabile men af andre grunde ikke er i standard kernen.
ACL er ikke noget der kommer i 2.6.0 kernen det har været tilgængeligt længe og har været testet.
Der findes patches uvidelser og versioner der er stabile men af andre grunde ikke er i standard kernen.
ACL er ikke noget der kommer i 2.6.0 kernen det har været tilgængeligt længe og har været testet.
#38:
Ligesom EXT3 krævede en patch til kernen kræver ACL det også.
Den patch kommer med som standard i EXT3, såvidt jeg ved :)
At der findes patches som er stabile har du måske ret i, men jeg foretrækker tingene lidt mere mainstream end det. Mainstream = de er med i kernen når jeg henter den.
Er det med som standard i kernen er changen for at de andre programmer der fås til linux også udnytter det fx samba.
Ligesom EXT3 krævede en patch til kernen kræver ACL det også.
Den patch kommer med som standard i EXT3, såvidt jeg ved :)
At der findes patches som er stabile har du måske ret i, men jeg foretrækker tingene lidt mere mainstream end det. Mainstream = de er med i kernen når jeg henter den.
Er det med som standard i kernen er changen for at de andre programmer der fås til linux også udnytter det fx samba.
#38 det er så din holdning men så bør du også værre klar over at du har bundet dig selv på hænder og fødder mht til valg af software og ikke tager stilling til virkeligheden.
Overvej også om der kan værre andre grunde end stabilitet til at man ikke har implementeret ACL som standard!
Hvis du satser 100% på mainsream får du aldrig nogen væsentlig konkurencemæssig fordel ud af dit IT-system.
Overvej også om der kan værre andre grunde end stabilitet til at man ikke har implementeret ACL som standard!
Hvis du satser 100% på mainsream får du aldrig nogen væsentlig konkurencemæssig fordel ud af dit IT-system.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund