Posté par xcomcmdr .
En réponse à la dépêche Sortie de la Mageia 4.
Évalué à 3.
Dernière modification le 04 février 2014 à 19:19.
Ça ne propose pas d'installer les paquets linguistiques manquants, comme le fait Ubuntu ?
Et y'a une logithèque qui installe tout ensemble (genre quand on installe libreoffice, ça ne prend pas juste LibreOffice, mais aussi les paquets de langue correspondant à la locale) ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Il m'arrive souvent de manquer des mises à jours (ie. je ne les fait pas quand elles sont publiées). Ça ne change rien à la fiabilité du système. Je les fait quand j'ai le temps, pas grave.
Quand il y a un problème, la marche à suivre est indiquée sur archlinux.org en page d'accueil.
Et ça roule comme ça depuis des années…
Bref, je soupçonne plutôt un problème dans l'interface chaise/clavier.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Tout ce que je dis c’est qu’il est naïf de croire l’excuse que « systemd c’est fait pour simplifier la vie des mainteneurs upstream »
Et pourtant, dans les faits c'est le cas. Comme par exemple, pour les mainteneurs de Archlinux.
C'est l'une des raisons du passage à systemd, et ils ont eu raison.
Et puis :
Myth: systemd being Linux-only is not nice to the BSDs.
Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it. And the same is true for the other Unixes in the world. Solaris has SMF, BSD has their own "rc" system, and they always maintained it separately from Linux. The init system is very close to the core of the entire OS. And these other operating systems hence define themselves among other things by their core userspace. The assumption that they'd adopt our core userspace if we just made it portable, is completely without any foundation.
Myth: systemd being Linux-only makes it impossible for Debian to adopt it as default.
Debian supports non-Linux kernels in their distribution. systemd won't run on those. Is that a problem though, and should that hinder them to adopt system as default? Not really. The folks who ported Debian to these other kernels were willing to invest time in a massive porting effort, they set up test and build systems, and patched and built numerous packages for their goal. The maintainance of both a systemd unit file and a classic init script for the packaged services is a negligable amount of work compared to that, especially since those scripts more often than not exist already.
Myth: systemd could be ported to other kernels if its maintainers just wanted to.
That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, …
And no, if you look at this list and pick out the few where you can think of obvious counterparts on other kernels, then think again, and look at the others you didn't pick, and the complexity of replacing them.
Myth: systemd is not portable for no reason.
Non-sense! We use the Linux-specific functionality because we need it to implement what we want. Linux has so many features that UNIX/POSIX didn't have, and we want to empower the user with them. These features are incredibly useful, but only if they are actually exposed in a friendly way to the user, and that's what we do with systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
The problem for over 30 years:
1) init starts a service process.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) service started falls over in a heap because sub process is still alive.
That 1 to 5 (rundown) to your normal init systems includes (Ubuntu's) upstart.
Solaris and systemd due to usage of zones and cgroups (respectively):
1) init starts a service process wrapped.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) Init system checks if anything is left in the cgroup or zone that should have been terminated.
6) service restarted stable.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Posté par xcomcmdr .
En réponse à la dépêche FreeBSD 10.
Évalué à 1.
Dernière modification le 02 février 2014 à 10:03.
Il n'y a qu'un seul processus :
fork + exec exec
Init --------------> Shell script -------> daemon
Dans tous les cas, utiliser les shell scripts pour contrôler les daemons ça donne ce résultat :
1) init starts a service process.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) service started falls over in a heap because sub process is still alive.
;-)
Beaucoup de code répetter, j'aimerais bein que tu m'explique ou. Tout le code commun se trouve dans rc et rc.subr. Si tu y vois du code répetté, tu es obligé d'admettre que la description des units est du code (déclaratif certes) répétté, car cela fonctionne exactement pareil.
Au lieu d'avoir un script d'init par distribution (qui font tous à peu près la même chose), il y a un fichier .service fourni par le projet concerné (exemple : Nginx) qui fonctionne partout sans modification.
Et comme ce n'est pas du code, il y a beaucoup moins de risques d'erreurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
(et non, ce n'est pas à cause d'une quelconque position domainante qui est une bonne excuse pour ne pas regarder le problème en face : il ne répond pas au besoin).
SI. C'est bien grâce à la livraison et préinstallation d'un système Windows (en fait ça a même débuté avec MS-DOS), que ses APIs se sont imposées aux développeurs tiers.
Et aujourd'hui on a une infinité d'applications qui ne fonctionne qu'avec Windows. Des milliers de gens qui n'ont connu que Windows sur le bureau. Ça continue depuis plus de 30 ans. Le nombre d'ordinateurs que l'on peut acheter avec Linux ou sans OS est ridicule. Windows est trop bien implanté (sur le desktop) pour que GNU/Linux le remplace un jour.
Ce ne sont pas les utilisateurs qui sont à convaincre, mais les constructeurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ah bon, j'ai sûrement rêvé quand SysV se bloquait lamentablement une fois sur deux sur un truc trivial comme le réseau. Alors que j'aurais bien voulu qu'il me démarre le display manager pendant ce temps. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
C'est comme HAL ou udev, c'est très bien, ça permet à un plus ample public de pouvoir monter des clés USBs facilement etc… mais est-ce vraiment utile dans tous les contextes?
udev sert à gérer le matériel, et c'est lui qui s'occupe de peupler /dev. Tu vois un exemple où il n'y en a pas besoin ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
L'intérêt de systemd n'est pas la vitesse de boot.
Tout à fait.
Si on voulais juste faire quelque chose de rapide, on peut le faire de pleins de façons
Non, pas vraiment. Le plus gros problème de la vitesse de boot sur SysV, c'est que SysV attend que chaque service ait fini de démarrer avant de démarrer un autre. Utiliser ureadahead, un SSD, ou autre astuce n'y changera pas grand chose du point de vue du temps de boot.
Le boot de systemd est parallélisable parce que les dépendances entre les services sont bien décrites, et que l'usage de udev et dbus font qu'elles sont plus faciles à gérer :
Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right. In fact, we never really sat down and optimized the last tiny bit of performance out of systemd. Instead, we actually frequently knowingly picked the slightly slower code paths in order to keep the code more readable. This doesn't mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.
Tu ne peux pas nier qu'il y a un vrai problème d'intégration des nouveautés. L'évolution pourrait très bien prendre en compte l'existant. C'est sur ce genre de petite chose que MacOS fait son beurre.
C'est le cas pour systemd, qui prend en charge les scripts d'init.
Quant à GNOME 3, quelques parties peuvent avoir besoin de logind ou d'un service équivalent (c'est pour ça que les patchs de Canonical pour que ça fonctionne sur Ubuntu ont été acceptés).
logind, lui, a besoin de systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Non. Les API Windows changent aussi souvent, depuis bien plus longtemps que Linux n'existe. Et pourtant, Windows est toujours largement dominant sur le desktop.
…Parce que MS fait attention à la rétrocompatiblité, que la plupart des applications tierces sont pour Windows, et que la vente liée Wintel est pratiquée depuis des décennies.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Mais c'est pas une bonne chose de changer aussi régulièrement les API linux, c'est peut être l'un des gros problèmes de linux sur desktop. C'est les API du bureau linux. Le problème n'est pas fonctionnel.
Non. Les API Windows changent aussi souvent, depuis bien plus longtemps que Linux n'existe. Et pourtant, Windows est toujours largement dominant sur le desktop.
Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.
Source ? Tu veux revenir à HAL + SysV ? Sérieusement ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Le clavier :
Le rétro-éclairage est vraiment classe et permet vraiment d'utiliser l'ordi dans le noir.
Au niveau du toucher je n'ai rien à redire, je le trouve très solide. Mais je n'ai pas beaucoup de goût en la matière. Tant que ça fonctionne, ça me va.
J'aime aussi le fait que les touches Home,PgUp,PgDown,et Fin soient enfin revenues (juste au dessus du pavé numérique)
Il y a aussi pas d'espace sous les touches, ce qui m'évite d'avoir des cochonneries dans le clavier (comme des poils de chien).
Le touchpad est parfois touché quand on écrit, mais après un temps d'adaptation ce n'est plus trop le cas. Et de toutes façons, sous Linux on peut le désactiver pendant la touche. Il y a aussi une touche Fn - F9 pour le désactiver, et j'utilise une règle udev pour le désactiver une fois qu'une souris USB est detectée (et inversement).
Pour la coque en alu, je le trimballe souvent. Ça tient très bien malgré le fait qu'il se prenne parfois quelques chocs légers. Après vu qu'il est tout neuf, j'ai pas osé trop tester la résistance.
L'écran en 1366x768 dans mon cas j'avais pas fait gaffe. :/
Mais ça me gêne pas trop. A part ça, l'angle de vision est bien meilleure que sur mon ancien PC, et il est beaucoup moins sombre.
Le son est très bon, très clair, et peut être très très fort. :o
Il y a même une sortie pour le caisson de basse portable (donné avec l'ordi, de même que la sacoche pour l'ordi), et le son est encore meilleur quand ce dernier est branché.
Elles sont très discrètes visuellement.
Sur l'ordi c'est marqué "Audio by Bang & Olufsen ICEpower".
(sur mon ancien, c'était des Altec Lansing qui étaient pas mal du tout)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
ca me rassure ce que tu dis, car encore une fois prtant labélisé haut de gamme le HP était vrmt bruyant, et je n'était pas du tout en train de faire des tâches lourdes.
HP est à éviter. De même que ACER. J'éviterais les Toshiba Satellite aussi (j'ai connu quelqu'un qui a eu un Toshiba Satellite pendant quelques mois : le temps qu'il crame tout seul).
Quant à l'aspect silencieux, mon ancien (ASUS x71SL) a duré 5 ans, et il était très silencieux (enfin, quand il était propre).
Ma soeur a eu un eeePC 1005 HA, il était plutôt bruyant (mais c'était un Intel Atom, le genre de merde qui chauffe à fond pour afficher un JPG…).
Maintenant elle a un ASUS eeePC 1225B, qui est lui aussi très silencieux.
Tu devrais chercher dans la série des ASUS N. Le mien (un i5, enfin la variante avec deux coeurs physiques et deux coeurs logiques supplémentaires grâce à l'HyperThreading) est un ASUS N56VV.
Il existe aussi l'ASUS N56-VZ : https://gist.github.com/loonies/6009671 (pour mon N56VV je n'ai pas de mise à jour de l'UEFI, et je n'en ai pas eu besoin, mais c'est le guide que j'ai plus ou moins suivi pour installer Arch)
Au delà, je ne peux pas décrypter tous les chiffres et lettres auxquels font références les trucs tels que N750JV-T4115H. Tout ce que je peux te dire, c'est qu'il fonctionne très bien sous Linux, et que le mien en est une copie conforme (visuellement du moins - après l'écran est plus grand, et y'a un i7 au lieu de i5).
Je crains que tu as de longues heures d'épluchage de sites Web, la série N semble avoir beaucoup de variantes.
Et sur un ASUS N56VZ, en lisant le guide sur GitHub on se rend compte une mise à jour de l'UEFI est très conseillée pour faire fonctionner Linux, ce qui est un peu inquiétant.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
J'ai eu un 17 pouces, et je confirme : c'est trop lourd, trop grand, trop encombrant, et la résolution d'écran pas si grande (1440x900, aujourd'hui j'ai un 15 pouces et c'est presque pareil : 1366x768).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
J'ai un ASUS de la même série, et très similaire au niveau des specs, et du look (identique), et le prix était très proche.
Il est très silencieux, très rapide, très léger, et fonctionne parfaitement.
Y'a juste l'écran qui est en 1366x768, pour un 15 pouces c'est un peu juste !
Le clavier est rétro éclairé, et la finition générale excellente.
750 Gio de HDD à 7200 RPM
6 Gio de RAM beau matériaux : aluminium, clavier rétro éclairé, je veux avoir une belle machine quoi. Bien finie.
Intel i5 (2 coeurs physiques, 2 coeurs logiques)
Ethernet : oui, 4 ports USB (dont de l'USB 3), wifi et bluetooth, sortie HDMI et VGA.
Malheureusement il a un système graphique NVIDIA Optimus (donc deux cartes graphiques : un VGA controller Intel HD 4000, et un 3D controller Nvidia Geforce GT 750M), mais de nos jours ça fonctionne bien sous Linux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
étant utilisateur de yaourt sous Archlinux, un des truc que j'aime bien c'est la séparation des "nouvelles version" VS "update de packaging".
C'est pas spécifique à yaourt, ça vient des informations de versions du paquet (pkgver et pkgrel dans le pkgbuild). Je crois bien qu'on retrouve un équivalent de ces deux champs dans les paquets au format Debian.
Après, c'est vrai que yaourt l'affiche de manière conviviale avant l'installation :
max-laptop% yaourt -Syu
[sudo] password for max:
:: Synchronisation des bases de données de paquets…
core est à jour
extra 1530,4 KiB 480K/s 00:03 [----------------------] 100%
community 2,0 MiB 476K/s 00:04 [----------------------] 100%
multilib est à jour
==> Continuer la mise à jour ? [O/n]
==> [V]oir les détails. Sélectionner les paquets [M]anuellement.
==> --------------------------------------------------------------
==>
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Qu'apporte Mageia ?
Posté par xcomcmdr . En réponse à la dépêche Sortie de la Mageia 4. Évalué à -1.
Et si à l'époque on regardait archlinux.org, on avait toutes les infos pour appliquer la mise à jour sans problème ! La preuve, je l'ai fait !
Bref, l'utilisateur qui fait nawak et qui accuse le système, classique !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Qu'apporte Mageia ?
Posté par xcomcmdr . En réponse à la dépêche Sortie de la Mageia 4. Évalué à 3. Dernière modification le 04 février 2014 à 19:19.
Ça ne propose pas d'installer les paquets linguistiques manquants, comme le fait Ubuntu ?
Et y'a une logithèque qui installe tout ensemble (genre quand on installe libreoffice, ça ne prend pas juste LibreOffice, mais aussi les paquets de langue correspondant à la locale) ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Qu'apporte Mageia ?
Posté par xcomcmdr . En réponse à la dépêche Sortie de la Mageia 4. Évalué à 0.
Il m'arrive souvent de manquer des mises à jours (ie. je ne les fait pas quand elles sont publiées). Ça ne change rien à la fiabilité du système. Je les fait quand j'ai le temps, pas grave.
Quand il y a un problème, la marche à suivre est indiquée sur archlinux.org en page d'accueil.
Et ça roule comme ça depuis des années…
Bref, je soupçonne plutôt un problème dans l'interface chaise/clavier.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 3.
Windows 95 existera toujours !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 5. Dernière modification le 03 février 2014 à 23:35.
Pas du tout.
Et pourtant, dans les faits c'est le cas. Comme par exemple, pour les mainteneurs de Archlinux.
C'est l'une des raisons du passage à systemd, et ils ont eu raison.
Et puis :
Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it. And the same is true for the other Unixes in the world. Solaris has SMF, BSD has their own "rc" system, and they always maintained it separately from Linux. The init system is very close to the core of the entire OS. And these other operating systems hence define themselves among other things by their core userspace. The assumption that they'd adopt our core userspace if we just made it portable, is completely without any foundation.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Qu'apporte Mageia ?
Posté par xcomcmdr . En réponse à la dépêche Sortie de la Mageia 4. Évalué à 0.
[référence nécessaire]
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 3.
Mouais, du temps de SysV, quasiment à chaque fois où j'arrêtais un daemon bloqué, je me retrouvais avec des processus zombie.
Les control groups, c'est mieux :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à quoi?
Posté par xcomcmdr . En réponse à la dépêche FreeBSD 10. Évalué à 1. Dernière modification le 02 février 2014 à 10:03.
Dans tous les cas, utiliser les shell scripts pour contrôler les daemons ça donne ce résultat :
;-)
Au lieu d'avoir un script d'init par distribution (qui font tous à peu près la même chose), il y a un fichier .service fourni par le projet concerné (exemple : Nginx) qui fonctionne partout sans modification.
Et comme ce n'est pas du code, il y a beaucoup moins de risques d'erreurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 2. Dernière modification le 01 février 2014 à 17:38.
SI. C'est bien grâce à la livraison et préinstallation d'un système Windows (en fait ça a même débuté avec MS-DOS), que ses APIs se sont imposées aux développeurs tiers.
Et aujourd'hui on a une infinité d'applications qui ne fonctionne qu'avec Windows. Des milliers de gens qui n'ont connu que Windows sur le bureau. Ça continue depuis plus de 30 ans. Le nombre d'ordinateurs que l'on peut acheter avec Linux ou sans OS est ridicule. Windows est trop bien implanté (sur le desktop) pour que GNU/Linux le remplace un jour.
Ce ne sont pas les utilisateurs qui sont à convaincre, mais les constructeurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 4. Dernière modification le 01 février 2014 à 16:13.
Ah bon, j'ai sûrement rêvé quand SysV se bloquait lamentablement une fois sur deux sur un truc trivial comme le réseau. Alors que j'aurais bien voulu qu'il me démarre le display manager pendant ce temps. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 2.
udev sert à gérer le matériel, et c'est lui qui s'occupe de peupler /dev. Tu vois un exemple où il n'y en a pas besoin ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Yet another painting program
Posté par xcomcmdr . En réponse au message Les supports physiques dans les logiciels de dessin. Évalué à 1.
Krita
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 0. Dernière modification le 01 février 2014 à 11:56.
Tout à fait.
Non, pas vraiment. Le plus gros problème de la vitesse de boot sur SysV, c'est que SysV attend que chaque service ait fini de démarrer avant de démarrer un autre. Utiliser ureadahead, un SSD, ou autre astuce n'y changera pas grand chose du point de vue du temps de boot.
Le boot de systemd est parallélisable parce que les dépendances entre les services sont bien décrites, et que l'usage de udev et dbus font qu'elles sont plus faciles à gérer :
http://0pointer.de/blog/projects/the-biggest-myths.html
OpenRC est rapide pour la même raison : il démarre les services de manière parallèle.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 3.
C'est le cas pour systemd, qui prend en charge les scripts d'init.
Quant à GNOME 3, quelques parties peuvent avoir besoin de logind ou d'un service équivalent (c'est pour ça que les patchs de Canonical pour que ça fonctionne sur Ubuntu ont été acceptés).
logind, lui, a besoin de systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 3.
…Parce que MS fait attention à la rétrocompatiblité, que la plupart des applications tierces sont pour Windows, et que la vente liée Wintel est pratiquée depuis des décennies.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 1.
Non. Les API Windows changent aussi souvent, depuis bien plus longtemps que Linux n'existe. Et pourtant, Windows est toujours largement dominant sur le desktop.
Source ? Tu veux revenir à HAL + SysV ? Sérieusement ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . En réponse au journal Debian à l'heure du choix. Évalué à 10. Dernière modification le 31 janvier 2014 à 14:10.
Tu confonds API et "API DBUS".
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: MSI
Posté par xcomcmdr . En réponse au message Conseil d'achat PC portable. Évalué à 2. Dernière modification le 31 janvier 2014 à 01:10.
Le clavier :
Le rétro-éclairage est vraiment classe et permet vraiment d'utiliser l'ordi dans le noir.
Au niveau du toucher je n'ai rien à redire, je le trouve très solide. Mais je n'ai pas beaucoup de goût en la matière. Tant que ça fonctionne, ça me va.
J'aime aussi le fait que les touches Home,PgUp,PgDown,et Fin soient enfin revenues (juste au dessus du pavé numérique)
Il y a aussi pas d'espace sous les touches, ce qui m'évite d'avoir des cochonneries dans le clavier (comme des poils de chien).
Le touchpad est parfois touché quand on écrit, mais après un temps d'adaptation ce n'est plus trop le cas. Et de toutes façons, sous Linux on peut le désactiver pendant la touche. Il y a aussi une touche Fn - F9 pour le désactiver, et j'utilise une règle udev pour le désactiver une fois qu'une souris USB est detectée (et inversement).
Pour la coque en alu, je le trimballe souvent. Ça tient très bien malgré le fait qu'il se prenne parfois quelques chocs légers. Après vu qu'il est tout neuf, j'ai pas osé trop tester la résistance.
L'écran en 1366x768 dans mon cas j'avais pas fait gaffe. :/
Mais ça me gêne pas trop. A part ça, l'angle de vision est bien meilleure que sur mon ancien PC, et il est beaucoup moins sombre.
Le son est très bon, très clair, et peut être très très fort. :o
Il y a même une sortie pour le caisson de basse portable (donné avec l'ordi, de même que la sacoche pour l'ordi), et le son est encore meilleur quand ce dernier est branché.
Elles sont très discrètes visuellement.
Sur l'ordi c'est marqué "Audio by Bang & Olufsen ICEpower".
(sur mon ancien, c'était des Altec Lansing qui étaient pas mal du tout)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: MSI
Posté par xcomcmdr . En réponse au message Conseil d'achat PC portable. Évalué à 2.
Oui les auto-collants sont là, mais ça s'enlève facilement.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: MSI
Posté par xcomcmdr . En réponse au message Conseil d'achat PC portable. Évalué à 2. Dernière modification le 30 janvier 2014 à 17:34.
HP est à éviter. De même que ACER. J'éviterais les Toshiba Satellite aussi (j'ai connu quelqu'un qui a eu un Toshiba Satellite pendant quelques mois : le temps qu'il crame tout seul).
Quant à l'aspect silencieux, mon ancien (ASUS x71SL) a duré 5 ans, et il était très silencieux (enfin, quand il était propre).
Ma soeur a eu un eeePC 1005 HA, il était plutôt bruyant (mais c'était un Intel Atom, le genre de merde qui chauffe à fond pour afficher un JPG…).
Maintenant elle a un ASUS eeePC 1225B, qui est lui aussi très silencieux.
Tu devrais chercher dans la série des ASUS N. Le mien (un i5, enfin la variante avec deux coeurs physiques et deux coeurs logiques supplémentaires grâce à l'HyperThreading) est un ASUS N56VV.
Il existe aussi l'ASUS N56-VZ : https://gist.github.com/loonies/6009671 (pour mon N56VV je n'ai pas de mise à jour de l'UEFI, et je n'en ai pas eu besoin, mais c'est le guide que j'ai plus ou moins suivi pour installer Arch)
Au delà, je ne peux pas décrypter tous les chiffres et lettres auxquels font références les trucs tels que N750JV-T4115H. Tout ce que je peux te dire, c'est qu'il fonctionne très bien sous Linux, et que le mien en est une copie conforme (visuellement du moins - après l'écran est plus grand, et y'a un i7 au lieu de i5).
Je crains que tu as de longues heures d'épluchage de sites Web, la série N semble avoir beaucoup de variantes.
Et sur un ASUS N56VZ, en lisant le guide sur GitHub on se rend compte une mise à jour de l'UEFI est très conseillée pour faire fonctionner Linux, ce qui est un peu inquiétant.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: MSI
Posté par xcomcmdr . En réponse au message Conseil d'achat PC portable. Évalué à 2.
Oups, une partie était une citation du journal…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: 17" c'est bien trop grand
Posté par xcomcmdr . En réponse au message Conseil d'achat PC portable. Évalué à 3.
J'ai eu un 17 pouces, et je confirme : c'est trop lourd, trop grand, trop encombrant, et la résolution d'écran pas si grande (1440x900, aujourd'hui j'ai un 15 pouces et c'est presque pareil : 1366x768).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: MSI
Posté par xcomcmdr . En réponse au message Conseil d'achat PC portable. Évalué à 3. Dernière modification le 30 janvier 2014 à 15:56.
J'ai un ASUS de la même série, et très similaire au niveau des specs, et du look (identique), et le prix était très proche.
Il est très silencieux, très rapide, très léger, et fonctionne parfaitement.
Y'a juste l'écran qui est en 1366x768, pour un 15 pouces c'est un peu juste !
Le clavier est rétro éclairé, et la finition générale excellente.
750 Gio de HDD à 7200 RPM
6 Gio de RAM beau matériaux : aluminium, clavier rétro éclairé, je veux avoir une belle machine quoi. Bien finie.
Intel i5 (2 coeurs physiques, 2 coeurs logiques)
Ethernet : oui, 4 ports USB (dont de l'USB 3), wifi et bluetooth, sortie HDMI et VGA.
Malheureusement il a un système graphique NVIDIA Optimus (donc deux cartes graphiques : un VGA controller Intel HD 4000, et un 3D controller Nvidia Geforce GT 750M), mais de nos jours ça fonctionne bien sous Linux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Xfce core devs
Posté par xcomcmdr . En réponse à la dépêche 1er week-end de février, en Belgique, au FOSDEM. Évalué à 4.
http://wiki.xfce.org/events/2014/fosdem
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Très bonne idée :)
Posté par xcomcmdr . En réponse au journal apti 0.5 : frontend à aptitude. Évalué à 2.
C'est pas spécifique à yaourt, ça vient des informations de versions du paquet (pkgver et pkgrel dans le pkgbuild). Je crois bien qu'on retrouve un équivalent de ces deux champs dans les paquets au format Debian.
Après, c'est vrai que yaourt l'affiche de manière conviviale avant l'installation :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)