rutrum

joined 1 year ago
[–] rutrum@lm.paradisus.day 1 points 4 days ago (4 children)

I've been using micromamba/mamba and not had solving issues like I did with conda. Im glad conda integrated libmamba.

Question: why were docker containers deemed security risks?

[–] rutrum@lm.paradisus.day 9 points 1 week ago

I recently built a site with hugo. Its very easy. You pick a theme, then write some markdown files. And when you need flexibility, you have it for later. I also think it's the most popular right now, which lends to a lot of themes to pick from and a lot of cpmmunity support.

[–] rutrum@lm.paradisus.day 1 points 1 week ago* (last edited 1 week ago) (1 children)

There are a few out there, but this is the one I use by GermanBread: https://github.com/GermanBread/declarative-flatpak

Edit: this is probably worth making its own post about

[–] rutrum@lm.paradisus.day 3 points 1 week ago (3 children)

I use a declarative flatpak flake that lets me install flatpaks declaratively. You could use this as well, in case you want to manage the flatpaks in your configuration.

[–] rutrum@lm.paradisus.day 1 points 1 week ago (1 children)

Which app menu? I use gnome and after a restart I see my flatpak apps in my app drawer.

[–] rutrum@lm.paradisus.day 2 points 1 week ago

According the docs, support for intel and amd graphics is supported out of the box. For nvidia, you can pass --nvidia to the distrobox create command and enable functionality. So yes it does!

[–] rutrum@lm.paradisus.day 3 points 1 week ago

Thats a great idea. Theres lots of Foss cad tools, and Im sure they have plenty of flexibility even when contrained to 2d.

[–] rutrum@lm.paradisus.day 3 points 2 weeks ago

Really love the side panel. I dont see those done vertically very often, and yours looks good.

[–] rutrum@lm.paradisus.day 3 points 2 weeks ago (7 children)

Can you share pics with this door? How do you walk outside and have it lock behind you?

[–] rutrum@lm.paradisus.day 4 points 2 weeks ago (2 children)

Use a raid atrray, and replace drives as they fail. Ideally they wouldnt fail behind your back, like an optical disk would.

[–] rutrum@lm.paradisus.day 3 points 3 weeks ago (1 children)

I've used minio briefly, and I've never used any other self hosted object storage. In the context of spinning it up with docker, it's pretty easy. The difficult part in my project was that I wanted some buckets predefined. The docker image doesn't provide this functionality directly, so I had to spin up an adjacent container with the minio cli that would create the buckets automatically every time I spun up minio.

But for your use case you would manage bucket creation manually, from the UI. It seems straight forward enough, and I don't have complaints. I think it would work for your use case, but I can't say its any worse or better than alternatives.

[–] rutrum@lm.paradisus.day 22 points 3 weeks ago

The problem isnt gmail, the problem is using an email for this purpose. Switching to protonmail wont make a difference. If you want privacy, use a different communications protocol. For example, use signal, and if anyone wants baby updates, they better install it too, cause thats the only way you'll send them.

 

I just setup my first automated and encrypted backup with borg. It's got me thinking about other chaotic events, and how to respond accordingly. I figured now is a good time to document my infrastructure: hardware, network, a files. This way if something bad happens, like my house burns down, I or a family member has instructions for how to quickly recover data and services. Examples:

  1. If my website goes down, with my nextcloud on it, what steps do I need to take to recover the data and restore service?
  2. If my harddrive fails, how do I access lost data and reimplement redundancy after a replacement is stood up?
  3. If someone important to me needs to access encrypted files, how can that access that data and get access to the passwords/encryption keys?
  4. If my phone bricks, how to recover 2fa codes?

So I'd like to have a physical printing copy that tries to cover these emergency scenarios. Of course, I'll have digital copy around as well.

I'm focusing more on digital assets, like encryption keys, personal files and media, cloud service access, accessing inaccessible machines, how to restart/recover from self hosted service if its down, etc. I understand how much wider this document can be to include physical assets, so to start I want to start with digital infrastructure.

So my big questions: what scenarios should be documented in this disaster recovery document? What should I prepare for? The nice correlary of this is that documenting a recovery plan will force me to actually stand up the backups/redundancy needed to recover.

 

I just got a drawing tablet, and have been wanting some software that would allow me to work out math problems, draw architecture diagrams, etc. I've seen some tools like Excalidraw, which look handy for the sharing capabilities. I also have just used plain krita, which has great feedback for the pen sensitivity, but obviously is overkill for whiteboarding.

Are there any tools you use or recommend for handwriting or picture drawing? Pen or mouse?

 

I love coffee, but have a surplus of tea bags that I want to experiment with. Does anyone have suggestions for how to get started with tea? Or a simple recipe to use as a baseline? I'm only working with tea bags at this time, which appear to be 2g. I would also love to know how much agitation you are supposed to do with the tea bag itself.

 

I'm in desparate need of setting up borgmatic for borg backup. I would like to encrypt my backups. (I suppose, an unencrypted backup is better than none in my case, so I should get it done today regardless.)

How do I save those keys? Is there a directory structure I follow? Do you backup the keys as well? Are there keys that I need to write down by hand? Should I use a cloud service like bitwarden secrets manager? Could I host something?

