Teenagers figure out how to hack locked down consoles, which are hostile to make money.
All it will take is someone to make a fediverse chat that can be simply stuck on a Pi from a premade image, and automatically runs a script to update the DNS with their IP and the kids will do it.
Someone will make it easier. All the stuff you use today used to be a lot harder and more complicated than it is now. People worked to take the difficulty off, usually because they wanted to do the same thing and the difficulty annoyed them.
> letting that effort linger till display tech catches up to whatever Apple is waiting for, would feel like a waste perhaps.
To add to this, it's often said that research can only take you so far, at some point you have to ship something to get the opinions and hands on from a wider audience of users to make further discoveries and improvements.
> Working with the kernel has been extremely disruptive to bcachefs development and the community
From an excited and hopeful potential future user looking in, this sounds like "working with <insert only grocery store in town> has been extremely disruptive to me selling my produce", there's nowhere else your customers can realistically get your product, unless you want to only sell to extremely picky customers who will make the hour long trip out to your farm and back.
> I do not strictly need bcachefs to be in the kernel.
But I (and your other users) do...
I shouldn't be weighing in, I'm a lightweight with no skin in the game here, just a regular (very technical) user. I guess I just want you to know that your product has many people that want to use it, but even I won't drive to your farm for it, as I can't risk a Linux-update breaking the DKMS-modules that make my system able to use the bcachefs filesystem all my data is on.
I don't know what possible avenue we have of getting bcachefs back into the kernel and maintained, but I hope you find it, whatever it is.
I'm not trying to do this as fast as possible and get it out to every single user as fast as possible
That's tech industry thinking; that is what btrfs did :)
In the long run, slow is fast and wins the race. Being in the kernel would have been great if it grew the development community, but instead the opposite happened - it drove people way.
The important thing is to get it done, with all the reliability and hardening and features that people want. There's no reason it can't go back in later.
I mean I've read a lot of what you've posted everywhere, and I can't really say I disagree with much of it, it's just a shame it all happened the way it did.
Hope "go back in later" isn't too far down the line, I have 10x8TB spinners, and 4x2TB NVMe disks that I'm looking to move from md-raid + BTRFS to something else, and I really want that to be an in-tree filesystem.
Which hurts so much because it truly seems amazing from so many perspectives, and I admire Kents dedication to it. I was extremely excited to make a large bcachefs filesystem, with RAID6-like redundancy, foreground NVMe disks and spinning rust as background storage, and it seemed to be in the near future too, but now it probably won't happen at all which makes me incredibly sad for us all.
> And you sure as hell don't have primadonna developers stay in the payroll for long if they start throwing tantrums and personal attacks towards fellow engineers when they are asked to follow the release process or are called out for trying to sneak untested changes in mission-critical components.
You've obviously not been in this industry for very long, about half the places I've been to have had at least one "rockstar developer" that was actually quite mediocre but had the ear of management which thought they were all that and as a result got to do whatever they wanted.
Depending on how degraded the original battery was it isn't necessarily placebo. If iOS detects a severely degraded battery it will clock down the CPU slightly to cope with it, sacrificing a little performance to keep the device stable.
With 3rd party batteries it can't do this, so it doesn't (I think, will admit I'm not entirely sure exactly how iOS deals with 3rd party batteries it can't determine the status of), and if you replaced it with an official part then it would have been in good condition, so regardless which road you took, it's possible that you went from a state where the OS was clocking down, to one where it wasn't anymore.
> If iOS detects a severely degraded battery it will clock down the CPU slightly
I currently have this problem (iPhone 11). It's not slight at all. Keyboard inputs sometimes has up to a full 1000ms latency and that's with autocorrect, suggestions, and spellcheck turned off. Scrolling in most apps are jumpy rather than smooth. When this phone dies, I don't know what I'll get. Hopefully a good linux phone exists by then.
That’s also a 6 year old device man, it is amazing that a device with such an old battery is still running at all, I presume its been a daily driver all this time?
The problem is not the battery, it's the battery, processor and price.
The iPhone 13 Mini made up around 3% of total iPhone sales, so there's clearly a market for compact, mid-range phones ($600-$700). You can manufacture them in China or India for somewhere between $250 and $400, depending on the battery, camera, and overall performance.
The real challenge is that the retail price of a mid-range Android phone can't go over the $500 mark. People in developing countries are always stuck trying to balance quality with price. And for $500 bucks they expect a prime phone nowadays.
reply