steph1978 a écrit 3052 commentaires

Alors moi c'est pas le mac qui m'a fait peur mais la tête des enfants !

Si l'on considère que :
- le stockage ne coûte pas grand chose,
- il est possible de faire de la déduplication au nivau FS ou blockdevice,
- MacOS et Android proposent déjà d'empacter toutes les dépendances d'une application avec son exécutable,
- Winsxs est une grosse daube,
- le travail des empacteurs pour distribution linux s'apparente à du stakhanovisme,
Je pense que la tendance est à Flatpak, ou Docker ou similaire.

De ce que je comprends, ASN.1 permet de sérialiser programmatiquement des struct C dans un encodage spécifique pour, par exemple, communiquer sur un protocole réseau.

Peux tu expliquer comment l'utiliser pour se rapprocher de l'usage proposé par binmake ?

Hachoir, générique avec de nombreux formats reconnus et la possibilité d'en spécifier de nouveaux.

binwalk, spécialisé dans les firmwares.

Et dans une moindre mesure radare, spécialisé dans les exécutables.

Complémentaire, oui mais peut être pas viables.
Les spécialistes qui lisaient opensilicium devront peut être venir grossir les lecteurs de hackable ou un autre magasine du groupe.

Tu pars du principe que le programmeur est meilleur que la machine pour optimiser et donc qu'il est plus efficace de partir d'un langage bas niveau qui donne toute la latitude pour piloter le calcul.

Mais c'est généralement faux. Il est souvent préférable d'avoir un langage haut niveau plus expressif, qui exprime l'intention algorithmique et de laisser un compilateur faire des optimisations difficilement appréhendable par un programmeur.

