Skip Navigation
git discussion bingo
  • A merge from upstream once a day, at the beginning of the day.

    I'm working on a DevOps setting, and even though we're a small team, we have about two to three changes going through the pipeline a day.

    If you keep your fork too long without syncing, it just get more complicated to merge, and more importantly if you need help from the upstream change author they'll have moved on to another subject and the change won't be as fresh in their mind as if you had merged the day after they pushed it.

  • git discussion bingo
  • I've had that kind of reaction - on rebases also - and most times it was in fact a code smell pointing to a case of spaghetti code.

    If you get to the point that you fear upstream merges/rebases into your WIP, stop for a second and ask yourself if maybe that might be an issue with too much interpendencies inside the code itself. Code should be as close to an directed acrylic graph as possible. (doesn't count, I was not speaking of git! :b )

  • Give browser and wine ownership to user "nobody" = "foolproof" against viruses?
  • A process owned by any user will be able to exploit a userspace vulnerability, whatever this user is. Selinux, chroot, cgroups/containerization add a layer of protection to this, but any vulnerability that bypass these will be as exploitable from nobody as from any other local user. It will protect a user files from some access attempts but will fail to prevent any serious attack. And as usual when it comes to security, a false sense of security is worse than no security at all.

    Remember that some exploits exist that can climb outside of a full-blown virtual machine to the virtualisation host, finding a user escalation vulnerability is even more likely.

    The only real protection is an up-to-date system, sane user behavior and maybe a little bit of paranoia.

  • Google Made Me Ruin A Perfectly Good Website: A Case Study On The AI-Generated Internet
  • Given this trend, GPT 5 or 6 will be trained on a majority of content from its previous versions, modeling them instead of the expect full range of language. Researchers have already tested the outcome of a model-in-loop with pictures, it was not pretty.

  • Microsoft is unbundling Teams from Office in Europe to address regulator concerns
  • You mean Microsoft will recoup the cost of unbundling by charging more per product compared to the previous bundle, given that it's now different products?

    'cause at work the powers that be has gone all-in on MS and this decision won't change a bit their "strategy".

  • Google Play is beyond annoying
  • Each and every line of code you write is a liability. Even more so when you wrote it for someone else. You must always be able to rebuild it from source, at least as long as your client expect the software to work. If you feel it's not worth it, you probably low-balled the contract. If you don't want to maintain code, have the client pay a yearly maintenance fee, give the code and the responsibility to maintain it to your client at the end of development, or add a time limit to it's support.

    There's no "maintenance mode" software: either it's in use and must be kept updated with regard to it's execution environment, or it's not used anymore and can be erased and forgotten. Doing differently opens too much security issues, which shouldn't be acceptable for us all as a trade.

  • Deleted
    *Permanently Deleted*
  • Forewarning : ops here, I'm one of the few the bosses come to when the "quick code" in production goes sideways and the associated service goes down.

    soapbox mode on

    Pardon my french but that's a connerie.

    Poorly written code, however fast it has been delivered, will translate ultimately into a range of problems going from customer insatisfaction to complete service outage, a spectrum of issues far more damageable than a late arrival on the market. I'd add that "quick and dirty code" is never "quick and dirty code with relevant, automated, test coverage", increasing the likelihood off aforementioned failures, the breadth of their impact and the difficulty to fix them.

    Coincidentally , any news about yet another code-pissing LLM bothers me a tad, given that code-monkeys using such atrocities wouldn't know poorly written code from a shopping list to begin with, thus will never be able to maintain the produced gibberish.

  • Trails and the invisibility of Versys

    Just stumbled upon a midsize japanese trails comparison, and the Versys was distinctly absent. A V-Strom, Tenere and Transalp, all different and with their strengths, be it off or on road, and yet no mention of my very subjectively beloved Versys.

    So may I ask this venerable assembly it's opinion on the subject? How come the Versys seems to fly under the radar, what is it lacking to be noticable - or more egoistically, what fun am I missing with mine?

    1
    Linux will continue to be a frustrating geeks-only club unless and until somebody starts getting paid to work on it
  • That's a lot of words for "I'm too lazy to master the most essential tool of my professional life and keep it updated to my requirements".

    If you don't want to do it, feel free to pay an Ubuntu support subscription, open a ticket, and get back to work. As you said: you should be working on your problem instead of whining. Or maybe you earn more whining?

    There's a saying that goes like that: "To a bad workman, there's always bad tools."

  • Why do I always need to rationalize use of proper architecture?
  • Others has answered the specific cases where TTM is paramount.

    When time is less of an issue, in my experience it's in no particular order a mix of:

    • product owners or similar role wanting "everything and right now" for no reason whatsoever, except maybe some bonus;
    • bosses bossing around to try and justify their existence instead of easying progress ;
    • developers being not much more than code jockeys with a tendancy to develop by StackOverflow copy/paste;
    • operations lacking time, resources or knowledge to build a proper CI/CD pipeline - when it's not an issue of operations by ServerFault copy/paste;
    • experts (DBA, virtualization, middlewares) being kept out of the project, and only asked for advice when things go terribly wrong later.

    All in all, instead of short term profit, it's a lack of not-so-long term vision and engagement from everyone involved. They just don't care.

    Yeah, I'm the one in charge of fixing the mess, why you ask?

  • Specifying complex forms
  • Your question is a bit vague but it looks to me that what you want is some sort of expert system of inference engine.

    There might be some open source solutions, and there's always the GNU Prolog language that might suit your needs.

    I suspect that you won't get a graphviz structure out of it though.

  • I don't find any value in Red-Hat but I see their corporate thinking. Who really need them and why?
  • You can add support contract requirements for some pieces of software coming from vendors with so little confidence in their product that they're rather have it run on an outdated dependencies environnement. A side effect of the logic you talked about, applied to software vendors.

  • France’s browser-based website blocking proposal will set a disastrous precedent for the open internet
  • Yet again an example of (for some, not-so) old, control-freak farts that just don't understand the world they live in. The law proposal is entitled "Regulation of digital space". As if a country could regulate an international network.

    Sometimes I'm really ashamed of our politicians.

  • InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)ST
    steph @lemmy.clueware.org
    Posts 1
    Comments 17