David Brown

Siden trådstarter skal kjøre Virtualbox, så er det nok snakk om et vanlig desktop OS også - og man kan trekke benchmarks ut av sammenhengen og få fram hva man vil, men Bulldozer er jo ikke ubrukelig, det er ting den er bra på - det er bare det at svakhetene overskygger dette.

 

Det er som sagt ikke stor uenighet om dette......

 

Jeg sendte min FX8150 tilbake og puttet inn igjen 1090T'en iallefall.

Du har sannsynligvis rett - VirtualBox er relativt sjelden brukt på serverer, og noen av spørsmålene til OP tider på at han ikke er spesielt erfaren med dette. Men hvis man ville så er det fult mulig å installere en minimalt Linux system og så VirtualBox, og kjøre "arbeidet" innenfor headless virtuelle PC'er. Hvis jeg måtte bruke Windows på en server, hadde jeg gjerne gjort det på den måten.

Du går ikke glipp av noen funksjonalitet med å installere en gui, men du går glipp av pålitelighet og sikkerhet. Prinsippet her er "KISS" - Keep It Simple, Stupid. Jo mer du har av programvare på systemet, jo mer det er som kan gå galt - og gui, skjermdriverer, og bruker applikasjoner er de svakeste punktene i programvare, og de frister den alle svakeste ledd i systemet - brukeren - til å kjøre gui programmer lokalt. Linux har med god grunn en rykte for å være langt sikrere og mer pålitelig enn Windows - men det er ingen som påstår at alt er 100%. Hvorfor installere en svak ledd hvis du ikke trenger det - gui'en hjelper ikke serverfunksjoner.

Ellers lurer jeg på hvorfor du gidder å kryptere filsystemet. Er det redd for at noen bryter seg inn hos deg, stjele serveren og less igjennom alle data? Jeg forstår kryptering av bærbar, og jeg forstår kryptering av trafikk over internet, men kryptering av filsystemet på en server er vanligvis helt unødvendig, og bare fører til komplikasjoner dersom det oppstår problemer.

Bruker du en OS som har skikkelig kontroll på forskjellige brukere (som f.eks. Linux, men også BSD'er eller t.o.m. MacOS), kan man lage en annen bruker og surfer fra den. Da er din vanlig bruker historikk, cookies, osv., ikke påvirket, fordi det er ikke "du" som kjører browseren.

Er man litt paranoid, er det bare å boote fra en Linux live CD, surfer så mye man vil, og skru av PC'en etterpå.

 

Veldig godt poeng på slutten der, det skal eg huske på Igjen tusen takk for hjelpen:) Trur eg har alt på plass av planleggingen så må begynne å kjøpe inn utstyr! Men det står på mange hovudkort kun støtte for RAID 0,1,10,5 ingenting om RAID 6men går det fint med kun software raid?!?

 

eksempel HK: http://www.komplett.no/k/ki.aspx?sku=599965#extra

Der er det 6 x SATA 600 mulighet for RAID 0,1,5,10 JBOD

+ 1 SATA 300 som eg skal bruke som OS:)

Glem hovedkort raid - det er et slags kunstig raid som har alle ulemper av hardware raid (infleksibilitet, tilknytting til bestemte hardware, og treghet) uten noen av fordelene. mdadm software raid i Linux er ikke begrenset av hovedkort.

https://raid.wiki.kernel.org/

Det er flere forskjeller mellom "desktop" og "server" versjonene, men også mange likheter. Det viktigste punktet er at de er samme systemet - det er bare default pakkene som er annerledes. Man kan alltid gå fra den ene til den andre (eller en blanding av begge deler) ved å installere forskjellige pakker.

Det mest synlig forskjell etter installasjon er at med "desktop" versjon har man en gui samt mange bruker applikasjoner. Med "server" versjon har man ingen gui. (Man har heller ikke mange server applikasjoner ved default - de installere man etter behov.) For en server, er det en /stor/ fordel ikke å ha en gui, og ikke å ha alle det andre programvare og tjenester som er tilpasset en desktop. Det viktigste grunnet er at med en server skal du holder systemet renn og enkelt - du skal kun ha det du trenger, og ikke noe mer. Det gjør serveren mer effektivt, sikrere (en server system har langt færre programmer), lettere å vedlikeholde, mer pålitelig, og lettere å administrere.

Det fins også andre mindre synlig forskjeller. Jeg er ikke særlig kjent med Ubuntu som server, men ofte er det forskjell mellom "server" kernel og "desktop" kernel - typisk er opsjonene i "server" kernel valgt for å få høyere gjennomgang av data, mens i "desktop" kernel er det større fokus på lavere responstid til bruker applikasjoner.

