Noyal a écrit 57 commentaires

Je n'y crois pas trop PsychoFox. Note qu'il n'y a pas de mal à partager un tel lien.
Mais si je devais présenter un nouveau logiciel je commencerais par aller à la source. :)

Au final, ce n'est pas plus mal, ça ne fait que montrer l'absurdité de ce système, d'un facteur x20 concernant ce logiciel.

Je vous rassure, je m'arrête ici.

Mais le prosélytisme saoulant, ça va.

Nulle part est proposé le flatpak, je vais sur la page officielle du site que l'utilisateur lambda aura découvert, il aura cliqué sur le bouton download et sera redirigé vers la page suivant:
https://docs.dust3d.org/en/latest/install.html

La première proposition de téléchargement pour Linux est AppImage, pas flatpak ni Fedora ni ma crémière, APPIMAGE.

Procédure

For Linux:
     https://github.com/huxingyi/dust3d/releases/download/1.0.0-rc.6/dust3d-1.0.0-rc.6.AppImage

NOTE: 34Mo le .AppImage créé par l'équipe officielle de dust3d

chmod a+x ./dust3d-1.0.0-rc.6.AppImage
./dust3d-1.0.0-rc.6.AppImage

Et je peux jouer. TOTAL TIME: 15secondes!!!

Je vais tenter le truc que tu essayes de nous vendre à chaques liens.
Je suis la procédure proposée par flatpak.
1) pacman -S flatpak
Il m'est demandé de redémarrer le système une première fois mais je l'ignore et ça ne pose ps de problème.

2)je m'execute
flatpak install flathub org.dust3d.dust3d

    '/var/lib/flatpak/exports/share'
    '/home/rmarc/.local/share/flatpak/exports/share'

    are not in the search path set by the XDG_DATA_DIRS environment variable, so
    applications installed by Flatpak may not appear on your desktop until the
    session is restarted.

    Looking for matches…
    Required runtime for org.dust3d.dust3d/x86_64/stable (runtime/org.kde.Platform/x86_64/5.14) found in remote flathub
    Do you want to inProceed with these changes to the system installation? [Y/n]: stall it? [Y/n]: y

    org.dust3d.dust3d permissions:
        ipc   wayland   x11   dri   file access [1]   dbus access [2]

        [1] xdg-config/kdeglobals:ro
        [2] com.canonical.AppMenu.Registrar

            ID                                             Branch            Op           Remote            Download
     1. [✓] org.freedesktop.Platform.GL.default            19.08             i            flathub            84.6 MB / 85.1 MB
     2. [✓] org.freedesktop.Platform.openh264              2.0               i            flathub           265.1 kB / 916.8 kB
     3. [✓] org.kde.KStyle.Adwaita                         5.14              i            flathub             6.0 MB / 6.0 MB
     4. [✓] org.kde.Platform.Locale                        5.14              i            flathub             6.1 MB / 337.1 MB
     5. [✓] org.kde.Platform                               5.14              i            flathub           265.2 MB / 324.5 MB
     6. [✓] org.dust3d.dust3d                              stable            i            flathub            32.1 MB / 44.1 MB

Installation complete.

600 MO!!! TOTAL TIME: 8min

J'execute la commande totalement-intuitive:
flatpak run org.dust3d.dust3d

OK, au moins, ça démarre. Mais, tout ça pour ça? Et qui maintient org.dust3d.dust3d ?

Où est l'argument, franchement?

"Openh264 est partagé"

1) dust3d n'en a pas besoin à la base.
2) KDE.Platform est partagé. Super, ça va me sauver quelques Mo sur les applications qui l'utiliseraient. Sauf que le AppImage là, il fait 34mo et la portion du flatpak qui correspond à dust3d fait 44.1Mo . Soit le développeur est un branque, soit flatpak ajoute des features.

Mais même sans ça, le dev a partagé une procédure de build simplissime (pour Debian/Ubuntu).

Description de la procédure de build :
 ;Install Qt5
$ sudo apt-get install --reinstall qtchooser
$ sudo apt-get install qtbase5-dev

