Skip Navigation

u_tamtam

@ u_tamtam @programming.dev

Posts
30
Comments
608
Joined
3 yr. ago

  • 18% of people running Nextcloud don't know what database they are using

    Jump

  • You seem to be obsessed with optimising one resource at the expense of others.

    If you want to push it and paint me as obsessed about something, then let it be this: providing this community with on-topic and reasonable advice

    you’re only going to save a few MB of RAM.

    This is false, and you should read once again my previous message illustrating why: on a decent "self-host"-friendly machine, the same software may work very well, or not at all, depending on whether the user would engage with very basic configuration. This goes beyond RAM (memory isn't the sole shared resource), and I'm adamant that the alternative (which was "pretending that the problem doesn't exist" turned into "throwing money at the problem") is unreasonable.

    On the other hand, if you’re doing it to learn more about computers then it might be worthwhile. This is a community of hobbiests, after all…

    Or more importantly: the extent to which you can self-host out of sheer luck and ignorance like you suggest is very limited. If you don't want to engage with a minimum amount of configuration, you might bump into security issues (a much broader and complex subject) long before any of the above has a material impact.

  • 18% of people running Nextcloud don't know what database they are using

    Jump

  • I’m saying this based on real world experience

    And do you think I would spend my time engaging if that wasn't from my own very "real world experience" of lessons learned the hard way?

    Bringing-up "diminishing returns" as if this was an optimisation game also doesn't do this justice. Take the typical "household FOSS package" with software names often brought up in here: a nextcloud instance, a photo-sharing service like immich, private instant messaging, a software forge, a subsonic-compatible audio/video streaming server, a couple php websites like wallabag and RSS aggregators.

    An Intel Atom CPU and 4GB of RAM is plenty sufficient for all that, and will cost you single digit USD a month, granted you put the (one-time) effort to tune and balance those services. Would you run all the above from upstream's docker files, I can guarantee you that you would deem this (perfectly fine otherwise) server underpowered for the task at hand (and would probably go for a 10th gen or so Intel Core CPU, quadruple the RAM and 3-6× the energy cost in the process).

    And that's the point I'm making here: a self-hosting community of tinkerers should (ideally) know better, for the ethics' sake of keeping the process environmentally friendly, and not wasting other people's money.

  • 18% of people running Nextcloud don't know what database they are using

    Jump

  • Do you have the data to back that up?

    I mean, you are the one making the exceptional claim that unnecessarily running multiple instances of programs on a device with finite resources has no practical adverse effect. Of course, the effects can be more or less drastic depending on the many variables at play (hardware, software, memory pressure, thread starvation, cache misses, …) and can indeed be negligible in some lucky circumstances. The point is that you don't call that shot, and especially not by burying your head in the sand and pretending it's never gonna be a problem.

    Effective use of computing resources requires tuning. Introduction of a new service creates imbalance. Ensuring that the server performs nominally and predictably for all intended services is a balancing act and a sysadmin's job. Services whose deployment settings are set by someone with no prior knowledge of the deployment constraints can't be trusted to do a good job at it (that's the nature of the physical world we live in, not my opinion), and promoting this attitude promote the kind of wasteful and irresponsible computing I was on about.

    Now, I'll give you the link to this basic helper for tuning a PostgreSQL server: https://pgtune.leopard.in.ua/Will you tell me what are the correct inputs for my homelab (I won't tell you the hardware, the set-up, the other services running on it, the state of the system, etc)?And later, when you will distribute your successful container to millions of users, what will you respond to the angry ones that will complain that your software is slow, to no fault of your coding, because they happen to pile up multiple DBs, web servers, application servers, reverse proxies, … on their banana SoCs?

  • 18% of people running Nextcloud don't know what database they are using

    Jump

  • I disagree. You are just entertaining the idea that servers must always and forever be oversized, that's the definition of wasteful (and environmentally irresponsible). Unless you are firing-up and throwing-away services constantly, nothing justifies this and sparing the relatively low effort it is to deploy your infrastructure knowingly.

  • 18% of people running Nextcloud don't know what database they are using

    Jump

  • Precisely what pre-devops sysadmins were saying when containers were becoming trendy. You are just pushing the complexity elsewhere, and creating novel classes of problems for yourself (keeping your BoM in control and minimal is one of many others that got thrown away)

  • 18% of people running Nextcloud don't know what database they are using

    Jump

  • Self hosting doesn't mean "being wasteful and letting containers duplicate services". I want to know which DB application X is using, so I pool it for applications Y and Z.

  • Hot on the heels of the H2S, Bambu Lab announces the seven-color, wireless nozzle-swapping Vortek H2C

    Jump

  • they dont have a functioning prototype

    Seems incompatible with their claim that they will ship this year

  • Scala's Gamble with Direct Style

    Jump

  • Interesting take. I'm personally fine with either style, but I can't go as far as pretending that the monadic one is ergonomic. I don't think it's a great way to develop in general, "Monads don't compose" is a reality, and having "do-it-all/God Monad" is band-aid for hardly managing to shove everything in a "mother-of-all" for-comprehension.

    I believe that a majority spontaneously rejects monadic style, for good and bad reasons. It used to be a necessity when there were fewer options out there for performant asynchronous programming. The "program is a value" argument is that of a leaky abstraction as soon as purity isn't enforced (for which, interestingly, caprese/capture-checking and "direct-style" might help).

    In all, the monadic style has always been pretty niche, except in the rare occasions there was no compelling alternative. I don't expect it will see more adoption. What it was promising to deliver on a theoretical-level only (referential transparency) will be accomplished in a more straightforward manner. Runtimes may or may not catch-up with the performance of effect systems, it won't matter for the vast majority of the programs. And if you are in this niche, then nothing will change for you except for the few compiler guarantees brought by capture-checking.

  • FFmpeg moves to Forgejo

    Jump

  • Why would you think so? Can you give examples of specific tools that wouldn't be available to mail clients? On the other hand, there are many things available on most email clients which are missing on GitHub, like tagging automation from custom and flexible rules, Turing-complete filtering, instant searching, saved searches, managing the lifecycle of issues, linking with the VCS etc. all in context and in one place.How people generally go about re-implementing those on GitHub is with bots, and you are left at the mercy of what the bot can do/its admin wants you to do, and each project is its own silo and possibly breaks your workflow.

    I'm fine with GitHub because these days I'm mostly a casual contributor, but there's a lost appreciation for the sheer power and universality of email-based workflows. That the largest projects (including the Linux kernel) run on that should speak for itself.

  • FFmpeg moves to Forgejo

    Jump

  • I figured they'd be juggling a lot of mails

    Yeah, but organized into as many threads as there are issues/PRs, so it's exactly as daunting as the same list as viewed on GitHub/project/issues (because it is exactly the same content).

    and I guess it is possible for some people to stay on top of that

    It's the crux of being a maintainer, it's your job "to stay on top of that", with, on larger projects, ad-hoc tooling and automation being the only way. Email is infinitely more flexible than the one-size-fits-all take by GitHub on that.

  • AI industry horrified to face largest copyright class action ever certified

    Jump

  • In which way do you expect this to strengthen copyright laws? Also, from the article, it reads like Anthropic implicitly admits to copyright infringement, and that their defence essentially boils down to "if you prosecute us, we will go bankrupt". I don't see how that flies, but then again, IANAL :-)

  • AI industry horrified to face largest copyright class action ever certified

    Jump

  • It's pretty simple: if Antropic wins, that's the end of the US copyright law, replaced by the diktat of the tech bros (worse for artists, and for anyone else but the tech oligarchs). If Antropic loses, nothing changes and we get to fight the (comparatively tiny) copyright mafia for another day.

  • Deleted

    IntelliJ Scala Plugin 2025.2 Is Out! | The IntelliJ Scala Plugin Blog

    Jump

  • Looks like it, indeed! The programming.dev Lemmy instance was incredibly slow, so that might have to do with it. Deleting this post as a result!

  • WhatsApp, Telegram et Signal, c'est terminé : les agents publics devront utiliser la messagerie de l'État Tchap dès la rentrée

    Jump

  • Et donc tu souhaites faire combien de fois le tour du même pot ? On est déjà passé par là. Matrix.org est la plus grosse instance, managée par EMS. Mozilla, KDE, Gnome sont les autres grosses instances, aussi managées par EMS. La même entité qui développe Synapse en opencore, la seule implémentation serveur compatible avec elle-même, et a la main mise sur le seul client capable (element), de même que le protocole. Je ne te laisserai pas dire que ce niveau de centralisation est "symbolique".

    Et dès que tu veux auto-héberger Synapse et sortir de cette centralisation, tu te retrouves confronté à ce genre de débilités. Donc je me répète mais non: la fédération technique bien qu'existante, est complexe et coûteuse en pratique, a contribué à faire de matrix.org le nœud principal du réseau, et son principal point de faiblesse tant la fédération entre matrix.org et le reste du réseau est constamment pétée.

    Je ne doute pas de ton enthousiasme pour Matrix, je sympathise, étant passé par là. Je t'invite cependant à sortir de ta bulle et voir ce qu'il existe autour.

  • WhatsApp, Telegram et Signal, c'est terminé : les agents publics devront utiliser la messagerie de l'État Tchap dès la rentrée

    Jump

  • Je pense qu'on a en effet dépassé le stade de la discussion cordiale, je sens beaucoup d'insécurité dans ta réponse et c'est bien dommage.

    Je ne gagne rien à ferrailler avec toi donc je ne vais pas entretenir ce débat plus longtemps, mais je vais quand même corriger certains propos mensongers ou inexacts pour qui lirait ce thread :

    Matrix est décentralisé en dessein mais pas en pratique

    C’est faux

    C'est vrai, de l'aveu même des développeurs de matrix, ref: https://matrix.org/blog/2024/03/why-matrix-org/

    Ça se fait très bien sur un SoC à 50-80€ à la maison, bref.

    Administrer un serveur fédéré requiert beaucoup de resources et d'attention:

    Le cas de Tchap est encore plus à charge: vu qu’il n’est de toute façon pas question de fédérer, à quoi bon s’imposer toute cette complexité technique ?

    Qu’est-ce qui te permet de l’affirmer ? Je demande parce que de toute évidence, la feuille de route 2025 de la DINUM mentionne la fédération

    D'après ton lien, il est question de "Permettre les interactions avec d'autres outils de communication qui utilisent le protocole Matrix. L’enjeu est de faciliter les échanges entre utilisateurs de différentes applications, permettant une collaboration plus fluide.", il n'est pas mentionné de fédération avec des utilisateurs d'autres serveurs, et encore moins de serveurs du réseau ouvert Matrix (si tu as des contre-exemples, je suis preneur).

    Et si element-hq finit par mettre la clé sous la porte définitivement, et qu’il ne reste plus que Tchap, fruit d’un déploiement très spécifique, il y a peu de chance que ce qu’il en résulte ne bénéficie à qui que ce soit.

    Sachant qu’il est possible de fork Tchap et de retirer les personnalisations qui seraient inutiles, ça bénéficie de fait à tout le monde

    Le gouvernement français n'a pas pour ambition de développer Tchap pour "tout le monde", le gouvernement français développe Tchap pour lui-même (ses fonctionnaires et ministères). Si le gouvernement français n'avait pas de besoins spécifiques en la matière, le gouvernement français utiliserait "element" et pas "tchap" et il n'y aurait pas de fork.

    Tu comprends que ce serait pas judicieux d’avoir un seul serveur pour toute la France ?

    Je ne pense pas que Matrix soit scalable au point de supporter 70M de comptes sur un seul serveur, non, mais d'autre protocoles fédérés en sont capables. Joli homme de paille, soit dit en passant (les problèmes que je remote à l'encontre de Matrix sont sans rapport il me semble?).

    Par ailleurs, et pour fermer le point sur ce que je trouve "judicieux" en la matière, il s'avère que j'administre plusieurs serveurs XMPP fédérés dont le plus gros a 500 comptes utilisateurs. Mon problème avec Matrix n'est pas idéologique comme tu le prétends, mais bien d'ordre pratique.

    Autres lectures récentes pour les curieux:

  • WhatsApp, Telegram et Signal, c'est terminé : les agents publics devront utiliser la messagerie de l'État Tchap dès la rentrée

    Jump

  • Ce que je lis ne fais pas beaucoup de sens de mon point de vue

    Il me semble qu’il y a une confusion entre la notion de “viabilité commerciale” et celle de “viabilité fonctionnelle” ou “maintenabilité”.

    Il n'y a aucune confusion, le fait est qu'aujourd'hui aucune organisation (commerciale ou non) n'est apte à supporter et maintenir Matrix (commercialement, fonctionnellement, technologiquement, je ne vois pas de nécessité à les différencier tant ils sont interconnectés).

    Il n'y a aucun signe avant-coureur que cela ne change, et pire, les contre-exemples d'échecs passés sont nombreux. J'y inclue:

    • les implémentations clients/serveurs tierces et officielles abandonnées
    • la volonté de dissocier l'entité en charge du développement du produit, de sa spécification, et de sa commercialisation n'ayant jamais abouti en pratique
    • le schisme récent subséquent au changement de license et la nécessité pour les contributeurs de signer un CLA au profit de element-hq (défaisant en partie le point précédent)
    • le manque complet de turnover/le problème de bus-factor
    • le fait que les financements en venture-capital qui permettaient à new-vector/element-hq/… d'opérer à perte n'ont pas été remplacés, sous quelque forme que ce soit (le niveau d'importance accordé à Matrix par ses proponents est clairement surestimé)

    Matrix est chaque jour de plus en plus moribond et à risque.

    Au contraire je dirais, c’est plutôt pour fournir une infrastructure décentralisée, ouverte et interopérable pour les communications, sans se soumettre aux exigences du marché classique.

    • Matrix est décentralisé en dessein mais pas en pratique : la plupart des comptes, bridges et salons actifs sont hébergés sur le node matrix.org, sur-représenté sur le réseau. Les raisons à ça sont mauvaises mais justifiées : auto-héberger matrix est une expérience atroce (j'ai donné) et coûteuse (en resources matérielles autant que temporelles), les soucis de fédération sont constants et traduisent un manque de maturité/robustesse de l'implémentation technique (ce qui est injustifiable après 10 ans…). En d'autres termes, je ne crois pas au potentiel de Matrix d'être le "protocole fédéré/décentralisé" du futur, il est trop inefficient et demandeur pour ça.
    • Le cas de Tchap est encore plus à charge: vu qu'il n'est de toute façon pas question de fédérer, à quoi bon s'imposer toute cette complexité technique ? On peut parier que les admins de Tchap retireront cette possibilité si tant est que element-hq n'est plus en mesure de supporter la maintenance gracieusement pour eux. Et si element-hq finit par mettre la clé sous la porte définitivement, et qu'il ne reste plus que Tchap, fruit d'un déploiement très spécifique, il y a peu de chance que ce qu'il en résulte ne bénéficie à qui que ce soit.

    Alors je sais pas ce que ça représente pour toi plusieurs états européens et institutions publiques mais disons que c’est pas les petites assos du coin non plus quoi

    • Ces mêmes institutions et états ont leurs œufs dans plusieurs paniers. L'OTAN utilise XMPP sur le terrain, de même que la police allemande. Il n'y a pas d'exceptionalisme Matrix en la matière.
    • Je ne sais pas dans quelle mesure tu es familier du sujet (apparemment assez-peu), mais ceci est le résultat direct de quand la France a décidé d'arrêter de payer element pour le support de Matrix. De la à penser que les intérêts et priorités divergent en la matière…

  • WhatsApp, Telegram et Signal, c'est terminé : les agents publics devront utiliser la messagerie de l'État Tchap dès la rentrée

    Jump

  • C’est un fork, ils ont la possibilité de continuer à le maintenir et au pire peuvent garder les versions actuelles qui marchent.

    Ça me paraît bien optimiste : en 10 ans de temps, à coup de millions en venture capital, Matrix n'a pas réussi à transformer l'essai et en faire un produit commercialement viable et efficace, ni a attirer une communauté d'enthousiastes suffisamment compétents et persévérants pour en assurer une maintenance par des tiers sur le long terme. Je pense que ça en dit long sur la complexité du projet, corroborée par le flux continu de failles de sécurité, et l'effort de maintenance associé.

    Après, c’est aussi AMHA le rôle d’un état que de participer à la maintenance d’un ecosystème libre, qui est une mission de service public par excellence.

    Sur ce point je suis d'accord, mais ça ne fait pas automatiquement de Matrix le "bon" choix.

  • WhatsApp, Telegram et Signal, c'est terminé : les agents publics devront utiliser la messagerie de l'État Tchap dès la rentrée

    Jump

  • Reste à voir pour combien de temps, Tchap est basé sur Matrix, qui est en difficulté financière depuis de nombreuses années. Le protocole est obscène au point qu'une seule entité (celle en faillite) a le courage de maintenir le protocole et sa seule implémentation (client ET serveur) à jour. Ça pue.

  • When the world connected on Skype

    Jump

  • I don’t see what you’re describing 🤷 Soon only appears once on the page and not in this context for me.

    It appears as a tooltip

    Anyhow, where I intended to draw your intention was on https://prose.org/downloads

    You can just download the client for your platform (assuming one is available), or use the web one (otherwise), or just build one from the sources I linked (which is what I do), and login with your usual XMPP account. Would you need an account and have to decide which provider to register with, this would come handy: https://providers.xmpp.net/

    In this set-up, prose.org isn't hosting your account and will of course let you interact with thousands of users or more, like any other XMPP client.

  • The Endgame of Edgelord Eschatology - Truthdig

    Jump

  • Those silicon valley tech billionaires are businessmen who, by the looks of it, have completely fallen for their own marketing, and secluded themselves in a weird echo chamber packed with sycophants and profiteers. They are not superior beings. They have no credential nor academic status enabling them to speak as authorities worth being listened to. Anyone with a critical mind and access to scientific literature understands better than them the actual challenges behind "uploading one's brain to the cloud" and can debunk that science fictionesque bullshit.

    All there is to this is a bunch of aging megalomaniacs with too much power, except over death, and that scares the crap out of them and makes them say some stupid shit. And I hate that we sanewash this just because they are rich and influential. As a society we should kick them back to where they belong, which is a court of law, for their continued effort in dismantling our society.