Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?
Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?
Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?
llgg , dans le message <qaq1ni$3i7$, a écrit :Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?
Non, c'est le passé qui essaie de se prétendre l'avenir.
llgg , dans le message <qaq1ni$3i7$1@news.gegeweb.eu>, a écrit :
Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?
Non, c'est le passé qui essaie de se prétendre l'avenir.
llgg , dans le message <qaq1ni$3i7$, a écrit :Si j'ai bien compris c'est l'avenir la technologie snap sous Linux?
Non, c'est le passé qui essaie de se prétendre l'avenir.
Je me suis un peux mal exprimé: AppImageKit permet de créer un seul
fichier-paquet-auto-exécutable. On double-clic dessus et l'application
se lance (y'a pas de copier-coller de fichiers çà et là dans le
filesystem; c'est plus qu'un simple installateur). Pour caricaturer,
tout se passe comme si les fichiers étaient dépaquetés en mémoire-RAM.
Je me suis un peux mal exprimé: AppImageKit permet de créer un seul
fichier-paquet-auto-exécutable. On double-clic dessus et l'application
se lance (y'a pas de copier-coller de fichiers çà et là dans le
filesystem; c'est plus qu'un simple installateur). Pour caricaturer,
tout se passe comme si les fichiers étaient dépaquetés en mémoire-RAM.
Je me suis un peux mal exprimé: AppImageKit permet de créer un seul
fichier-paquet-auto-exécutable. On double-clic dessus et l'application
se lance (y'a pas de copier-coller de fichiers çà et là dans le
filesystem; c'est plus qu'un simple installateur). Pour caricaturer,
tout se passe comme si les fichiers étaient dépaquetés en mémoire-RAM.
"llgg" a écrit dans le message de groupe de discussion :
qasu0l$1kvv$Je ne suis pas trop d'accord avec snap et compagnie.
Mais bon, je vais attendre de voir ce que ça donne.
Je vais radoter, mais suis personnellement pro-snap (mais j'attends aussi:
trop récent pour voir ce que ça donnera; en attendant, mettre les mains dans
la "cambouis" avec imageApp n'est pas contradictoire), car j'adhère à la
raison qui a fait que plusieurs leaders de format de paquets (*.deb zé
*.rpm) se soient entendus, avec Canonical comme fer de lance: la vraie
raison de ce format d'installation naissant, c'est le marché Linux desktop.
La création d'une norme d'installation universelle d'applications, la
définition d'un seul format qui permette de créer une seule et même
installation à destination de toute l'idiosyncrasie de chaque installation
spécifique aux us et coutumes de l'utilisation du filesystem selon chaque
distribution LinuxPOSIX-***desktop*** répond à ce fait: sur le desktop,
"Mr et Mme Michut" n'utilisent pas Linux. Ils utilisent Windows. Et ils n'y
iront pas tant qu'ils s'entendront dire qu'ils doivent apprendre à taper des
lignes de commandes. Le seul fait d'apprendre qu'ils doivent à minima
retenir s'ils seront sur une distro. pro-*.deb ou pro-*.rpm les effraient...
Snap cache l'idiosyncrasie du desktop Linux. Pour l'utilisateur final d'un
Linux-desktop, Linux apparaitra alors comme un tout homogène, en face de
Windows.
Le truc que je surveillerai d'un œil, c'est que si snap décolle (il peut
être un catalyseur de l'adoption d'un Linux-desktop par "Mr et Mme Michut"
qui n'auront plus qu'à trancher selon leur mixture de fonction
d'utilitébeauté d'un bureau), alors fatalement ce sera parce que des
scripts-shell ou que sais-je encore, bref du code-adaptateur
multi-distros-desktop sera factuellement sérialisé, et disponible par et
pour la communauté snap. Là, je basculerai vers ce format.
"llgg" a écrit dans le message de groupe de discussion :
qasu0l$1kvv$1@news.gegeweb.eu...
Je ne suis pas trop d'accord avec snap et compagnie.
Mais bon, je vais attendre de voir ce que ça donne.
Je vais radoter, mais suis personnellement pro-snap (mais j'attends aussi:
trop récent pour voir ce que ça donnera; en attendant, mettre les mains dans
la "cambouis" avec imageApp n'est pas contradictoire), car j'adhère à la
raison qui a fait que plusieurs leaders de format de paquets (*.deb zé
*.rpm) se soient entendus, avec Canonical comme fer de lance: la vraie
raison de ce format d'installation naissant, c'est le marché Linux desktop.
La création d'une norme d'installation universelle d'applications, la
définition d'un seul format qui permette de créer une seule et même
installation à destination de toute l'idiosyncrasie de chaque installation
spécifique aux us et coutumes de l'utilisation du filesystem selon chaque
distribution LinuxPOSIX-***desktop*** répond à ce fait: sur le desktop,
"Mr et Mme Michut" n'utilisent pas Linux. Ils utilisent Windows. Et ils n'y
iront pas tant qu'ils s'entendront dire qu'ils doivent apprendre à taper des
lignes de commandes. Le seul fait d'apprendre qu'ils doivent à minima
retenir s'ils seront sur une distro. pro-*.deb ou pro-*.rpm les effraient...
Snap cache l'idiosyncrasie du desktop Linux. Pour l'utilisateur final d'un
Linux-desktop, Linux apparaitra alors comme un tout homogène, en face de
Windows.
Le truc que je surveillerai d'un œil, c'est que si snap décolle (il peut
être un catalyseur de l'adoption d'un Linux-desktop par "Mr et Mme Michut"
qui n'auront plus qu'à trancher selon leur mixture de fonction
d'utilitébeauté d'un bureau), alors fatalement ce sera parce que des
scripts-shell ou que sais-je encore, bref du code-adaptateur
multi-distros-desktop sera factuellement sérialisé, et disponible par et
pour la communauté snap. Là, je basculerai vers ce format.
"llgg" a écrit dans le message de groupe de discussion :
qasu0l$1kvv$Je ne suis pas trop d'accord avec snap et compagnie.
Mais bon, je vais attendre de voir ce que ça donne.
Je vais radoter, mais suis personnellement pro-snap (mais j'attends aussi:
trop récent pour voir ce que ça donnera; en attendant, mettre les mains dans
la "cambouis" avec imageApp n'est pas contradictoire), car j'adhère à la
raison qui a fait que plusieurs leaders de format de paquets (*.deb zé
*.rpm) se soient entendus, avec Canonical comme fer de lance: la vraie
raison de ce format d'installation naissant, c'est le marché Linux desktop.
La création d'une norme d'installation universelle d'applications, la
définition d'un seul format qui permette de créer une seule et même
installation à destination de toute l'idiosyncrasie de chaque installation
spécifique aux us et coutumes de l'utilisation du filesystem selon chaque
distribution LinuxPOSIX-***desktop*** répond à ce fait: sur le desktop,
"Mr et Mme Michut" n'utilisent pas Linux. Ils utilisent Windows. Et ils n'y
iront pas tant qu'ils s'entendront dire qu'ils doivent apprendre à taper des
lignes de commandes. Le seul fait d'apprendre qu'ils doivent à minima
retenir s'ils seront sur une distro. pro-*.deb ou pro-*.rpm les effraient...
Snap cache l'idiosyncrasie du desktop Linux. Pour l'utilisateur final d'un
Linux-desktop, Linux apparaitra alors comme un tout homogène, en face de
Windows.
Le truc que je surveillerai d'un œil, c'est que si snap décolle (il peut
être un catalyseur de l'adoption d'un Linux-desktop par "Mr et Mme Michut"
qui n'auront plus qu'à trancher selon leur mixture de fonction
d'utilitébeauté d'un bureau), alors fatalement ce sera parce que des
scripts-shell ou que sais-je encore, bref du code-adaptateur
multi-distros-desktop sera factuellement sérialisé, et disponible par et
pour la communauté snap. Là, je basculerai vers ce format.
C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque.
Si je me souviens bien, c'était même l'argument ultime il y a quelques
années
pour éviter les problèmes de DLL sous windows.
Quant à l'empreinte mémoire du truc, j'en rigole d'avance. On se demandera
pourquoi il faudra 16 Go de mémoire pour > lancer la moindre distribution
Linux d'ici quelques années.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !
C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque.
Si je me souviens bien, c'était même l'argument ultime il y a quelques
années
pour éviter les problèmes de DLL sous windows.
Quant à l'empreinte mémoire du truc, j'en rigole d'avance. On se demandera
pourquoi il faudra 16 Go de mémoire pour > lancer la moindre distribution
Linux d'ici quelques années.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !
C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque.
Si je me souviens bien, c'était même l'argument ultime il y a quelques
années
pour éviter les problèmes de DLL sous windows.
Quant à l'empreinte mémoire du truc, j'en rigole d'avance. On se demandera
pourquoi il faudra 16 Go de mémoire pour > lancer la moindre distribution
Linux d'ici quelques années.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !
"JKB" a écrit dans le message de groupe de discussion :C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque.
Ce n'est pas l'avis de Linus Torvalds ***quant à Linux-desktop***.
Si je me souviens bien, c'était même l'argument ultime il y a quelques
années
pour éviter les problèmes de DLL sous windows.
Oui: on parlait de l'enfer des dlls, parce que chaque application y allait
de l'installation de sa dll supposée "shared" par dessus celle installée
pour que son appli. fonctionne... quitte à casser le fonctionnement des
autres. Et Linux est tombé dans les mêmes erreurs: le loader d'ELF de Linux
regarde dans les chemins "génériques" (un peu partout de fait de
l'idiosyncrasie des distro. Linux-desktop. Ensuite, il regarde les
registrations des librairies.
==> le loader d'ELF sous Linux nécessiterait une évolution qui le rendrait
aussi pratique que Windows du point de vue des développements desktop, à
savoir regarder en priorité d'abord dans le même répertoire que
l'application chargée, si la librairie "NEEDED" ne s'y trouverait pas, par
le meilleur des hasards (avant d'aller voir dans )!!! La majorité des
applis-desktop Windows installent leurs dll juste à côté de l'exécutable
maintenant: ça n'est pas pour rien. Du coup, Linux-desktop a du retard quant
à la compréhension de l'utilisation simplifiée des librairies.
Le problème, c'est que si "monsieur Michut" achète un desktop-Linux, il se
fout complètement de l'administration zé des administrateurs: c'est *son*
ordinateur. Il veut pouvoir y installer facilement des logiciel pour éditer
des fichiers, écouter de la musique, voir des vidéos, et naviguer sur
internet. system.d, il s'en fout comme de l'an 40 (vu qu'on est le 8 mai)
==> il veut installer un logiciel pour Linux-desktop. Point barre.
Quant à l'empreinte mémoire du truc, j'en rigole d'avance. On se demandera
pourquoi il faudra 16 Go de mémoire pour > lancer la moindre distribution
Linux d'ici quelques années.
Les programmeurs chargent et déchargent les dll, créent et détruisent les
objets, selon les besoins contextuels des fonctionnalité demandé par
l'utilisateur. Toutes les fonctionnalités ne sont jamais chargées en même
temps en mémoire.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).
L'empaquetage Debian ou Red-hat continuera; Mais là, ça deviendra un
empaquetage pour l'installation de l'OS-même, ou pour des paquets très
orientés shell. Bref, des paquets d'administration que "monsieur Michut"
voit défiler quand il accepte de mettre à jour son desktop-Linux.
Concernant Snap, les dépendances sont également correctement gérées. Mais
elles restent à 90% dans le
/home/.MrMichut/tous-les-fichiers-nécessaires-à-l-appli.
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.
Des machines *nix-desktop? Ouah!!? Vous travaillez sous quelles
distro.-desktop dans votre entreprise? Quand tu veux installer une
application pour retoucher une image, tu peux le faire sans attendre 3 jours
que ton administrateur ait terminé l'écriture de son script d'admin., ou sa
migration du serveur de BDD de l'entreprise, ou...?
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !
De telles applis existent déjà, sont téléchargeables depuis le logithèque
d'Ubuntu d'ailleurs (je viens de vérifier: Canonical a intégré son
snap-store dans la logithèque; c'est transparent sur cette distro.) ==> Gimp
n'a pas besoin de 32 Go de mémoire. Et "Mr Michut" n'installe pas une
serveur de BDD sur son poste. S'il le fait, alors il est conscient ou on lui
fera vite comprendre qu'il va devoir acquérir des compétences de DBA pour
PostgreSQL, MS-SQL (qui est maintenant disponible sous Linux), ou Firebird.
Mais dans ce cas, ça veut dire qu'il a décidé de s'intéresser à
l'informatique côté "cambouis", et non plus de rester dans la catégorie
simple consommateur multi-média.
"JKB" a écrit dans le message de groupe de discussion :
slrnqd56mm.did.jkb@rayleigh.systella.fr...
C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque.
Ce n'est pas l'avis de Linus Torvalds ***quant à Linux-desktop***.
Si je me souviens bien, c'était même l'argument ultime il y a quelques
années
pour éviter les problèmes de DLL sous windows.
Oui: on parlait de l'enfer des dlls, parce que chaque application y allait
de l'installation de sa dll supposée "shared" par dessus celle installée
pour que son appli. fonctionne... quitte à casser le fonctionnement des
autres. Et Linux est tombé dans les mêmes erreurs: le loader d'ELF de Linux
regarde dans les chemins "génériques" (un peu partout de fait de
l'idiosyncrasie des distro. Linux-desktop. Ensuite, il regarde les
registrations des librairies.
==> le loader d'ELF sous Linux nécessiterait une évolution qui le rendrait
aussi pratique que Windows du point de vue des développements desktop, à
savoir regarder en priorité d'abord dans le même répertoire que
l'application chargée, si la librairie "NEEDED" ne s'y trouverait pas, par
le meilleur des hasards (avant d'aller voir dans )!!! La majorité des
applis-desktop Windows installent leurs dll juste à côté de l'exécutable
maintenant: ça n'est pas pour rien. Du coup, Linux-desktop a du retard quant
à la compréhension de l'utilisation simplifiée des librairies.
Le problème, c'est que si "monsieur Michut" achète un desktop-Linux, il se
fout complètement de l'administration zé des administrateurs: c'est *son*
ordinateur. Il veut pouvoir y installer facilement des logiciel pour éditer
des fichiers, écouter de la musique, voir des vidéos, et naviguer sur
internet. system.d, il s'en fout comme de l'an 40 (vu qu'on est le 8 mai)
==> il veut installer un logiciel pour Linux-desktop. Point barre.
Quant à l'empreinte mémoire du truc, j'en rigole d'avance. On se demandera
pourquoi il faudra 16 Go de mémoire pour > lancer la moindre distribution
Linux d'ici quelques années.
Les programmeurs chargent et déchargent les dll, créent et détruisent les
objets, selon les besoins contextuels des fonctionnalité demandé par
l'utilisateur. Toutes les fonctionnalités ne sont jamais chargées en même
temps en mémoire.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).
L'empaquetage Debian ou Red-hat continuera; Mais là, ça deviendra un
empaquetage pour l'installation de l'OS-même, ou pour des paquets très
orientés shell. Bref, des paquets d'administration que "monsieur Michut"
voit défiler quand il accepte de mettre à jour son desktop-Linux.
Concernant Snap, les dépendances sont également correctement gérées. Mais
elles restent à 90% dans le
/home/.MrMichut/tous-les-fichiers-nécessaires-à-l-appli.
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.
Des machines *nix-desktop? Ouah!!? Vous travaillez sous quelles
distro.-desktop dans votre entreprise? Quand tu veux installer une
application pour retoucher une image, tu peux le faire sans attendre 3 jours
que ton administrateur ait terminé l'écriture de son script d'admin., ou sa
migration du serveur de BDD de l'entreprise, ou...?
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !
De telles applis existent déjà, sont téléchargeables depuis le logithèque
d'Ubuntu d'ailleurs (je viens de vérifier: Canonical a intégré son
snap-store dans la logithèque; c'est transparent sur cette distro.) ==> Gimp
n'a pas besoin de 32 Go de mémoire. Et "Mr Michut" n'installe pas une
serveur de BDD sur son poste. S'il le fait, alors il est conscient ou on lui
fera vite comprendre qu'il va devoir acquérir des compétences de DBA pour
PostgreSQL, MS-SQL (qui est maintenant disponible sous Linux), ou Firebird.
Mais dans ce cas, ça veut dire qu'il a décidé de s'intéresser à
l'informatique côté "cambouis", et non plus de rester dans la catégorie
simple consommateur multi-média.
"JKB" a écrit dans le message de groupe de discussion :C'est surtout une autre usine à gaz du type systemd qui fera que
Linux se bloatwarisera encore un peu plus. Balancer dans un paquet
le programme à installer ainsi que ses dépendances qui vont se
décompresser sur un fs lors de l'utilisation est grotesque.
Ce n'est pas l'avis de Linus Torvalds ***quant à Linux-desktop***.
Si je me souviens bien, c'était même l'argument ultime il y a quelques
années
pour éviter les problèmes de DLL sous windows.
Oui: on parlait de l'enfer des dlls, parce que chaque application y allait
de l'installation de sa dll supposée "shared" par dessus celle installée
pour que son appli. fonctionne... quitte à casser le fonctionnement des
autres. Et Linux est tombé dans les mêmes erreurs: le loader d'ELF de Linux
regarde dans les chemins "génériques" (un peu partout de fait de
l'idiosyncrasie des distro. Linux-desktop. Ensuite, il regarde les
registrations des librairies.
==> le loader d'ELF sous Linux nécessiterait une évolution qui le rendrait
aussi pratique que Windows du point de vue des développements desktop, à
savoir regarder en priorité d'abord dans le même répertoire que
l'application chargée, si la librairie "NEEDED" ne s'y trouverait pas, par
le meilleur des hasards (avant d'aller voir dans )!!! La majorité des
applis-desktop Windows installent leurs dll juste à côté de l'exécutable
maintenant: ça n'est pas pour rien. Du coup, Linux-desktop a du retard quant
à la compréhension de l'utilisation simplifiée des librairies.
Le problème, c'est que si "monsieur Michut" achète un desktop-Linux, il se
fout complètement de l'administration zé des administrateurs: c'est *son*
ordinateur. Il veut pouvoir y installer facilement des logiciel pour éditer
des fichiers, écouter de la musique, voir des vidéos, et naviguer sur
internet. system.d, il s'en fout comme de l'an 40 (vu qu'on est le 8 mai)
==> il veut installer un logiciel pour Linux-desktop. Point barre.
Quant à l'empreinte mémoire du truc, j'en rigole d'avance. On se demandera
pourquoi il faudra 16 Go de mémoire pour > lancer la moindre distribution
Linux d'ici quelques années.
Les programmeurs chargent et déchargent les dll, créent et détruisent les
objets, selon les besoins contextuels des fonctionnalité demandé par
l'utilisateur. Toutes les fonctionnalités ne sont jamais chargées en même
temps en mémoire.
Plutôt que de perdre de l'énergie à développer ce genre de chose,
autant empaqueter pour les différentes distributions. Les
dépendances sont correctement gérées (sauf dans le cas de paquets
foireux, mais c'est un problème de concepteur et non de
distribution ou de gestionnaire de paquets).
L'empaquetage Debian ou Red-hat continuera; Mais là, ça deviendra un
empaquetage pour l'installation de l'OS-même, ou pour des paquets très
orientés shell. Bref, des paquets d'administration que "monsieur Michut"
voit défiler quand il accepte de mettre à jour son desktop-Linux.
Concernant Snap, les dépendances sont également correctement gérées. Mais
elles restent à 90% dans le
/home/.MrMichut/tous-les-fichiers-nécessaires-à-l-appli.
Quand je vois ce genre de chose, je suis vraiment content d'avoir
commencé à migrer toutes mes machines critiques vers d'autres Unix.
Des machines *nix-desktop? Ouah!!? Vous travaillez sous quelles
distro.-desktop dans votre entreprise? Quand tu veux installer une
application pour retoucher une image, tu peux le faire sans attendre 3 jours
que ton administrateur ait terminé l'écriture de son script d'admin., ou sa
migration du serveur de BDD de l'entreprise, ou...?
Il est aujourd'hui quasiment impossible d'utiliser un poste diskless
sous Linux, même avec 32 Go de mémoire (!). Ça swappe dans tous les
sens ! J'imagine ce que ce sera avec de telles applications. Dans la
même situation un FreeBSD ou NetBSD s'en titre très bien avec 8Go de
mémoire. Cherchez l'erreur !
De telles applis existent déjà, sont téléchargeables depuis le logithèque
d'Ubuntu d'ailleurs (je viens de vérifier: Canonical a intégré son
snap-store dans la logithèque; c'est transparent sur cette distro.) ==> Gimp
n'a pas besoin de 32 Go de mémoire. Et "Mr Michut" n'installe pas une
serveur de BDD sur son poste. S'il le fait, alors il est conscient ou on lui
fera vite comprendre qu'il va devoir acquérir des compétences de DBA pour
PostgreSQL, MS-SQL (qui est maintenant disponible sous Linux), ou Firebird.
Mais dans ce cas, ça veut dire qu'il a décidé de s'intéresser à
l'informatique côté "cambouis", et non plus de rester dans la catégorie
simple consommateur multi-média.
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).
Dans une entreprise qui se respecte, même sous Windows, tu ne peux
pas installer un logiciel qui n'est pas explicitement autorisé par
l'adminsys. Sinon, c'est le bordel assez rapidement. Autre
argument ?
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).
Dans une entreprise qui se respecte, même sous Windows, tu ne peux
pas installer un logiciel qui n'est pas explicitement autorisé par
l'adminsys. Sinon, c'est le bordel assez rapidement. Autre
argument ?
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).
Dans une entreprise qui se respecte, même sous Windows, tu ne peux
pas installer un logiciel qui n'est pas explicitement autorisé par
l'adminsys. Sinon, c'est le bordel assez rapidement. Autre
argument ?
"JKB" a écrit dans le message de groupe de discussion :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.
"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.
"JKB" a écrit dans le message de groupe de discussion :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 sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD.
Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.
Je sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD.
Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.
Je sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD.
Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.
Le 08/05/2019 à 12:19, JKB a écrit :Je sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD.
Bon courage et merci, car ça semble plombé !
Mais je crache dans la soupe, car j'utilise FreeCAD 0.16 en appimage.
Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.
Moi aussi, mais jaune...
Le 08/05/2019 à 12:19, JKB a écrit :
Je sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD.
Bon courage et merci, car ça semble plombé !
Mais je crache dans la soupe, car j'utilise FreeCAD 0.16 en appimage.
Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.
Moi aussi, mais jaune...
Le 08/05/2019 à 12:19, JKB a écrit :Je sais bien que ce truc existe déjà. Pour info, je débuggue un truc
qui s'appelle FreeCAD.
Bon courage et merci, car ça semble plombé !
Mais je crache dans la soupe, car j'utilise FreeCAD 0.16 en appimage.
Lorsque toutes les applications desktop viendront dans ce
format, je rigolerai.
Moi aussi, mais jaune...