;Prepare compile environment for CGAL-4.13
$ sudo apt-get install libcgal-dev  ; This is not the latest version, will encounter compiler error when build the Dust3D with this version, but helps resolve internal dependencies of CGAL for you
$ sudo apt install cmake

;Install CGAL-4.13
$ wget https://github.com/CGAL/cgal/releases/download/releases/CGAL-4.13/CGAL-4.13.zip
$ unzip CGAL-4.13.zip
$ cd CGAL-4.13
$ mkdir build
$ cd build
$ cmake ../
$ make
$ sudo make install

;Clone the Main project
$ cd ~/Documents
$ git clone https://github.com/huxingyi/dust3d.git

;Compile Dust3D
$ cd ~/Documents/dust3d
$ qmake -qt=5 -makefile
$ make
$ ./dust3d

ça montre 3 choses:
- AppImage ça marche
- Qt/KDE est facilement portable
- Flatpak est overkill

Désolé de pinailler et de faire un foin mais le prosélytisme idiot me gave. Ni vois pas d'attaque personnelle.

Merci

Ce type d'application flatpakagée est celle avec la procédure de build la plus claire/straightforward du coup, l'intérêt de flatpak en est encore plus réduite.
D'autant qu'il existe un paquet pour Debian/ubuntu, oserai-je dire une majorité du parc? Et que pour une autre distro, elle n'offrira aucunes difficultés à être compilée/assemblée (c'est du python) car l'utilisateur aura déjà eu le courage de sortir des clous. En parlant de clou:

Quand on utilise un marteau, tout ressemble à un clou.

C'est que ce langage a eu une hype immédiate sans même avoir à le prouver, sans applications ou biblio construitent avec et suffisament long dans le temps.

Ce que je n'ai jamais compris et trouvé un peu louche. Une sensation de "trop beau pour être vrai".

Même les fanboys JS n'en font pas des caisses quand un rejetons plusse mieux débarque, même à l'époque la plus chaude.

https://www.reddit.com/r/spacex/comments/gxb7j1/we_are_the_spacex_software_team_ask_us_anything/

"The ifconfig command on operating systems such as FreeBSD and OpenBSD was updated in line with the rest of the operating system. It nowadays can configure all sorts of network interface settings on those operating systems, and handle a range of network protocols. The BSDs provide ioctl() support for these things."

et ça c'est beau!

Merci pour le lien @lolop, c'est très instructif!

C'est fait avec LaTeX ?

-->[X] !!!
… -->[] - \O/

Merci pour la mise au point.
Me prend un beau rateau

Gloire à toi Antistress pour cette trouvaille.

Haha, fumier!

D'ailleurs ça me fait penser, ne serait-il pas temps pour ces émissions d'arrêter les génériques ostentatoires au ton grave et "fear"?

Je verrais bien un petit air au pizzicato. Non, surtout pas de yukulele!!!

OpenBSD est proche de la perfection mais l'attitude de certains des développeurs peut rendre la communauté un peu toxique, c'est bien dommage.

Oh la rangaine de la toxicité.
Ben écoute, FreeBSD est maintenant la terre d'accueil de la "diversity" qu'il fallait appliquer d'urgence et en détourner la trésorerie de la fondation, on verra, hein.

Il suffit de faire un tour sur le mastodon BSD.network out chaos.social pour voir cette diversity qui est plus sur l'ostentation et l'arrogance que victime de la stigmatisation.
Je n'ai vu aucuns profil OpenBSD à part Solène et elle est à l'image d'OpenBSD, passionnée, pro et non gueularde.

OpenBSD est intransigeant et ne se laisse pas polluer par la politique. Et si toxicité il y a, et bien dans les résultats elle lui est plutôt favorable

Moué, FreeBSD est surtout vanté pour ZFS. Tu lui retires ZFS et il lui reste plus grand chose, les jails? Là aussi, c'est la foire aux UIs. Behyve?

Ajoutez à ça la fragmentation à la linux, il n'y a plus vraiment rien d'intéressant.

Si FreeBSD ne tient plus l'échelle selon l'aveu de leur plus grand promoteur (iXsystems), il lui reste quoi?

