I'm a huge fan of my underprovisioned homelab, squeezing perf out of a tiny old i3 based system is weirdly satisfying. Just one more container, baby! One more transcode stream...
For a long time my home server was a dell wyse 3040 that I got for £25 on flea-bay. 1.4ghz quad core x86-64, 2g ddr3 ram, 8gb emmc, <= 5w max load, fanless, runs standard, normal debian like a treat. :) Eventually I got tired of being constantly vigilant about disk space and replaced it with a more traditional desktop, but I still love that little (compute) engine that could (it's still alive as a glorified ereader desktop for the kids -- just enough muscle to run firefox and epub/pdf readers without being capable of distractions).
Just add one more solar panel and your server is powered. This assumes you can sell excess production at wholesale rates (like we do here in Sweden). If you can not sell power and you're a tinkerer there's ways to build battery storage which can power both the lab as well as the house using a wide variety of batteries. Used EV batteries are one source, used LiFePO4 standby power supply packs another. This is the way we'll go if/when it is no longer possible to sell excess production. Until such a time well enjoy our negative electricity bills, we have not had a positive bill since installing the PV array even though there's a DL380G7 with a DS4246 storage array running 24/7 under the stairs.
Yeah… I stopped doing stable horde after admitting my electric rate was never going down, and it’s already about 55 cents per kWh. I try to put as many electric things to sleep or off now.
The UK can get pretty rude, for example. ~40p/kWh is not unheard of for residential. (Natural gas price shocks, unfettered greed post-privatization, badgers in the transformers, idkwtf, etc.)
No. If that interstitial is working, it's only working due to obscurity, and the moment this system becomes even slightly popular it'll become worthless.
Proof of work is not a viable defense -- it's basically impossible to tune the parameters such that the cost is prohibitive or even meaningful to the scrapers but doesn't become an obstacle to users.
It's pretty much just a check for whether the client can run JavaScript. But that's table stakes to a scraper. Trying to discriminate between a real browser, a real browser running in headless mode, or something trying to fake being a real browser requires far more invasive probing of the browser properties (pretty much indistinguishable from browser fingerprinting) and obfuscating what properties are being collected and checked.
That's already what any commercial bot protection product would be doing. Replicating that kind of product as an on-prem open source project would be challenging.
First, this is an adversarial abuse problem. There is actual value in keeping things hidden, which an open source project can't do. Doing bot detection is already hard enough when you can keep your signals and heuristics secret, doing it in the open would be really hard mode. (And no, "security by obscurity is no security at all" doesn't apply here. If you think it does, it just means you haven't actually worked on adversarial engineering problems.)
Second, it's an endless cat and mouse game. There's no product that's done. There's only a product that's good enough right now, but as the attackers adapt it'll very quickly become worthless. For a product like this to be useful it needs constant work. It's one thing to do that work when you're being paid for it, it's totally another for it to be uncompensated open source work. It'd just chew through volunteers like nobody's business.
Third, you'll very quickly find yourself working only in the gray area of bots that are almost but not quite indistinguishable from humans. When working in that gray area, you need access to fresh data about both bot and real user activities, and you need the ability to run and evaluate a lot of experiments. Not a good fit for on-prem open source.
From what I gather the idea for Anubis isn't to _stop_ bots, it's to make them slow down enough to not bring down servers.
Like they said in the presentation, git(lab/tea) instances have insane amounts of links on every page and the AI crawlers just blindly click everything in nanoseconds, causing massive loads for servers where normally there might be a maybe a few thousand git pulls/pushes a day and a few hundred people clicking on the links at a human pace.
Plus the bots are made to be cheap, fast and uncaring. They'll happily re-fetch 10 year old repositories with zero changes multiple times a week, just to see if they might've changed.
Even a if the bad proof of work requires the bots to slow down their click rate, it's enough. If they somehow manage to bypass it completely, then that's a problem.
Aside: is there a term to define the developers that use these kinds of cutesie graphics? Seems to be a real movement, I'm older, and I seem to have missed the memo. Where did that start and is there some history behind why?
It's both anime/weeb and furry art styles. Usually these are two groups don't really have anything to do with each other but the author is just part of both.
Which doesn't strictly have anything to do with developers either other than the author being part of all three.
The graphics would be called chibis, IMO (or デフォルメ if you wanna be fancy) and IDK about developers, but perhaps weaboos/weebs would be the general term
This is giving a big anime-enthusiast and possibly furry community vibe, it's really pretty separate culturally than just being a developer. For people who really are into it, it becomes a fetish... and no judgement for things that happen between consenting adults but... it can seem pretty odd from the outside. But it can also be entirely innocent, nothing wrong with liking certain art styles.
So if you don't understand these things best not to copy them because you could unintentionally be sending some pretty strong signals.
It's also somewhat in the style of the Manga Guides, which are fantastic and an entirely different way to make some of these things accessible.
I find the way people talk about "homelabs" endlessly confusing. Is it "a playground for devops"? OK - that sounds about as appealing to me as a playground for washing the dishes, or a playground for changing the oil on my car, but people like different things and there's nothing wrong with that.
But wait, you also run your plex instance on there? And a git server? And wait, it stores your tax documents too?
Is it a playground, or a functional home server?
I run plex and a NAS and a VPN server on a machine in my home, too. But it's a home server. It's definitely not a "homelab" or a "playground" of any kind, any more than my freezer is a playground for storing food.
There is certainly no hard division between "playground" and "functional", and I'm barely convinced there's a soft division. Consider car enthusiasts: Some people like playing with cars, and have a fully kitted-out garage to support that interest. Some of them certainly have cars that are only for shows and they'd never actually drive, but more commonly they lavish time and care on their "babies" and then drive them to work. Home labs are the same.
I certainly don't consider my home server that packs a 30 W TDP CPU from 10 years ago to be a homelab. Someone with half a rack that peaks at 2 kW? That's clearly a homelab.
I mean, scale is also a valid range to include, but I was more thinking about utility and stability. Like, I personally think that a single Raspberry Pi in the corner can be a home lab so long as you're learning something from it. But the thing you're learning on it can be "how do I write a toy HTTP server and the only traffic it gets is me testing it", or "this DNS server is in the critical path for every device on my network". High stakes, low stakes, big, small, careful, YOLO; if you experiment and learn things, it's a (home) lab.
To go back to your car analogy, isn't an RPi like a 25 year old econo beater? I always took homelab to refer to a home datacenter; I always assumed (possibly incorrectly) that the origin of the name was due to the analogy of someone who sets up something like a chemistry lab in their garage.
I think of it as the computational equivalent to a home machine shop. If you don't have some heavy duty equipment can you really claim you have your own shop setup?
If someone works on and tweaks and gets to know their 25 year old econo beater, I don't think anyone has the right to say they aren't a car enthusiast. It's less about the horsepower (or ghz) and more about the passion put into it. For example you could add an ad-blocking DNS server on your devices and it would work just fine - but if you put in the effort to self-host it, even on a Pi, it's (IMO) a home lab.
> Is it a playground, or a functional home server?
It’s both for me! I’ve had a homelab in some form since high school (~12 yrs ago).
Having a home lab has gradually taught me Linux, Shells/Terminals, Ansible, Docker, and most recently Kubernetes.
I have to be careful with backing up data when I do something new. I use this setup for Home Assistant, Plex, small self-hosted apps, a personal Jenkins instance for my open source stuff, and game servers for friends.
It has taught me a lot and has had significant (unintentional) benefit to my career by exposing myself to new concepts/tech and thinking about how operations works solo vs in a team setting.
Homelabs are for people who enjoy unrestrained and irrational exercise of technology in whatever way they decide to. It doesn't have to be about reliability or efficiency. It's just poking at things until neat stuff happens or it all breaks.
The surest way to take all the joy out of a hobby is to do it as a job. You sound thoroughly employed.
I think the vibe is kinda like maintaining an old car or something. Some people like doing this kind of work, especially in a space where you get to decide how it all works.
Good way to explore ideas without having to do concensus building with those around you. Its your own little pet project!
Yes, it is a playground for devops, but IMO the appeal is being able to run any service you want without paying for a SaaS. It often fills the "I want that"/instant gratification void. That and organizing things "just so". Which makes it a hobby.
I get the appeal for other people, but for me I quickly burnt out just trying to keep Deluge, Jellyfin, Zoneminder, and Homeassistant up and functional— Zoneminder in particular is (or was, anyway) an absolute nightmare to deploy and run.
> Zoneminder in particular is (or was, anyway) an absolute nightmare to deploy and run.
Install it, configure it, make sure to give it enough storage so you have the desired retention duration - here about 2 days - and restart it regularly to keep memory leaks in check. Once you've got it set up don't mess with it anymore. I've run it this way for close to 5 years now without too many problems. I did a thorough survey of the available free and cloud-free software before I settled on ZM and regularly check whether something 'better' has shown up but have not seen anything which matches the functionality yet. There's lots of other surveillance camera software but most developers seem to consider a Javascript-heavy glitzy UI the prime directive while the backend is more of an afterthought. I hardly ever use the UI, most interaction goes through apps (ZMNinja etc.) or other systems (OpenHAB etc.). ZM, once configured, does very well this way as long as you keep the memory leaks in the zmc processes in check.
In short ZM is a flawed but functional piece of software with the best balance between functionality and flaws for our application - stable and farm monitoring services. It may not be what your want if you want to have a web interface to that camera on the front porch.
I, after all those years, can finally understand my dad coming into my room, yelling at me due to the electrical bill.
Couldn't understand, only was running Seti@Home 24/7 on my Pentium 4 :D
edit: silly typo!
Proof of work is not a viable defense -- it's basically impossible to tune the parameters such that the cost is prohibitive or even meaningful to the scrapers but doesn't become an obstacle to users.
It's pretty much just a check for whether the client can run JavaScript. But that's table stakes to a scraper. Trying to discriminate between a real browser, a real browser running in headless mode, or something trying to fake being a real browser requires far more invasive probing of the browser properties (pretty much indistinguishable from browser fingerprinting) and obfuscating what properties are being collected and checked.
That's already what any commercial bot protection product would be doing. Replicating that kind of product as an on-prem open source project would be challenging.
First, this is an adversarial abuse problem. There is actual value in keeping things hidden, which an open source project can't do. Doing bot detection is already hard enough when you can keep your signals and heuristics secret, doing it in the open would be really hard mode. (And no, "security by obscurity is no security at all" doesn't apply here. If you think it does, it just means you haven't actually worked on adversarial engineering problems.)
Second, it's an endless cat and mouse game. There's no product that's done. There's only a product that's good enough right now, but as the attackers adapt it'll very quickly become worthless. For a product like this to be useful it needs constant work. It's one thing to do that work when you're being paid for it, it's totally another for it to be uncompensated open source work. It'd just chew through volunteers like nobody's business.
Third, you'll very quickly find yourself working only in the gray area of bots that are almost but not quite indistinguishable from humans. When working in that gray area, you need access to fresh data about both bot and real user activities, and you need the ability to run and evaluate a lot of experiments. Not a good fit for on-prem open source.
Like they said in the presentation, git(lab/tea) instances have insane amounts of links on every page and the AI crawlers just blindly click everything in nanoseconds, causing massive loads for servers where normally there might be a maybe a few thousand git pulls/pushes a day and a few hundred people clicking on the links at a human pace.
Plus the bots are made to be cheap, fast and uncaring. They'll happily re-fetch 10 year old repositories with zero changes multiple times a week, just to see if they might've changed.
Even a if the bad proof of work requires the bots to slow down their click rate, it's enough. If they somehow manage to bypass it completely, then that's a problem.
Which doesn't strictly have anything to do with developers either other than the author being part of all three.
So if you don't understand these things best not to copy them because you could unintentionally be sending some pretty strong signals.
It's also somewhat in the style of the Manga Guides, which are fantastic and an entirely different way to make some of these things accessible.
https://www.ohmsha.co.jp/english/manga.htm
I learned a ton so far, it's been really rewarding having to manage the entire stack yourself.
Also Talos is golden!
But wait, you also run your plex instance on there? And a git server? And wait, it stores your tax documents too?
Is it a playground, or a functional home server?
I run plex and a NAS and a VPN server on a machine in my home, too. But it's a home server. It's definitely not a "homelab" or a "playground" of any kind, any more than my freezer is a playground for storing food.
I certainly don't consider my home server that packs a 30 W TDP CPU from 10 years ago to be a homelab. Someone with half a rack that peaks at 2 kW? That's clearly a homelab.
I think of it as the computational equivalent to a home machine shop. If you don't have some heavy duty equipment can you really claim you have your own shop setup?
It’s both for me! I’ve had a homelab in some form since high school (~12 yrs ago).
Having a home lab has gradually taught me Linux, Shells/Terminals, Ansible, Docker, and most recently Kubernetes.
I have to be careful with backing up data when I do something new. I use this setup for Home Assistant, Plex, small self-hosted apps, a personal Jenkins instance for my open source stuff, and game servers for friends.
It has taught me a lot and has had significant (unintentional) benefit to my career by exposing myself to new concepts/tech and thinking about how operations works solo vs in a team setting.
If you wanna see it: https://github.com/shepherdjerred/homelab
The surest way to take all the joy out of a hobby is to do it as a job. You sound thoroughly employed.
Good way to explore ideas without having to do concensus building with those around you. Its your own little pet project!
Install it, configure it, make sure to give it enough storage so you have the desired retention duration - here about 2 days - and restart it regularly to keep memory leaks in check. Once you've got it set up don't mess with it anymore. I've run it this way for close to 5 years now without too many problems. I did a thorough survey of the available free and cloud-free software before I settled on ZM and regularly check whether something 'better' has shown up but have not seen anything which matches the functionality yet. There's lots of other surveillance camera software but most developers seem to consider a Javascript-heavy glitzy UI the prime directive while the backend is more of an afterthought. I hardly ever use the UI, most interaction goes through apps (ZMNinja etc.) or other systems (OpenHAB etc.). ZM, once configured, does very well this way as long as you keep the memory leaks in the zmc processes in check.
In short ZM is a flawed but functional piece of software with the best balance between functionality and flaws for our application - stable and farm monitoring services. It may not be what your want if you want to have a web interface to that camera on the front porch.
⁽¹⁾ https://github.com/blakeblackshear/frigate