date:20141116

Le Sun, 16 Nov 2014 12:32:39 +0100
admini adm...@freeatome.com a écrit:

 
 ça c'est à condition que qqn porte dotnet sous unix. j'ai peur qu'on
 en arrive là. qui sait, c'est microsoft qui le fera !
 

N'est-ce pas le but de mono ?

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141116165457.6cfb5563140b21c4b...@neuf.fr

Re: [HS] Chiffrer, oui mais...

Le Sun, 16 Nov 2014 12:23:37 +0100
steve dl...@bluewin.ch a écrit:

   Salut la liste,
 
   J'aimerais mettre une solution de chiffrement pour un groupe d'une
   dizaine de personne, utilisant des systèmes différents (en gros OSX,
   windows et linux). La partie génération de clefs est facile sous
 tous ces systèmes. La partie plus compliquée est pratique.
 Théoriquement, si je veux envoyer un document chiffré à 10 personnes,
 je dois utiliser la clef publique de chacune des personnes, chiffrer
 le document et l'envoyer. Pratiquement, je peux imaginer écrire un
 script qui automatise tout ça. Premier problème, ça signifie envoyer
 10 messages puisque le document chiffré sera différent pour chaque
   personne. 

N'étant un pro du chiffrage, je me demande pourquoi ne fais-tu pas
l'inverse, à savoir chiffrer avec ta clé et que les destinataires ouvre
avec ta clé publique ?

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141116170317.5a5c84a2b59a3a6c30525...@neuf.fr

Re: mate, pas de notification de batterie.

2014-11-16 Thread Frederic MASSOT


Le 16/11/2014 12:19, prego jeremy a écrit :

bonjour à tous,

j'utilise le bureau mate sous une debian jessie, et j'ai constaté que
quand je suis sur batterie et que celle-ci arrive a la fin, j'ai aucune
notification me l'indiquant.
il doit me manquer un paquet, mais lequel ?


C'est le rôle de mate-power-manager de gérer la batterie :

Description: power management tool for the MATE desktop
 MATE Power Manager is a session daemon for the MATE desktop
 that takes care of system or desktop events related to power, and
 triggers actions accordingly. Its philosophy is to completely hide
 these complex tasks and only show some settings important to the user.
 .
 The MATE power manager displays and manages battery status, power plug
 events, display brightness, CPU, graphics card and hard disk drive
 power saving, and can trigger suspend-to-RAM, hibernate or shutdown
 events, all integrated to other components of the MATE desktop.


Pour avoir tous les paquets de Mate, il faut installer :

- mate-desktop-environment : MATE Desktop Environment (meta package)
- mate-desktop-environment-core : MATE Desktop Environment (essential 
components, meta package)
- mate-desktop-environment-extras : MATE Desktop Environment (extra 
components, meta package)



--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5468d910.7030...@juliana-multimedia.com

Re: [HS] Microsoft s'ouvre t-elle à l'opensource ?

2014-11-16 Thread andre_debian

On Sunday 16 November 2014 08:32:29 FGK wrote:
 Mais ce que fait .NET Fondation est d'un tout autre registre. En effet, dès
 la soumission, le contributeur concède *totalement* ses droits. Si le
 projet n'est pas accepté pour intégration, le code reste malgré tout la
 propriété de la Fondation. Impossible pour le contributeur de proposer son
 code, sa fonction ou son idée à un autre projet.

 C'est comme si vous écriviez un article pour une revue A. La revue A refuse
 l'article. Vous le proposez alors à la revue B. Et ainsi de suite jusqu'à
 ce que vous trouviez preneur. En signant le CLA de .NET Fondation, vous
 proposez votre article à la revue A. Celle-ci refuse. Mais l'article reste
 sa propriété pleine et entière. Impossible pour le rédacteur de proposer
 son article (qui n'est dès lors plus le sien) à une autre revue sans
 enfreindre les termes du contrat et donc du droit

Bonsoir,

Dès lors que le travail d'un contributeur reste la propriété
de la Fondation auquel il l'a soumis, on est dans la * négation * 
même du principe du logiciel libre et opensource.

Le terme propriété n'existe pas dans la licence libre GPL,
à moins qu'il s'agisse d'une variante revue à la sauce
de nostalgiques déguisés du copyright...

Si cette info de FGK se révèle vrai, l'ouverture de Microsoft
à l'opensource est sciée à la base et devient une forme
de tromperie.

Même dans un cadre de droit d'auteur, ce serait inacceptable
et scandaleux, alors vis à vis de la GPL, n'en parlons pas !
(comment un auteur peut voir son travail confisqué par un organisme
 même si celui-ci n'est pas accepté ?)

C'est vrai que Microsoft est bien présente chaque année maintenant
au salon Linux et Opensource à la Défense et Golden-Sponsor,
avec ce slogan Microsoft, c'est aussi l'Opensource !
mais sans convaincre personne sur l'artifice et la supercherie.

S'agit-il d'une nouvelle tromperie pour inverser
le désengouement des utilisateurs de l'informatique à Microsoft ?

Il faudrait connaître l'avis de l'AFUL et de l'APRIL.

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201411161835.47895.andre_deb...@numericable.fr

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread Christian Ottié


Le 16/11/2014 17:03, Gaëtan PERRIER a écrit :

Le Sun, 16 Nov 2014 12:23:37 +0100
steve dl...@bluewin.ch a écrit:


   Salut la liste,

   J'aimerais mettre une solution de chiffrement pour un groupe d'une
   dizaine de personne, utilisant des systèmes différents (en gros OSX,
   windows et linux). La partie génération de clefs est facile sous
tous ces systèmes. La partie plus compliquée est pratique.
Théoriquement, si je veux envoyer un document chiffré à 10 personnes,
je dois utiliser la clef publique de chacune des personnes, chiffrer
le document et l'envoyer. Pratiquement, je peux imaginer écrire un
script qui automatise tout ça. Premier problème, ça signifie envoyer
10 messages puisque le document chiffré sera différent pour chaque
   personne.

N'étant un pro du chiffrage, je me demande pourquoi ne fais-tu pas
l'inverse, à savoir chiffrer avec ta clé et que les destinataires ouvre
avec ta clé publique ?

Gaëtan

Il faut toujours tourner le mulot sept fois autour du clavier avant de 
poster me disait mon vieil instit...


On signe avec sa clé privée, comme ça tout le monde peut vérifier la 
signature avec la clé publique.

Si on chiffre avec la clé privée, tout le monde peut déchiffrer...

Christian

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5468e0e9.1020...@laposte.net

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread Yves Rutschle

On Sun, Nov 16, 2014 at 05:03:17PM +0100, Gaëtan PERRIER wrote:
 N'étant un pro du chiffrage, je me demande pourquoi ne fais-tu pas
 l'inverse, à savoir chiffrer avec ta clé et que les destinataires ouvre
 avec ta clé publique ?

Si la clé est publique, alors... tout le monde pourrait
déchiffrer le message.

On fait dans le sens que tu dis pour signer, pas pour chiffrer.

Y.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116171649.gs20...@rutschle.net

Gestion électronique de documents

2014-11-16 Thread BERTRAND Joël


Bonjour à tous,

	Je recherche un système libre de gestion électronique de documents 
(pour mettre sur le côté obscur du web, donc en opensource). Y a-t-il 
des choses packagées pour debian ? Je n'ai pas trouvé grand'chose de 
probant. Et avez-vous des retours d'expérience ?


Bien cordialement,

JB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5468e483.1090...@systella.fr

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread Gaël

Salut,


 N'étant un pro du chiffrage, je me demande pourquoi ne fais-tu pas
 l'inverse, à savoir chiffrer avec ta clé et que les destinataires ouvre
 avec ta clé publique ?

Parce que la clef publique est publique. Au sens ou elle est
possiblement accessible à n'importe qui, déposée publiquement sur un
serveur de clefs.
La clef publique sert à chiffrer un message à destination du
propriétaire de la clef, qui lui (ou elle), possède la clef privée.
La clef privée reste bien rangée secrètement, est protégée par une
phrase de passe, et c'est elle qui permet de déchiffrer un message
chiffré grace à la clef publique.


Si le sujet t'intéresse, je crois que ce lien n'est pas trop mal :
http://www.bibmath.net/crypto/index.php?action=affichequoi=moderne/pgp

C'est un domaine un poil tordu, qui prend un tout petit peu de temps
(et de pratique) pour saisir les bases, et beaucoup plus pour faire
des trucs pointus :)



ciao!

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cagkqbrn+sz9usn6t_ry7npoowk+usiv46u7ifmttu2gjby4...@mail.gmail.com

Re: Gestion électronique de documents

2014-11-16 Thread Rija Andriamoria

Bonsoir à tous

Odoo anciennement OpenERP, très anciennement TinyERP,
https://www.odoo.com/fr_FR/

Cordialement

Le 16 novembre 2014 20:53, BERTRAND Joël joel.bertr...@systella.fr a
écrit :

 Bonjour à tous,

 Je recherche un système libre de gestion électronique de documents
 (pour mettre sur le côté obscur du web, donc en opensource). Y a-t-il des
 choses packagées pour debian ? Je n'ai pas trouvé grand'chose de probant.
 Et avez-vous des retours d'expérience ?

 Bien cordialement,

 JB

 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists

 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: https://lists.debian.org/5468e483.1090...@systella.fr

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread JF Straeten


LO,


On Sun, Nov 16, 2014 at 06:37:45PM +0100, Christian Ottié wrote:

[...]
 Théoriquement, si je veux envoyer un document chiffré à 10 personnes,
 je dois utiliser la clef publique de chacune des personnes, chiffrer
 le document et l'envoyer. Pratiquement, je peux imaginer écrire un
 script qui automatise tout ça. Premier problème, ça signifie envoyer
 10 messages puisque le document chiffré sera différent pour chaque
personne.

C'est sûr ça ? Je veux dire qu'il soit nécessaire de chiffrer 10 fois
distinctement le document, une fois pour chaque destinataire ?

Tu ne peux pas tout simplement le chiffrer une seule fois pour les
10 ? (Avec les 10 clés publiques des destinataires, chacun devant
pouvoir le déchiffrer avec sa clé privée.)

Je n'ai plus utilisé gpg depuis un moment, et jamais dans un contexte
multi-destinataires, mais peut-être que gpg permet ce genre de chose
(plusieurs -r dest sur la ligne de commande ?).

Il prévoit en tout cas l'option '--encrypt-to-self' qu'il fallait
spécifier, si je me souviens bien, en cas d'envoi d'un message chiffré
à quelqu'un, sous peine de ne plus pouvoir le relire sinon, c.-à-d. si
(et parce que) il est chiffré uniquement avec la clé du
destinataire.

C'est juste une idée non vérifiée, mais je creuserais dans ce sens là
d'abord...

[...]
 On signe avec sa clé privée, comme ça tout le monde peut vérifier la
 signature avec la clé publique.
 Si on chiffre avec la clé privée, tout le monde peut déchiffrer...

Yep, on chiffre pour un destinataire, donc avec la clé publique dudit
destinataire.

A+

-- 

JFS.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116180717.ga22...@jones.jfs.dt

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread Stephane Bortzmeyer

On Sun, Nov 16, 2014 at 12:23:37PM +0100,
 steve dl...@bluewin.ch wrote 
 a message of 32 lines which said:

   Premier problème, ça signifie envoyer 10 messages puisque le
   document chiffré sera différent pour chaque personne.

Euh, non, PGP ne fonctionne pas comme cela. Un seul document est
chiffré pour les dix destinataires (pour comprendre comment ça marche,
il faut se rappeler que le chiffrement se fait avec une clé partagée,
chiffrée avec la clé publique de chaque destinataire).

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116181552.ga17...@sources.org

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread Stephane Bortzmeyer

On Sun, Nov 16, 2014 at 08:31:20AM -0500,
 Fabián Rodríguez magic...@member.fsf.org wrote 
 a message of 121 lines which said:

 Thunderbird et Enigmail c'est intéressant à condition que vos
 interlocuteurs les utilisent tous,

Euh, non, Enigmail utilise la norme OpenPGP
http://www.bortzmeyer.org/4880.html et ça marche donc avec tous les
utilisateurs d'un logiciel OpenPGP.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116181750.gb17...@sources.org

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread Fabián Rodríguez



Le 2014-11-16 13:17, Stephane Bortzmeyer a écrit :
 On Sun, Nov 16, 2014 at 08:31:20AM -0500,
  Fabián Rodríguez magic...@member.fsf.org wrote 
  a message of 121 lines which said:
 
  Thunderbird et Enigmail c'est intéressant à condition que vos
  interlocuteurs les utilisent tous,
 Euh, non, Enigmail utilise la norme OpenPGP
 http://www.bortzmeyer.org/4880.html et ça marche donc avec tous les
 utilisateurs d'un logiciel OpenPGP.
 

OpenPGP est la norme, oui, pas le logiciel.

Sans les logiciels comme Enigmail comme interface, c'est moins
intéressant point de vue utilisabilité, productivité, etc. dans un
environnement de bureau dit moderne, et encore moins quand le groupe
auquel on s'adresse (et pour lequel on va probablement fournir aide et
soutien) n'utilise pas en majorité le même outil.

F.

-- 
Fabián Rodríguez - XMPP/Jabber+OTR: magic...@member.fsf.org
http://debian.magicfab.ca




signature.asc
Description: OpenPGP digital signature

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread andre_debian

On Sunday 16 November 2014 20:24:20 Fabián Rodríguez wrote:
 Sans les logiciels comme Enigmail comme interface...


Enigmail, 
nom sans doute pris à la machine presque du même nom : Enigma,
machine électromécanique portable d'origine allemande, 
(Die Chiffriermaschine Enigma) faisant appel à des rotors montés 
sur cylindres pour le chiffrement et le déchiffrement de l'information,
très utilisée par l'Allemagne nazie... :
http://fr.wikipedia.org/wiki/Enigma_%28machine%29

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201411162033.49644.andre_deb...@numericable.fr

Re: Gestion électronique de documents

2014-11-16 Thread BERTRAND Joël


Rija Andriamoria a écrit :

Bonsoir à tous

Odoo anciennement OpenERP, très anciennement TinyERP,
https://www.odoo.com/fr_FR/


Bonsoir,

Je n'ai rien vu de packagé... Ou alors je ne cherche pas au bon 
endroit...

JB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5468fda1.5070...@systella.fr

Re: Gestion électronique de documents

2014-11-16 Thread Rija Andriamoria

Rebonsoir

le bon endroit: http://nightly.odoo.com/
Odoo Debian/Ubuntu packages To install the Debian/Ubuntu package, add the
following line to your /etc/apt/sources.list:

deb http://nightly.odoo.com/8.0/nightly/deb/ ./



Rija

Le 16 novembre 2014 22:40, BERTRAND Joël joel.bertr...@systella.fr a
écrit :

 Rija Andriamoria a écrit :

 Bonsoir à tous

 Odoo anciennement OpenERP, très anciennement TinyERP,
 https://www.odoo.com/fr_FR/


 Bonsoir,

 Je n'ai rien vu de packagé... Ou alors je ne cherche pas au bon
 endroit...

 JB

 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists

 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: https://lists.debian.org/5468fda1.5070...@systella.fr

Re: Gestion électronique de documents

2014-11-16 Thread Stéphane GARGOLY

Bonjour à tous les utilisateurs et développeurs de Debian :

Le dimanche 16 novembre 2014 à 19:40, BERTRAND Joël 
joel.bertr...@systella.fr a écrit :
  Odoo anciennement OpenERP, très anciennement TinyERP,
  https://www.odoo.com/fr_FR/
 
   Je n'ai rien vu de packagé... Ou alors je ne cherche pas au bon
   endroit...

Pour la version Squeeze, il était possible d'installer Odoo/OpenERP/TinyERP. 
Voir la page suivante : 
https://packages.debian.org/search?keywords=openerpsearchon=namessuite=allsection=all

Mais pour Wheezy, cela a été retiré faute de mainteneur apparemment. Voir les 
rapports de bogues suivants https://bugs.debian.org/633587 et 
https://bugs.debian.org/633592

Autrement, il faut aller à la page http://nightly.odoo.com/ et accepter 
d'ajouter un dépôt tiers dans son fichier /etc/apt/sources.list (ou dans son 
répertoire /etc/apt/sources.list.d ).

Cordialement et à bientôt,

Stéphane.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201411162007.59216.stephane.garg...@gmail.com

Re: [HS] Chiffrer, oui mais...

