Benny Simonsen

Lasse Mølgaard

Jeg har set lidt på https://docker-mailserver.github.io/docker-mailserver/edge/.

Off-topic

Er i øvrigt også blevet varslet om min “gratis” Google tjeneste ophører i år, efter 16 år.

Waterboarding var vel en aprilsnar, men slap du for at blive varetægtsfængslet, mod at sikre at ingen på Kviknet kan uploade kritiske billeder af Mette? Jeg har ikke haft held til at uploade et billede med et Sankt Hans bål, så tænker på om filtret er lidt for godt?

Jeg mener at det var FreeBSD, men husker jeg ret?</p>
<p>Ja, som sagt ovenfor var det et ufravigeligt krav til vores VCS.</p>
<p>

Jeg mener at det var FreeBSD, men husker jeg ret?</p>
<p>Ja, som sagt ovenfor var det et ufravigeligt krav til vores VCS.

Jeg er vist forvirret ... jeg vil da mene at argumenterne mod Git har gået på manglende versionsnumre/juristeri, men hvis det er lettere at ændre i historikken i SVN end i Git må det da være et kvalitetsstempel på Git, selvfølgelig trelst hvis man har brug for at fjerne noget fra historikken.

Altså er der ingen diskusion om hvad git commit "ab12..." indeholder, uanset rettigheder (dog med forbehold for SHA1's svaghed), for SVN ville version 1.2.3 godt kunne være ændret (med nødvendige rettigheder).

PS: Det kan sagtens lade sig gøre at fjerne noget fra Gits historik, men det bliver med nye SHA1 sums (vil ske i en ny branch der deler sig før det der skal fjernes kom med).

Jeg mener at der for nogle år siden var et Open source projekt, som vragede Git fordi det ikke var muligt at fjerne noget fra versionshistorikken - f. eks. hvis der blev brugt noget som ikke måtte være med pga. licens, og skulle slettes - inkl. slettes i fortiden.

Jeg mener at det var FreeBSD, men husker jeg ret?

Under alle omstændigheder skal man da gøre sig umage for at lave om på historikken og ende op med samme checksum (SHA1's svaghed hjælper selvfølgelig). Alt andet lige vil jeg mene at det er noget lettere at erstatte indholdet af en fil v. 1.2.3.4 med noget andet hvis der ikke er checksum.

Og det forhindrer ikke på nogen måde at man bruge Git til det det er designet til og som det er rigtig godt til, nemlig gruppearbejde.

Er det Git's standardinstillinger der er problemet, således at f. eks. Gitolite eller Github med passende hooks er et versionsstyringsværktøj? - versionsnummeret må kunne sættes på som en del af push i f. eks. Gitolite.

Magit til Emacs er min favorit - og også værd at overveje selvom man ikke bruger Emacs - der bruges primært enkelttaster (a-z uden Ctrl, Alt), og der er hjælp med hvilke valgmuligheder man har.

Magit giver et godt overblik:

• Let at checke sine ændringer inden de stages (klar til checkind) ændring for ændring - Dette kan gøres for
  • alle filer
  • pr. fil
  • pr. ændret region
  • pr. linie Dvs. der arbejdes ikke kun på filniveau, men man kan stage del af en fil, og lade resten af ændringerne være. På samme måde kan ændringerne i del af en fil fortrydes.

Desuden er der log (med forskellige muligheder), skift af branch, push, pull, stash, ...

Se mere f. eks. her:https://magit.vc/screencasts/

CLI er også meget nyttig, og som tidligere nævnt, kan det være godt for forståelsen. Der er go' understøttelse i shells af git - f. eks. tab-completion af filer der kan addes og visning af status (med grafiske symboler). Dette er der support for i bla. Zsh (bla. Oh-my-zsh), bash og på Windows er Git bash god, og supporterer også visning af status, men man skal vist selv sætte det op.

Til CLI bør man få sat sig nogle aliases op, f. eks. en log med en een linie pr. commit (søg på git lg). Jeg har også lga (lg for all branches) + lghs og lgahs som viser status og første del af loggen:

[alias]
	# Log on one line
	lg  = log --color --graph --pretty=format:'%Cred%h%Creset 
-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' 
--abbrev-commit
	# As lg, bur for all branches
	lga = !git lg --all
	# Show status short (paths relative to current dir), 
and show head of log 
	lghs = !cd ./$GIT_PREFIX && git status -s && git lg|head
	# Show status short (paths relative to current dir), 
and show head of log 
for all branches - this might not show head for current branch
	lgahs = !cd ./$GIT_PREFIX && git status -s && git lga|head

Jeg forstår ikke at teknikkerbesøg er nødvendigt ved pair-bonding. Da mine forældre fik ADSL på 2. par fordi de havde ISDN på 1. par var teknikkerbesøg ikke nødvendigt i huset; men i samtlige skabe imellem central og bopæl.

Hvem betaler for at etablere forbindelser i skabene imellem central og bopæl?

Skal teknikkerbesøg ved pair bonding være påkrævet, hvis begge linier har været i drift hos anden udbyder for nylig burde det ikke være nødvendig - men det kan jo nok godt give sure kunder hvis det ikke virker, og der ikke er informeret godt nok.

Cacher i ikke opslag i TDCs DB (opdaterer jeres kopi af CSV filen) ... det kunne det se ud som om (tandhjulet er der ikke anden gang jeg tester en adresse), men I bør nok altid slå op (hvis cache er mere end nogle minutter gl.) i TDCs DB igen ... der kunne jo blive rettet fejl i DB.

Men CSV filen kan selvfølgelig være gammel hvis i får den som snail-mail som C-post.

Du kan da sende et postkort til dem (det bliver jo alligevel offentlig), adressen kan du finde på deres /fine/ hjemmeside. Du kan også spare lidt og sende det via email.

Forøvrigt må man må da sige at de har hørt at der ønske om åbne data.

Stofanet forsøger også at være med i kapløbet, ikke så meget deres website, men deres mail, der er de ikke kommet til at bruge kryptering i forbindelse med login.

Mht. autoation: Ufraw gemmer en lille og overskuelig xml fil (.ufraw) med parametre der er brugt under fremkaldelse af billedet. Der er også ~/.ufraw med default parametre - så lidt automation support er der, ellers må man selv skrive .ufraw filerne og bruge ufraw-batch.

Jeg har set lidt på det den anden dag - det var dog for at kopiere fra en gmail-konto til en anden.

• https://github.com/nicolas33/offlineimap
• http://www.gmail-backup.com/ (Virkede lørdag)
• http://www.beyondinbox.com/ - Findes i 2 udgaver - en med GUI og en med command line interface, sidstnævnte kan kun tage backup, ej restore til Gmail.
• http://www.benshoemate.com/2007/11/09/how-to-upload-all-your-old-archived-email-to-gmail-from-outlook-lotus-notes-and-unix-pine - Til migrering af mails til Gmail
• imapsync (Jeg har eksempel på script til kopiering imellem to konti påhttp://slbs.dk/org/tricks-mail.html#Gmail.cp_mv_mails.imapsync