Moi, ce qui me stupéfait le plus, à chaque fois, c'est qu'en dehors de toute considération de faisabilité technique, je ne vois pas pourquoi ce serait au FAI de faire le travail de la SA{CEM|BAM}. Ou alors, le FAI en question doit recevoir un subside en conséquence de la part de l'organisme. Si on va par là, n'importe quelle structure, même de droit privé, doit pouvoir exiger la même chose.
Chez nous comme en belgique, puisque l'on ne peut pas apréhender le pirate, on va s'en prendre au transporteur.
Nan, justement, sous Windows, même en Administrateur, tu n'es pas sûr de pouvoir tout faire, et encore moins avec les niveaux d'accréditation prédéfinis inférieurs.
Le vrai problème majeur, comme tu dis, c'est que bien souvent, pour pouvoir faire quelque chose d'un tant soit peu ambitieux, on est obligé de passer Administrateur, et du coup, la majorité des utilisateurs qui émigrent sous UNIX exportent le même modèle de pensée, alors qu'à la base ce n'est quand même franchement pas compliqué : 99% des ressources se gèrent au travers du système de fichiers.
En particulier, beaucoup de fichiers de config appartiennent à root mais font également partie d'un groupe, ce afin que les utilisateurs autorisés puissent modifier ce qui relève de leurs prérogatives.
Il faut aussi tenir compte des pseudo-users, tels que postgresql, qui est assez tâtillon sur les droits d'accès.
Bref, si un script d'installation m'avait fait ce coup-là, ça m'aurait mis de très mauvaise humeur ...
C'est affreux parce qu'il y a bon nombre de gens qui pensent que l'on ne peut pas faire autrement que de passer root dès lors qu'UNIX dresse la moindre barrière ! "Bah oui, j'ai été obligé de défoncer la porte puisqu'elle était fermée à clef ...".
Ce post-ci, dans lequel l'auteur a au moins le mérite d'être clair sur ses intentions, est assez révélateur de ce qui doit se passer dans la tête de pas mal de monde : https://linuxfr.org/forums/15/22167.html
Et c'est inquiétant parce que cela confirme la probabilité d'un grand danger avec l'expansion du système dans le grand public : la faille de sécurité majeure viendra de l'utilisateur.
Et oui cela a tellement etait bien defini que c'est tout plein d'erreurs, d'inconsistances et de manques.
CTJ (Comme Ton Journal) ? /o\
Il y a des formules incorrectes, qui si elles sont implementees tel que decrites dans ce standard, vont faire apparaitre de serieux problemes mentaux, securitaire et environnemental
Punaise ! Ca fout les jetons !
Honte a ceux qui encensait et continue de d'encenser les formules de OOXML sans avoir lu leurs definitions
Je vais être honnête, je n'ai encore lu ni ODF, ni OOXML en entier et je ne connais pas beaucoup de gens qui l'aient fait. Le fait que PasBill n'ait pas encore réagi laisserait à penser, à priori, que tout cela est vrai, mais présenté de cette façon, je ne suis pas sûr que l'on favorise l'adoption du premier.
Ce qui est malheureux, c'est d'être obligé d'exhiber ces dangers-là pour faire réagir le quidam, alors que le véritable enjeu est quand même de pouvoir certifier que le format ne pourra pas se faire enfermer à postériori.
Une fois que ceci est dit, et étant donné que je suis déjà entièrement gagné à la cause de l'ODF, j'aimerais bien savoir si de telles faiblesses ont déjà été détectées de son coté aussi, ou si personne ne creuse pour le moment ...
Tiens, ce serait marrant, ça : la GNU Font !
Tout plein de gentils moines typographistes tous en rang à respecter une belle charte graphique pour faire une fonte officielle complète ...
Ah ... Google me souffle à l'oreillette que
1) ça existe déjà,
2) ° Bloub °
3) C'est en bitmap
4) Ce n'est toujours pas complet
C'est surtout de l'unicode que tu essaies de faire apparaître, en l'occurence ! Si tu utilises les entités HTML (&#xxx;), effectivement, le charset en entête ne sert à rien.
Par contre, ne rêve pas, tu ne pourras pas afficher la totalité des caractères de la planète (il n'y a qu'a imaginer le temps qu'il faudrait à une personne pour coder 65536 caractères dans un seul fichier de police).
Technologies de l'information . Format de document ouvert pour applications de bureau (OpenDocument) v1.0
...
Mode dépose de fichier Vous devez utiliser le modèle de saisie de commentaires au format Word (.doc de 30Ko). Si vous ne l'avez pas déjà téléchargé cliquez ici
En fait, il faut que tu mettes un peu les doigts dans UNIX et surtout que tu oublies toutes les habitudes Windows : la copie intégrale, secteur-à-secteur, d'un disque vers un autre, tu peux le faire en une seule commande sous Unix : dd. Et encore, dd n'est là que pour suivre un temps soi peu le processus, mais en fait, copier le contenu d'un /dev/hd- vers un autre suffit à effectuer cette opération.
Les principales raisons pour lesquelles on ne le fait pratiquement jamais sont :
1) La duplication de la table des blocs défectueux du disque source qui ne correspondent bien sûr pas à ceux du disque destination. Ceci se résout en relançant un fsck -cc.
2) Les géométries des disques qui, eux, ne sont en général jamais du même modèle.
3) Le fait que sous Unix, tout est fichier. Il suffit donc de tout copier de filesystem à filesystem et de rappeler lilo ou grub depuis un liveCD pour résoudre le problème en entier.
Pour le reste, c'est de la redondance de machine qu'il faut faire si tu veux faire de la tolérance de panne. Au moins tu assures les défaillances matérielles dans le lot et le tout te coûte guère plus chère que des licences de logiciels dédiés.
En gros, si quelqu'un flingue une machine, une autre est déjà en ligne pour prendre le relais dans la milliseconde, le temps que tu répares la première. Même si UNIX permet de presque tout faire, y compris le genre d'accrobaties dont tu parles, on ne dépanne pas une voiture à 130 sur l'autoroute ...
Bon, en fait, je dis GTK comme ça, mais c'est loin d'être la bibliothèque la plus facile à utiliser ! Par contre, elle est bien documentée ...
Sinon, je veux dire que si tu comptes utiliser deux consoles, il faudra déjà ouvrir toi-même ces deux consoles. C'est normal dans le cas de la première puisque c'est depuis cette console que tu vas lancer ton programme. En outre, les flux d'entrée et de sortie seront ouverts pour toi.
Ensuite, pour gérer une deuxième console, essaie de voir comment on peut écrire dedans. La solution, c'est que chaque console est reliée à un fichier spécial (un /dev) qui permet de communiquer avec.
Plus précisément : dans le cas de terminaux physiques réels, ceux-ci sont en général reliés sur le port série, il faut donc envoyer des données sur ce port pour qu'elles apparaissent sur le terminal. Pour ce faire, on écrit dans /dev/ttyS0, par exemple.
Quand on utilise des terminaux virtuels en nombre indéfini depuis un serveur X, ils utilisent des fichiers spéciaux qui se comportent comme des pipes dans /dev/pts/... qui simulent le canal normalement emprunté.
Essaie d'ouvrir un terminal, puis un second. Dans le deuxième, tapes tty. Tu sauras à quel fichier ton xterm est attaché. Par exemple /dev/pts/1
Ensuite, depuis le premier, essaie de taper « echo "Bonjour" > /dev/pts/1 » et regarde ce qu'il se passe. Note : il se peut que tu n'aies pas les droits pour le faire.
L'idée est donc d'utiliser des fopen() ordinaires pour ouvrir des fichiers en lecture et écriture vers ce /dev et dont tu noterais les descripteurs « auxin » et « auxout », par exemple (par analogie avec stdin et stdout).
Ensuite, tu choisis la console dans laquelle tu veux travailler et tu les gère toutes deux de la même façon.
'faudrait que tu nous dises exactement ce que ton prof' attend de toi.
Attention, quand je dis graphique, c'est très basique; j'ai besoin de représenter un schéma de distribution électrique.
Oui, mais ça doit quand même être graphique (c'est-à-dire utiliser l'interface) ou bien est-ce que tu dois dessiner un environnement dans une console texte ? Parce que l'approche à avoir va être radicalement différente.
Dans le premier cas, tu vas ouvrir une connexion vers le serveur X ou exploiter une bibliothèque toute faite comme GTK ou Qt, gérer des événements, etc. tout en continuant à lire et écrire dans stdin/stdout pour dialoguer avec l'utilisateur.
Dans le second, tu ne travailleras qu'avec des flux type stdin/stdout mais il te faudra toi-même ouvrir un terminal et le fichier spécial qui lui est associé.
# Alors, à vue de nez, comme çà ...
Posté par Obsidian . En réponse au message Pour faire un post sur un PB GCC. Évalué à 2.
[^] # Re: En effet
Posté par Obsidian . En réponse au journal Un revers pour OOXML. Évalué à 4.
N'empêche que je bénis le type qui a inventé la balise Strike <s> ! On aurait pu l'appeler <ironic>, c'eût été exactement la même chose :-).
[^] # Re: Petit point !
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 2.
http://it.slashdot.org/it/07/07/18/0319203.shtml
# Mais qui on juge, là ?
Posté par Obsidian . En réponse au journal Tiscali contraint au filtrage. Évalué à 3.
Chez nous comme en belgique, puisque l'on ne peut pas apréhender le pirate, on va s'en prendre au transporteur.
[^] # Re: Énorme !
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 2.
Allez, un petit effort, tout le monde : déjà 5 diggs, plus que 345 pour que l'article passe dans les news populaires !
[^] # Re: Petit point !
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 2.
http://linuxfr.org/comments/850495.html#850495
# g-google ?
Posté par Obsidian . En réponse au journal Une nouvelle alternative a Google .... Évalué à 2.
[^] # Re: Voir source du script d'installation
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 2.
Le vrai problème majeur, comme tu dis, c'est que bien souvent, pour pouvoir faire quelque chose d'un tant soit peu ambitieux, on est obligé de passer Administrateur, et du coup, la majorité des utilisateurs qui émigrent sous UNIX exportent le même modèle de pensée, alors qu'à la base ce n'est quand même franchement pas compliqué : 99% des ressources se gèrent au travers du système de fichiers.
[^] # Re: Petit point !
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 3.
En particulier, beaucoup de fichiers de config appartiennent à root mais font également partie d'un groupe, ce afin que les utilisateurs autorisés puissent modifier ce qui relève de leurs prérogatives.
Il faut aussi tenir compte des pseudo-users, tels que postgresql, qui est assez tâtillon sur les droits d'accès.
Bref, si un script d'installation m'avait fait ce coup-là, ça m'aurait mis de très mauvaise humeur ...
[^] # Re: Petit point !
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 3.
Sans rire, un volontaire pour prévenir Samsung que leur bêtise risque de ternir la marque entière ?
[^] # Re: Voir source du script d'installation
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 4.
Ce post-ci, dans lequel l'auteur a au moins le mérite d'être clair sur ses intentions, est assez révélateur de ce qui doit se passer dans la tête de pas mal de monde : https://linuxfr.org/forums/15/22167.html
Et c'est inquiétant parce que cela confirme la probabilité d'un grand danger avec l'expansion du système dans le grand public : la faille de sécurité majeure viendra de l'utilisateur.
[^] # Re: youpi youpi matin!
Posté par Obsidian . En réponse au journal linuxfr dans télématin .... Évalué à 2.
(je poste mon troll en avance parce que demain je serai très occupé).
# Use The Shell, Luke
Posté par Obsidian . En réponse au journal Le meilleur éditeur de texte ? [FEU A VOLONTE]. Évalué à 3.
grep / grep -v
grep -v / grep
cut -b -15
grep
# Le jour du troll, c'est après-demain ...
Posté par Obsidian . En réponse au journal Une nouvelle raison de refuser Microsoft openXML. Évalué à 2.
CTJ (Comme Ton Journal) ? /o\
Punaise ! Ca fout les jetons !
Je vais être honnête, je n'ai encore lu ni ODF, ni OOXML en entier et je ne connais pas beaucoup de gens qui l'aient fait. Le fait que PasBill n'ait pas encore réagi laisserait à penser, à priori, que tout cela est vrai, mais présenté de cette façon, je ne suis pas sûr que l'on favorise l'adoption du premier.
Ce qui est malheureux, c'est d'être obligé d'exhiber ces dangers-là pour faire réagir le quidam, alors que le véritable enjeu est quand même de pouvoir certifier que le format ne pourra pas se faire enfermer à postériori.
Une fois que ceci est dit, et étant donné que je suis déjà entièrement gagné à la cause de l'ODF, j'aimerais bien savoir si de telles faiblesses ont déjà été détectées de son coté aussi, ou si personne ne creuse pour le moment ...
[^] # Re: ...
Posté par Obsidian . En réponse au journal je sais pas si quelqu'un l'a déja faite aujourd'hui.... Évalué à 2.
http://www.jesuismort.com/
Je connaissais pas (2005 apparement).
[^] # Re: code ascii
Posté par Obsidian . En réponse au message Lister tout les caractères existant.. Évalué à 2.
Tiens, ce serait marrant, ça : la GNU Font !
Tout plein de gentils moines typographistes tous en rang à respecter une belle charte graphique pour faire une fonte officielle complète ...
Ah ... Google me souffle à l'oreillette que
1) ça existe déjà,
2) ° Bloub °
3) C'est en bitmap
4) Ce n'est toujours pas complet
http://czyborra.com/unifont/HEADER.html
[^] # Re: code ascii
Posté par Obsidian . En réponse au message Lister tout les caractères existant.. Évalué à 2.
Voir plutôt du coté de :
http://fr.wikipedia.org/wiki/UTF-8
http://fr.wikipedia.org/wiki/Unicode
et voire même
$ man unicode
Par contre, ne rêve pas, tu ne pourras pas afficher la totalité des caractères de la planète (il n'y a qu'a imaginer le temps qu'il faudrait à une personne pour coder 65536 caractères dans un seul fichier de police).
[^] # Re: ils sont de retour !
Posté par Obsidian . En réponse au journal dell+ubuntu pour le reste du monde. Évalué à 3.
# Format de l'enquête
Posté par Obsidian . En réponse à la dépêche Enquêtes publiques probatoires de l'AFNOR concernant OOXML et ODF. Évalué à 10.
Mouais : y a encore du travail, quoi ! :-)
[^] # Re: Mondo Rescue
Posté par Obsidian . En réponse au message Ghost à chaud sous linux. Évalué à 4.
Les principales raisons pour lesquelles on ne le fait pratiquement jamais sont :
1) La duplication de la table des blocs défectueux du disque source qui ne correspondent bien sûr pas à ceux du disque destination. Ceci se résout en relançant un fsck -cc.
2) Les géométries des disques qui, eux, ne sont en général jamais du même modèle.
3) Le fait que sous Unix, tout est fichier. Il suffit donc de tout copier de filesystem à filesystem et de rappeler lilo ou grub depuis un liveCD pour résoudre le problème en entier.
Pour le reste, c'est de la redondance de machine qu'il faut faire si tu veux faire de la tolérance de panne. Au moins tu assures les défaillances matérielles dans le lot et le tout te coûte guère plus chère que des licences de logiciels dédiés.
En gros, si quelqu'un flingue une machine, une autre est déjà en ligne pour prendre le relais dans la milliseconde, le temps que tu répares la première. Même si UNIX permet de presque tout faire, y compris le genre d'accrobaties dont tu parles, on ne dépanne pas une voiture à 130 sur l'autoroute ...
[^] # Re: man diff
Posté par Obsidian . En réponse au message créer un patch pour rajouter des sous répertoire. Évalué à 2.
[^] # Re: Plus d'infos
Posté par Obsidian . En réponse au message Gérer deux sorties écran avec un programme en C. Évalué à 5.
Sinon, je veux dire que si tu comptes utiliser deux consoles, il faudra déjà ouvrir toi-même ces deux consoles. C'est normal dans le cas de la première puisque c'est depuis cette console que tu vas lancer ton programme. En outre, les flux d'entrée et de sortie seront ouverts pour toi.
Ensuite, pour gérer une deuxième console, essaie de voir comment on peut écrire dedans. La solution, c'est que chaque console est reliée à un fichier spécial (un /dev) qui permet de communiquer avec.
Plus précisément : dans le cas de terminaux physiques réels, ceux-ci sont en général reliés sur le port série, il faut donc envoyer des données sur ce port pour qu'elles apparaissent sur le terminal. Pour ce faire, on écrit dans /dev/ttyS0, par exemple.
Quand on utilise des terminaux virtuels en nombre indéfini depuis un serveur X, ils utilisent des fichiers spéciaux qui se comportent comme des pipes dans /dev/pts/... qui simulent le canal normalement emprunté.
Essaie d'ouvrir un terminal, puis un second. Dans le deuxième, tapes tty. Tu sauras à quel fichier ton xterm est attaché. Par exemple /dev/pts/1
Ensuite, depuis le premier, essaie de taper « echo "Bonjour" > /dev/pts/1 » et regarde ce qu'il se passe. Note : il se peut que tu n'aies pas les droits pour le faire.
L'idée est donc d'utiliser des fopen() ordinaires pour ouvrir des fichiers en lecture et écriture vers ce /dev et dont tu noterais les descripteurs « auxin » et « auxout », par exemple (par analogie avec stdin et stdout).
Ensuite, tu choisis la console dans laquelle tu veux travailler et tu les gère toutes deux de la même façon.
# Plus d'infos
Posté par Obsidian . En réponse au message Gérer deux sorties écran avec un programme en C. Évalué à 5.
Oui, mais ça doit quand même être graphique (c'est-à-dire utiliser l'interface) ou bien est-ce que tu dois dessiner un environnement dans une console texte ? Parce que l'approche à avoir va être radicalement différente.
Dans le premier cas, tu vas ouvrir une connexion vers le serveur X ou exploiter une bibliothèque toute faite comme GTK ou Qt, gérer des événements, etc. tout en continuant à lire et écrire dans stdin/stdout pour dialoguer avec l'utilisateur.
Dans le second, tu ne travailleras qu'avec des flux type stdin/stdout mais il te faudra toi-même ouvrir un terminal et le fichier spécial qui lui est associé.
# Select ?
Posté par Obsidian . En réponse au message Mon buffer de socket se remplit il ?. Évalué à 3.
[^] # Re: GNU coreutils
Posté par Obsidian . En réponse au message code source STTY. Évalué à 5.