Le Sun, 16 Nov 2014 18:37:45 +0100
Christian Ottié christian.ot...@laposte.net a écrit:

 Le 16/11/2014 17:03, Gaëtan PERRIER a écrit :
  Le Sun, 16 Nov 2014 12:23:37 +0100
  steve dl...@bluewin.ch a écrit:
 
 Salut la liste,
 
 J'aimerais mettre une solution de chiffrement pour un groupe d'une
 dizaine de personne, utilisant des systèmes différents (en gros OSX,
 windows et linux). La partie génération de clefs est facile sous
  tous ces systèmes. La partie plus compliquée est pratique.
  Théoriquement, si je veux envoyer un document chiffré à 10 personnes,
  je dois utiliser la clef publique de chacune des personnes, chiffrer
  le document et l'envoyer. Pratiquement, je peux imaginer écrire un
  script qui automatise tout ça. Premier problème, ça signifie envoyer
  10 messages puisque le document chiffré sera différent pour chaque
 personne.
  N'étant un pro du chiffrage, je me demande pourquoi ne fais-tu pas
  l'inverse, à savoir chiffrer avec ta clé et que les destinataires ouvre
  avec ta clé publique ?
 
  Gaëtan
 
 Il faut toujours tourner le mulot sept fois autour du clavier avant de 
 poster me disait mon vieil instit...
 
 On signe avec sa clé privée, comme ça tout le monde peut vérifier la 
 signature avec la clé publique.
 Si on chiffre avec la clé privée, tout le monde peut déchiffrer...
 

Oui et c'est bien ce qu'il veut, non ?

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141116213923.e78b8509a3d586f0cc9ab...@neuf.fr

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread Gaël

Yope,


 Si on chiffre avec la clé privée, tout le monde peut déchiffrer...

 Oui et c'est bien ce qu'il veut, non ?

euh, nan, il veut que seul-e-s les destinataires spécifié-e-s puissent
lire. Or, là, *tout le monde* pourra lire :)
Et si tout le monde peut lire, l'intérêt du chiffrement devient faible.



Bien à vous!

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAGKqBrmvWv=hlwrel9znirkogkzdzuaki1inaz_khtqp1dl...@mail.gmail.com

Re: [HS] Microsoft s'ouvre t-elle à l'opensource ?

2014-11-16 Thread FGK

Bonjour,

On Sun, Nov 16, 2014 at 06:35:47PM +0100, andre_deb...@numericable.fr wrote:
 On Sunday 16 November 2014 08:32:29 FGK wrote:
  Mais ce que fait .NET Fondation est d'un tout autre registre. En effet, dès
  la soumission, le contributeur concède *totalement* ses droits. Si le
  projet n'est pas accepté pour intégration, le code reste malgré tout la
  propriété de la Fondation. Impossible pour le contributeur de proposer son
  code, sa fonction ou son idée à un autre projet.
 
  C'est comme si vous écriviez un article pour une revue A. La revue A refuse
  l'article. Vous le proposez alors à la revue B. Et ainsi de suite jusqu'à
  ce que vous trouviez preneur. En signant le CLA de .NET Fondation, vous
  proposez votre article à la revue A. Celle-ci refuse. Mais l'article reste
  sa propriété pleine et entière. Impossible pour le rédacteur de proposer
  son article (qui n'est dès lors plus le sien) à une autre revue sans
  enfreindre les termes du contrat et donc du droit
 
 Bonsoir,
 
 Dès lors que le travail d'un contributeur reste la propriété
 de la Fondation auquel il l'a soumis, on est dans la * négation * 
 même du principe du logiciel libre et opensource.

D'un pur point de vue personnel, je suis parfaitement d'accord avec toi.

 Le terme propriété n'existe pas dans la licence libre GPL,
 à moins qu'il s'agisse d'une variante revue à la sauce
 de nostalgiques déguisés du copyright...

Si je peux me permettre, à propos de l'existence de terme de propriété
(property en anglais) dans la GPL, l'idée est un peu plus compliqué que
cela. Notes que l'on se base sur la version anglaise de la GPL, seul texte
opposable puisque seul diffusé par la FSF. Le terme n'apparaît effectivement
pas --- sauf une fois quand il est question de l'User Product. Je vais me
permettre d'enfoncer une porte ouverte, mais ça va mieux en l'écrivant : la
GNU GPL établit un régime d'exception vis-à-vis du Copyright en en modifiant
les effets afin de permettre les quatre libertés. Le Copyright étant le régime
applicable aux États-Unis d'Amérique quant à la propriété intellectuelle[1]
(j'ai dit que j'enfonçais des portes ouvertes ?). Donc la GNU GPL n'est donc
pas un autre régime, mais une ouverture du Copyright. La GNU GPL ne traite
donc que de propriété. D'ailleurs, sans rentrer dans le détail, car cela tout
le monde le sait, la personne qui pose son travail sous GNU GPL en garde
certains aspects notamment, dont le principal à savoir que le développeur
reste l'auteur original de son travail, son nom restant attaché au travail. En
schématisant, il en garde donc la propriété extrapatrimoniale (ce que l'on
nommerait droit moral en droit français) --- mais la comparaison en utilisant
des termes de droit fançais est tendancieuse, je ferais peut-être mieux de
m'abstenir...

1. http://www.copyright.gov/title17/92chap1.html

 Si cette info de FGK se révèle vrai, l'ouverture de Microsoft
 à l'opensource est sciée à la base et devient une forme
 de tromperie.

Vis-à-vis de l'esprit et de la coutume dans la communauté libre et open source
? Certainement !

 Même dans un cadre de droit d'auteur, ce serait inacceptable
 et scandaleux, alors vis à vis de la GPL, n'en parlons pas !
 (comment un auteur peut voir son travail confisqué par un organisme
  même si celui-ci n'est pas accepté ?)

En fait le truc rigolo c'est que le CLA de .NET Fondation comporte des clauses
qui ne serait pas valable en droit français (j'utilise le conditionnel au cas
où) mais qui le sont parfaitement en droit anglo-saxon. En effet, cette CLA
opère un transfert complet du copyright, donc aussi de la paternité, ce qui
est parfaitement faisable aux USA notamment ; il suffit de voir ce qui se
passe dans l'industrie du cinéma pour en avoir des exemples pratiques
notamment lors des débats pour les final cut où le réalisateur détenteur du
copyright l'emporte toujours juridiquement sur le réalisateur. On peut se
souvenir aussi à titre d'exemple de ce réalisateur accompagné de ses acteurs
arborrant un tshirt montrant la clause leur interdisant de critiquer les choix
du producteur. Étant en désaccord complet avec ce dernier, c'est le seul moyen
qu'ils avaient trouvé pour justement critiqué.

Mais pour en revenir à .NET Fondation, si je ne me trompe donc pas elle
pourrait réutiliser le travail non publié du développeur sans même avoir à
citer son nom. Mais je ne connais pas assez bien le droit anglo-saxon pour
être tout à fait catégorique, information donc à vérifier. Par contre, et en
tout cas, c'est ce qui ressort clairement du texte du CLA de .NET Fondation.

Impossible en France ! Pour le voir il faut combiner les articles L.111-1,
L.111-3 et L.121-1 du code de la propriété intellectuelle (CPI).

Les deux premiers nous apprennent que l'auteur d'une oeuvre de l'esprit jouit
sur cette oeuvre, du seul fait de sa création, d'un droit de propriété
incorporelle exclusif et opposable à tous (art. L.111-1 al. 1 CPI) et qu'elle
est indépendante de la propriété de l'objet

Re: Gestion électronique de documents

2014-11-16 Thread BERTRAND Joël


Stéphane GARGOLY a écrit :

Bonjour à tous les utilisateurs et développeurs de Debian :

Le dimanche 16 novembre 2014 à 19:40, BERTRAND Joël
joel.bertr...@systella.fr a écrit :

Odoo anciennement OpenERP, très anciennement TinyERP,
https://www.odoo.com/fr_FR/


Je n'ai rien vu de packagé... Ou alors je ne cherche pas au bon
endroit...


Pour la version Squeeze, il était possible d'installer Odoo/OpenERP/TinyERP.
Voir la page suivante :
https://packages.debian.org/search?keywords=openerpsearchon=namessuite=allsection=all

Mais pour Wheezy, cela a été retiré faute de mainteneur apparemment. Voir les
rapports de bogues suivants https://bugs.debian.org/633587 et
https://bugs.debian.org/633592

Autrement, il faut aller à la page http://nightly.odoo.com/ et accepter
d'ajouter un dépôt tiers dans son fichier /etc/apt/sources.list (ou dans son
répertoire /etc/apt/sources.list.d ).


D'accord. Je pensais trouver un truc dans les dépôts officiels.

Merci du tuyau,

JB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54691907.5000...@systella.fr

Re: [HS] Chiffrer, oui mais...

Le Sun, 16 Nov 2014 22:11:48 +0100
Gaël gag...@gmail.com a écrit:

 Yope,
 
 
  Si on chiffre avec la clé privée, tout le monde peut déchiffrer...
 
  Oui et c'est bien ce qu'il veut, non ?
 
 euh, nan, il veut que seul-e-s les destinataires spécifié-e-s puissent
 lire. Or, là, *tout le monde* pourra lire :)

Si seuls les destinataires ont cette clé publique, ça marche. Je me disais
que rien n'oblige à diffuser à la planète entière une clé publique, mais je me
trompe peut-être ?

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141116225254.3156d76d9e9c227f749ba...@neuf.fr

Re: [HS] Microsoft s'ouvre t-elle à l'opensource ?

2014-11-16 Thread andre_debian

