Fichier snap?

Le 09/05/2019 à 13:54, JKB a écrit :

J'utilise une 0.0.19 en rolling release. Il y a quelques trucs qui
m'énervent dans les éditions des esquisses intermédiaires, mais
globalement, il vaut mieux un 0.0.19 qu'une 0.0.16...

J'ai aussi la version git 1.0.19pre et je constate des progrès par
rapport à la 0.18.
Les "shape binder" (formes liées) qui te permettent de dessiner par
rapport à des arêtes existantes sont très utiles, et les clones sont
bien pratiques aussi.

Toutefois, il est souvent impossible de modifier des éléments par la
suite sans que tout parte de travers (objets qui reviennent à leur
position initiale, par exemple, quand on les réédite).

Il y a, paraît-il, une procédure pour bien faire et éviter certains
problèmes, mais à côté de cela, tu peux toujours utiliser les anciennes
procédures qui, elles, te conduisent vers ces problèmes...

En tout cas, dès qu'il s'agit de produire, je sors la version 0.16 !

Meuh non... Il paraît que ce format, c'est pour notre bien.

C'est ce qu'on verra.


--
jp willm
http://perso.orange.fr/willms/index.html

Le Thu, 9 May 2019 15:46:53 +0200,
jp willm <nicole.jeanpaul.willm@wanadoo.fr> écrivait :

Le 09/05/2019 à 13:54, JKB a écrit :

J'utilise une 0.0.19 en rolling release. Il y a quelques trucs qui
m'énervent dans les éditions des esquisses intermédiaires, mais
globalement, il vaut mieux un 0.0.19 qu'une 0.0.16...

J'ai aussi la version git 1.0.19pre et je constate des progrès par
rapport à la 0.18.
Les "shape binder" (formes liées) qui te permettent de dessiner par
rapport à des arêtes existantes sont très utiles, et les clones sont
bien pratiques aussi.

Toutefois, il est souvent impossible de modifier des éléments par la
suite sans que tout parte de travers (objets qui reviennent à leur
position initiale, par exemple, quand on les réédite).

C'est effectivement un très gros problème, mais il y a des
améliorations ces temps-ci.

Il y a, paraît-il, une procédure pour bien faire et éviter certains
problèmes, mais à côté de cela, tu peux toujours utiliser les anciennes
procédures qui, elles, te conduisent vers ces problèmes...

Quelle procédure pour éviter les problèmes ?

En tout cas, dès qu'il s'agit de produire, je sors la version 0.16 !

Je sors tout avec la rolling release. Je viens de produire un énorme
boîtier métallique avec des tas de pièces à l'intérieur pour un
amplificateur. Je n'ai pas eu de problème avec la 0.0.19 sauf avec
les mises en plan et les cotes qui changent de point d'appui...
Assez problématique, mais on arrive à sortir quelque chose en
bataillant un peu.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

"zeLittle" , dans le message <5cd1823f$0$15490$426a74cc@news.free.fr>, a
écrit :

Honnêtement, l'idée est louable: elle tente de créer des installations
***universelles*** comme sous Windows

C'est exactement le problème : c'est une technologie inventée pour
favoriser les applications fermées, distribuées sous forme binaire, et
donc qui dépendent d'une version particulière de bibliothèques. Les
applications libres (vraiment, donc celles qui sont possibles à compiler
par un tiers) n'en ont pas besoin.

Sans compter le problème technique afférent : le suivi de sécurité des
bibliothèques en question n'est plus centralisé par la distribution, il
va falloir compter par les développeurs de chaque application. Ce qui
veut dire en pratique que ça ne sera pas fait.

Gourmand, peu sécurisé et privateur de liberté : tous les inconvénients
du monde Windows amenés au monde Linux.

Non merci !

Le 09/05/2019 à 16:40, JKB a écrit :

Il y a, paraît-il, une procédure pour bien faire et éviter certains
problèmes, mais à côté de cela, tu peux toujours utiliser les anciennes
procédures qui, elles, te conduisent vers ces problèmes...

Quelle procédure pour éviter les problèmes ?

Le premier cas - le plus courant - et qui pose problème :

- à partir de l'atelier "Part", tu crées comme à l’accoutumée un "Cube
plein"

- Tu vas, comme à ton habitude héritée des versions précédentes, dans
l'atelier "Part Design"

