It’s likely illegal. The administration would call it theft of service because it’s not authorized and they wouldn’t be wrong. I also don’t see why you would want to do it. You’re giving the IT department at your school complete access to your web history.
I can’t for the life of me understand how you’re having a difficulty understanding this to begin with…
You said that at 4% market share they would be idiots to not break their backs chasing that 4% in revenue but were there right now and they’re not breaking their back at all they’re hardly doing anything…
The entirety of your statements that you’ve said so far are verifiably incorrect because they are the reality that we’re living right now. I’m not the one that struggling with reality buddy, that’s you.
It’s not trust me bro at all. That’s the situation we’re currently in. So if these businesses would be “crazy” to leave all this money on the table and they currently are, what does that say to you?
I know critical thinking is hard, but try.
It’s zipping a zip file. Endlessly re-compressing things doesn’t yield positive results in the way you describe.
The market share is already there and there not doing open source drivers, so I guess you’re empirically wrong. I dunno what else to tell ya.
Well they’re not, so I guess they are. 🤷♂️
I don’t disagree, but at the same time, circle back to my original statement. Even if every single *nix user were to only use open source drivers, that’s still not enough. 4% of the market share isn’t going to change anyone’s mind about *nix support.
Blu-rays are compressed.
All streaming data is compressed at some point. I clearly meant not over-compressed. 4K video or UHD BD can both be taken from their original states and processed through HEVC to get crisp 1080p h265 10bit at a steep data discount. But it’ll take a very long time to process. It’s simply not worth it.
“Zipping a zip file” doesn’t apply here because zips are lossless.
It’s a figurative expression and I feel that was pretty damn obvious…
I’m confused… Are you grabbing pirated video files from the net and re-encoding them… If you’re attempting to further compress already compressed video, you’re just zipping a zip file. It’s crazy and you’ll do nothing but bloat the file size (versus a properly compressed video file) and further reduce the quality of the video via artifacts. I’ll call the police and have you committed right now.
If you’re grabbing 8/4k or UHD BD movies and re-encoding them into lets say, 1080p HEVC 10bit, I could see that being worth it if you really love the movie (and have 5 days with nothing to do), but only if you’re going from an inferior compression to better (h264 to h265), otherwise like I said, you’re zipping a zip file.
Because hardware manufacturers don’t care about 4% market share. They just don’t. They can’t survive by pandering to that 4%, and it costs them time and money to make decent hardware drivers for linux.
Sad truth of it.
Binary supply-chain attacks are not “minor security issues”.
Yes they are. The binaries for Ventoy aren’t even updated from release to release. It’s not even evident how old they are. So crying about an attack that only matters if these binaries are bleeding edge is absolutely a minor issue. I don’t even understand how someone of sound mind and body could possibly believe otherwise.
Not having a security first posture on these kinds of attacks is how the xz event happened
No one is making the argument that security doesn’t matter. No one is pushing the idea that Ventoy is secure. I’m saying singularly and only that a supply chain attack is just about the dumbest goddamn angle possible to bitch about Ventoy because I could argue that Ventoy would be more vulnerable than it is now to a supply chain attack if the binary blobs are built and updated every time you build a bootable drive. It’s just a truly fucking insane argument that shows a lack of understanding of what a supply chain attack is. The built binaries may be vulnerable and it’s difficult to prove if they are or not, but if you update the binaries all the time they’re more (attack surface is larger) than if they’re only updated when absolutely necessary…
It’s just plain a poor argument and I’m tired of every armchair expert pretending that its not. People in high security environments aren’t using Ventoy. It’s just such a ridiculous argument.
The advantage of Ventoy is its ability to work in any environment and handle 99% of ISOs. Compiling the binaries at build time requires a mature development environment to be able to build these utilities… Your exponentially increasing the size and complexity of the project to solve a relatively minor security issue.
Ventoy is not the only way to create a bootable drive… If you don’t trust the blobs then don’t run the software.
Forking ventoy to add the complexity of building these utilities is only going to be available for *nix base environments so Windows users are pretty much shit out of luck. Your exponentially increasing the size of the project, it’s complexity, and simultaneously significantly narrowing its usability…
I said it before and I’ll say it again it’s such a bad fucking argument. It’s not mature software. It’s a literal confluence of hacks… And if you’re not comfortable with using it then don’t use it. It really is a huge security risk. But advocating that nobody use it is such stupid fucking thing.
Advocate that people understand the risks of using it but to just run around and scream about how nobody should be using it for any reason whatsoever until the maintainer closes the security hole that makes it run is pretty stupid.
This has always been the key. Amazing to me that not many seem to take it seriously.
There’s no way to emote it, but you know when those old Italian ladies spit at people to keep the evil away from themselves? I just did that in your general direction…
No. But the argument itself is so stupid to me.
Ventoy has never been a secure tool. People are making the argument that it should be, which is just nutty.
If you’re one of those people that grab random fuckin’ ISO’s from all over the internet to test em out, then no. You really shouldn’t use Ventoy. If you run official ISO from recognized sources, then realistically the risk is ever present, but minimal.
Like getting in a wreck on the way to the store to pick up milk. It’s always a possibility, but not many people would stand around and make the argument that you should stay home forever because you might get into an accident, which is basically the argument against Ventoy. It’s “we’ll, it’s a crazy useful tool, but you shouldn’t use it because something might happen.”
It’s just such a bad argument. Fact of the matter is, is that if there were a non-hacky as shit way to do what Ventoy does, it would be available right now. But it’s not… Because it’s really not.
The only way to avoid the issues that Ventoy employs is to not use ISOs and use something like netboot.xyz, which presents its own set of issues. How do you know you’re not being MITM from the iPXE environment? Like, sure. You can technically verify it, but how do you know for sure on the fly?
Like, if you sit down you can pick apart any software for being an insufferable gaping asshole of security vulnerabilities.
Because it has integrations for The Internet Archive: https://x0.at/Wny_.png
It says “local html” but I have a feeling it simply grabs a copy from the internet archive. I can’t even find where its storing these copies with it enabled.
The same way you do any other project. If you’re interested, you go looking. You find my project which has a link to the repo. A link is a link. You’re simply fighting over where the link goes to, and I’m pointing out that it’s a stupid argument to be had.
The biggest issue I have with Caddy and running ancillary services as some services attempt to utilize port 80 and/or 443 (and may not be configurable), which of course isn’t possible because Caddy monopolizes those ports. The best solution to this I’ve found is to migrate Caddy and my services to docker containers and adding them all to the same “caddy” network.
With your caddy instance still monopolizing port 80 and 443, you can use the Docker
exposeorportparameters to allow your containers to utilize port 80 and/or 443 from within the container, but proxify it on the host network. This is what my caddy config looks like;It works very well.