On Sunday 16 November 2014 22:33:53 FGK wrote:
 On Sun, Nov 16, 2014 at 06:35:47PM +0100, andre_deb...@numericable.fr wrote:
  On Sunday 16 November 2014 08:32:29 FGK wrote:
   Mais ce que fait .NET Fondation est d'un tout autre registre. En effet,
   dès la soumission, le contributeur concède *totalement* ses droits. Si
   le projet n'est pas accepté pour intégration, le code reste malgré tout
   la propriété de la Fondation. Impossible pour le contributeur de
   proposer son code, sa fonction ou son idée à un autre projet.
  
   C'est comme si vous écriviez un article pour une revue A. La revue A
   refuse l'article. Vous le proposez alors à la revue B. Et ainsi de
   suite jusqu'à ce que vous trouviez preneur. En signant le CLA de .NET
   Fondation, vous proposez votre article à la revue A. Celle-ci refuse.
   Mais l'article reste sa propriété pleine et entière. Impossible pour le
   rédacteur de proposer son article (qui n'est dès lors plus le sien) à
   une autre revue sans enfreindre les termes du contrat et donc du
   droit

  Dès lors que le travail d'un contributeur reste la propriété
  de la Fondation auquel il l'a soumis, on est dans la * négation *
  même du principe du logiciel libre et opensource.

 D'un pur point de vue personnel, je suis parfaitement d'accord avec toi.

  Le terme propriété n'existe pas dans la licence libre GPL,
  à moins qu'il s'agisse d'une variante revue à la sauce
  de nostalgiques déguisés du copyright...

 Si je peux me permettre, à propos de l'existence de terme de propriété
 (property en anglais) dans la GPL, l'idée est un peu plus compliqué que
 cela. Notes que l'on se base sur la version anglaise de la GPL, seul texte
 opposable puisque seul diffusé par la FSF. Le terme n'apparaît
 effectivement pas --- sauf une fois quand il est question de l'User
 Product. Je vais me permettre d'enfoncer une porte ouverte, mais ça va
 mieux en l'écrivant : la GNU GPL établit un régime d'exception vis-à-vis du
 Copyright en en modifiant les effets afin de permettre les quatre libertés.
 Le Copyright étant le régime applicable aux États-Unis d'Amérique quant à
 la propriété intellectuelle[1] (j'ai dit que j'enfonçais des portes
 ouvertes ?). Donc la GNU GPL n'est donc pas un autre régime, mais une
 ouverture du Copyright. La GNU GPL ne traite donc que de propriété.
 D'ailleurs, sans rentrer dans le détail, car cela tout le monde le sait, la
 personne qui pose son travail sous GNU GPL en garde certains aspects
 notamment, dont le principal à savoir que le développeur reste l'auteur
 original de son travail, son nom restant attaché au travail. En
 schématisant, il en garde donc la propriété extrapatrimoniale (ce que l'on
 nommerait droit moral en droit français) --- mais la comparaison en
 utilisant des termes de droit fançais est tendancieuse, je ferais peut-être
 mieux de m'abstenir...
 1. http://www.copyright.gov/title17/92chap1.html

  Si cette info de FGK se révèle vrai, l'ouverture de Microsoft
  à l'opensource est sciée à la base et devient une forme
  de tromperie.

 Vis-à-vis de l'esprit et de la coutume dans la communauté libre et open
 source ? Certainement !

  Même dans un cadre de droit d'auteur, ce serait inacceptable
  et scandaleux, alors vis à vis de la GPL, n'en parlons pas !
  (comment un auteur peut voir son travail confisqué par un organisme
   même si celui-ci n'est pas accepté ?)

 En fait le truc rigolo c'est que le CLA de .NET Fondation comporte des
 clauses qui ne serait pas valable en droit français (j'utilise le
 conditionnel au cas où) mais qui le sont parfaitement en droit anglo-saxon.
 En effet, cette CLA opère un transfert complet du copyright, donc aussi de
 la paternité, ce qui est parfaitement faisable aux USA notamment ; il
 suffit de voir ce qui se passe dans l'industrie du cinéma pour en avoir des
 exemples pratiques notamment lors des débats pour les final cut où le
 réalisateur détenteur du copyright l'emporte toujours juridiquement sur le
 réalisateur. On peut se souvenir aussi à titre d'exemple de ce réalisateur
 accompagné de ses acteurs arborrant un tshirt montrant la clause leur
 interdisant de critiquer les choix du producteur. Étant en désaccord
 complet avec ce dernier, c'est le seul moyen qu'ils avaient trouvé pour
 justement critiqué.

 Mais pour en revenir à .NET Fondation, si je ne me trompe donc pas elle
 pourrait réutiliser le travail non publié du développeur sans même avoir à
 citer son nom. Mais je ne connais pas assez bien le droit anglo-saxon pour
 être tout à fait catégorique, information donc à vérifier. Par contre, et
 en tout cas, c'est ce qui ressort clairement du texte du CLA de .NET
 Fondation.

 Impossible en France ! Pour le voir il faut combiner les articles L.111-1,
 L.111-3 et L.121-1 du code de la propriété intellectuelle (CPI).

 Les deux premiers nous apprennent que l'auteur d'une oeuvre de l'esprit
 jouit sur cette oeuvre, du seul fait de sa création, d'un droit de
 propriété incorporelle exclusif et

Re: [HS] Chiffrer, oui mais...

2014-11-16 Thread Jean Baptiste FAVRE

On 16/11/2014 22:52, Gaëtan PERRIER wrote:
 Le Sun, 16 Nov 2014 22:11:48 +0100
 Gaël gag...@gmail.com a écrit:
 
 Yope,


 Si on chiffre avec la clé privée, tout le monde peut déchiffrer...

 Oui et c'est bien ce qu'il veut, non ?

 euh, nan, il veut que seul-e-s les destinataires spécifié-e-s puissent
 lire. Or, là, *tout le monde* pourra lire :)
 
 Si seuls les destinataires ont cette clé publique, ça marche. Je me disais
 que rien n'oblige à diffuser à la planète entière une clé publique, mais je me
 trompe peut-être ?

Si la clef publique ne doit pas être (trop) diffusée, c'est donc une
clef secrète/privée.
On ne chiffre *jamais* avec une clef privée, c'est inutile.

JB

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/546925b5.6070...@jbfavre.org

Re: [HS] Microsoft s'ouvre t-elle à l'opensource ?

2014-11-16 Thread FGK

On Sun, Nov 16, 2014 at 11:16:31PM +0100, andre_deb...@numericable.fr wrote:
 Je vais donc résumer :

 copyright, droit d'auteur, ce n'est sans doute pas tout à fait la même
 chose.

On les oppose même très souvent.

 Les lois les régissant semblent être différentes selon les pays.

C'est cela. Surtout que, et comment déjà dit, essayer d'expliquer la GPL et
des contrats anglo-saxons en utilisant des termes de droit français se révèle
assez difficile, voir carrément incorect, puisque les notions étant définies
autrement. Ça peut aider à la compréhension, mais du point de vue du
raisonnement juridique ça ne tient pas beaucoup. Je connais un ou deux
juristes qui crieraient au scandale parce que j'ai utilisé droit
extrapatrimonial/droits moraux dans la même phrase que Copyright. Il faut
normalement utiliser les mots anglais qui ont leur propre définition.

 La GPL - GNU aux USA serait une extension du copyright.

D'une certaine manière oui. En réalité on parle de régime d'exception (en tout
cas en droit français). Un régime consiste, grosso modo, en toutes les règles
qui régissent une situation donnée ainsi que ses effets (juridiques
s'entend). La but de la GNU GPL vis-à-vis du Copyright est de dire : voilà ce
que fait le Copyright mais nous, par exception à ses termes, on va dire que
vous avez le droit de faire ça et ça. Ce mécanisme juridique est opéré dans le
point 2. Basic Permissions de la GNU GPL.[1]

1. http://www.gnu.org/copyleft/gpl.html

 La proposition de .NET Microsoft d'orienter certains logiciels
 vers l'opensource, pourrait être légale sans contredire la GPL.

Si je peux me permettre il faut bien faire la différence entre licence et
CLA. Techiquement, ce que propose .NET Fondation est de l'open source. Elle
utilise la licence Expat pour cela (faussement nommée MIT par tout un
chacun). C'est une licence open source mais bien plus permissive que la
GPL. Ici nous parlons du code diffusé par .NET Fondation. Et c'est donc à ne
pas confondre avec le code *soumis par un contributeur à .NET Fondation* qui
lui est régit par la CLA.

Pour réexpliquer plus clairement. Le développeur signe la CLA et soumet son
code. Dès soumission du code, celui-ci appartient totalement à la
fondation. Elle décide alors de faire un choix. Soit de diffuser ce qui est
maintenant *son* code en l'intégrant au projet sous licence MIT. Pour le
développeur c'est transparent puisqu'il escomptait justement que son code soit
sous cette licence. Soit de ne pas diffuser son code sur ce projet et sur
cette licence mais d'en faire autre chose (et là on peut imaginer tout ce
qu'on veut). Le truc abérrant j'en conviens, c'est que si le code n'est pas
effectivement intégré au projet, légalement, du fait de la signature de la
CLA, le code appartenant dorénavant à .NET Fondation, le développeur n'a pas
le droit de le réutiliser comme il veut. Il peut le faire bien sûr, mais dans
ce cas, s'il vient à l'idée de la fondation de l'attaquer, il y a de très
forte chance qu'elle gagne. En pratique, globalement, il y a peu de chances
que ça arrive. Je vois mal Microsoft attaquer un développeur indépendant sous
prétexte qu'il a réutiliser trois lignes de code préalablement soumis à .NET
Fondation. Par contre, imaginons que ce développeur ait une idée lumineuse,
une fonction nouvelle, que sais-je. S'il venait à réutiliser cette idée dans
un autre projet et que celui-ci fasse vraiment concurrence à Microsoft, la
Fondation aurait un moyen légal d'agir.

Il faut donc bien séparer la licence sous laquelle .NET Fondation diffuse son
code (licence open source) et le régime contractuel qui régit les relations
entre le développeur contributeur et la fondation. Dans ce second cas, la
bonne comparaison à faire est d'opposer la CLA de la FSF (et non la GPL) à la
CLA de .NET Fondation.

Pour en terminer là, le but de ma première intervention était simplement de
mettre en lumière ce que _permet_ cette CLA. Son application pratique par la
.NET Fondation étant tout autre chose. Il est hors de question pour moi, je le
répète, de jeter la pierre. Il existe des tas de développeurs pour lesquels
cette situation ne présente aucun problème, à commencer par ceux qui ont
l'habitude que leur code appartiennent totalement à la boîte pour laquelle il
travaille. Par contre, ça en gène d'autres, et s'ils signent sans savoir, une
belle déconfiture est à prévoir.

 Par contre, point de vue éthique GPL pure, oui c'est inacceptable.

Voir l'avant-dernier paragraphe ci-dessus.
 
 Je confirme que microsoft participe au salon sus-cité,
 sans vergogne en s'auto-proclamant Microsoft, c'est aussi l'opensource !,
 ce qui lui vaut (heureusement) quelques défilés vengeurs de la part
 d'associations dont l'April devant leur stand (quand même !).

Haha j'imagine l'ambiance avec les regards en chiens de faïence. Ça doit être
assez fun/épique.

 Piqûre de rappel CLA :
 http://en.wikipedia.org/wiki/Contributor_License_Agreement
 Les organismes/compagnies qui utilisent le CLA :
 Apache Software

Re: mate, pas de notification de batterie.

2014-11-16 Thread prego jeremy



Le 16/11/2014 18:04, Frederic MASSOT a écrit :

Le 16/11/2014 12:19, prego jeremy a écrit :

bonjour à tous,

j'utilise le bureau mate sous une debian jessie, et j'ai constaté que
quand je suis sur batterie et que celle-ci arrive a la fin, j'ai aucune
notification me l'indiquant.
il doit me manquer un paquet, mais lequel ?


C'est le rôle de mate-power-manager de gérer la batterie :


merci, j'ai retesté et en effet ça fonctionne !



Pour avoir tous les paquets de Mate, il faut installer :

- mate-desktop-environment : MATE Desktop Environment (meta package)
- mate-desktop-environment-core : MATE Desktop Environment (essential 
components, meta package)
- mate-desktop-environment-extras : MATE Desktop Environment (extra 
components, meta package)




justement, je ne souhaite installer que le minimum, et tout fonctionnait 
sauf ça.


jerem

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54692d20.5040...@prego-network.net

[resolu] Re: [testing] message bizarre quand je fais un ls dans /root

Le Fri, 14 Nov 2014 23:52:00 +0100
Gaëtan PERRIER gaetan.perr...@neuf.fr a écrit:

 Bonjour,
 
 Je viens de constater que je fais un ls dans /root j'ai un message bizarre
 qui s'affiche dans le terminal:
 
 # ls /root/
 ult: exit-code) since Wed 2014-08-06 21:16:46 CEST; 1h 37min ago
 ystemd[1]: Failed to start Remount Root and Kernel File Systems.
 

En fait ce n'étaient pas des messages qui apparaissaient mais 2 fichiers qui
avaient pour noms des bouts de messages ...
Je ne sais pas comment ils ont été créés, sûrement une fausse manip.
Je les ai effacé.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141117001034.dd1c6225ef0e4647ea646...@neuf.fr

Re: [HS] Microsoft s'ouvre t-elle à l'opensource ?

2014-11-16 Thread Haricophile

Le Mon, 17 Nov 2014 00:02:14 +0100,
FGK f...@opmbx.org a écrit :

 Pour en terminer là, le but de ma première intervention était
 simplement de mettre en lumière ce que _permet_ cette CLA. Son
 application pratique par la .NET Fondation étant tout autre chose. Il
 est hors de question pour moi, je le répète, de jeter la pierre. Il
 existe des tas de développeurs pour lesquels cette situation ne
 présente aucun problème, à commencer par ceux qui ont l'habitude que
 leur code appartiennent totalement à la boîte pour laquelle il
 travaille. Par contre, ça en gène d'autres, et s'ils signent sans
 savoir, une belle déconfiture est à prévoir.

C'est là où RMS fait la distinction entre Opensource et Libre, ce qui
n'est pas compris par tout le monde. 
Il y a des gens qui veulent simplement pouvoir bosser avec le
code sans trop comprendre que le libre a des implications concrètes qui
vont plus loin que la pure doctrine ou la philosophie. 
Il y a d'ailleurs aussi ceux qui veulent avoir de l'open-source pas
libre, ceci semble en être une assez bonne illustration.

Dans un registre différent, j'ai vu avec intérêt la question
qu'a posé un journaliste à Bill Gates, en pleine tournée humanitaire en
Afrique en présence des enfants aidés par sa fondation, concernant le
travail des enfants dans les filières de fabrication des ordinateurs et
téléphones. Question bien évidemment suivi d'aucune réponse et d'un
départ anticipé, suivi d'une engueulade de l'attaché de presse. Bill
Gates n'a plus rien à voir avec tout ça, il ne travaille plus avec
Microsoft, il n'est plus qu'un des principaux actionnaires c'est à
dire rien du tout. 

C'est vrai quoi, faut pas déconner, on fait du charity business, on
soigne son image de marque, on économise sur les impôts, on fait du
public-relation, on achète quelques indulgences pour aller au Paradis et
on place ses produits au passage. C'est pas comme si les fondations
c'était un truc désintéressé ou charitable.

Ou plutôt il y en a, mais celles de ces gros poissons, j'ai quelques
difficultés à y accorder du crédit. Ils ne sont désintéressés que
lorsque ça leur rapporte plus que ça ne leur coûte.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117013421.11339f26@azuki.jisui

Bajar version anterior de un paquete

2014-11-16 Thread Pablo

Gente la otra ves me hicieron una consulta en un curso sobre un tema con el
que nunca me tope. Me preguntaron que sucede cuando uno necesita tener
instalada una versión antigua de un paquete y por accidente se actualizo
dicho paquete, como se puede volver a una version mas vieja del mismo, y
como se puede evitar que se actualice ese paquete por mas que tenga nuevas
versiones. Por lo que tengo entendido se que hay una forma de marcar un
paquete para que no lo actualicen, nunca lo hice pero se que hay un método
creo que lo llaman algo asi como holdear un paquete. Ahora ni idea de como
hacer para de un paquete que se actualizo para volver dicho paquete a una
versión mas antigua.



-- 
Pablo

Re: Bajar version anterior de un paquete


El 16/11/14 a las 11:40, Pablo escribió:

Gente la otra ves me hicieron una consulta en un curso sobre un tema con
el que nunca me tope. Me preguntaron que sucede cuando uno necesita
tener instalada una versión antigua de un paquete y por accidente se
actualizo dicho paquete, como se puede volver a una version mas vieja
del mismo, y como se puede evitar que se actualice ese paquete por mas
que tenga nuevas versiones. Por lo que tengo entendido se que hay una
forma de marcar un paquete para que no lo actualicen, nunca lo hice pero
se que hay un método creo que lo llaman algo asi como holdear un
paquete. Ahora ni idea de como hacer para de un paquete que se actualizo
para volver dicho paquete a una versión mas antigua.



--
Pablo


Hola Pablo:
Te cuento como lo hacía en entorno gráfico con Synaptic (digo hacía 
porque al menos con la versión estable me funcionaba, ahora en testing 
no me funciona, supongo que por eso, ser testing)


Abres synaptic y seleccionas el paquete que quieres volver a una versión 
anterior


Vas al menú Paquete, forzar versión... y coges la anterior.
Y lo mismo para bloquear la versión, el mismo menú

Así me iba a mi en estable, pero con testing siempre me sale la opción 
de forzar versión en gris (desactivada)


--
www.LinuxCounter.net

Registered user #558467
has 2 linux machines


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m4a0fm$o10$1...@ger.gmane.org

Re: Bajar version anterior de un paquete

2014-11-16 Thread Manolo Díaz

El domingo, 16 nov 2014 a las 12:06 horas (UTC+1),
Eduardo Rios escribió:

El 16/11/14 a las 11:40, Pablo escribió:
 Gente la otra ves me hicieron una consulta en un curso sobre un tema con
 el que nunca me tope. Me preguntaron que sucede cuando uno necesita
 tener instalada una versión antigua de un paquete y por accidente se
 actualizo dicho paquete, como se puede volver a una version mas vieja
 del mismo, y como se puede evitar que se actualice ese paquete por mas
 que tenga nuevas versiones. Por lo que tengo entendido se que hay una
 forma de marcar un paquete para que no lo actualicen, nunca lo hice pero
 se que hay un método creo que lo llaman algo asi como holdear un
 paquete. Ahora ni idea de como hacer para de un paquete que se actualizo
 para volver dicho paquete a una versión mas antigua.



 --
 Pablo

Hola Pablo:
Te cuento como lo hacía en entorno gráfico con Synaptic (digo hacía 
porque al menos con la versión estable me funcionaba, ahora en testing 
no me funciona, supongo que por eso, ser testing)

Abres synaptic y seleccionas el paquete que quieres volver a una versión 
anterior

Vas al menú Paquete, forzar versión... y coges la anterior.
Y lo mismo para bloquear la versión, el mismo menú

Así me iba a mi en estable, pero con testing siempre me sale la opción 
de forzar versión en gris (desactivada)


También se puede hacer con apt-mark (del paquete apt), con aptitude, ...

En cuanto a buscar versiones antiguas, en http://snapshot.debian.org/
puedes encontrarlas todas.

Saludos.
-- 
Manolo Díaz


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116125549.54e61...@gmail.com

Re: Bajar version anterior de un paquete

2014-11-16 Thread Ricardo Adolfo Sánchez Arboleda

Yo hago esto:
Bajo el paquete lo instalo en synaptic voy a paquete marco bloquear versión.
y cuando me salen actualizaciones las hago directamente desde synaptic
para que no se actualice el paquete con la ultima versión y listo.

*Saludes;*

rasa.

El día 16 de noviembre de 2014, 6:55, Manolo Díaz
diaz.man...@gmail.com escribió:
El domingo, 16 nov 2014 a las 12:06 horas (UTC+1),
Eduardo Rios escribió:

El 16/11/14 a las 11:40, Pablo escribió:
Gente la otra ves me hicieron una consulta en un curso sobre un tema con
el que nunca me tope. Me preguntaron que sucede cuando uno necesita
tener instalada una versión antigua de un paquete y por accidente se
actualizo dicho paquete, como se puede volver a una version mas vieja
del mismo, y como se puede evitar que se actualice ese paquete por mas
que tenga nuevas versiones. Por lo que tengo entendido se que hay una
forma de marcar un paquete para que no lo actualicen, nunca lo hice pero
se que hay un método creo que lo llaman algo asi como holdear un
paquete. Ahora ni idea de como hacer para de un paquete que se actualizo
para volver dicho paquete a una versión mas antigua.

--
Pablo

Hola Pablo:
Te cuento como lo hacía en entorno gráfico con Synaptic (digo hacía
porque al menos con la versión estable me funcionaba, ahora en testing
no me funciona, supongo que por eso, ser testing)

Abres synaptic y seleccionas el paquete que quieres volver a una versión
anterior

Vas al menú Paquete, forzar versión... y coges la anterior.
Y lo mismo para bloquear la versión, el mismo menú

Así me iba a mi en estable, pero con testing siempre me sale la opción
de forzar versión en gris (desactivada)

También se puede hacer con apt-mark (del paquete apt), con aptitude, ...

En cuanto a buscar versiones antiguas, en http://snapshot.debian.org/
puedes encontrarlas todas.

Saludos.
--
Manolo Díaz

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116125549.54e61...@gmail.com

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAE=ryQ_p1k+89U3UrD2FBXCco_Tb8QiPT=hht2cb9cyh7pn...@mail.gmail.com

Re: Herramienta para documentar desarrollo de software

2014-11-16 Thread jorarome

El día 13 de noviembre de 2014, 10:56, Roberto Moreno P.
rmor...@gmail.com escribió:
La pregunta primera es

¿Que deseas documentar en detalle?

Saludos

El 13 de noviembre de 2014, 12:41, jorarome jorar...@gmail.com escribió:

Recurro a la lista para que me brinden informacion sobre herramientas
libres u open source que permita via web (on line) hacer documentación
de desarrollo de software.

Es poco lo que encontrado, como:
http://trac.edgewall.org/
http://sourceforge.net/projects/osrmt/ que podria ser.
http://sourceforge.net/projects/nimble/ que entiendo es solo para
levantamiento de requerimientos.

Es posible que mi busqueda este mal direccionada, por lo que acudo a
ustedes.

Gracias por la atenciòn y Saludos,

Jose Raul

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
https://lists.debian.org/caom8zoy3z-f3pssesysh3wv1m587tm0nr8an_x-2ikwmwhb...@mail.gmail.com

--
Roberto Andrés Moreno Pérez

Hola Roberto:

En respuesta a tu inquietud:
Se requiere una aplicacion web (en linea) que permita documentar los
proyectos de desarrollo de aplicaciones web, app o cualquier tipo de
desarrollo software, es decir, que una vez se ha definido el documento
de planeación con sus respectivos casos de uso y estos son conformes
con la necesidad del cliente, se inicia el desarrollo y finalmente se
hace la entrega al cliente, posteriormente, se efectuaran
ajustes/correcciones en el código desarrollado por parte de
desarroladores que no participaron en el inicio del desarrollo, por lo
que se ve la necesidad de contar con algun tipode documento del
desarrollo.

Agradezco a todos los que han dado sus opiniones y comentarios ante
esta inquitud.

Jose Raul

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAOM8zOa7SDkV8WN5XoZ1DVzq8497gc=+aigqaslsvuzmrys...@mail.gmail.com

Re: Bajar version anterior de un paquete

El Sun, 16 Nov 2014 12:06:32 +0100, Eduardo Rios escribió:
 Te cuento como lo hacía en entorno gráfico con Synaptic (digo hacía
 porque al menos con la versión estable me funcionaba, ahora en testing
 no me funciona, supongo que por eso, ser testing)

(...)

 Así me iba a mi en estable, pero con testing siempre me sale la opción
 de forzar versión en gris (desactivada)

Dado que testing ya se ha congelado, me extrañaría que no funcionara esa 
opción :-?

Quizá te aparece en gris porque el paquete que seleccionas no tiene dos 
versiones (o más) disponibles que poder instalar. Eso podrás verlo 
seleccionado el paquete y yendo a la pestaña Versiones; si sólo aparece 
una no te permitirá seleccionar la opción de forzar una versión concreta.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11.16.16.08...@gmail.com

Re: Bajar version anterior de un paquete


El 16/11/14 a las 17:08, Camaleón escribió:

El Sun, 16 Nov 2014 12:06:32 +0100, Eduardo Rios escribió:

Te cuento como lo hacía en entorno gráfico con Synaptic (digo hacía
porque al menos con la versión estable me funcionaba, ahora en testing
no me funciona, supongo que por eso, ser testing)


(...)


Así me iba a mi en estable, pero con testing siempre me sale la opción
de forzar versión en gris (desactivada)


Dado que testing ya se ha congelado, me extrañaría que no funcionara esa
opción :-?

Quizá te aparece en gris porque el paquete que seleccionas no tiene dos
versiones (o más) disponibles que poder instalar. Eso podrás verlo
seleccionado el paquete y yendo a la pestaña Versiones; si sólo aparece
una no te permitirá seleccionar la opción de forzar una versión concreta.

Saludos,



Mira, un ejemplo: Hoy he actualizado estos paquetes:
Actualizó los siguientes paquetes:
acpi-fakekey (0.142-5) to 0.142-6
acpi-support (0.142-5) to 0.142-6
acpi-support-base (0.142-5) to 0.142-6
acpid (1:2.0.23-1) to 1:2.0.23-2
dbus (1.8.8-2) to 1.8.10-1
dbus-x11 (1.8.8-2) to 1.8.10-1
i965-va-driver (1.4.1-1) to 1.4.1-2
libdbus-1-3 (1.8.8-2) to 1.8.10-1

Pues, al menos con synaptic, no puedo volver a la versión 0.142-5 de 
acpi-fakekey...


Con estable, siempre me salian varios paquetes, marcados como (stable) 
si es el que venía con la distro o (now) si tenía otra posterior.


Pero creo que con testing el funcionamiento es diferente, ya que como 
siempre que se actualiza es la nueva testing, no se puede volver atrás 
(o esa es mi impresión).



--
www.LinuxCounter.net

Registered user #558467
has 2 linux machines


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m4als9$pfp$1...@ger.gmane.org

Re: Bajar version anterior de un paquete


El 16/11/14 a las 18:11, Eduardo Rios escribió:

El 16/11/14 a las 17:08, Camaleón escribió:

El Sun, 16 Nov 2014 12:06:32 +0100, Eduardo Rios escribió:

Te cuento como lo hacía en entorno gráfico con Synaptic (digo hacía
porque al menos con la versión estable me funcionaba, ahora en testing
no me funciona, supongo que por eso, ser testing)


(...)


Así me iba a mi en estable, pero con testing siempre me sale la opción
de forzar versión en gris (desactivada)


Dado que testing ya se ha congelado, me extrañaría que no funcionara esa
opción :-?

Quizá te aparece en gris porque el paquete que seleccionas no tiene dos
versiones (o más) disponibles que poder instalar. Eso podrás verlo
seleccionado el paquete y yendo a la pestaña Versiones; si sólo aparece
una no te permitirá seleccionar la opción de forzar una versión concreta.

Saludos,



Mira, un ejemplo: Hoy he actualizado estos paquetes:
Actualizó los siguientes paquetes:
acpi-fakekey (0.142-5) to 0.142-6
acpi-support (0.142-5) to 0.142-6
acpi-support-base (0.142-5) to 0.142-6
acpid (1:2.0.23-1) to 1:2.0.23-2
dbus (1.8.8-2) to 1.8.10-1
dbus-x11 (1.8.8-2) to 1.8.10-1
i965-va-driver (1.4.1-1) to 1.4.1-2
libdbus-1-3 (1.8.8-2) to 1.8.10-1

Pues, al menos con synaptic, no puedo volver a la versión 0.142-5 de
acpi-fakekey...

Con estable, siempre me salian varios paquetes, marcados como (stable)
si es el que venía con la distro o (now) si tenía otra posterior.

Pero creo que con testing el funcionamiento es diferente, ya que como
siempre que se actualiza es la nueva testing, no se puede volver atrás
(o esa es mi impresión).


Como decía, debe ser algo así, porque con paquetes instalados locales u 
obsoletos (que aparecen iceweasel e icedove), si me deja escoger entre 
la versión 33 (now) ó 31 (testing)



--
www.LinuxCounter.net

Registered user #558467
has 2 linux machines


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m4amcp$4bi$1...@ger.gmane.org

Re: Bajar version anterior de un paquete

El Sun, 16 Nov 2014 18:11:38 +0100, Eduardo Rios escribió:

 El 16/11/14 a las 17:08, Camaleón escribió:
 El Sun, 16 Nov 2014 12:06:32 +0100, Eduardo Rios escribió:
 Te cuento como lo hacía en entorno gráfico con Synaptic (digo hacía
 porque al menos con la versión estable me funcionaba, ahora en testing
 no me funciona, supongo que por eso, ser testing)

 (...)

 Así me iba a mi en estable, pero con testing siempre me sale la opción
 de forzar versión en gris (desactivada)

 Dado que testing ya se ha congelado, me extrañaría que no funcionara
 esa opción :-?

 Quizá te aparece en gris porque el paquete que seleccionas no tiene dos
 versiones (o más) disponibles que poder instalar. Eso podrás verlo
 seleccionado el paquete y yendo a la pestaña Versiones; si sólo
 aparece una no te permitirá seleccionar la opción de forzar una versión
 concreta.


 Mira, un ejemplo: Hoy he actualizado estos paquetes:

(...)

Eduardo, ¿qué te dice la pestaña Versión en cada uno de esos paquetes? 
Eso es lo importante.

 Pues, al menos con synaptic, no puedo volver a la versión 0.142-5 de
 acpi-fakekey...
 
 Con estable, siempre me salian varios paquetes, marcados como (stable)
 si es el que venía con la distro o (now) si tenía otra posterior.
 
 Pero creo que con testing el funcionamiento es diferente, ya que como
 siempre que se actualiza es la nueva testing, no se puede volver atrás
 (o esa es mi impresión).

Me parece que te estás liando. La opción de Forzar versión sólo aparece 
cuando tienes varias opciones/versiones posibles, así que seguramente lo 
que te haya pasado es que en estable tenías habilitado el repositorio de 
testing de ahí que pudieras elegir entre dos versiones de un mismo 
paquete. Ahora en testing sólo tendrás el repo de testing de ahí que no 
te permita bajar la versión ;-)

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11.16.17.26...@gmail.com

