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 )
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.
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.
Subjective take: there’s worse than FreeCAD - sure it’s a bit “old school” but it’s bearable. O. The other hand, the solver has crashed on me so many times… The workbench way of doing things requires some time to get usdmed to, sure, but a crashing solver is far worse.
This one is interesting. What java bias is linked to user experience in Jetbrains products exactly?
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.”
EOL of version 7 is next year in June, you got a nice pile of work here!
And *nix shells a perfect example of the KISS principle.
On behalf of garbage, I loudly protest on this attempt to assimilate it to Powershell.
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.
We went from a computational tool serving a wide range of tasks to an entertainment widget barely more interactive than a TV were work is an afterthought.
The former was expected to not get in the way of their users, the latter is designed to retain attention as long as possible to maximize consumption
Given the state of this world, there’s better things to do than to add such gimmicks in EV. There’s enough energy and matter wasted in useless widgets to at least spare the new generation of such stupidity. I could get behind a new kind of recycled ICE vehicles, operating on captured-carbon fuel and paid at a premium for those who need to love the rumble of a well-tuned engine, but that should stay a fringe hobby.
Time’s for a compromise on the length of the fuse is over, we, as a whole, should be focussing on preventing the climate bomb to do too much damages to humans.
Or maybe we should double down, extract and burn even more fuel, produce and discard even more plastic, without forgetting to have it circle five times the Earth before before it hands in the customers’ hands: it wouldn’t be the first mass extinction and the planet will get through. Us humans, though…
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.