Posté le 15/08/2017 à 15:49 Membre depuis le 28/10/2001, 7625 messages
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.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 15/08/2017 à 16:12Edité par Kevin Kofler le 15/08/2017 à 16:14 Membre depuis le 10/06/2001, 40282 messages
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.)
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 15/08/2017 à 16:13 Membre depuis le 10/06/2001, 40282 messages
Lionel Debroux (./7080) :
pro-virus
gni
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 15/08/2017 à 16:45 Membre depuis le 01/08/2017, 985 messages
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 ?
avatarROM ne s'est pas compilé en un jour
Posté le 15/08/2017 à 17:00 Membre depuis le 27/04/2006, 60494 messages
Probablement rien : /dev n'est pas dans le PATH normalement, et de toute façon ce qu'il contient n'est pas exécutable.
avatarZeroblog

« 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
Posté le 15/08/2017 à 21:52 Membre depuis le 18/06/2001, -26075 message
Sauf si c'est moi qui le fait. J'exécute bien la pile, donc /etc, c'est un jeu d'enfant embarrassed
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 15/08/2017 à 22:38 Membre depuis le 27/04/2006, 60494 messages
grin
avatarZeroblog

« 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
Posté le 15/08/2017 à 22:58 Membre depuis le 10/06/2001, 40282 messages
Exécuter la pile, c'est pour les noobs, j'exécute l'écran, moi. tongue
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 15/08/2017 à 23:17 Membre depuis le 18/06/2001, -26075 message
Ah oui tiens, c'est vrai cheeky
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 16/08/2017 à 01:29 Membre depuis le 11/11/2001, 116514 messages
(c'est pas pire que d'exécuter les dissidents)
avatarWebmaster 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
Posté le 16/08/2017 à 01:44 Membre depuis le 18/06/2001, -26075 message
(grin)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 16/08/2017 à 02:54 Membre depuis le 10/06/2001, 45129 messages
(grin)
Posté le 16/08/2017 à 03:53 Membre depuis le 24/04/2009, 2572 messages
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 (?))
Posté le 16/08/2017 à 09:05 Membre depuis le 18/06/2001, -26075 message
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
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 16/08/2017 à 10:35 Membre depuis le 13/06/2002, 42696 messages
Roh, un peu de bonne volonté embarrassed
PS C:\Users\moi> Get-Command ls

CommandType     Name                                                Definition
-----------     ----                                                ----------
Alias           ls                                                  Get-ChildItem
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)
Posté le 16/08/2017 à 11:14 Membre depuis le 10/06/2001, 40282 messages
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 16/08/2017 à 11:38 Membre depuis le 24/04/2009, 2572 messages
Ouais, j'etais sur mon telephone, dans mon lit au milieu de la nuit grin
Posté le 16/08/2017 à 17:01 Membre depuis le 16/06/2001, 69801 messages
lionel: non, cinnamon nest pas leger. essaye le sur un samsung n150 et tu passeras vite a Mate grin
Posté le 21/08/2017 à 12:47 Membre depuis le 30/06/2001, 71449 messages
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)
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 22/08/2017 à 14:18 Membre depuis le 29/10/2003, 25435 messages
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.
Posté le 22/08/2017 à 14:36 Membre depuis le 10/06/2001, 40282 messages
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).
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 22/08/2017 à 14:45 Membre depuis le 30/06/2001, 71449 messages
-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
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 22/08/2017 à 14:50 Membre depuis le 29/10/2003, 25435 messages
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 ?
Posté le 22/08/2017 à 14:52 Membre depuis le 10/06/2001, 8845 messages
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
Posté le 22/08/2017 à 15:10 Membre depuis le 27/04/2006, 60494 messages
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 ?
avatarZeroblog

« 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
Posté le 22/08/2017 à 15:33 Membre depuis le 30/06/2001, 71449 messages
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.
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 22/08/2017 à 15:55 Membre depuis le 29/10/2003, 25435 messages
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…
Posté le 22/08/2017 à 17:28 Membre depuis le 27/04/2006, 60494 messages
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.
avatarZeroblog

« 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
Posté le 22/08/2017 à 18:15 Membre depuis le 30/06/2001, 71449 messages
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...
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 22/08/2017 à 18:24 Membre depuis le 13/06/2002, 42696 messages
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.
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)
Posté le 22/08/2017 à 18:56Edité par Godzil le 22/08/2017 à 19:23 Membre depuis le 30/06/2001, 71449 messages
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 !
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o