Re: Bajar version anterior de un paquete

El Sun, 16 Nov 2014 18:20:26 +0100, Eduardo Rios escribió:

 El 16/11/14 a las 18:11, Eduardo Rios escribió:
 El 16/11/14 a las 17:08, Camaleón escribió:

(...)

 Quizá te aparece en gris porque el paquete que seleccionas no tiene
 dos versiones (o más) disponibles que poder instalar. Eso podrás verlo
 seleccionado el paquete y yendo a la pestaña Versiones; si sólo
 aparece una no te permitirá seleccionar la opción de forzar una
 versión concreta.

(...)

 Pero creo que con testing el funcionamiento es diferente, ya que como
 siempre que se actualiza es la nueva testing, no se puede volver
 atrás (o esa es mi impresión).
 
 Como decía, debe ser algo así, porque con paquetes instalados locales u
 obsoletos (que aparecen iceweasel e icedove), si me deja escoger entre
 la versión 33 (now) ó 31 (testing)

Precisamente eso confirma mi teoría, es decir, que la opción de Forzar 
versión funciona correctamente en testing y sólo cuando hay dos paquetes 
de distintas versiones disponibles (en tu caso la 31 vendrá del repo 
testing y la 33 del repo experimental) te permite seleccionarla ;-)

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11.16.17.58...@gmail.com

Re: Bajar version anterior de un paquete


El 16/11/14 a las 18:26, Camaleón escribió:

El Sun, 16 Nov 2014 18:11:38 +0100, Eduardo Rios escribió:


El 16/11/14 a las 17:08, Camaleón escribió:

El Sun, 16 Nov 2014 12:06:32 +0100, Eduardo Rios escribió:

Te cuento como lo hacía en entorno gráfico con Synaptic (digo hacía
porque al menos con la versión estable me funcionaba, ahora en testing
no me funciona, supongo que por eso, ser testing)


(...)


Así me iba a mi en estable, pero con testing siempre me sale la opción
de forzar versión en gris (desactivada)


Dado que testing ya se ha congelado, me extrañaría que no funcionara
esa opción :-?

Quizá te aparece en gris porque el paquete que seleccionas no tiene dos
versiones (o más) disponibles que poder instalar. Eso podrás verlo
seleccionado el paquete y yendo a la pestaña Versiones; si sólo
aparece una no te permitirá seleccionar la opción de forzar una versión
concreta.



Mira, un ejemplo: Hoy he actualizado estos paquetes:


(...)

Eduardo, ¿qué te dice la pestaña Versión en cada uno de esos paquetes?
Eso es lo importante.


Solo me aparece la versión 0.142-6 como (testing).
¿No debería salir también la anterior?




Pues, al menos con synaptic, no puedo volver a la versión 0.142-5 de
acpi-fakekey...

Con estable, siempre me salian varios paquetes, marcados como (stable)
si es el que venía con la distro o (now) si tenía otra posterior.

Pero creo que con testing el funcionamiento es diferente, ya que como
siempre que se actualiza es la nueva testing, no se puede volver atrás
(o esa es mi impresión).


Me parece que te estás liando. La opción de Forzar versión sólo aparece
cuando tienes varias opciones/versiones posibles, así que seguramente lo
que te haya pasado es que en estable tenías habilitado el repositorio de
testing de ahí que pudieras elegir entre dos versiones de un mismo
paquete. Ahora en testing sólo tendrás el repo de testing de ahí que no
te permita bajar la versión ;-)


Pues creo que tienes razón... Pensándolo más detenidamente, creo que me 
salían varias versiones porque tenía el repositorio backports...


Si hubiera tenido solo el repositorio stable, cada paquete que se 
hubiera actualizado, sería el nuevo estable, y tampoco hubiera podido 
elegir otra versión anterior, ¿verdad?




--
www.LinuxCounter.net

Registered user #558467
has 2 linux machines


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m4aovn$epj$1...@ger.gmane.org

Re: Bajar version anterior de un paquete

El Sun, 16 Nov 2014 19:04:40 +0100, Eduardo Rios escribió:

 El 16/11/14 a las 18:26, Camaleón escribió:

(...)

 Eduardo, ¿qué te dice la pestaña Versión en cada uno de esos
 paquetes? Eso es lo importante.
 
 Solo me aparece la versión 0.142-6 como (testing).
 ¿No debería salir también la anterior?

No, porque para esos paquetes no tienes configurado ningún repositorio 
adicional que te proporcione otra versión (ni inferior ni superior), sólo 
el de testing y el de seguridad.

(...)

 Me parece que te estás liando. La opción de Forzar versión sólo
 aparece cuando tienes varias opciones/versiones posibles, así que
 seguramente lo que te haya pasado es que en estable tenías habilitado
 el repositorio de testing de ahí que pudieras elegir entre dos
 versiones de un mismo paquete. Ahora en testing sólo tendrás el repo de
 testing de ahí que no te permita bajar la versión ;-)
 
 Pues creo que tienes razón... Pensándolo más detenidamente, creo que me
 salían varias versiones porque tenía el repositorio backports...

:-)
 
 Si hubiera tenido solo el repositorio stable, cada paquete que se
 hubiera actualizado, sería el nuevo estable, y tampoco hubiera podido
 elegir otra versión anterior, ¿verdad?

Sólo podrías seleccionar una versión anterior en los paquetes que hayan 
recibido alguna actualización de seguridad, como por ejemplo la imagen 
del kernel (linux-image-*), ahí sí que tendrías dos o más versiones 
disponibles en la pestaña de Versiones.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11.16.18.18...@gmail.com

Re: Ayuda!!!!!!

2014-11-16 Thread Alberto


El 18/10/14 11:48, fernando sainz escribió:

2016-04-27 21:53 GMT+02:00 lreyes lre...@ipurr.sc.sc.rimed.cu:

hola amigis megustaria saber porque motivo mi postfix no me quiere enviar

...


A mi me gustaría saber por que diablos se responde a mensajes como este:

No pone un asunto relacionando con el problema que tiene.
Escribe, con perdón, como el culo.
Es bastante OT.
Probablemente tiene problemas por enviar correos basura.


si a eso le sumas que ha escrito el mismo correo, con EL MISMO ASUNTO a 
la lista de Postfix, y ya se le contestó, pues...



--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5468fa08.1060...@bersol.info

[OT] duda en sistemas i386 y amd64 (32 y 64 bits)

2014-11-16 Thread unciegobailando


Hola gente linda de la lista !!
(y tambien a la otra no tan linda que con profundo desagrado tambien 
suelo leer y repudiar en silencio)


 Me surgio un antiguo fantasma del pasado en lo referente a 
arquitecturas. Ese fantasma me supo susurrar al oido que los sistemas 
-compilaciones- para 32 bits instalados en equipos con arquitectura 64 
bits y con un total de memoria ram no superior a los 4 gb resultan mas 
veloces que sus pares de 64 bits en similares condiciones.


 Hoy en dia sabemos que con restecto al limite de 4 gb de memoria ram 
para sistemas de 32 bits se ha encontrado una solucion en los nucleos 
linux, implementada en aquellos cuyo nombre contiene la sigla: pae.


 Tambien podemos pensar mas o menos ayudados por la logica que si un 
microprocesador funciona a razon -por ejemplo el que utilizo- de 1,6 mhz 
de velocidad (o frecuencia) parecera mas efectivo trasladando en un 
mismo tiempo paquetes de informacion de 64 bits de tamaño en vez de 
otros de 32 bits, en lo cual se necesitaria de 2 tiempos para igualar la 
cantidad de informacion procesada en aquel.


 Y a pesar de esto no dejo de leer cada tanto en la web recomendaciones 
o directamente experiencias en las que se recomienda instalar un sistema 
de 32 bits sobre un procesador amd64 para ganar agilidad o velocidad.


 Dejando exclusivamente de lado los problemas referentes a librerias y 
soporte de arquitecturas que pueden presentar sobre todo programas de 
tipo privativo, finalizo con tres pregutnas orientativas:

1) ¿cual es su conocimiento y opinion al respecto?

2) ¿es un mito, una especie de sancionalismo o es realidad?

3) ¿las reglas de compilacion por defecto para con cada una de las 
arquitecturas tendran algo que ver al respecto?


 saludos desde el sur, donde un ciego pregunta.

P.D.: como suelo tener instalados en el mismo equipo dos sistemas, ambos 
debian, en diferentes versiones; Uno estable y otro testing o sid es que 
pense en usar el nuevo Jessie estable para 32 bits...



--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5468fc24.7010...@mail.com

Re: [OT] duda en sistemas i386 y amd64 (32 y 64 bits)

El Sun, 16 Nov 2014 16:33:56 -0300, unciegobailando escribió:

(...)
 
   Y a pesar de esto no dejo de leer cada tanto en la web recomendaciones
 o directamente experiencias en las que se recomienda instalar un sistema
 de 32 bits sobre un procesador amd64 para ganar agilidad o velocidad.

Si mal no recuerdo Ubuntu está recomendando la versión de 64 bits en aras 
de dejar de mantener la versión de 32 bits en un futuro.

Creo que la diatriba radica en sistemas con 4 GiB (o menos) de RAM, ahí 
es donde merece la pena replantearse la instalación de un sistema de 32 
bits aunque el micro admita las extensiones de 64 bits.

Por aquí tienes un par de tests orientativos ejecutados con versiones de 
32/64 bits y configuración de 4/8 GiB de RAM:

http://www.phoronix.com/scan.php?page=articleitem=ubuntu_1404_x64num=1
http://www.phoronix.com/scan.php?page=articleitem=ubuntu_1410_32v64num=1

   Dejando exclusivamente de lado los problemas referentes a librerias y
 soporte de arquitecturas que pueden presentar sobre todo programas de
 tipo privativo, finalizo con tres pregutnas orientativas:
 1) ¿cual es su conocimiento y opinion al respecto?

Resumiendo mucho, a partir de 4 GiB de RAM instalar un sistema de 64 bits.

 2) ¿es un mito, una especie de sancionalismo o es realidad?

No, no es mito ni sensacionalismo, pero cada configuración/sistema es un 
mundo y no hay una única regla que sea válida para todos los entornos. 
Además, en la mayoría de las instalaciones genéricas la diferencia en 
cuanto a rendimiento entre una instalación de 32 o 64 bits suele ser 
mínima e imperceptible.

 3) ¿las reglas de compilacion por defecto para con cada una de las
 arquitecturas tendran algo que ver al respecto?

Es posible, lo que sí que recuerdo es un mensaje (antiguo ya) de la lista 
del kernel donde decían que a partir de 6 GiB usar un kernel con PAE 
tenía un efecto negativo en el rendimiento del sistema, que con esa 
cantidad de RAM era recomendable usar un kernel de 64 bits.
 
   saludos desde el sur, donde un ciego pregunta.
 
 P.D.: como suelo tener instalados en el mismo equipo dos sistemas, ambos
 debian, en diferentes versiones; Uno estable y otro testing o sid es que
 pense en usar el nuevo Jessie estable para 32 bits...

