As mentioned, I'm a linux noob. On an embedded device with eMMC storage like these routers have, I'm anxious to enable anything that leads to using a swap file for system memory. This anxiety has no basis on fact because I don't know exactly how these things work - but prior experience with linux devices like Raspberry Pi projects and other small embedded systems has demonstrated that if you can avoid the cpu from needing a swap file, you're better off.
I have enabled only the two default AGH lists for now and get a 96% on the test. That's fair enough until I investigate further. I'm also experimenting with an Opnsense system running on an N150 x86 cpu with 8GB ram - if I add a few hagezi lists to the filter that system gets me 99% - 100%, so there's obviously room for improvement on the Flint 2.
One day as I gain more knowledge (and gear lol) I'll probably end up with an Opnsense system using an AP for wifi... But for now my Flint 2 is doing pretty well outside some 2.4 wifi speed concerns. And there's definitely value in a single device that doesn't require any substantial management (or much electricity).
AdGuard Team don't know the limitation of the hardware where their software will be installed. It can be installed in a Router or in a Powerful PC.
On another hand, GL-iNet know exactly the limitations of their own hardware, so the software installed in their own firmware should be customised to avoid crashes.
It's not about agreements or not. The main issue: AdGuard Home is a piece of software, 3rd party. GL can't modify it (or it does not make sense to do so - because it's an entirely different thing)
Microsoft won't modify Adobe's Photoshop just because Photoshop needs 10 GB of RAM if you can provide only 4...
The user is responsible for using the 3rd party software correctly.
Adobe Photoshop is not opensource.
AdGuard Home is opensource.
If an user enable so many block lists in AdGuard Home and the router doesn't have enough memory available, it should show an warning message and disable the lists to avoid the router to crash.
Just because AGH is open source doesnât mean that GL can go modifying it for you, any more than MS could change Adobe code. And AGH developers have no reason to make changes just for GL users, when other people might have systems that can use 64GB of ram.
OSS imposes more responsibility on the user. Thatâs just the way it is. And why propriety software sells.
Edit - and if you think this is confusing, wait until you try setting up AGH in something like OpnsenseâŚ. Thereâs few warnings to prevent you from mucking up the whole system.
I guess GL could make a fork of AGH that does what you wantâŚ. And be responsible for yet another project while trying to maintain all their existing projects. But I wouldnât hold my breath for that.
This is not how operating systems work. I agree that GL might be able to adjust AGH so it won't crash the whole routerâbut ultimately, it's within the responsibility of each user.
You were given the tools, up to you what you build with them.
How the user will know that a blocklist will crash the router?
The only way to know is when you crash the router. Which is quite easy to do on GL-B3000 and GL-MT3000.
And to revert this, is not an easy task.
The interface should preload the blocklist. If it consume more than 85% of Free Memory, it should send an warning to the user instead of applying it. After that point, I agree that is the user responsibility.
Did you report this issue to the AGH team already, that they should fix the memory leakage / overuse within AGH? I mean⌠it's their responsibility. AGH should check how much memory is available and show a warning then. I mean, that is exactly what you want.
When you have a problem with Google Chrome, because it uses too much memory due to invalid configuration (or bad configuration because you load too many plugins) you need to ask Google, not the PC manufacturer.
Memory management is mostly some application thing - until the OS will kill the application - which is what happens with AGH. But it's not the OS fault.
However I agree that there might be a warning about too big lists, but checking them isn't something the GL firmware should do. User are responsible if they use 3rd party integration.
Another option would be removing AGH from low power devices, I assume.
You missed the key point: it's not ADH developers making changes to GL-iNet users.
It's about GL-iNet developers making changes for ADH used in their own Hardware.
I think you missed my pointâŚ. In the open source community, AGH developers are responsible for the AGH code. GL canât just tweak it however they want - especially if they want to allow future updates. Because once you start modifying code, you own it - and whoâs to say that something as innocuous as a memory warning doesnât play well with future revisions to AGH. So, the only professional way to handle this would be to create a fork of the AGH project that GL maintains. Now, theyâve added responsibilities and resources to another code base.
Iâm grateful that GL provides easy access to AGH, because the real solution here would be to not put AGH in the GL menu and instead make you go through Luci to add it. But what could be done is adding a user warning about not adding more filters to AGH when you enable it from GL.
EDIT - actually, the real solution is communicating with the AGH devs and requesting them to add a memory check warning.
Adding a warning and perhaps a link to an information page that discusses the issue plus an option to reset AGH to default would be helpful. That would at least negate the need to use the CLI to edit the AGH filter file, which is likely somewhat beyond the average userâs understanding.
Open source software requires more tweaking than commercial options. Itâs a double edged sword for users not familiar with how things work.
Do you want expand filter list? Why not try add filter lists in cloud DNS server (Adguard DNS) and put upstream in your router with or without Adguard home.
Need more ? Split list in Adguard DNS server and local Adguard Home.
Solved problems
I think it is best to say "one of the common use cases I see in the forum". This avoids confusion regarding opinions vs raw data and facts from GL.inet themselves. I only bring this up because your feedback constantly comes off borderline hostile yet I appreciate your feedback (once I understand opinion vs fact).
This product is a commercial offering sold on Amazon, meaning it is designed for a broad audience and does not default to the Luci or OpenWRT command line. In general, commercial products come with higher expectations for advertised features, including legal requirements to ensure they function as promised.
I understand that some users, like yourself, prefer command-line access for customization. However, othersâincluding myselfâare looking for a more user-friendly, plug-and-play solution. My perspective comes from a background in user experience design and product management, specifically in network security, where I spent over 25 years working with customers across different industries, including small businesses, mid-size businesses, enterprises, and government agencies. From these conversations, a common theme emerged: customers wanted products that were easy to set up, reliable, and cost-effective.
The main request here is to present this product in a way that ensures a simple, stable experience for those who may not have technical expertise, while still allowing power users to customize it as they wish. This product should aim to support both user groups effectively.
