ff9097 a écrit 637 commentaires

Seul les groupes LDAP ne sont pas supporté dans la version communautaire.

GitLab CE est effectivement vraiment libre. Le fait qu'ils mettent en avant la version entreprise c'est juste ce que font toute entreprise qui vends un produit.

Il faut quand même préciser que si la version communautaire est à ce niveau-là aujourd'hui c'est parce qu'il y a une rentré d'argent suffisante (via la version entreprise) pour payer des devs à temps plein pour avoir un développement très dynamique (une release majeure par mois environ, plusieurs versions maintenue en parallèles) et ils sont assez ouvert pour pouvoir inclure des fonctionnalités de la version entreprise à la version communautaire. (Récemment les pages)

Gitlab n'est pas vraiment libre. Tu le dis toi-même dans la parenthèse. Et tu verras que si tu as une utilisation avancée de ta forge, tu vas déchanter du « vraiment libre » Gitlab

Que veux-tu dire ?

Si systemd l'a fait c'est peut-être qu'il y avait un besoin réel

Le développeur occasionnel récupère le dépôt et fait ses corrections. Ensuite il pousse sur son dépôt public puis doit effectivement prévenir quelqu’un qu’il a fait le taf. (par mail, bugtracker…) l’intégrateur va récupérer les modifs. Si elles n’ont pas le niveau attendu, elles n’iront jamais sur le dépôt officiel. Si c’est bon, c’est l’intégrateur qui pousse sur le dépôt officiel.

Il n'y a pas besoin de mail. Lorsque le dev occ a poussé ses modifications sur une branche sur son dépôt (dépot public sur ton schema) il crée une MR/PR via l'interface web, une PR/MR est simplement une demande d'intégration d'une branche d'un dépôt forké sur une branche (en général master) du dépot officiel. L'intégrateur n'a plus qu'à lire le diff et peut accepter en un clic (ou faire des commentaires sur une ou des parties du code si quelque chose ne lui plait pas). Il y a un espace de discussion sur chaque PR/MR

Pull Request/Merge Request

Le problème du rebase c'est que tu peux être amener à devoir corriger des conflits potentiellement obsolètes (car tu appliques commit par commit) alors que le merge tu corriges une et une seule fois maximum.

Je suppose que Mozilla souhaitait que ça soit très proche peu importe les plateformes.

Avec la version communautaire seulement le merge request est permis, adieu les possibilités de rebase/squash+cherry-pick qui permettent d'avoir un historique linéaire.

Et quel est intérêt d'avoir un historique linéaire ? Rien ne t'empêche de rebase avant de merger

Pardon pour ces fautes ridicules je ne me suis pas relu et j'ai écrit depuis mon téléphone

LXDE, LXQT, XFCE c'est tellement rien comparé à KDE que la question ne se pose pas. Mais comparé à GNOME je ne sais pas c'est une bonne question

Officiellement non mais officieusement un peu quand même oui (enfin accident est un peu fort quand même). Ça ne me choque pas. Si les distributions se concentraient sur un bureau bien intégré et à jour au lieu de tout proposer le choix serait plus simple.

déjà le gain en perf n'est pas flagrant

Ça l'était bien plus avant. Sans compter le moteur de rendu mieux suporté, la meilleure stabilité grâce à la séparation des processus présent depuis très longtemps. Firefox a pas mal progressé ces derniers mois sur ces points mais ça a pris des années.

J'utilise cette distribution depuis la 21 et je n'ai jamais été aussi satisfait d'une distribution. Je la trouve stable, avec des mises à jour régulières des paquets, pas obsolètes comme ça peut l'être sous Debian stable ni trop instable comme sous Arch.
Je peux passer très souvent par l'interface graphique pour les tâches d'administrations (installation / désinstallation de logiciels graphiques, mises à jour, ajout d'imprimantes, ajout d'utilisateurs, (dé)compression, renommage de fichiers en masse… J'aime beaucoup le look en feel de GNOME et de ses applications ! L'intégration y est parfaite !
Bref que du bonheur !

Suffit de supprimer la permission au navigateur d'accéder à la webcam

l'un n'est pas mieux que l'autre et ne devrait pas être rémunéré plus que l'autre.

Ah bon c'est comme ça fonctionne dans la vie ?

J'ai eu des managers très bons, qui ne connaissaient rien en technique. Pourquoi on ne laisse pas les gens dans la technique et les managers dans le management

Personnellement j'apprécie que la boîte est privilégié de monter quelqu'un de la boîte et qui donc connait bien les process plutôt que d'aller chercher un externe. Mais je comprends tout à fait que tu ne t'y retrouve pas

modèle android : l’application décide à quoi elle a accès, tu choisis tout d’un bloc (soit tu acceptes tout, soit tu refuses tout).

Visiblement tu es encore plus en retard que Replicant

Ça marche très bien depuis plus d'un an.

Ça reste logiciel

Comme mentionné le problème des majuscules accentués n'est qu'un problème Windows car sous Linux c'est très simple…. Même si je ne conteste pas le fait que le clavier AZERTY n'est pas optimal !

Difficile de leur reprocher cela mais je suis d'accord qu'il y a un déséquilibre,et encore il y a pire qu'agenda, certaines apps sont encores à l'ergonomie Gtk2 (pas de HeaderBar par exemple). Logithèque c'est super important car c'est clairement l'avenir, Nautilus reste incontournable. Agenda ça reste utile qu'avec un compte pro configuré et le smarphone est souvent utilisé à la place.

En effet, j'ai souvent des notifications qui s'affichent puis disparaissent du menu. Si je vais afk puis reviens à mon ordinateur, je ne sais pas qu'elles se sont produites. Et cela arrive même avec des > logiciels GNOME tel qu'Evolution étonnemment.

Normalement elles s'affichent sur l'écran de verrouillage (sauf si configuré pour que non)

C'est utilisable pour autre chose que du développement GNOME ?

Je ne suis pas tellement d'accord sur ce point.
Upstart est une étape intermédiaire entre l'init traditionnel et systemd, il a permis de tester des concepts et de voir certains défauts d'architecture pour rendre systemd meilleur.

Le "fail" est peut-être sévère mais il signifit que upstart ne s'est pas imposé

N'oublions pas que Canonical n'est pas une entreprise très rentable et qu'ils ont peu de ressources humains et financiers par rapport à d'autres comme Red Hat ou OpenSuse, ils ne peuvent se permettre de gaspiller des ressources à faire ce genre de choses.

C'est pourtant l'impression qu'on a eu au vu de la liste ci-dessus

• Upstart… fail
• Unity… fail
• Mir…
• Snap…

Canonical n'est pas vraiment en réussite pour ce qui est de développer et réussir à imposer leurs solutions. Mais c'est justement par ce qu'on a toujours eu l'impression qu'il développait ça pour eux avant tout. Les ressources vont peut-être enfin être mieux utilisé