ntimeu a écrit 21 commentaires

Sinon, pour info, on a créé la balise href, c'est pour que les liens ne se retrouvent pas
en bas, ça fait tellement années 80s

Heu, j'ai un doute mais c'est pas du markdown l'éditeur de DLFP ? (donc pas de href à placer)

Je suis triste également pour les personnes, toujours incapables de prononcer ou d'écrire
« GNU », système GNU, ou GNU/Linux… et encore plus pour celles qui sont incapables de
prononcer ou d'écrire « logiciel libre »

Boh alors ça, ça n'est pas un gros problème pour moi (ça n'est que mon opinion, vous avez le droit de pas être d'accord).

combien de libristes pour combien de "gratuitistes" dans les utilisateurs?

+1, la plupart des personnes utilisent des logiciels libres parce que "ça coûte cher de payer la licence du logiciel proprio équivalent". Ou encore "j'utilise LibreOffice parce que mon crack pour Office marche plus".

J'ai passé mon Firefox en version 40 hier (sous windows), et ça a supprimé mon extensions. Un simple passage sur le site de l'EFF, je récupère l'extension une nouvelle fois et là elle reste installée. Donc aucun problème pour les non signées !

Ce que je préfère dans Gogs :

• aucune dépendance sur des librairies externes (vu qu'il est écrit en Go, toutes les libs sont compilées en statiques dans le binaire)
• léger (~10 Mo de RAM utilisé au repos)
• rapide (selon le CPU évidemment)
• possède une grande partie des features intéressantes de Github (exception faite des wikis et des PR, mais les forks fonctionnent), webhooks,
• simple et intuitif à utiliser

Bref, voilà pourquoi je conseille Gogs (encore en développement actif, mais avance bien et ne plante pas).

Gogs est un équivalent à Github mais auto-hébergé, avec peu de dépendances (et très simple à installer). Dépôts privés et publiques à la clé.

il faut savoir si chacun des appels systèmes que tu utilise fait parti ou non du groupe que tu autorise.

Les "groupes" d'appels systèmes de tame(2) semblent assez bien faits et rassemblent les syscalls de la bonne façon (par exemple le flag TAME_CPATH rassemble les syscalls qui permettent de créer des fichiers/dossiers/liens symboliques). Donc à moins d'utiliser un syscall à la signification obscure, tu n'auras pas souvent ce problème (et dans ce cas,
man 2 tame
Et une recherche te donne le groupe du syscall.

Si seccomp groupait les syscalls tu pourrais utiliser des « policies » identiques.

C'est exactement ce qui a été proposé dans les commentaires de l'article sur LWN.net. Il y a eu proposition pour développer une bibliothèque équivalente au syscall tame(2) avec les mêmes fonctions/fonctionnalités/interface se basant sur seccomp pour gérer les syscalls. Je trouve que c'est une super idée.

il faut quand même déterminer ce qu'on veut autoriser le programme à faire ou non.

Alors en fait pas vraiment, si tu sais que ton programme a besoin d'accéder au système de fichiers, tu demandes à tame(2) d'autoriser l'utilisation des syscall travaillant sur le système de fichiers (avec distinction READONLY, WRITEONLY, RW). Si tu as besoin du réseau, tu demandes à tame(2) d'autoriser les syscalls pour l'accès réseau, etc.

Pour la distinction entre l'initialisation et la boucle principale c'est un peu plus compliqué mais on pourrait imaginer une « policy » seccomp ou autre qui n'est activée qu'après un fork() par exemple.

Côté Linux, ça pourrait être fait, mais côté OpenBSD je ne pense pas qu'il y ait grand chose de fait à la base (seccomp n'existe pas dans OpenBSD). Le principe, c'est de dire :

• je lance un programme
• ce programme effectue toutes ses opérations privilégiées à ce moment, et ne les fera plus
• il appelle tame(2) pour réduire ses capacités au strict nécessaire pour son fonctionnement nominal
• si un appel à un syscall non autorisé est effectué, c'est que l'on n'est pas dans un comportement nominal (tentative d'exécution frauduleuse d'une opération non prévue ? Buffer overflow ?)

Je pense que pour Theo, ça n'augmente pas réellement la charge de travail/maintenance de leurs outils, car via tame(2) ils n'ont pas d'audit de code à conduire pour déterminer la liste EXACTE des syscalls autorisés.

Je ne vois pas cette critique dans le lien que tu donnes et je ne suis pas sûr de comprendre le raisonnement.

Post de Theo paragraphe 4.