¿Cuánta RAM hay por ahí?

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11.16.21.01...@gmail.com

Re: darse de baja

2014-11-16 Thread Angel Claudio Alvarez

El Fri, 14 Nov 2014 00:40:13 +0100
fernando sainz fernandojose.sa...@gmail.com escribió:

El día 14 de noviembre de 2014, 0:24, javier frf
francisco...@gmail.com escribió:

El 13 de noviembre de 2014, 19:34, fernando sainz
fernandojose.sa...@gmail.com escribió:

El día 13 de noviembre de 2014, 22:09, Rivera Valdez
riveraval...@ysinembargo.com escribió:
fer, tu mensaje cae en la misma lógica que estás criticando.

Me parece que hay varios que tienen una especie de cruzada
o guerra santa personal con Camaleón y al final están ensuciando
los hilos sólo para saltar a agredirla cada vez que les parece
oportuno. ¿Y si la dejan en paz o la filtran y listo?

Slds

No hay ninguna cruzada personal, te lo aseguro. (De hecho cuando leo
los mensajes no suelo fijarme en quien los manda, respondo a
cualquiera, incluso he respondido a Camaleón aun sabiendo que me tiene
filtrado, porque las respuestas que aquí se dan son para el que
pregunta y para los demás que puedan verse en esa situación en un
futuro.)

Llevo algunos años en esta lista y no he visto nada semejante a esta
persona.

No sé si es algún trastorno de personalidad o algo así, porque no es
normal. (Debe pensar que todos los mensajes van dirigidos a ella y
tiene la necesidad compulsiva de responder)
.
Nunca he criticado cuando responde a preguntas a la lista dando
soluciones.
He criticado sus actitudes poco solidarias con el resto de la lista.

1- lo de los filtros, que ya comenté el problema que suponen y que ya
ha respondido Manolo en este mismo hilo.

2- Sus respuestas de hacer una búsqueda en google y dar los enlaces
que encuentra. No ayudan a la persona que preguntaba que perfectamente
podría haber hecho esa búsqueda y deja en el histórico de la lista
enlaces que pueden acabar rotos en un futuro cercano.

3- Esta lista no es un chat de opinión y muchos de los hilos en los
que interviene acaban así.

4- No acepta las opiniones de los demás y siempre acaba replicando a
todo el mundo hasta que por
aburrimiento le dan la razón (se callan...)

5- Defiende los OT como un derecho, cuando deben ser algo excepcional
y no generar mas ruido del necesario. (No vale la excusa de que si se
marcan [OT] pueden ser filtrados)

6- Para terminar (podría añadir muchos más puntos) te diré, que el
otro día analizando unos 2000 mensajes de la lista, 500 eran de ella,
algunos legítimos sin duda, pero parece no ser consciente de que los
que estamos subscritos a la lista recibimos los mensajes e interrumpe
nuestra actividad, cosa que no nos importa cuando se trata de ayudar,
pero es muy molesto leer un mensaje suyo dando respuestas evidentes,
ya dadas (porque también tiene la costumbre de no leer las respuestas
de los demás, o los tiene filtrados) o haciéndose la graciosilla... en
fin...

Imagina si por ejemplo otros 50 suscritos a la lista tuviéramos la
misma actitud. (No serían 2.000, serían más de 25.000)

S2.

tienes toda la razón compañero!!
pero a corto plazo no veo solución al asunto, pues cual sería?

Eso es un OT total (más para una lista de psiquiatría). ;-)
No en serio, supongo que tarde o temprano aunque se haga la sorda
filtrando a los que criticamos sus actitudes, se dará cuenta de que
debe corregirlas y entonces la lista volverá a la normalidad.

Lamento comunicarte que los reyes magos son los padres.
S2.

2014-11-07 12:30 GMT-03:00 fernando sainz
fernandojose.sa...@gmail.com:
2014-11-07 16:20 GMT+01:00 Camaleón noela...@gmail.com:
El Fri, 07 Nov 2014 08:09:47 -0500, Ginsberg Gamarra escribió:

Me parece que así no vas a poder.

https://www.debian.org/MailingLists/unsubscribe

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11.07.15.20...@gmail.com

Todos sabemos como se borra uno de la lista, porque lo pone al final
de cada mensaje que recibimos.

Si no puedes contener tu enfermiza necesidad de responder a todo, por
lo menos responde al privado de esa persona y no molestes al resto de
listeros.

S2.

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
https://lists.debian.org/cagwrhgj9f+kpfa7rjfupgoch71d7gt-oxx5hwtf6vcuefd...@mail.gmail.com

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAGw=rHjAq8zmL03cE9aj7eOJ7E2O8Enuqi4PA6GqPUOsett=_...@mail.gmail.com

--
Angel Claudio Alvarez an...@angel-alvarez.com.ar

--
To UNSUBSCRIBE, email to

Re: darse de baja

2014-11-16 Thread Angel Claudio Alvarez

El Fri, 14 Nov 2014 11:35:54 -0300
Paulo Riquelme olivar...@gmail.com escribió:

 
 La ayuda en base a experiencia propia pienso que es súper bien
 recibida, aunque siempre habrán diferencias muy pequeñas que hagan
 distinta cada situación, pero lo de leer el man, sinceramente y con la
 seguridad de que obtendré algunos calificativos no muy aceptables, me
 atreveré a decirte que yo uso el computador por las utilidades que me
 presta, pero de verdad, con mucho respeto y aprecio a quienes brindan
 su tiempo para otros en esta lista, yo no vivo para conocer más mi
 sistema operativo, si en algún momento tengo algún problema, busco y
 si encuentro la solución bien, si me mandas a leer un manual así en
 pelota, voy a seguir buscando en otra parte una respuesta más clara.
 Para mi suerte Debian está en un momento en que los problemas de uso
 cotidiano son casi inexistentes, pero si llego a tener alguno qué
 bueno que hay gente que con su conocimiento me puede brindar el camino
 a la solución.

Mira vos, sos pura solidaridad
O sea que usas a la lista como soporte tecnico, ya que lo unico que haces es 
buscar soluciones
y aportar no podes hacerlo ya que no estas interesado en aprender sobre tu S.O. 
y por ende cualquier aporte que hagas sera basado en una solucion anteriormente 
publicada.
Muy bueno lo tuyo
De mi parte no esperes nunca una ayuda.

 
 Sobre lo que escriben del exceso de respuestas, las respuestas obvias
 y el aspecto humano que acá se ha mencionado, quizás me equivoco pero
 siento que no van los tres aspectos en el mismo sentido, de hecho para
 mí algunas de esas respuestas obvias me sirven, quitarlas va en contra
 de ser humano con ese pobre ser que como yo quiere usar su sistema
 para labores diarias y no ponerse a modificarlo.

si queres hacer eso se un poco honesto y paga por el soporte, ya que no 
devolves de ninguna forma la ayuda que te brindan y que es la base de la 
comunidad Debian

Hasta nunca
 
 saludos
 
 
  En fin...
 
  Como dije no se cuestiona las medidas que ella tome con algunos usuarios de
  la lista cuando habla de sus filtros,  tampoco se cuestiona su ayuda,  pero
  si su actitud golosa por decirlo a responder a todo.
 
  Saludos.
 
 
 
 -- 
 Paulo Riquelme Olivares
 UEFI = Una Espantosa y Fregada Imbecilidad
 
 
 -- 
 To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 https://lists.debian.org/CAJvcBJZuU=mR2QEFGxzHYh82Gzjh7X61bu34kxo1=sKuHh0d=a...@mail.gmail.com
 


-- 
Angel Claudio Alvarez an...@angel-alvarez.com.ar


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141116233455.836cff58a81ab56147309...@angel-alvarez.com.ar

Re: MALWARE Virus no Ubuntu [Alerta]

2014-11-16 Thread Helio Loureiro

Se não estava atualizado, pode ter sido uma exploração de vulnerabilidade
do bash (shell shock).
Nos meus logs eu vejo que isso virou lugar comum. Por qualquer serviço
aberto. Http, https, mail, etc.

Helio Loureiro
-= sent by Android =-
On Nov 15, 2014 4:22 PM, Thiago Zoroastro thiago.zoroas...@bol.com.br
wrote:

Adicionar o usuário para usar sudo no /etc/sudoers
rootALL=(ALL:ALL) ALL

deixo embaixo do de cima:
usuarioALL=(ALL:ALL) ALL

E uso sudo no Debian e Debian-baseds. Que é desabilitado por padrão.

Tenho feito isso sempre desde que migrei do Ubuntu.

On 15-11-2014 10:31, henrique wrote:

A minha **opinião** eh que não importa a distribuição, se você alterar o
padrão dela, vai dar alguma coisa errada.
Veja:

- Ubuntu deixa a senha de root em branco por padrão, e deixa o acesso de
root habilitado no ssh por padrão. E isso é seguro. Idiota e non-sense ao
meu ver, mas seguro.

- Debian pede para você setar a senha de root e deixa o acesso de root
desabilitado por padrão. E isso é seguro.

O que não é seguro é o usuário modificar o padrão sem pensar em
consequências. Por ex, habilitar a senha de root no ubuntu, ou habilitar o
login de root via ssh no debian, deixa ambos os sistemas mto inseguros,
caso a senha de root seja fraca. E esta combinação de fatores (senha fraca
no root e acesso de root via ssh ) eh perigosa em qualquer distribuição, em
qualquer sistema, seja gnewsense, trisquel, *bsd, beos, tra-la-la-systems.

Os sistemas tem um bom nível de segurança por padrão - com as devidas
limitações causadas pelo nosso fator humano. As catástrofes são geral e
costumeiramente causadas pelo usuário aspirante a administrador, em
qualquer distro, em qualquer sistema, em qualquer cenário.

Abraços

Henry

--
*De:* Thiago Zoroastro thiago.zoroas...@bol.com.br
thiago.zoroas...@bol.com.br
*Para:* debian-user-portuguese@lists.debian.org
*Enviadas:* Sexta-feira, 14 de Novembro de 2014 19:20
*Assunto:* Re: MALWARE Virus no Ubuntu [Alerta]

Depende é claro do tipo de usuário. LMDE é perfeito para usar sem
inesperados empecilhos por conta dos formatos privativos predominantes. O
mais indicado é Trisquel ou gNewSense, mas o gNewSense é uma porção mais
trabalhoso que o próprio Debian.

On 14-11-2014 17:05, Flavio Menezes dos Reis wrote:

Por estas e por outras que prefiro o Debian.

Em 14 de novembro de 2014 14:25, Rodrigo Cunha rodrigo.root...@gmail.com
escreveu:

Srs, utilizo o ubuntu e nesta semana me deparei com um problema.
Minha rede estava falhando e resolvi vas culhar o meu S/O.
Descobri os arquivos abaixo instalados no meu PC local :

/etc/init.d/DbSecuritySpt
/etc/init.d/selinux
/etc/init.d/.SSH2
/etc/init.d/.SSH2

Eles geravam um daemon chamado sfewfesfs e alguns subprogramas chamados
de sshdd14xxx e se conectavam com ips na china :

netname: CHINANET-ZJ-HU
country: CN
descr: CHINANET-ZJ Huzhou node network

Ainda bem que descobri a tempo, só achei estranho, meu primeiro virus de
linux e, pelo que eu me lembre não instalei nada no S/O nestes ultimos dias.

Bom, para quem é leigo em segurança, como eu, e quer saber como descobri
essas praguinhas, eu sem nada conectado eo meu host, executei netstat
-putona, vi os programas que estavam com nomes do tipo :
tcp0 0 192.168.0.3:45200 ipremoto:7668
ESTABELECIDA 1592/.sshhdd14 keepalive (55,40/0/0)
tcp0 0 192.168.0.3:35433 ipremoto:36665
ESTABELECIDA 18537/sfewfesfs keepalive (50,02/0/0)
tcp0 0 192.168.0.3:58840 ipremoto:7168
ESTABELECIDA 13987/.sshdd14 keepalive (50,79/0/0)
No meu caso, para encontra-los, nao usei a TI, mas sim a lógica, vi os
ultimos programas instalados no meu init 2 (meu runlevel)
e estavam lá, os arquivos listados como instalados ontem:
/etc/init.d/DbSecuritySpt
/etc/init.d/selinux
/etc/init.d/.SSH2
/etc/init.d/.SSH2
Emfim :
Não via,até hoje, a necessidade de utilizar um antivírus no meu
linux...porém agora
Caso queiram procurar algo, busquem no google por
/etc/init.d/dbsecurityspt e encontrarão algumas referencias.
Em todo caso fiquem alertas, principalmente se seu S/O estiver na DMZ
(meu caso).
Achei o caso desse cara interessante:

https://forums.plex.tv/index.php/topic/103175-rootkit-on-my-readynas-516-check-your-boxes/

--
Atenciosamente,
Rodrigo da Silva Cunha

--
Flávio Menezes dos Reis
Procuradoria-Geral do Estado do RS
Assessoria de Informática do Gabinete
Técnico Superior de Informática
(51) 3288-1763

Re: Como monitorar portas e arquivos? (era: MALWARE Virus no Ubuntu)

2014-11-16 Thread Helio Loureiro

É impossível monitorar uma rede com comandos.

Se faz isso pra achar a causa.

Em geral é melhor ter uma ferramenta gráfica como ntop.

Em redes maiores é preciso ter um nagios ou algo similar.

Helio Loureiro
-= sent by Android =-
On Nov 15, 2014 3:24 PM, Andre N Batista andrenbati...@gmail.com wrote:

 On Fri, Nov 14, 2014 at 07:15:12PM -0200, Thiago Zoroastro wrote:
  Como poderia eu monitorar essas portas?

 Dê uma olhada no netstat.

 
  $ top
  e
  $ ps aux
 
  Quais processos não deveriam estar ali?

 Isso é o administrador que vai ter que saber/escolher, afinal é ele que
 define a política de instalação de softwares e de segurança da máquina.

 
  Que outras formas de monitorar vulnerabilidades do sistema podem ser
 feitas?

 Você pode monitorar também os arquivos abertos com o lsof e testar suas
 configurações com o nmap.

 Abraços,

Re: MALWARE Virus no Ubuntu [Alerta]

2014-11-16 Thread Thiago Zoroastro

Ok, eu hackeei o Debian mas não sei se fiz algo certo.

Att.

