The reason why modern smartphones have such good camera picture quality is primarily thanks to the ISP profiles developed by teams of people for the particular sensor in use. ISP is an imaging signal processor, a component of most mobile SOCs that sits between the camera and the rest of the system. It is a proprietary component that is essentially a black box controlled with a "profile" for specific camera chip. The profile specifies how to debayer, denoise, sharpen, color correct, adjust brightness and autofocus of the chip. Without a very good profile even a good camera sensor output will look like crap.
I've spent few weeks of my (spare) time improving a Sony imx219 driver for a Rockchip rk3566 cpu that is used in few pine devices I own. I needed high fps video (I managed to get 120fps 720p - I think I could push it further to 140 perhaps, but this was OK for now) and as low latency as I could get. I wanted <20ms as I could encode 720p h264 frames in 7ms,unfortunately I got stuck with ISP (image signal processor) adding 40ms of latency even when in pass through mode.
The modern ISP is a "black box" even with source code for the drivers. In addition every single ISP has its own proprietary format for those profiles. There are OS projects that try to make universal camera sensor profiles that work with multiple ISPs (libcamera for one), but it is still early days.
What we need is a truly programmable/flexible isp. As it stands the only way to get sub 40ms of latency from a camera for a hobbyist is to use an fpga...
People used to make similar arguments about injket printer drivers (where the computer does dithering, head scheduling, etc).
Over time the open source crowd implemented the state of the art image processing techniques once, then pointed them at reverse engineered backend drivers for each model.
The result was better than what the manufacturers (especially HP, but also canon, etc) could do.
I'm hoping history repeats itself with these camera sensors.
The Pinephone Pro ISP is documented in RK3399 TRM (part3), and in various PDFs available online. It's not really a huge blackbox.
It does not make the calibration (or preparation of profiles for various light conditions) easy though. There's a need for a bunch of HW tooling that is somewhat expensive for a hobbyist. And there's a lot of work and algorithm design that needs to be done outside of ISP for controling the autofocus, autoexpsoure and detection of type lighting in the scene and profile switching. None of this is particularly trivial.
It's registers are documented yes, but from the point of how it actually works. How data flows, how it is buffered internally, how it is timed etc it is absolute mystery. Yes, you can configure various parameters, but you can't for example skip functional blocks and get data quicker. It is unknown if it is all done with hardcoded static logic blocks, some sort of purpose made vector cpu and firmware. No one knows(or those that do don't say).
I worked with rk3566, but I believe rk3399 has the earlier version of the exact same isp. The version in rk3566 is 1.1. There are also versions 1.0 and just 1. All are documented in TRMs in the same way.
Edit: BTW, if you need the tooling (Rockchips isp profile development tool v2.1 and the manual for it) please let me know and I'll send it to you.
> Edit: BTW, if you need the tooling (Rockchips isp profile development tool v2.1 and the manual for it) please let me know and I'll send it to you.
It's not usable for RK3399 version of the ISP. BTW the same/very similar ISP (to RK3399) is used in NXP SoC, and it has documentation there, too. (NXP docs tend to be better ;))
So they write a bunch of drivers and stuff for pine phone. As a pine fan I thank them, but this doesn't mean we can't have a difference in opinion what does it mean for some component to be a black box.
If you compare with some other manufacturer that gives us absolutely no docs, then yes having register level docs and user side source is really nice. But if you want to do something unconventional (like switch the whole damn thing off and bypass its latency) not knowing how it works internally is still a black box. For example there is an irq that fires when the first component of the isp(MI-memory interface) sees a vsync signal for a frame. We know it exists. We know how to enable/disable that irq. We can write code that does stuff when it fires. But what we don't know is is this vsync signal fired truly at the input of the ISP? It's output? Or perhaps between some specific components? It turns out that vsync fires not when the isp sees the very first vsync what the location of the registers suggests, but after all the processing is done at the output buffer (40ms later usually), but one wouldn't be able to tell without a lot of profiling. This amongst other things is what I call a black box.
However, compare it with let's say a raspberry pi, and at register level the documentation is much better (for the isp).
There are bunch of interrupt statuses around frame capture: RIS_FRAME_IN, RIS_FRAME, RIS_V_START.
Not sure why you'd decide to use V_START for deciding when the frame is in memory. VSYNC start is sent at the start of a frame and it's documented as just a interrupt that is directly triggered from the MIPI CSI sync signal in the datasheet.
quote: "The incoming hsync and vsync control signals from the camera are connected to interrupt
logic. It is possible to trigger on these signals for an event triggered configuration during
processing."
Parts of the ISP are blackboxes (debayer), other parts are quite trivial and documented in a bit more detail (gamma/degamma, BLC, color matrix transformation, etc.) and some parts are a bit of a mix.
The documentation is spread over many PDFs, incl. from different venors who use the same ISP like NXP, who tend to document things in a bit more detail.
Can someone dive more deeply into this? I'm asking because it seems to me that there is more to this than what you just described. Sony AOSP is constantly upgrading the kernel, but the camera is always mediocre at best.
If it was just the ISP there should have been a way in the past to take the ISP blob from similar chipset phones in the past and just use it with an updated base no? But that by itself doesn't seem to be enough to get the cam working decently.
People don't realise how much stuff the ISP does. It took me over a week to make an extremely basic profile for a new camera chip. And I had all the tools and the documents OEMs use. There is a 100 page long procedure I had to follow taking multiple pictures of calibration standards illuminated with various calibrated lights. Then at the end it still looks like crap, but it is pretty true looking. Then the work to make it look good really starts. I had no idea before I started.
There are simple things like debayer, but even just talking about exposure and gain control based on illumination is a pretty complex subject in itself. First you need to define parameters when to change exposure and when to leave it alone and just use camera gain. Then you need a set of parameters for when to use analog gain and when to use digital gain as communicated to the sensor. Then you have another two sets of parameters one for adjusting gain on the ISP (as opossed to all the previous stuff that feeds in to the camera chip) and some ISPs I'm told also have more advanced builtin correction based on curves. All this and we haven't even touched on how you measure the Illumination of the scene. At the very least you need one profile for back-lit and one for front-lit scenes. Then you need parameters for how the isp decides which profile to apply automatically and so on.
Mind that this is just brightness, we haven't even started talking about color correction, white balance, denoise, sharpen and 13 other ISP blocks that are there. BTW, you need another profile for every resolution your camera outputs too.
I don't know a lot about different ISPs. I only worked with one, but it gave me enough of an understanding to know why there is no way one profile will work for two camera chips. Or one profile will not work with two different versions of ISP hw.
That's why I hope libcamera succeeds. They try to standardise all the isp control, but it is a huge task especially when every single isp is different.
Well, with a camera port. Both the soquartz and Quartz64-A have csi connector for the camera. The pinout is such that raspberry pi v2 camera (imx219) can be connected directly to soquartz. However for Quartz64-A it requires an adapter.
Regarding my imx219 code that pushes it to 120fps I haven't submitted it upstream because the way fps is set changed in v5 Linux kernels. I used a v4 driver as a starting point because many other features only worked on v4(such as full gpu encode/decode etc). Also I preferred my userland side to not have to calculate timing parameters as it would require a per device implementation.
So my 120fps imx219 driver is for linux kernel 4.19 named rk3566_bsp_kernel-4.19, but I do have plans to upstream my code when I make them compatible with newest.
I really wish OP would try a distro other than Manjaro. But since they are, frankly, I am not at all surprised at stability issues. I do not think I have seen any of these issues on a non-Manjaro distro. For some more context:
Manjaro consistently applies incomplete and WIP patches into their builds, causing that sort of instability. Every time I have had a strange issue filed in a program I maintain, it has been traced back to Manjaro doing something like that.
Manjaro sucks. The thing is, it's really nice out of the box - frankly, it's probably the nicest OOB experience. Their desktop looks great and the layout switcher is cool. I also like the utility that lets you choose different kernel versions. The pamac package manager is great (if you ignore the fact that it has some problems with the way it works with AUR). Unfortunately, it has all kinds of problems under the hood that will eventually bite the kind of user Manjaro is trying to attract. It's a strange situation where one has to be familiar with Arch to understand why Manjaro isn't working.
IMO, Manjaro should take the Endeavour route and just use the upstream repositories. Manjaro does a lot right and brings some good ideas, but they are really lacking on the reliability and professionalism fronts.
I don't understand why these users all love pain. Use Ubuntu or Fedora and just be done with it. The further off the beaten path you go the more of a pain in the ass things get.
Android is steadily going downhill, even using older Android version on 3 year old device. I wanted to install an application from "external source", so I downloaded it from F-Droid and tried using Total Commander to install it, like I did some time ago (I rarely install new apps though, especially ones from external sources). And guess what? Total Commander removed install functionality, because of risk from being removed from Google Play Store. Just great, now this makes TC less useful and requires me to use Google's own "Files" application, which I had replaced with Total Commander...
Not to mention how Google Play app UI has degraded: now half of app updates screen is taken up by unremovable banner asking me to enable automatic app updates, otherwise I might "lose your right to make legal claims".
Not sure what the future brings, but probably even more limitations. My next phone will probably be a "dumb phone", and all saved money I will spend on decent camera.
I've had good luck so far with GrapheneOS. I still have Google Play but it only has normal app permissions, and it's in its own user profile that stays off unless I need to use an app that uses Google Play. I can install from external sources just fine, including the built in browser. Google Play Store is also an external source with Graphene's setup.
For years the first thing I do is install LineageOS (I only buy devices they support) and everything is remarkable stable, in terms of not crashing and usability. Most of my apps come from Fdroid.
Highly recommended. The irony is that Googles Pixel phones are great options.
> Total Commander removed install functionality, because of risk from being removed from Google Play Store. Just great, now this makes TC less useful and requires me to use Google's own "Files" application, which I had replaced with Total Commander...
I guess the Solid Explorer's dev isn't concerned about that, because it still has that capability today.
To test your hypothesis I just googled the articles Pixel 2 vs it's competitor iPhone 8. In both the top two search results the Pixel (narrowly) bested the iPhone, so looks like maybe a bit of rose-tinted brand-owners perspective in your case?
When I spoke of inferior experiences, I was referring to the Pine Phone, not the Pixel 2. I'm sorry that wasn't clear!
That said, the iPhone 8 is still supported by Apple (probably for the last year), while the Pixel 2, like the Pixels 3, 4, and 5, are no longer supported by Google. This likely doesn't matter to someone not running standard Google-supplied AndroidOS, though!
My use of the closed-source iPhone is not solely based on feature quality, and I've got no illusions that every feature is the best in class.
P.S. Just before clicking the reply button, I decided to do the search myself, curious. The iPhone 8 was a weird model; that was the year they released both the iPhone 8 and the iPhone X, because (IMO) they lacked the courage to switch things up in their flagship product so much in one year. (Okay, and maybe also supply issues?) Still, when I DDG'd "pixel 2 iphone 8", I got results[0] that seem to not be the same as yours. The first doesn't really make any determination, the second is mealy-mouthed but seems to give an edge to Pixel 2 based primarily on price ("the Pixel 2 is a better value, starting out at about $50 and £70 cheaper than the iPhone 8" vs "you'll actually get more bang for your buck with the iPhone 8"), and the third, well, it's right in the title: "iPhone 8 vs. Pixel 2: Why Apple Beats Google." So I don't know, I bought an iPhone X that year rather than an iPhone 8, and just replaced that with an iPhone 14 Pro this year after five years of faithful service. But choosing a 2017 phone today, either one, while very clearly a step up from Pinephone for all the of the reasons mentioned in the article, maybe still reflects a but of compromise in service of wanting to run LineageOS. In 2017, was photo quality the same when running LineageOS rather than Google's own camera software? Maybe it was after that they started to apply more and more AI to the photo-taking process, I'm not sure.
The pixel 4 is only losing support this month. Pixel 5 is supported til Oct 2023, and 5a til Aug 2024. Pixel 6 gets feature updates til Oct 2024 and security updates til Oct 2026.
So you realize how bad it is that a phone made by Google introduced in November of 2019 is losing support in 3 years? iOS 16 supports the iPhone 8/iPhone 10 from 2017 and the iPhone 5s from 2013 just got a security update August of this year.
And now fast forward 5 years and the iPhone 8 is still getting full OS updates and the Pixel 2 stopped getting basic security patches 2 years ago.
At this point I think I qualify as a career Android developer (did other stuff but just a lot of time on Android) and my joking reply to anyone who asks why I use an iPhone is:
> I'll switch back when Android can handle a screen rotation without blanking the screen.
The thing is, the fact there's no smooth rotation isn't literally a blocker, but it's what such a subtle thing represents: Android apps are still living with the complexity of a situation that showed up because of the limitations of the 256 MB of RAM the Android G1 had in 2008.
-
They're still doing this messy state restoration stuff where the OS essentially has to kill part of your app to support a basic rotation, they never went back and fixed it as phones matured, bad configuration change handling easily causes hundreds of thousands of crashes a day for end users, constantly throws a wrench in development that Google has had to invent many different catcher's mitts for, drains resources that would be better used on improving the user-facing functionality of these apps.
And this isn't the only feature like that. There are so many basic sharp edges of the OS UX-wise that will just seemingly never get fixed, and even if were fixed tomorrow, it'd be at least 6 years before those improvements represented even 90% of the Android userbase (something iOS tends to achieve within 12 months...)
[and before the nitpickers show up, yes you can override configuration changes and manage that for your own app... no it doesn't scale for any "normal" app]
Your device does it. These days it's hidden with clever animations so you don't literally see a blank screen, but the UI is being completely killed on each rotation.
Android will kill the user-facing portion of the process ("Activity") and recreate it* if you rotate the screen.
Devices have gotten fast enough to hide it with an animation, but it's still "kill UI, draw new UI". (specifically it's usually "render the UI to an image, squish it and rotate it, then show the new UI underneath".
My problem isn't with the literal animation, it's what that mess of rebuilding the entire user facing UI because they rotated their screen represents.
(* apps can opt out of this, but that's reserved for games and apps that render their own custom UI directly to a raw surface)
Not really? I mean maybe dumpsys window might give you a hint if the memory address of an activity changes, but it's not really an intended usage and I'm not sure it's fine-grained enough for that
The best time to fix it was before the G1 launched and the 2nd best would have been right after, but here we are more than a decade later paying for its sins.
I've seen it on older apps and ones I've tried to make myself. The app where it's caused me the most grief is in AndFTP where rotating the screen will kill any in-progress file transfers. I've learned to just lock the screen rotation when I'm using that one, which definitely shouldn't be necessary but also isn't the end of the world.
That's actually part of the (intentional?) design of the Android framework underneath. By default, if rotation is allowed, Activities (basically a "UI screen", but not exactly) are destroyed and recreated when the screen is rotated. If the data structures AndFTP uses to manage/track the download are stored in the Activity, then they'll be destroyed on screen rotation as well.
This is something you learn very quickly once you start building Android applications -- or, at least, I did when I started back in 2011 (I haven't done much Android dev in the past decade since then). While I do think this behavior is a pretty terrible default behavior for the underlying UI framework, it's pretty bad that the AndFTP developers have not fixed this bug in their application -- and yes, it is a bug in their application.
The UI development paradigm has changed quite a bit over the life of Android, making "Fragments" more popular to use in some quarters than "Activities" as the "unit of UI screen" (though Fragments are still underpinned by Activities), but I believe the fundamental issue is still there: if you don't explicitly handle rotation properly, and store state in your Activity, it will get destroyed whenever the screen is rotated.
There's a lot of insane things about modern operating systems. For example, some OSes don't even let you buy software without first paying the hardware manufacturer. Crazy stuff, we should really encourage regulators to bring these companies to their knees.
It's certainly crazy if you don't know better. The 48 billion in revenue the Play Store hit last year would tell you that regardless of security policy, people tend to use first party app stores on mobile.
But you know what? Maybe instead we should discourage people from clumsily trying to push their pet agenda the moment their favorite sports team (erm excuse me, Operating System) is painted in a poor light.
Some people are willing to make that sacrifice because their limited feature set doesn't impede on their day-to-day use. I know quite a few people who use their phone for nothing but texting, a camera, and two factor auth.
Hell, I, who would be considered a power user, spend 99% of the time on my phone browsing the web, Reddit, some Facebook, using a calculator, or taking photos. Most of my computing is done on an actual computer because the form factor of a phone just doesn't satisfy my needs.
The reason why I'm on Android instead of a iOS 1200 euro Apple device with fancy sensors is because I don't give a shit about making pictures or videos.
Exactly, Android has phones in the under 400 euro range.
I'm just not a cool person flashing expensive iPhone taking Instagram pictures. Drop the camera suite and image processing and you can cut half the cost of a smartphone!
What I actually want is mediocre camera, high build quality, small form factor. But I’m pretty sure there are not enough of us, so I have to go with medium cam, build, and size.
> In addition, it'll crash while taking or making calls.
Thanks for giving me flashbacks to my Hiptop days. I loved messing with the apps, and the camera. My friends pointed out that a phone that had a flip put keyboard and apps but often crashed while being a phone was not much of a phone. :)
Luckily the Hiptop crew went on to make Android, which got to be rock solid, eventually!
Unrelated to android, but I would just like to mention, that today best working implementation of linux on phones is Sailfish OS ( https://sailfishos.org/ - not connected with them all, but I use it as daily driver after years of searching; I was using angstrom distro on HTC Blueangel so you can imagine I have searched for long ). It would be really nice if the community would concentrate on one distribution instead supporting 674 of them and have none really usable.
I'm not an expert in the area and hadn't heard about Sailfish before, so I took a look and stumbled on this article [0] of Rosteltelekom (Russian national company) acquiring majority in the company Jolla that produces Sailfish OS, which makes everything about Sailfish a bit less enticing from a security perspective.
Another article [1] from a few months back says that Rosteltelekom owns about 45% and Jolla is trying to find another EU company to buy those shares, but didn't see anything more recent.
It works, which gives everything else that doesnt work a joke prefix.
I am not here to support Stallman style political warfare "who is more open source and less working".
I am just stating the obvious. Sailfish works. Everything else I have seen is a non working joke, that is unusable. Feel free to prove me wrong.
Not with bullshit, downvoting and PRing. URL please.
Not political BSing about which project is completely open source but no one sane would use as it is completely unusable. Which is actually the topic here.
Open source is great but < working phone (less than 10 years old), with usable front and back camera, 4g, phone calls that don't reset your phone, SMS messages that are actually delivered and... oh... ah... Bruce Almighty... working fingerprint reader.
We already have a "working" Linux distribution for mobile devices: Android. But what projects like Pine and Librem are trying to do is build an alternative that is 100% open source (or as close as reasonably possible) and does not rely on proprietary, third-party services. If that's not important to you, that's fine, but don't dismiss the progress that's been made. Some of us actually care about this stuff. :)
I'm also not sure how Sailfish is relevant to this discussion at all while Android exists and is the dominant (non-iOS) mobile platform.
A lot of problems obviously, many of which would be deal breakers for anyone, but the author expresses a strong emotional bias towards the phone. Unfortunately they don't say why, I'd really be interested in knowing what the advantages are of the phone that make it so loved despite all these issues. After all, some of us might be interested in having one as an additional device either for fun or as for the additional utility it might provide.
I too have a (fairly) strong emotional bias towards pine products. I can tell you why. For one, pine is the only manufacturer I know of that managed to obtain and release real down to register level documentation for the hardware they use. We have very comprehensive documentation from rockchip (a lot of it in Chinese, but auto translation tools are good enough). They publish schematics for everything. They let you download source code for so called "proprietary" drivers that work with old versions of Linux kernel.
All this means, for a tinkerer/hobbyist one can do stuff that is simply impossible on any other hardware that has comparable performance (basically modern 64bit embedded systems like those in newest mobile phones).
Then there is all the time we(hobbyists/devs) spend tinkering with this hardware. When one invests so much time into some product it is hard to just let it go.
However, having said all that I would never use an unfinished product as my main phone. If I had a pine phone I woukd probably carry it as a secondary, but those devices are nowhere near the state people can rely on them in case of emergency.
As a person that spends way too much time on these efforts[0], here's what makes the phone still worthwhile to me despite being slow and at times buggy: It's nice to be in an ecosystem that does not have ad frameworks, that does not nudge you into using iCloud or where you have to use Play Services (or invest time into building around not having them (and more than once, did that for years)) for apps to work properly.
(That aside, I have not had the problems OP describes - but the worst problems with PinePhone (outside of highly experimental software) I suffered through where with Manjaro.)
Why is the camera so bad? I know author says the sensor is bad but I suspect it is more than that. It amazes me to see what raw images look like coming off a CCD and then what software stacks like the one in the iPhone (and apparently Pixel) will do to get such an amazing final result.
I think there is a lot of secret sauce that perhaps is lacking in the Pine software stack.
Definitely, the GNU/Linux software stack needs improvement for everything that's not a UVC Webcam. libcamera is a relevant project in that context. Purism, who make the Librem 5, are working on that - they have a paid team, but it's small so this will take a bit.
That said, the PinePhone camera app, Megapixels, recently got better post-processing thanks to postprocessd, which may have landed in OPs Manjaro or not.
1. For profit companies are in business to make money, not “market share”
2. Having access to the premium market is important enough to Google for them to pay Apple $18 Billion a year to be the default search engine on Apple devices
3. Do you think developers are advertisers care more about “market share” or who has disposable income?
1. For-profit companies are easier to hit with antitrust regulation than a variety of competing manufacturers.
2. Airing out Apple and Google's dirty laundry doesn't make either of them look good. If anything, it just confirms that Apple is hopelessly addicted to advertising/promotional money and is willing to put a price on degrading the user experience and giving Google access to your data.
3. Developers care about money, same as Apple does. Long-term, they will not invest in a platform that fleeces them in one hand and exploits them with the other. There are dozens of pain-points where this is showing it's face (payment-processing, app distribution, browser control, file control, background process control, entitlement documentation, double-standards/undertable deals with FAANG, etc.)
Even the web is a smarter target than a native iOS app, because at least you get to keep your profits. That's why the web is winning.
1. ...a variety of competing manufacturers who are either running a single operating system with a single defendant, or are a rounding error in market share, profit, or any other way one cares to slice it.
2. Setting Google as the default, and easily changed, search engine does not equate to giving Google access to your data.
3. How long-term are we talking about? Because since 2008, 14 years so far, most investment seems to have been made into the iOS App Store, with more than $260 billion[0] paid to developers so far.
The web is a great target platform, I'm glad we agree! You give up a lot in terms of discoverability and potential promotion, and you have to do some extra work to manage payments and so on, plus you have to overcome the natural distrust for paying a new vendors, but you absolutely do get to keep 100% of whatever you can convince people to pay you, for sure. Or even better, don't charge! That's why the web is... an alternative that isn't losing, let's say.
For #2 what would the alternative be? You definitely don’t want an Apple search engine to replace Google’s it would be a much worse experience. Although Apple does have its own search engine powered by AppleBot that is used in some parts of the interface.
But it’s not a general purpose search engine.
> Even the web is a smarter target than a native iOS app, because at least you get to keep your profits. That's why the web is winning.
This is a horrible take. It came out in the Epic trial that 80%+ of App Store revenue came from games an in app purchases from “whales”. Not the poor little Indy developer.
Most of the popular non game apps don’t even allow in app purchases like Netflix and Spotify and others allow you to purchase the service either in or out of the App Store
I think the reason parent leaned on that sub-group is that it is easy to move a lot of units at the very low end with minimal or even negative profit, and that was definitely Samsung's (to name one company) approach in years past. They would sell many, many Android phones at something like $100 each, in some cases losing money on every sale, and very, very few of the higher-margin profitable phones that most people on HN think of when they think of Samsung Android phones.
That's how, for example, iPhone accounts for 75% of all profit in the smartphone market worldwide, despite a low 13% market share[0].
When it comes to the big numbers, most people aren't really comparing Apples to apples.
> I don’t know if it’s Apple propaganda or just like a tribal in-group versus out-group thing going on, but people don’t seem to like green text bubbles that much and seem to have this visceral negative reaction to it.
I am not a teenager and I do not care about status symbols, but I too have an immediate negative reaction to green bubbles. iMessage Internet-based delivery system is just sooo much better than an SMS one. “Message failed to deliver, repeat?” - what’s not to dread here.
Journos though seem to constantly ignore technical, engineering differences between solutions which make people prefer to use one or another. Probably conspiracy theories sell better.
Nobody uses iMessage or SMS outside of the US. If those are the only two ways someone communicates on their phone, you can guarantee they don't have any international friends.
It hasn't won at all. One reason I use Android is because it has apps I use that don't exist on iOS. File explorer, h/w accelerated video player w/ codec support, manga reader, etc.
iMessage doesn't mean anything to me anymore. Apple waited too long and didn't open it up when they should have, same mistake BlackBerry made.
One reason I use Android that has no viable replacement on iOS is call recording. I deal with government officials a lot and I want to hold them accountable (I live in a nation with one-party consent laws, in the sense that I only need my own permission to record a conversation).
iOS will not let you do this natively, you have to add a call recording service via a three-way call whereas I can do this out of the box with /e/OS on a Fairphone.
This is one of the best reasons I've ever heard for not running iOS.
I completely understand why Apple won't allow it from a third party: that's a security and privacy nightmare.
I even somewhat understand why Apple hasn't developed such a feature themselves: it's a very minority use case and has some legal concerns in some jurisdictions.
But the end result is, yes, iOS is not for anyone that needs to record calls like that.
That is the question of the ages, many cheap things or fewer expensive things. Problem is the cheap things get better and better until the only reason you stay on the expensive thing is they're actively trying to lock you in in a desperate attempt to keep their marketshare
Well, you’re not the first person to get this wrong. Clay Christenson, the author of “The Innovator’s Dilemna” and the person who came up with the entire theory of “low end disruption” said the same thing about the iPhone in 2007.
But Apple has been selling electronics that cost more than its competitors since 1980.
And they only almost went bankrupt a few times. Rolex has been doing the same thing.
If they don't want to sell to everyone, that's fine, but if most people can't afford your product, you're not going to win the market by definition. They could sell their phones for way cheaper, but they don't want to, why? Because less profit.
For a for profit company, profit is winning. “Market share” never paid a bill. There is a reason that Apple has been one of the three most valuable companies in the US since 2011.
They almost went bankrupt once because:
- supply chain issues: they thought that users wanted low end Macs and they manufactured too many of them and not enough high end Macs. Everyone agrees that Apple now is the best in the world when it comes to managing their supply chain
- the processors they were using were behind performance wise. It was hard to compete when Apple was only selling a few million Macs and Intel could throw money at performance thanks to having the entire PC market. Now Apple sells about as many ARM based devices as the entire personal computer market (not including servers) and has higher margins to invest. Again no one is saying that Apple doesn’t have the best processors.
- the operating system was far behind the competition. That’s definitely not the case now. Apple has shown to be far more nimble than its competitors.
- there was a dearth of software for its platform. Now that’s definitely not the case except for computer games . The PC gaming market is small and declining.
- They didn’t have any cash on hand. Apple has $200 billion in cash now and it’s doing all it can to throw off cash via stock buybacks and dividends. It could easily have more if it saw that it needed it down the road
The question behind the question is can a closed ecosystem survive? Will the open competitor replace it over time? The closed ecosystem company always has to invest more money because it's not shared between multiple other companies.
If the latest iPhone doesn't have the feature you need, you have to leave the ecosystem
Amused to see that Microsoft is releasing a new product to cache Microsoft updates for Windows users, that runs in Linux on Docker
Having 70% of the profits in the phone market, with Samsung being a distance second and the rest of the manufacturers scraping by, I would say yes.
> The question behind the question is can a closed ecosystem survive?
You realize that Macs have survived along side Microsoft based PCs for 40 years? For 26 of those years (1984 -2006 and 2020- present) even using a different processor?
> Will the open competitor replace it over time? The closed ecosystem company always has to invest more money because it's not shared between multiple other companies.
You realize that Apple has more money than all of the other “multiple companies” combined? Who has the money to invest in processor research and manufacturing (Apple invest billions in TSMC for its manufacturing capacity).
Apple has been ahead processor wise in mobile for over decade and now is ahead in personal computers.
I've spent few weeks of my (spare) time improving a Sony imx219 driver for a Rockchip rk3566 cpu that is used in few pine devices I own. I needed high fps video (I managed to get 120fps 720p - I think I could push it further to 140 perhaps, but this was OK for now) and as low latency as I could get. I wanted <20ms as I could encode 720p h264 frames in 7ms,unfortunately I got stuck with ISP (image signal processor) adding 40ms of latency even when in pass through mode.
The modern ISP is a "black box" even with source code for the drivers. In addition every single ISP has its own proprietary format for those profiles. There are OS projects that try to make universal camera sensor profiles that work with multiple ISPs (libcamera for one), but it is still early days.
What we need is a truly programmable/flexible isp. As it stands the only way to get sub 40ms of latency from a camera for a hobbyist is to use an fpga...