- Tu sélectionnes une face de ce cube pour y créer une esquisse
(indépendante ou non).

- Tu veux "Créer une cavité à partir de l'esquisse sélectionnée"

Aucune cavité possible !


Procédure nouvelle :

- aller dans l'atelier "Part Design"
- créer une "Boite additive..."
- sélectionner une face et créer une esquisse
- "Créer une cavité à partir de l'esquisse sélectionnée"

Félicitation, tu as utilisé la bonne icône pour créer ton cube au départ !

Question : pourquoi n'avoir pas supprimé l'ancienne façon de créer des
volumes ?

Je n'ai pas eu de problème avec la 0.0.19 sauf avec
les mises en plan

Là, sauf exception, j'exporte en DXF et je reprends sur LibreCAD

et les cotes qui changent de point d'appui...

Assez problématique, mais on arrive à sortir quelque chose en
bataillant un peu.

On peut le dire. Mais bon, c'est une version 0.19.



--
jp willm
http://perso.orange.fr/willms/index.html

"Nicolas George" a écrit dans le message de groupe de discussion :
5cd47cec$0$20334$426a74cc@news.free.fr...

C'est exactement le problème : c'est une technologie inventée pour
favoriser les applications fermées, distribuées sous forme binaire, et
donc qui dépendent d'une version particulière de bibliothèques. Les
applications libres (vraiment, donc celles qui sont possibles à compiler
par un tiers) n'en ont pas besoin.

Sur mon poste, in fine, je ne lance que des binaires, dont des interpréteurs
(binaires aussi).

C'est juste une technologie pour avoir son application "tout en un" sur une
clé USB, ou dans son home, par simple copiercoller, et qui peut se lancer
pour peu que la personne ait un compte utilisateur.
Autre exemple: pour installer des applications /.Wine, certains installent
dans le /.Wine originel, d'autres dupliquent la totalité du /.Wine par
application installée (comme Snap ou ImageApp), pour ne pas casser ou se
faire casser leur registre.

Sans compter le problème technique afférent : le suivi de sécurité des
bibliothèques en question n'est plus centralisé par la distribution, il
va falloir compter par les développeurs de chaque application. Ce qui
veut dire en pratique que ça ne sera pas fait.

Pfff! la gestion des link name, de soname (avec une sur-couche Ripolin de
soft-symlink sur Debian & descendants), voire de versions ultra-spé.
déboguées, est quelque chose qui n'est pas du ressort d'un administrateur.
C'est du ressort du développement et dudes packagiste(s) qui travaille(nt)
avec le développement. Alors ensuite il y a derrière, globalement, deux
sortes de développement: ceux qui développent un OS, et ceux qui développent
over un OS. Les premiers créent effectivement des biblio. "shared" à l'OS,
eg d'un serveur ou de services HTTP, de base de données, etc. Les seconds
créent aussi et souvent des bibliothèques qui sont spécieuses pour des
fonctionnalités, car n'ayant rien à faire sur un serveur et qui n'ont donc
absolument pas à être dépendante du bon vouloir d'un admin-sys. car ces
librairies doivent aller dans le /home du seul utilisateur.

Un autre truc de base sous les desktop: chaque fois que le noyau GTK ou QT
est officiellement mis à jour sur une distro., il y a forcément unedes
fonctionnalités d'applis visuelles qui régressent car des widgets ont
eux-aussi des deprecated ou des régressions. LinuxUnix ne sont pas plus
omniscient ou parfait que monsieur Crosoft.

Gourmand, peu sécurisé et privateur de liberté : tous les inconvénients
du monde Windows amenés au monde Linux.
Non merci !

Gourmand: ça dépend de la programmation. Privateur de liberté: personne ne
t'oblige à installer un Snap ou un imageApp. Et personne ne t'empêche de
rester borné au package-OS Debian. On est dans un monde libre.

Ta façon de trancher revient à dire que si /usr existe, c'est parce que
certains admin-sys veulenttiennent à se rendre indispensable pout tout.
Pourquoi avec créer un /usr alors qu'il y a un /home??! Tu vois bien que
lorsque LinuxUnix a créé, il y avait des contradictions au sein même de
ceux qui l'ont imaginé... Les privateur de liberté ne sont pas forcément
toujours là de façon constante où l'on veut le voir ou le faire croire.

