Oui, mais par la suite il explique son choix (Au cas où on s'arrêterais a la première phrase.)

"So some clarifications: obviously this was a post to make fun of the irrational systemd haters fearing a conspiracy of systemd taking over the world.

Yes, kwin_wayland uses the logind DBus interfaces. Not because I want to "depend on systemd" or $evil reason, but because logind nicely solves problems, we need to be solved and no other project is able to solve that. You don't like logind? Fine! Implement the interface and kwin_wayland will happily connect to it. Or provide and maintain patches to not use the logind DBus interfaces.

Will kwin_x11 use logind? Probably not, but Plasma 5 uses logind and this will increase. Again it solves problems no other software solves. E.g. if you want to end the lock screen with a command: possible only with logind in Plasma5. If there is a problem I need to solve for kwin_x11 and logind solves it, I will use logind."

Toute haine envers systemdOS mise de côté (merde, I might be doing it wrong ), les mainteneurs de projets qui se décident à dépendre de lui se coupent un peu de l'appellation "cross-platform". Bon, je sais qu'en pratique les environnements de bureau ne sont cross-platform que sur le papier (pour ceux qui prétendent au titre...), mais encore une fois on évolue vraiment vers un Linux "gros pâté" où tout vient avec des dépendances énormes (comme si c'était pas déjà suffisamment la merde comme ça), pas systématiquement justifiées et allant à l'encontre même de ce qu'on appelait "philosophie UNIX" à l'époque où Linux s'en inspirait encore.
Je veux dire, à une certaine époque on pouvait avoir Gnome 2 avec le WM qui nous plait, l'init qu'on voulait, la pile audio qu'on préférait etc. et ça fonctionnait très bien. Le point commun entre ces logiciels? Aucun, chacun a son rôle distinct du reste (je ne demandais pas à Gnome de gérer l'audio, mais juste de me fournir une logithèque à peu près cohérente, des fenêtres et une barre pour loger des widgets).
Donc bon, sincèrement, que ce soit justifié ou non sur le plan technique j'estime qu'on migre vers un modèle encore plus foireux que l'actuel pour l'utilisation de Linux sur desktop

Le nombre de devs Linux qui supportent systemd me sidère quand même

@JameaGourmand https://www.jeuxvideo.com/forums/1-38-7665853-2082-0-1-0-0.htm#message_7818589

Si seulement...

En réalité l'hébergement de repos Git c'est à peine la partie émergée de l'iceberg. Aujourd'hui, je dépend plus de GitHub que de Google pour te donner une idée.

GitHub c'est aussi :

• une interface web de consultation **et modification** des repos Git,
• un réseau social axé sur le développement de logiciels libres,
• une surcouche de gestions de droits sur des repos Git avec une gestion d'équipes de développement,
• un outil de collaboration interne et externe à une organisation, avec un workflow simplicime de « fork, pull request[, discuss], merge »,
• un issue tracker intégré avec brio aux repos Git,
• un outil de gestion de projet avec gestion des tâches également étroitement lié aux repos et aux issues, affectation à des équipes ou des développeurs, planification des releases futures (ça fait aussi office de roadmap du coup),
• un outil de création (et hébergement) de wikis avec gestion des droits (toujours avec la notion d'équipes et d'organisations),
• hooks de notifications sur des repos pour une floppée de services (genre trigger une build sur un service de CI, publier une release dynamiquement sur les repos d'un gestionnaire de paquets, mise à jour d'un CDN, intégration avec un outil de gestion de projet externe, etc, voir même envoyer un mail ou poster un tweet) et possibilité de configurer des hooks personnalisés.

Et pour ce que je n'utilise pas :

• un hébergeur de sites statiques avec intégration native de Jekyll,
• un générateur de pages projets logiciels avec une gallerie de thèmes prédéfinis et personnalisables.

Là c'est tout ce qui me vient à l'idée, mais la liste n'est probablement pas exhaustive. Donc non, se passer de GitHub ne se résume pas à faire un git init --bare sur son propre serveur (du moins selon le niveau d'utilisation de GitHub).

