freem a écrit 5059 commentaires

on n'a pas l'info exacte, mais sait qu'il y a un bon revenu deja, sauf que, comme souligne(pas par moi, j'avoue avoir oublie ce point important), bon revenu c'est vague, et si on enleve les 2/3, ca peut etre merdique.
J'avoue penser par reflexe d'employe que bon revenu est rapport a la charge de travail: 2k€/m net pour 70h/s, c'est pas un bon revenu (en dessous du smic je crois meme).

A mon avis, le probleme n'est juste lie aux charges, mais aussi au tout controlé: difficile j'imagine d'accepter de ceder des responsabilites quand la boite necessite du taf de qualite pour survivre, ce qui est je pense le cas de toutes les boites avec moins de 10 personnes et qui produisent, et quand on a toujours tout fait tout seul. les 1ers employes cadoit etre dur.

je connais aussi, assez proche du sens ici, la partie qui reste au vendeur d'un carnets de tickets, dont une sous feuille est ecrite en meme temps que la 1ere. pas usite par les particuliers, mais encore dans certains tertiaires (enfin, ya 3-4 ans)

De nos jours peut-etre, mais y'a 10 ans?

Et a 70h/semaine, pas moyen d'avoir quelqu'un de plus pour l'épauler?
Dans la liste des tâches que tu cites, à priori, rien n'empêche d'avoir plusieurs personnes.

Accessoirement, c'est pas parce que t'as les sources que tu as quelqu'un qui peut les comprendre, et parfois lire du code source est plus difficile que lire de l'assembleur…

Surtout que ce commentaire n'apporte pas de solution à l'absence de solution de l'article.

C'est quoi, le rapport?

si ça inclue des commandes qui écrivent dans des endroits protégés (autres que $HOME et /tmp en gros) ou qui sont pas dans le $PATH des user normaux, probable en effet.

M'enfin, au dela de ça, je me demande pourquoi ne pas utiliser directement les paquets logiciels de la distrib hébergée? Je veux dire, de mémoire, y'a des paquets xorg avec des "pilotes" pour virtualbox?

J'imagine qu'il faudrait faire attention si ça dépends de la libcaca.

Il paraît qu'il existe aussi des gens qui font leur taf correctement, même s'ils savent qu'ils vont partir à très court terme parce qu'ils ne veulent pas continuer de travailler dans leurs conditions présentes.
Par exemple, mon dernier contrat (la 1ère fois et j'espère la dernière) que j'ai rompu une période d'essai, j'ai fini par «résoudre» (identifier la cause réelle en fait, et donc résolu dans la foulée) l'un des problèmes majeurs(1) ayant motivé ma démission le dernier jour et achever ma 1ère compilation du soft sur lequel je devais bosser au bout de plus de 2 mois. Ça faisait pratiquement 1 mois que je cherchais un autre employeur.

N'empêche, j'ai fait ce que j'ai pu jusqu'à la fin.
Je ne dirais pas que c'est une bonne chose d'avoir envie de partir en moins de 3 mois, mais si l'employé est honnête et franc (bon, faut aussi savoir prendre du recul et pas juste envoyer chier le monde en crachant sur les collègues/services/whatever qui ont causé la démotivation) je pense que ça peut devenir une bonne chose pour l'entreprise, qui peut en tirer des leçons.
Je ne sais pas ce qu'ils sont devenus, mais j'ai dit ce que je pensais (en argumentant, à froid et en analysant les problèmes des divers côtés, le mien inclus) de la boîte quand ils m'ont demandé pourquoi je partais, et le fait d'avoir fait mon taf jusqu'à la fin à permis de confirmer que mes raisons étaient pas totalement déconnantes.

Je doute d'être le seul à avoir ce type de mentalité.

1: pour faire court: les devs d'un côté, un service d'admin «IT» de l'autre.
L'IT installe et maintien les systèmes de base: passwords UEFI, activation du matos (accélération matériel pour les VMs, par exemple), OS, softs installés, comptes utilisateurs éventuellement admin locaux, création et gestion des machines virtuelles, etc.
Les devs ont la responsabilité d'installer quelques outils supplémentaires dont ils ont besoin, qui peuvent être des patchs MS spécifiques (pour VS, dans le cas qui m'intéresse) considérés expérimentaux ainsi que l'installation des VMs (préalablement créées et configurées par l'IT, bien sûr).
In fine, le problème majeur qui m'empêchait de travailler, le plugin de VS vital, ne répondait juste pas. La cause? Une machine mal (voire pas) nettoyée.
Je passe sur les autres anecdotes désagréables qui se sont ajoutées à ce problème.

Chiffres amusants, dommage que l'on ne puisse savoir qui rompt le plus les périodes d'essai: l'employé ou l'employeur? Bon, après, je doute que l'on puisse facilement avoir l'information de manière fiable.

on ne te demande pas ta carte d'identité en entrant.

