/* Topic des codeurs [8] */

HP · Le 05/03/2013, à 18:12

:!pakman a écrit :

Je ne connait pas Ruby, mais j'ai l'impression que ça fournit exactement le même service que la plateforme Python...

Je sais pas… moi je trouve le modèle objet de Ruby plus abouti, sans compter la metaprog'… de plus, l'identation qui délimite les blocs, ça peut finir par lasser !

grim7reaper · Le 05/03/2013, à 18:36

HP a écrit :

moi je trouve le modèle objet de Ruby plus abouti

En quoi ?

HP a écrit :

sans compter la metaprog'…

qui existe aussi en Python…
À moins que tu ne souhaites soulever un point précis ?

HP · Le 05/03/2013, à 18:40

grim7reaper a écrit :

HP a écrit :
moi je […]
En quoi ?

De façon, toute personnelle…

grim7reaper · Le 05/03/2013, à 18:45

Choix personnel ou pas, ça n’empêche pas d’expliquer pourquoi tu trouves que le modèle objet de Ruby est meilleur. Ça peut permettre d’apprendre des trucs ou de faire débattre un peu les gens sur leurs critères pour définir un « bon » modèle objet.

Mais bon, ne te fatigues pas. J’ai bien compris que l’argumentation c’est pas ton trip.
Y’a juste à aller à la page précédente pour en avoir un exemple :

HP a écrit :

Mindiell a écrit :
Les tests unitaires ne servent pas à grand chose si tu ne dev pas en mode TDD […]
Faux

Dernière modification par grim7reaper (Le 05/03/2013, à 18:46)

The Uploader · Le 05/03/2013, à 18:59

grim7reaper a écrit :

HP a écrit :
moi je trouve le modèle objet de Ruby plus abouti
En quoi ?

