7080

Cinnamon, MATE ou XFCE sur Mint donnent un environnement raisonnablement léger et solide. C'est vers ce genre de solutions que j'orienterais la rénovation d'une vieille machine.

Folco (./7065) :
Pas d'antivirus, Windows Defender powa ^^
Très léger et discret par rapport aux concurrents et suffisant à mon goût. smile
Attention quand même, en plus d'être assez limité, Windows Defender s'est récemment fait épingler par l'équipe du Project Zero de Google pour contenir une dizaine de failles gravissimes (dont ACE) et pour ne pas être sandboxé, contrairement à plusieurs autres composants de Windows smile
Mais bon, quel que soit le pro-virus, les taux de faux positifs, de faux négatifs et de vulnérabilités intrinsèques sont inacceptables. Ils sont tous mauvais, certains le sont juste encore plus que les autres. Il est important d'utiliser un PV gratuit, pour ne pas financer cette très lucrative industrie d'insécurité informatique.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7081

Lemokitu (./7079) :
Kevin Kofler (./7073) :
Les noms réservés existent partout. Windows réserve même globalement des noms comme NUL, CON etc.
Kevin Kofler (./7077) :
C'est bien ce que je dis, il y a des noms réservés et ça foire si tu essaies de les utiliser.
Donc tu confirmes implicitement que Windows est supérieur ?
Non, c'est inférieur. Un fichier nommé df ne cause aucun conflit, ce n'est qu'un exécutable dans le PATH qui n'a pas le droit de porter ce nom. Réserver globalement les noms est très CON (grin) comme comportement. (Pour NUL, CON etc., ce sont de simples fichiers /dev/null, /dev/tty etc. sous GNU/Linux, rien n'est réservé globalement.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7082

Lionel Debroux (./7080) :
pro-virus
gni
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7083

Kevin Kofler (./7073) :
(Pour NUL, CON etc., ce sont de simples fichiers /dev/null, /dev/tty etc. sous GNU/Linux, rien n'est réservé globalement.)
Et si quelqu'un duplique 'null' ou 'tty' en se plaçant avant dans le PATH, façon 'df', il se passe quoi ?
avatar
ROM ne s'est pas compilé en un jour

7084

Probablement rien : /dev n'est pas dans le PATH normalement, et de toute façon ce qu'il contient n'est pas exécutable.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7085

Sauf si c'est moi qui le fait. J'exécute bien la pile, donc /etc, c'est un jeu d'enfant embarrassed

7086

grin
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7087

Exécuter la pile, c'est pour les noobs, j'exécute l'écran, moi. tongue
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7088

Ah oui tiens, c'est vrai cheeky

7089

(c'est pas pire que d'exécuter les dissidents)
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

7090

(grin)

7091

(grin)

7092

C'est peut être très con comme comportement mais ça a le mérite d'éviter ce genre d'anerie quand on sait qu'un bon paquet de setups vont ajouter le chemin du binaire au PATH. (Windows)

Cela dit il reste toujours which quand on n'est pas trop sûr de soi ... (Linux / PowerShell (?))

7093

PS C:\Users\mdemo> which
which : Le terme «which» n'est pas reconnu comme nom d'applet de commande, fonction, fichier de script ou programme
exécutable. Vérifiez l'orthographe du nom, ou si un chemin d'accès existe, vérifiez que le chemin d'accès est correct
et réessayez.
Au caractère Ligne:1 : 1
+ which
+ ~~~~~
    + CategoryInfo          : ObjectNotFound: (which:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
cheeky

7094

Roh, un peu de bonne volonté embarrassed
PS C:\Users\moi> Get-Command ls

CommandType     Name                                                Definition
-----------     ----                                                ----------
Alias           ls                                                  Get-ChildItem
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7095

avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7096

Ouais, j'etais sur mon telephone, dans mon lit au milieu de la nuit grin

7097

lionel: non, cinnamon nest pas leger. essaye le sur un samsung n150 et tu passeras vite a Mate grin

7098

On va bientot pouvoir faire du 2FA avec SSH sur linux en ayant la possibilité de faire:

Public key + Verification Code OU Password + Verification Code

et non soit l'un soit l'autre exclusivement ou pire PubKey + Password + Code... (et si un manque c'est "sorry you can log")


Cf: https://bugzilla.mindrot.org/show_bug.cgi?id=2408
(il aura quand meme fallu 2 an pour qu'ils se bougent et implementent cette option qui va permettre de faire ca)
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7099

Je viens d'apprendre à mes dépens l'existence de l'OOM killer.
En gros, quand un process tourne depuis trop longtemps, l'OOM killer considère que c'est un poids mort dans la mémoire et tue le process sans autre forme de procès.

J'ai donc été obligé de mettre en place des exclusions pour ne pas que mon process qui peut parfois durer 24 heures ou plus se fasse killer la gueule.

7100

Normalement, l'OOM killer ne tue pas un processus juste parce qu'il tourne trop longtemps, à mon avis, tu leakes de la mémoire (ce qui peut faire beaucoup si le processus tourne longtemps).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7101

-Normalement.

OOM signifie Out Of Memory. Il ne tue des process que si il sont TRES gourmant en memoire et qu'il y a une exception de type Out Of Memory.

Et plutot que faire des bidouilles il vaux mieux le desactiver c'est bien plus propre:

echo "2" > /proc/sys/vm/overcommit_memory

Ca desactive l'overcommit de ma memoire (allocation sans verification qu'il y a assez d'espace) et les app se verront repondre "vtff" si elle essaye d'allouer de la memoire alors qu'il n'y en a plus de dispo plutot que d'avoir des random kill
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7102

Un memory leak dans un script bash qui s'occupe d'établir une liste de fichiers via find et de les bouger d'un point A vers un point B ?

7103

Godzil (./7101) :
Ca desactive l'overcommit de ma memoire (allocation sans verification qu'il y a assez d'espace) et les app se verront repondre "vtff" si elle essaye d'allouer de la memoire alors qu'il n'y en a plus de dispo plutot que d'avoir des random kill
Comme la majorité des appli ne vérifient pas qu'un malloc réussit, ça risque pas d'être à peu près la même chose ?
Des applis vont planter aléatoirement, et pas forcément celles qui sont à l'origine du problème.
avatar

7104

L'OOM killer est connu pour ne pas toujours tuer le "bon" process (il utilise des heuristiques). Ça me semble possible que le leak mémoire soit dans un autre process, et que ce soit le tien qui trinque.

Pour moi il faut remonter à la racine du problème, sinon tu risques de simplement le déplacer ailleurs : pourquoi l'OOM se déclenche-t-il ?
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7105

Si ton applie ne verifie pas le retour de malloc et autre fonction, don appli est MAL codée.

Tout ne tourne pas autour de linux et linux est, a ma connaissance, le seul a faire de l'overcommit. Windows, OS X et d'autre on plein de chance de te retourner un pointeur NULL suite a un malloc.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7106

Zerosquare (./7104) :
L'OOM killer est connu pour ne pas toujours tuer le "bon" process (il utilise des heuristiques). Ça me semble possible que le leak mémoire soit dans un autre process, et que ce soit le tien qui trinque.

Pour moi il faut remonter à la racine du problème, sinon tu risques de simplement le déplacer ailleurs : pourquoi l'OOM se déclenche-t-il ?
Après un rapide coup d'œil via top, je vois un processus java qui bouffe 50 % de RAM en permanence.
Je n'ai aucun moyen de manager cette merde, je bosse sur une machine partagée…

7107

Godzil > je considère l'overcommit comme un bug fondamental (on a déjà discuté du sujet), mais sous Linux ça me paraît difficile de s'en passer.

L'origine, c'est fork(). Sans overcommit, ça veut dire que si tu forkes un process qui a alloué 500 Mo (par exemple), tu te retrouves à devoir allouer 500 Mo pour le nouveau process, juste au cas où celui-ci modifierait toute la mémoire allouée (même si ça a peu de chances de se produire).

Or comme fork() est justement massivement utilisé sous Linux, à moins d'être prêt à rajouter plein de barrettes de RAM "au cas où", je ne vois pas trop de solutions.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7108

Oui enfin si tu fork un process qui a 500Mo d'alloué c'est que tu as un problème de conception dans ton app... :/ ( ou que tu devrait utiliser des Thread.

D'ailler l'OC n'est vraiemnt "utile" que pour le CoW, et non fork n'est pas massivement utilisé par les apps qui sont celle susceptible d'allouer beaucoup de memoire, ca n'a aucun sens s'allouer 1Go et de faire un fork, ou comme je dit plus haut tu utlise plusieurs process pour faire des thread? ce n'est pas ce qu'il y a de mieux.

Fork et, et ne devrait, que etre utilisé pour lancer un process non lié, et il y a des options qui indiquent clairement qu'on se fout de copier la memoire du parent.

Quoi qu'il en soit, malloc peu retourner NULL, et tout code qui ne teste pas si il retourne NULL n'est pas du code qu'on peu mettre en production...
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7109

C'est un peu rapide comme verdict. Même si en théorie c'est vrai, tu sais très bien que la quasi-totalité des programmes utilisés sur n'importe quelle plate-forme de production ne teste jamais la réussite des appels à malloc. C'est triste mais c'est un fait, et à partir de là si ta solution consiste à dire "tous les programmes du monde sont buggés et il faut les réécrire", ça n'est pas très crédible.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7110

Excuse moi mais si tu travaille dans un environnement un tant soit peu sérieux tu as des outils comme l'analyse statique ou équivalent (lint pour du C est suffisant pour ça par exemple) qui veille au grain pour ce genre de choses.

C'est le genre de test BASIQUE qui soit être systématiquement fait.

Je n'ai, a vrai dire, jamais vu du code de PRODUCTION, qui ne fasse pas ce genre de test. Dans du code reservé a a faire des test a la limite, mais en prod non.

C'est avec ce genre de pratiques/phrases qu'on se trouve avec des heartbleed. (meme si la ce n'est pas lie a un pointeur null)

beaucoup de bugs sont lié a une gestion de la memoire calamiteuse, donc oui un soft qui ne fait pas de test basique (meme un simple ASSERT(ptr != NULL); est suffisant, brutal mais suffisant) ne peux PAS etre mis en prod sans enorme risque.

D'ailleurs meme avec l'overcommit malloc peux quand meme répondre NULL sous linux. (sous une version 32bit essaye d'allouer plus de 3Go au total tu va voir..)


Et si vraiment tu as la FLEMME de faire toi meme pour chaque allocation, tu fait une fonction genre

void *safe_alloc(size_t sz) { void *ptr = calloc(sz); ASSERT(ptr != NULL); return ptr; }
Et ne fait plus appeil a malloc directement mais a safe_alloc.

Un pointeur null + dereferencement, au meilleurs des cas on a un segfault. Sauf si on a une operation de type (pointer + X) et la.. on va potentiellement lire de la memoire si elle est alloué dans la MMU.

Donc tu fait comme tu veux, mais une app qui ne gere pas la memoire correctement n'a absolument rien a faire en production.

Donc non assumer que malloc ne retourne JAMAIS une erreur est un probleme, Et non j’espère vraiment que la "quasi-totalité des programmes utilisés sur n'importe quelle plate-forme de production ne teste jamais la réussite des appels à malloc" parce qu'on aurais vraiment pas mal d'emmerdes a cause de ca, et je peux t'assurer que tout code un tant soit peu serieux (et qui doit l'etre) qui me soit passé dans les main ne part pas du principe que malloc ne retourne jamais une erreur, c'est meme plutot le contraire, il faut TOUJOURS assumer que tout peux foirer


edit: un exemple de ce dont je veux parler sur le fait que c'est une faille potentielle:
#include <stdio.h> #include <stdint.h> int main() { char *ptr = NULL; char ascii[] = "Hello World"; uint64_t depl = (uint64_t)&ascii[0]; printf("ptr = %p\n", ptr); printf("ptr[depl] = %p\n", &ptr[depl]); printf("ascii = %p\n", &ascii[0]); printf("%s\n", &ptr[depl]); return 0; }
Ce code marche sans probleme:

ubuntu@ubuntu-armhf:~$ ./test 
ptr       = (nil)
ptr[depl] = 0xbec32b90
ascii     = 0xbec32b90
Hello World

Suivant ce que fait le code, un malloc foireux peux etre exploité pour acceder a de la memoire, c'est une faille de securite au meme titre que ne pas verifier ta requete SQL ou faire un eval($_GET['bla']) ou include($_GET['bla']) en PHP.

Au contraire tout projet serieux fait super attention a l'allcoation memoire, exemple:

https://www.nginx.com/resources/wiki/extending/api/alloc/#ngx-alloc
utilisaton: https://github.com/nginx/nginx/blob/0f89206a1078a216961d974ed5bcf6464b65cbdf/src/event/modules/ngx_devpoll_module.c#L151

Apache fait un abort en cas d'erreur d'allocation:
https://github.com/apache/httpd/blob/f3a50c0902efd798f80c6b86290e0bddf26b2843/server/util.c#L3109
(ap_abort on oom: https://github.com/apache/httpd/blob/f3a50c0902efd798f80c6b86290e0bddf26b2843/server/util.c#L3093 )

Si tu trouve un application qui est fait pour de la production et qui ne gère pas l'allocation mémoire correctement c'est un bug report direct !
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.