On 16-11-2014 09:20, Helio Loureiro wrote:

 Se não estava atualizado, pode ter sido uma exploração de
 vulnerabilidade do bash (shell shock).
 Nos meus logs eu vejo que isso virou lugar comum. Por qualquer serviço
 aberto. Http, https, mail, etc.

 Helio Loureiro
 -= sent by Android =-

 On Nov 15, 2014 4:22 PM, Thiago Zoroastro
 thiago.zoroas...@bol.com.br mailto:thiago.zoroas...@bol.com.br wrote:

 Adicionar o usuário para usar sudo no /etc/sudoers
 rootALL=(ALL:ALL) ALL

 deixo embaixo do de cima:
 usuarioALL=(ALL:ALL) ALL

 E uso sudo no Debian e Debian-baseds. Que é desabilitado por padrão.

 Tenho feito isso sempre desde que migrei do Ubuntu.

 On 15-11-2014 10:31, henrique wrote:
 A minha **opinião** eh que não importa a distribuição, se você
 alterar o padrão dela, vai dar alguma coisa errada. 
 Veja: 

 - Ubuntu deixa a senha de root em branco por padrão, e deixa o
 acesso de root habilitado no ssh por padrão. E isso é seguro.
 Idiota e non-sense ao meu ver, mas seguro. 

 - Debian pede para você setar a senha de root e deixa o acesso de
 root desabilitado por padrão. E isso é seguro. 

 O que não é seguro é o usuário modificar o padrão sem pensar em
 consequências. Por ex, habilitar a senha de root no ubuntu, ou
 habilitar o login de root via ssh no debian, deixa ambos os
 sistemas mto inseguros, caso a senha de root seja fraca. E esta
 combinação de fatores (senha fraca no root e acesso de root via
 ssh ) eh perigosa em qualquer distribuição, em qualquer sistema,
 seja gnewsense, trisquel, *bsd, beos, tra-la-la-systems. 

 Os sistemas tem um bom nível de segurança por padrão - com as
 devidas limitações causadas pelo nosso fator humano.  As
 catástrofes são geral e costumeiramente causadas pelo usuário
 aspirante a administrador, em qualquer distro, em qualquer
 sistema, em qualquer cenário. 

 Abraços

 Henry

 
 *De:* Thiago Zoroastro thiago.zoroas...@bol.com.br
 mailto:thiago.zoroas...@bol.com.br
 *Para:* debian-user-portuguese@lists.debian.org
 mailto:debian-user-portuguese@lists.debian.org
 *Enviadas:* Sexta-feira, 14 de Novembro de 2014 19:20
 *Assunto:* Re: MALWARE Virus no Ubuntu [Alerta]

 Depende é claro do tipo de usuário. LMDE é perfeito para usar sem
 inesperados empecilhos por conta dos formatos privativos
 predominantes. O mais indicado é Trisquel ou gNewSense, mas o
 gNewSense é uma porção mais trabalhoso que o próprio Debian.



 On 14-11-2014 17:05, Flavio Menezes dos Reis wrote:
 Por estas e por outras que prefiro o Debian.

 Em 14 de novembro de 2014 14:25, Rodrigo Cunha
 rodrigo.root...@gmail.com mailto:rodrigo.root...@gmail.com
 escreveu:

 Srs, utilizo o ubuntu e nesta semana me deparei com um problema.
 Minha rede estava falhando e resolvi vas culhar o meu S/O.
 Descobri os arquivos abaixo instalados no meu PC local :

 /etc/init.d/DbSecuritySpt
 /etc/init.d/selinux
 /etc/init.d/.SSH2
 /etc/init.d/.SSH2

 Eles geravam um daemon chamado sfewfesfs e alguns
 subprogramas chamados de sshdd14xxx e se conectavam com ips
 na china :

 netname: CHINANET-ZJ-HU
 country:   CN
 descr:  CHINANET-ZJ Huzhou node network

 Ainda bem que descobri a tempo, só achei estranho, meu
 primeiro virus de linux e, pelo que eu me lembre não instalei
 nada no S/O nestes ultimos dias.
  
 Bom, para quem é leigo em segurança, como eu, e quer saber
 como descobri essas praguinhas, eu sem nada conectado eo meu
 host, executei netstat -putona, vi os programas que estavam
 com nomes do tipo :
 tcp0  0 192.168.0.3:45200
 http://192.168.0.3:45200/  ipremoto:7668  
 ESTABELECIDA 1592/.sshhdd14 keepalive (55,40/0/0)
 tcp0  0 192.168.0.3:35433
 http://192.168.0.3:35433/  ipremoto:36665
 ESTABELECIDA 18537/sfewfesfs  keepalive (50,02/0/0)
 tcp0  0 192.168.0.3:58840
 http://192.168.0.3:58840/  ipremoto:7168  
 ESTABELECIDA 13987/.sshdd14 keepalive (50,79/0/0)
 No meu caso, para encontra-los, nao usei a TI, mas sim a
 lógica, vi os ultimos programas instalados no meu init 2 (meu
 runlevel)
 e estavam lá, os arquivos listados como instalados ontem:
 /etc/init.d/DbSecuritySpt
 /etc/init.d/selinux
 /etc/init.d/.SSH2
 /etc/init.d/.SSH2
 Emfim :
 Não via,até hoje, a necessidade de utilizar um antivírus no
 meu linux...porém agora
 Caso queiram procurar algo, busquem no google por

Re: Como monitorar portas e arquivos? (era: MALWARE Virus no Ubuntu)

2014-11-16 Thread Thiago Zoroastro

Uma vez li que os navegadores de internet são aonde tem mais
possibilidade de vulnerabilidades. E é o que parece mesmo. Mas não
apenas isso, é como eles tornam-se pesados de vez em quando. Tem vezes
que preciso fazer
$ killall iceweasel

Para restabelecer o computador. Quando a carga no monitor do sistema
está lá no alto, ou eu fecho o Iceweasel ou é preciso reiniciar o netbook.

O
usuario is not in the sudoers file.  This incident will be reported.

voltou a aparecer quando uso o sudo em $

Att.

On 16-11-2014 09:22, Helio Loureiro wrote:

 É impossível monitorar uma rede com comandos.

 Se faz isso pra achar a causa.

 Em geral é melhor ter uma ferramenta gráfica como ntop.

 Em redes maiores é preciso ter um nagios ou algo similar.

 Helio Loureiro
 -= sent by Android =-

 On Nov 15, 2014 3:24 PM, Andre N Batista andrenbati...@gmail.com
 mailto:andrenbati...@gmail.com wrote:

 On Fri, Nov 14, 2014 at 07:15:12PM -0200, Thiago Zoroastro wrote:
  Como poderia eu monitorar essas portas?

 Dê uma olhada no netstat.

 
  $ top
  e
  $ ps aux
 
  Quais processos não deveriam estar ali?

 Isso é o administrador que vai ter que saber/escolher, afinal é
 ele que
 define a política de instalação de softwares e de segurança da
 máquina.

 
  Que outras formas de monitorar vulnerabilidades do sistema podem
 ser feitas?

 Você pode monitorar também os arquivos abertos com o lsof e testar
 suas
 configurações com o nmap.

 Abraços,

Re: Como monitorar portas e arquivos? (era: MALWARE Virus no Ubuntu)

2014-11-16 Thread Emerson Sobreiro

O erro nos navegadores de ficarem lentos, pesados e chegar travar eu já
percebi mas testando descobri que é o Flash.

Re: Como monitorar portas e arquivos? (era: MALWARE Virus no Ubuntu)

2014-11-16 Thread Enio Climaco Sales Junior


Veja se o usuário está em /etc/sudoers
On 16-11-2014 15:29, Thiago Zoroastro wrote:

usuario is not in the sudoers file.  This incident will be reported.



--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5468f8b2.3050...@gmail.com

Re: Como monitorar portas e arquivos? (era: MALWARE Virus no Ubuntu)

2014-11-16 Thread Thiago Zoroastro

Retirei propositalmente.

Pô cara eu tenho domínio sobre meu sistema..

Abs


On 16-11-2014 17:19, Enio Climaco Sales Junior wrote:
 Veja se o usuário está em /etc/sudoers
 On 16-11-2014 15:29, Thiago Zoroastro wrote:
 usuario is not in the sudoers file.  This incident will be reported.




-- 
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54691b09.1070...@bol.com.br

Re: advice on choosing an AMD chipset

2014-11-16 Thread Michael Fothergill



  For me, fiddling with ventilation/cooling fans is a job for Archibald
  Harry Tuttle

 Nice one! I'm assuming you're referring to the movie Brasil.

 That's right.  The business of cooling seems to be important in computing

 (see
http://techreport.com/review/26279/amd-radeon-r9-295-x2-graphics-card-reviewed
and  http://primeurmagazine.com/weekly/AE-PR-07-14-104.html)

I have become curious about the excavator/carrizo APU that AMD are working
on.

If it were powerful enough then you could cut out the Tuttle factor but
still have good all round cpu and graphics performance. That would be
convenient.
-- 
Michael Fothergill

Tempus fugit , sed Latini etiam sugit

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Laurent Bigonville

Le Sat, 15 Nov 2014 20:21:49 -0500,
Marty mar...@ix.netcom.com a écrit :

 On 11/15/2014 06:49 AM, Andrei POPESCU wrote:
[...]
 
  At least some of people rejecting systemd demand that it be removed
  completely, including libsystemd. How is it pro-choice to forbid me
  from being able to use a software at its full potential?
 
 For me it's more about being unable to remove it completely, because
 of vendor lock-in. There's no technical reason that I know of that
 anything in userspace cannot modular, and replaceable, so when
 something cannot be replaced then an alternative must be provided, or
 else my default assumption is that vendor lock-in is in effect.

Well, yes there are technical reasons why you cannot remove a library
package when you have symbols provided by this library used in an
executable. You can still recompile the package and remove some
configure flag if you want to remove this dependency.

OTHO there is no technical reasons that I can see, to completely remove
libsystemd package. You have tenth of other libraries on your system
that, like libsystemd, turn them self into a noop if some some
functionality or daemon are not enable. I'm thinking here for example
about libselinux and libaudit (both also written by Red Had and the
NSA, OMG!!!11), and yet I fail to see any outcry here...

So as long as you cannot _prove_ that having libsystemd installed on
your machine is causing any issues, I'll personally mentally classify
your request as I don't want to see any packages containing the
systemd string on my machine and redirect these to /dev/null.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116112652.78d2a...@fornost.bigon.be

Re: Installing an Alternative Init?

2014-11-16 Thread Brian

On Sat 15 Nov 2014 at 19:31:27 -0500, The Wanderer wrote:

 On 11/15/2014 at 07:21 PM, Paul E Condon wrote:
 
  Yet another topic: It should be possible to install systemd on a
  system that already has some other init system installed on it. This
  should be tested, but how?
 
 If I understand what you mean by install systemd, then it's trivial:
 
 apt-get install systemd
 
 That does not switch the active init system to be systemd. Doing *that*
 would require:
 
 apt-get install systemd-sysv
 
 and even that, in its turn, does not (automatically?) remove
 sysvinit-core from the system; you can still boot to it (from a
 backup-installed location) with a kernel command line option, as a
 fallback if systemd does break something too badly to even boot.

systemd-sysv and sysvinit-core are not co-installable and this is
expressed in the Conflicts: for both packages. Installing one results
in the other being removed.

 Or that's the claim, anyway. I've been examining files from
 sysvinit-core on my own computer in an attempt to remind myself of some
 of the details of how that works, and at a glance I don't see the backup
 copy of /sbin/init anywhere...

A Wheezy system has the sysvinit package installed. Moving to Jessie
will upgrade this package. The only thing of real interest in it is
/lib/sysvinit/init, the fallback SysV init binary.

A new installation does not have the sysvinit package so it would have
to be purposefully installed to get the fallback init.

Which leads to yet another way of getting a first boot with sysvinit
using d-i:

1. Preseed installation of sysvinit with base-installer/includes or a
   late_command.

2. Boot with 'init=/lib/sysvinit/init'. A late_command could put this in
   /etc/default/grub.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/16112014103424.b38d685b4...@desktop.copernicus.demon.co.uk

Re: iceweasel Video can't be played because the file is corrupt

2014-11-16 Thread Brad Rogers

On Sat, 15 Nov 2014 21:39:29 +
Lisi Reisz lisi.re...@gmail.com wrote:

Hello Lisi,

Thanks, Brad.

NP.

As I said, I could only alter Flash, and that made no difference.  
Still: Video can't be played because the file is corrupt.

TBH, I'm not really sure what's happening, since the H264 codec doesn't
seem to have any MIME types associated with it.

I suggest you install gecko-mediaplayer(1) from the Debian repos and
restart Iceweasel, then try again.

(1) It can handle all sorts of file formats.

-- 
 Regards  _
 / )   The blindingly obvious is
/ _)radnever immediately apparent
I'm spending all my money and it's going up my nose
Teenage Depression - Eddie  The Hot Rods


pgpuWEWVwnJPY.pgp
Description: OpenPGP digital signature

Re: Installing an Alternative Init?

2014-11-16 Thread Brian

On Sun 16 Nov 2014 at 00:23:24 +, Martin Read wrote:

 On 15/11/14 23:04, Paul E Condon wrote:
 If one could absolutely rely on apt-get always getting it right, then
 
 apt-get install -y sysvinit-core
 
 could always be used to remove systemd even from a system that has
 been booted into systemd and running, and not just in the context
 of a pre-seed. Right?
 
 That command is unlikely to actually remove systemd on any Debian
 jessie system. What it will do is change what the symlink /sbin/init
 points to so that next time the system on which you do it is
 rebooted, it will use sysvinit as the init daemon.

I see a removal of a symlink, not a change.

With the systemd-sysvinit package installed:

   root@jessie-b2:~# ls -l /sbin/init
   lrwxrwxrwx 1 root root 20 Sep 28 20:05 /sbin/init - /lib/systemd/systemd

With the sysvinit-core package installed:

   root@jessie-b2:~# ls -l /sbin/init
   -rwxr-xr-x 1 root root 39396 Nov 11 19:59 /sbin/init



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1611201440.e3038d94c...@desktop.copernicus.demon.co.uk

Anyone having troubles with autofs and NTFS formatted drives on Jessie/sid ?

2014-11-16 Thread Thierry Rascle

Hi list,

I'm using sid, with wmii as my only window manager and desktop
environment.

I'm using autofs for automounting my external devices:
- CD/DVD drives,
- USB sticks formatted as FAT or NTFS,
- external hard disk drives formatted has EXT4 or NTFS.  or NTFS),
  CD-ROM drives, external hard disk drives).

I dist-upgrade my system very regularly.

The automounting used to work perfectly for all my external devices,
but since a few weeks (or perhaps a few months), it does not work any
more with my NTFS formatted devices. I have to manually mount them
instead.

Does any one have the same issue ? I can't find any post or bug report
about that. I can't tell which package upgrade caused the issue. I
believe it is not an upgrade of the autofs package that caused the
issue because the autofs package has not been upgraded since March
2014.

I have not changed my autofs configuration files recently, so I don't
believe they're the cause of the issue.

My /etc/auto.master file contains one line:
/var/autofs/removable   /etc/auto.removable
--timeout=2,sync,nodev,nosuid

The /etc/auto.removable has the following entries:
chikai  -fstype=iso9660,ro,sync,nodev,nosuid:/dev/chikai
chil-fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/chil
eos_digital
-fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/eos_digital
nikon_d200
-fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/nikon_d200 fao
-fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/fao ikki
-fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/ikki jacala
-fstype=iso9660,ro,sync,nodev,nosuid:/dev/jacala buldeo
-fstype=iso9660,ro,sync,nodev,nosuid:/dev/buldeo kaa
-fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/kaa mao
-fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/mao nag
-fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/nag medianavmp3
-fstype=vfat,gid=46,dmask=002,fmask=113 :/dev/medianavmp3
akela2_root -fstype=ext4:/dev/akela2_root
akela2_home -fstype=ext4:/dev/akela2_home
akela2_tmp  -fstype=ext4:/dev/akela2_tmp
akela2_usr  -fstype=ext4:/dev/akela2_usr
akela2_var  -fstype=ext4:/dev/akela2_var

The automounting used to work for all of the entries, but now does not
for the three entries with -fstype=ntfs.

Note that the associated devices in /dev are still created properly
when the devices are plugged in, so I don't suspect a udev related
issue.

Thierry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116124231.219ca73e@akela.localdomain

Re: If Not Systemd, then What?

2014-11-16 Thread Klistvud


Dne, 21. 10. 2014 04:06:23 je Marty napisal(a):

On 10/20/2014 03:45 PM, Patrick Bartek wrote:

After much vitriolic gnashing of teeth from those opposed to systemd,
I wonder...  What is a better alternative?  And it can't be sysvinit.


Why not? I do not see sysvinit -- or any other legacy init system, for  
that matter -- as contradicting the following:


Whichever one the user wants is the best. The users should decide,  
individually and collectively. The distro should be the testbed for  
new ideas, with users trying out and choosing solutions that work  
best for them. Debian should not make that choice for users.  
Upstreams should not make that choice for Debian.


I'll second that. There has been much gnashing of teeth and talking  
about forks and pitchforks on this list. Instead of talking of  
catastrophic upheavals, such as systemd or forking, why not talk of  
refreshing/refurbishing/maintaining sysvinit and other existing  
systems? After all, we probably wouldn't be dealing with this hot  
systemd potato now had sysvinit been maintained intensely, actively,  
and with adequate manpower through all these years. Instead, it has  
been left more or less bitrotting on savannah (kudos to the few  
maintainers working on it despite the hostile stance of the Linux  
community), and this major upheaval is now the result.




This is official Debian Policy but some people seem upset about it.


Exactly. Instead of all the ire, sysvinit  alternatives are in dire  
need of some love. Instead of reinventing the square wheel, much of  
this misguided energy could be directed toward patching up the old  
wheels which, after all, had been serving us -- and serving us well --  
for the last 20 years.


I hope this just a misunderstanding that gets cleared up after the  
dust settles and everyone starts talking again, instead of just  
yelling at each other.


Ditto. I hope some defectors come back to Debian and realize that if  
they give Debian/upstream packages some work, many bitrotten packages  
may be reinstated into Debian main, without having to make a blend/fork  
or whatever. For the benefit of us all.


So, what would you all propose?  For a server?  Or for a user  
desktop?

Or something that fulfills both scenarios?  And why?


We all should be able to propose our ideal solution with a reasonable  
expectation that if it's a good idea, and somebody does the work, it  
could be adopted and help other people, without being unduly hindered  
by a software bundle laying exclusive claim to PID 1.


1. Reviving the existing init systems. Modernizing them, making them  
into true, interchangeable drop-in replacements of each other, which do  
the task assigned, and do it well. Each of them accomplishing at least  
the common subset of tasks an init system is supposed to provide.


2. Complementing them with existing or new tools (again, drop-in  
interchangeable replacements of each other) which build on them and  
provide the next layer. For example, the kernel autofs facility  
provides very nice automounting and could be deployed to the majority  
of desktop installs (instead of being just an optional package, as it  
is now), thus making the various automount daemons of the various  
desktop environments/file managers virtually superfluous. As a further  
example, the former udev (prior to being merged into systemd) has  
already been forked and could/will serve us well for years to come. And  
so on.