Du burde lære deg å gjøre enkelte administrasjon fra kommandolinjen. Det går ikke an å gjøre alt fra guier likevel. Kommandolinjen er ikke farlig, men det tar litt mer tid å bli vant med en en gui. Men når du har prøvd kommandolinjen en del, og lært litt, er det /mye/ mer effektivt. Når du har funnet ut hvor enkelt og raskt det er å installere en pakke med "apt-get install", kommer du aldri igjen å bruke gui-basert pakkemanager selv på desktop systemer - det er bare så treg og tungvindt. Når serveren din sitter gjemt i en skap en plass, med bare nettverk og strøm tilkobling, og du administrere den fra hvor som helst via ssh, vil du tenke med latter på de som må ha plass til en skjerm, tastatur og mus til en server, og trenger å gå fysisk til maskinen for å gjøre de enkleste jobb.

Det er klart at det blir litt skremmende i første omgang å bruke kommandolinjen. Ikke vær redd for å prøve ting, setter av god tid slik at du kan forstå det du skriver, og ha en PC med en browser lett tilgjengelig for å hjelpe deg. Vær presis når du kopiere kommandoer fra howtos og andre resurser, og passer på at rådet kommer fra pålitelige kilder. Og pass på at du har kopier av alt data!

Også husk at det fins mellomløsninger som er nyttig i mange tilfeller. webmin er veldig praktisk program som gir deg en webbasert grensesnitt inn til serveren uten at du har alle ulempene av å ha en desktop installerte på den.

Takk for godt svar!!!

kommer du til å bruke mye/om ikkje alt av den informasjonen du har gikk meg nå til å sette isammen ein PC

 

RAID 6 er vel det samme som RAID 5 ,berre det tolerere 2 disk-failure.

Det var ein del enklere å finne hovudkort til kun 6 disker i raid så trur nok eg gjer det, siden eg ser at eg kan få nok plass med 6 disker.Då vil eg ha 10 TB i raid og ein harddisk med OS Til sammen 7 disker.

Heile raid-område skal være dedikert til data-område.

Til backup, skal eg ha ein identisk PC som står i eit anna bygg... Burde eg ha ein 3.backup og eller ?!?

Ja, raid6 er som raid5 men med 2 parity blocks, og dermed toleranse for 2 diskfeil. Writes i raid6 koster mer enn med raid5 i cpu tid og latency, fordi det mer krevende kalkulasjoner og man må alltid lese inn hele stripen før man kan endre noe. Men det gjør ingenting for deg - det er bare for write-heavy applikasjoner (og spesielt med mange små writes) at dette er et problem. Det er også ofte mye dyrere med raid6 støtte på hardware raid kort - fabrikantene tar ofte ekstra betalt for en "raid6 lisens" - men med Linux software raid er prisen den samme (gratis).

Om du trenger en tredje backup kommer an på om du har flere kopier av dataen allerede. Hvis du har alt på andre steder, som f.eks. på dvd'er (med flere kopier), er det ikke så kritisk - men hvis disse to pc'er er de eneste to med alt data, burde du ha en tredje kopi. Men da vil jeg anbefale at du /ikke/ ha automatisk backup - eller at du ihvertfall er svært forsiktig med det. Det er veldig dumt om noen skriver noe feil til en av filene, eller slette en fil, og denne feilen blir replikert automatisk til alle kopier...

Husk når du legge opp raid'en at du tester den - prøv å ta ut en disk og se hva som skjer, og hvordan du takle den. Du ønsker å vite på forhånd hva du skal gjøre når noe går galt - det blir /veldig/ stressende å lære om dette mens en disk er død. Og skriv nummerer på diskene - det siste man ønsker å gjøre når en disk har død er å fjerne feil disk! (Det er derfor raid6 er så mye bedre enn raid5 :-)

Det skal være eit arkiv (filmer og statestikker osv...). Oppetid er ikkje kritisk (det gjer ingenting om serveren /PC er nede 2 dager). Planen er å ha 4x harddisker alla 2 TB i raid 0 og 4 stk som blir speilet. Så 8TB på raid 10 , eller har eg misforstått RAID 10?

Det er i hovudsak til Read-only og det skal være både på eit LAN (der mesteparten av kopieringen kommer til å skje) og tilgjengelig på nett (enkeltpersoner). Nettverkstilkoblingen rekner eg med at det er godt nok med 1 GB nettverksport. Skal ha ei linje på 60/60 som den skal stå på. Rekner ikkje med at trafikken ut kommer til å være veldig stor. Backup ,tenkte eg at det skal være ein NAS boks (4bay RAID 0) som skal stå på eit annet bygg ,men i samme nettverk. Trenger evt. eit bra backup program (som lager dublikat av filer visst dei blir endret og ikkje sletter filer )

 

OS er eg litt usikker tar gjerne imot tips, linux er god sjanse for.

 

Minne er jo såpass billig nå, at det blir for 16GB minne på PC (er det overkill?)

 

Sorry for dårlig språk og mange skrive-leifer...

Språket gjør ingenting - jeg er skotsk, så jeg er mest vant til julekalender språk...