Okay, y'a certains points dans la liste où il y a des alternatives ; de façon générale GitLab et Gitosis qui sont grosso modo des équivalents libres et self-hosted. Le problème majeur de ces alternatives, c'est les collaborations externes ; au lieu d'avoir un unique compte GitHub avec le quel tu peux contribuer à **tous** les projets sur GitHub, tu dois te créer un compte sur chaque installation différente de GitLab/Gitosis et équivalents. Au lieu d'avoir O(1) comptes, t'as O(n) comptes (n étant le nombre de projets auxquels tu contribues). C'est un problème, et ça fait un bout de temps que je cogite pour y trouver une solution.

Le système de notifications externe peut être remplacé par des scripts dans des hooks Git, la différence principale étant que sur GitHub les scripts sont déjà tout prêts et installés et configurés en quelques clics via l'interface web.

L'interface de consultation des repos Git, peut être remplacée par GitWeb, la gestion des droits est excellemment couverte par Gitolite, l'issue tracker et gestion d'équipes/releases peuvent être remplacés par un Bugzilla (sans l'intégration Git je suppose), les wikis peuvent être remplacés par un simple repo Git (c'est aussi ce que fait GitHub d'ailleurs, à la différence qu'il apporte une interface d'édition web).

Bref, j'ai bien des pistes pour m'en passer, la seule fonctionnalité majeure pour laquelle je n'ai pas de solution qui me convienne c'est la simplicité du « fork, pull request[, discuss], merge » sur GitHub, et ça implique donc le fait qu'une quantité phénoménale de projets soient sur GitHub ; avoir un seul et unique workflow, une seule habitude, pour pouvoir contribuer à une telle masse de projets de projets, c'est un avantage monstre.

Même si je suis conscient des points qui peuvent pousser à délaisser Github, est-ce que ça en vaut vraiment le coup ? J'ai pas l'impression que Github soit une si grande menace que ça pour ses utilisateurs, et vu les services qu'il propose gratuitement, ça reste extrêmement 'rentable'.
Pourquoi tu tentes à tout prix de t'en débarrasser ?

@vava > Pour tes réponses d'hier : ah d'accord, je comprends mieux, merci. Je vais plutôt m'orienter vers ce que tu propose alors.
Pour l'histoire de responsabilité en cas d'accès au serveur (en supposant que rien ne me dédouane dans les CGU) : si je suis sur un mutualisé, la faute incombe à l'hébergeur dans une certaine mesure, non ? Même question pour un VPS.

Il est vrai que github offre des fonctionalités sympathiques mais personellement je n'utilise que les fonctionnalités que pourrait m'offrir un serveur basique.

Et tu peux faire de la gestion de droit avec ssh, certes moins pratique mais il suffit d'ajouter la clé ssh de tes collaborateurs et vous pouvez tous commit sur ton propre serveur.

Mais je n'ai pas dis qu'il était aisé de se débarasser de GitHub, j'utilise Bitbucket personellement mais c'est pas mieux non plus.

Sinon j'ai un léger soucis

Je me refais le projet Euler en Haskell, c'est déjà plus aisé que de le faire en mode no brain bruteforce. Ca fait déjà un moment que je suis sur le probleme 3, j'ai un code bruteforce fonctionnel mais la complexité est bien trop elevé. Le programme tourne maintenant depuis 10h et je doute qu'il finisse dans un temps respectable. J'ai donc tout recodé en mode un peu plus smart. J'ai un algorithme récursif fonctionnel (crible d'eratosthène) mais le critère que j'utilise pour sortir de la récursion me fait perdre certains nombres premiers

Je sors de la récursion quand la tête de liste au carré est supérieure à la fin de liste. Quelqu'un aurait une idée d'un meilleur critère? Je vois difficilement sans perdre en efficacité.

Voilà le code,

http://pastebin.com/fQbDhGfW

Remarque pour le problème c'est entièrement suffisant, j'aurais juste aimé construire une fonction paresseuse qui me retourne les premiers dans une liste

