moonpiedumplings

Step 1 is communication.

Talk to your english teacher. Explain to them, why Google Docs, the way they track history and changes, is not a preferred option for you, due to ethical or privacy considerations.

Explain to them your selected technical alternatives for tracking changes. A few alternatives are (many commenters already covered):

• LibreOffice Word + it's build in version history
• Etherpad, onlyoffice, or an open source hosted solution with version history
• Git: Yes, it is the most technical option. But don't assume that your teacher doesn't know it, or is unwilling to learn it, so it has to be included on the list for a complete set of options.

Secondly, you need to remember that what your english teacher wants is not "document history", but instead seeing your process (maybe to prove you didn't chatgpt it, in which case, writing it on paper also might prove that). If none of those technical alternatives are viable solutions for them, another alternative is to simply submit documents that encapsulate each stage of the process. For example, a common pattern that my teachers and professors would do for writing assignments is:

• Annotated Bibliography: Collection of sources, but also annotations, or comments on each one. Why you included them, how they can be used in your essay, and so on.
• Outline: This can be bullet point like overviews of each paragraph and the topics they will discuss, how, and what sources will be used
• Rough draft (and various stages of it, as it gets reviewed by you, or others like classmates)
• Final Draft: self explanatory

The above setup is nice, because it is not tied to any particular software, and can even be executed on paper. This would mean that future students, similar to you, going through the same class, could write essays with their preferred writing software, instead of only with google docs or whatever solution you get the teacher to learn how to work with (assuming they are nontechnical and teaching the teacher is difficult.

I only started seeing it done like this in college classes. High school classes only sometimes required an outline, and never required an annotated bibliography. It also is more work then just writing an essay from sources.

But the two big benefits of this setup are:

• Even though it is more work initially, it is less work overall, while leading to a better organized and higher quality essay.
• By assigning due dates to each step of the process, the teacher can eliminate lots of procrastination and doing the entire essay at the last minute.

Good Luck!

If an attacker wanted to hand me bad code, couldn’t they also hand me a bad signature/certificate/key?

This is what multi-party key signing is for. Now, multiple people verify code, and also verify build artifacts. Rather than trusting an individual, you trust a process during which developer's continuously verify each other.

The other thing to note is that the builder is not always the distributor. For example many Linux distro's have mirrors setup, where they share their built artifacts to other institutions and hosters, who then redistribute code.

Even for a single party, key signing has value because it ensures that everything after the original creation of the artifacts is not compromised, as long as the key distribution system is different than the distribution system of the artifacts.

But for a solo dev on Github, yes. Signing doesn't really do anything, since the developer and the distribution chain are close enough that it's highly likely the key would be compromised along with the source.

I think the most straigthforward solution for you would be to boot the live ISO installer in a virtual machine, and then connect the USB device to it and then install. This is mostly guaranteed to work, since it is already using the actual ISO.

Alternatively, the program that most Linux distro's use to install nowadays is called calamares. And yes, you can install it on a non-live system.

sudo apt install calamares calamares-settings-debian

This might be easier, but it also might be harder, if say, the installer is not preconfigured with the various settings the live ISO comes with.

The current thing I was working on was figuring out if I can do this: https://github.com/NilsIrl/dockerc . This project, compiles a docker image, and runtime to a single container. The interesting thing I find about it, is that it brings the docker container runtime and sandbox along. If I replace a user's login shell with it, the user is now placed inside a sandboxed environment and can't do anything.

My usecase is I want to replace people's login shells with a container in a defensive cybersecurity competition. But, containers are not a sandbox, and full network access, and so on.

So my improvement, was to:

• Use the gvisor/runsc runtime instead of a normal container. Gvisor is a reimplementation of the Linux kernel in Go, and it is as secure as a virtual machine, way more secure than a normal container, BUT I can't guarantee nested virtaulization is enabled
• Rip out dependencies on user namespaces or fuse for sandboxing or the container runtime, and entirely rely on Gvisor for isolation, just in case machines are old/misconfigured and those components don't work
• Use Nix to build images and all in one executables instead: Nix has ways to package static programs that avoid pitfalls of above

I am having trouble meeting all of these requirements, so I suspect one or a few will go, or I will have multiple versions of the project with tradeoffs.

All of my projects, often involve doing something standard, but with extra constraints, or some kind of "twist". Like a very common thing I find myself doing, is to do something normal, but then rip out one of the underlying components of the system, replacing it with something else.

I've found that I've learned a lot about how these systems work, without having to spend time building them entirely from scratch. You learn way more about Linux by reconfiguring your init system to enable encryption, than copy pasting from the Arch Linux Installation Guide the whole time, doing the standard setup. And then ignoring the partition layout so that my kernels are restored by BTRFS snapshots, which is not the default configuration.

That's the way to break out of tutorial hell. You have to not follow the tutorial. You can still follow them most of the way, but you have to pick a few steps, and do something different. I pick something that I think will benefit or make my setup better in some way.

It is kind of difficult, since I feel like Linux has gotten more popular, and people know write more blog posts, and something that was previously a cool twist, is now something I can find a tutorial for. But with some care, you can ensure you still are learning, and it's made easier by picking projects with twists.

Skill issue. I have to constantly convince the models that what I want to do is in fact possible, and that the "alternate paths" they give are things I already considered but discarded because of various reasons.

It's gotten to the point where I would ask them to search for blogs directly, but they still try to give me hallucinated slop that isn't actually what I want instead of following my instructions of being a search engine that filters out all the SEO slopspam that's so prevalent nowadays.

I currently am doing:

https://blogsearch.io/

https://marginalia-search.com/

To find blogs directly.

Although I do almost exclusively Linux/Kubernetes stuff, and very little programming atm, that might be why I have a different experience.

Back when chatgpt wasn't as broad (and people hadn't posted blogs on as many things) I used to assign students things that chatgpt would find impossible do solve, and I got great glee from watching them spend a day trying to get chatgpt to do it entirely for them, before they gave up and had to actually learn. They can learn from chatgpt ofc, idrc, but it wouldn't be able to do ut for them.

Nowadays, things like "set up nextcloud with caddy instead of apache" have 10 thousand (real, non hallucinated) blogposts about them, which have been fed into chatgpt so it can do that without much difficulty.

It is getting harder to find things that beginners can do that chatgpt can't, but as soon as you move beyond the level of advanced beginner (also called being stuck in tutorial hell) in linux, you quickly find the LLM can't do everything for you.

Account with no comments = suspicious af

Tailscale works great, but their free tier is limited to a total of 8 users, which is enough for a tiny minecraft server, but doesn't seem to be enough for your usecase.

For 10-15+ users, you probably want to self host a VPN on your own VPS. Like, you can self host headscale, which is tailscale but self hosted. : https://github.com/juanfont/headscale [1]

I wouldn't port forward game servers, because they often lack authentication (login and stuff), and then they also have security issues due to not receiving updates. If your game server isn't truly public, then it's easier to just have people use the tailscale client to connect to your VPN.

[1] Although I would recommend headscale to OP for it's simplicity, it is very barebones, and software like netbird or netmaker is more close to a truly self hosted tailscale, with things like more advanced accounts, OIDC integration, authorization, and so on. But they are more annoying to host and set up.

OP is definitely a bot,

But both choco and winget use the upstream windows installers to download the program already, they just wrap/script it.

They might pull related programs, but they don't really manage dependencies the same way Linux package managers do.

No, firefox doesn't implement the webusb standard which they probably want.

https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API

The problem here is not browser support, but them not shipping a native application or library (which I would want to be open source).

Do nix and then use nix2appimage, or nix bundle to package the app compressed as an arx archive without the startup times they complain about.

You can also use https://github.com/DavHau/nix-portable to bundle it a bit better, without needing nix on the host.

And then, based off a quick search:

https://github.com/neobrain/nix2flatpak

https://github.com/barstoolbluz/nix2deb

I couldn't find nix2rpm or nix2pacman, but there exist tools to convert between formats (alien, debtap, rpmtap, and one more who's name I can't remember but I remeber as being the most versatile).

What I'm trying to say, is that when people said "just use nix", they probably really mean to use nix as a platform to build other packages withouth doing extra work.

On the other hand,

You can also use one of the newfangled appimage like formats: https://docs.pkgforge.dev/formats/packages

This one is linked in there and creates a static executable from any binary: https://github.com/VHSgunzo/sharun

Now they would still have to build for macos and windows, but they are already doing that anyways.

As a sidenote, there is also this: https://github.com/pacur/pacur , which is an aur like repo that buids debs, rpm's, and pacman packages. So there's semi-automatic updates, via a publuc repo you can out stuff on.

The real elite solution, imo, is to host forgejo, or use codeberg, which insanely has a package registry for every possible format of packages. So you can directly just push there, after building however you want.

But if developer's were good at packaging, I wouldn't be so mad when they try to do it.

Because this:

The next version will include a new built-in self-updating mechanism

Downloading unsigned, unverified binaries directly from the latest versioned github release?

Makes it so that all that's needed for getting malware on the system is pwning the developers account via some supply chain malware, that hooks into there browser and pushes a release.

And every additional developer who can release, or every github actions that is potentially vulnerable but can be made to release, or claude (since the author is letting it commit, which requires it to run without sandboxing afaik) becomes more attack surface.

There are ways to fix this. Conventional distros use multi party signing of commits and releases, where developers continously verify eachother and look over changes.

More newfangled flows involve using github actions to build immutable releases, directly from tagged versions of the code.

But random developer #3989 isn't doing this. They are distributing their software in a way that malware distributors will be ery happy to see after pwning their account.

I want devs to use nix, because then I can build or run their program directly from the source code. It sidesteps so many issues with visibility of the supply chain, or being unable to inspect what I am running.

I like nix becuase I can make developers like the above satisfied by giving them a way to easily build static binaries, or other formats.

Nix is also packaged in debian as nix-bin.

A common distribution method involves multi-party signing, that is, multiple developers use keys to sign off on reviewed changes.

Multiple developers review the changes, before signing the git commit after review. Then they build the package, either locally or on CI servers, but again, multiple parties/servers sign and review, doing a reproducible build to verify across machines.

In an ideal architecture, there is never a single point of failure. You would have to compromise the computers of multiple devs, or multiple build servers that are building signed reproducible builds, in order to do it.

Although in theory, you could compromise all of them. But it's extremely difficult.