I’m away on vacation and weather reports say there might be a thunderstorm at my house with high probability of power outage, so maybe I lower the temperature setting to try and extend the life of the contents.
Kids/nanny/housekeeper changes the temperature against my wishes.
I’ve left the house for a long vacation with the fridge emptied and I’d like to change the temperature to consume less power while I’m gone, forgot to do it before I left.
And again it’s trivially simple functionality that costs almost no money or development effort to I implement.
So you spend 11k on a smart fridge, have a nanny, but maniacally control the temperature depending on contents, possible weather scenarios and and if you are vacation. Makes sense. Maybe that is why I'm still poor, imagine all the money I've wasted never once adjusting my fridge temp remotely (or even manually) in the last 14 years.
I said it above but I will say it again, if your fridge has a door open sensor it should have a close the door function. This is especially true if you spent $11k on it.
I think you misunderstand the built-in luxury appliance market a little bit. They are meant to be permanent appliances that are easy to repair and replace parts for, and they are built to higher quality standards (depending on the brand, of course, but Sub-Zero has a good quality reputation and builds their appliances in Wisconsin).
Because they are designed to be installed for decades, they also evolve at a slower pace than typical consumer appliances. If something breaks 15 years down the line, the manufacturer either still makes the same part or makes a compatible replacement. They are sold under the assumption that they are installed long-term.
Sub-Zero explicitly markets their refrigerators as being designed to last at least 25 years.
They have fewer features than Samsung feature checkbox fridges on purpose.
An automatic door close function would also be potentially dangerous with a built-in custom panel refrigerator like mine. My fridge has more pinch points than a normal fridge because the cabinetry is designed to be seamless.
A temperature control is a dead-simple and basic smart function that’s easy to implement. Automatic door closing would be a complicated mechanical mechanism prone to failure.
I will also note that I didn’t choose this fridge to be a snob, I chose it because my home already came with a custom panel refrigerator that needed to be replaced (a garbage piece of shit from Viking that wasn’t worth repairing, side note, I hate that company even more than Samsung). If I replaced my refrigerator with a normal one I would have had to do additional carpentry work on my house to avoid the area looking gutted so to speak, and I would also devalue my home since luxury built-in custom panel appliances are features that show up on real estate listings and they are a “luxury” indicator to buyers.
> so maybe I lower the temperature setting to try and extend the life of the contents.
Bullshit. The ideal refrigerator temperature is already close enough to freezing that any small adjustment you could make is unlikely to do any good. If this was actually a good idea then by your logic (similar to odd love for printer manufacturers) the all wise manufacturers would have already incorporated this into their “smart” fridges.
I can imagine one good use: plotting graphs of inner temperature, configured set point, motor on/off status, door open/closed status, and power consumption. But that use case does not require having control of the fridge compressor...
If the temperature goes out of acceptable range than then it is defective. The only people who need that plot are the lawyers for the class action lawsuit for a defective appliance.
There are scientific reasons to need the plot, but that is not normal and they likely need a special fridge with tighter controls or something anyway.
I’d just throw an analog min/max thermometer in there and investigate if the max temp goes above 40F, sounds a lot easier than adding a temp probe and door switch to a residential refrigerator.
There is already a door switch in all the refrigerators I have used. It controls the light (at least I think it does, I have never seen the light go off:)
It's hard to explain without going into a few low-level details of PCI Express, but let me try.
Most PCI devices expose some memory and/or I/O ports to the CPU. That memory (or I/O ports) is mapped to somewhere in the address space visible to the CPU. Besides the memory and I/O ports, all PCI devices also expose a separate set of configuration registers; among these registers, there are the Base Address Registers (BARs), which configure where the memory or I/O ports is mapped.
Here's an example output from "lspci -vv" for a GPU:
Region 0: Memory at 7c00000000 (64-bit, prefetchable) [size=8G]
Region 2: Memory at 7e00000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=256]
Region 5: Memory at fca00000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at fcb00000 [disabled] [size=128K]
Note that regions 0 and 2 are above the 4GB addressable by old 32-bit CPUs. To be compatible with these old CPUs, this card and many others like it allow the firmware (and/or the operating system) to choose not only where the memory is mapped, but also its size. We can see this in the same "lspci -vv" output for this GPU:
Capabilities: [200 v1] Physical Resizable BAR
BAR 0: current size: 8GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB
BAR 2: current size: 256MB, supported: 2MB 4MB 8MB 16MB 32MB 64MB 128MB 256MB
Older systems which do not understand this extended capability will still treat these regions as fixed size, probably with the first size in this list (256MB for region 0, 2MB for region 2). Newer systems can tell the device to "resize" the BAR to a bigger size, which obviously needs the first region to be placed above the 4GB barrier since it's too big.
Why is this useful? This particular GPU has 8GB of VRAM; it's quite obvious that region 0 is a direct view into that VRAM. When using the maximum BAR size, the CPU can directly read and write anywhere into the VRAM; when using a smaller BAR, the CPU can only see a small window into the VRAM, and has to use less direct methods to access it.
(As an aside: go right now and do a "sudo lspci -vv" on your computer, if you see a Resizable BAR capability which isn't using the maximum size, you can probably gain a bit more speed for free by going into the BIOS and enabling "Resizable BAR" and/or "Above 4G decoding". If you can't find these options, well, AFAIU that's what this project is all about..)
> (As an aside: go right now and do a "sudo lspci -vv" on your computer, if you see a Resizable BAR capability which isn't using the maximum size, you can probably gain a bit more speed for free by going into the BIOS and enabling "Resizable BAR" and/or "Above 4G decoding". If you can't find these options, well, AFAIU that's what this project is all about..)
IIRC Linux doesn't need resizable bar enabled in the BIOS since the kernel will resize the bar if supported by the GPU, Windows however relies on the UEFI doing it which is where it being enabled in the BIOS is needed.
> Yes, /dev/(u)random is supposed to do that, [...] getrandom() is often times suggested, but alas isn’t a standardized function, i.e. it’s not part of the POSIX specification.
Is /dev/random or /dev/urandom part of the POSIX specification?
Neither one is last time I looked. I’m a lot more uptight about POSIX compliance with code that needs to compile than I am with code that just needs a special /dev file to run, for the simple reason, when using POSIX during the compile stage, I can place the blame on GCC and/or clang if the program doesn’t compile when my program is POSIX and C99 compliant (I was, like many, burned by the C23 changes which made a lot of code which previously used to compile no longer compile).
I actually at one time had a Windows binary which would use Windows proprietary calls to make a “urandom” file (secret.txt was its name) so people could have good entropy on systems using the exact same interface as fopen("/dev/urandom","rb") (i.e fopen("secret.txt","rb")) without needing an actual /dev/urandom.
Length extension attacks are not an issue for git, because every object has two fields in its header, which is prepended to the object before hashing: the object type and the length in bytes.
Interesting. Anyway, since they're going through the pain of changing the hash function, why not using the latest standard? SHA3 has been standardized for some time now, and using SHA256 isn't any easier than using SHA3-256.
> they're going through the pain of changing the hash function
They've already gone through the pain, deciding on it on 2018[0] (and functional & non-experimental 3 years ago per TFA). What's left is just changing the default (and some stragglers to complete support). Changing the function now would push back changing the default by a couple additional years until the new git version gets widespread deployment (incl. on LTS distros and whatnot).
> Good, are there (m)any other plans to ditch the slow files and use proper database?
The filesystem is a proper database, just not a relational one.
Linus focused heavily on performance when he wrote git; he used the filesystem because, as the main Linux kernel maintainer, he knew that the Linux VFS and filesystems were fast enough for these use cases.
(It's the use cases that have changed; it was not expected back then to have more than a few hundred refs in a single repository.)
Ah, yeah, "you're holding it wrong", though use cases haven't changed, it's closer to the expected common case of expectations turning out wildy wrong (Why would you ever expect people to stop NAMING things at scale???)
But also the core property of the filesystem database has always been low performance for a bunch of tiny things
Not so much a "you're holding it wrong" as much more directly "we didn't expect it to be used that way". The Linux Kernel team was using it in a DVCS way with a mailing list as the primary "remote work in progress ref storage" and local refs mostly just local personal branches and tags. The "Hub" model of everyone on a project having access to nearly any and all refs in the project is different from the model of the original git developers. Neither model is "wrong" just one is more unexpected when working on the other.
(As a Windows user, I certainly can't argue that sometimes the filesystem as database has been a performance hit when using git. Though Windows filesystem performance isn't always slow, just performs differently, especially with corporate anti-virus tools involved.)
> GrapheneOS's goal is privacy for the world and that's achieved through secure devices.
Perfect is the enemy of good. What's better for privacy, an old but inexpensive smartphone running Android 11, or the same smartphone running an up-to-date third-party rebuild of Android 16 or newer with as many privacy-improving bells and whistles as the hardware can support?
> Soon there will be two different phone brands which you can install it on.
...will they be available in my country (Brazil)? I don't think I've ever seen a Google Pixel phone in person.
Not sure if you have any experience with eBay. I looked it up and people had problems selling to Brazil [1] but there are various listings that offer to ship. So maybe not a great option.
KaBuM!, Intec Store, Performance Solutions all charge significantly more with a 10a being more than double than from Google.
Motorola officially sells the Signature in Brazil [2] at the same price or cheaper than in the UK. It will be supported by GrapheneOS in 2027 on the 2027 version. From then on, hopefully Qualcomm brings MTE to the non-flagship chips and Motorola and GrapheneOS support budget or midrange devices.
>perfect is the enemy of good
I don't consider that relevant when users deserve ≥ security than an iPhone. GrapheneOS is not purpose-built to avoid big-tech's services although it does that more completely than any other alternative mobile operating system, the focus is privacy.
> Are all of these unsuitable [0]? [...] I looked it up and people had problems selling to Brazil [1] but there are various listings that offer to ship.
Do these phones have ANATEL certification? Because if they don't, they will be rejected by customs. It's not simply a case of the item being held until you pay a 60% import tax.
There are [1] people currently using GrapheneOS in Brazil. You can ask on the forum and you might get more clarity. The Motorola Signature will be announced in a few days but is a high end flagship with all-around better hardware than the Pixel 11 Pro XL and it's cheaper, but it's still a flagshio.
What's better for privacy, an old but inexpensive smartphone running Android 11, or the same smartphone running an up-to-date third-party rebuild of Android 16 or newer
I see your point, but it would be very misleading, since the phone would still have a lot of known holes. Only the OS would get updated, typically not the drivers, driver firmware, possibly not the kernel. The phone would still be easily compromised through all the known RCEs. So you tie up non-profit projects in a lot of extra work to get an improvement that does not really matter.
This is a mess created by the OEMs and they will continue to create this mess until people will stop buying from OEMs that only give lip service to security updates (roll out Android Security Bulletins to show a high patch level, while in reality the phone the phone has many known CVEs).
Android Security Bulletins do list a tiny subset of firmware, Linux kernel, driver and HAL patches so they do require at least very minimal updates to those. Most non-Google-certified operating systems are setting an inaccurate Android security patch level by ignoring the non-AOSP portion of the patches. GrapheneOS doesn't do that but most of the other AOSP-based projects not being certified by Google are doing it. OEMs were caught doing it too but it's not clear if it was intentional in most cases as it is with the alternate operating systems.
Android Security Bulletins set a very low bar since the AOSP patches are available to ship by OEMs 2-6 months prior to the bulletin being published. It's also only High/Critical severity patches being listed. Due to a recent policy change, it's also officially only a subset of the patches for AOSP. That's visible through the Android platform components having patches in the Pixel Update Bulletin for September 2026 despite those being applicable to other operating systems. It's because they no longer want to backport all High and Critical severity patches due to the high volume of issues discovered by AI models. It's similar to how they stopped backporting any Low and Moderate severity patches years ago due to high volume.
The purpose of GrapheneOS isn't providing a less bad operating system for insecure devices which still lacks anything close to reasonable security patches and protections. It would not be possible to provide the core GrapheneOS feature set on those devices. More importantly, they'd have many years of missing firmware, kernel, driver and HAL updates. Those are among the most important security updates and would not be available in practice. That would not be GrapheneOS and is not the purpose of GrapheneOS.
> Same as traditional physical keys, you don't have a single key, you have multiple ones [...]
I have multiple identical ones.
> [...] and can go to the local locksmith and get another one in minutes.
Can I go to the digital equivalent of a locksmith (like a backup software) and duplicate my passkey? Can I do that with only my passkey in hand (without having to do anything to the corresponding lock, or having to contact its issuer), like I recently did with a physical key?
Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!
So if we are enforcing MFA requirements and allow this kind of clonable key, then we should really require some other factor that is not clonable.
That's the core silliness of this whole passkey mess, IMHO. So many turns of rhetoric and weird compromises, we have cargo cult security and no real understanding of what security level is in place.
Instead of the best of worlds, we can accidentally have the worst of worlds without realizing until it is too late and we're painted into one of those ugly corners.
> Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!
If you have a photo of a traditional metal key, you can duplicate it. AFAIK, there's also a numeric representation of the height of each position on the key; if you know that number, you can duplicate the key. A traditional metal key is more like a password than most people think.
In the world of object-oriented programming: https://en.wikipedia.org/wiki/Liskov_substitution_principle#...
reply