It silently messes with the kernel boot flags which breaks the boot process If you do get it to work it silently adds extra broken repos which make it impossible to install packages.
Why would any distro want to support a tool that intentionally breaks things? Ventoy could just boot ISOs without messing with them and everything would work fine, but the developers insist on injecting garbage.
> If you do get it to work it silently adds extra broken repos which make it impossible to install packages.
This is not true.
I use it extensively and have done for more than 4 years now. It adds nothing at all to the installed OS. It doesn't care about the installed OS: I have successfully installed Linux, FreeBSD, Windows, even FreeDOS from Ventoy.
It comes up regularly in OpenSUSE communities, it silently breaks the installed OS by hooking in to the init process of the ISO and fucking with it for no good reason:
You have misunderstood what these reports are saying.
You claimed "Ventoy adds repos". It does not. It is incapable of doing anything of the kind. It does not run on the installed system. It does not modify the boot media in any way. This is demonstrable and verifiable.
When booted from Ventoy, openSUSE apparently adds the installation media as a repository.
This is not some disaster or horrible hack. This is normal behaviour for Debian, for example.
That means that something in the openSUSE installer is misinterpreting boot parameters.
This is a openSUSE bug, not a Ventoy bug.
SUSE, though, has an institutional habit of blaming problems on others, or denying that problems exist. I know this for a fact from my own personal direct experience: I worked at SUSE from 2017 to 2021.
You are misreading bug reports, wrongly deducing things that did not happen, and mis-attributing blame. The fault here is yours, and secondarily SUSE's. It is not Ventoy's.
> You claimed "Ventoy adds repos". It does not. It is incapable of doing anything of the kind. It does not run on the installed system. It does not modify the boot media in any way. This is demonstrable and verifiable.
It adds a parameter to the kernel boot line. That is not adding a repository. It is not doing what you claim it does.
I am not putting any pressure on you. If you don't want to use it, then don't.
I find it hugely useful, have been using it for about 10 years now on dozens of machines and hundreds of distros and OSes, and it's saved me not just hours but days and weeks of work, effort, and time wasted writing files to USB keys.
All I am asking you to do is not tell lies about it.
Fine, the repository gets added because ventoy hijacks the boot process and messes with it, it does not directly add it. The problem is still the same and it would still be a problem even if it didn't break anything: It should not be hijacking the boot process, there's absolutely no good reason for it.
> As far as I'm concerned, if the player wants to cheat he's just exercising his god given rights as the owner of the machine.
By this same logic: As far as I'm concerned, if the game developer only wants to allow players running anticheat to use their servers then they're just exercising their god given rights as the owner of the server.
This is just yet another example of the remote attestation nonsense where your computer is only "trusted" if it's corporate owned. If you own your machine, you "tampered" with it and as a result you get banned from everything. You get ostracized from digital society.
My position is this is unfair discrimination that should be punished with the same rigor as literal racism. Video games are the least of our worries here. We have vital services like banks doing this. Should be illegal.
> I’m a GUI guy though. As soon as I try delving in, I abort when I see things like “just type c-C dingle bob to do x thing.” I’m happy these people found something that works with their brains. I just want a GUI that works like what they use.
You do have that somewhat with packages like which-key that will show you a menu of options every time you press a key. You then learn the keybinds that you use the most. You can also search for them by name and see the keybind like you do with VS Code etc..
Here's what doom-emacs looks like when I press space and then space-t:
This inevitably happens when the approach to language design is "try it and see". I know people here hate design-by-committee, but historically it's led to some very cohesive languages.
I don't think it is about having committee, but rather having a spec. And I mean spec, not necessarily ISO standard. There should be a description of how specific features work, what is expected behavior, what is unexpected and should be treated as bug, and what is rationale behind specific decision.
Coincidentally people here hate specs as well, and that explains some things.
I know there is some work on Rust spec, but it doesn't seem to progress much.
AIUI, that is what the MIR formalization work is about, and it seems to be moving along fine. My impression is that covers essentially all the interesting parts of Rust worth specifying formally.
Well ok ... experiment but maybe unlike c++ we could have added N keywords removed M keywords for arguably net-simpler language.
Geez I'd hate to be in rust dev shoes if I can't remove something later when I have a better better min/max. I guess this could be done off main, stable.
> Rust's development process is also design by committee, interestingly enough.
Sure, but it's still quite informal and they just add things as they go instead of writing a complete standard and figuring out how everything interacts before anything is added to the language. Design-by-committee was probably not the best term to use.
> the (OnShape) free tier is hobbled beyond the point of usefulness.
The free tier is identical to the standard tier except you can not create private documents and it has a no commercial use clause. This has been the case for many years, so I'm not sure where "hobbled beyond the point of usefulness" is coming from.
There's simply never a reason for a user to replace a fuse in a properly designed device. If a fuse blows then it means something has gone horribly wrong and replacing the fuse won't fix it.
The exception would be a device that sends mains more-or-less directly to a user device, then a fuse would be protecting against a fault in the user device and should be replaceable. A lamp that takes a regular light bulb would be a good example of this.
True, but in that case the fuse only needs to be as easy to replace as whatever else you're replacing. If there's internal socketed components then the fuse only needs to be internal and socketed. If everything is soldered to a board then it's fine to have the fuse soldered too.
Many older appliances did expect the user to put some external bits in that would be across mains, or maybe across a transformer to mains, and in that case the fuse was just as replaceable as the user-provided part.
The fuse in the plug comes from a history of not wanting everything to blow up in the face of "I spilt my tea into the toaster". Very simple device, probably fine once it's dried out.
But really the value of having the fuse in the plug is that if it blows, the live wire in the cable is definitely disconnected all the way to the wall, so whatever has happened you know as best you can that it's not in a state where it could still get worse.
Why would any distro want to support a tool that intentionally breaks things? Ventoy could just boot ISOs without messing with them and everything would work fine, but the developers insist on injecting garbage.
reply