Readit NewsThese aren't the words of a human – they're the words of an LLM
It just distracts the discussion away and adds nothing.
Deleted Comment
For any RFC, there will be a "comment" after publication from someone who did not take earlier comments seriously enough to read them.
Mind boggling
Personally I also question the practicality or usefulness of this table because why should I care about having "the best unicode support"?
Curious, I briefly compared top ranked emulator (ghostty) on how fast it can print 10000 lines and it took 432ms compared to alacritty, ranked 18 (50ms), and Terminal.app, ranked 29 (50ms). If this is the trade-off to have the best unicode support, why should I want it? Why does it matter?
Deleted Comment
I don’t see the state file as a complete downside. It is very simple and very easy to understand. It makes it easy to tell or predict what terraform will do given the current state and desired state.
Its simpleness makes troubleshooting easier: the state files are easy to read and manipulate or repair in the event of a drift, mismatch, or botched provider update.
With the solution proposed it feels like the state becomes a black box I shouldn’t put my hands in. I wonder how the troubleshooting scenarios change with it.
Personally, I haven’t ran into the scaling issue described; at any given time there is usually only one entity working with the state file. We do use terragrunt for larger systems but it is manageable. ~1000 engineer org.
Maybe I'm unique, but nowadays 99% of my phone time is spent in a browser. If anything, it seems easier now to get something like this going because all you'd need is a bare bones UI and a good web browser.
Sure, it's not competitive with a Samsung foldable, but he I've gotta start somewhere...
I do sort of wonder if an x86-based phone is at all a reasonable prospect. It seems a bit weird to go backwards but at least they've sorted out the generally open ecosystem part XD. Power consumption is 99% about the software anyway.
Very good question; what's holding us back really? If we want an open phone there should be more discussions on this. Some thoughts aided with chatgpt:
Easy: get display, sound, cellular, sensors, inputs working
Harder: (efficient) Power management, App ecosystem: distribution, SDK, compatibility, (tight) Privacy controls, (robust) Update delivery system, (vast) Hardware support, Backward compatibility, Accessibility, Localization, Customizability, Camera (apparently)
Beyond tech:
Proprietary hardware drivers: how do you get the hardware manufacturers' commitment to allocate their engineers to write drivers for the open phone system? Reverse engineering requires more effort and is not very sustainable.
Carrier requirements: Supporting and testing emergency services, lawful interceptions, certifications, possibly differing requirements for each carrier and regions.
Regulatory compliance: Constantly changing requirements by nations and geographical regions.
--
Reading from the other comments, power management seems very hard to get right.
The non-tech reasons seem to be the most challenging; it introduces the most complexity and it's not exactly something that can be achieved by a passionate person in an evening
Deleted Comment
Seemingly effortless comments yelling to the void not worth starting a conversation with. Not the kind of comments that belongs or are wanted in this platform.