Euh Ruby n'a pas d'héritage multiple (même si les mixin peuvent l'émuler), donc déjà c'est mal parti. Mais pour ce que ça vaut :
http://stackoverflow.com/questions/1113 … vice-versa

Intéressant, oui. De là à dire que le modèle objet est plus abouti, faudrait déjà définir ce qu'est le modèle objet ultime...

HP a écrit :

de plus, l'identation qui délimite les blocs, ça peut finir par lasser !

Pourtant c'est DRY-compliant.

Dernière modification par The Uploader (Le 05/03/2013, à 19:03)

Pylades · Le 05/03/2013, à 19:46

@ Rolinh : à un moment ils se justifient de ne pas avoir choisi Wayland. Mais venant d’Ubuntu, j’ai du mal à avoir confiance et à penser que ce sera une vraie avancé, je vois plus venir un truc tout bloated.

Cela dit, je suis super jaloux du nom.

The Uploader a écrit :

Quand RedHat sort PulseAudio ou systemd, ils réinventent la roue aussi. Mais comme la roue d'avant était carrée, on leur en veut pas.

Et là-dessus, ils pondent des roues en losange…

The Uploader · Le 05/03/2013, à 20:49

Pylade a écrit :

Et là-dessus, ils pondent des roues en losange…

Plaît-il ?

J'ai beaucoup moins de problèmes de mixage des différents flux audio avec pulseaudio.

Quant à systemd, adieu les scripts rc crasseux.

Pylades · Le 05/03/2013, à 21:14

Je pense qu’il est inutile de revenir sur les critiques de PulseAudio…

Quand à systemd, il est aussi crasseux que les scripts. Pour plein de raisons. Les scripts, ils avaient un fonctionnement intelligible. Systemd, ça ressemble plus de la boîte noire à laquelle il est difficile de bitter quelque chose. Et puis c’est crado, il y a des fichiers vraiment dans tous les sens. Ça dépend de D-bus et udev, ça en gêne aussi certains. C’est juste űber-chiant à configurer, les liens symboliques je ne peux pas piffer, et puis des fois c’est impossible de trouver comment configurer correctement (je pense à dhcpcd). Ça a des bugs remontés dont tout le monde se fout (/etc/vconsole.conf). Ça retire la possibilité d’un /etc/rc.conf. Et j’en oublie probablement.

The Uploader · Le 05/03/2013, à 22:23

Pylade a écrit :

Je pense qu’il est inutile de revenir sur les critiques de PulseAudio…

Ben si, vu que j'en vois aucune qui subsiste aujourd'hui. Par contre, alsa qui n'a pas de volume pour chaque application, c'est so 90s (et über-chiant !).

Quant aux risques de latence, le problème c'est qu'en pratique je ne les ai jamais eu.

Pylade a écrit :

Les scripts, ils avaient un fonctionnement intelligible.

Euh ouais, si tu le dis.... Et tous les scripts n'étaient pas bien maintenus, sans compter les problèmes de sécurité de certains (bash a pas mal de pièges). Mais tu peux toujours les utiliser avec systemd si tu veux.

Avec les unit-files de systemd, au moins c'est clair et net.

Les scripts d'init c'est bloated de toutes façons :

Well, bloated certainly has many different definitions. But in most definitions systemd is probably the opposite of bloat. Since systemd components share a common code base, they tend to share much more code for common code paths. Here's an example: in a traditional Linux setup, sysvinit, start-stop-daemon, inetd, cron, dbus, all implemented a scheme to execute processes with various configuration options in a certain, hopefully clean environment. On systemd the code paths for all of this, for the configuration parsing, as well as the actual execution is shared. This means less code, less place for mistakes, less memory and cache pressure, and is thus a very good thing. And as a side-effect you actually get a ton more functionality for it...
As mentioned above, systemd is also pretty modular. You can choose at build time which components you need, and which you don't need. People can hence specifically choose the level of "bloat" they want.
When you build systemd, it only requires three dependencies: glibc, libcap and dbus. That's it. It can make use of more dependencies, but these are entirely optional.
So, yeah, whichever way you look at it, it's really not bloated.

Le principe DRY, c'est pas que pour les cochons.

dbus n'est même pas un problème :

Myth: systemd is not scriptable, because of its D-Bus use.
Not true. Pretty much every single D-Bus interface systemd provides is also available in a command line tool, for example in systemctl, loginctl, timedatectl, hostnamectl, localectl and suchlike. You can easily call these tools from shell scripts, they open up pretty much the entire API from the command line with easy-to-use commands.
That said, D-Bus actually has bindings for almost any scripting language this world knows. Even from the shell you can invoke arbitrary D-Bus methods with dbus-send or gdbus. If anything, this improves scriptability due to the good support of D-Bus in the various scripting languages.

Pylade a écrit :

systemd, ça ressemble plus de la boîte noire à laquelle il est difficile de bitter quelque chose.

man systemd, man systemctl, man journald.
Aussi :

Myth: systemd is not debuggable.
False. Some people try to imply that the shell was a good debugger. Well, it isn't really. In systemd we provide you with actual debugging features instead. For example: interactive debugging, verbose tracing, the ability to mask any component during boot, and more. Also, we provide documentation for it.
It's certainly well debuggable, we needed that for our own development work, after all. But we'll grant you one thing: it uses different debugging tools, we believe more appropriate ones for the purpose, though.

Myth: systemd is complex.
There's certainly some truth in that. Modern computers are complex beasts, and the OS running on it will hence have to be complex too. However, systemd is certainly not more complex than prior implementations of the same components. Much rather, it's simpler, and has less redundancy (see above). Moreover, building a simple OS based on systemd will involve much fewer packages than a traditional Linux did. Fewer packages makes it easier to build your system, gets rid of interdependencies and of much of the different behaviour of every component involved.

Mais encore :

Myth: systemd's use of D-Bus instead of sockets makes it intransparent.
This claim is already contradictory in itself: D-Bus uses sockets as transport, too. Hence whenever D-Bus is used to send something around, a socket is used for that too. D-Bus is mostly a standardized serialization of messages to send over these sockets. If anything this makes it more transparent, since this serialization is well documented, understood and there are numerous tracing tools and language bindings for it. This is very much unlike the usual homegrown protocols the various classic UNIX daemons use to communicate locally.

Pylade a écrit :

Ça dépend de D-bus et udev, ça en gêne aussi certains.

Et pas d'autres.

Pylade a écrit :

C’est juste űber-chiant à configurer, les liens symboliques je ne peux pas piffer

En même temps c'est pas toi qui t'en occupe des liens symboliques. Et puis les liens symboliques, c'est uniquement pour les unit-files que tu as activé ou non.

Et y'a quoi d'über-chiant à utliser :

sudo systemctl mask bidule

pour désactiver un service et :

sudo systemctl unmask truc

pour en réactiver un autre ?

Surtout que

systemctl

Te donne directement ta config...

Quant au reste de systemd, ça se configure directement avec vim si tu veux :

Myth: systemd requires you to use some arcane configuration tools instead of allowing you to edit your configuration files directly.
Not true at all. We offer some configuration tools, and using them gets you a bit of additional functionality (for example, command line completion for all settings!), but there's no need at all to use them. You can always edit the files in question directly if you wish, and that's fully supported. Of course sometimes you need to explicitly reload configuration of some daemon after editing the configuration, but that's pretty much true for most UNIX services.

Pylade a écrit :

et puis des fois c’est impossible de trouver comment configurer correctement (je pense à dhcpcd)

Tu peux détailler ?

Pylade a écrit :

Ça a des bugs remontés dont tout le monde se fout (/etc/vconsole.conf)

Bah en même temps sans les cgroups impossible de tuer un daemon à peine complexe au niveau de ses processus fils proprement à chaque coup et tout le monde s'en fout depuis des décennies.

Pas de problème chez moi quant à /etc/vconsole.conf. Et ce n'est pas le seul logiciel à avoir des bugs remontés dont "tout le monde se fout" (bug difficile à reproduire, etc...).

Pylade a écrit :

Ça retire la possibilité d’un /etc/rc.conf.

/etc/rc.conf n'était pas KISS. Les paramètres enregistrés là dedans étaient répercutés automatiquement dans les fichiers qui vont bien par un script maintenu par les auteurs d'Archlinux. (par exemple ce qui allait dans /etc/rc.conf et qui est maintenant directement dans /etc/mkinitcpio.conf ou /etc/vconsole.conf ou encore /etc/locale.conf). Du bricolage. Bon débarras.

Aussi, systemd respecte plus la tradition UNIX que sysv :

Myth: systemd is not UNIX.
There's certainly some truth in that. systemd's sources do not contain a single line of code originating from original UNIX. However, we derive inspiration from UNIX, and thus there's a ton of UNIX in systemd. For example, the UNIX idea of "everything is a file" finds reflection in that in systemd all services are exposed at runtime in a kernel file system, the cgroupfs. Then, one of the original features of UNIX was multi-seat support, based on built-in terminal support. Text terminals are hardly the state of the art how you interface with your computer these days however. With systemd we brought native multi-seat support back, but this time with full support for today's hardware, covering graphics, mice, audio, webcams and more, and all that fully automatic, hotplug-capable and without configuration. In fact the design of systemd as a suite of integrated tools that each have their individual purposes but when used together are more than just the sum of the parts, that's pretty much at the core of UNIX philosophy. Then, the way our project is handled (i.e. maintaining much of the core OS in a single git repository) is much closer to the BSD model (which is a true UNIX, unlike Linux) of doing things (where most of the core OS is kept in a single CVS/SVN repository) than things on Linux ever were.
Ultimately, UNIX is something different for everybody. For us systemd maintainers it is something we derive inspiration from. For others it is a religion, and much like the other world religions there are different readings and understandings of it. Some define UNIX based on specific pieces of code heritage, others see it just as a set of ideas, others as a set of commands or APIs, and even others as a definition of behaviours. Of course, it is impossible to ever make all these people happy.
Ultimately the question whether something is UNIX or not matters very little. Being technically excellent is hardly exclusive to UNIX. For us, UNIX is a major influence (heck, the biggest one), but we also have other influences. Hence in some areas systemd will be very UNIXy, and in others a little bit less.

Pylade a écrit :

Et j'en oublie probablement.

J'oublie probablement d'autres avantages à systemd, mais je te recommande cette page : http://0pointer.de/blog/projects/the-biggest-myths.html
Et la série des systemd for Administrators

Dernière modification par The Uploader (Le 05/03/2013, à 22:35)

Pylades · Le 05/03/2013, à 23:38

The Uploader a écrit :

Avec les unit-files de systemd, au moins c'est clair et net.

Bah même ça, je trouve que c’est inutilement compliqué.

The Uploader a écrit :

Les scripts d'init c'est bloated de toutes façons :
[…]

Ah, je suis bien d’accord. Juste que systemd aussi.

The Uploader a écrit :

En même temps c'est pas toi qui t'en occupe des liens symboliques. Et puis les liens symboliques, c'est uniquement pour les unit-files que tu as activé ou non.
Et y'a quoi d'über-chiant à utliser :
sudo systemctl mask bidule
pour désactiver un service et :
sudo systemctl unmask truc
pour en réactiver un autre ?
Surtout que
systemctl
Te donne directement ta config...

La complexité inutile. Où est la difficulté à faire un /etc/systemd.conf :

[enabled]
multi-user
graphical
network
cronie
ntp
gpm

Ça, ce serait simple. Et même, je trouve moyennement opportun de faire de graphical juste un synonyme d’un DM, lequel doit être spécifié ailleurs.

The Uploader a écrit :

Quant au reste de systemd, ça se configure directement avec vim si tu veux :
[…]

Ouais, dconf aussi, si l’on va par là (j’exagère à peine )…

The Uploader a écrit :

Pylade a écrit :
et puis des fois c’est impossible de trouver comment configurer correctement (je pense à dhcpcd)
Tu peux détailler ?

T’as réussi à activer dhcpcd, toi ?
Je veux dire, l’avoir en permanence qui tourne, indépendamment de l’interface connectée.

The Uploader a écrit :

Pas de problème chez moi quant à /etc/vconsole.conf.

Bah en fait, il faut obligatoirement l’early-KMS, sinon ça chie. Je trouve ça un peu fort de café. Et chez moi, je ne peux pas avoir l’early-KMS.

The Uploader a écrit :

/etc/rc.conf n'était pas KISS. […] Bon débarras.

Je suis bien d’accord ;même s’il ne faut pas confondre le rc.conf fourre-tout le rc.conf à peu près propre (la ligne DAEMONS).
J’ai lapsusé : je voulais dire /etc/rc.local.

The Uploader a écrit :

Aussi, systemd respecte plus la tradition UNIX que sysv :
[…]

Dans un sens oui, dans un autre non. Un logiciel fait une chose et la fait bien. Je trouve systemd bien trop compliqué. Il n’est pas portable, non plus. En ce sens, il est moins Unix.

The Uploader a écrit :

J'oublie probablement d'autres avantages à systemd, mais je te recommande cette page : http://0pointer.de/blog/projects/the-biggest-myths.html
Et la série des systemd for Administrators

Je sais que systemd a des tas d’avantages. Je lui reproche d’avoir aussi des tas de défauts ; je trouve que c’est un peu du gâchis. Je commence à croire que Poettering est incapable de faire quelque chose de propre ; qu’il est fondamentalement crado.

The Uploader · Le 06/03/2013, à 20:31

Out with rubygame, in with gosu \o/

Dernière modification par The Uploader (Le 06/03/2013, à 20:38)

Rolinh · Le 06/03/2013, à 22:30

Bon, j'ai toujours pas résolu le bug. J'ai fait testé au rapporteur de bug une version où j'ai ajouté ceci en entête de dfc.c:

#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE

Mais si cela ne pose pas de problème sur mon Arch 64-bit, sur une installation 32-bit cela conduit à une segfault (j'ai pu le tester par moi-même avec une Debian testing 32-bit dans une machine virtuelle).

$ bin/dfc
FILESYSTEM               (=) USED      FREE (-) %USED AVAILABLE     TOTAL MOUNTED ON 
rootfs                   [================----]   79%      3.3G     15.8G /
Segmentation fault

Bref, je sens que j'en ai pas encore fini avec ce bug gênant...

EDIT: Ça ressemble quand même beaucoup à ça, non?

Dernière modification par Rolinh (Le 06/03/2013, à 22:43)

tshirtman · Le 06/03/2013, à 22:51

Rolinh a écrit :

Dites, il n'y a que moi qui ai cette impression ou bien Canonical essaie à nouveau de réinventer la roue avec Mir?
En fait, apparemment ils n'ont même pas cherché à contacter les développeurs de Wayland avant de se lancer là-dedans...
J'ai vraiment du mal à comprendre cette attitude à vouloir à chaque fois réinventer la roue (Bazaar, Upstart, ...), au lieu d'adapter l'existant comme le permet justement le modèle open-source.
J'étais sûr qu'ils tablaient sur Wayland en plus (c'était prévu pour Ubuntu 12.10 non?).

Oh, je te rassure, tu n'es pas le seul à avoir cette idée, mais comme dis par d'autres, ils ne sont pas les seuls à faire ce genre de choses, le changement ça fait toujours un peu de casse, mais il faut un an ou deux pour voir si c'était une bonne idée ou pas en général. (au passage, quand ils ont commencé le dev de bazaar, y'avait pas grand chose sur le marché dans les gestionnaires de sources distribués). Apparement ils ont déjà quelque chose de bien fonctionnel, donc c'est plutôt rassurant, mais bon, j'ai pas regardé le code (et je ne serait probablement pas à même de juger de toutes façons).

:!pakman a écrit :

C'est quoi la différence entre Python et Ruby ?
Je ne connait pas Ruby, mais j'ai l'impression que ça fournit exactement le même service que la plateforme Python...

Il y a des similitudes… de loin, ce sont tous les deux des langages dynamiques (mais pas vraiment de la même façon), full objet (mais pas vraiment de la même façon), multiparadigmes (mais…), qui essayent de favoriser un mode d'expression proche des language naturels (mais…).

Au delà, les communautés sont assez différentes, si python a trouvé une certaine légitimité dans les grands groupe, et a un gros historique de base installé (avec ce que ça implique de compatibilité descendante), ruby est encore un langage très "startup", de boite s innovantes que se moquent des conventions et n'hésite pas à casser la compatibilité pour avancer (ruby 1.8 à 1.9 à été un saut équivalent à celui de python 2.7 à 3.0, en terme de difficulté, et sans les outils pour prémacher le boulot), et ça se sent un peu (le passage de gros projets comme redmine à 1.9… sans compter tous les plugins hum…). Du coup, j'ai un peu une image de "fire and forget" pour ruby, tu fais ton produit/site et tu l'oublie, sinon, c'est compliqué sur le long terme, mais bon, c'est l'image que j'en ai pour en avoir fait quelques mois il y a un an.

Après, dans la boite à outil (bibliothèques dispos), y'a un peu les même choses, on trouve des équivalents pour un peu tout, mais les languages, et donc les communautés qui les pratiques sont assez différentes.

The Uploader a écrit :

HP a écrit :
de plus, l'identation qui délimite les blocs, ça peut finir par lasser !
Pourtant c'est DRY-compliant.

Et les "end", ça lasse assez vite aussi… surtout qu'on indente quand même (donc oui, le DRY, et les bugs que ça induit de ne pas le respecter).

Dernière modification par tshirtman (Le 06/03/2013, à 22:53)

The Uploader · Le 06/03/2013, à 23:23

Youpi, "mon" nviidia-96xx-all ne compile pas avec le kernel 3.8.

Déjà qu'il a fallu un patch de chez gentoo pour linux 3.7 (merci gentoo ! \o/ ).

Là, soit le module se plaint de ne pas trouver la version du kernel et exige de fournir une variable (déjà fournie et valide) SYSSRC qui pointe vers le dossier des fichiers d'en-tête du kernel (la fonction est inutile de toutes façons : elle n'arrive pas à déterminer quel Makefile utiliser : celui pour les kernels < 2.6 ou celui pour les kernels >= 2.6...), soit (quand je force le bon Makefile) :

error : agp_backend_release called with too few arguments

(parmi d'autres erreurs antérieurs)

/lib/modules/3.8.2-1-ck/build/include/linux/agp_backend.h :

[...]
extern void agp_backend_release(struct agp_bridge_data *);

Le truc c'est que la fonction requiert aussi un argument dans les sources de linux-3.7, et que donc logiquement ça ne devrait pas compiler non plus pour linux 3.7. (et non le code n'est pas modifié selon le kernel, juste quelques headers. Et puis de toutes façons ce bidule requiert Xorg 1.12, c'est dire à quel point c'est abandonné par nvidia depuis longtemps...).
WHAT. THE. FUCK ?

Vivement que nouveau fonctionne... Ou que le mainteneur de nvidia-96xx (tout court) sort un autre patch tiers lorsque linux 3.8 sera sur les dépôts Arch officiels.

Dernière modification par The Uploader (Le 06/03/2013, à 23:30)

grim7reaper · Le 07/03/2013, à 04:28

Rolinh a écrit :

Mais si cela ne pose pas de problème sur mon Arch 64-bit, sur une installation 32-bit cela conduit à une segfault (j'ai pu le tester par moi-même avec une Debian testing 32-bit dans une machine virtuelle).

Ça c’est pas normal par contre.
Peut-être des cast un peu violent par endroit, ce qui montre qu’ils n’ont pas lieu d’être.

Rolinh a écrit :

EDIT: Ça ressemble quand même beaucoup à ça, non?

Oui, j’avais trouvé ce fil aussi, mais ça semble aller dans notre sens.

tshirtman a écrit :

ruby est encore un langage très "startup", de boite s innovantes que se moquent des conventions et n'hésite pas à casser la compatibilité pour avancer (ruby 1.8 à 1.9 à été un saut équivalent à celui de python 2.7 à 3.0, en terme de difficulté, et sans les outils pour prémacher le boulot), et ça se sent un peu (le passage de gros projets comme redmine à 1.9… sans compter tous les plugins hum…). Du coup, j'ai un peu une image de "fire and forget" pour ruby, tu fais ton produit/site et tu l'oublie, sinon, c'est compliqué sur le long terme, mais bon, c'est l'image que j'en ai pour en avoir fait quelques mois il y a un an.

Pas sûr que ça soit très vrai, ou en tout cas c’est en train/ça va changer.
Car s’ils ont fait standardisé le langage par l’ISO (pas gratuit hein) en vue que le gouvernement japonais l’utilise, c’est pas pour tout péter entre deux versions.
D’ailleurs, je crois que la 2.0 ne casse rien par rapport à la 1.9 (à vérifier).

@The Uploader : c’est dans ces cas-là que tu voudrais sortir un bon
Fuck You Nvidia!
non ?

The Uploader · Le 07/03/2013, à 08:49

Oui c'est clair mais j’aimerais surtout comprendre ceci (je crois que c'est l'erreur la plus importante, mais c'est loin d'être la seule) :

Le truc c'est que la fonction requiert aussi un argument dans les sources de linux-3.7, et que donc logiquement ça ne devrait pas compiler non plus pour linux 3.7. (et non le code n'est pas modifié selon le kernel, juste quelques headers. Et puis de toutes façons ce bidule requiert Xorg 1.12, c'est dire à quel point c'est abandonné par nvidia depuis longtemps...).
WHAT. THE. FUCK ?

Parce que j'ai vraiment l'impression d'être dans la quatrième dimension et je déteste ça.

Dernière modification par The Uploader (Le 07/03/2013, à 08:58)

:!pakman · Le 07/03/2013, à 16:40

Hello
Petite question concernant les DAO, voila le truc :

Mettons, on a 1 DAO par table, par exemple pour la table Personne :

Personne.php       # Objet recordset
PersonneDAO.php    # Objet DAO

Cette Personne a un type, c'est une clé étrangère vers TypePersonne :

TypePersonne.php
TypePersonneDAO.php

TypePersonne, elle, associe pour chaque clé primaire (numéro), le type en toutes lettres.

Comment on fait avec les 2 pour faire une jointure avec les DAO ?
Pour sélectionner une Personne avec son type en toutes lettres, ce qui implique une jointure ?

On crée un nouveau DAO ? Vu que chaque DAO est réservé pour une seule table...
Ou alors utiliser les DTO ? On n'en a pas parlé en cours, je ne voit pas trop ce que c'est...

Dernière modification par :!pakman (Le 07/03/2013, à 17:10)

Mindiell · Le 07/03/2013, à 22:18

L'idée derrière le DAO c'est pas de faire abstraction du modèle de données plutôt ? Donc, a priori, j'aurai tendance à avoir un DAO Personne qui fait ce qu'il veut mais qui me permet de récupérer le nom et le type de la personne.
D'après Wikipédia, c'est bien ça. Donc tu n'as pas, voire tu ne dois pas, retranscrire bêtement la structure de ta base de données, mais plutôt des objets que tu vas utiliser. L'intérêt étant que ces objets "persistants" puissent persister justement, sans avoir à t'en préoccuper: Tu sais que ça marche, que ça soit dans une BDD avec 6 tables ou un gros fichier TXT crado, tu t'en fiches

:!pakman · Le 07/03/2013, à 22:33

Ok, j'étais parti effectivement pour retranscrire la structure exacte de ma base, je vais adapter ça
Faire un DAO qui me permet de récupérer une Personne qui comprend son type en toutes lettres (dont les infos proviennent en fait de 2 tables).
Merci

Pylades · Le 08/03/2013, à 02:27

Au fait, The Uploader, t’as trouvé un moyen simple et propre d’avoir un /etc/rc.local ?
On ne peut quand même pas dire que ce n’est pas KISS, le /etc/rc.local…

The Uploader · Le 08/03/2013, à 09:08

Je n'utilise pas /etc/rc.local, pas besoin.
edit : http://superuser.com/questions/278396/s … c-rc-local

Dernière modification par The Uploader (Le 08/03/2013, à 09:11)

The Uploader · Le 08/03/2013, à 19:07

Le VP8 enfin à l'abri des brevets H.264 qu'il violait (et viole toujours)

Dernière modification par The Uploader (Le 08/03/2013, à 19:08)

grim7reaper · Le 08/03/2013, à 19:34

On le savait déjà, maintenant au moins c’est officiel.

Édit : tiens un article un peu long mais sympa : The care and feeding of software engineers (or, why engineers are grumpy)
(Pour les anglophobes il y a le lien vers une traduction en français en bas de l’article).

Dernière modification par grim7reaper (Le 08/03/2013, à 20:01)

Pylades · Le 08/03/2013, à 19:35

The Uploader a écrit :

Je n'utilise pas /etc/rc.local, pas besoin.
edit : http://superuser.com/questions/278396/s … c-rc-local

Bah moi j’en ai vraiment besoin.
Et ouais, c’est une solution. Pas super élégante, non plus. Ça participe à rendre systemd boiteux.

HP · Le 08/03/2013, à 23:08

http://superuser.com/questions/278396/s … c-rc-local

C'est quoi ce truc tout vilain avec une syntaxe type ini/desktop ?
Pfffiou… on se croirait sous Mac OS X limite… sauf que ce serait une syntaxe XML (plist).

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#776 Le 05/03/2013, à 18:12

Re : /* Topic des codeurs [8] */

#777 Le 05/03/2013, à 18:36

Re : /* Topic des codeurs [8] */

#778 Le 05/03/2013, à 18:40

Re : /* Topic des codeurs [8] */

#779 Le 05/03/2013, à 18:45

Re : /* Topic des codeurs [8] */

#780 Le 05/03/2013, à 18:59

Re : /* Topic des codeurs [8] */

#781 Le 05/03/2013, à 19:46

Re : /* Topic des codeurs [8] */

#782 Le 05/03/2013, à 20:49

Re : /* Topic des codeurs [8] */

#783 Le 05/03/2013, à 21:14

Re : /* Topic des codeurs [8] */

#784 Le 05/03/2013, à 22:23

Re : /* Topic des codeurs [8] */

#785 Le 05/03/2013, à 23:38

Re : /* Topic des codeurs [8] */

#786 Le 06/03/2013, à 20:31

Re : /* Topic des codeurs [8] */

#787 Le 06/03/2013, à 22:30

Re : /* Topic des codeurs [8] */

#788 Le 06/03/2013, à 22:51

Re : /* Topic des codeurs [8] */

#789 Le 06/03/2013, à 23:23

Re : /* Topic des codeurs [8] */

#790 Le 07/03/2013, à 04:28

Re : /* Topic des codeurs [8] */

#791 Le 07/03/2013, à 08:49

Re : /* Topic des codeurs [8] */

#792 Le 07/03/2013, à 16:40

Re : /* Topic des codeurs [8] */

#793 Le 07/03/2013, à 22:18

Re : /* Topic des codeurs [8] */

#794 Le 07/03/2013, à 22:33

Re : /* Topic des codeurs [8] */

#795 Le 08/03/2013, à 02:27

Re : /* Topic des codeurs [8] */

#796 Le 08/03/2013, à 09:08

Re : /* Topic des codeurs [8] */

#797 Le 08/03/2013, à 19:07

Re : /* Topic des codeurs [8] */

#798 Le 08/03/2013, à 19:34

Re : /* Topic des codeurs [8] */

#799 Le 08/03/2013, à 19:35

Re : /* Topic des codeurs [8] */

#800 Le 08/03/2013, à 23:08

Re : /* Topic des codeurs [8] */

Pied de page des forums