Thanks! MBCompass will stay fully FOSS and free. Donations are extremely rare (tbh, I've not received a single one), especially from the Foss Android community, but they’re still very helpful for long-term sustainability (given Google's non-sense Play monthly policies) and greatly appreciated, especially for users new to open source.
Not true anymore! \o/ I don't use Android anymore, but I agree a lot with the principles you've shared here, so it's a thank you for sharing that. And I know how difficult it is to get the first donations, and after you get the first, it's much easier to get the later ones. So best of luck, and I hope you'll remain steadfast with your principles when it'll matter! :)
Thank you, that really means a lot. Consistency has been important to me, whether it’s shipping regular releases with real improvements (https://github.com/CompassMB/MBCompass/releases) or writing about Android development and FOSS alongside the project. I really appreciate the encouragement and support.
You might add Bitcoin, Lighting or Monero to your donations page. Would've gladly dropped you a few bucks but I don't use any of the services you're offering.
Thanks for the suggestion, that’s a fair point. I currently rely on a couple of mainstream platforms mainly to keep things simple, but I do see the value in more open and permissionless options like Bitcoin/Lightning or Monero.
I’ll definitely consider adding at least one of them going forward. Really appreciate the willingness to support.
> But what additionally raised red flags was the presence of tcpdump and aircrack - tools commonly used for network packet analysis and wireless security testing. While these are useful for debugging and development, they are also hacking tools that can be dangerously exploited.
Must be another AI slop article. Stop feeding your writings into GPT & co to turn into extra long nonsense.
systemd is so resource hungry that i'm sure they removed it to reduce the RAM bill. Apt... why install apt if the distro has a different means of updating?
2. While these are useful for debugging and development, they are also hacking tools that can be dangerously exploited.
This is purely fear mongering. Even the shell could be a "hacking tool that can be dangerously exploited". Let's remove the shell too.
There are some legitimate complaints in the article, like the use of the same key on all installs. The rest looks more like fear mongering and security theater.
Including the microphone. What were they supposed to do, desolder it manually and add $10 to the price of each device?
I don't see the article complaining that a PiKVM has so many unused peripherals when used as a KVM. To go in the spirit of item #2, the usb ports could be used as "dangerous hacking tools" so you should desolder your usb ports from a Pi used as a KVM, right?
apt is a package manager. It's only relevant if the system uses it to manage it's packages. Red Hat based distributions, for example, don't use apt. Embedded devices typically don't manage packages on an individual basis, rather updating the entire distribution via "firmware updates".
Oh yes I know they do in this post, I meant more generally. Even myself I often wish I had a need to use a lower-level, cooler language, but the pragmatic side of me just can't justify it.
It is if the script is written badly, gets truncated while it's being downloaded, and fails to account for this possibility.
Look into tailscale's installation script, they wrapped everything into a function which is called in the last line — you either download and execute every line, or it does nothing.
This "what if it gets truncated in the middle of the download, and the half-run script does something really bad" objection gets brought up every time "curl | bash" is mentioned, and it always feels like "what if a cosmic ray flips a bit in your memory which makes the kernel erase your hard drive". Like, yes, it could happen in the same way getting killed by a falling asteroid could happen, but I'm not losing sleep over it.
Just living far from major datacenters is enough. I get truncated downloads pretty regularly, maybe a couple times a month or so. The network isn't really all that reliable when you consistently use it across the globe.
It usually happens on large files though, due to simple statistics, but given enough users, not hard to imagine it happening with a small script...
That's quite uncommon. Typically your distribution checks that the downloaded source/binary has the correct checksum and an experienced maintainer checked the (sandboxed) installation. Here someone puts an arbitrary script online that runs with your user's permission and you hope that the web page is not hijacked and some arbitrary dev knows how to write bash scripts.
Although this article does state that bind's "configuration files and options require careful attention to detail".
So, maybe it's not appropriate for the modern hype-cycle s/w development model?
In general, I don't think I'm disagreeing with you, so I'm not sure what message the reply is intended to convey.
Technitium seems like another one of those: "My weekend hobby project was to reinvent fire, and the wheel" sort of things, that seem popular on the HN feed.
My favorite feature of bind is "split views". This allows the same service to provide DNS on the local LAN, as well as authoritative DNS to the internet.
I am fan of Technitium, because I like to build and I built two plugins for it to fit my use case. But at work, we use Windows DNS and Bind in parallel. So, this is also a hobby of mine. The hook for me is that it is built with dotnet, and I have experience in that stack. Other features are secondary actually.
I am curious though, what would TDNS do so that you can replace BIND with TDNS in your homelab/workplace or wherever it is used? I genuinely ask for it so that I can help the original developer with some PRs.
Are you kidding? Bind has been the de facto standard for DNS servers for ages but it's just a badly engineered piece of software and had braindead vulnerabilities for decades:
Already 20 years ago it was common knowledge to never use software that Paul Vixie had touched (bind, vixie-cron, sendmail ...) and we used alternatives such as djbdns. Good old times...
Bold statement just one month after the last cache poisoning vulnerability. Bind is the Microsoft Windows of DNS servers - a lot of users and bugs nonetheless the go-to for many admins because that's what they are most familiar with. And similar to Windows, the internet mostly relies on others - none of the big companies (Meta, Cloudflare, Google, MS, Amazon, Netflix, Twitter...) use bind and neither do most hobbyists. It's just for the plethora of mid-sized companies with unmotivated admins.
By "..._MAX" I assume that you mean the maximum value of a given integer type.
In a language where half-open intervals are supported consistently in all the places, this would be solved trivially, e.g. for a signed byte the _MIN and the _MAX values would be defined as -128 and +128, more intuitively than when using closed intervals, where you must remember to subtract 1 from the negated minimum value.
Even the C language has some support for half-open intervals, because the index pointing after the last element of an array is a valid index value, not an out-of-range value (though obviously, attempting to access the array through that index value would be trapped as an out-of-range access, if that is enabled).
Applied consistently, the same method would ensure that the value immediately above the last representable value of an integer type is valid in ranges of that type, even if it would be invalid in an expression as an operand of that type.