Med vanlig RAID10 på 8 disker har man 4 sett med RAID1 mirror par, og de fire sett er da koblet sammen som en RAID0 stripe. Det går an å lage en RAID0 stripe av 4 disker, og så lage en mirror av den - det kalles RAID01, og er sjelden brukt (det er mye mindre effektivt dersom en disk dør).

Siden det er hovedsakelig read-only, ville jeg anbefale heller RAID6 - da får du samme total kapasitet med bare 6 disker, og det vil være enklere for deg å kabinett og hovedkort. Jeg ville også tenke på en egen disk til OS - gjerne en liten SSD. Det trengs ikke mye plass på den, men det er litt ryddigere dersom raid array'en er dedikert til data området.

Til backup er jeg glad du sier det skal være i et annet bygg - det er mange som ikke tenker på det. Men det gir bedre sikkerhet mot brann eller innbrudd. Men her ville jeg har lagt to identiske systemer - backup systemet blir fysisk likt hovedsystemet, med nesten samme oppsett. Hvis noe går fryktelig galt på hovedsystemet kan man bruke backupen direkte. Bruk rsync for å holde filområdene synkroniserte.

Når det gjelder OS, hadde mitt valg vært Linux, men jeg vet at mange også bruke FreeBSD til ftp serverer. Det er litt vanesak kanskje. Men Linux Debian kan kjøre dette uten problem. Du trenger en veldig minimalt installasjon - kun basesystmet, en ftp server (jeg har brukt proftp, men det fins flere), og rsync.

Bruk Linux mdadm software raid - ikke tenk på hardware raid kort. Slike kort har noen fordel i situasjoner med mye skriving, fordi raid6 er treg i skriving, men kun dersom man har en dyrt kort og batteri backup. Og da hadde det vært billigere med flere disker og raid10. Men software raid6 har flere andre fordeler, som fleksibilitet og uavhengighet fra bestemte hardware.

Bruk xfs som filsystem på raid'en - det er det beste systemet til store filsystemer med store filer.

Det er neppe nødvendig med så mye som 16 GB minne - du merker ikke forskjellen (med mindre enn at de vanligste filene får plass i cache i 16 GB, og folk ellers kan merke 20 ms kortere forsinkelse). Når det ikke er så mange som trenger å bruke serveren samtidig, trenger du ikke så mye - 4 GB holder lenge. Faktisk ville 1 GB sannsynligvis være mer enn nok (jeg har nylig pensjonert en filserver som hadde 64 MB minne), men som du sier minne er blitt veldig billig.

mvh.,

David

Heisann!

 

Skal kjøpe ein enkel pc til å bruke som FTP-server

 

Skal ha 8*3,5" harddisker i eit RAID 10 og ein OS harddisk

 

Anbefalt spec?

8 disk er litt mer enn vanlig på en PC - det betyr en spesielt stor kabinett, og enten en hovedkort med mange SATA port, eller en ekstra SATA kort. Har du virkelig behov til så mange disker, og har du virkelig behov til Raid 10? Hvis du kan si litt om bruksområde til serveren, kan vi gi deg bedre råd. Hvor mye data har du egentlig? Er det store filer, eller små filer? Er det mest read-only, eller blir det mye skriving? Er det mange brukerer samtidig? Er det 24t operasjon, eller bare om dagen? Skal det server en raskt lokalt nettverk, eller er det på internet? Er det kritisk med uptime? Har du backup i orden? Er du erfaren med konfigurasjon og drift av serverer?

Ellers må du tenke på nettverkstilkobling. CPU gjør ingenting - du klarer ikke å kjøpe en cpu som ikke er raskt nok til å holde 2-3 GBit ethernet fullt opptatt med en FTP server. Mer minne er alltid kjekt å ha, for å holde mye brukt filer i minne.

Du må nok opp i prisklasse for å få veldig mange. Evt. så kan du se på RAID kort i ulike prisklasser. Om du skal ha alle 8 diskene i RAID 10, så må du nok over på ett dedikert RAID kort, da veldig få HK har så mange SATA porter som kan kobineres i samme RAID

Hvorfor tenker du bare på hardware/firmware raid? Han skal lage en FTP server - da er det enten Linux eller BSD han kjører, og det naturlig er da software raid. Spesielt med raid10 på Linux kjører det raskere enn hardware raid løsninger.

Alle Linux distribusjoner fungere fint som router og brannmur, ihvertfall hvis man ikke er redde for å konfigurere iptables selv. Til DHCP og DNS servering, anbefale jeg sterkt å bruke dnsmasq - det er svært lett å konfigurere. Og til VPN er OpenVPN det letteste og mest fleksibel løsningen.

Men selv om Linux passer utmerket til brannmur og router, er det sjelden god sikkerhetspraksis å blande server funksjonalitet med brannmur/router funksjonalitet. Man ønsker heller å holde brannmuren så enkelt som mulig for å minimisere angripsmuligheter.

