abriotde a écrit 985 commentaires

  • [^] # Re: Reconditionné

    Posté par  . En réponse au lien Le marché des smartphones est en chute libre et ce n’est pas près de s’arrêter. Évalué à 1.

    Non, je ne pense pas que ce soit le reconditionné qui joue un rôle majeur.

    Il y a d'un côté une baisse de l'innovation et de l'autre une désaffection pour la nouveauté qui à souvent des défauts de jeunesses. Si vous voulez un exemple, prenez l’accueil qui a été réservé au smartphone pliable. Même les journalistes ont tapé dessus pourtant franchement, avoir un téléphone assez petit pour être dans une poche et utilisable avec un plus grand écran c'est génial.

    Mais voilà, les journalistes (et les clients) ont dis "l'écran est fragile". Pourtant c'était aussi vrai avec les smartphone et les gens en avaient achetés malgré tout. Très souvent ils en changeait au bout de 18 mois car le téléphone était tombé et trop fellé (problème inconnu des "dumpphone")… Les smartphones ont fait des progrès sur ce point, ils en sont au niveau des dumphone d'il y a 15 ans et les téléphones pliant sont les smartphones modernes… mais les gens préfèrent prolonger leur téléphone, ce n'est pas toujours une question écolo, mais une question de budgets et de priorité… jusqu'à quand?

  • [^] # Re: VM est non écologique par essence

    Posté par  . En réponse au journal Uxn : un langage assembleur axé sur la frugalité. Évalué à 4.

    On parle à logiciel équivalent d'un point de vue "utilisateur". Il est evident qu'un jeu vidéo 3D hyper realiste consomera normalement plus de ressources qu'un Pacman et que pour consommer moins d'énergie on peut jouer aux cartes avec un ami ;)

  • [^] # Re: VM est non écologique par essence

    Posté par  . En réponse au journal Uxn : un langage assembleur axé sur la frugalité. Évalué à 2.

    C'est le bon contre-exemple sauf qu'il ne s'applique pas ici, du moins pas dans l'utilisation principale actuelle…

  • [^] # Re: VM est non écologique par essence

    Posté par  . En réponse au journal Uxn : un langage assembleur axé sur la frugalité. Évalué à 3.

    Pour préciser, quand je dis "pour rien", jz n'entends pas qu'il y a aucun intérêt à virtualiser, mais d'un point de vue consommation d'énergie, il y a pertes. Il y a gain en sécurité, en praticité, en maintenance… De même une chaîne de vélo perd de l'énergie, elle à un rendement inférieur à 100%, elle à simplement un intérêt de confort et vitesse car l'humain est incapable de pédaler a 100 tours par minutes efficacement.

  • # VM est non écologique par essence

    Posté par  . En réponse au journal Uxn : un langage assembleur axé sur la frugalité. Évalué à -2.

    Une VM, c'est une couche de virtualisation supplémentaire et donc des calculs pour "rien". Aussi léger et efficace qu'elle soit. C'est un peu comme un camion pour transporter une voiture, cela consommera toujours plus que la voiture seule.

    Par contre on peut construire un écosystèmes en virtuel pour, un jour faire un vrai processeur Uxn.

  • [^] # Re: Erratum : 7 applis, pas 5

    Posté par  . En réponse au lien The Verge suggère 5 applis de messagerie chiffrée, aucune n'est libre. Évalué à 4.

    J'utilise Element et je pense que c'est la plus sécurisé (décentralisé, open-source, "non-controlable"). Par contre elle n'est pas hyper-simple à installer/configurer dans la mesure ou l'on peut facilement perdre les clé privées/public et galérer à récupérer son compte sans compter que l'on aura perdu tous ses messages…

    Sinon, Signal est la plus simple d'utilisation je pense (elle peut-être mise en messagerie par défaut ce qui est pas mal). Son gros défaut c'est que l'on ne peut pas l'utiliser sur un PC… sachant que les smartphones sont plus souvent infestés de spyware et qu'en plus on ne peut pas contrôler que côté serveurs ils ne décryptent pas tes messages…

  • [^] # Re: Et le grand nettoyage ?

    Posté par  . En réponse au sondage Quelle est la fréquence de nettoyage de vos périphériques d'entrée ?. Évalué à 3.

    Ce n'est pas la saleté sous les touches qui pose problème, mais les saletés coincées à l'intérieur du clavier… Un nid à bactéries et cela peut bloquer des touches.

  • [^] # Re: Manque une case !

    Posté par  . En réponse au sondage Quelle est la fréquence de nettoyage de vos périphériques d'entrée ?. Évalué à 1.

    C'est bien pour les gens qui tapent au clavier entre 2 vidanges (C'est plus facile à nettoyer et cela évite les saletés coincées à l'intérieur) mais pour les gens dessus toutes la journée, je pense que ça gène la frappe non?

  • [^] # Re: C'est A MOI !

    Posté par  . En réponse au sondage Quelle est la fréquence de nettoyage de vos périphériques d'entrée ?. Évalué à 1.

    Anti-vol peut-être pas, mais un anti-squat par ta famille/collègues car eux connaissent l'état de propreté :D

  • # Julia

    Posté par  . En réponse au journal Le taptempo du web. Évalué à 2.

    #!/usr/local/bin/julia
    
    using HTTP
    using HTTP.Messages
    using Random
    using Logging
    using Sockets
    
    LogLevel(Logging.Warn)
    
    if length(ARGS)<2
        println("Missing arguments : Usage 'random_url_server.jl port nbImages'")
        exit();
    end
    
    port=parse(Int64,ARGS[1])
    nbImg=parse(Int64,ARGS[2])+1
    
    HTTP.listen(Sockets.localhost,port) do http::HTTP.Stream
        if uri(http.message)=="/"
            HTTP.setstatus(http, 307) # Temporary Redirect
            HTTP.setheader(http, "Location" => string("https://avatar.spacefox.fr/Renard-",rand(1:nbImg),".png"))
            HTTP.startwrite(http)
        end
    end

    C'est un langage réputé performant. Par contre il se "compile" au premier appel alors j'ai fais un premier appel avant le test.

    ab -n 100000 -c 10 http://localhost:3000/
    This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    
    Benchmarking localhost (be patient)
    Completed 10000 requests
    Completed 20000 requests
    Completed 30000 requests
    Completed 40000 requests
    Completed 50000 requests
    Completed 60000 requests
    Completed 70000 requests
    Completed 80000 requests
    Completed 90000 requests
    Completed 100000 requests
    Finished 100000 requests
    
    
    Server Software:        
    Server Hostname:        localhost
    Server Port:            3000
    
    Document Path:          /
    Document Length:        0 bytes
    
    Concurrency Level:      10
    Time taken for tests:   16.392 seconds
    Complete requests:      100000
    Failed requests:        0
    Non-2xx responses:      100000
    Total transferred:      8657325 bytes
    HTML transferred:       0 bytes
    Requests per second:    6100.53 [#/sec] (mean)
    Time per request:       1.639 [ms] (mean)
    Time per request:       0.164 [ms] (mean, across all concurrent requests)
    Transfer rate:          515.76 [Kbytes/sec] received
    
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    0   0.1      0       4
    Processing:     0    2   1.1      1      76
    Waiting:        0    1   1.1      1      76
    Total:          1    2   1.1      1      76
    
    Percentage of the requests served within a certain time (ms)
      50%      1
      66%      2
      75%      2
      80%      2
      90%      2
      95%      2
      98%      3
      99%      4
     100%     76 (longest request)
    
    
  • [^] # Re: une version en haskell

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 4.

    C'est le nouveau taptempo. :D On se fait tous les langages ;)

  • [^] # Re: Version Rust

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 1.

    J'ai testé et le mien est un poil plus rapide mais il ce n'est pas vraiment significatif d'autant plus que mon PC avait déjà des choses à tourné (Chromium, Firefox, Thundebird, anti-virus … )

    J'ai réuni les 3 versions dans un tar téléchargeable ici :

    https://drive.google.com/file/d/1d69P_igfk3gYrqtvur7aNlcVarSBWNdh/view?usp=sharing

  • [^] # Re: Version Rust

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 1.

    Je n'ai pas testé, en fait, je suis un débutant en Rust (plus habitué au PHP et C). J'ai pris ça en exercice et après j'ai vu le tiens. Je pense que le tiens est plus léger au niveau plugin au moins.

  • [^] # Re: Version Rust

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 2.

    Il existe donc réellement des personnes qui utilisent des makefiles avec Java ?

    Il existe surtout des personnes qui n'utilisent pas Java ;) J'aime bien le Makefile pour automatiser certaines compilation en tests. Je suis de la vielle école.

    Mais bon, j'ai réussi…

    This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    
    Benchmarking localhost (be patient)
    Completed 10000 requests
    Completed 20000 requests
    Completed 30000 requests
    Completed 40000 requests
    Completed 50000 requests
    Completed 60000 requests
    Completed 70000 requests
    Completed 80000 requests
    Completed 90000 requests
    Completed 100000 requests
    Finished 100000 requests
    
    
    Server Software:        
    Server Hostname:        localhost
    Server Port:            3000
    
    Document Path:          /
    Document Length:        0 bytes
    
    Concurrency Level:      10
    Time taken for tests:   13.204 seconds
    Complete requests:      100000
    Failed requests:        0
    Non-2xx responses:      100000
    Total transferred:      16157208 bytes
    HTML transferred:       0 bytes
    Requests per second:    7573.62 [#/sec] (mean)
    Time per request:       1.320 [ms] (mean)
    Time per request:       0.132 [ms] (mean, across all concurrent requests)
    Transfer rate:          1195.01 [Kbytes/sec] received
    
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    0   0.2      0      11
    Processing:     0    1   1.0      1     105
    Waiting:        0    1   0.9      1     103
    Total:          0    1   1.0      1     106
    
    Percentage of the requests served within a certain time (ms)
      50%      1
      66%      1
      75%      1
      80%      2
      90%      2
      95%      3
      98%      4
      99%      5
     100%    106 (longest request)
    

    Je suis donc pasé de 12 000 en Rust à 7 573 en Java ;)

  • [^] # Re: Version Rust

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 2. Dernière modification le 14 juin 2022 à 16:35.

    Cela fais longtemps que je n'ai pas pratiqué Java.

    J'ai fais mon makefile:

    AvatarHttpServer.class: AvatarHttpServer.java
        javac AvatarHttpServer.java
    
    AvatarServer-1.0-SNAPSHOT.jar: AvatarHttpServer.class
        jar cfM AvatarServer-1.0-SNAPSHOT.jar AvatarHttpServer.class
    
    all: AvatarServer-1.0-SNAPSHOT.jar
    
    run: AvatarServer-1.0-SNAPSHOT.jar
        java -Xmx8m -Xss256k -jar ./AvatarServer-1.0-SNAPSHOT.jar 3000 21
    
    clean:
        rm -f ./AvatarServer-1.0-SNAPSHOT.jar ./AvatarHttpServer.class

    Mais "make run" me dit :

    java -Xmx8m -Xss256k -jar ./AvatarServer-1.0-SNAPSHOT.jar 3000 21
    Error: Invalid or corrupt jarfile ./AvatarServer-1.0-SNAPSHOT.jar
    
    
  • [^] # Re: Version Rust

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 2.

    alberic@minicoda6:~/scripts-utils/diffuse $ ab -n 100000 -c 10 http://localhost:3000/
    This is ApacheBench, Version 2.3 <Revision: 1843412>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking localhost (be patient)
    Completed 10000 requests
    Completed 20000 requests
    Completed 30000 requests
    Completed 40000 requests
    Completed 50000 requests
    Completed 60000 requests
    Completed 70000 requests
    Completed 80000 requests
    Completed 90000 requests
    Completed 100000 requests
    Finished 100000 requests

    Server Software:

    Server Hostname: localhost
    Server Port: 3000

    Document Path: /
    Document Length: 0 bytes

    Concurrency Level: 10
    Time taken for tests: 7.984 seconds
    Complete requests: 100000
    Failed requests: 0
    Non-2xx responses: 100000
    Total transferred: 14152909 bytes
    HTML transferred: 0 bytes
    Requests per second: 12525.70 #/sec
    Time per request: 0.798 ms
    Time per request: 0.080 ms
    Transfer rate: 1731.20 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 0 0 0.1 0 3
    Processing: 0 0 0.3 0 12
    Waiting: 0 0 0.3 0 11
    Total: 0 1 0.3 1 12

    Percentage of the requests served within a certain time (ms)
    50% 1
    66% 1
    75% 1
    80% 1
    90% 1
    95% 1
    98% 2
    99% 2
    100% 12 (longest request)

  • [^] # Re: Version Rust

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 1.

    Non, je ne sais pas trop comment m'y prendre

  • # Version Rust

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 4.

    Voici ma version Rust (je ne suis pas un expert). On a moins de librairies disponible dans le "core", il m'a donc semblé juste d'utiliser des dépendances.

    #![deny(warnings)]
    
    use std::convert::Infallible;
    use rand::Rng;
    use hyper::service::{make_service_fn, service_fn};
    use hyper::{Body, Method, Request, Response, Server, StatusCode};
    
    
    async fn random_fox(req: Request<Body>) -> Result<Response<Body>, Infallible> {
        match (req.method(), req.uri().path()) {
            (&Method::GET, "/") => {
                let mut randomGenerator = rand::thread_rng();
                let imgCount=20;
                let rndInt=randomGenerator.gen_range(1..imgCount);
                let rndStr=rndInt.to_string();
                let url = "https://avatar.spacefox.fr/Renard-".to_owned()+&rndStr+ ".png";
                let set_location = Response::builder()
                    .header(hyper::header::LOCATION, url)
                    .status(StatusCode::MOVED_PERMANENTLY)
                    .body(Body::from("")).unwrap();
                Ok(set_location)
            },
            // Return the 404 Not Found for other routes.
            _ => {
                let mut not_found = Response::default();
                *not_found.status_mut() = StatusCode::NOT_FOUND;
                Ok(not_found)
            }
        }
    }
    
    #[tokio::main]
    pub async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
        let port = std::env::args().nth(1).expect("no port given")
            .parse::<u16>().unwrap();
        let _imgCount:u16 = std::env::args().nth(2).expect("no imgCount given")
            .parse::<u16>().unwrap();
    
        pretty_env_logger::init();
        let make_svc = make_service_fn(|_conn| {
            async { Ok::<_, Infallible>(service_fn(|req| random_fox(req))) }
        });
        let addr = ([127, 0, 0, 1], port).into();
        let server = Server::bind(&addr).serve(make_svc);
        println!("Listening on http://{}", addr);
        server.await?;
        Ok(())
    }

    Et le Cargo.toml
    ```ini
    [package]
    name = "random_url_server"
    version = "0.1.0"
    edition = "2021"

    [dependencies]
    hyper = { version = "0.14", features = ["full"] }
    tokio = { version = "1", features = ["full"] }
    rand = { version = "*"}
    pretty_env_logger = "0.4"
    ```

  • # Rust et C

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à -1.

    Pour un programme aussi simple et statique, coder en C++ ou Rust me parait aussi simple et beaucoup plus efficace (en tout cas par rapport à Java).

  • [^] # Re: PHP ?

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 2.

    Je trouve que cela vaudrait vraiment le coup. Car PHP sera compilé en byte-code et entièrement en RAM et à mon avis il ne consommera pas plus que Java sur ce cas pour les même perfs (à minima).

    PHP est moins bon que Java dans la gestion des tableau (ou classes) et dans les boucles. Là tu n'en a pas…

  • [^] # Re: Avec un peu de créativité, tu peux même tout faire avec nginx

    Posté par  . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à -4.

    Oui mais Quid de la conso mémoire/CPU. A mon avis elle n'est pas top car l'usage requière une grosse partie virtualisation. Et même si ce n'est bien sûr pas une vrai virtualisation, cela consomme pour si peu de besoin…

  • # Sur Tesla, Il a mis de nombreux brevets en libre de droits

    Posté par  . En réponse au journal Elon musk ouvrirait le code de tweeter ?. Évalué à 1.

    Sur Tesla, Elon Musk l'a fait et généralement, il tiens parole. Pas toujours dans les temps et sur Tesla il y a une condition (indiquer qu'il y a des brevets Tesla), c'est pourquoi aucun constructeur ne les utilise (Sauf un peu des chinois je crois).

    Mais Elon Musk n'est pas intéressé par le profit en soit mais par son idéal. Il n'a rien a voir avec Bill Gates ou Jeff Bezos. C'est pourquoi il est beaucoup plus imprévisible et, selon moi, génial…

  • [^] # Re: Le plus simple

    Posté par  . En réponse au journal Logiciels transmettant en douce des données vers la russie. Évalué à 6.

    Arrêter de mettre des trackers n'est pas une solution, c'est comme dire aux magasins de refuser l'accès aux voleurs…

    Il y a une seul solution : l'Open-Source. Comment peut-on justifier que l'application Blablacar ne soit pas open-source? Il n'y a aucun secret dedans autres que les trackers.

    L'autre solution, c'est de ne pas utiliser les applications mais les pages Web. Elles sont standard multiplate-forme, permettent tout et l'utilisateur en contrôle facilement les autorisations et quand on les quittent elles s'arrêtent. Pour Blablacar, c'est une évidence. Je peut comprendre qu'une application ait besoin du GPS mais pas h24 7j/7, seulement quand on l'utilise, pour ça seul l'application Web le garanti.

  • [^] # Re: Merci pour le lien

    Posté par  . En réponse au lien catala : traduction directe d'un règlement ou texte législatif en algorithme.. Évalué à 4.

    ça risque de rendre les textes de lois compréhensibles

    Je n'irais pas jusque là. Du moins pas par beaucoup de monde (pas pour les juristes) mais au moins pour les ordinateurs (et donc en pratique de faire beaucoup de choses) et pour les informaticiens.

    Je dirais plutôt que ça pourrait rendre les textes de lois exploitable. Au sens ou on pourrait vérifier algorithmiquement la conformité de la loi sans craindre un texte qui remette tout en question.

  • [^] # Re: Open-Source, liberté, censure...

    Posté par  . En réponse au journal censure ou pas. Évalué à 0. Dernière modification le 21 mars 2022 à 14:55.

    Parfois ça marche, parfois ça fonctionne pas

    Oui mais ça marche tout de même mieux qu'autrement. Tu connais la maxime "la democratie est le pire des régimes à l'exception des autres", eh bien là c'est pareil. En fait ce qu'il se produit si tu n'a pas la liberté d'expression, c'est irrémédiablement, une concentration des pouvoirs en un seul. De nombreuses études montre que "tout pouvoir tend a utiliser tout ses pouvoirs". Dis autrement si ton gouvernement, à le droit d'utiliser la censure, tu peut être certains que tôt ou tard il va le faire et qu'il va même l'étendre à tout. S'il n'y a pas un principe inaliénable, il n'y aura plus rien a terme.

    Et dans un endroit pétri de liberté, il y aura toujours un combat, et même si la "fake news" peut gagner un temps, a terme elle sera toujours renverser par une démonstration.

    Le problème est que la censure, interdit l'idée de penser autrement bloquant tout débat. C'est probablement, ce qui a pousser Potine à penser qu'il battrait en 3 jours l'Ukraine. Il s'est auto-persuader de la vérité, et aucune remise en question n'était possible.