C'est ce que tente de faire pythran, cython ou pypy avec Python : permettre, par des annotations, de décrire l'intention algorithmique (et aussi d'ajouter du typage, moyen le plus efficace de permettre des optimisations et qui manque cruellement à python, ne nous leurrons pas).

Les langages fonctionnelles sont très efficaces pour cela. Les notions de fonctions pures, de typage fort (avec ou sans inférence), d'évaluation paresseuse, les map (qui sont une forme de SIMD), donnent beaucoup d'information à un compilateur pour faire des optimisations très efficaces.

En augmentant le budget en conséquence, je serai partant pour un 13" FullHD, SSD.
Et un clavier Dvorak/Bepo aussi !
Mince noël c'est dans 11 mois et demi.

J'adhère beaucoup aux principes du logiciel Trojita que j'utilise quotidiennement. Il simple (dépend uniquement de Qt), rapide (non, blazing fast) et conforme à la norme IMAP. Il supporte plusieurs compte en même temps mais pas avec une boite unifiée (et pas de stockage local).

Je n'ai que quelques défauts à lui reprocher dont je prévois de faire des remontés de but ou de pull requests.

Tout ça pour dire que le paysage des clients mail est déjà bien plein. Il faut trouver un positionnement pour trouver son public.

C'est prometteur, je pense que je vais expérimenter ça d'ici peu.

J'ai un peu eu la flemme de chercher mais peut être qu'une bonne âme peut expliquer : quelle est le lien entre Guix/GuixSD et Nix/NixOS ?

Très drôle. Le point d'orgue pour moi : "Windows has 40,000 fairly well structured solutions right out of the box".
IMHO, windows a surtout deux grands atouts : les commerciaux de chez MS et les juristes de chez MS.

J'ai aussi tiqué sur le passage sur la répartition par langage.
Si les 26k de shell sont générées par des outils, elles de devraient pas être comptabiliser.
Ensuite, sur la méthode elle même, compter des lignes est très brutale.
Si Rust est moins verbeux alors sont empreinte totale est sous estimée.
Si un langage est utilisé sur une partie critique et d'autres sur de l'enrobage, il devrait ressortir.
Bref, IMHO, un tel indicateur n'est pas très pertinent et je suis content de voir une deuxième réalisation concrète en Rust après Servo.

FAT = File Allocation Table

C'est une implémentation de base d'un FS. De là à parler de technologie…

C'est un peu prêt aussi nul que si j'appelais mon système d'exploitation "fenêtre".

---> []

Plus sérieusement, ils ne s'y sont pas collé tout seul, il y avait aussi NCR, SCP, IBM, Compaq, Digital Research, Novell, Caldera.

Puisque chacun y va de sa recette : j'utilise une gomme blanche.

Ce n'est pas chimique, juste mécanique : la gomme se mêle à la colle et le tout part en peluches. Cela ne fait pas de rayure. Le pire qu'il puisse arriver est que cela ne marche pas. Mais je n'ai jamais rencontré le cas.

Faut juste cliquer sur le lien IoT.

Je "gueule" pas sur azul. Ils font ce qu'ils veulent et leurs clients aussi.

Je me plaints que tu viennes en faire la pub sur ce site sans même avoir regardé à quoi ça ressemble. C'est soit de la provocation soit de la négligence.

On y trouve des perles dans la partie "open source" washing de leur site :

Through the use of proprietary tools, Azul scans more than 7 million lines of OpenJDK sources (including dynamically generated files) to verify that Classpath Exception (CPE) tags are in all appropriate source files and that all accessible Java APIs have corresponding CPE tags. License verification ensures that a customer’s Java code is never contaminated by GPL or other licenses that could require the customer to open source their code or purchase additional licenses.

En gros, ils font un grep dans les sources de l'openjdk pour être bien sûr que le code client ne se fera pas contaminer par la GPL.

Quelle contribution à l'opensource !

Azul Zulu, a binary build of OpenJDK (a Java implementation) developed by Azul Systems

Pfiu, heureusement qu'il y a wikipedia pour expliquer clairement ce que sont les choses.

on va avoir des versions libres sérieuses en alternative à JAVA, pour toutes les plateformes.

C'est exactement l'inverse. OpenJDK est libre et multiplateforme. Azul zulu est binaire, donc limité aux plateformes choisies par l'éditeur et propriétaire. Peut être même une simple tentative de chantage aux brevets envers Sun à l'époque.

les développeurs de logiciels libres remplacent progressivement JAVA par cette version libre.

Tu as craqué ?!

Zulu n'est pas une alternative à Java, c'est une JVM. Zulu c'est une alternative propriétaire à OpenJDK.

Faut descendre de ton nuage ou ne pas croire que les autres y sont…

Que Ms ait choisi de déployer ça sur azure montre qu'ils ont encore du chemin dans leur opensource washing.

Moissez, fuyez !

Les codes de chiffrement ne sont plus spécifiques

J'en déduis que ext4 peut chiffrer les données, tout comme F2FS. C'est ce que confirme la page wikipedia de ext4.

Quels sont les avantages / inconvénient à chiffrer au niveau FS par rapport à chiffrer au niveau block (dmcrypt) ?

J'ai souvent vu du chiffrement block (c'est ce que m'a proposé ma distrib), rarement au niveau FS. D'ailleurs les man de mount ou mke2fs ne semblent pas dire comment faire.

une abomination tel que pulseaudio

Des analyses plus précises pour nous éduquer ?

Parce que là le seul retour que j'ai c'est celui de mon casque audio qui me dit que c'est tombé en marche…

Je trouve l'approche "user story" très bienvenue.
Le site est plutôt agréable et donne envie.
Par contre j'ai butté sur la punchline : "liberate your genius" je trouve que ça fait très franglish.
Bon c'est pas ça qui va m'empêcher de tester, histoire de comparer à Gitlab que nous utilisons en ce moment.

il a été PROUVÉ par un audit que EncFS n'est pas sécurisé

Est-ce qu'il a été prouvé que crashplan est sécurisé ?

bof,
j'utilise le gestionnaire de package de ma distrib pour le FF mainstream.
Et le targz de la nigthly qui ensuite se met à jour tout seule.
ça me parait pas insurmontable.

C'est intéressant.
Mais ça explique pas l'utilisation de l'extension de fichier.

Je partage ton espoir concernant les containers.
Cela serait une solution élégante pour protéger sa vie privée.
Pour l'instant j'utilise les profiles : un profile poubelle, un profile surf intense, un profile par membre du GAFAM.
Mais cela consomme pas mal de ressource. Et la gestion des mots de passe est un peu pénible.
Reste à rendre la fonctionnalité compréhensible et utilisable (un peu comme le mode privé sauf que c'était plus simple).

J'avoue ne jamais avoir plongé dans le code de FF. Mais quand tu pointes

protection lors du téléchargement contre un large panel d'exécutables sous GNU/Linux, macOS et Windows ;

avec un lien vers le fichier source ApplicationReputation.cpp, cela fait un peu peur.

Cela commence à la ligne 399 : // Extracted from the "File Type Policies" Chrome extension
Pour finir à la ligne 682. Soit presque 300 lignes pour lister des extensions de fichiers qui auraient pu être mises dans un fichier de configuration ou à la rigueur dans une liste.

Je suis perplexe.

D'autre part, ce code n'explique finalement pas en quoi consiste cette "protection".
Ceci l'explique un peu.

Moi je trouve sain que Mozilla se préoccupe de l'usage qui est fait de son produit. Les extensions sont la raison principale pour laquelle j'utilise FF et je suppose ne pas être le seul dans ce cas.
IMHO, cela ne veut pas dire qu'il faut aller jusqu'à inclure des extensions dans le cœurs (c'est très mal passé pour la tentative pocket). Car cela augment la taille du logiciel inutilement. L'idée même d'un système d'extension est bien d'avoir un cœur réduit qui soit "étendable".
Les releases ne sont bloquées que lorsqu'il y a un changement majeur des API voire de l'architecture du logiciel comme pour e10s. Lors des changements mineurs, c'est plutôt les mainteneurs d'extensions qui font les ajustements.