Hvorfor ikke bare bruke en vanlig hardware firewall/router? Kjør gjerne OpenVPN server på Linux boksen med port-forwarding gjennom routeren (det er en av grunnene til å velge OpenVPN - det er mye lettere til slike routing enn IPSec osv.). Hjemme kjører jeg også DHCP/DNS server på Linux serveren istedenfor hardware firewall/router'en. Men selve brannmuren er en egen boks.

Dersom du vil gjøre noe litt mer morsomt med brannmuren, kan man kjøpe en billig boks og omprogrammere den med f.eks. OpenWRT Linux eller monowall BSD.

I tillegg er tastaturet britisk engelsk, istedenfor norsk.

Prisforskjellen mellom Storbritannia og Norge er ikke veldig store på datautstyr, ihvertfall for utstyr som er nokså dyrt i utgangspunkt. Det pleier å være større forskjell på lavend.

Som du allerede har hørt - velg nvidia til skjermkort. Intel sine er ikke kraftig nok (greit nok til bærbar), og AMD har ikke god nok Linux støtte.

Det alle meste av hardware ellers fungere fint "out of the box" med kurante Linux distribusjoner. Det eneste som kan være problematisk er enkelte nettverkskort eller nettverk brikker på hovedkort krever non-free driverer. Alle ikke-fanatiske distribusjoner støtter dem, men du må kanskje velge å installere en pakke som heter "linux-firmware" el.l.

Dette er ikke noen store krav - ca. hvilken som helst moderne trådløs router ville fungere.

Jeg har i programmet Scilab klart slette noen paletter. Disse finner jeg ikke tilbake til. Derfor prøvde jeg slette hele programmet og installere på ny.

 

Dette funket ikke, da den FORTSATT husket at palettene mine var sletta.

 

Jeg uninstalla programmet gjennom avinstalleren, og jeg søkte gjennom hele regedit etter alt relatert til scilab og palett som kunne relateres til scilab.

 

Hva kan jeg gjøre? Må være noe som henger igjen som husker scilab palette infoen

Det ligger sikkert en innstillingsfil en eller annen plass. Er det på Linux, er det sannsynligvis i en fil eller mappe med navn som "~/.scilab". På Windows er det kanskje i "Application Data" mappen i "Documents and Settings".

Har problemer mer to Acer-maskiner som kjører Mint 12.

Oppdatering virker ikke, men kan oppdateres gjennom terminalen.

Sudo apt-get update fungerer ikke, men "upgrade" gjør.

Eller sudo apt-get update && sudo apt-get Upgrade

Er ikke sikker på hva den siste der egentlig skal gjøre ?

"apt-get update" henter de siste indeksfilene fra Mint serverer (og kanskje noe fra Ubuntu, Debian, og tredjeparti server også, avhengig av hvilke "respositories" man har konfigurerte). Disse indeksfilene sier hvilke som er de siste versjonene av pakkene, hvilke pakker avhenger av hvilke andre pakker, og beskrivelser av pakkene.

Når man bruke en gui verktøy (som Synaptic eller de forskjellige Mint installasjon og oppgraderingsverkøy), kjører disse en "apt-get update" i bakgrunn for å oppdatere indexfilene. Disse verktøyene bruker akkurat de samme indeksfilene og pakkedatabase som "apt".

"apt-get upgrade" sjekker gjennom indeksfilene på pc'en din og sammenligne det med alle de pakkene du allerede har installerte. Dersom det er en nyere versjon nevnt i indeksfilene, går "apt" ut og hente den nyere versjonen og installere den.

Dette tilsvare en "oppdatering" fra gui verktøy (jeg vet at terminologien her er en smule ukonsekvent - gui verktøy snakker om "oppdatering" av systemet og pakkene, mens apt-get snakker om "oppdatering" av indeksfilene).

Hvis du ikke først kjøre "apt-get update", vet ikke "apt" om mulig nye versjoner - så hvis du ikke har kjørt "apt-get update" (eller ikke /kan/ kjøre det) siden sist "apt-get upgrade", vil "apt-get upgrade" alltid sier at alle pakkene er i siste versjonen.

Så hvis du har problemer med "apt-get update", eller "refresh" fra gui verktøyene, ligger problemet i henting av indeksfilene. Da skal du lese nøye på feilmelding som kommer, og eventuelt poste dem her. Det kan også være hjelpsom å vise hva du har i "/etc/apt/sources.list" fil - der ligger alle repositories som apt bruker.

apt-get -s upgrade

"-s" betyr "simulate" - da kan man se hva apt-get kommer til å gjøre.

Det er ofte best å bruke "less" (apt-get -s upgrade | less) slik at du får lest alt.

En annen nyttig switch ved upgrade er "apt-get -d upgrade" eller "apt-get -d dist-upgrade" - da laster ned apt filene til cachen, men kjøre ikke selve installasjon. Når du senere skrive "apt-get upgrade" eller "apt-get dist-upgrade" bruker den filene fra cachen.

apt-get man page

David Brown:

 

Jeg klarer ikke se hvorfor du prøver å løse et håpløst problem med argumenter som ikke har noen betydning for problemstillingen.

 