"Capitaine, capitaine! Regardez là sur l'écran de contrôle… regardez bien, y a rien!" (ref)

https://www.freedesktop.org/wiki/Software/PulseAudio/About

certes, elle fait appel à ce diagramme également mais autant y aller via le bon chemin.

Voulais-tu dire, Le début de la fin pour GNU/Linux, non?

Fuchsia OS c'est tout le système noyau+userland.

Le noyau Linux n'est sans doute pas parfait mais ce ne sont pas les imperatifs techniques qui ont donné naissance à Fuchsia OS, on y voit plutôt la volonté de Google de supporter bout-en-bout sa pile logiciel, à la l'Apple et plus loin (cf: server).

Honnêtement j'ai du mal à voir si le noyau Linux est vraiment le problème dans cette histoire.
J'avoue pour ma part que le meneur de fil Fedora ne m'envoit pas du rêve et pourtant il conditionne le développement d'un système GNU/Linux.
J'en suis à utiliser un linux comme il y a 20 ans, certes le système est plus rapide et plus flexible (mes skills aussi) mais c'est une partie que je n'aurais pas souhaité prendre à ma charge encore en 2020.

Apparement pour Tizen aussi, il y a une API .Net Core.
Et depuis Tizen 4.x ça semble moins Symbianesque.

J'ai une Smart TV avec la dernière mouture de Tizen et j'avoue que c'est assez lèché et fonctionnel, l'écran déporté marche instantanéement et les YouTube/Prime/WWW pareil.

Après, je dois être en manque d'imagination mais je ne vois pas ce que j'aurais envie de coder pour une télé.

La prouesse est sympa mais c'est overkill. Less is more!
On aurait pu aussi citer syncthing mais je le trouve la config peu claire et les perfs décevantes. Dommage, j'aime bien le format 1 binaire (client/server) propre à Go.

Cela ne m'a pas attiré à développer dessus.

Comme Android, en fait. :)

https://doliscan.org/fr/client

Les paquets sont proposés au téléchargemnt sur
- Directement sur notre serveur si votre smartphone est rooté

Il ne faut pas que le téléphone soit rooté pour installer des paquets non-signés. Android demandera explicitement la permission pour installer un tel paquet.

Que l'intérêt ne concerne pas tout le monde c'est probable, mais je comprends la démarche d'activer vocalement ces systèmes.

Je le comprend mais c'est aussi malhonnête et trompeur de le voir comme seule condition pour valider l'usage des commandes vocales.

Moi, je trouve le clavier virtuel pénible et peu pratique en mouvement. Si une simple action physique ex: pression temporisée, combo de touche voire gestures, me permet de m'en passer c'est un maigre prix. D'autant qu'il ne faille pas que ça soit une action qui nécessite de la précision ou trop d'attention, bref un minimum de friction tout à fait acceptable.

Bref, l'un n'empêche pas l'autre mais je préfère que l'utilisateur donne le signal plutôt que de faire accèpter inconsciement qu'il faille une écoûte continue.

Merci!

ah, du coup c'est toujours la bande passante du possesseur de la video qui est utilisée ?
Je pensais que ça suivait le principe du bitorrent.

Juste que quitte à faire une commande vocal autant le faire complétement.

Hé bien non. On peut utiliser une commande vocale car elle serait plus rapide qu'une prise de note au clavier, virtuel qui plus est et donc, imprécis.

Que ça ne change pas grand chose niveaux sécurité/vie privé, si au final le son est toujours envoyer dans le cloud, et que le switch est juste logiciel.

Hé bien si :), ça change tout. Entre une écoûte explicite initié par l'utilisateur qui est conscient de ce qu'il envoit et une écoûte continue qui enregistre des conversations qui ne regardent aucuns services, il y a un monde.

Même si ton téléphone est sous Android/iOS, ce n'est pas une raison.

Pourquoi toutes ces solutions nécessitent-elles un mot clé d'activation qui donc, nécessite que le microphone soit actif en continu?

Une activation physique serait amplement suffisant, non? On a tous une télécommande à portée de main sous la forme d'un smartphone voire d'une smartwatch