Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Discussions Générales 4 G sous linux ?

4 G sous linux ?

141 réponses
Avatar
ptilou
Bonsoir,

Je vais me prendre un abonnement 4 G chez AT & T, y a t'il du Linux qui fonctionne ?

( euh NON ! )

Ptilou
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3 4 5 6 7
Avatar
LeLapin
Le Fri, 8 Feb 2013 09:50:59 +0000 (UTC)
JKB a écrit :

Le Fri, 8 Feb 2013 10:49:12 +0100,
LeLapin écrivait :
> Le Fri, 8 Feb 2013 09:46:09 +0000 (UTC)
> JKB a écrit :
>
>> Surtout que tous les outils cités ne fonctionnent qu'avec
>> d'horribles hacks et ne compilent que grâce à des #ifdef
>> Darwin et #define _DARWIN_C_SOURCE. Dans compter les verrues
>> redéfinissant des fonctions POSIX de base pour qu'elles soient
>> conformes à POSIX.
>
> Les interpréteurs compilent...
>
> Après quasi 40 ans d'informatique je découvre ça. :D

Ton interprète, tu dois le compiler avant qu'il puisse
interpréter le moindre code.



Juste que par définition un interpréteur est stable, ne se base q ue sur
ses propre librairies, et (mais c'est récent, et on a des tas
d'exemples que ça marche bien) sur d'autres librairies avec des entr ées
stables.

C'est un peu comme si tu disais qu'un interpréteur Basic des 70s/80s
renvoyait un message d'erreur sur une instruction parce qu'entretemps
un connard responsable de la routine de ladite était mal-baisé.

T'es pas sérieux, et la totalité des langages interprétà ©s te détrompent.
(non que je les aime, mais faut pas déconner quand même)
Avatar
JKB
Le Fri, 8 Feb 2013 11:02:32 +0100,
LeLapin écrivait :
Le Fri, 8 Feb 2013 09:50:59 +0000 (UTC)
JKB a écrit :

Le Fri, 8 Feb 2013 10:49:12 +0100,
LeLapin écrivait :
> Le Fri, 8 Feb 2013 09:46:09 +0000 (UTC)
> JKB a écrit :
>
>> Surtout que tous les outils cités ne fonctionnent qu'avec
>> d'horribles hacks et ne compilent que grâce à des #ifdef
>> Darwin et #define _DARWIN_C_SOURCE. Dans compter les verrues
>> redéfinissant des fonctions POSIX de base pour qu'elles soient
>> conformes à POSIX.
>
> Les interpréteurs compilent...
>
> Après quasi 40 ans d'informatique je découvre ça. :D

Ton interprète, tu dois le compiler avant qu'il puisse
interpréter le moindre code.



Juste que par définition un interpréteur est stable, ne se base que sur
ses propre librairies, et (mais c'est récent, et on a des tas
d'exemples que ça marche bien) sur d'autres librairies avec des entrées
stables.



Tu ne pas pas lu (ou pas compris). L'interprète est stable, c'est un
fait. Mais pour qu'il puisse interpréter un début de programme sous
MacOS X, il a fallu qu'un type se tape le portage de cet interprète
sous MacOS X, et c'est un sale boulot pour l'avoir fait. Idem pour
les bibliothèques associés à cet interprète.

C'est un peu comme si tu disais qu'un interpréteur Basic des 70s/80s
renvoyait un message d'erreur sur une instruction parce qu'entretemps
un connard responsable de la routine de ladite était mal-baisé.



Rien à voir avec le schmilblick. Certaines fonctions Unix03 (je
parle de ça parce que MacOS X est prétendûment Unix03) ne sont pas
conformes aux specs parce qu'il n'existe pas d'appel système dans
XNU pour les implanter facilement. Je ne te parle pas de fonctions
des années 70, mais de fonctions parfaitement spécifiées dans Unix03
ou POSIX.1 (je ne demande même pas un truc conforme à POSIX-2008 !)
Résultat des courses, si ton interprète, par le plus grand des hasards,
utilise cette fonction sur un Unix de base, tu vas devoir tourner
autour du pot pour qu'il fonctionne de la même façon sous MacOS X.
Ça peut être assez marrant. Le dernier truc que j'ai dû bricoler
ressemble à ça :

__EXTERN__ pthread_mutex_t mutex_sem __STATIC_MUTEX_INITIALIZATION__;
__EXTERN__ sem_t __PTR__ semaphore_gestionnaires_signaux;
...

avec les #define qui vont bien pour __EXTERN__ et pour __PTR__,
uniquement pour contourner les manquements de MacOS X (et augmenter
par là la propreté du code). Pour l'utilisateur, rien n'a changé.
Mais pour la maintenance du code de l'interprète, tu m'excuseras,
mais ce n'est pas terrible.

Et ce sont deux exemples parmi tant d'autres comme :

# define sem_init(a, b, c) sem_init_SysV(a, b, c)
# define sem_destroy(a) sem_destroy_SysV(a)
# define sem_wait(a) sem_wait_SysV(a)
# define sem_trywait(a) sem_trywait_SysV(a)
# define sem_timedwait(a, b) sem_timedwait_SysV(a, b)
# define sem_post(a) sem_post_SysV(a)
# define sem_getvalue(a, b) sem_getvalue_SysV(a, b)
# define sem_open(...) sem_open_SysV(__VA_ARGS__)
# define sem_close(a) sem_close_SysV(a)
# define sem_unlink(a) sem_unlink_SysV(a)

avec les réécritures des fonctions en question histoire qu'elles
soient conforme à quelque chose de connu en utilisant les fonctions
standard sous la autres Unix (et en évitant de se vautrer lors de
l'édition des liens).

T'es pas sérieux, et la totalité des langages interprétés te détrompent.
(non que je les aime, mais faut pas déconner quand même)



Entre purement interprété à la façon Basic et entièrement compilé à
la façon C ou Fortran, il y a toute une foultitude de langages
semi-compilés tout à fait intéressants.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
LeLapin
Le Fri, 8 Feb 2013 10:15:11 +0000 (UTC)
JKB a écrit :

Le Fri, 8 Feb 2013 11:02:32 +0100,
LeLapin écrivait :
> Le Fri, 8 Feb 2013 09:50:59 +0000 (UTC)
> JKB a écrit :
>
>> Le Fri, 8 Feb 2013 10:49:12 +0100,
>> LeLapin écrivait :
>> > Le Fri, 8 Feb 2013 09:46:09 +0000 (UTC)
>> > JKB a écrit :
>> >
>> >> Surtout que tous les outils cités ne fonctionnent
>> >> qu'avec d'horribles hacks et ne compilent que grâce à des #ifdef
>> >> Darwin et #define _DARWIN_C_SOURCE. Dans compter les verrues
>> >> redéfinissant des fonctions POSIX de base pour qu'elles soient
>> >> conformes à POSIX.
>> >
>> > Les interpréteurs compilent...
>> >
>> > Après quasi 40 ans d'informatique je découvre ça. :D
>>
>> Ton interprète, tu dois le compiler avant qu'il puisse
>> interpréter le moindre code.
>
> Juste que par définition un interpréteur est stable, ne se ba se que
> sur ses propre librairies, et (mais c'est récent, et on a des tas
> d'exemples que ça marche bien) sur d'autres librairies avec des
> entrées stables.

Tu ne pas pas lu (ou pas compris). L'interprète est stable,
c'est un fait. Mais pour qu'il puisse interpréter un début de
programme sous MacOS X, il a fallu qu'un type se tape le portage de
cet interprète sous MacOS X, et c'est un sale boulot pour l'avoir
fait. Idem pour les bibliothèques associés à cet interpr ète.

> C'est un peu comme si tu disais qu'un interpréteur Basic des 70s/8 0s
> renvoyait un message d'erreur sur une instruction parce
> qu'entretemps un connard responsable de la routine de ladite était
> mal-baisé.

Rien à voir avec le schmilblick. Certaines fonctions Unix03
(je parle de ça parce que MacOS X est prétendûment Unix03) ne sont pas
conformes aux specs parce qu'il n'existe pas d'appel système
dans XNU pour les implanter facilement. Je ne te parle pas de
fonctions des années 70, mais de fonctions parfaitement spécifi ées
dans Unix03 ou POSIX.1 (je ne demande même pas un truc conforme à  
POSIX-2008 !) Résultat des courses, si ton interprète, par le p lus
grand des hasards, utilise cette fonction sur un Unix de base, tu vas
devoir tourner autour du pot pour qu'il fonctionne de la même faà §on
sous MacOS X. Ça peut être assez marrant. Le dernier truc que j 'ai dû
bricoler ressemble à ça :

__EXTERN__ pthread_mutex_t mutex_sem
__STATIC_MUTEX_INITIALIZATION__; __EXTERN__ sem_t __PTR__
semaphore_gestionnaires_signaux; ...

avec les #define qui vont bien pour __EXTERN__ et pour
__PTR__, uniquement pour contourner les manquements de MacOS X (et
augmenter par là la propreté du code). Pour l'utilisateur, rien n'a
changé. Mais pour la maintenance du code de l'interprète, tu
m'excuseras, mais ce n'est pas terrible.

Et ce sont deux exemples parmi tant d'autres comme :

# define sem_init(a, b, c) sem_init_SysV(a, b, c)
# define sem_destroy(a) sem_destroy_SysV(a)
# define sem_wait(a) sem_wait_SysV(a)
# define sem_trywait(a) sem_trywait_SysV(a)
# define sem_timedwait(a, b) sem_timedwait_SysV(a, b)
# define sem_post(a) sem_post_SysV(a)
# define sem_getvalue(a, b) sem_getvalue_SysV(a, b)
# define sem_open(...) sem_open_SysV(__VA_ARGS__)
# define sem_close(a) sem_close_SysV(a)
# define sem_unlink(a) sem_unlink_SysV(a)

avec les réécritures des fonctions en question histoire
qu'elles soient conforme à quelque chose de connu en utilisant les
fonctions standard sous la autres Unix (et en évitant de se vautrer
lors de l'édition des liens).

> T'es pas sérieux, et la totalité des langages interprét és te
> détrompent. (non que je les aime, mais faut pas déconner quan d même)

Entre purement interprété à la façon Basic et enti èrement
compilé à la façon C ou Fortran, il y a toute une foultitu de de
langages semi-compilés tout à fait intéressants.

JKB




Yop ! Un peu en vrac.

J'ai pas débuggé le log, pour de bonnes raisons. ;)

Tu mets en cause le semi-interprété, ce qui est plus que louable
(l'interface) mais tu ne réponds pas à ma question.sur la notion de
profondeur du langage, et ce que tu appelais (et où je répondais)
"interprété".

Je ne vais pas passer mon printemps à faire la différence entre un
langage localisé, ne serait-ce que partiellement, et un interprét é.

Et j'ai vu un Fortran interprété qui n'implémentait juste pas
le F-77.

Par ailleurs il y a eu des Basics compilés plutôt pas mal.

Un langage interprété n'a rien à branler de l'édition d e liens. Ni des
définitions.
Avatar
ST
* JKB wrote:

Surtout que tous les outils cités ne fonctionnent qu'avec
d'horribles hacks et ne compilent que grâce à des #ifdef Darwin et
#define _DARWIN_C_SOURCE. Dans compter les verrues redéfinissant des
fonctions POSIX de base pour qu'elles soient conformes à POSIX.



Tu veux dire qu'un Unix dont l'interface graphique n'est pas X et qui
est basé sur un couple Darwin/FreeBSD a nécessité des adaptations pour
que le gros du logiciel Libre (dont une grosse partie se base sur GNU)
puisse tourner dessus.

Incroyable, on dirait une implémentation simulée.

Porter du code sources à l'un des standards Unix sous MacOS X est
souvent plus tordu que de porter le même code sous OpenBSD, c'est
dire. Et je sais à peu près de quoi je parle, mon cher ST, parce que
c'est un sport que je pratique.



Ben oui, et, ça suffit pas pour faire de OS/X un mauvais Unix. Tout au
plus, cela en fait une implantation incomplète et imparfaite, ce qui est
le cas de tous les Unix (c'est même ce qui les définit, d'ailleurs).

Il y a des implantations POSIX bien plus incomplètes et imparfaites de
POSIX que OS/X, il y en a d'autres meilleures. Le fait est que OS/X
tourne et que la très grosse majorité de la bibliothèque Unix Libre
tourne très bien dessus.
Avatar
Tonton Th
On 02/08/2013 04:40 AM, ST a dit:

choix délirant des logiciels installés par la Slack



Chic, une li ste !

En plus c'est une vraie question : je vais bientôt installer
une machine "percheron", et je cherche une distribution simple
et robuste, avec juste ce qu'il faut pour compiler/utiliser
des choses comme postgresql, povray et apache+perl.

--
http://foo.bar.quux.over-blog.com/article-thsf-2013-114632120.html
Avatar
Tonton Th
On 02/08/2013 06:11 AM, ptilou a dit:

Je vous l'accorde, bien dire ne dispense pas de bien faire ...



D'ailleurs, pourrais-tu expliquer en quoi quoter avec
un double interlignage est "bien faire" ?

--
http://foo.bar.quux.over-blog.com/article-thsf-2013-114632120.html
Avatar
LeLapin
Le Fri, 08 Feb 2013 13:03:26 +0100
Tonton Th a écrit :

On 02/08/2013 06:11 AM, ptilou a dit:

> Je vous l'accorde, bien dire ne dispense pas de bien faire ...

D'ailleurs, pourrais-tu expliquer en quoi quoter avec
un double interlignage est "bien faire" ?




Dans le genre, en quoi écrire avec tabs (ou espaces répétà ©s) en début
de ligne est un truc acceptable ? :p
Avatar
Tonton Th
On 02/08/2013 09:26 AM, ST a dit:

LaTeX, Mutt, slrn, Emacs, Vim, Perl, Python, Ruby ... la liste est
encore TRES longue, fonctionnent très bien sur Mac OS X.



C'est bizarre, il n'y a pas la moindre application X11 dans
cette liste... Peut-on savoir comment fonctionnent ces quelques
trucs que j'ai dans mon "desktop" Linux :

firefox, thunderbird, geeqie, gimp, xpaint, gedit, transmission,
xchat, liferea, audacity, frozen-bubble et ghostview ?

--
http://foo.bar.quux.over-blog.com/article-thsf-2013-114632120.html
Avatar
ST
* Tonton Th wrote:
choix délirant des logiciels installés par la Slack


Chic, une li ste !



La quantité incroyable de saloperies (casual games) qui vont avec KDE,
le fait que tout ce qui est reseau soit dans la meme categorie (des
lecteurs de news a ifconfig) ...

J'aime bien la Slack, mais mon gros probleme avec cette distrib est la
difficulté pour simplement installer un système de base sans trucs
parasites.

En plus c'est une vraie question : je vais bientôt installer
une machine "percheron", et je cherche une distribution simple
et robuste, avec juste ce qu'il faut pour compiler/utiliser
des choses comme postgresql, povray et apache+perl.



FreeBSD, aujourd'hui, je pense que c'est l'Unix Libre le plus
fonctionnel, le plus pratique et le mieux foutu sur le marché.
Avatar
Tonton Th
On 02/08/2013 11:36 AM, LeLapin a dit:

Et j'ai vu un Fortran interprété qui n'implémentait juste pas
le F-77.



Je suis preneur.

--
http://foo.bar.quux.over-blog.com/article-thsf-2013-114632120.html
3 4 5 6 7