Som nevnt så kan ikke Clarion sine APP's versjonkontrolleres. Eller for å si det på en anne måte, de er ikek spesiellt versjonkontroll vennlige. Appene inneholder en masse mekanikker som har avhengigheter andre steder i APP filen. App filen er å annse som en relasjonsdatabase. Det blir jo helt håpløst for en utvikler å måtte analysere innholdet i APP filen for å ta et standpunkt på hva som ska være med eller ikke. Jeg sier ikek at det er umulig, men svert upraktisk. Nå er solutionen vår fordelt på ca 20 forskjellige Clarion APP filer. Hver av dem har sine egne egenskaper og funksjonalitet.

 

Jeg skjønner ikke hvorfor du føler du trenger låsing til dette.

Vel. Dette har med det at en app som hentes ut av SubVersion normalt lagres på arb. stasjon uten ReadOnly flagget. Dette forteller Clarion at filen kan endres på. Når appen så åpnes i Clarion og lukkes igjen så har allerede Clarion touchet filen og annses som endret i SubVersion. Når utvikler da sjekker inn igjen så vil SubVersion automatisk mase om versjons konflikt, noe som er helt unødvendig. Ved å locke filen vil den få ReadOnly attribut på utviklers maskin og dermed vil ikke Clarion gjøre noe endringer på APP filen. Du må huske på at i Clarion sammenheng blir SubVersion kunn brukt som et "utlånssystem" for appene. Noe annet kan ikek dette brukes til side man ikke kan kildekode kontrollere noe som helst i Clarion uansett versjonskontroll system.

 

Man kan selvsagt si - Hvorfor bruker man SubVersion i det hele tatt da? Dette har jo med at vi også bruker Visual Studio til andre parter av vår program portefølje og av organisatoriske hensyn så er det fint å ha alt som har med utvikling å gjøre på ett og samme sted. Jeg kunne helt sikkert enkelt laget et BAT fil system som automatisk satte ReadOnly flagget og slikt, men hvorfor? SubVersion gjør jo dette veldig elegant.

 

Så derfor er det uaktuellt å gå over til GIT for det betyr at Visual Studio prosjektene må lagres i GIT og Clarion prosjektene må lagres i noe annet. Den veien gidder jeg ikek engang å ta. Jeg vil ha alt under samme paraply og derfor kan det se ut til at TFS er veien å gå, hvis vi i det hele tatt gidder å bruke mere tid på det. SubVersion gjør jo en god jobb tross alt. Inledningsvis var jo mitt spørsmål om det finnes andre og bedre alternativer og det har jeg fått svar på. Git var ett av dem, men siden Clarion er litt sært så er dette uaktuellt. TFS vil være veien å gå hvis vi tar en beslutning på å bytte...

Når jeg leser hvordan Clarion fungere, med "touch" på filer som er uendret bare fordi man har åpnet dem for å lese dem, har jeg mye mer forståelse for hvorfor du ønsker låsing. Da er den "read-only" checkout du får fra låsing veldig hjelpsom.

Men det er likevel ikke nok i seg selv. Hvis du ta en checkout eller update på en prosjekt og låse det, kommer Clarion til å endre filene dine selv om de egentlige er det samme. Dermed ved neste commit blir disse filene sendt til serveren som en ny versjon, som er høyst uønsket.

Jeg vet ikke hva som er det beste løsningen her (annet enn å klage på de som lagte Clarion). Kanskje du må bli vant til å ta en "svn revert" på Clarion mappene før en commit, når du vet at du ikke har endret noe? Det ville selvfølgelig fungere med andre VCS også.

Der tar du nok feil ;-)

Hvordan kan det være mulig? Tenk deg hva som skjer - To personer gjør endringer i prosjektet og dette lagres binært. Når subversion (eller et hvilket som helst annet system) så presenterer for brukeren en konflikt - hvordan skal da den brukeren kunne avgjøre hvilke kryptiske tegn som vises som en konflikt, skal gjelde?

Det er svært enkelt - de ser fort hvilke filer er i konflikt. Når det er binære filer, kan ikke svn (eller tortoise, dersom du bruker den som front end) hjelper deg med å sammenligne filene. Noen programvare har støtte til slike sammenligningene (f.eks. OpenOffice/LibreOffice kan hjelpe dersom det er tekstbehandler filer). Men som regel må man åpne både den nye versjonen av filen, og din egen endret versjonen (og eventuelt også den tidligere felles baseversjonen), og manuelt kopi og lim endringer over.

Husk at dette skal være en unntakssituasjon - har dere en konflikt, har dere dummet dere ut ved å jobbe uavhengige på samme fil.

Låsing er bare en måte å se at man kommer til å gjøre noe dumt før man kommer så langt. Men det er fult mulig å gjøre det dumme likevel (man kan jobbe med filen uten å kjøre update - da vet man ikke at det er låst).