Ben non, c'est le meilleur critère pour sortir de ta liste. sqrt(600851475143) est le deuxième plus grand facteur de ce nombre (vu que le premier, c'est lui même). Si tu veux le faire plus vite (en théorie) tu peux commencer la liste depuis la fin (soit sqrt(600851475143) - n).

Mais bon, je l'avais fait en mode idiot, ça avait pris du temps (moins que 10 heures quand même) mais c'était fait.

Vous me faites penser que j'ai un compte GitHub mais je ne m'en sers pas à ce jour.
À côté de ça j'ai déjà déployé un GitLab sur Debian 7, c'est long et horriblement manuel (mais bon au moins j'ai un GitLab à jour ) mais le guide est clair dans les étapes donc difficile de se tromper. Et ça fournit déjà pas mal de trucs GitHub-like je trouve.

Et à la maison je me contente d'un gitweb avec un thème CSS proche de celui de GitHub, c'est trèèèès très bien comme ça

C'est officiel et indéniable : la doc d'emberjs est la meilleure doc qui soit, tous domaines confondus

Le soucis c'est que je me retrouve avec des choses comme ça,

ghci>primefactors 10
[5]
ghci>divisorsOf 10
[1,2,5,10]
ghci>primesin [2..10]
[5,7]

Il ne s'arrêtera pas tant que le premier élément sera inférieur à la racine du dernier. C'est un des soucis qui vient du fait de poser cet algorithme de manière récursive je pense.

Je l'avais fait de cette manière en Ruby et ça m'avait pris que quelques heures aussi mais là je refais en Haskell et cette approche avec un langage fonctionnel n'est limite pas fonctionelle Enfin c'est surtout la paresse d'Haskell qui pose soucis dans ce cas là.

D'ailleurs j'ai du mal comprendre, j'avais aussi lu qu'on pouvait majorer l'ensemble des facteurs premiers d'un entier par sa racine carrée mais quand je décompose 10 en facteurs premiers j'ai 5 et 2. Pourtant 2 < sqrt(10) < 5. J'ai mal compris? Ca fait longtemps que j'ai pas fait d'arithmétique

Non, tu confonds. Si tu veux savoir si N est premier, tu peux tester tout les nombres entre 2 et sqrt(N) (arrondi au nombre supérieur). Si il y a un facteur dans cette borne là, N n'est pas premier.

Sinon, il y a aussi le fait qu'un nombre composé est le produit de deux nombres premiers, comme 10 qui est le produit de 2 * 5, ou 9 qui est 3 * 3, etc.

"Je l'avais fait de cette manière en Ruby et ça m'avait pris que quelques heures"

Tu parles du crible ou du projet euler 3 ?
Parce que même en bruteforce le problème 3 prends que quelques centièmes de seconde.

Si il est mal fait, ça prends facilement quelques heures de plus...

Quelques centièmes de secondes c'est complétement impossible, on parle pas du même problème 3 je crois

Okay Knakis ça aide à affiner une approche par bruteforce mais ça ne fonctionne pas pour le crible d'erathostène.

Pour utiliser l'algorithme je dois obligatoirement avoir un sous-ensemble de l'ensemble des entiers naturels en valeur initiale, donc. Comme [2..x] par exemple, si j'ai des coupures dans ma liste initiale l'algorithme échoue. Du coup je pars avec [2..x] pourr trouve

owned by tab

pour trouver la liste des premiers entre 2 et x, sauf qu'il suffit que sqrt(x) > 2 et je n'aurais pas 2 dans ma liste alors qu'il est premier.

Ce qui me laisse penser qu'on ne peut pas implémenter le crible de manière récursive ou du moins pas aussi simplement que ça. Je pourrais partir de la fin mais le problème serait le même

Avec l'affinement par la racine le bruteforce doit être faisable sans trop de problèmes.

"Avec l'affinement par la racine le bruteforce doit être faisable sans trop de problèmes. "

Ah oui, c'est ce dont je parlais.
http://pastebin.com/Y9R950GU

C'est pas du bruteforce débile, mais la manière de tester les nombres premiers reste du bruteforce.

Ouais en effet c'est plus instant que je croyais avec l'affinement

Mais je pense pas que ce soit possible un tel bruteforce avec Haskell à cause de sa paresse, mais je vais tenter. Mon objectif n'est pas de le faire en bruteforce toutefois

Slut.
Excuser moi de vous deranger, j'ai telecharger le cd1 de Debian aveg Kde, et ca m'a mis en lancant l'installation graphique qu'il ne pouvait pas lire les fichiers, puis j'ai eu des lignes de commandes.
La ça marche avec l'inztallation normale, sachant que je n'ai pas internet, je continue d'après vous?
J'aurai bien KDE en l'installant sans reseau vu que j'ai pris le cd1 amd64 KDE?
Merci!

@Caletlog https://www.jeuxvideo.com/forums/1-38-7665853-2083-0-1-0-0.htm#message_7818618

« Même si je suis conscient des points qui peuvent pousser à délaisser Github, est-ce que ça en vaut vraiment le coup ? J'ai pas l'impression que Github soit une si grande menace que ça pour ses utilisateurs, et vu les services qu'il propose gratuitement, ça reste extrêmement 'rentable'.
Pourquoi tu tentes à tout prix de t'en débarrasser ?  »

Je suis dépendant à un service propriétaire et centralisé. L'histoire montre que ce type de service est dangereux et à éviter. J'ai beau faire relativement confiance à GitHub, je ne veux pas avoir une quelconque dépendance avec ce service.

J'ai pas l'intention de m'en débarrasser, je veux juste avoir un équivalent sur lequel j'ai le contrôle (typiquement un GitLab chez-moi, mais ça ne répond pas à tous mes problèmes), et me servir de GitHub uniquement comme mirroir.

---

Concernant ton projet et les questions légales, ça serait intéressant d'en faire un topic sur le CDSW, je pense pas être à côté de la plaque mais c'est toujours bon d'avoir plusieurs avis.

« Pour l'histoire de responsabilité en cas d'accès au serveur (en supposant que rien ne me dédouane dans les CGU) : si je suis sur un mutualisé, la faute incombe à l'hébergeur dans une certaine mesure, non ? Même question pour un VPS. »

Faut voir les conditions d'utilisations de ton hébergeur, ainsi que ton contrat. À tous les coups il y a une clause pour préciser qu'ils n'offrent aucune garantie quant à une faille causée par **ton** utilisation de leur service. À ce moment là, si tu te fais piquer un accès FTP ou SSH, c'est toi le seul responsable. Idem si ton application présente une quelconque faille qui permette d'obtenir un accès au système de fichiers. Pour le (rare) cas où la faille provient de l'hébergeur, faut voir le contrat.

Par exemple chez OVH pour un mutualisé :

« OVH ne pourra être tenu responsable envers le Client de l'introduction d'un virus informatique sur le Service du Client. »

« OVH ne saurait être tenu responsable d’une défaillance ayant pour origine une mauvaise utilisation du Service par le Client. »

Et pour les dédiés, le client est clairement défini comme total responsable du serveur.

Bref, mets des CGU qui te déchargent de toute responsabilité, les utilisateurs ne les liront pas dans tous les cas.

Mais bon, même si tu t'es couvert avec les CGU, à partir du moment où les données sont un minimum sensibles t'as intérêt à chiffrer au possible (et mieux, à laisser les gens installer l'application chez-eux). En ce moment le chiffrement c'est à la mode en plus, c'est un très bon argument marketing (même si on sait très bien qu'un simple JS compromis suffit à faire tomber cette pseudo-sécurité). Faut quand même savoir que les mémos peuvent contenir des données nominatives très privées, et ça en ferait une mine d'or pour faire du chantage si ton service venait à être très populaire.

---

« C'est officiel et indéniable : la doc d'emberjs est la meilleure doc qui soit, tous domaines confondus  »

Bof, y'a aussi les man pages BSD.

Et la doc de PHP aussi, surtout avec les exemples soumis par la communauté, j'ai jamais vu ça ailleurs et pourtant c'est tellement pratique.

@Google_Bot https://www.jeuxvideo.com/forums/1-38-7665853-2083-0-1-0-0.htm#message_7818626

Lien du thème CSS GitHub pour GitWeb ?