Re: Ghostscript produces much larger pdf files now
On Sat, Sep 29, 2018 at 8:01 AM Flo wrote: > > I recompiled the versions 9.24, 9.23 and 9.22: > It changed from 9.22 to 9.23 . Does anyone has an idea what changed here > such that the size of the pdf files are bigger? > > Flo. I do not know much about ghostscript pdf conversion. But the information you have given so far is not enough to reproduce the issue. I see that you have already given the command you are using. Please provide a sample input file, and sample output files. What is the increase in size of the pdf files produced with different versions you tried? -- Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog
Re: Where is xfce.org?
On 2018-09-29 at 21:06, Dennis Wicks wrote: > What has happened to xfce.org? > It seems to have disappeared and left no tracks. There's apparently an announcement on Reddit about it: https://www.reddit.com/r/xfce/comments/9jvh2b/xfceorg_is_down_due_to_hosting_issues/ I'd done a fair bit of independent investigation, before going looking for further discussion elsewhere, and finding this. Based on that investigation, it seems likely that it could be DNS registration expired, hosting provider (apparently the University of Namur, formerly Facultes Universitaires Notre-Dame de la Paix) no longer providing, or some combination of both. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
On Thu, 27 Sep 2018 17:54:26 +1000 Andrew McGlashan wrote: ... > The biggest weakness with the Dropbear setup is that the initramfs is > stored on an unencrypted partition (no matter which file system is > used). That means that someone with physical access can rebuild the > initramfs and include their own key as well as other stuff to > compromise the security of the server. > > Aside from the fact that the IME is suspect, it would be great if grub > can be, somehow, given a method that allows for full disk encryption > which will include everything in /boot -- especially initramfs. But grub itself and its configuration can't be encrypted, so an attacker could still compromise that code / data. IIUC, your solution basically just implies moving some of the logic currently in the initramfs into grub. One solution is to run grub from removable media, and preventing attackers from getting physical access to it ... Disclaimer: I'm no expert, and am just expressing my understanding of the underlying unsolvable problem based on what I've read about it. Celejar
Where is xfce.org?
What has happened to xfce.org? It seems to have disappeared and left no tracks.
Re: Syncing GnuPG between 2 system
Jim Popovitch wrote: > On Sat, 2018-09-29 at 09:50 -0400, Roberto C. Sánchez wrote: >> If all you care about is the public keys for verifying signatures, >> then I say don't bother trying to proactively sync. Just let each >> system get keys and key updates from the public keyservers as needed. > > OK, that makes sense, and seems to be the popular opinion. > >> Your original message seemed to inidicate that you wanted to both >> verify signatures and also produce signatures on multiple >> machines. That was why I provided the link to the article on subkeys, >> as I consider that to be the only sensible way to have signing >> capabilities on multitple devices related to a single GnuPG >> key. Perhaps I misread your email in that regard. > > > You read my email correctly. I did quickly read and have bookmarked > your link. Thank you for that. > IMO you sign based on the e-mail you use. IMO it is confusing with multiple machines. A key is associated with identity -> the email. With the sub keys you can add more identities. Still to encrypt you need the private key. It is sufficient to update the private key on the other machines. You usually do not copy it over internet connection. Some people use secure key cards, other encrypted usb sticks or md/sd whatever cards. the public keys are uploaded to the key server after updated (for example signed by you) and downloaded/updated on the other machines when needed. It is up to you to decide how you handle your security. It is a sensitive topic, so general reading and understanding of the matter is required, before proceeding in real life. regards
Re: How to react on a factually wrong Debian wiki change ?
On 9/29/18, Dominic Knight wrote: > On Sat, 2018-09-29 at 08:59 +, Curt wrote: >> On 2018-09-28, Thomas Schmitt wrote: >> > This is not "unreliable" it is "clueless". >> > Insofar Curt's proposal is technically more correct. >> > But actually i see no improvement over my shorter statement. >> > (Maybe it's better english, but it's not better message.) >> >> I thought nobody said "should better not be used," but sticking that >> quoted >> phrase in a search engine produces over 12,000 hits. >> > So 12,000 people can be wrong :) > > Just altering the word order gives more clarity to the statement. > > "should be better not used" While still not entirely correct implies > less of a threat. > > "(it) better not be used (or)" - "the computer gods will frot you" > > "would be better not used" may be correct depending on the rest of the > context. > > Maybe an implicit threat of resulting danger needs to be implied? Wodim should not be used for burning to DVD or BD media. Which also implies no support for DVD/BD burning. And link "should not be used" to https://lists.debian.org/debian-user/2018/09/msg01048.html to explain why it should not be used? Regards, Lee
Re: Re : ponctuation espagnole avec vim
salut,
> > je n'ai pas trouvé comment faire pour le point d'interrogation
> > et le point d'exclamation sous vim
> Comme partout ailleurs ?
> Compose+!+! pour obtenir ¡ et Compose+?+? pour obtenir ¿ ?
je découvre :) merci ...
Bernard: tu trouveras plus d'infos dans la section "saisie de caractères
spéciaux" de Gnome.
Cf aussi http://doc.ubuntu-fr.org/caracteres_etendus.
Pour répondre à ta question et avoir accès à encore bien plus de
symboles: dans vim il y a les digraphs:
* puis 2 caractères pour un spécial
* en général c'est assez mnémotechnique (par exemple * pour grec donc
*a donne α et *P donne ∏)
* tu peux avoir la liste en tappant simplement la commande :digraphs
* préfère le résultat dans un fichier donc j'ai fais
la chose suivante
: redir > ~/vim-digraphs.txt
: digraphs
: redir END
maintenant je e ~/vim-digraphs.txt pour avoir une référence dans
laquelle je peux chercher.
* tu peux créer tes propres digraphs. dans mon vimrc, du coup
if has("digraphs")
digraphs .3 8230
digraphs :) 9786
digraphs :( 9785
digraphs <3 9829
endif
du coup <3 pour ♥
a+
marc
Re : ponctuation espagnole avec vim
Le 29/09/2018 18:12:45, Bernard Schoenacker a écrit : > bonjour, > je n'ai pas trouvé comment faire pour le point d'interrogation > et le point d'exclamation sous vim Comme partout ailleurs ? Compose+!+! pour obtenir ¡ et Compose+?+? pour obtenir ¿ ? nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: libreoffice base - null columns with trigger/default values
kjo...@poczta.onet.pl (Kamil Jońca) writes: > Package: libreoffice-base > Version: 1:6.1.2-1 > > Package: libreoffice-sdbc-postgresql > Version: 1:6.1.2-1 > > I have simple form based on postgresql table. > In this table there is a column > > nametype nullable default > value > utw timestamp without time zone not null now() > > This column does not have its field in form. > Recently (after upgrade?) I cannot save filled form to database, because > "required utw field has no value" > > When I drop "not null" from column, and restart libreoffice - form could > be saved to database. I tried with version: 1:6.1.1~rc1-2 of libreoffice packages and its works as expected. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ That's what she said.
ponctuation espagnole avec vim
bonjour, je n'ai pas trouvé comment faire pour le point d'interrogation et le point d'exclamation sous vim merci slt bernard
libreoffice base - null columns with trigger/default values
Package: libreoffice-base Version: 1:6.1.2-1 Package: libreoffice-sdbc-postgresql Version: 1:6.1.2-1 I have simple form based on postgresql table. In this table there is a column nametype nullable default value utw timestamp without time zone not null now() This column does not have its field in form. Recently (after upgrade?) I cannot save filled form to database, because "required utw field has no value" When I drop "not null" from column, and restart libreoffice - form could be saved to database. Should I fill a bug? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Martin was probably ripping them off. That's some family, isn't it? Incest, prostitution, fanaticism, software. -- Charles Willeford, "Miami Blues"
Re: Syncing GnuPG between 2 system
On Sat, 2018-09-29 at 09:50 -0400, Roberto C. Sánchez wrote: > If all you care about is the public keys for verifying signatures, > then I say don't bother trying to proactively sync. Just let each > system get keys and key updates from the public keyservers as needed. OK, that makes sense, and seems to be the popular opinion. > Your original message seemed to inidicate that you wanted to both > verify signatures and also produce signatures on multiple > machines. That was why I provided the link to the article on subkeys, > as I consider that to be the only sensible way to have signing > capabilities on multitple devices related to a single GnuPG > key. Perhaps I misread your email in that regard. You read my email correctly. I did quickly read and have bookmarked your link. Thank you for that. -Jim P. signature.asc Description: This is a digitally signed message part
Re: Syncing GnuPG between 2 system
On Sat, Sep 29, 2018 at 09:37:43AM -0400, Jim Popovitch wrote: > > I get the secret key part. Are you saying to forget about syncing > public keys (from other's emails) and just let each client download > those from a public keyserver? If so, I may be over thinking the need to > sync GnuPG between devices. H. > If all you care about is the public keys for verifying signatures, then I say don't bother trying to proactively sync. Just let each system get keys and key updates from the public keyservers as needed. Your original message seemed to inidicate that you wanted to both verify signatures and also produce signatures on multiple machines. That was why I provided the link to the article on subkeys, as I consider that to be the only sensible way to have signing capabilities on multitple devices related to a single GnuPG key. Perhaps I misread your email in that regard. Regards, -Roberto -- Roberto C. Sánchez
Re: Syncing GnuPG between 2 system
On Sat, 2018-09-29 at 09:16 +0200, deloptes wrote: > Jim Popovitch wrote: > > > Copying .gnupg is simple and easy, but not quite what I'm looking > > for. Imagine having to copy your email folders or address book from > > system to system, instead of using something like IMAP. I suppose I > > could build something that uses WebDav to sync .gnupg... I was just > > hoping somethinglike that existed. > > you definitely do not want to upload your secret key anywhere. Well of course not, and that is not what this question is about. ;-) You certainly don't want to sync your email account password either, nor your mothers maiden name. ;-) > Keep your private key secret and use a keyserver for the public keys. > When you have this setup IMAP is not an issue. I get the secret key part. Are you saying to forget about syncing public keys (from other's emails) and just let each client download those from a public keyserver? If so, I may be over thinking the need to sync GnuPG between devices. H. > and BTW no one said that you should copyyour mail folder. I'm the one who brought that up, as an example, because someone (you?) was saying to copy files around from box to box. I mentioned IMAP as an alternative to copying email files/folders, and that I was looking for a similar technique for GnuPG. -Jim P. signature.asc Description: This is a digitally signed message part
Re: How to react on a factually wrong Debian wiki change ?
On 2018-09-29, Dominic Knight wrote: > > Maybe an implicit threat of resulting danger needs to be implied? Implicit threats? Yeah, man. Like: "Got money and DVD/BD media to burn? Then burn 'em up with wodim*, the geeky masochist's premier choice for an unspecifiable subset of his burning needs." *Read instructions before use. Harmful if swallowed. > Cheers > Dom. -- "Now she understood that Anna could not have been in lilac, and that her charm was just that she always stood out against her attire, that her dress could never be noticeable on her." Leo Tolstoy, Anna Karenina
Re: Shell Bash Linux - Dropbox en ligne de commande
Petite mise à jour avec mon petit niveau pour un script de connexion a Dropbox. J’enchaîne dans le second script, avec une question concernant le chiffrement des données. #!/bin/bash # Ajouter le script Demarrer-Arreter-Dropbox.sh dans /usr/local/bin # Limiter les droits du fichier avec chmod 644 et chown l'utilisateur courant # Lancer le script : sh /usr/local/bin/Demarrer-Arreter-Dropbox.sh # Pour la première connexion : Établir la connexion avec Dropbox. # Ouvrir le lien qui est proposé en console. # Valider le bouton depuis le site de dropbox. # La connexion est établie. # Facultatif : # Rendre le script exécutable chmod +x Demarrer-Arreter-Dropbox.sh # Permet de le lancer avec ./usr/local/bin/Demarrer-Arreter-Dropbox.sh # Aller dans le répertoire utilisateur pour démarrer la connexion avec Dropbox. cd $HOME # Détacher le terminal pour pouvoir continuer d'autres actions avec le script. (.dropbox-dist/dropboxd &)& # Sleep de 3 minutes. # Synchronisation des données avec le cloud distant durant les 3 minutes. # La synchronisation se fait avec des droits en 755 qui sont appliqués sur le dossier Dropbox par un autre script, puis, retirés par après. sleep 180 # On tue le processus de Dropbox pour fermer la connexion. sudo pkill dropbox # On limite les droits de consultation du dossier Dropbox. sudo chmod -R 640 Dropbox/ # On termine le script. exit 0 Avec ce script, je définis les données qui seront sauvegardées. Je rencontre un problème lors du chiffrement des données. Il semble que je ne puisse déchiffrer les données que sur une machine Debian. Si je tente de déchiffrer le fichier sur Linux Mint, le déchiffrement ne fonctionne pas. J'ai cru à une archive corrompue, mais, si je la charge en machine virtuelle Debian, le déchiffrement fonctionne. Je ne sais pourquoi ... # Se placer dans le répertoire de l'utilisateur. cd /home/UTILISATEUR/ # Copier les données dans le dossier local Unis-pour-le-climat de Dropbox. cp backup/fichiers/redmine/sauvegarde_fichiers_redmine_$(date +'%d_%m_%y_%Hh').tgz Dropbox/Unis-pour-le-climat/backup/fichiers/redmine/sauvegarde_fichiers_redmine_$(date +'%d_%m_%y_%Hh').tgz cp backup/sql/redmine/sauvegarde_sql_redmine_$(date +'%d_%m_%y_%Hh').sql Dropbox/Unis-pour-le-climat/backup/sql/redmine/sauvegarde_sql_redmine_$(date +'%d_%m_%y_%Hh').sql # Changer les droits sur le dossier local servant de dépôt pour la sauvegarde. # sudo chown -R UTILISATEUR:UTILISATEUR Dropbox/Unis-pour-le-climat/backup/ # Donner le droit 755 pour permettre la synchronisation avec le cloud Dropbox. # Retirer les droits pour restreindre l'accès avec chmod 640. ( C'est le script précédent qui s'en charge à la fermeture de la connexion. ) sudo chmod -R 755 Dropbox/ # Chiffrer un dossier avec un mot de passe. # Exemple : tar -czf - * | openssl enc -e -aes256 -out secured.tar.gz tar -czf - Dropbox/Unis-pour-le-climat/backup/fichiers/redmine/sauvegarde_fichiers_redmine_$(date +'%d_%m_%y_%Hh').tgz | openssl enc -e -aes256 -pass pass:LEMOTDEPASSE -out Dropbox/Unis-pour-le-climat/backup/fichiers/redmine/sauvegarde_fichiers_redmine_$(date +'%d_%m_%y_%Hh').tgz.tar.gz tar -czf - Dropbox/Unis-pour-le-climat/backup/sql/redmine/sauvegarde_sql_redmine_$(date +'%d_%m_%y_%Hh').sql | openssl enc -e -aes256 -pass pass:LEMOTDEPASSE -out Dropbox/Unis-pour-le-climat/backup/sql/redmine/sauvegarde_sql_redmine_$(date +'%d_%m_%y_%Hh').sql.tar.gz # Déchiffrer le fichier : # openssl enc -d -aes256 -in archive.ext | tar xz # Le dossier est décompressé dans le répertoire de Dropbox. # La décompression ne fonctionne pas depuis GNU/Linux Mint. # La décompression fonctionne depuis Debian Stretch. # Supression des archives non sécurisées pour ne pas les exporter. rm Dropbox/Unis-pour-le-climat/backup/fichiers/redmine/sauvegarde_fichiers_redmine_$(date +'%d_%m_%y_%Hh').tgz rm Dropbox/Unis-pour-le-climat/backup/sql/redmine/sauvegarde_sql_redmine_$(date +'%d_%m_%y_%Hh').sql Source : https://www.visionduweb.eu/wiki/index.php?title=Installer_Redmine_sur_Debian#Exporter_une_copie_de_la_sauvegarde_vers_le_dossier_Dropbox_en_local
Re: How to react on a factually wrong Debian wiki change ?
On Sat, 2018-09-29 at 08:59 +, Curt wrote: > On 2018-09-28, Thomas Schmitt wrote: > > This is not "unreliable" it is "clueless". > > Insofar Curt's proposal is technically more correct. > > But actually i see no improvement over my shorter statement. > > (Maybe it's better english, but it's not better message.) > > I thought nobody said "should better not be used," but sticking that > quoted > phrase in a search engine produces over 12,000 hits. > So 12,000 people can be wrong :) Just altering the word order gives more clarity to the statement. "should be better not used" While still not entirely correct implies less of a threat. "(it) better not be used (or)" - "the computer gods will frot you" "would be better not used" may be correct depending on the rest of the context. Maybe an implicit threat of resulting danger needs to be implied? Cheers Dom. > Doubts now linger in my mind as to whether I haven't used up a lot of > electrons > for nothing. > > There's so many of them, though, I guess frugality isn't an issue > (unless > Wheeler was right, and I've sent the one zipping all over the place). > > Out. > > > Have a nice day :) > > > > Thomas > > > > > >
Re: Ghostscript produces much larger pdf files now
I recompiled the versions 9.24, 9.23 and 9.22: It changed from 9.22 to 9.23 . Does anyone has an idea what changed here such that the size of the pdf files are bigger? Flo. On 09/28/18 23:54, Flo wrote: > Dear All, > > I am using ghostscript to make pdf files smaller. > > Three days ago I upgraded my system and now I am running 9.25 . However > the size of the pdf files increased significantly. > > I guess a default value changed. Does anyone know about it. I'd like to > have it the way as it worked before. > > Thanks for your hints. > > Flo > > PS: I am using: > gs -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite > -sOutputFile="$outputfile" "$@" > >
Re: ncurses problem
On 9/29/18 9:14 AM, Sven Joachim wrote: On 2018-09-29 11:02 +, Grzesiek Sójka wrote: On 9/28/18 9:44 AM, Sven Joachim wrote: Actually it is exactly the other way around. If LINES and COLUMNS are set in the environment, then the ncurses library will _not_ update the screen size upon receiving SIGWINCH, and that causes the behavior Grzesiek observed. This is documented in ncurses(3). It seems that the problem is not related to the environment: # set | egrep 'LINE|COL|BASHOPTS' BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_LINENO=() COLORTERM=truecolor COLUMNS=119 LINES=84 # ssh localhost # set | egrep 'LINE|COL|BASHOPTS' BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_LINENO=() COLUMNS=119 LINES=84 You need to look at the output of env(1) instead. By default bash does not export LINES and COLUMNS, so they are not visible in child programs: , | % bash | $ echo $LINES | 52 | $ dash | $ echo $LINES | ` Ok, you right. -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa.
Re: How to react on a factually wrong Debian wiki change ?
On 9/29/18 10:59 AM, Curt wrote: > Doubts now linger in my mind as to whether I haven't used up a lot of > electrons > for nothing. > > There's so many of them, though, I guess frugality isn't an issue (unless > Wheeler was right, and I've sent the one zipping all over the place). That's quite some entropy created in our universe. If Carnot is right, we won't get away with it. Cheers. -- Étienne Mollier
Re: ncurses problem
On 2018-09-29 11:02 +, Grzesiek Sójka wrote: > On 9/28/18 9:44 AM, Sven Joachim wrote: >> >> Actually it is exactly the other way around. If LINES and COLUMNS are >> set in the environment, then the ncurses library will _not_ update the >> screen size upon receiving SIGWINCH, and that causes the behavior >> Grzesiek observed. This is documented in ncurses(3). > > It seems that the problem is not related to the environment: > > # set | egrep 'LINE|COL|BASHOPTS' > BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath > BASH_LINENO=() > COLORTERM=truecolor > COLUMNS=119 > LINES=84 > # ssh localhost > # set | egrep 'LINE|COL|BASHOPTS' > BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath > BASH_LINENO=() > COLUMNS=119 > LINES=84 You need to look at the output of env(1) instead. By default bash does not export LINES and COLUMNS, so they are not visible in child programs: , | % bash | $ echo $LINES | 52 | $ dash | $ echo $LINES | ` Cheers, Sven
Re: ncurses problem
On 9/28/18 9:44 AM, Sven Joachim wrote: On 2018-09-27 08:51 -0400, Greg Wooledge wrote: On Wed, Sep 26, 2018 at 10:38:53PM +, Grzesiek Sójka wrote: Hi there, I compiled following test program: == #include #include [snip] It's supposed to show current window dimension when resizing terminal window. Unfortunately, dimensions are not updated and it shows initial geometry. Interesting thing is that it works perfectly after "ssh localhost" or "su -". I tested on both, sid and stretch. exactly the same result. Any ideas?? My first thought is that your shell login profile, PS. I use xfce4 and lxdm. ... which is NOT how you normally log in, is turning on bash's checkwinsize option, which causes bash to set the LINES and COLUMNS variables upon receipt of a SIGWINCH (a signal that is sent when the window changes size). In the absence of that option, those variables might not be set at all, or might be set to the wrong size, and won't be updated when the window changes size while sitting in an idle shell. (What an ncurses program does with this signal, I honestly do not know.) So, just wild-ass guessing here, you might have put the necessaray "shopt -s checkwinsize" and "export LINES COLUMNS" into ~/.profile which is only read when you perform a shell login, and NOT when you perform an lxdm login. Actually it is exactly the other way around. If LINES and COLUMNS are set in the environment, then the ncurses library will _not_ update the screen size upon receiving SIGWINCH, and that causes the behavior Grzesiek observed. This is documented in ncurses(3). It seems that the problem is not related to the environment: # set | egrep 'LINE|COL|BASHOPTS' BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_LINENO=() COLORTERM=truecolor COLUMNS=119 LINES=84 # ssh localhost # set | egrep 'LINE|COL|BASHOPTS' BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_LINENO=() COLUMNS=119 LINES=84 -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa.
Re: How to react on a factually wrong Debian wiki change ?
On 2018-09-28, Thomas Schmitt wrote: > > This is not "unreliable" it is "clueless". > Insofar Curt's proposal is technically more correct. > But actually i see no improvement over my shorter statement. > (Maybe it's better english, but it's not better message.) I thought nobody said "should better not be used," but sticking that quoted phrase in a search engine produces over 12,000 hits. Doubts now linger in my mind as to whether I haven't used up a lot of electrons for nothing. There's so many of them, though, I guess frugality isn't an issue (unless Wheeler was right, and I've sent the one zipping all over the place). Out. > Have a nice day :) > > Thomas > > -- "Now she understood that Anna could not have been in lilac, and that her charm was just that she always stood out against her attire, that her dress could never be noticeable on her." Leo Tolstoy, Anna Karenina
Re: How to react on a factually wrong Debian wiki change ?
On 2018-09-28, Thomas Schmitt wrote: > Insofar Curt's proposal is technically more correct. > But actually i see no improvement over my shorter statement. > (Maybe it's better english, but it's not better message.) As specified in the part of my article you snipped, the unique purpose of my proposals was to eliminate your unidiomatic phraseology, not to alter or embellish or ameliorate the nature of the message itself. I do think you should probably add your cell phone number to the wiki so that confused users can ring you up if they encounter difficulties. This is being done more and more by developers these days. There's nothing like that "personal touch," Tom, to get those recalcitrant users on board with your software. Good luck and have a good one. Curt > Have a nice day :) > > Thomas > > -- "Now she understood that Anna could not have been in lilac, and that her charm was just that she always stood out against her attire, that her dress could never be noticeable on her." Leo Tolstoy, Anna Karenina
Re: Syncing GnuPG between 2 system
Jim Popovitch wrote: > Copying .gnupg is simple and easy, but not quite what I'm looking for. > Imagine having to copy your email folders or address book from system to > system, instead of using something like IMAP. I suppose I could build > something that uses WebDav to sync .gnupg... I was just hoping something > like that existed. you definitely do not want to upload your secret key anywhere. Keep your private key secret and use a keyserver for the public keys. When you have this setup IMAP is not an issue. and BTW no one said that you should copy your mail folder. regards