We don't need another Windows,
We don't need to know the way /home
All we want is life beyond the Thunderdome


--
Kinda regards,
my beast washes

Klistvud  
http://bufferoverflow.tiddlyspot.com
Certifiable Loonix Oozer #481801 Please reply to the list, not to  
me.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416138037.11318.0@compax

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Joel Rees

I have been informed off-list that some might misinterpret something I
wrote here, so I will attempt to clarify a few things.

On Fri, Nov 14, 2014 at 8:59 AM, Joel Rees joel.r...@gmail.com wrote:
 On Thu, Nov 13, 2014 at 11:04 PM, Tanstaafl tansta...@libertytrek.org wrote:
 On 11/12/2014 5:18 PM, Andrei POPESCU andreimpope...@gmail.com wrote:
 On Mi, 12 nov 14, 15:43:09, Tanstaafl wrote:

 Sounds good to me, but in reality, since the default *and only* init
 system for the last very many years was Sysvinit (this extremely salient
 point seems to be completely and totally lost on the systemd
 proponents), I think only systemd and sysvinit need to be there... but
 allowing for additions once required bugs implementing them are resolved
 as fixed.

 You're forgetting about:

 It doesn't matter Andrei...

 1. The *default* is what we are discussing.

 The *default* for Debian has been sysvinit since - forever?

 2. The systemd proponents pushed to make systemd the *new* default - a
 massively major change from *all* previous releases since... forever?

 3. A bug was opened to allow for the ability to allow a clean install to
 be performed with systemd on wheezy, while sysvinit was still the default.

 It should have been made mandatory that the systemd folks get this bug
 fully resolved and functional *on wheezy*, *and* commit to maintaining
 this ability in jessie, as a pre-condition to even getting the question
 of a change of the default init system for jessi on the ballot.

 Anything else, as I said, makes no sense.

 To explain to the systemd advocates who refuse to understand the
 engineering questions, this is the real engineering mistake in
 systemd.

 The engineering question keeps getting sidetracked by people who
 assert that we are talking about technical details, and then proceed
 to question (foolishly) the necessity of modularity, or (rightly) the
 meaning of modularity, etc. That all was and is still relevant, but if
 proper engineering principles had been followed in bringing systemd
 in, the open development practices our larger community claims as its
 reason for existence would have taken care of the technical details.

 Maybe it would help if I said, engineering management, instead of
 just engineering, although you really can't separate management from
 engineering.

This person says that I have misrepresented the Fedora community's
reaction in my description of events.

This is not an attempt to be a linear history of systemd adoption in
Fedora. It is simply intended as a few of my observations there when I
was a user, and from here in the two years since I left.

 It was clear much longer than four years ago how deeply the changes
 would effect the infrastructure which defines the system, and on which
 the stability of the system depends. Every daemon package would be
 effected, even if the systemd project had restrained themselves to
 working only on the init part of the infrastructure. Every daemon
 package needed to be fixed to the new interface, and tested under it.
 (Many still need that.)

This is not disparaging, it is acknowledging reality. If I were to
develop an alternative init, add full daemon/service management, tie
it to device management, login management, error logging, etc., the
result would impose the same level of re-implementation and testing
burden across the OS.

I wouldn't do it that way, of course, but that's the level of
engineering cost the approach they take incurred.

 They didn't, of course they didn't,

... restrain themselves, that is.

 they've admitted many times that
 the init system was not their ultimate target.

Links to Poetterings blog have been posted. It's hard to assume that
he was intending to speak in the absurd, or that he was
misrepresenting the goals of the project he leads.

 Therefore, every package that uses or provides authentication got
 entangled in the changes and needed both careful editing and extensive
 testing. The testing is still to be completed, because we are not
 talking about context-free grammar simplicity here in any of the
 parts.

I know that the systemd proponents want to claim that testing is
almost finished, but, hey, we all know how it is when we tell them
that the project is 90% complete. It's 90% of what we can see, and
more than half the time we aren't seeing anything close to the real
extent of what remains. Top-down was supposed to fix that, objects
were supposed to fix that, declarative programming was supposed to fix
that, but programming projects tend to be like cave systems. The more
we get done, the deeper we dig, the more we discover has to be done
before we are finished.

This is one of the very reasons for the existence of open source
software, that we can decide, when it is our own project, this is
where we stop for now. But just because we stop doesn't mean we are
finished.

I know the systemd proponents really want the job to be mostly
complete, and most of what they see is mostly complete. It's

Re: Anyone having troubles with autofs and NTFS formatted drives on Jessie/sid ?

2014-11-16 Thread Reco

 Hi.

On Sun, 16 Nov 2014 12:42:31 +0100
Thierry Rascle thier...@free.fr wrote:

 The automounting used to work for all of the entries, but now does not
 for the three entries with -fstype=ntfs.

Install ntfs-3g, replace

-fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/ikki jacala

with

-fstype=fuse,gid=46,dmask=002,fmask=113 :ntfs-3g#/dev/ikki jacala


You're using in-kernel NTFS implementation which was feature-incomplete
10 years ago and hasn't developed ever since.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141116161836.61724982c073ecf589f84...@gmail.com

Re: Installing an Alternative Init?

2014-11-16 Thread The Wanderer

On 11/16/2014 at 05:58 AM, Brian wrote:

 On Sat 15 Nov 2014 at 19:31:27 -0500, The Wanderer wrote:
 
 On 11/15/2014 at 07:21 PM, Paul E Condon wrote:
 
 Yet another topic: It should be possible to install systemd on a
 system that already has some other init system installed on it.
 This should be tested, but how?
 
 If I understand what you mean by install systemd, then it's
 trivial:
 
 apt-get install systemd
 
 That does not switch the active init system to be systemd. Doing
 *that* would require:
 
 apt-get install systemd-sysv
 
 and even that, in its turn, does not (automatically?) remove
 sysvinit-core from the system; you can still boot to it (from a
 backup-installed location) with a kernel command line option, as a
 fallback if systemd does break something too badly to even boot.
 
 systemd-sysv and sysvinit-core are not co-installable and this is
 expressed in the Conflicts: for both packages. Installing one
 results in the other being removed.

You're right. I misinterpreted which functionality was provided by which
package.

The backup copy of sysvinit's init binary is provided by the sysvinit
package, not by the sysvinit-core package. I was confused by this
because A: the word core seems to imply that the core functionality of
the thing being packaged is present in that package, and B: the sysvinit
package's description claims that if you have systemd working fine, you
can safely remove that package - which I read as implying that the
actual sysvinit init binary must not be in the sysvinit package, because
otherwise it would not be safe to remove it.

I've figured out the real story again now, and I agree that there's a
logic to it; it just wasn't sufficiently intuitive for me last night for
some reason.

-- 
   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: Installing an Alternative Init?

On Sb, 15 nov 14, 21:25:01, Marty wrote:

 I don't think Debian (or FOSS, for that matter) was ever about a
 winner-take-all approach to software choice. That seems to have originated
 in the commercial distributions, which have a financial interest in a)
 controlling users and b) controlling costs. I don't think that philosophy
 was ever part of Debian in the past.

My mental image about Debian and FOSS is more of an eco-systemd, where 
survival of the fittest applies.

 I had thought that all it takes is one
 interested maintainer to keep a package alive in Debian.

... with enough time and skill and...

 You might also be simplifying the problem. Software entanglement is a
 complex technical problem. There's a reason it's regarded as lock-in,
 because it's a technical cage that can be hard to break out of. It herds
 users in one direction, so the popularity issue is not only irrelevant, but
 misleading.
 
 I don't think there is a direct relationship between the number of users of
 alternate software, and the importance of maintaining it. I would say it's
 more of an opposite relationship, if user choice is valued. As less people
 use locked-out alternate software, those alternates arguably become more
 important to maintain to protect the choice of that minority. This of course
 presumes that user choice is still valued in Debian, which is something I no
 longer take for granted.
 
And how can this work in an environment where nobody can be forced to do 
work? Popularity and maintenance resources go hand in hand.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Installing an Alternative Init?

On Sb, 15 nov 14, 17:21:22, Paul E Condon wrote:
 
 Another topic:
 My reading of the man page for apt-get seems to say that there
 is no way to purge the configuration file of packages that were pulled
 in to satisfy a dependency and subsequently autoremoved. I hope this
 is an artifact of poor use of English. But if true, it should be fixed.

apt-get --purge autoremove

I agree it's not obvious from the manpage, so a minor bug could make 
sense.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Installing an Alternative Init?

On Du, 16 nov 14, 15:32:58, Andrei POPESCU wrote:
 
 My mental image about Debian and FOSS is more of an eco-systemd, where 
 ^^
 survival of the fittest applies.
 
That typo is just too funny :p

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: If Not Systemd, then What?

2014-11-16 Thread Nuno Magalhães

On 2014-11-16 11:40, Klistvud wrote:
 1. Reviving the existing init systems. Modernizing them, making them
 into true, interchangeable drop-in replacements of each other, which do
 the task assigned, and do it well. Each of them accomplishing at least
 the common subset of tasks an init system is supposed to provide.
 
 2. Complementing them with existing or new tools (again, drop-in
 interchangeable replacements of each other) which build on them and
 provide the next layer. For example, the kernel autofs facility provides
 very nice automounting and could be deployed to the majority of desktop
 installs (instead of being just an optional package, as it is now), thus
 making the various automount daemons of the various desktop
 environments/file managers virtually superfluous. As a further example,
 the former udev (prior to being merged into systemd) has already been
 forked and could/will serve us well for years to come. And so on.

+1 for being reasonable and making sense

It's an approach that would keep a lot of people happy and, more
importantly (at least to me), it gives the user choice instead of taking
it away. At least this way each user could choose the loosely-coupled
components s/he wanted.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5468ac54.6040...@eu.ipp.pt

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sb, 15 nov 14, 11:37:14, Miles Fidelman wrote:
 
 For some (many?) of us, systemd represents no gain, and significant
 operational impact (time required to deal with changes).

Have you considered, just for a fraction of a second, that a migration 
to systemd, however painful it may prove, could in fact make your setup 
much more reliable and understandable?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Installing an Alternative Init?

2014-11-16 Thread Ludovic Meyer

On Sat, Nov 15, 2014 at 09:25:01PM -0500, Marty wrote:
 On 11/15/2014 07:45 PM, Ludovic Meyer wrote:
 On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote:
 On 11/11/2014 02:16 PM, Brian wrote:
 On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote:
 
 On 11/11/2014 12:07 PM, Laurent Bigonville wrote:
 
 There are no functional differences between an installation with
 sysvinit-core out of the box or an install where sysvinit-core is
 installed later, this is a fact.
 
 Allowing the user to choose this at install time from the interface is
 a nice to have feature (wishlist bug) not a RC bug like you were
 claiming earlier.
 
 There is a potential practical consequence of not advertising an
 init alternative during setup. It makes users less likely to be
 aware of it, or even aware that the init system has changed.
 
 New users do not need to be be aware of all the background to the
 choosing of a default init. No advertisement is needed. By definition,
 they do not care. They want Debian. Please let them have it.
 
 They will not care by definition only if they are not aware of the
 change, and most won't be aware unless they are informed during the
 installation.
 
 They won't know they lost the choice they didn't know they had. Capisce?
 
 What choice have they lost?
 
 They lost an *informed* choice. I think the installation program
 should not take sides but just inform the user. A choice that the
 user is not aware of is the same as no choice, and is potentially
 coercive and disrespectful. It makes Debian seem partial to Red
 Hat's business plan to take over the Linux ecosystem.
 
 If you care so much about Redhat code, maybe you should document
 yourself, and see there pay coders for glibc, gcc, the kernel ( a
 ton of them, according to lwn and linux fundations reports ), on
 coreutils, gnome, kde, php, python, openssh, etc, etc.
 
  Whatever it was, it didn't exist as you imply
  in Wheezy.
 
 It wasn't an issue in Wheezy because the default init option had not
 changed from the previous release, and any release before that.
 
 They won't know, that is, until it bites them somewhere down the
 line. Then they won't know where to look or who to blame, and will
 blame Debian.
 
 What bites them?
 
 Individually, probably something that requires sysvinit or one many
 core services that got replaced. Collectively, getting trapped by
 vendor lock-in.
 
 You keep using those words, but you do not seems to use them correctly.
 If the same system is present on more than one distributio, that's not
 vendor lock-in since you can switch distribution and then reuse the same
 system.
 
 I meant that one vendor seeks to control the Linux ecosystem.
 Whether that plan is viable or even sane, is another issue, but I am
 not eager to see if their plan will succeed or be a guinea pin in
 the experiment.
 
 (I would like to see systemd succeed in Debian, however, *without*
 sacrificing modularity or user choice. That would be like embrace
 and extend in reverse, and could serve to protect downstreams.)
 
 Being tied to one package format ( and so on the ecosystem around ) would
 be true lock-in. And no one complained that much since Debian existed,
 despites the .deb having a few shortcomings at start, shortcomings that
 were fixed later such as having checksum of installed software, a feature
 rpm had at a time the dpkg didn't ( around 2002, so that's really a old 
 stuff ).
 
 In both cases it could be the result of users being steered to the
 default init by the installation program, leaving alternatives to
 rot.
 
 Alternatives will rot if no one use them, so either you recognize than
 no one is interested to use them and it will indeed rot,
 or that the few interested to use them are unable to fill bug reports and
 help the alternatives survives.
 
 Given that a reading of the archives here show less than 50 people by a
 large margin complaining on this list, I would indeed see that as a minority.
 
 ( as I hope there is more than 100 000 to 1 million Debian users, since
 Ubuntu speak of 20 millions, Fedora speaking around 2 or 3 millions. But that
 doesn't matter, since 100 000 or 1 million, there would still be far less 
 than 1%
 of the user base ).
 
 I don't think Debian (or FOSS, for that matter) was ever about a
 winner-take-all approach to software choice. That seems to have
 originated in the commercial distributions, which have a financial
 interest in a) controlling users and b) controlling costs. I don't
 think that philosophy was ever part of Debian in the past. I had
 thought that all it takes is one interested maintainer to keep a
 package alive in Debian.

You are incorrect, on several point. First, it would be totally stupid to 
want to control users when you give them the source code, way to build it
and the legal right to do what they want with it ( modulo GPL restrictions ). 
You can still use the software after you stop paying for it in commercial 
distribution, 
so if the goal is to control

Re: Anyone having troubles with autofs and NTFS formatted drives on Jessie/sid ?

2014-11-16 Thread Thierry Rascle

Hi,

Thank you very much for your help.

Replacing
ikki-fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/ikki
with
ikki-fstype=fuse,gid=46,dmask=002,fmask=113 :ntfs-3g#/dev/ikki
solved the problem.

ntfs-3g was already installed on my system.

Regards.

Thierry

On Sun, 16 Nov 2014 16:18:36 +0300
Reco recovery...@gmail.com wrote:

  Hi.
 
 On Sun, 16 Nov 2014 12:42:31 +0100
 Thierry Rascle thier...@free.fr wrote:
 
  The automounting used to work for all of the entries, but now does not
  for the three entries with -fstype=ntfs.
 
 Install ntfs-3g, replace
 
 -fstype=ntfs,gid=46,dmask=002,fmask=113 :/dev/ikki jacala
 
 with
 
 -fstype=fuse,gid=46,dmask=002,fmask=113 :ntfs-3g#/dev/ikki jacala
 
 
 You're using in-kernel NTFS implementation which was feature-incomplete
 10 years ago and hasn't developed ever since.
 
 Reco
 
 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116151422.645eafe4@akela.localdomain

Re: If Not Systemd, then What?

2014-11-16 Thread Ansgar Burchardt

Hi,

Nuno Magalhães nunomagalh...@eu.ipp.pt writes:
 On 2014-11-16 11:40, Klistvud wrote:
 1. Reviving the existing init systems. Modernizing them, making them
 into true, interchangeable drop-in replacements of each other, which do
 the task assigned, and do it well. Each of them accomplishing at least
 the common subset of tasks an init system is supposed to provide.
 
 2. Complementing them with existing or new tools (again, drop-in
 interchangeable replacements of each other) which build on them and
 provide the next layer. For example, the kernel autofs facility provides
 very nice automounting and could be deployed to the majority of desktop
 installs (instead of being just an optional package, as it is now), thus
 making the various automount daemons of the various desktop
 environments/file managers virtually superfluous. As a further example,
 the former udev (prior to being merged into systemd) has already been
 forked and could/will serve us well for years to come. And so on.

 +1 for being reasonable and making sense

 It's an approach that would keep a lot of people happy and, more
 importantly (at least to me), it gives the user choice instead of taking
 it away. At least this way each user could choose the loosely-coupled
 components s/he wanted.

Nobody is stopping anybody from improving sysvinit if they want to. So,
have fun hacking on it. ;)

Ansgar


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761efp6ka@deep-thought.43-1.org

