There are definitely good, non malicious reasons to have it as a separate app and that should actually be preferred. Off the top of my head:
Some people might actually like this: thinking of women getting unsolicited dick picks in particular
Ah sorry yea agreed, at least for the units I know about
That is the simplest possible thermostat and works great for setting a temperature, but that’s not the ideal thermostat. The temperature your house “feels like” also depends on humidity. You may also care about the temperature more in a spot further from the thermostat and getting accurate measurements in that location can save you money and waste less gas. There is also the decision of how long you should run a furnace and, in the case of multiple stages, which stage you should run, although some furnaces control the stages themselves. Then there is air flow. Controlling the fan separately is useful if the house doesn’t evenly heat. Sometimes you can just have the fan turn on more often and use the actual furnace less, saving gas again.
Also sometimes it makes sense to heat your house slightly more during high demand hours to save money. I dunno there is just a lot that could be done with an intelligent thermostat, it’s one of the few things that makes sense to make smart to me.
Programmers love to oversimplify things; “do easily with an RPi and some simple Python” is kinda meaningless. Like, yes, an RPi is a general purpose computer and Python is turing complete, thanks.
For one, UI/UX is actually hugely important for a consumer device and definitely nontrivial, but on top of that, there is way more that goes into creating custom hardware than a bill of materials (which isn’t just saying “Raspberry Pi”) and choosing a programming language…
A thermostat is controlling a very expensive device that runs on a highly flammable gas that costs me real money to use. I want 0 serious bugs. I also want 100% uptime. A poorly made “smart thermostat” is way worse then the old school analog metallic ones imo. I also want my partner to be able to control the temperature in the house. These devices are actually not simple at all and I assume that’s the reason there isn’t a good open source/open hardware solution.
Embedded systems aren’t some mystical impossible thing - contrary to the previous commenter I actually find working with them easier then designing GUIs - but the commercially available devices are definitely nontrivial to recreate
Smart thermostats do way more than just set the temperature: that’s just table stakes and of course easy. Off the top of my head the ecobee will:
Set the temperature also taking the room’s humidity into account
Communicate with sensors throughout your house
Can change things via the Internet in case you accidentally forget to set it to a better temperature when you’ll be gone for a few days
Tweak your schedule based on demand
I’m probably missing things, but they’re actually pretty useful, and I’m someone who thinks most IoT is shit.
A smart thermostat is the only “smart device” I have in my home (ecobee). I figure it actually is better than something I could design in a week so it seemed worth it. Do you know of an actually competitive open hardware/open source solution?
Yea, but there are also some things AppArmor just can’t do. Although in my experience most aren’t as big of a deal. Things like saying “only processes of this type can bind to port X” for example and much more fine grained control of file or directory actions. Does AppArmor provide kernel module controls?
They both have really bad documentation though :(
AppArmor is great but it isn’t nearly as powerful as SELinux. Way more user friendly though.
I haven’t looked around that much in years beyond NixOS, what else has MAC by default these days? I remember a lot of the Debian based ones having some things constrained by AppArmor, but I personally prefer SELinux and it wasn’t everything.
I don’t know if it ships with a firewall, but that’s definitely easier than an ad hoc SELinux setup. I always just transfer my iptables (nftables now) rules over.
One of the few with SELinux by default
Should also definitely be quoting both arguments
I almost never use Windows, but aren’t commands and variables in PowerShell case insensitive?
As long as it’s installed on a device you control it’s pretty easy to sniff TLS traffic from an Android application, even if they’re pinning certs. I do this all the time for work. Frida makes it extremely easy, even giving you the ability to edit boringssl if something important is happening in native code. I’ve had to do this a couple times.
If you don’t have root you’ll have to recompile the application though which could matter if you need the signature to not change, but that isn’t a common requirement.
It’d be nice to have a better way to test though; I’ve wanted to check out Waydroid. Some coworkers just use an emulator which works great if it doesn’t need specific hardware.
Hm I always remember hearing this:
In a confidential memo to the Republican party, Luntz is credited with advising the Bush administration that the phrase “global warming” should be abandoned in favour of “climate change”, which he called a “less frightening” phrase than the former.
This is a real exploit chain in cups-browsed. The tl;dr is that it will add basically anything that knows the correct protocol to your list of available printers, and this can be exploited for RCE if you print to the malicious printer. The service listens on all interfaces by default on UDP 631.
It is not as horrible as it was marketed, but it’s real and not great. You may or may not have this service running by default; I didn’t on Fedora.
His full write-up is here: https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/
Redox also takes some inspiration from Plan9 and https://doc.redox-os.org/book/ch05-00-schemes-resources.html is interesting. Also reading https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html made me a bit more interested in things trying to be more Plan9-like than Unix-like.
This doesn’t seem to be a Rust problem, but a modern development trend appearing in a Rust tool shipped with Cargo. The issue appears to be the way things are versioned and (reading between the lines maybe?) vendoring and/or lockfiles. Lockfiles exist in a lot of modern languages and package managers: Go has go.sum, Rust has Cargo which has Cargo.lock, Python has pip which gives a few different ways to pin versions, JavaScript has npm and yarn with lock files. I’m sure there are tons of others. I’m actually surprised this doesn’t happen all the time with newer projects. Maybe it does actually and this instance just gains traction because people get to say “look Rust bad Debian doesn’t like it”.
This seems like a big issue if you want your code to be packaged by Debian, and it doesn’t seem easy to resolve if you also want to use the modern packaging tools. I’m not actually sure how they resolve this? There are real benefits to pinning versions, but there are also real benefits to Debian’s model (of controlling all the dependencies themselves, to some extent Debian is a lockfile implemented on the OS level). Seems like a tough problem and seems like it’ll end up with a lot of newer tools just not being available in Debian (by that I mean just not packaged by Debian, they’ll likely all run fine on Debian).
I agree and think that should be helpful, but I hesitate to say how much easier that actually makes writing sound unsafe code. I’d think most experienced C developers also implicitly know when they’re doing unsafe things, with or without an unsafe block in the language – although I think the explicit unsafe should likely help code reviewers and tired developers.
It is possible to write highly unsafe code in Rust while each individual unsafe block appears sound. As a simple example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6a1428d9cae5b9343b464709573648b4 [1] Run that on Debug and Release builds. Notice the output is different? Don’t take that example as some sort of difficult case, you wouldn’t write this code, but the concepts in it are a bit worrisome. That code is a silly example, but each individual unsafe block appears sound when trying to reason only within the block. There is unsafe behavior happening outside of the unsafe blocks (the do_some_things function should raise eyebrows), and the function we ultimately end up in has no idea something unsafe has happened.
Unsafe code in Rust is not easy, and to some extent it breaks abstractions (maybe pointers in general break abstractions to some extent?). noaliases in that playground code rightly assumes you can’t have a &ref and &mut ref to the same thing, that’s undefined behavior in Rust. Yet to understand the cause of that bug you have to look at all function calls on the way, just as you would have to in C, and one of the biggest issues in the code exists outside of an unsafe block.
[1]: If you don’t want to click that link or it breaks, here is the code:
fn uhoh() {
let val = 9;
let val_ptr: *const usize = &val;
do_some_things(val_ptr);
println!("{}", val);
}
fn do_some_things(val: *const usize) {
let valref = unsafe { val.as_ref().unwrap() };
let mut_ptr: *mut usize = val as *mut usize;
do_some_other_things(mut_ptr, valref);
}
fn do_some_other_things(val: *mut usize, normalref: &usize) {
let mutref = unsafe { val.as_mut().unwrap() };
noaliases(normalref, mutref);
}
fn noaliases(input: &usize, output: &mut usize) {
if *input < 10 {
*output = 15;
}
if *input > 10 {
*output = 5;
}
}
fn main() {
uhoh();
}
No intention of validating that behavior, it’s uncalled for and childish, but I think there is another bit of “nontechnical nonsense” on the opposite side of this silly religious war: the RIIR crowd. Longstanding C projects (sometimes even projects written in dynamic languages…?) get people that know very little about the project, or at least have never contributed, asking for it to be rewritten or refactored in Rust, and that’s likely just as tiring as the defensive C people when you want to include Rust in the kernel.
People need to chill out on both sides of this weird religious war. A programming language is just a tool: its merits in a given situation should be discussed logically.
The real issue is definitely people not having total control over their own devices.
It doesn’t need permissions to be sent pictures from messages though, that’s all local and likely done via an exported Service. Good chance other Google products are or will make use of it in the future.