> You do mentoring because the pay off is a junior that develops into a senior; writes better code more efficiently. But what's the pay off with going through this process with AI?
This point is so underrated, when discussing about replacing junior devs with AI.
What a coincidence, today is the annual LAN party with my school friends. We've been doing this once a year between christmas and new year for many years, and I enjoy every second of it.
It gets worse if your machines have bitlocker active, lots of typing required. And it gets even worse if your servers that store the bitlocker keys also have bitlocker active and are also held captive by crowstrike lol
I've already seen a few posts mentioning people running into worst-case issues like that. I wonder how many organizations are going to not be able to recover some or all of their existing systems.
Presumably at some point they'll be back to a state where they can boot to a network image, but that's going to be well down the pyramid of recovery. This is basically a "rebuild the world from scratch" exercise. I imagine even the out of band management services at e.g. Azure are running Windows and thus Crowdstrike.
I recently had a xz moment where the rust zip crate was taken over by a single person and the original crate was completely replaced. I'm still not sure if this was legit or not: https://github.com/zip-rs/zip-old/issues/446
Honestly, from reading this it seems like people blew it _way_ out of proportion. Someone forked the project to make updates because the original maintainer seemed to be not doing much, the original maintainer came back to say that they were correct to ask about maintenance because they didn't expect to do any more work due to health issues and then volunteered to transfer the crate to the person who forked on their own, which the person who forked it accepted.
It's kind of bizarre to me because I don't really understand what mental model could lead to not taking any action earlier than this if the was things turned out is so upsetting. If they were happy to keep using it exactly as is because no updates were needed, why not just pin the dependency to that version exactly (and republish their own fork if they were worried about old versions being "yanked" and not being able to use it for anything new or offline)? If they did expect some form of updates over time, where did they expect them to come from when the existing maintainer felt they were unable to continue given health issues? Any attempt to find some other solution to future ownership would be heavily scrutinized by the exact people who commented on this issue with strong opinions and don't seem to have much empathy for the health issues, which would defeat the entire purpose of trying to take time away from work for their health.
I'm surprised that this needs to be said, expecting people to put in extra work to project you from what happens to their projects when they literally can't keep maintaining them due to health issues will never work, and it's also just an awful way to treat people. If you have serious concerns about how situations like this could be exploited by malicious actors, you should be paying much closer attention to the status of your dependencies and taking actions to insulate yourself from potential fallout long before some like this happens. If you've gotten to this point under the assumption that you can just veto any change in ownership that you don't trust, you're already too late.
This is not a ‘xz moment’, as a sibling comment said, it is norm in open-source.
Someone with more time forked the repo, included the changes that were necessary, build up trust and then this eventually get merged. Now obviously there is no guarantee they will never act up in the future, but this is not different than for the original owner.
Trust is a necessity to open-source reliably functionning, because it in parts makes up for the lack of money, and allow to move fast.
XZ is the exception. And frankly there is not much to do against it.
I currently have the same problem, I would like to root my dreame roboter, but unfortunately I can't get the components for the dreame PCB, or nobody sells me a ready soldered dreame PCB. Too bad there is no alternative, but that makes it really hard for people with a dreame robot to use the project.
I wouldn't say that soldering a pcb [0][1] yourself is beginner-friendly but I understand your argument. Some robots are unfortunately still very difficult to root (which is not valetudos fault), which makes getting started with the project very cumbersome.
I think beginner-friendly is kind of relative. Considering the end goal, you're tying to achieve (hack the robot to run your custom software), requiring a user to solder a relatively simple board is a very accessible requirement.
I might be fine with soldering. But it's a completely different skill than running the software to flash something, I can see how it would put people off.
True, this seems like one of those ideas that sounds so good, until you realize that it already exists, it's used by everyone, just under a different name.