En annen ting - Om filen er kryptert eller ikke spiller ingen rolle. Dataene som presenteres er like kryptiske uansett da det ikek er noen forskjell for det menneskelige øyet mellom krypterte data og ikke

 

Husk at side dette lagres binært så er det ikke noe lesbart i disse prosjektfilene..

Som sagt gjør dette ingenting for svn (eller annen VCS) - alt den vet er at filen har endret seg.

Og jeg regner med at brukeren kan lese filen, med de rette programvarene. Ellers er det galskap å bruke dette utviklingsverktøyet.

Filen inneholder kunn instillinger i forhold til en template og dette lagres som verdiene. Noe kildekode finnes det der, men det er svert lite. Resten oppfattes av øynene som skrot.

Enten er filen en del av prosjektet ellers så er det ikke. (Med "prosjekt" mener jeg en program skrevet med dette verktøyet.) Hvis det er en del av et prosjekt, skal det stå sammen med de andre prosjektfilene i prosjektmappen. Den som jobber med det prosjektet tar en checkout eller update, jobber med filene, og så commit'er. Hvis du ønsker at mange skal jobbe samtidig på samme prosjekt, så må du velge utviklingsverktøy som støtter denne modellen - det høres ut som det blir vanskelig med Clarion.

Tror jeg skal undersøke på jobben om det er mulig å flytte til Git istedet for SVN.

 

Du kan bruke git som front-end til svn som gir deg mange av fordelene til git.

 

git svn clone svn://svn-uri

 

deretter jobbe i git, lage brancher, klone disse videre for testing andre steder, la andre clone ditt git repo for testing, git bisect, slå sammen mange små git commits med git rebase -i og til slutt

 

git svn rebase
git svn dcommit

 

for å sjekke tilbake inn i svn. Den første svn clone tar en del tid (hvis repo er stort), men etter det er det mye mer effektivt å buke git som front-end. Jeg jobber fortsatt i mot svn repo'er, men har ikke brukt svn på flere år. Bruker magit i emacs slik at man aldri ser git kommandoene heller...

Dette var veldig interessant å lese om. Jeg har ikke satt meg inn i git ennå, men er stor bruker av subversion. Men på enkelte prosjekter hadde det vært nyttig med lokale billige brancher eller små committer - bruk av git lokalt kombinært med svn på serveren er kanskje det beste løsningen der. (Jeg mener å ha lest at mercurial kan også fungere sammen med svn på den måten, men skal jeg først lære og bli vant til en DVCS, er det kanskje mer nyttig å lære git.)

Om locking er en fordel eller ikke spiller ingen rolle fordi Clarion prosjektene lagres som BIN filer. Siden vi er tre som jobber med dise prosjektene så kan dette gjøres på en av to måter. Vi kan ha en felles mappe med prosjektene og så ha en manuell ordninger der man markerer prosjektet som AKTIVT og stole på at alle som skal gjobbe med Clarion går veien om denne listen. Alternativt kan vi bruke SubVersion eller lignende og velge File Lock. Ser ikke hvorfor dette er noe ulempe i dette tilfellet - snarere tvert imot, siden Clarion prosjekter ikke lar seg kildekode kontrollere. Om det er en historisk artefakt eller ikke er jo meningsløst. Faktum er jo at Slik er det og man løser ikke problemet ved å velge "utelat" i en eller annen variant. Da kan man jo like gjerne droppe hele SubVersion og gå tilbake til den manuelle måten, som i hvertfall er å annse som en historisk artefakt

Jeg skjønner ikke hvorfor du føler du trenger låsing til dette.

Tenk deg hva som skjer hvis man ikke låser når du har begynt å jobbe med et prosjekt. Samtidig begynner en annen å jobbe med samme filene. (Skjer dette ofte, har du en svikt i prosjektstyring, som ikke har noe med tekniske løsningene å gjøre.) Første man commit'er koden sin - alt går greit. Neste man prøver å commit'er - han får en "konflikt" og commit går ikke igjennom. Respository er uendret, ingenting er merged (svn prøver ikke å merge binære filer), og utvikleren må rydde opp og manuelt merge. Ingenting blir mistet eller korruptert.

Og dersom du låser filene før du begynne å jobbe, mens en annen jobber med filene som han allerede har. Da få han omtrent samme effekt - bare at han får en annen feilmelding da han prøver commit.

Låsing hjelper ikke mot dårlig struktur i prosjekt eller mappene, og det hjelper ikke mot dårlig planlegging og organisering av arbeid og oppgaver. Det også åpner for nye problemer, med folk som tar en lås og glemme å frigjøre den (svn har dermed mulighet til å bryte en lås). Låsing passer til enkelte filer eller mapper som mange må endre ofte med raske update/change/commit sykluser - det hjelper da for å unngå conflicts. Men det er aldri nødvendig, og gir ingen realt ekstra sikkerhet (fordi låsene kan brytes) - det er mer kosmetisk, som en ekstra måte å kommunisere mellom utviklerne. Bruker du låsing i vanlig prosjektarbeid, jobber du feil.