Ça dépend, si t'as une tête un peu trop jeune et que tu demandes un truc alcoolisé, le patron peut le faire (je dirais même en a l'obligation). Mais disons que la consommation d'alcool est une feature des gens identifiés comme majeurs (bien que la méthode d'identification numéro 1 soit de qualité douteuse) :)

L’insécurité, les fabricants de processeurs s’en chargent directement !

Meltdown et Spectre sont si loin que ça dans les mémoires? L'insécurité, ce n'est pas forcément voulu.
Sinon, il y a pas mal de code auquel personne n'a accès qui fait l'interface entre le matériel et les pilotes de périphérique. S'il faut vraiment citer un exemple de ce type de logiciel, dont la sécurité reste à prouver (dans un sens comme dans l'autre à ma connaissance) on peut parler de l'IME.

Rien n'interdit aux gens de continuer a chercher un boulot mieux adapte une fois en poste

C'est sûr, à condition de ne pas être trop cassé à la fin de la journée et d'avoir la possibilité de prendre des RDV facilement sur le temps de travail.

Surtout que démissionner en période d'essai est assez facile.

C'est un fait, ça m'est arrivé une fois.

Il me semble meme que pas mal de personnes font ca.

Vraiment? Je pense que je suis le seul que je connaisse qui l'ait fait? Enfin, c'est pas comme si je connaissais tant de monde que ça, je te l'accorde, mais j'ai jamais eu l'impression que c'était très utilisé (que ce soit par les patrons ou les employés, pour le coup: les patrons semblent préférer les CDD courts en guise de période d'essai, pour une raison que je ne connais pas).
Bon, je répond juste sur mes impressions et mon expérience personnelle, hein, si y'avais des chiffres un peu plus scientifiques sur le sujet, ça serait intéressant, pour confirmer ou infirmer les opinions des gens sur cette fameuse période d'essai, notamment (et pour la culture perso aussi).

j'ai utilisé les lignes de commande pour exécuter le fichier "VBoxLinuxAdditions.run" seulement je n'arrive pas à exécuter le fichier, car je n'ai pas les droits…

Il faut que le fichier soit marqué exécutable pour ça, root ou pas. Pour le marquer exécutable avec une interface graphique (d'autant que ça change selon l'environnement en plus), je ne sais pas comment faire, mais en ligne de commande: chmod +x.

En même temps, si c'est juste envoyer des SMS et prendre des photos, pourquoi prendre un smartphone?

C'est moi, ou en général on associe le terme cloud à l'idée d'avoir des données auxquelles les autres n'ont pas accès sur le PC de quelqu'un d'autre? Parce que si c'est pas moi, je ne vois pas comment on peut faire sans méthode d'identification à minima, ce qui implique la création d'un compte?

Tu noteras que certains outils interactifs utilisent aussi ce principe, et plutôt avec bonheur: je pense surtout à mpd et sa pléthore de clients (je crois que kakoune utilise le même principe, mais je ne suis pas sûr, faudrait vraiment que je prenne le temps de voir comment utiliser la coloration syntaxique avec cet outils pour le tester à fond), mais on peut aussi considérer qu'une «application web» c'est un travail de découpe: client lourd (j'ai du mal à considérer un navigateur internet + interface web blindée de JS qui fait papa-maman en fonction de l'OS, de la langue, de la résolution, … comme étant léger), serveur web, base de données, peut-être communication avec d'autres processus derrière…

Bref, ce principe peut aussi marcher avec l'interactif, c'est juste que, forcément, on ne peux pas se limiter à un tuyau à sens unique.

Pour Debian, au cas ou tu en aies besoin, tu as dans /var/cache/apt/archives les paquets que tu as déjà installés (dossier qui tend à grossir pas mal, d'ailleurs) si rien ne les vide régulièrement. Du coup, tu as peut-être moyen de trouver une version plus ancienne du paquet glib qui ne pose pas le problème, en espérant que la plus récente ne soit pas imposée par un autre paquet.

Mais peu importe, sous latin-9 (si je me plante pas), tu peux y avoir accès via AltGr+Shift+w et AltGr+Shift+x (sans le Shift, ça donne «», utile aussi).

la présence d'un bot d'indexation montre qu'ils sont à minima hybrides.

Si être hybride c'est utiliser le résultat des autres en plus de son propre bot, alors je doute qu'il reste des moteurs "purs". Par exemple, il me semble bien que google exploite les résultats d'une recherche wikipedia pour affiner les choses.

Il y a le moteur de recherche symbolhound pour cette problématique mais ce n'est pas toujours extraordinaire.

Oh bon sang, ça, ça peut m'aider! J'ai le même problème que toi, par rapport à l'interprétation de mes recherches, et ça me gonfle sévère.

l'ère des 8 bits a été une époque bénie pour apprendre l'informatique

Pour les bases de programmation de µcontrôleur, sûrement, oui. J'ai aussi codé en mode réel sur du 16bits, c'était clairement plus simple. Plus simple aussi de cramer la machine en se trompant d'adresse mémoire.
Par contre, pour des trucs plus compliqués, pas vraiment non. D'ailleurs, c'était passionnant, le graphisme en 16 couleurs… ou pas. Bon, j'exagère, je sais: c'était 256 couleurs en 320x200, vive le mode 13h. Et avec quelques bidouilles d'asm, on pouvait doubler la résolution, mais bon, pas à franchement parler le plus simple.
Je gage que c'est toujours dispo sur nos archis 64bits, le mode réel, d'ailleurs.

Je dirais que je suis quand même assez d'accord sur le fait qu'il soit pénible de galérer autant juste pour afficher des formes simple à l'écran. Ceci dit, à quelqu'un qui veut vraiment apprendre du code, je ne conseille pas de faire du graphismes ou des jolies fenêtres en 1er: d'abord la ligne de commande, ensuite un peu de SDL pour avoir un minimum de compréhension, et après oui, utiliser les trucs plus classe. Sachant qu'avec la SDL on n'est pas limité comme à l'époque en terme de résolution et de nombre de couleurs (mais, c'est vrai, pas de commande pour générer du son ou des images de façon procédurale. Pas son job, faut dire.).

quand on les allumait, elle étaient immédiatement utilisables (pas de temps de boot)

Vraiment? Pas de POST, pas de BIOS? Rien que le POST de mes 1ères machines (16bits, encore une fois… quoique, si ça se trouve j'ai connu du 8bits et je m'en souviens pas. Je veux dire, en tant que PC pour bosser, sinon c'est certain que j'ai connu) mettait plusieurs secondes… passer l'étape complète du BIOS mettait plusieurs dizaines de secondes.

Et surtout : il était doté d'un mode direct !

Il me semble bien que c'est le cas également de tous les langages interprétés que je connais, anciens ou modernes.

Non seulement le néophyte avait tout de suite une réaction de sa machine la première fois qu'il la sollicitait, mais on pouvait très rapidement enchaîner tout de suite sur des choses plus élaborées…

Hum. De nos jours, il est possible au néophyte de faire des choses très élaborées avec Excel, sans jamais taper la moindre ligne de code. Malheureusement pour les devs qui doivent rattraper les dégâts, d'ailleurs :)

on pourrait mettre ça dans la notice d'un ordinateur neuf

Les notices ont été supprimées parce que ça coûte cher à imprimer et que de toute façon les gens ne les lisent pas. Ironiquement, c'est moi qui lis le plus souvent les notices des appareils dans ma famille, alors que je suis celui qui a la plus grande maîtrise de cet outil. Et je râle pas mal quand je dois aller chercher la doc sur le net ou dans les tréfonds d'un CD…

• de lourdeur de protocole (HTTP c'était pas fait pour les notification 24h/24)

En effet, mais j'ai une question: j'imagine que ça utilise des websockets (une connexion bidirectionnelle en flux, bâtie sur un protocole pas du tout fait pour ça, lui-même bâti sur le protocole TCP qui, lui, est fait pour envoyer un flux de données de façon bidirectionnelle…), et il semblerait que ce truc n'ait qu'un overhead limité comparativement à TCP brut.
Problème: je n'ai jamais vu d'explications supportant cette théorie?

• d'interopérabilité : ceux qui ont déjà une solution d'IM établie pourraient juste ajouter ce compte dedans.

D'un autre côté, le HTTP passe facilement les proxy sans configuration supplémentaire. C'est le seul argument en faveur des websockets qui ne me passe pas trop en travers de la gorge, en fait (après, je n'ai p'tet pas tout compris, j'avoue ne pas avoir lu la RFC).

je n'ai pas de terminal dans la version d'essai de Ubuntu

Le terme version d'essai donne l'impression que tu utilises un shareware genre winrar :D

À priori, les environnements graphiques utilisent souvent le raccourcis Alt+F2 pour lancer le lanceur d'applications. De là, tu devrais pouvoir t'en sortir en lançant x-terminal-emulator. YMMV.

Dans le lien, il est dit (je traduis à la louche):

"Ajouter la ligne autologin-user=ton_login" dans le fichier /etc/lightdm/lightdm.conf. Le "ton_login" correspond au nom que tu entres pour te connecter.

Pour faire ça, il te faut donc (le fichier se situe dans un espace protégé) avoir les droits root.
Pour les avoir, soit tu te connecte directement en tant que root (pas super conseillé en graphique, mais bon…), soit tu passes par un terminal (plus compliqué, il faut savoir lancer une commande) pour lancer un éditeur de texte (pas un traitement de texte hein, pas libreoffice quoi) via su ou sudo, soit tu passe par un frontal graphique qui sait récupérer les droits (gksu, par exemple).