JFY, there are thousands of weather stations reporting the temperature across the globe on the APRS network. Fairly easy to check temperatures for most places at zero cost and without internet.
Look, I'm with you on those critics and my opinion about python in general is just "duh" but this project looks good, it is easy to write/deploy and looks well documented (need to test it out).
For apps that are simple, might be OK. I've done a similar operating system which would run C-like scripts (using Wrench) instead of python and came with a command line if you wanted to shell directly into the device but nobody cared: https://github.com/radio3-network/B3OS
At least they've done a far better job in presenting a capable operating system and bringing people to move it further.
Compared to other microcontrollers: ESP32 is very power hungry. Shiny displays are very power hungry, Wi-Fi is power hungry. So expect to draw about 5 watts/hour continuously while in operation with all bells and whistles.
With this said (I'm also using them for off-grid) you will need to put them to sleep and only use the display when absolutely needed for most scenarios. I've recently started using devices with e-paper display which at least solve that nuisance of the display power draw: https://www.waveshare.com/wiki/ESP32-S3-ePaper-1.54
The last thing to keep in mind is heating. They will warm quite a bit and you should consider a way to either keep them cooled or make them sleep enough to cooldown, otherwise they will reboot or stop working until they are cooled again.
> If someone is interested in draw over a period, e.g. over one hour, you'd say it used 5Wh in that period.
Wh per hr? Let's just cut through the confusion and say it draws (J/s)Hr / Hr. :P
More seriously, if you are interested in energy the "correct" SI unit is J although in electrical applications [k/Mega/Giga]Whr is common. If you are interested in energy draw over a period, aka power, the "correct" and common unit is W. While 5 Wh per hour might seem simpler, it is equivalent to say this thing draws as much energy per hour as a device that that draws 5W would draw over one hour - needlessly redundant.
In the offgrid world we look constantly at batteries and they often express themselves in Wh. So it is a habit to measure anything else that way to avoid confusions.
There is little point in fortifying the front-door when the backdoor is wide open.
The hardware itself should never be trusted when being produced by a vendor like Google and cannot be verified on the component level. Their business model completely revolves in reducing your private sphere and sell it to others.
Never use google hardware if you are serious about security.
You have it backwards. It's smartphones other than iPhones and Pixels with the front door open due to lack of basic security patches and protections. You're making unsubstantiated claims about backdoors not backed by any evidence. Those claims can be made about ANY available hardware. Using devices without basic privacy/security patches for firmware/drivers, an end-of-life Linux kernel and lack of important hardware-based security features is the opposite of being serious about security.
The reason GrapheneOS has an OEM partner we're working with towards their at least one of their upcoming devices meeting our requirements is because Pixels are the only currently viable options. If other OEMs were making reasonably secure devices with support for using another OS on their own, we wouldn't need OEM partnerships. The currently available devices from our OEM partner don't meet our security features or update requirements, but a subset of their future devices will. GrapheneOS will be officially supported so it will be easier to provide a fully production quality OS and we'll be able to do lower level privacy and security improvements at a hardware, firmware and driver level.
All mobile computing and connectivity hardware is unverifiable in reality and by design. It's not some property exclusive to Google Pixels.
Their business model also does not involve selling data afaik, it's selling access to their adspaces [1] all over the internet including the ability to target people (based on information Google jealously hoard). They stand to lose just as much as most other OEMs if they did suspicious things in hardware just like Apple, Samsung etc.
If you're serious about security you will avoid using OEMs that have unfortunate patch gaps which leave device owners at the mercy to *known vulnerabilities* [1][2][3][4] as well as unknown threats which is fortunately one of GrapheneOS's many reasonable device support requirements.
That is incorrect. There are more reasons for a major US-government contractor to implant spyware on their hardware to hand our privacy on a plate to alphabet agencies than a generic cheap android without a known brand.
This doesn't mean the cheap device arrives without spyware, likely the difference is the spyware being monitored by chinese rather than US agencies so pick your poison. I'll pick mine.
Open schematics for a PCB don't make it any harder to hide a backdoor. You're talking about devices which still have an entirely closed source SoC with all of the real complexity. The products you're repeatedly marketing here use a bunch of low end components with very poor security including lacking ongoing patches for vulnerabilities and basic standard security protections. They're falsely marketed as open but are actually closed source hardware with closed source firmware. A closed source SoC, Wi-Fi, Bluetooth, cellular, NFC, SSD, touchscreen, camera, etc. attached to a PCB with open schematics is not open hardware.
They're talking about devices known to be extraordinarily insecure, which are still closed source hardware with closed source firmware. Having schematics for the board does not avoid trusting the hardware. It's still a closed source SoC and the same for the other components such as the SSD, Wi-Fi, Bluetooth, cellular, etc. but those components are much less secure without proper updates and security protections. The whole point of an SoC is that it has the complexity of a traditional CPU, GPU, motherboard and other components merged into a single chip, and that's entirely closed source with closed source firmware on those devices.
So you are just attacking another FLOSS community with false [0] claims. This is suspicious.
[0] You can't say "extraordinary insecure" without specifying a threat model. For some threat models, GrapheneOS is less secure, e.g., https://news.ycombinator.com/item?id=45556788
Also, if I explicitly don't trust Google with anything, GOS is extraordinarily insecure for me until a new vendor appears.
The author wanted to take down their account (to take a break) so this is actually working as designed. The takedown was issued from the author’s repository (which they control), and the downstream app server acknowledged the request.
I'm not sure I would necessarily draw that conclusion.
If the author intentionally deactivated their Bluesky account, does the fact that he can successfully do that on Bluesky lead to the conclusion that it's less resilient?
I think you've nailed a problem with all of these, they would make "deleting your stuff" HARDER. What's stopping the rogue node from saving all your stuff forever?
I think "trying to make a thing that can work through rogue or stupid nodes" is just prohibitively harder than "work on making nodes more reliable" (which I absolutely grant is extremely hard.)
Taking this idea further -- this is the sort of thing that really makes me consider whether or not ATProto might be literally the worst idea in all of social media.
Which is to say "can track you just as intrusively as any private service, but now your history is cryptographically signable and even EASIER to share and move everywhere"
The comment makes so little sense that it could only be intended as a dumb gotcha from someone who thinks they're fighting in some sort of culture war about the Twitter succession. Ignoring is better than encouraging.
(Note: I put a subtle bug in there because it always happened)
SQL injection is horrible, but people were managing to do that all these years after prepared statements anyway without text blocks. I really don’t think they made things worse. Same thing with embedding HTML in the code. They were gonna do it anyway.
I'm that author. It has been more than a decade and still won't use streams nor lambdas. Makes the code too difficult to write and debug for me.
Really prefer to have more lines of code and understanding very clearly what each one is doing, than convoluting too many instructions on a single line.
For me it's the opposite: If I had to write the code that I usually use lambdas for in any other way then _that_ would be very difficult to write and to debug.
Especially when writing JavaFX code which is full of callbacks and event handlers I really don't see any other (useful) option.
Can lambdas be misused? Of course they can - but so can every other code construct.
I bet you don't like how it looks when you put huge code blocks inside a lambda. Me neither. But that's an issue with coding style; it forces you to extract processing code into a method. I'd argue the opposite way - imperative syntax constructs make spaghetti code too easy to work with.
Yes, well expressed. For that case using var is not a wise approach.
It does help when writing:
var x = new MyClass();
Because then you avoid repetition. Anyways, I don't ever use "var" to keep the code compatible with Java-8 style programming and easier on the eyes for the same reasons you mention.