"zeLittle" , dans le message <5cd5715e$0$15170$426a74cc@news.free.fr>, a
écrit :

Sur mon poste, in fine, je

Ce début de phrase suffit à souligner le problème de ta position : tu ne
t'intéresses qu'à ta petite personne.

Dans une situation concurrentielle, les choix de chacun influent sur les
choix de tous. Si un produit n'a pas assez de clients, il ne sera plus
produit, et les quelques clients qui restaient ne pourront plus
l'acheter. Si un logiciel n'a pas assez d'utilisateurs, il ne sera plus
maintenu, et les quelques utilisateurs qui restaient ne pourront plus
l'utiliser.

Quand un utilisateur de logiciel libre ne trouve pas son besoin en
libre, il peut aller chercher du côté propriétaire, ou bien faire des
efforts pour faire exister une solution. Ce sont ceux de la seconde
catégorie qui font progresser la communauté. Ceux de la première
catégorie ne sont que des égoïstes profiteurs : ils bénéficient des
progrès amenés par les autres et ne contribuent rien en retour.

Snap, ses défenseurs et des utilisateurs se placent sans ambiguïté dans
la première catégorie : les profiteurs égoïstes.

"Nicolas George" a longuement réfléchi avant de répondre à ce bout de
phrase coupée:

Sur mon poste, in fine, je

Ce début de phrase suffit à souligner le problème de ta position :
tu ne t'intéresses qu'à ta petite personne.

Ouaip.
Simple texte tronqué donc, et attaque ad hominem sans répondre techniquement
sur Snap, Snapcraft, ou AppImage (bref, quid des format d'application plus
ou moins portable développés pour Linux. permettant d'installer et de lancer
des applications sans même parfois devoir accès aux droits de
super-utilisateur, tout en ne mettant pas en danger le poste).

Mon tout petit Nicolas, des tas de personnes installent maintenant des
logiciels sous Ubuntu desktop, sans se souvenir préalablement qu'ils doivent
te demander ta permission, ni respecter ton analyse à deux balles de l'O/D
de softs privés à Open source ceretis paribus ou inversement, vu les
banalités de tes leçons de morales probablement dues à tes privilèges
d'administrateur qui claque des dents à la seule idée de penser que l'on
puisse se passer de ses services égoïstes.

On Wed, 8 May 2019 13:59:16 +0200
"zeLittle" <noreply@noreply.invalid> wrote:

"JKB" a écrit dans le message de groupe de discussion :
slrnqd5b8u.did.jkb@rayleigh.systella.fr...

>
> Et ne peut-on pas s'inspirer du fonctionnement des BSD ? Ah non,
> c'est pas libre et c'est trop simple. Dans les BSD, le chemin des
> bibliothèques est dans le fichier exécutable. Ça évite ce genre de
> conneries (comme le segfault bien connu lorsqu'un exécutable utilise
> deux versions de la même bibliothèque, l'une chargée par
> l'exécutable et l'autre en tant que dépendance d'une autre
> bibliothèque).
>

Et bien +1 à BSD. Debian ferait bien de s'en inspirer alors.

Je déterre ce sujet, car l'affirmation sur BSD est fausse.
Le Loader d'Elf de BSD et de Linux sont les mêmes, même s'ils sont maintenus par des gens différents. Mais globalement, quand l'un subit une modification, l'autre se la voit copiée peut après. Les 2 ne regardent pas dans "."
Ces 2 loaders ne bougent pratiquement plus.

==> Cf. https://forums.freebsd.org/threads/legend-or-truth-concerning-the-librariess-loader.71276/

C'est d'ailleurs pour ça que certains ont créé un utilitaire patchelf utilisé dans la communauté POSIX, pour écrire en relatif par rapport à l'emplacement de l'ELF-exécutable, des chemins de recherches de librairies comme "." ou ".bin", etc, où il peut aussi rechercher des librairies NEEDED dans /usr,/etc...

On Tue, 30 Jul 2019 12:30:31 +0200
zeLittle <noreply@noreplay.invalid> wrote:

==> Cf. https://forums.freebsd.org/threads/legend-or-truth-concerning-the-librariess-loader.71276/
[SNIP]

.../... des chemins de recherches de librairies comme "." ou "./bin" par ex., où il peut aussi aller rechercher des librairies NEEDED comme dans les chemins canoniques que sont /usr/lib, etc.