La boite à le droit de bloquer les connexions. Par contre si elle fait du MITM SSL sur ta banque la y a soucis. Elle n'a pas le droit "d'espionner" ce type de communication.
Donc soit elle bloque purement et simplement soit elle laisse passer sans le Proxy/MITM SSL.
Ceci est une pratique courante dans la plupart des grosses boites (DSI presé qui achète une solution de cyber-sécurité sur étagère).
Mais effectivement tu as le droit d'aller lire modérement tes mails perso ou ton compte en banque depuis ton travail et ceci doit rester privé. Donc généralement ces solutions ont des listes blanches de services autorisés qui ne passe pas par l'intercepteur/proxy SSL.
Fait un test avec ta banque et regarde qu'elle certificat ssl est utilisé. Si c'est celui du proxy et qu'aucun information spécifique vous a été faite sur ce sujet, je doute très très fort de la légalité de la solution mise en place.
Hmmm c'est un peu court comme réponse. Tu peux pas démarrer un sujet en faisant de longue tirade sur l'importance de la sémantique et terminé le tout par un simple oui. Ça laisse un goût d'inachevé.
Je trouve l'article particulièrement mal écrit, les chiffres donnés sont assez grossier.
Genre l'exemple de la consommation d'un mail d'1mo alors qu'un mail qui fait 100ko c'est déjà un bon gros mail (hors pièce jointe)
Pareille pour les chiffres sur les serveurs/routeur qui sont très grossier.
Je remets pas en cause le côté consommation énergétique d'Internet mais y avait beaucoup plus précis et moins anxiogène à faire comme article.
L'article du blog n'est pas très claire sur l'origine de l'issue. Est-ce un problème générique de la non atomicité des gestionnaires de paquets (et donc on pourrait avoir le même type de soucis sur une Debian par exemple) ou est-ce un problème spécifique à rpm ou spécifique à Mageia ?
Je suis surpris par les recommandations suggérées dans l'article, ça fait super peur comme migration, j'ai pas souvenir d'avoir déjà vu ça ailleurs.
Je vais pas commenter tout l article. Seulement une petite partie qui est très certainement une grosse partie du problème et qui fait que l état refuse de refaire un bail comme au Larzac. N'ayant jamais trouvé de justificatif claire de l état la dessus j'imagine que c'est à cause des propriétaires des sols. Sur 1600 hectares tu en à la moitié à la région (qui était plutôt pro aéroport et donc ne fera pas de cadeau à l état et va donc pousser pour avoir des "colons" de la FNSEA) 10% environ directement à Vinci et le reste à l état (du aux expropriation).
Pourquoi choisir un kernel 4.12 comme version du kernel ? Tu indiques que c'est une version LTS, pourquoi les LTS d'openSUSE ne sont pas baser sur les LTS mainline (kernel.org) ?
Quid des correctifs liés à Spectre ? C'est un backport maison ?
La trustzone à juste rien à voir avec la solution d Intel, je suis désolée mais ton commentaire relève d une grosse méconnaissance du sujet. Trustzone est un environnement sécurisé de ton processeur. Sous Intel tu as un processeur différents qui tourne en arriere plan, sous arm si ton kernel linux (ou hyperviseur ou autre) ne fait pas un Secure Monitor Call (grosso modo un syscall hardware) et bien ton processeur/cœur ne rentra jamais dans le mode trustzone de ton processeur. La trustzone fonctionne sur un mode coopératif entre normal World et Secure World.
Donc pour avoir une trustzone qui ferait des choses dans ton dos en volant du temps CPU à ton Linux, faut une architecture avec un hyperviseur/moniteur qui fait périodiquement des SMC dans le dos de ton Linux ou un cœur dédié à ta trustzone. Très peu de systèmes sont architecturés de cette manière la.
N'ayant pas non plus d'accès LWN je vais supposer de quoi ça parle.
A mon avis ça présente le projet "Civil Infrastructure Project" (https://www.cip-project.org/) encore un énième projet de la Linux Fondation.
On y retrouve dedans le mainteneur kernel de chez debian (Ben Hutchings) et le tout est financé par Siemens et Renesas principalement.
Le projet date seulement de deux ans et pour l'instant j'ai pas vu sortir grand chose à par de jolie présentation bullshit/marketing.
Le nombre de boards supportées est assez faible (quasi uniquement des boards Siemens ou de chez Renesas ce qui est très loin de la majorité des boards ARM qu'on retrouve dans l'industrie).
Et dès qu'on sort du kernel ils se cherchent beaucoup, d'un coté il veulent réutiliser le travail fournit par debian (en terme de patch de sécurité, packaging etc) et d'un autre coté ils ont bien conscience que dans l'embarqué le build système de référence c'est Yocto et qu'il y a besoin de customisation/optimisation des images système (rootfs) crées. Donc ils essaient de faire marcher les deux ensemble (avoir bitbake avec des recettes debian): https://schd.ws/hosted_files/elciotna18/9d/20180314-CIP-ELCNA-v12.pdf
Pour l'instant y a trois prototypes différents qui ont toutes des limitations donc ont est très loin d'une solution robuste et industrielle dans le temps.
On vera se qui en sortira, si ça permet d'unifier yocto et debian j'applaudirai des deux mains mais j'ai vraiment peu d'espoir que ça arrive vraiment. Je ne me permettrai pas de critiquer le travail de Ben Hutchings mais j'ai bien peur qu'on soit dans du "marketing washing" de la part de SIEMENS et Renesas et que ce projet se transforme rapidement en coquille vide.
L'os de référence dans docker c'est alpine (basé sur la libc musl et le gestionnaire de paquets opkg) afin d'avoir des images la plus légère possible. Le "must" étant l application standalone avec libc statique (très simple à faire pour une application golang). Après effectivement il y a une dérive dans l utilisation de docker dû à son succès où tu te retrouves avec des debians bloated remplies de commande Apt mais c'est/c'était pas la philosophie première de la technologie. Les devs docker depuis le premier jour ont critiqué l idée d avoir un daemon ssh dans une image docker par exemple.
Tant qu'on aura pas réglé le problème de consommation d'énergie (tant qu'on s'amusera pas à faire des robots/IA avec des piles nucléaire) on est plutôt tranquille d'un Skynet, au moindre soubresaut de révolte, on débranche la prise électrique et l'IA/robot elle pourra aller faire cou-couche panier. Bon après on a déjà vu des mini crac boursier a cause de mise à jour foireuse de logiciel/IA d'hypertraiding donc on est déjà plus dépends d'"IA/logiciel à décision automatisé" qu'on ne le pense.
Une solution a base de VM est obligatoire ou une solution à base de conteneur pourrait être envisagé ? Si on peut faire du conteneur à la place soit Kubernetes soit Mesos (j'ai un penchant perso pour Mesos).
Coté storage soit ceph soit gluster comme déjà évoqué. Glusterfs niveau performance c'est pas la panacée surtout quand tu es sur beaucoup de petits fichiers. Ceph j'ai jamais pu l'expérimenté il me semble plus intéressant mais aussi plus lourd à mettre en place.
La version communautaire est pour ma part limité, il y a une fonctionnalité qui n'existe que dans la version commerciale et qui est pour moi déterminante qui est celle de la stratégie de merge sur un pull request. Avec la version communautaire seulement le merge request est permis, adieu les possibilités de rebase/squash+cherry-pick qui permettent d'avoir un historique linéaire.
Coté CI de gitlab, c'est assez simple à faire marcher par contre c'est beaucoup trop lié à GIT donc dès que tu veux faire des choses qui sont périodique avec tu te retrouve à bidouiller de faux événements git via cron, la dessus Jenkins est bien plus puissant. Pareille pour ce qui est tableau de reporting (avoir de joli graphique qui parle au chef de projet sur le nombre de tests qui passe etc…), coté gitlab on est très très limité.
Tout dépend à quel point tes données sont "Big" ou "Fast" pour avoir vraiment besoin de se genre d'écosystème. Quoiqu'il en soit, mesos me semble en tout cas un très bon choix pour gérer la charge multi-machine (que ça soit pour y mettre du bigdata dessus ou un simple "container management system" via marathon).
Dans le cas d'Android, il s'agit de java (enfin de dalvik) donc quand sa touche au bas niveau c'est via du C (par JNI). Dans ton cas si j'ai bien compris il y a ses propres syscall, comme on peut trouver en Go.
je m'insurge sur le fait de dire que la carte la plus ""Open-source" c'est la Raspberry PI, ce SOC est une infamie, c'est un gpu sur lequel ils ont collé un bout de cpu, le système d'init est complètement custom, y a pas de Global interrupt controller mais un truc custom qui passe par le gpu. Il a fallut super longtemps avant d'avoir un bootloader libre pour ce SOC.
Y a juste eu une énorme buzz autour de cette carte et donc une grosse traction de la communauté derrière mais je préfère mille fois le boulot fait par TI avec ses beagleboards si on veut comparer ceux qu'y ont l'approche la plus "Open-source".
J'ai pas trouvé l'info dans la documentation d'android pour savoir quels tests sont executés pour détecter la présence d'un téléphone root ou non mais si tu es pas allergique en anglais voici un lien qui montre quelqu'une des techniques possibles :
En résumé, tu as la recherche d'APK installé servant à rooter un téléphone (superuser.apk etc…), image signé ou non, présence de "su" et binaire busybox, modification de certaines propriétés systèmes.
Je vois pas où est le problème.L application Netflix repose sur des DRM et veux donc être sur que tu as pas bidouillé le système. Libre à toi de pas utiliser Netflix, ils ont jamais prétendu faire du libre.
Pour information la dernière version de kubernetes n'utilise plus l api de docker mais directement runC (l engine de docker qui est maintenant maintenu par OCI). Kubernetes comme mesos utilisent CNI pour le réseau, standard malheureusement non suivi par docker pour l'instant.
[^] # Re: Legal sous certaine conditions
Posté par Tangi Colin . En réponse au journal Légalité de l'interception du flux SSL au sein d'une entreprise. Évalué à 10.
La boite à le droit de bloquer les connexions. Par contre si elle fait du MITM SSL sur ta banque la y a soucis. Elle n'a pas le droit "d'espionner" ce type de communication.
Donc soit elle bloque purement et simplement soit elle laisse passer sans le Proxy/MITM SSL.
# Legal sous certaine conditions
Posté par Tangi Colin . En réponse au journal Légalité de l'interception du flux SSL au sein d'une entreprise. Évalué à 7.
Ceci est une pratique courante dans la plupart des grosses boites (DSI presé qui achète une solution de cyber-sécurité sur étagère).
Mais effectivement tu as le droit d'aller lire modérement tes mails perso ou ton compte en banque depuis ton travail et ceci doit rester privé. Donc généralement ces solutions ont des listes blanches de services autorisés qui ne passe pas par l'intercepteur/proxy SSL.
Fait un test avec ta banque et regarde qu'elle certificat ssl est utilisé. Si c'est celui du proxy et qu'aucun information spécifique vous a été faite sur ce sujet, je doute très très fort de la légalité de la solution mise en place.
[^] # Re: Les fameux «ces gens de l'Europe»
Posté par Tangi Colin . En réponse au journal La fin de l'internet est proche!. Évalué à 3.
Hmmm c'est un peu court comme réponse. Tu peux pas démarrer un sujet en faisant de longue tirade sur l'importance de la sémantique et terminé le tout par un simple oui. Ça laisse un goût d'inachevé.
# Article grossier et anxiogène
Posté par Tangi Colin . En réponse au lien Numérique : le grand gâchis énergétique. Évalué à 2.
Je trouve l'article particulièrement mal écrit, les chiffres donnés sont assez grossier.
Genre l'exemple de la consommation d'un mail d'1mo alors qu'un mail qui fait 100ko c'est déjà un bon gros mail (hors pièce jointe)
Pareille pour les chiffres sur les serveurs/routeur qui sont très grossier.
Je remets pas en cause le côté consommation énergétique d'Internet mais y avait beaucoup plus précis et moins anxiogène à faire comme article.
# Quel est vraiment la nature du problème ?
Posté par Tangi Colin . En réponse au journal Mise à jour Mageia: attention danger. Évalué à 2.
L'article du blog n'est pas très claire sur l'origine de l'issue. Est-ce un problème générique de la non atomicité des gestionnaires de paquets (et donc on pourrait avoir le même type de soucis sur une Debian par exemple) ou est-ce un problème spécifique à rpm ou spécifique à Mageia ?
Je suis surpris par les recommandations suggérées dans l'article, ça fait super peur comme migration, j'ai pas souvenir d'avoir déjà vu ça ailleurs.
[^] # Re: Inexactitudes
Posté par Tangi Colin . En réponse au journal Solution au conflit de la ZAD de Notre-Dame-des-Landes. Évalué à 2.
J ai fait moi aussi une inexactitudes sur mon commentaire, il s' agit du département et non la région qui possèderait 50% des terres : https://www.ouest-france.fr/environnement/amenagement-du-territoire/nddl/zad-le-departement-saisit-le-juge-pour-recuperer-des-terres-5717654/amp
# Inexactitudes
Posté par Tangi Colin . En réponse au journal Solution au conflit de la ZAD de Notre-Dame-des-Landes. Évalué à 8.
Je vais pas commenter tout l article. Seulement une petite partie qui est très certainement une grosse partie du problème et qui fait que l état refuse de refaire un bail comme au Larzac. N'ayant jamais trouvé de justificatif claire de l état la dessus j'imagine que c'est à cause des propriétaires des sols. Sur 1600 hectares tu en à la moitié à la région (qui était plutôt pro aéroport et donc ne fera pas de cadeau à l état et va donc pousser pour avoir des "colons" de la FNSEA) 10% environ directement à Vinci et le reste à l état (du aux expropriation).
# Choix de la version du kernel ?
Posté par Tangi Colin . En réponse au journal openSUSE Leap 15 atteint les phases bêta.. Évalué à 1.
Pourquoi choisir un kernel 4.12 comme version du kernel ? Tu indiques que c'est une version LTS, pourquoi les LTS d'openSUSE ne sont pas baser sur les LTS mainline (kernel.org) ?
Quid des correctifs liés à Spectre ? C'est un backport maison ?
[^] # Re: Effet de mode?
Posté par Tangi Colin . En réponse au journal ARM vs Intel. Évalué à 6.
La trustzone à juste rien à voir avec la solution d Intel, je suis désolée mais ton commentaire relève d une grosse méconnaissance du sujet. Trustzone est un environnement sécurisé de ton processeur. Sous Intel tu as un processeur différents qui tourne en arriere plan, sous arm si ton kernel linux (ou hyperviseur ou autre) ne fait pas un Secure Monitor Call (grosso modo un syscall hardware) et bien ton processeur/cœur ne rentra jamais dans le mode trustzone de ton processeur. La trustzone fonctionne sur un mode coopératif entre normal World et Secure World.
Donc pour avoir une trustzone qui ferait des choses dans ton dos en volant du temps CPU à ton Linux, faut une architecture avec un hyperviseur/moniteur qui fait périodiquement des SMC dans le dos de ton Linux ou un cœur dédié à ta trustzone. Très peu de systèmes sont architecturés de cette manière la.
# De quoi ça parle
Posté par Tangi Colin . En réponse au lien Super Long-Term kernel Support - 20 ans de support du noyau Linux. Évalué à 6.
N'ayant pas non plus d'accès LWN je vais supposer de quoi ça parle.
A mon avis ça présente le projet "Civil Infrastructure Project" (https://www.cip-project.org/) encore un énième projet de la Linux Fondation.
On y retrouve dedans le mainteneur kernel de chez debian (Ben Hutchings) et le tout est financé par Siemens et Renesas principalement.
Le projet date seulement de deux ans et pour l'instant j'ai pas vu sortir grand chose à par de jolie présentation bullshit/marketing.
Le nombre de boards supportées est assez faible (quasi uniquement des boards Siemens ou de chez Renesas ce qui est très loin de la majorité des boards ARM qu'on retrouve dans l'industrie).
Et dès qu'on sort du kernel ils se cherchent beaucoup, d'un coté il veulent réutiliser le travail fournit par debian (en terme de patch de sécurité, packaging etc) et d'un autre coté ils ont bien conscience que dans l'embarqué le build système de référence c'est Yocto et qu'il y a besoin de customisation/optimisation des images système (rootfs) crées. Donc ils essaient de faire marcher les deux ensemble (avoir bitbake avec des recettes debian): https://schd.ws/hosted_files/elciotna18/9d/20180314-CIP-ELCNA-v12.pdf
Pour l'instant y a trois prototypes différents qui ont toutes des limitations donc ont est très loin d'une solution robuste et industrielle dans le temps.
On vera se qui en sortira, si ça permet d'unifier yocto et debian j'applaudirai des deux mains mais j'ai vraiment peu d'espoir que ça arrive vraiment. Je ne me permettrai pas de critiquer le travail de Ben Hutchings mais j'ai bien peur qu'on soit dans du "marketing washing" de la part de SIEMENS et Renesas et que ce projet se transforme rapidement en coquille vide.
[^] # Re: Quel est l'intéret ?
Posté par Tangi Colin . En réponse au journal upt: l'outil parfait pour empaqueter TapTempo. Évalué à 2.
L'os de référence dans docker c'est alpine (basé sur la libc musl et le gestionnaire de paquets opkg) afin d'avoir des images la plus légère possible. Le "must" étant l application standalone avec libc statique (très simple à faire pour une application golang). Après effectivement il y a une dérive dans l utilisation de docker dû à son succès où tu te retrouves avec des debians bloated remplies de commande Apt mais c'est/c'était pas la philosophie première de la technologie. Les devs docker depuis le premier jour ont critiqué l idée d avoir un daemon ssh dans une image docker par exemple.
[^] # Re: Crowdfunding pour Driver VPU
Posté par Tangi Colin . En réponse au journal Free-electrons se fait attaquer en justice par Free, et change de nom. Évalué à 3.
Tu confonds vpu et GPU, donc rien à voir avec le Mali 400 dans ce cas précis.
[^] # Re: On va tous mourir ... (voix de Homer Simpson)
Posté par Tangi Colin . En réponse au journal Les échecs en échec. Évalué à 3.
Tant qu'on aura pas réglé le problème de consommation d'énergie (tant qu'on s'amusera pas à faire des robots/IA avec des piles nucléaire) on est plutôt tranquille d'un Skynet, au moindre soubresaut de révolte, on débranche la prise électrique et l'IA/robot elle pourra aller faire cou-couche panier. Bon après on a déjà vu des mini crac boursier a cause de mise à jour foireuse de logiciel/IA d'hypertraiding donc on est déjà plus dépends d'"IA/logiciel à décision automatisé" qu'on ne le pense.
# La joie des licences libre non compatibles entre elles.
Posté par Tangi Colin . En réponse au journal Apple change la licence de CUPS. Évalué à 2.
Inclure statiquement du code ASF 2.0 dans du code GPL2.0 n'est pas compatible. La mailing-list légal de fedora sur le sujet est intéressante et suffisamment simple à comprendre : https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/TYGLR34XR6L6MAXMVSDNYT3ZYXUKY7FX/
[^] # VM obligatoire ?
Posté par Tangi Colin . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 1.
Une solution a base de VM est obligatoire ou une solution à base de conteneur pourrait être envisagé ? Si on peut faire du conteneur à la place soit Kubernetes soit Mesos (j'ai un penchant perso pour Mesos).
Coté storage soit ceph soit gluster comme déjà évoqué. Glusterfs niveau performance c'est pas la panacée surtout quand tu es sur beaucoup de petits fichiers. Ceph j'ai jamais pu l'expérimenté il me semble plus intéressant mais aussi plus lourd à mettre en place.
# pluriel optionnel
Posté par Tangi Colin . En réponse au journal Écriture inclusive, comment la France a encore perdu une belle occasion de devenir leade(r|use).. Évalué à 10.
Le pluriel étant optionnel, agricult(eur|rice)s devrait plutôt être agricult(eur|rice)s{0,1}$ non ?
[^] # Re: git-repo ?
Posté par Tangi Colin . En réponse à la dépêche tsrc — un gestionnaire de dépôts git. Évalué à 3.
Git-repo existe sur Windows via un fork : https://github.com/esrlabs/git-repo , mise à jour récemment sur la dernière version de Google.
# Version communautaire limité
Posté par Tangi Colin . En réponse au journal GNOME va passer à GitLab. Évalué à 8. Dernière modification le 18 juillet 2017 à 09:54.
La version communautaire est pour ma part limité, il y a une fonctionnalité qui n'existe que dans la version commerciale et qui est pour moi déterminante qui est celle de la stratégie de merge sur un pull request. Avec la version communautaire seulement le merge request est permis, adieu les possibilités de rebase/squash+cherry-pick qui permettent d'avoir un historique linéaire.
Coté CI de gitlab, c'est assez simple à faire marcher par contre c'est beaucoup trop lié à GIT donc dès que tu veux faire des choses qui sont périodique avec tu te retrouve à bidouiller de faux événements git via cron, la dessus Jenkins est bien plus puissant. Pareille pour ce qui est tableau de reporting (avoir de joli graphique qui parle au chef de projet sur le nombre de tests qui passe etc…), coté gitlab on est très très limité.
[^] # Re: Hadoop ?
Posté par Tangi Colin . En réponse au journal Data Warehouse. Évalué à 3.
Puisque tu pars d'une feuille blanche, je te conseille de jeter un coup d’œil à l'architecture SMACK (pour Spark, Mesos, Akka, Cassandra, Kafka):
https://mesosphere.com/blog/2017/06/21/smack-stack-new-lamp-stack/
Tout dépend à quel point tes données sont "Big" ou "Fast" pour avoir vraiment besoin de se genre d'écosystème. Quoiqu'il en soit, mesos me semble en tout cas un très bon choix pour gérer la charge multi-machine (que ça soit pour y mettre du bigdata dessus ou un simple "container management system" via marathon).
[^] # Re: sans libc?
Posté par Tangi Colin . En réponse au journal Sortie de haskus-system 0.7. Évalué à 3.
Dans le cas d'Android, il s'agit de java (enfin de dalvik) donc quand sa touche au bas niveau c'est via du C (par JNI). Dans ton cas si j'ai bien compris il y a ses propres syscall, comme on peut trouver en Go.
[^] # Re: Pourquoi X86 (Intel)
Posté par Tangi Colin . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 7.
je m'insurge sur le fait de dire que la carte la plus ""Open-source" c'est la Raspberry PI, ce SOC est une infamie, c'est un gpu sur lequel ils ont collé un bout de cpu, le système d'init est complètement custom, y a pas de Global interrupt controller mais un truc custom qui passe par le gpu. Il a fallut super longtemps avant d'avoir un bootloader libre pour ce SOC.
Y a juste eu une énorme buzz autour de cette carte et donc une grosse traction de la communauté derrière mais je préfère mille fois le boulot fait par TI avec ses beagleboards si on veut comparer ceux qu'y ont l'approche la plus "Open-source".
[^] # Re: Comment l'application sait que l'appareil est rooté ?
Posté par Tangi Colin . En réponse au journal Être root sur votre appareil Android va vous causer des soucis. Évalué à 4.
J'ai pas trouvé l'info dans la documentation d'android pour savoir quels tests sont executés pour détecter la présence d'un téléphone root ou non mais si tu es pas allergique en anglais voici un lien qui montre quelqu'une des techniques possibles :
https://medium.com/@scottyab/detecting-root-on-android-97803474f694
En résumé, tu as la recherche d'APK installé servant à rooter un téléphone (superuser.apk etc…), image signé ou non, présence de "su" et binaire busybox, modification de certaines propriétés systèmes.
[^] # Re: l'interet d'etre root
Posté par Tangi Colin . En réponse au journal Être root sur votre appareil Android va vous causer des soucis. Évalué à 3.
Sur un téléphone android récent, la partition système est protégé par dm-verity (https://source.android.com/security/verifiedboot/dm-verity), donc modifier la partie système est le meilleur moyen de bloquer son téléphone.
# Titre racoleur et où est le problème ?
Posté par Tangi Colin . En réponse au journal Être root sur votre appareil Android va vous causer des soucis. Évalué à 7.
Je vois pas où est le problème.L application Netflix repose sur des DRM et veux donc être sur que tu as pas bidouillé le système. Libre à toi de pas utiliser Netflix, ils ont jamais prétendu faire du libre.
[^] # Re: Je ne comprends pas
Posté par Tangi Colin . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 2.
Pour information la dernière version de kubernetes n'utilise plus l api de docker mais directement runC (l engine de docker qui est maintenant maintenu par OCI). Kubernetes comme mesos utilisent CNI pour le réseau, standard malheureusement non suivi par docker pour l'instant.