That’s all fair enough. I’ve seen it listed as a gotcha on some very pro-gun sites for the specific case of a thief who’s taken something, jewelery for example, and is now running away. You can’t take the offensive to get it back. (At least not with your gun. I expect trackling them to the ground would be fine?)
I’ll be damned as well.
Worth noting for any Californians that it u-turns if the person stops being a threat. If you threaten and they run away, you’re now in the wrong if you shoot.
I agree. Forgejo itself is stable and I love it. Gitea never gave me trouble and that carried over.
Actions is just a bit hard to setup, at least for me, when I tried. We’ll get there one day. (I believe the big thing is really just documentation.)
First of all, I actually do prefer Forgejo Actions over Woodpecker. Once set up, my only problem with it (so far) is almost certainly caused by my infrastructure and isn’t inherent to FA itself. Pecker, on the other hand, is quite a bit easier to set up and better documented, but I had that issue where it would disconnect from Forgejo and need a few buttons pressed to fix.
This one is just FA being weird:
If you want to deploy the Runner using Docker, the documentation is poor at best. From both a security and documentation standpoint, having it in its own VM is better, but you can do Docker. You just have to read and figure out more on your own. Reading through the example deployments from the documentation will eventually lead you to something along the lines of this (which I copy-pasted from my deployment rather than search for again):
forgejo-runner:
image: code.forgejo.org/forgejo/runner:6.3.1
restart: always
user: 1000:1000
environment:
- DOCKER_HOST=tcp://dind:2376
volumes:
- runner_cache:/data
depends_on:
- dind
command: >-
bash -ec '
forgejo-runner create-runner-file --name runner --instance https://${DOMAIN} --secret ${RUNNER_SECRET};
sed -i -e "s|\"labels\": null|\"labels\": [\"docker:docker://docker.io/node:22-bookworm\", \"ubuntu-latest:docker://ghcr.io/catthehacker/ubuntu:act-latest\"]|" .runner ;
forgejo-runner generate-config > config.yml;
sed -i -e "s|^ network: \"\"$| network: host|" config.yml ;
sed -i -e "s|^ envs:$$| envs:\n DOCKER_HOST: tcp://dind:2376\n CONTAINER_HOST: tcp://dind:2376|" config.yml ;
forgejo-runner --config config.yml daemon
'
You don’t actually need to do this since you could edit the two config files yourself and bind them to the container. This is just how you automatically generate those files… And it’s dumb, but it works and it means you don’t have to keep track of those files.
This one is probably just my infrastructure: https://lemmy.world/comment/16093731
If you do go for FA in Docker (or Podman) and need some help, just ask. I’ll post more of my compose and explain my decisions.
I run Forgejo and had issues with woodpecker’s hooks breaking causing workflows to not start. Moved to Forgejo Actions which had it’s own different set of quirks (really just depends on your exact deployment method), but I’m happy with it.
While I do not make heavy use of these two, I like having my contacts and calendar synced and accessible on both my PCs and phone.
I actually use the notes app, and have a yubikey. For notes, I could just use the regular markdown editor, but I like way the app lays everything out. For the yubikey, NC by default uses yubikeys for passwordless login. I use an app which uses them for 2FA instead. I also use apps which allow me to view hashes and metadata from the files tab.
All that makes me not want to switch yet. We’ll get there eventually since none of the features I want are ultra complex or super uncommon.
OCIS, last I tested it (a while ago), also lacked the ability to right click files, requiring you to select it with the checkbox and then select the operation at the top of the screen. I sure hope that they’ve added that feature by now.
I actually did not know this. Thank you! That was one of my more major gripes.
Nextcloud is more featureful (more apps like notes and hardware 2fa support). That is currently holding me to NC.
OpenCloud (fork of OCIS not original OC) is very similar when it comes to core functionality, but is missing those few apps I do not want to let go of.
Also note that nextcloud stores files in a very natural manner, where your file names and directories are stored the exact same on disk as on the interface. Opencloud does not do that. This is particularly handy if one day the app just explodes and refuses to run. With NC, you can just copy the files off the disk. Not so easy with OC.
As a heads up, almost all OpenWRT routers function as managed switches with vlan capabilities. Not truly all, but a very good number.
I agree that it is quite possibly related to the version of Podman moreso than an inherent issue. I am currently satisfied, however, and have no desire to fiddle with it any more… Or at least until Debian 13 gets released.
My use of PinP is almost entirely for cleanliness. It allows me to more easily wipe the build environment (clear out space, troubleshooting). It also mildly improves security as the ‘untrusted’ actions containers run on a separate environment from the important Forgejo container.
The workaround I use for the premade Docker actions not functioning is to simply install Podman as one of the build steps and use that instead, lol. (Some configuration required, but that’s the gist.)
Forgejo Actions is definitely not a turnkey idential-to-GitHub solution, but it’s quite similar and for most not-super-complicated setups it’s basically the same (for better or worse, depending on if you like GH’s Actions).
As far as I remember, everything that I need works out of the box, except for Docker. In fact, just about everything Docker is somewhat quirky in Forgejo Actions.
One mildly annoying quirk of Forgejo is that as of current, the token generated for each Actions run is not quite the same as GitHub’s token. For my specific use case, if you want to upload a Docker Image to the package repository, you can not use the standard auto-generated token, which GitHub does allow you to use. Forgejo instead currently requires you generate your own app token and use that instead, as the auto-generated one lacks permissions over packages. (https://codeberg.org/forgejo/forgejo/issues/3571)
Depending on your infrastructure, it might just be impossible to make the various Docker-related actions (such as https://code.forgejo.org/docker/build-push-action) work. As an example, my infrastructure outlined below is one such case where those actions simply do not work.
Bare Metal (Debian 12) /
├─ Rootless Podman/
├─ Forgejo
├─ Forgejo Runner
├─ Podman-in-Podman (Inner Podman also Rootless)/
├─ <Actions Containers Run Here>
* If you use rootful Docker with Docker-in-Docker, those actions will then work as expected. It is just that attempting to make them work with Rootless Podman (at least the version that ships with Debain 12) currently seems to be impossible.
For all intents and purposes, “gateway” just means “router,” especially in consumer/home networking. Routers act as a gateway, routing traffic from one network to another network. On one end of the router is your WAN (ISP / internet at large / etc.), and on the other end if your LAN.
Switches on the other hand are “dumb” and only act to expand a network. They basically act like a power strip does: What was one port is now more. (This example will probably upset someone for reasons, but they’ll also understand that it works well enough.)
Thought exercise: What happens if you plug the WAN cable from your ISP into a dumb switch (like https://www.amazon.com/dp/B00A128S24), and from there you plug in several devices (PC, printer, etc)? I am not answering that question because just about anything can actually happen. It depends on how your ISP is configured and will almost certainly not work 100% correctly.
Now onto the actual response: For the most part, every consumer router is a router/switch/wifi AP combo box, and are capable of being used for all or any combination of those features.
If you’re not planning to use your device as a router, then we’ll ignore the routing functionality. All prior points where I say “this happens at the router, not the switch” still apply. (Your device can still be called a router, as that’s what it’s sold as, but you’d be using it with the all routing functionality disabled, only using the switch and possible WiFi features)
If you do plan to use your device as a router, then the prior points where I say that now apply.
Anyway, you’re in luck since the switch built into your device is almost certainly VLAN-capable (it’s quite rare, but some devices are not capable of it). If you’re not using the device as a router, that’s where things probably end, since (at the switch level) VLAN support is pretty much the only thing of note.
I spent so long writing this I actually forgot what I was trying to say initially. I’ll likely draw a diagram to explain some things for you.
The important thing is that “switches” (or your device if you’re not using the routing functionality) are “dumb devices” that only do very simple tasks and generally aren’t capable of much in terms of advanced security features. “Routers” are smarter devices where the task they do is a bit more complex, and are where the advanced security features can actually be applied.
Building on the advice others gave:
Going off your response to foggy:
achieve better security through segmentation by isolating cloud-connected devices, guest devices from trusted devices.
You’re describing VLANs. VLANs are something that the OWRT documentation (last I used it) was simply very shit at. I’ll make the assumption you understand or are capable of learning about how VLANs work. (TLDR is that devices on different VLANs can not talk to one another without going through a router or a layer-3 switch, which I don’t think OWRT handles anyway. Once you know what tagged/untagged means, then you’re good to proceed.)
The way you access VLANs in modern OWRT is: Network > Interfaces > Devices (tab). From here, you may see different things depending on your hardware. In my case (I use consumer routers), I have several “network devices” which map to a physical port, and a single bridge device. From there, I can click on “configure” for the bridge device and select the “Bridge VLAN Filtering” tab to configure the vlans on the various ports.
Note that VLANs if incorrectly configured can easily make it impossible for you to access your device, requiring you reset it.
Being able to “pin” a Mac address to an IP, and being able to use internal network name resolution to reach those devices.
To my knowledge, OWRT lacks the ability to pin MACs to specific ports, at least in the web UI. It may be possible to do this manually in the configuration files, but I have never attempted to do so myself.
a blocklist for known ad-domains / malicious domains.
You generally do this on your (core) router, not the switch. (Unless your switch is doing some really funky behavior, in which case you’re not here asking questions.) Most devices OWRT runs on, however, have very little flash and not much RAM. While you can probably get Pi-Hole or Adguard Home to run on them, I do it differently.
I run Adguard Home on a device separate from my router, and on the router, I have set the AGH device as the first DNS sever (OWRT: Network > DHCP and DNS > Forwards (tab)), then I enable Strict Order (“Resolv & Hosts Files” tab).****___
a high level monitoring capability to seen what devices are communicating with what domains / IPs
I would do this on the router level, not switch level. That said you can actually just follow this tutorial here https://grafana.com/blog/2021/02/09/how-i-monitor-my-openwrt-router-with-grafana-cloud-and-prometheus/
An IDS capability of some sort to be able to detect anomalies in my LAN.
This is not something I’ve ever attempted or done, so I’m interested in hearing what you come up with when/if you ever get there.
I was joking with some friends about doing exactly this. Schuck it down to just the battery and minimal drivetrain, and make a very heavy go-kart.
Seagate’s error rate values (IDs 1, 7, and 195) are busted. Not in that they’re wrong or anything, but that they’re misleading to people who don’t know exactly how to read them.
ALL of those are actually reporting zero errors. This calculator can confirm it for you: https://s.i.wtf/
Edit: As for the first image, I don’t see any attributes in #2 which match with it. It’s possible there is an issue with the drive, but it could also be something to do with the cable. I can’t tell with any confidence.
Edit Edit: I compared the values to my own Seagates and skimmed a manual. While I can’t say for sure what the error reported is in relation to, it is absolutely not to be ignored. If your return period ends very soon, stop here and just return it. If you have plenty of time, you may optionally investigate further to build a stronger case that the drive is a dud. My method is to run a test for bad blocks using this alternative method (https://wiki.archlinux.org/title/Badblocks#Alternatives), but the smart self-test listed would probably also spit errors if there are issues. If either fail, you have absolute proof the drive is a dud to send alongside the refund.
No testing/proof should be required to receive your refund, but if you can prove it’s a dud, you may just stop it from getting repacked and resold.
I don’t know you but I fucking love you.
Reference: https://developer.valvesoftware.com/wiki/Lightmap
Skipping over some details and simplifying this to (hopefully) make it something anyone can reasonably understand: For Source in particular (as other engines may do things differently), maps start out as being fully bright without shadows. Here is an image I stole off a google search showing what that looks like:
When the map is being compiled (or exported or whatever term resonates with you the best), the lights placed within the map (and probably sky information too) are used to determine what parts should be covered in shadow and what should be brightly lit. The result is called the lightmap. (The lightmap itself doesn’t have any texture of, say concrete. It only stores data along the lines of “this light brightness here is 50%”). By taking the texture of the surface (concrete, asphalt, stucco) and darkening / lightening it according to the lightmap, you then end up with a lit version of the map which does have shadows.
Now on to the bicubic part: To keep the size of map files down, and reduce the resources required to load it, lightmaps by default render at a resolution of one pixel per (approximately) 40 cm or roughly one pixel per 1.5 ft. This low resolution is perfectly fine since the shadow of a building or highway overpass doesn’t need to be especially detailed beyond just “it’s dark over there”. Where required, the map author can increase the resolution in the spots that require additional detail. However, there is still one problem: When rendering a frame for you to view, the low resolution lightmap is “scaled up” to cover the entire surface, and you don’t want pixelated shadows. The fast way of handling this is linear scaling, where to find the value of a “scaled up” pixel, you just take the values of the nearest “original pixels” and simply average them (with more weight given toward nearer “original pixels” than farther). While extremely fast, this leads to stair-stepping as shown in the top-left panel:
Bicubic is just a fancier method of finding the value of that “scaled up” pixel. It’s a slower method than linear, but it resolves the stair-stepping problem.
The earliest thing I remember with certainty it’s correct was my friend across the street, who was older than me, asking me to look up “naked girls” for him.
I have one hen who is a cross of buff orpington, barred rock, and various random breeds. She is a pretty bird but that is a gorgeous one.
Aaand GSMArena says no on headphone jack… Damn it.
https://gsmarena.com/nothing_cmf_phone_2_pro_5g-13821.php