Og det har ingenting med binære filer å gjøre. Jeg mener det er kritiske at en versjonskontroll program skal kunne håndtere binære filer (vi har mange type ikke-tekst filer i svn repository, som f.eks. odt filer), men man trenger ikke låser for det.

Alle versjoner av Windows etter Windows XP (i XP kunne man skru det på) støtter Physical Address Extention, men av grunner som ser ut til å være prinsipielle, er det ingen Windows versjoner (uten om 32-bit versjoner av Windows Server) som benytter noe mer enn 4 GB RAM. Windows Server 2008 er kun tilgjengelig i 64-bit. Jeg synes nesten det er mystisk at Microsoft gir ut Windows 8 også for 32-bit x86.

Jeg viste ikke at ikke-server versjoner av Win32 støttet PAE i det hele tatt. Jeg har en XP PC med 4 GB, men kan kun bruke ca. 3.3 GB av det - jeg lurer på om jeg kunne bruke hele 4 GB ved å skrue på PAE? Det er neppe verdt risikoen av å prøve - så stor forskjell blir det ikke.

SSE er ikke en del av 64-bit instruksjonssettet, og er tilgjengelig også i 32-bit programmer.

Nei, SSE er ikke i seg selv en del av amd64 ISA. Men de forskjellige x86 prosessor har forskjellige generasjoner av SSE (eller andre SIMD utvidelser), og jeg mener det er noen som kun er tilgjengelig i 64-bit modus.

De fleste Windows programmer er også tilgjengelig i 64-bit, ihvertfall de som fortsatt aktivt utvikles. Spill er derimot en helt annen greie, hvor det er et svært lite fåtall som kjører 64-bit (Crysis er eneste unntaket jeg kan tenke på)

Jeg tror du tar litt feil her. Det er noen Windows programvarer som er tilgjengelig i 64-bit versjoner. En del utviklingsverktøy kommer i 64-bit versjoner, og MS Office, og en del programmer som ellers er krevende å kjøre og dermed har mye å vinne fra 64-bit modus. Ellers er en del open source programvare tilgjengelig i 64-bit versjoner dersom de er i utgangspunkt cross-platform - fra Linux verden er de allerede vant med 32-bit og 64-bit versjoner. Men massen i Windows programvare markedet er laget av nokså små firmaer - det å gi ut 64-bit versjoner er ofte resurskrevende, og ikke verdt bryet. De alle fleste slike programmer ble laget med kun 32-bit i tankene - og det tar tid å gå igjennom kildekoden for å sikre seg at det skal fungere fint med 64-bit kompilering. Jeg tror det blir lang tid før en "gjennomsnittlig" Windows program fins i 64-bit versjoner. Men det er bare min mening, uten at jeg har undersøkt det så nøye.

Min mening er at om man ikke har en spesiell grunn til å kjøre 32-bit (de aller fleste har det ikke) så er det smarteste å velge 64-bit.

Det er jeg enige i (ihvertfall ved valget av OS).

Hei skal kjøpe meg pc, jeg har windows 7 32 bit liggende. jeg vet ikke hva ulempene er bortsett fra at jeg max bruker 4gb ram. er det andre ulemper?

Det er en missforståelse av hva "minne" egentlig er. Det vi kaller "minne" er ikke egentlig "minne". Det er for adressering av maskinvare i PC-en. Vi sier vi har et 4 GB langt minneområde, men det er ikke riktig. Vi har et 4 GB langt adresseområde. Minne er bare en del av dette adresseområde. Derimot er dette et problem når vi har minne som krever større adressering enn adresseområdet tillater, og for ikke å nevne at store deler av adresseområdet allerede er opptatt av hardware eller operativsystemet til helt andre ting enn minne.

 

Så i praksis får du mindre enn 4 GB RAM tilgjengelig. Kommer helt ann på oppsettet ditt. Det er ingen tvil om at 32-bit er for lite adresseområde nå.

 

Åja, 64-bit programmer vil være noe raskere enn 32-bit også, og UEFI er ikke støttet av 32-bit Windows versjoner.

Det som gjør største innslag i 4GB adresseområde er grafikkkortet. Har man en grafikkkort med 1 GB minne, samt adresseplass til alt annet hardware på PC'en, kan du faktisk bare bruke litt under 3 GB av minne - det siste GB av ram blir "gjemt" bak grafikkortet.

Har man en OS som støtter PAE (Processor Address Extensions) kan man derimot bruke alt minne selv med 32-bit OS. Men jeg tror det er bare serverversjoner av Windows som støtter dette (de fleste 32-bit Linux distribusjoner har ingen problem med tilgang til alt minne).

Når det gjelder hastighet av 32-bit vs. 64-bit programvare, er resultantene svært varierende. I 64-bit modus er det som regel de ekstra registers som gir bedre ytelse - det er veldig få programmer som kan med fordel benytte 64-bit regning. Og det krever at man bruke en god kompilator, og vet hvordan man bruke det, for å få fordelene (det er utrolig hvor mange programmere det fins som ikke forstår verktøyene sine). Men ulempen med 64-bit modus er at alle pekere bruker 64-bit - det betyr mer minne tatt i bruk, og dermed færre cache hits.