Le principe des outils comme seccomp, c'est d'autoriser/interdire chaque syscall un par un (il existe un mode "simple", qui n'autorise que read(2), write(2), _exit(2) et un autre dont je ne me souviens plus, sigreturn(2)).

Le problème c'est que si tu dois faire passer ton programme dans une moulinette qui t'indique les syscall utilisés, c'est sous-optimal et pas forcément pratique. De plus c'est complexe.

Prenons un exemple : imagine que tu analyses un serveur web que tu as codé toi-même. Pour savoir quel syscalls sont utilisés, tu as deux choix, lire statiquement le code source de ton programme et déterminer lesquels sont des syscalls, et retourner la liste (complexe + cher, mais marche à tous les coups). L'autre solution c'est de lancer ton programme et de regarder les syscalls qui apparaissent au fur et à mesure et à la fin retourne lui aussi la liste des syscalls (simple + léger, mais si un syscall n'a pas apparu durant ton exécution, alors certains auront des problèmes).

Le principe de tame, c'est d'autoriser/interdire des groupes d'opérations au cours de l'exécution (hors initialisation du programme, là où des opérations privilégiées sont nécessaires).

les seuls qui désactivent SELinux sur Fedora, ce sont les admins systèmes qui ne savent
pas l'utiliser

Si les admins systèmes sont incapables de manipuler leur système correctement, où va-t-on …

Trêve de plaisanteries, SELinux a le mérite d'ajouter une couche de sécurité très importante au noyau Linux, mais en échange c'est assez compliqué à mettre en place pour un néophyte. C'est principalement ça que je reproche à SELinux.

En matière de sécurité, j'ai tendance à considérer que plus un outil est complexe à configurer/manipuler, plus le risque d'erreurs est grand. SELinux fait partie de ces outils complexes à utiliser. Packet Filter a une syntaxe très simple à prendre en main, ce qui me permet de comprendre très rapidement son fonctionnement et donc me permet de bien le configurer.

J'ai déjà eu un problème avec SELinux, et ce qu'on m'a conseillé c'est de le passer en mode permissif … sans jamais lire les logs pour identifier le/les problèmes. Donc SELinux perd tout son intérêt (dans mon cas).

Implémenter un CPU dans un FPGA, ça n'a quasiment aucun intérêt

Aucun intérêt, oui, mais ça reste tout de même assez intéressant dans une optique d'apprentissage. Et le fait d'avoir une chaîne de développement libre fait qu'il est plus simple de développer sur les FPGA pour un amateur (comme moi).

Concernant l'intérêt du compilateur déporté sur une carte accélératrice, personnellement je ne vois pas vraiment l'utilité : peu de projets nécessitent autant de compilation (à l'exception évidemment des dépôts de logiciels, comme ceux des *BSD ou de GNU/Linux).

A la rigueur un compilateur adapté à des cartes comme celle d'Adapteva serait plus utile, car ce sont des coeurs ARM (et donc le "CPU" est déjà conçu). Si on voulait faire du FPGA (comme le présente l'auteur de l'article), il faudrait :

• soit "recoder" une plateforme complète (et donc des CPU & GCC adapté à ces CPU) + gérer l'accès au HDD pour les fichiers sources
• soit avoir un FPGA "pré chargé" avec une plate forme (type Epiphany), et le compilateur serait capable de dispatcher les différentes compilations sur la carte accélératrice.

EDIT: la seconde solution me paraît réalisable, mais pas la première (pour l'instant).

Comme sujet de recherche/découverte/essai, ça serait génial d'essayer la conception d'un tel projet, par contre pour une utilisation plus "industrielle"/utile, …

AMHA, l'important dans un compilateur c'est principalement la qualité du code généré, beaucoup plus que la vitesse de génération de code. Par contre, un FPGA pour accélérer les calculs au sein d'une application (compression, chiffrement, encodage, …), ça a du sens.

Après une petite recherche dans l'arbre des sources,

% find . -name *.s
./libs/ardour/sse_functions_64bit_win.s
./libs/ardour/sse_functions.s
./libs/ardour/sse_functions_64bit.s

On dirait des interactions avec le hardware pour les extensions SSE des processeurs.

Ça n'est pas une critique de ce logiciel, loin s'en faut. Je trouve ça courageux. C'est plutôt une explication des raisons pour lesquelles si peu de logiciels libres existent dans ce domaine, et si encore moins ont du succès.

Effectivement, peu de personnes travaillent directement sur des outils aussi spécialisés. Néanmoins, l'arrivée d'une telle chaîne d'outils est bienvenue. Je m'intéresse depuis quelques années aux FPGA, et le manque d'outils complets libres est assez flagrant dans ce domaine. Dommage que le VHDL ne soit pas supporté :)

En fait j'ai un chip Intel HD 4000, ce qui, à proprement parler, n'est pas une carte graphique.

Les chipsets Intel HD sont très bien pour la majorité des usages "standards". Après, si tu souhaites faire du jeu en HD et/ou du rendu/encodage/etc, une carte dédiée serait plus adaptée.

Et si tout le calcul graphique se faisait uniquement coté serveur, pourquoi tente-t-il de charger un driver Nvidia ?

Pour afficher sur ton écran en local, il faut un driver dans tous les cas ^{^} le serveur envoie le rendu graphique à ton client, et ton client l'affiche sur l'écran en utilisant son driver à lui.

755 : tout le monde à le droit de lire/exécuter

Justement, ici les permissions sont bonnes mais l'accès est refusé au dossier, c'est ce qui me paraît étrange …
Quelle est ta config (distribution, version de OpenSSH) ? Est-ce que tu as redémarré le serveur SSH après tes modifs ? Aurais-tu un autre serveur SFTP qui tourne en même temps sur la machine ?

Sont-ils dans le bon groupe ?

Une question que je me pose, c'est pourquoi le dossier partagé (/sftp/dossiergroupe) appartient au groupe root ? Car dans ce cas, les utilisateurs du groupe NOMDEMONGROUPE ne peuvent lister le contenu du dossier dans lequel ils sont chrootés. C'est pour celà que tu obtiens l'erreur de permission sur le dossier courant (dossier ".").

Le moyen serait (à mon avis) de changer les permissions sur le dossier, en changeant le groupe d'appartenance :

chown -R root:NOMDEMONGROUPE /sftp/dossiergroupe

Perso, mon ArchLinux avec i3 et la barre de status me conviennent. Après, c'est du systemd mais bon on ne peut pas tout avoir !

Tu as raison sur le principe. Mais dans le cas d'un document à écrire rapidement/non réutilisé, je ne m'embêtais pas.

Maintenant, j'ai un peu d'expérience en LaTeX donc je ne m'embête plus à écrire mes documents dans un LibreOffice/autre. Vim + XeLaTeX + git me suffisent largement pour la rédaction et l'archivage (en plus d'être réutilisables !).

Je connais une personne qui écrit tout ses cours sous Word, et inclue ses codes source directement dans son document. Et honnêtement de rendu est plutôt intéressant.
Après, il utilise Visual Studio pour écrire son code, du coup c'est peut-être bien intégré.

Je préfère quand même LaTeX et son paquet "listings" pour insérer du code proprement dans la page. Sinon en LibreOffice créer un tableau de 1*1, changer la police au sein du tableau et placer la couleur comme son éditeur de texte/IDE favori. Manuel mais efficace.

Vu que ce sont des paquets, il est peut-être possible de créer un "méta paquet" qui dépende de mysql, etc et qui par la suite applique tes fichiers de config (je n'ai fait ça qu'avec des RPMs, mais ça doit marcher pareil avec les .deb).

Après tu pourrais appliquer automatiquement ton paquet ? A moins que ça ne marche pas comme ça ?

Alors concernant ce sujet, tu n'es pas le seul à te demander quand sera disponible un hébergemnet sous OpenBSD !

Si tu es (comme moi) sous Kimsufi, le lien suivant pourra t'être utile (pour DragonFlyBSD mais s'adapte à OpenBSD). A essayer chez soi avant de tester directement en prod.

Après si tu as un serveur plus "cher", il y a possibilité d'avoir du vKVM (une sorte de console graphique par le réseau, qui te permets de voir ce qui se passe à "l'écran", comme si étais avec le serveur chez toi). Du coup tu peux indiquer le CD d'installation sur ton PC et le serveur bootera dessus à distance. Mais c'est disponible que sur les serveurs chers OVH.

Sinon il me semble que Online (filiale d'Illiad) propose du vKVM sur leurs serveurs low cost, mais je m'en suis jamais servit.
Et enfin, Digicube louerait des serveurs sous OpenBSD, mais l'option ne m'as jamais été proposée.

Ce post semble donner des pistes sur des loueurs de VPS avec de l'OpenBSD.

Alerte ! Un mec télécharge une iso debian en ayant cliqué sur le lien torrent coupons vite l'accès à ce terroriste !

C'est malheureusement le problème : vu que les torrents sont très utilisés pour partager des films, etc. on bloque le protocole. Alors que pour certains, le torrent permet d'éviter d'avoir une infrastructure pour mettre à disposition les ISOs complets d'OS.

Et pendant ce temps là pas de soucis pour le direct download ou les sites de streaming pourris.

Cas MégaUpLoad.

De toute façon, pour faire ce que tu veux dans les universités le meilleur moyen ça reste les VPN/tunnel ssh sur un serveur dédié (ça coûte pas très cher, c'est assez simple à mettre en place quand tu connais un peu l'administration système et c'est rapide).

Sinon essayer de voir si des étudiants n'ont pas déjà un VPN à eux (fait par un petit geek dans son garage logement étudiant et qui sers à ses potes) peut être une solution.

LinOTP
Peut-être que ça correspond à tes attentes ?