Im ignorant on this matter. The most I've done is add ssh keys to git forges and use ssh-copyid. But I've always been able to access what I need to without keeping those (I login to the web interface.) Can you share with me best practices or what you do to manage non-password secrets?

 

If given the option, which route do you go? I have services running in both, and I'll often just do whats easier. I dont really notice a different in performance the configuration for containers is simple enough I don't mind it.

I also wish there was a nix function that parsed a docker compose and used it for the oci-container config. Then I could use my existing compose files or the ones I find in docs online.

 

This idea is inspired by nixos-mailserver. It was so easy to spin up the mailserver after changing some DNS records and putting in some settings. I thought it might be a good idea to do the same for services that need public, decentralized infrastructure to support. Some ideas include

  • Tor relay, or exit node
  • Encrypted messaging nodes. It looks like SimpleX chat relies on SMP servers to relay communication
  • Crypto miners (I know, I know, but you understand how it fits the “public contribution” usecase)
  • Search engines like searxng (I currently use a public instance)
  • Libredirect services, like proxy clients for social media

Maybe federated services, but those require more than just the software running on the public internet. Those require moderation and long term maintenance. Ideally, the services in this config would be ephemeral.

Does this sound like a good idea? Would you spin one of these up on a $10 VPS? I understand that this is the NixOS community, not necessarily the privacy community, but I figured thered be overlap.

What other services do you think would be applicable?

 

This idea is inspired by nixos-mailserver. It was so easy to spin up the mailserver after changing some DNS records and putting in some settings. I thought it might be a good idea to do the same for services that need public, decentralized infrastructure to support. Some ideas include

  • Tor relay, or exit node
  • Encrypted messaging nodes. It looks like SimpleX chat relies on SMP servers to relay communication
  • Crypto miners (I know, I know, but you understand how it fits the "public contribution" usecase)
  • Search engines like searxng (I currently use a public instance)
  • Libredirect services, like proxy clients for social media

Maybe federated services, but those require more than just the software running on the public internet. Those require moderation and long term maintenance. Ideally, the services in this config would be ephemeral.

Does this sound like a good idea? Would you spin one of these up on a $10 VPS? I understand that this is the NixOS community, not necessarily the privacy community, but I figured thered be overlap.

What other services do you think would be applicable?

 

I've been enjoying the daily commentated reciews by BrightWorksGaming

 

You know, ZFS, ButterFS (btrfs...its actually "better" right?), and I'm sure more.

I think I have ext4 on my home computer I installed ubuntu on 5 years ago. How does the choice of file system play a role? Is that old hat now? Surely something like ext4 has its place.

I see a lot of talk around filesystems but Ive never found a great resource that distiguishes them at a level that assumes I dont know much. Can anyone give some insight on how file systems work and why these new filesystems, that appear to be highlights and selling points in most distros, are better than older ones?

Edit: and since we are talking about filesystems, it might be nice to describe or mention how concepts like RAID or LUKS are related.

 

I made a post a while ago asking what you do when NixOS isn't cutting it. You need a package that isn't available as a flatpak/appimage or already in nixpkgs. You don't want to build from source, because it's either too difficult or too time consuming. One suggestion was containerization or virtual machines, but those seemed too cumbersome. Well, distrobox is the tool that fixes it.

Distrobox is a shell script that wraps over docker/podman to run a container of a distribution of your choice. But it does it behind a very high level API, and integrates the container environment seemlessly with your host environment. It is seriously as easy as this, if you need to install something with apt inside debian.

$ distrobox create -n my_debian --image debian:latest
$ distrobox enter my_debian

And bang, your in a debian container and it won't even feel like it. It automatically integrates your shell environment and maps your root directory inside the container (or something like that.) You seriously wouldn't know unless you neofetch. Best part is that since everything is in the nix store, every program in your environment should work, for the most part, inside this container. I've not noticed problems yet.

Tada! apt is available in this environment and you can install what you need. Then you can run it while inside the container. From the host machine, outside the container, you can run it directly too. Say you installed program X in debian:

$ distrobox enter my_debian -- X

And it will just run the command and send you back to the host machine.

In the case of docker, you can type docker ps and it will show you your debian image my_debian listed.

There's two more things I want to do to really polish this workflow. The first is to change my shell prompt so I know that I'm actually in debian without typing neofetch! Inside the box the variable CONTAINER_ID is set and the hostname is modified. I've adjusted my starship prompt to look like this when inside the box:

distrobox:my_debian ~ $

And lastly, I really want to blur the lines. If I install X in debian, I want to just call it directly from the host as X, not invoke my debian instance with distrobox enter.

When you type X and the program is missing, bash (and fish and zsh I'm sure) runs a hook that you can look at by typing

$ declare -p -f command_not_found_handle

By overriding this, you could first have it try the inside container if it can't find the application in the host container, like so.

command_not_found_handle () {
  distrobox enter my_debian -- $@
}

This is not a perfect solution, but I'm still experimenting with how to integrate this both seamlessly and also not accidentally run things inside debian and not realize it. If you have suggestions for how to improve handling calling commands from the outside environment, please share. Best case might just be adding aliases for programs explicitly. For example, `alias X=distrobox enter my_debian -- X.

Anyway, distrobox is the solution! This is one more barrier removed that was preventing me from moving my main computer over to NixOS. I'm so happy to have found this and wanted to share.

view more: next ›