> The battery is stubbornly glued down, and the soldered charge port can’t be easily replaced.
You have to take a heat gun to your phone to soften the glue to get the old battery out. Too little heat, the battery won't budge. Too much heat, you damage your screen or worse, ignite your battery. Good luck.
GOS's limited device support is disappointing, but I understand their reasoning. I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.
As an alternative to replaceable batteries you could consider installing something like acc[1] to mitigate stress on your battery. My phone is 7 years old and the original battery still holds a charge like the day I bought it.
> GOS's limited device support is disappointing, but I understand their reasoning.
Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking.
> I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.
It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.).
Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
I just migrated from a QNAP NAS to a custom build with ZFS. I have files with creation times dating back to the 90s on my original FAT16 filesystem and I didn't want to lose them, so I recently did a (way-too-)deep dive on this, I'll summarize my notes for you.
First, ext4 actually does support creation times, called "crtime". But there's some internet confusion about it since this support predated linux kernel support, so you had to use ext4-specific tooling (on an unmounted filesystem) to access it, e.g.:
The btrfs situation is similar, but btrfs called it "otime" (for some reason?). Linux 4.11 introduced kernel-level support unified across all filesystems, calling it "btime" (birth time).
But the normal file syscalls only support reading btimes, not setting them to arbitrary values. And rsync on linux, as you saw, can't do anything the kernel doesn't have a syscall for. For a while the only option was to:
1. set the system clock
2. create a file (at which point the kernel sets btime to the system time, plus a few nanoseconds)
3. restore the system clock
Obviously a huge hack, and needs root, but tools like s-tar automated it (search for "time storm" in this manpage):
I almost gave up and spun up a Windows VM (since Windows has supported reading and writing creation times since the beginning). But then it clicked -- the kernel interface to the filesystem module takes the btime as an explicit parameter. So if you could find a kernel module that talks to the filesystem module directly (instead of going through the usual high-level file syscalls), you can pass along any btime you want. And there just so
Here's some corporate-lawyer-speak straight from Google:
> We are aware that Gemini is offering inaccuracies...
> As part of our AI principles, we design our image generation capabilities to reflect our global user base, and we take representation and bias seriously.
That doesn't back up the assertion; it's easily read as "we make sure our training sets reflect the 85% of the world that doesn't live in Europe and North America". Again, 1/4 white people is statistically what you'd expect.
Fuck, this is going to sound fucked up... but just because you have a 1/4 chance of getting a random white person from the globe, they generally tend to clump together. For example, you generally find a shitload of Asian people in Asia, white people in Europe, and African people in Africa, and Indian people in India.
Probably the only chance where you wouldn't expect this are in heavily colonized places like South Africa, Australia, and the Americas.
> Globally, it appears that much less than 1% (probably around 0.2%) of the proceeds of crime laundered via the financial system are seized and
frozen.
> the confiscation rate might be 0.07 percent. In other words, despite ubiquitous money laundering controls, criminals retain up to 99.93 percent of criminal proceeds.
that's like saying that nearly nobody robs banks so there's no point having so much security in banks. the real question is what would the figures be if there were no checks?
and KYC isn't only for money laundering, it's also for tax fraud
Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.
The internet's reaction to this has been so silly.
Jetbrains has for a long time included a set of optional plugins that are disabled by default and make HTTP calls to Jetbrains servers:
- Spaces
- Code With Me
- Shared Indexes
- their plugin authoring plugin
- (probably more I'm forgetting)
Now they released plugin #5+, that is also disabled by default, and also requires you to take a series of several explicit steps before you can enable it and use it, but this time everyone loses their minds? I feel bad for the engineers there.
> Curcumin is the primary bioactive substance in turmeric. It has anti-inflammatory properties, and there is decent evidence that it can alleviate various conditions, from chronic pain to depression. Curcumin has poor bioavailability on its own, and thus it is often combined with Black Pepper or with lipids.
I'm not sure how you got " it doesn't seem to do much"?
The very second reference on that page is to a paper by the fraudster. The first link is to a compound study of five studies, including one of the fraudster. The fourth reference cites Aggarwal as well, and no doubt the chain continues.
I can't tell how much of the linked effects are based on retracted papers (it's all members-only), but I wouldn't trust these websites too much until every dubious paper has been retracted and websites like these have been updated, if they will be updated at all.
Most scientific research into the substance seems to be based (at least in part) on Aggarwal's work, so in turn most of the research needs to be re-evaluated; that's a lot of tedious work, and I'm not sure if websites like these will have the manpower to do that.
There's always the mrustc[1] compiler that compiles Rust to C source files. So any platform that can compile C, can also compile Rust (with caveats of course).
Of course, this only means we could, it doesn't necessarily mean we should.
https://www.ifixit.com/repairability/smartphone-scores
> The battery is stubbornly glued down, and the soldered charge port can’t be easily replaced.
You have to take a heat gun to your phone to soften the glue to get the old battery out. Too little heat, the battery won't budge. Too much heat, you damage your screen or worse, ignite your battery. Good luck.