> Someone decided to trash the one part of Windows that was usable? The file system is no longer usable. The registry is not usable. This program listing was one sane place but now it is all crapped up.
This is so true, and not only under Windows. Install any modern program under any modern OS and have a look at the filesystem, it's a flaming mess.
Nowadays the only solution "smart people" have found is to install a complete system, complete with libraries and frameworks, for each program.
One of my "santa's not real" moments of computing was realizing how much static and dynamic libraries fucking suck. This cannot be overstated, and is illustrated perfectly by the heroic efforts of software vendors to get away from them.
Okay, a few functions like fopen are fine - but even those are syscall wrappers IRL. But every OS seems to have concluded, that in the place of API calls, one should rather have streams of text (UNIX) or binary messages (Windows, also a bunch of Linux desktop stuff, like Wayland), or File I/O.
Basically a major motivation behind JIT langauges (C#/.NET certainly) was an effort to get away from dynamically linked libraries,
Even DOS didn't really have libraries, you had peripherals mapped to memory at certain addresses, and a set of interrupts, and that was it.
These single file Go and Rust programs read and write stdio and/or network, which is a reasonable solution to a lot of problems, but certainly not all of them, especially in the interactive space.
That's why I like the "managed" model Debian uses. Programs are enforced to comply to the OS standards. If they don't, they either get changed by the Debian maintainers or just not included into the distribution. That's why I can know where things are in my filesystem.
The difference in complexity between my go and my Python docker image is actually hilarious. 100s of files and package managers and npm and whatever else.. vs 1 file.
Not in the Alps, but mid summer looked like the start of autumn. At this rate, it won't be long until we don't even have an autumn like the tropics.
Swiss Tourism Agency will have to work overtime now promoting Tiktok clips and Insta reels, because of Rösti's stupid policy. And the country is going to pay for it over the next few decades.
Pixel 11 has an incremental upgrade to the CPU, the same underpowered GPU and less RAM for the base Pro models. It has a new major version of the secure element (Titan M3) which likely greatly improves Before First Unlock state security for users without a strong passphrase. It has a better radio from a performance and efficiency perspective but it's still a more than yearly generation behind Qualcomm. The cellular radio firmware is also likely a security downgrade but the userspace code is more secure due to moving to AOSP IMS code. If these devices hadn't removed MTE, then they would have been a sidegrade with marginally better security. Removing MTE ruins these devices for GrapheneOS. We could still support the Pixel 11 series but it would be greatly rolling back overall security to before the Pixel 8. It does at least have PAC and BTI but MTE was the main improvement with the Pixel 8 rather than those.
You keep repeating this everywhere but this is just plainly wrong. They went from an old big.Little (with middle cores) arrangement that everyone abandoned for flagship chips generations ago, with core arches that were 2-3 generations behind competition, to a modern, up to date arrangement. There's literally nothing newer that they could've gotten from Arm, and other CPUs are releasing with C1 generation.
And I don't get your angle on the GPU. GOS is not gaming oriented, Pixels are not gaming oriented, and never were. They have a decent NPU to handle AI, a decent ISP to handle cameras, what more do you need the GPU for? Why would they put in a PC grade monster like Qualcomm?
Same for the modem, it's well known that Qualcomm are way ahead of the game, but they also charge like crazy for their SOCs and are a horrific partner to work with. They treat clients like shit, I get why Google ditched them when they were able to.
And you keep recommending P10 when it's genuinely a non improvement over P9, with worse battery life and running hotter, and the same modem. What the f is your angle? Is Micay back to GOS?
The CPU is 10-15% faster, that’s incremental in use even if it’s technically interesting.
Lots of apps and websites only run smoothly on newer GPUs, too. You can play the “they’re dumb and I just won’t use them” game, but not everybody has your priorities, and it’s a relevant factor either way.
The modem comment, likewise, is simply correct, and evaluating performance is good even when shortcomings are understandable.
They supported Pixel 10 because they supported every new Pixel that wasn’t a security downgrade and shortly preceding a better alternative. The logic isn’t “performance bad therefore no upgrade”, it’s “no upgrade for a bunch of other reasons, and it’s not like we’re missing out on a 3x performance improvement”.
> Lots of apps and websites only run smoothly on newer GPUs, too.
GPU is barely used in non-3D applications. My OP15 runs normal apps and websites just as well as my Pixel 10 Pro did. Speedometer 3.1 returns 10% higher scores in favour of the OP, even though it has the latest and greatest qcom chip.
UI experience is all about scheduler tuning, drawing pipeline optimizations and (to a much lesser degree) single core performance. Anything above Cortex X1 can have perfect 120 fps anywhere, without a major energy penalty, if the software is well optimized. I know because we did experiments like that when I was still doing custom Android kernels.
Not a single time did we need to do anything to the GPU, most of the time it's in 2D clocks and never wakes up.
> They supported Pixel 10 because they supported every new Pixel that wasn’t a security downgrade and shortly preceding a better alternative. The logic isn’t “performance bad therefore no upgrade”, it’s “no upgrade for a bunch of other reasons, and it’s not like we’re missing out on a 3x performance improvement”.
Not my question. I get why P10 was supported, I don't get why it's recommended by the person running the account, when it's objectively just a more expensive P9 with worse battery life and running warmer.
Pixel 10a is the most recently released recommended device. It has the same SoC as the 9th generation Pixels with a far better cellular radio than the Pixel 9a.
Pixel 9 to Pixel 10 had a bigger incremental CPU upgrade than the Pixel 10 to Pixel 11. GPU was initially a downgrade due to poor drivers but that was resolved already.
Pixel 10 has various small but significant security advantages over the Pixel 9. Pixel 11 would similarly have small security advantages if they hadn't ruined the overall security by removing MTE.
We definitely do want better CPU, GPU and radio performance for flagship devices and haven't been happy with those on Pixels. It doesn't outweigh security updates and security features but it matters to us. We're going to be a lot happier with a next gen flagship Snapdragon SoC for many reasons.
Getting a 15% increase to CPU performance is an incremental upgrade to the CPU performance. We expected a much better improvement from the new CPU architecture. It's quite disappointing and the removal of MTE support is even more disappointing. Using HWASan instead of MTE would have around 2x CPU overhead, 25% memory overhead and would not provide nearly as much of the security benefits due to only working for code instrumented with it. Compared to doing memory tagging using HWASan, decent MTE support is an incredible performance boost.
GrapheneOS works well for running games and people can toggle off hardened_malloc and MTE for a game to eliminate nearly all of the performance difference. It doesn't usually make any noticeable difference. GrapheneOS is intended to be fully usable by everyone including people who care about GPU performance whether it's for games or other apps. Claiming GrapheneOS isn't gaming focused is your opinion. We care a lot about compatibility with games and have put effort into it. Pixels using a GPU with poor gaming compatibility and performance wasn't our choice and doesn't mean we don't care about it.
> and the same modem
Pixel 10a has a drastically better cellular radio than the Pixel 9a. The 'a' series Pixels are consistently the most popular devices supported by GrapheneOS. Pixel 10a is still the latest one so there isn't going to be any gap in people being able to buy a new device for GrapheneOS if we don't add the Pixel 11 and instead skip right to Motorola flagships and then more Motorola devices. We hope the Pixel 12 adds back MTE support but aren't optimistic.
> back to GOS?
You're directing abusive comments towards our team based on highly inaccurate harassment content.
IMO they peaked with the Nexus 6 - camera has gotten worse and they make up with it in software or try to. You could and can see this at night or stacked shots in N6 vs pixel 4,5,6.
They bought the best phone hardware and software companies (Motorola and Android) and gutted them both.
They purchased Motorola Mobility for the patent portfolio as essentially a nuclear deterrent against Apple and then sold it to Lenovo. They're doing quite well internationally but haven't been a big brand in the US for a while. Their flagship phones are going to have GrapheneOS as a selling point soon and we'll hopefully be able to expand beyond the high end over the next couple years.
> They purchased Motorola Mobility for the patent portfolio as essentially a nuclear deterrent against Apple
By Apple, you mean Microsoft.
The early Android device makers had to pay a per device patent licensing fee to Microsoft.
Google sued Microsoft for massive amounts of money using video standards essential patents they purchased from Motorola, but it didn't work out well for them in court.
Apple was actively going after Android OEMs including Samsung too. We did mean Apple but Microsoft was also relevant. The point was that they primarily bought Motorola Mobility to strip mine it for patents.
The company that Google targeted with their Motorola patents was Microsoft.
Google sought to ban the sale of Microsoft products that used the H.264 video standard on a global basis if Microsoft didn't hand over a literal fortune.
> Microsoft and Motorola are embroiled in a legal spat around the world over the software giant’s alleged use of Motorola industry-standard H.264 patents in its many products. Motorola has argued that Microsoft has used the technology illegally and should have its products banned until it licenses them.
Motorola says that Microsoft should pay $4 billion for the use of its technology, applying a 2.25 percent royalty based on product price.
I have my parents and in laws running Moto phones. They hold up well, are well built, just no big flagship phone that I'm drawn to. I like their flat screens, SD cards, headphone jacks, all that good stuff. I think their cameras are getting better now too so that'll probably tip me over with the icky new Pixel 11's
I had the Galaxy Nexus (Samsung) and the Nexus 6. I may have had the Nexus 4 or 5, I dont remember. I had a few HTC phones before that and the DROID by Moto before that as my original smart phone. The DROID was peak - I miss the slide out keyboard.
...have you tried any of the cameras from the last 5 years or just the pixel 6? My 11 pro's cameras are by far the best cameras I've ever used on a smartphone, my previous iPhone included.
Have you seen the raw images you get out of those cameras? They're still the same grainy low res webcam sensors they were 10 years ago (if not worse), most of the improvement is just AI hallucinating details.
RocksDB’s default is WriteOptions.sync = false. It can lose recent acknowledged writes after power loss, much like TurboKV Durable. Most folks use that unknowingly.
While it’s important to make this explicit, at what point do we just assume a high-reliability UPS is table stakes?
Of course, if you need SIL2 type reliability then you need to assume any given hardware component can spontaneously combust and become a total loss, at which point the data loss caused by a power cut is a rounding error.
> While it’s important to make this explicit, at what point do we just assume a high-reliability UPS is table stakes?
Several years after they become commercially available?
My experience with small UPSes is they tend to cook the batteries and you don't find out until they switch the load and the battery doesn't hold up.
Large facility UPSes tend to do better, but automatic transfer switches have a tendancy to fail ocassionally. If you're hosted in many locations, it's not unusual to have a couple ATS failures per decade.
All that said, unexpected power loss is certainly one reason that writes may be lost, but OSes crash too. Disk firmware can also crash, but if thst bricks the disk, writes in progress don't really matter. Sometimes cabling fails. Or you get a uncorrectable ECC error (which will typically cause an OS panic... unless you're running a very fancy OS, but if it's in dirty disk backed page, even a fancy OS wouldn't save you)
Plenty of applications don't need or want to pay the cost for full commit to disk, but calling something durable when it's not committed to disk is inaccurate.
And that's before we get into the whole thing where the OS and the disk like to return success when things haven't quite finished.
Not sure how you managed to do it but you got it completely backwards.
If someone demands that the database should use fsync and only respond with success once the write finished, it is not some arbitrarily high reliability demand that needs to be implemented using reliable hardware. In fact, the entire point of implementing the power loss protection in software is so that you don't need perfectly reliable hardware. The power loss event turns into a downtime event which is often completely acceptable.
The requirement to have infallible hardware only emerged because the software refused to do its job. Infallible hardware is not a requirement decided by the user, it's a requirement decided by the developer of TurboKV to intentionally restrict his software to exclusively operate in a reliable hardware environment.
The fact that the user specified durability of the KV store during power loss does not make the user obsessed over hardware reliability, the software shifted the burden onto the hardware and forced the user to deal with this mess.
I don't know how exactly TurboKV works so let's talk about a hypothetical software instead.
Let's say the software cannot survive a power loss event and just corrupts the database. If the user wants to operate the software, he is forced by the software to operate it in an infallible environment where power loss can never occur. Based on how the software was designed, power loss is a catastrophic event. The SIL2 type reliability you're talking about only makes sense in contexts with catastrophic events.
So how it went is that the user made a reasonable demand with bounded reliability: "please survive power loss with durable writes" and the author says, sure just run the software on a SIL2 type reliability hardware environment.
It's not the user who blew up the hardware requirements.
reply