Re: Installing an Alternative Init?

2014-11-16 Thread Ludovic Meyer

On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
 Marty wrote:
 On 11/15/2014 07:45 PM, Ludovic Meyer wrote:
 On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote:
 On 11/11/2014 02:16 PM, Brian wrote:
 On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote:
 
 On 11/11/2014 12:07 PM, Laurent Bigonville wrote:
 
 There are no functional differences between an installation with
 sysvinit-core out of the box or an install where sysvinit-core is
 installed later, this is a fact.
 
 Allowing the user to choose this at install time from the
 interface is
 a nice to have feature (wishlist bug) not a RC bug like you were
 claiming earlier.
 
 There is a potential practical consequence of not advertising an
 init alternative during setup. It makes users less likely to be
 aware of it, or even aware that the init system has changed.
 
 New users do not need to be be aware of all the background to the
 choosing of a default init. No advertisement is needed. By definition,
 they do not care. They want Debian. Please let them have it.
 
 They will not care by definition only if they are not aware of the
 change, and most won't be aware unless they are informed during the
 installation.
 
 They won't know they lost the choice they didn't know they
 had. Capisce?
 
 What choice have they lost?
 
 They lost an *informed* choice. I think the installation program
 should not take sides but just inform the user. A choice that the
 user is not aware of is the same as no choice, and is potentially
 coercive and disrespectful. It makes Debian seem partial to Red
 Hat's business plan to take over the Linux ecosystem.
 
 If you care so much about Redhat code, maybe you should document
 yourself, and see there pay coders for glibc, gcc, the kernel ( a
 ton of them, according to lwn and linux fundations reports ), on
 coreutils, gnome, kde, php, python, openssh, etc, etc.
 
  Whatever it was, it didn't exist as you imply
  in Wheezy.
 
 It wasn't an issue in Wheezy because the default init option had not
 changed from the previous release, and any release before that.
 
 They won't know, that is, until it bites them somewhere down the
 line. Then they won't know where to look or who to blame, and will
 blame Debian.
 
 What bites them?
 
 Individually, probably something that requires sysvinit or one many
 core services that got replaced. Collectively, getting trapped by
 vendor lock-in.
 
 You keep using those words, but you do not seems to use them correctly.
 If the same system is present on more than one distributio, that's not
 vendor lock-in since you can switch distribution and then reuse the same
 system.
 
 I meant that one vendor seeks to control the Linux ecosystem.
 Whether that plan is viable or even sane, is another issue, but I
 am not eager to see if their plan will succeed or be a guinea pin
 in the experiment.
 
 As much as I dislike systemd, I'm not sure that it's a vendor
 conspiracy to control the Linux ecosystem.  Yes, redhat pays
 Lennart Poettering's salary (among others).  But... I'm hard pressed
 to see how turning a collection of free distros into functional
 equivalent's of redhat, or increasing the resources applied to free
 distros, is really to their benefit.  If anything, it would seem to
 dilute the competitive advantage of paid RHEL.
 
 Personally, I think it's more a matter of one, prima donna
 developer, who has the advantage of a salary, who has a vision and
 design philosophy that he's promoting in a very aggressive and
 single minded way.  And he's very overt about it.  (Somebody posted
 an email from Poettering last week saying, roughly, 'first we're
 going to get kdbus into the kernel, then we're going to make udev
 depend on it, and then everyone will have to eat systemd to get
 udev.'  As I recall, the message closed with 'gentoo, be warned.')
 
 I figure this is more a case of redhat management not wanting to
 tick off valued prima donna, and maybe seeing what he's doing as a
 contribution to the open source community (to date, redhat has been
 pretty good about contributing to the community in lots of different
 ways).  Still,  if I were in their shoes, I'd be trying to reign the
 guys in. 

Why would the management of a external company care about what 
happen in Debian ? 
People keep wanting the project to be free of corporate influence, but 
it seems that some wouldn't be against having a bit of corporate influence if 
the
influence was in the way they want..

 Given that RHEL's main selling points are enterprise
 capabilities, quality control, and (for the government market)
 security accreditation and lots of support, I'd much rather see
 diversity and weak code spread across competing distributions.

Canonical was criticized for keeping their code for their ( mir, unity ),
and Redhat would be criticized for not keeping the code only for them. 

I guess there is no good way for a company to make free software that
change something in the core of existing ecosystem.

--

Re: If Not Systemd, then What?

2014-11-16 Thread Jerry Stuckle

On 11/16/2014 6:40 AM, Klistvud wrote:
 Dne, 21. 10. 2014 04:06:23 je Marty napisal(a):
 On 10/20/2014 03:45 PM, Patrick Bartek wrote:
 After much vitriolic gnashing of teeth from those opposed to systemd,
 I wonder...  What is a better alternative?  And it can't be sysvinit.
 
 Why not? I do not see sysvinit -- or any other legacy init system, for
 that matter -- as contradicting the following:
 
 Whichever one the user wants is the best. The users should decide,
 individually and collectively. The distro should be the testbed for
 new ideas, with users trying out and choosing solutions that work best
 for them. Debian should not make that choice for users. Upstreams
 should not make that choice for Debian.
 
 I'll second that. There has been much gnashing of teeth and talking
 about forks and pitchforks on this list. Instead of talking of
 catastrophic upheavals, such as systemd or forking, why not talk of
 refreshing/refurbishing/maintaining sysvinit and other existing systems?
 After all, we probably wouldn't be dealing with this hot systemd potato
 now had sysvinit been maintained intensely, actively, and with adequate
 manpower through all these years. Instead, it has been left more or less
 bitrotting on savannah (kudos to the few maintainers working on it
 despite the hostile stance of the Linux community), and this major
 upheaval is now the result.


The problem here is lack of time and/or skills.  I would love to help,
but I already have my plate full.  Additionally, I've done device
drivers and applications, but never dealt with init systems.  There
would be a big learning curve.  And then there is the politics of being
accepted by the DD community.  Maybe some people don't think it's too
bad - but I get enough politics in real life that I don't want to deal
with it in a volunteer position.

Most of the qualified people I know are pretty much in the same position.


 This is official Debian Policy but some people seem upset about it.
 
 Exactly. Instead of all the ire, sysvinit  alternatives are in dire
 need of some love. Instead of reinventing the square wheel, much of this
 misguided energy could be directed toward patching up the old wheels
 which, after all, had been serving us -- and serving us well -- for the
 last 20 years.
 

So why, instead of spending all this time on a new init system didn't
developers already familiar with sysvinit work on it?  Systemd wasn't
one person alone.

 I hope this just a misunderstanding that gets cleared up after the
 dust settles and everyone starts talking again, instead of just
 yelling at each other.
 
 Ditto. I hope some defectors come back to Debian and realize that if
 they give Debian/upstream packages some work, many bitrotten packages
 may be reinstated into Debian main, without having to make a blend/fork
 or whatever. For the benefit of us all.
 

I don't think this is going to happen.  I know a lot of people who are
looking at another distro, or even helping with a fork.  This includes
me.  And when I find a distro I like, I won't be coming back.  The
others feel the same way.

I don't change distros very often; it's a lot of work to test new
systems before placing in production.  And then there is the learning
curve.

 So, what would you all propose?  For a server?  Or for a user desktop?
 Or something that fulfills both scenarios?  And why?

 We all should be able to propose our ideal solution with a reasonable
 expectation that if it's a good idea, and somebody does the work, it
 could be adopted and help other people, without being unduly hindered
 by a software bundle laying exclusive claim to PID 1.
 
 1. Reviving the existing init systems. Modernizing them, making them
 into true, interchangeable drop-in replacements of each other, which do
 the task assigned, and do it well. Each of them accomplishing at least
 the common subset of tasks an init system is supposed to provide.
 

That would be great, but it's not going to happen.  The TC has already
indicated systemd is going to be the default, and packages are already
beginning to require systemd.  I predict more and more packages will
require systemd as time goes on.

 2. Complementing them with existing or new tools (again, drop-in
 interchangeable replacements of each other) which build on them and
 provide the next layer. For example, the kernel autofs facility provides
 very nice automounting and could be deployed to the majority of desktop
 installs (instead of being just an optional package, as it is now), thus
 making the various automount daemons of the various desktop
 environments/file managers virtually superfluous. As a further example,
 the former udev (prior to being merged into systemd) has already been
 forked and could/will serve us well for years to come. And so on.


This would also be great.  However, who's going to spend the time
building these replacements?  Maintaining/upgrading sysvinit is minor
compared to this job, and even that couldn't be done.

 We

Re: HTML5 videos in Jessie

2014-11-16 Thread Proxy

On 2014-Nov-03 22:46, Proxy wrote:
 On 2014-Nov-02 18:36, kamaraju kusumanchi wrote:
  On Sun, Nov 2, 2014 at 7:41 AM, Proxy proxy-...@mail.ru wrote:
  
   Still doesn't work. I don't think this is related to Iceweasel version.
  
  
  That is my guess. But I also do not know which package/version could be
  triggering this problem for you.
  
  Also, did you install any extensions to the iceweasel? If so, try disabling
  them and see if you can reproduce the issue.
  
  Try running iceweasel -safe-mode and see if the problem is reproducible?
 
 Tried that just now and problem is still there.
 
  FWIW, here is the list of packages I have installed on my system
  https://drive.google.com/file/d/0B-OMw5Fsje3kQjNiSVZlM080Y1U/view?usp=sharing
 
 I'll try to compare that with my installed packages.

Couldn't find what package could be the problem.

Can anyone confirm that webm/VP8 works in Iceweasel 31.2.0 in Jessie? 

I would file a bug report, but don't know what package. I tried
downloading Firefox from mozilla.org and it behaves the same. Video
looks like it is played fast forward. 

From what I know, playing VP8 videos depends on libvpx1 package. Could
that be the problem?



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116153407.ga6...@angelina.example.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Miles Fidelman


Andrei POPESCU wrote:

On Sb, 15 nov 14, 11:37:14, Miles Fidelman wrote:

For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Have you considered, just for a fraction of a second, that a migration
to systemd, however painful it may prove, could in fact make your setup
much more reliable and understandable?




Let me also turn the question back at you:

Have you considered, just for a fraction of a second, that a migration
to systemd, could, in fact, make some systems LESS reliable and understandable?


But in answer to your question:

Sure.

For a long time, I just assumed that Jessie would be an improvement on 
Wheezy (otherwise, why release a new version), and like previous 
releases, it would be largely backwards compatible, have some bugs 
resolved, some security holes tightened, and offer some new features 
that might or might not be of interest.  To the extent that I thought 
about systemd at all, it was to the same degree as I think of any other 
core system service - it's there, it works, nothing to see here.


Then, I became aware of how many basic system services were being 
incorporated into the systemd collection of stuff, and how many other 
things it touched (like, for example, PAM - which I use extensively), 
and logging, and so on.


And then I started reading the (conflicting) documentation, such as 
there is, describing all the things I'd have to test, change, watch out 
for when it came to rebuilding our servers on top of Jessie. Followed by 
reading about the design, philosophy, approach, and agenda of its 
developers - in their own words, in their own emails, and on their own 
blogs.  And then, I started seeing the reactions of the developers and 
apologists to legitimate criticisms and concerns.


I've sat through an awful lot of design reviews for software and system 
projects, on both sides of the table, and personally, I would have 
killed this thing early in its life.  Joel Rees has this exactly right, 
this has all the signs of a death march project, not just for Debian but 
for large chunks of the Linux ecosystem.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5468c040.6040...@meetinghouse.net

Re: If Not Systemd, then What?

2014-11-16 Thread Ansgar Burchardt

Hi,

Jerry Stuckle stuckleje...@gmail.com writes:
 The problem here is lack of time and/or skills.  I would love to help,
 but I already have my plate full.  Additionally, I've done device
 drivers and applications, but never dealt with init systems.  There
 would be a big learning curve.  And then there is the politics of being
 accepted by the DD community.  Maybe some people don't think it's too
 bad - but I get enough politics in real life that I don't want to deal
 with it in a volunteer position.

If you do not have time/skill/motivation to deal with it yourself, there
is also the option of hiring someone to do the work for you.

See [1] for a list of people offering services for Debian to start
with.

  [1] https://www.debian.org/consultants/

 So why, instead of spending all this time on a new init system didn't
 developers already familiar with sysvinit work on it?  Systemd wasn't
 one person alone.

Presumably nobody was interested enough to do so.

 1. Reviving the existing init systems. Modernizing them, making them
 into true, interchangeable drop-in replacements of each other, which do
 the task assigned, and do it well. Each of them accomplishing at least
 the common subset of tasks an init system is supposed to provide.

 That would be great, but it's not going to happen.  The TC has already
 indicated systemd is going to be the default, and packages are already
 beginning to require systemd.  I predict more and more packages will
 require systemd as time goes on.

It's not going to happen, because...

 This would also be great.  However, who's going to spend the time
 building these replacements?  Maintaining/upgrading sysvinit is minor
 compared to this job, and even that couldn't be done.

... nobody wants to work on it (at least not for free).

Ansgar


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjbrkvtm@deep-thought.43-1.org

Re: If Not Systemd, then What?

2014-11-16 Thread Martin Read


On 16/11/14 11:40, Klistvud wrote:

1. Reviving the existing init systems. Modernizing them, making them
into true, interchangeable drop-in replacements of each other, which do
the task assigned, and do it well. Each of them accomplishing at least
the common subset of tasks an init system is supposed to provide.


Given the profundity of disagreement about what init systems are 
supposed to provide, I believe that this would be a Sisyphean task. 
Positions people hold on the topic include, but:


1. The init daemon should fork exactly once; in the child it should exec 
another program, while the parent (PID 1) does nothing except reap zombies.


2. As (1), except that if the initially-forked child process exits, PID 
1 should repeat the fork and exec-in-child procedure.


3. The init daemon should have a simple integrated service management 
mechanism akin to sysvinit's /etc/inittab.


4. The init daemon should have a complex integrated service management 
mechanism, perhaps akin to those of upstart or systemd.


5. The init program should do some basic setup, then exec a service 
manager daemon *within PID 1*.


Moving on from *there*, let's take a look at two of the things you 
suggest, each of which are quite reasonable in isolation.


On the one hand, making them into true, interchangeable drop-in 
replacements of each other suggests to me that you think they should 
all have exactly the same set of interfaces and functionality. I don't 
agree with this position, but it's reasonable, though it's rather 
stifling (since now you can't add new functionality unless you can 
persuade all the other init maintainers to add it).


On the other, each of them accomplishing at least the common subset of 
tasks an init system is supposed to provide suggests to me that you 
think it would be all right for some of them to have extra interfaces 
and functionality - but as soon as you allow extra interfaces and 
functionality, you no longer achieve the true, interchangeable drop-in 
replacements part.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5468c4a7.5000...@zen.co.uk

Why focus on systemd?

2014-11-16 Thread Peter Nieman

Frankly, I don't understand why so many people are focussing on systemd 
so much. In my opinion, systemd ist just a *symptom* (although perhaps a 
very prominent one). It is not the *cause* of the disease or the disease 
itself.


Has anyone ever wondered where all these funny directories like 
~/.cache, ~/.config, ~/.local or even ~/Desktop (with a capital D) came 
from that appeared in Debian after upgrading to - was it Lenny? Here's 
an answer:

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Has anyone wondered where funny files like recently-used.xbel suddenly 
came from? A file written in a format that requries *five* lines to tell 
file selector dialogs that there are no Recently Used files, and that 
is being recreated even if you don't want any Recently Used entry in 
your File open dialogs at all?


Does anyone remember when files containing entries like
SUBSYSTEM==block, ENV{ID_CDROM}==?*, 
ENV{ID_PATH}==pci-:00:02.1-usb-0:5:1.0-scsi-0:0:0:1, SYMLINK+=

cdrom1, ENV{GENERATED}=1
suddenly appeared under /etc/... and when countless people started 
complaining in mailing lists about incorrect loading of devices?


What I am trying to say is that the same kind of people who graciously 
donated systemd to all of us without asking have been shaping our 
systems for a long time already, adding bloat, cruft and obscurity and 
removing manual configurability and easy and straightforward control 
wherever they could.


It's the domination of the desktop environment ideology that's the 
problem. Many users came to Linux and Debian years ago because they were 
fed up with Microsoft. And now the same ideology infiltrates their 
Linux, whether they chose to install a desktop environment or not.


Desktop environments are made by people who lack the fantasy to imagine 
a computing world different from Microsoft's, who - just like MS - don't 
care for economical use of resources, and who believe that users don't 
need to know what's going on under the hood and that users should take 
or leave what's being given to them. In principle I don't have a 
problem with such people. But I do have a problem when they start 
shaping Debian also for the rest of us.


Preventing the systemd takeover is certainly important, but it won't be 
enough to reverse the trend, I fear.


Just my 2 Cents.

p.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/m4aggt$6a3$1...@ger.gmane.org

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)