Så for noen type programmer, som kan bruke 64-bit regning eller nyere SSE (f.eks. bildebehandling, kryptering, osv.), eller som kan bruke mye minne (som videoredigering), kjører 64-bit versjoner betydelig raskere. Men for de fleste programmer, er forskjellene små eller ingenting.

Ikke at det gjør så mye på Windows - de alle fleste Windows programmene er 32-bit.

Det er hovedsakelig tre grunn til å ha en kort med to (eller flere) sokkel - for å få flere kjerner enn man få med en sokkel, for å få mer minne sokkel, eller for å få mer IO båndbredde. Når man husker på at det fins enkelsokkel cpu'er med 12 kjerner lett tilgjengelig, skal man ha veldig god grunn til å ha to sokkel til prosesseringskraft. Du må enten jobber med mye number crunching, eller med tunge server oppgaver.

Ulempene med fleresokkel kort er pris (de koster betydelig mer), størrelse (de er ofte stor og tunge, og man må ha plass i kabinetten til flere vifter), strømforbruk, og at de typiske er tregere en enkelsokkel kort p.g.a. tregere minnebuss (flere kanaler betyr lavere klokke) og ofte lavere cpu frekvens, spesielt lavere på "turbo boost" el.l.

 

Grunnen til at jeg ikke har gjort det slik tidligere(lagt /boot på SSD), har vært for å slippe å måtte velge boot device i hytt og pine. Har vel stort sett lagt det bort som en uakseptabel halvveisløsning, men som et alternativ til at ting ikke fungere så er det vel kanskje aktuelt alikevel.

 

Hvis det var at man måte gå inn i bios oppsett hver gang man skulle velge mellom Linux og Windows, hadde jeg vært enige med deg. Men de fleste moderne bioser har en boot device meny som man kan få ved oppstart (som sagt er det ofte ved å trykke på F12), som er like enkelt og raskt som å velge fra en grub meny. Det er kanskje ikke den mest elegante løsningen, men det er enkelt å bruke og lett å få til (gitt at bios'en din har en sånn meny).

 

Når det kommer til det at jeg har 5 disker i RAID0 så er det som sagt mest bare tull, og jeg er klar over farene. Realiteten er at jeg stort sett ikke har viktige data, og alt av skolearbeid har jeg uansett på dropbox. Med en 100/100-linje tar det heller ikke så lang tid å anskaffe de uviktige dataene som evt skulle gå tapt ved en krasj.

 

Du sa ikke at RAID0 var til tull - du sa "mest 4 teh lulz" som er totalt meningsløst.

Men gitt at RAID'en er hovedsakelig til lek (eller ihvertfall uviktige ting), gjør det ingenting hvordan det er delt opp, eller om du bruker alle disker i RAID0 eller bare noen av dem.

 

Når det gjelder det å sette opp RAID i linux så er jeg stort sett ikke fan av tanken grunnet at jeg har et mye større behov for lagringskapasitet i windows enn i linux, og da har jeg fort en situasjon som er litt baklengs i forhold til det som er behovet mitt.

 

Mvh Håkon

Hva skal du bruke Linux og Windows til? Det eneste bruk jeg ser til store lagringsplass som er Windows-spesifisk er spill - og man klarer ikke å fylle en moderne disk med bare spill.

Uansett, er det mange måte å ta i bruk disse diskene. Du kunne ha en HD til Linux og 4 disker i fakeraid til Windows (men da må man bruke BIOS boot meny, eventuelt legge inn Linux som opsjon i Windows boot menyen). Ellers kunne du ha en HD til Linux og Windows system disk, med vanlig dual-boot oppsett (dermed booting til grub meny). De andre 4 disker tar du i fakeraid med en NTFS filsystem, som du kan bruke fra både Windows og Linux etter ønske.

Du har en SSD som du ikke bruker i dag. Hva med å bruke den til Linux? 40 GB er rikelig med plass til OS og programvare, og du kan alltid mount partisjoner som ligger på HD raid for å holde større datamengder.

Da kan du ha Grub + Linux på SSD'en, og Windows på raid'en. Bruk "boot menu" i bios'en (typisk F12) for å velge hvilke disk du skal boote fra.

Det må nevnes at raid0 med 5 HD'er er nokså dumdristig. Pass på backups!

Er det faktisk et krav at Windows får tilgang til raid'en? Linux software raid er en langt bedre og mer fleksibel løsning enn hovedkort raid, og er ofte både raskere og mer pålitelig. Du kunne f.eks. bruke en disk til Windows, og fire HD'er til en skikkelig Linux raid. Dersom du må ha tilgang til raiden mens du har bootet Windows, kan du alltids lage en Linux VirtualBox maskin som får direkte tilgang til diskene.