[HN Gopher] Fairphone suggests Qualcomm is the biggest barrier t...
___________________________________________________________________
Fairphone suggests Qualcomm is the biggest barrier to long-term
Android support
Author : thg
Score : 392 points
Date : 2021-03-26 15:30 UTC (1 days ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| rektide wrote:
| worth noting that there has been really good progress reverse-
| engineering support for 2017's Snapdragon 845[1] (SD845). quad
| A76 + quad A55 on Samsung 10nm. pretty modern, all in all.
|
| generally i still feel tortured by the situation, by highest of
| high tech devices being unsupportable, unmaintainable after a
| couple years, and it seems like upstream support is the only
| available path to keep devices from turning to e-waste. however,
| there are some positive signs. most chips still have seen nearly
| no support from the chip makers, but we have seen, for example,
| Qualcomm land some additional support for some additional the
| SD845 gpu, for which reverse engineered support had already been
| nicely developing.
|
| we're also seeing more phones with Samsung, MediaTek, & some
| other chips. it's notable that none of the other chip makers have
| much of a presence in kernel upstreaming either. it's not just
| Qualcomm: everyone is very bad at making mobile devices able to
| be supported.
|
| i'm very interested to see what starts happening with cars, which
| face a similar supportability problem, but which are less
| disposable. long term kernel support has been extended greatly to
| enable a longer life. Google's Project Treble has created a
| device-driver abstraction layer to try to ease things along some.
| but it's very hard to imagine the sea-change necessary for
| commercial teams to take their work, & rebuild it, safely,
| successfully, easily, atop the complex drops of vendor code &c.
| chip makers have had an enormously difficult job supporting the
| teams making software, providing them updates that they can
| readily begin to use, and it's been a very conservative, slow,
| deliberate process. most technical folk seem anxious to shift the
| mode, to get more upstream support, such that kernel & system
| upgrades don't require carefully tailored support packages from
| the chip maker to make updates possible. the current pace feels
| very logjammed, there's so much custom code people shipping
| products rely on, and trying to make folks less critically
| dependent is such a powerful compelling vision for so many
| techies to improve supportability, to make updates shippable both
| faster & doable in the long term.
|
| [1] https://en.wikichip.org/wiki/qualcomm/snapdragon_800/845
|
| [2]
| https://www.phoronix.com/scan.php?page=news_item&px=Qualcomm...
| floatboth wrote:
| SD660/630 too:
| https://github.com/SoMainline/linux/tree/SoMainline/v5.11-rc...
|
| Not many device trees written yet (really only Sony devices)
| though
| traverseda wrote:
| Isn't this (binary blob drivers) an obvious violation of the
| linux kernel's GPL license?
|
| I presume that there's a good reason why that isn't being
| enforced, but I would like to better understand why.
| bayindirh wrote:
| There are intentional loopholes left in the kernel to allow
| such drivers (Nvidia, fglrx, etc. are also closed source).
|
| There are some rules though: Kernel module is always open
| source and cannot use all the symbols. Also, using such driver
| marks the kernel tainted.
|
| There are some very valid reasons for not releasing open source
| drivers. NDA bound 3rd party code is one (Java had it, fglrx
| had it, HDCP stuff has it, Intel's old GPU drivers had it).
| Another reason is software based secret sauce. Again GPU
| drivers are the worst offenders in this class. Third reason is
| greed/being insecure. Lastly, some companies use this method to
| _effectively deprecate_ their products, so they can sell newer
| units more. Embedded space is the biggest example of this. I
| also worked with such vendor in a very unrelated product
| category. It 's unpleasant.
|
| I don't support any of these reasons, but I understand them
| from an economic sense. Some companies started to bake their
| magic into their hardware (Mellanox, AMD), so they can open
| their software completely. This is a much better path IMHO.
| AnthonyMouse wrote:
| The sad thing is that all of the "reasons" are really only
| enabled by a lack of competition.
|
| Customers want devices with in-kernel drivers. Not just
| curmudgeonly Richard Stallmans who care about the plight of
| the wild libre, but Joe Sixpack who just wants to be able to
| keep using the phone he likes instead of having to buy
| another one every other year. There is a market for that.
| Regular people would choose it on purpose.
|
| And it's not being satisfied because Qualcomm keeps buying up
| their competitors. Because they dominate the Android market
| and the incentives of an effective monopolist are different
| than the incentives of a competitive market.
|
| If you're one of five equally-sized chip makers, you don't
| care that the customer isn't going to buy a new phone for ten
| years instead of three, because with high probability they
| could buy from one of the other four next time anyway. And
| because you need a competitive advantage to get the sale
| today, and "don't have to buy a new phone after three years"
| is that.
|
| If you're Qualcomm, you get the sale even if you don't offer
| the advantage because there is no viable alternative, and
| then you get another sale in three years.
|
| Time to break them up. Or at least, and I mean come on, stop
| letting them buy their competitors.
| monocasa wrote:
| For the most part, yeah, the closed source kernel blobs are
| blatant GPL violations. I've heard a cute legal theory as to
| why Nvidia's GPU blobs are at least grey area, but most of the
| other blobs don't follow that model.
| phh wrote:
| In the Android smartphone world, most big OEMs abid by the GPL
| properly, with nothing closed source in kernel.
|
| But if you have bugs either in other processors' firmware, or
| in userspace binary libraries, kernel's GPL won't save you.
|
| One could say that userspace binary blobs are meant to
| circumvent the GPL, but I don't have that feeling: GLES libs
| are userland just like Mesa, modem is userland just like ofono
| It looks like userspace/kernelspace separation is pretty much
| the same between oss world and android smartphones' proprietary
| world
| nanna wrote:
| Congratulations to Fairphone. This sounds like a massive task
| especially for such a small team. I run a Fairphone 3 and I
| couldn't be happier. Sure it was on the pricy side but it's
| served me well, takes great photos, has survived numerous drops
| (the phone protector shipped with it is great), looks
| cool,strikes up interesting conversations now and then, and will
| apparently have Android updates well into the future. Fairphone's
| a great company shipping a great product. Well worth the
| investment!
| imiric wrote:
| It's a decent device, but feels several generations behind any
| mid-range phone released in 2019. The screen has color blurring
| when scrolling especially visible with text, the fingerprint
| reader often doesn't get a good read, and it's noticeably
| sluggish in everyday tasks.
|
| I justified the higher price to support their vision, not
| because it's a great daily driver, but it serves well as a
| backup phone with /e/OS. The cameras can be upgraded to the 3+
| ones, so it's great that it's the only truly modular and DIY
| repairable device on the market.
|
| I wish that a chipset swap and upgrade would be possible
| though. Google's Project Ara was interesting, but it was
| probably infeasible, and the technology might not be there yet.
| bartvk wrote:
| > it's noticeably sluggish in everyday tasks.
|
| I'm not a fan of statements like this. They really should be
| qualified further, because the Fairphone project deserves
| thoughtful critique.
|
| What exactly is sluggish? Scrolling in the mail app? Tapping
| links when browsing over cellular? Opening the app drawer?
| Vinnl wrote:
| I'm writing this on a Fairphone 2, and even that I wouldn't
| describe as sluggish. Scrolling, tapping links, opening the
| app drawer - everything responds to my touches directly.
|
| I'm sure newer phones are significantly faster, and heavier
| workloads can probably feel a bit janky (I don't usually
| have those), but phones haven't been sluggish the way pre-
| SSD computers could be for quite a while now.
| the_pwner224 wrote:
| > The screen has color blurring when scrolling especially
| visible with text
|
| This was a big issue on my Samsung Galaxy S9 (2-3 years old
| flagship), OnePlus 7 Pro (2 years old flagship), and Google
| Pixel 5 (8 month old flagship). Those are all AMOLED so it's
| not an issue in normal mode black text on white background,
| but with dark themes scrolling makes the text look really
| bad, and it's even worse at low brightness.
| nanna wrote:
| I'll admit I'm not someone who really follows phone
| developments closely enough to disagree. What you say is the
| standard review of FFs, that it costs more and is technically
| inferior. But then again I believe it costs what a fairly
| sourced and built phone costs. Other phones are too cheap.
|
| > The screen has color blurring when scrolling especially
| visible with text
|
| Mine doesnt
|
| > the fingerprint reader often doesn't get a good read
|
| I don't make a habit of volunteering biometric data near
| Google, so can't comment.
|
| > it's noticeably sluggish in everyday tasks.
|
| Not sure what everyday tasks you mean? Haven't ever really
| noticed it being sluggish? HN is snappy as hell :)
|
| > The cameras can be upgraded to the 3+ ones
|
| I didn't know, thanks!
| luckylion wrote:
| How happy are you with the audio quality? I've been reading
| about issues with echoes on coip connections that seem to have
| been plaguing some people for quite some time. I dislike the
| cell phone audio quality by itself, but additional echoes would
| be a complete show stopper for me.
| nanna wrote:
| Really can't say I've experienced anything like this at all.
| Audio has always worked fine for me.
| [deleted]
| The-loan-wolf wrote:
| Theirs bootloader is biggest barrier in running mainline Linux.
| surround wrote:
| > First, your SoC (System on a Chip) manufacturer (usually
| Qualcomm) has to get hold of it and customize Android for a
| particular SoC, adding drivers and other hardware support. Then,
| that build goes to your phone manufacturer (Fairphone, in this
| case) which adds support for the rest of the hardware--things
| like cameras, the display, and any other accessories.
|
| Why is it so easy to boot any linux distro on almost any desktop
| computer? What makes it more difficult for phones?
| guerrilla wrote:
| They aren't PCs. That was the purpose of the PC and open
| architecture. I don't know why mobile manufacuteres don't see
| it as beneficial to them though, but it's possibly just because
| it was such a rapidly developing space until recently and has
| yet to settle but something else could be at play.
| 10000truths wrote:
| It's hard to make devices as small and thin as a modern day
| smartphone while keeping its components modular at the same
| time. Now, this might be an acceptable tradeoff for you in
| particular, but Apple, Google, Samsung et al have probably
| already determined that it's not worth catering to that market
| segment.
| jeroenhd wrote:
| Size has nothing to do with size or modularity. The same
| Qualcom chips get used from smart watches to tablets to cheap
| PCs, there's plenty of variety going on there. The difference
| is that the mobile SoCs are designed differently, requiring a
| complex system of bootloaders to even turn on that can change
| between models or even revisions of the chips.
|
| The second problem is the proprietary nature of the chips.
| The PC became popular because other manufacturers copied and
| reversed IBM's BIOS and hardware, bringing a huge variety of
| available hardware that runs the same software. The only way
| that model could be profitable was to make sure everyone
| stuck mostly to the same standard, because breaking
| compatibility made your computer significantly incompatible
| with existing software your customers want. The crux of this
| requirement was that the user brought the software to the
| hardware, and the manufacturer could at most provide an
| operating system with a few tweaks at risk of breaking
| whatever the user wanted to run. This backwards compatibility
| still exists today, to the point that many BIOS update tools
| from manufacturers will boot FreeDOS to flash chips, running
| a software architecture older than many of their users on
| bleeding edge x64 chips.
|
| The mobile ecosystem is designed so that devices last two,
| maybe three years, after that consumers throw their phones
| out and buy a new one. If you want to use your phone for
| longer then good luck, hope you bought a brand that ships you
| updates.
|
| Qualcom, Huawei and Mediatek do not share the same level of
| compatibility the original PCs did, because they control the
| software supply chain. You don't take your software to
| Qualcom and make it work, you take Qualcom's kernel and then
| write your software. If Qualcom doesn't want to update the
| kernel version for your chip, good luck getting Android to
| boot; their open source drivers probably won't work because
| they either don't exist or are shoddily designed to fit only
| one kernel.
|
| There's ongoing work over at the postmarketOS to mainline
| existing devices. Mainlined devices can run a proper, modern
| version of Linux with normal update support like any
| operating system, though Linux distributions often fail to
| properly implement things like deep sleep that are essential
| to using a phone. It'll be a while before mobile Linux
| becomes viable.
|
| Then there's Apple, kind of a weird manufacturer in that they
| provide updates for well over five years even for slow mobile
| devices. They can do this because they don't need to buy
| chips from a manufacturer with an incentive to provide as
| little support as possible so end users buy new devices.
| They're also too popular for Linux not to hack in support for
| their weird, proprietary architectures.
|
| All modular prototypes for Android have had the same problems
| with chipset and operating system constraints their constant-
| hardware cousins had; the same kernel supply line, with the
| same update problems.
| fulafel wrote:
| Lack of motivation / market pressure. Also a good excuse for
| planned obsolescence.
| Nextgrid wrote:
| A PC is somewhat standard, at least standard enough that you
| can use a common API to read from a boot drive and display text
| on a screen. Going beyond that however does require hardware-
| dependent drivers and problems start if you don't have them.
|
| A phone doesn't really have this standard; it's closer to a
| microcontroller with random shit attached to its pins,
| including for critical operations such as display or disk IO
| (where as on PCs you can get away with using the generic BIOS-
| provided functionality, which while not fast will at least
| work).
| k_sze wrote:
| Like I've said before, there need to be laws that require
| companies like Qualcomm to open source their stuff once they stop
| supporting them in any meaningful way.
| hvemsomhelst wrote:
| some qcom competitors pay ip designers for new android version
| drivers for designs from more than a decade ago
| ac29 wrote:
| Android is only 12 years old. Are there really devices from the
| 1.x/2.x Android days that are still getting updated?
| zozbot234 wrote:
| Chipset support from the manufacturer is not, strictly speaking,
| essential. What we need is support in the mainline Linux kernel.
| Many of the custom hardware blocks that a kernel has to support
| via its drivers are shared across chipsets generations anyway, so
| they end up being supported a lot longer than any single HW
| platform.
| kelnos wrote:
| Right, and we're not going to get support in the mainline
| kernel without chipset manufacturer support. Namely in the form
| of open sourcing all the binary blobs, because those aren't
| going to be accepted into the mainline kernel.
|
| Qualcomm just doesn't want to do this. I'm not sure if it's
| because they don't feel like spending the developer time
| (money) to do so, or if they believe 2-year obsolescence is
| better for their bottom line. Probably both.
| zozbot234 wrote:
| The kernel- and user-space binary blobs can be replaced by
| the community. See freedreno, lima, panfrost, nouveau etc.
| CameronNemo wrote:
| ... with a lot of work that starts only after devices start
| shipping, and rarely takes advantage of the whole
| functionality of the hardware.
|
| This is not a sustainable model.
| swiley wrote:
| Have you seen the sunxi project?
| dathinab wrote:
| It's not just Qualcomm it's closed source driver blobs in
| general.
|
| Even if your CPU might still be supported your other hardware
| might not. A common offender is camera drivers as far as I know
| and while you sometimes can still make the camera work it often
| comes with noticeable decreased quality (as the special patent
| encumbered closed source image post processing sausage is
| missing).
|
| Besides that potential but as far as I know less likely offenders
| include the modem.
|
| Ironically both might be integrated into the SoC which then
| massively increases the chance for problems.
| diegs wrote:
| Yeah, I think this is a major design point behind
| Fuschia/Zircon; they have a stable driver ABI to address this
| specific problem
| codewiz wrote:
| > It's not just Qualcomm it's closed source driver blobs in
| general.
|
| To be precise, Qualcomm's Linux drivers are GPL'd like the rest
| of the kernel. Drivers often come with firmware blobs and
| proprietary binaries in userspace, but it should be possible to
| keep the kernel driver compatible with both.
|
| The actual reason why older SoCs stop working on newer Linux
| kernels is that Qualcom's drivers were not fully upstreamed,
| either because they didn't submit them, or because they tried,
| but there were quality issues.
|
| In theory, anyone could port those drivers onto the latest
| Android kernel, but without hardware documentation it's not an
| easy job.
| klodolph wrote:
| My understanding is that a number of Android vendors operate
| by just taking a version of the Linux kernel and making any
| changes they need. By the time the phone is released and
| anyone cares, it's an old version of the Linux kernel, and
| the changes weren't written in a way that it's easy to
| incorporate them in the first place. The idea of
| incorporating a large chunk of changes all at once at the end
| is nobody's idea of a good time.
|
| I get that they have no responsibility vis a vis the GPL to
| upstream their changes, and I have no doubt that this is a
| cheaper way for them to run their business.
| londons_explore wrote:
| The SoC manufacturer provides to the OEM exactly one kernel
| version that works on that chip.
|
| The OEM has to use that version. Oftentimes the SoC
| manufacturer will deliberately make it an old version
| because they know that the next android release will
| require a newer kernel version, therefore forcing the OEM
| to update to a new and more profitable SoC rather than
| continuing to sell an old model.
| jasonjayr wrote:
| Isn't that a blatant GPL Violation?
|
| Also; has any work been done on decompiling that kernel
| and trying to match up the symbols with existing source
| code?
| my123 wrote:
| The full source code of that kernel version is provided,
| including all KM drivers.
| kevincox wrote:
| That may keep the phone working but that doesn't provide
| security updates. Only Qualcomm can provide security updates
| for the binary blobs, so if Qualcomm won't sell security
| updates past 3 years than no OEM can guarantee a secure phone
| for more than 3 years. Sure, they can update other components
| but I would be very upset if 3.5 years into my 5 year
| supported phone a CPU vulnerability was discovered that let
| apps get root.
|
| So while in practice this is rare it means that longer
| updates can't be offered as a product feature, and if it
| can't be offered as a product feature than how does it help
| sell phones.
|
| I'll tell you right now that if any somewhat reputable
| manufacturer promised 5 year support on an otherwise
| reasonable phone I would buy it (and 5 isn't even that much).
| I would even pay a bit more for it. The amount of
| environmental waste that is basically working phones that
| just need a couple of software patches is disgusting.
| forty wrote:
| > I'll tell you right now that if any somewhat reputable
| manufacturer promised 5 year support on an otherwise
| reasonable phone I would buy it
|
| I think that's exactly what Fairphone does. Sure they are
| not as big as Samsung, but they seem to be true to their
| word (I'm a happy FP3 customer, but to be honest I have
| much reasonable expectations for my phone than many :) )
| bpye wrote:
| This was one of the big reasons my newest phone is an
| iPhone, not an Android phone. I am tired of buying new
| hardware every 2-3 years just to have a secure device.
| mgalgs wrote:
| I worked on the Linux Kernel team at Qualcomm for about five
| years, left in 2016. Our director was very much in favor of
| upstreaming but the product release schedules were so
| aggressive everyone was scrambling just to hit customer
| deadlines. It was incredibly difficult to get upper
| management on board with spending an additional 20% time
| getting drivers upstreamed, despite our team making the case
| for it ad nauseam.
|
| Hopefully they recognize the value of "upstream first" more
| now. I think it is getting better...
| ntauthority wrote:
| Meanwhile, on a platform with a generally stable binary driver
| ABI alike Windows, even drivers for a prototype MSM8960 phone
| (Snapdragon S4) released in 2012-2013 will still run on 2021
| versions of ARM32 Windows (insofar as these are still being
| built and released, of course).
| fragileone wrote:
| Google is changing this for Android with GKIs (General Kernel
| Images) being mandatory[1] for new phones which launch with
| Android 12 (i.e. late 2022 phones). They'll maintain a stable
| ABI so that OEMs can plug in their proprietary drivers as
| kernel modules.
|
| Additionally with the work the Android Kernel team are doing
| to upstream so Android Common Kernel can be just replaced
| with using the Linux mainline, we're getting ever closer to
| limiting the effect that closed-source drivers have on
| updates.
|
| [1] https://source.android.com/devices/architecture/kernel/ge
| ner...
| bildung wrote:
| ABIs are only needed because some manufacturers insist on
| closed source blobs. Why should Linux, a project whose entire
| raison d'etre is to provide an _open source_ kernel, make
| life easier for companies unwilling to accept that?
| ClumsyPilot wrote:
| The questuon is, can you actyally force their hand? So far,
| the answer seems to be no.
|
| Personally I feel we need to push for a law where the iser
| has a right to an open driver in the same way he has a
| right to a manual. Attempts to ship undocumented / secret
| functionality is software or devices should be equates with
| spreadind spyware or malware.
| xvilka wrote:
| > A common offender is camera drivers
|
| This is precisely why open source libcamera[1] exists.
|
| [1] https://libcamera.org/
| nobodywasishere wrote:
| Android should have been GPL
| cwyers wrote:
| The part of Android that talks to the Qualcom drivers is the
| Linux kernel, which is GPL already.
| nine_k wrote:
| You can read the patented algorithm in the patent, and even
| implement it, but you cannot legally distribute it, until
| the parent expires.
| pmlnr wrote:
| And how would that make any difference when it comes to radio
| firmware?
| herogreen wrote:
| The radio firmware could be executed on different CPU than
| the Android kernel and communicate with a standard protocol
| ?
| monocasa wrote:
| That's more or less what happens already.
| teruakohatu wrote:
| It is but if the radio driver was open source then the
| interface with the radio SoC would be documented.
|
| Right now it is the worst of both worlds. Closed
| interface for a closed undocumented chip able to execute
| arbitrary code.
| UncleMeat wrote:
| Drivers don't need to be open source to interact with
| GPLed code.
| [deleted]
| wyldfire wrote:
| The interface isn't closed anymore, is it? [1]
|
| [1] https://www.kernel.org/doc/html/latest/mhi/mhi.html
| lrem wrote:
| Apache License 2.0 is GPL-compatible, isn't it?
|
| Edit: expanding the acronym, to evade Android/Apache
| confusion.
| techrat wrote:
| What I don't understand (due to my ignorance, please explain if
| you can)... what keeps the driver blobs from continuing to work
| from one version of Android to the next?
|
| What prevents people from using the same drivers for a device
| on Android 7 and upgrading the OS to 9 or 10? I always
| understood that drivers would continue to allow the OS to
| recognize the component that the drivers are for unless
| something drastically changes on the OS side of things.
|
| Why can't we say "Fuck you, Qualcomm" and continue to use the
| older drivers for newer OS versions without having to wait for
| them to officially support it?
| pantalaimon wrote:
| Are you implying the 'no stable binary ABI' policy is
| responsible for a lot of e-waste?
| cwyers wrote:
| I mean, that seems to be the result, yes? The intent is to
| compel device manufacturers to release the source of their
| drivers, but at this point, I think we have to admit that's
| not a great description of what's happening in the mobile
| space.
| DaiPlusPlus wrote:
| > The intent is to compel device manufacturers to release
| the source of their drivers
|
| I doubt that was the "intent"... perhaps a contributory
| argument in favour of a non-stable ABI, but I understand
| the reasons are far more pragmatic: maintaining a stable
| kernel ABI is a _lot_ of work which could have strangled
| Linux in its early years.
| UncleMeat wrote:
| There are many different reasons that all contribute. But
| Linux clearly _can_ keep some form of stability, given
| their dedication to never breaking userspace, if they
| really want to.
| namibj wrote:
| Granted, even ABI-stability to some extend is difficult.
| I remember that I have some cheap wifi adapters that
| aren't supported by in-tree code, but came with a CD
| (small diameter) that had the SDK on it. This was
| unfortunately for the old timespec or w/e the exact
| struct is called, and I could have ported it to use the
| new API, especially considering that there are in-tree
| and/or up-to-date versions for closely related chips, but
| honestly the lack of easily-accessible tooling for that
| discouraged me from doing so.
|
| The reason I got them initially is that, some about 2.5y
| back, they were sold on Aliexpress for 3.50 EUR (~5$) and
| could do dual-band with at least 40 MHz channels, iirc
| maybe even 80 MHz on 5GHz. They are just tiny USB-A
| dongles with a USB 2.0 HighSpeed host interface, but they
| could do station/softAP/station+softAP, obviously
| restricted to a single channel.
|
| There's a related issue of a rtl8812-au or rtl8821-au (or
| compatible) stick (Edimax EW-7822UAC) I got before that,
| with a USB 3.0 SuperSpeed host interface, intended for
| trying out a remote radio head point-to-point
| configuration using polarization-duplex with a recycled
| satellite-TV dish on each end, as it could do AP-mode on
| 80 MHz wide channels in the 5 GHz band on Linux, with a
| 867 Mbit/s link rate (assuming full polarization
| multiplexing based on the stick's 2x2 MIMO and a circular
| polarizing feed antenna).
| dathinab wrote:
| > have strangled Linux in its early years.
|
| And likely would still do so toady. I mean we are
| speaking about the _kernel internal API_ (not the syscall
| API, which is stable).
|
| Even systems which pride themself for internal kernel API
| stability do change the API every view years, _while
| often having much less internal (feature /platform
| support) changes then Linux_. Furthermore in android
| Linux LTS versions are often used which do support a long
| term stable ABI, potentially longer then certain other
| more niche systems priding themself with long support.
|
| The problem is when a device is sold the kernel (minus
| back ported security fixes) is often already multiple
| years old so even if you use a kernel with 7 years
| longtime support you _still_ have a good chance to run
| into problem. And supporting any kernel internal API for
| more then that time is unrealistic.
| cwyers wrote:
| Why? WDDM drivers written for Windows Vista can still
| work on Windows 10. And Windows is not a "niche" system.
| dathinab wrote:
| Because Windows is a (very broken) Micro-Kernel system
| which did very little changes to it's kernel (as far as I
| know) in the last many years, in difference to that Linux
| is a macro kernel with constant changes and improvements
| to it.
|
| Are the improvements worth the cost? I don't know. (For
| server applications likely yes, but for desktop likely
| not).
|
| What I do know is that there are clear benefits of micro
| kernel architectures, even if they are kinda messed up
| (for a micro kernel) hybrids like windows has.
|
| Lastly the way the kernel API's are designed can also
| make a major difference independent of the rest. Honestly
| the Linux kernel API _feels_ much more raw then the
| windows API, but I only have every written a single dummy
| driver for each platform and that was quite a while ago.
| [deleted]
| DaiPlusPlus wrote:
| Windows NT is not a microkernel - Windows CE was,
| however.
|
| NT has been shifting towards running more driver-code in
| user-space, as has macOS as well, especially with UMDF
| (especially for USB devices) and for graphics drivers,
| which are historically the #1 cause of BSODs - however
| just because the kernel passes control to user-space for
| the bulk of the driver's number-crunching doesn't mean
| that architecturally the kernel is still responsible for
| huge swathes of the computer's functionality. With a true
| micro-kernel there isn't any third-party code in the
| kernel space - not even a stub.
| DaiPlusPlus wrote:
| > however just because the kernel passes control to user-
| space for the bulk of the driver's number-crunching
| doesn't mean that architecturally the kernel is still
| responsible for huge swathes of the computer's
| functionality
|
| I typo'd that - it should be
|
| > however just because the kernel passes control to user-
| space for the bulk of the driver's number-crunching
| doesn't mean that architecturally the kernel isn't still
| responsible for huge swathes of the computer's
| functionality
| kevingadd wrote:
| This comment feels like it was written by someone who
| hasn't done much Windows development (which is fine!).
| The kernel changes a lot over time, introducing entirely
| new driver models (see https://en.wikipedia.org/wiki/Wind
| ows_Display_Driver_Model#H... for an example), OS-wide
| features, etc. Things like thread scheduling or timer
| granularity can and will change (see
| https://randomascii.wordpress.com/2020/10/04/windows-
| timer-r... for a recent example)
|
| Let's not forget about massive stuff like the whole
| Windows Subsystem For Linux, which was literally an
| entire separate process type alongside Win32 processes,
| with its own set of syscalls etc. Added and then
| deprecated (and probably eventually removed entirely)
| over the span of years.
|
| Maintaining a stable kernel ABI is no doubt a big
| investment, but it's possible and doesn't have much to do
| with whether your kernel is a microkernel or not. Lots of
| Windows drivers these days are user-space which helps
| maintain compatibility and stability.
| [deleted]
| admax88q wrote:
| I dunno, seems a stretch to blame the kernel for e-waste
| when theres tons of other well funded parties creating
| the waste in the first place with zero intention of
| supporting the device beyond a year, let alone enabling
| anyone else to support it.
|
| The android ecosystem is already better than the
| completely proprietary feature phones of before.
| AnthonyMouse wrote:
| > The intent is to compel device manufacturers to release
| the source of their drivers, but at this point, I think
| we have to admit that's not a great description of what's
| happening in the mobile space.
|
| But it's still the thing we want, for that and a lot of
| other reasons. So presumably what we need to do is find a
| way to exert more leverage, so that we actually get what
| we want, instead of folding and letting the bad thing
| take root forever.
| imtringued wrote:
| No, Qualcomm is responsible for that. It's their device.
| The idea that a third party is responsible for supporting
| thousands of different devices simply doesn't make sense.
| bri3d wrote:
| This is because the Linux kernel itself is constructed and
| developed in a way where driver interfaces (API) are
| ruthlessly refactored and the linker interface for kernel
| modules (ABI) is intentionally version-incompatible. If the
| driver's source code is not in the kernel, it doesn't gain
| the benefit of kernel developers doing this ruthless
| refactoring and falls behind immediately from a source point
| of view, and from a binary point of view, modules compiled
| for one kernel intentionally will not work with another.
|
| This is a conscious and opinionated strategy on the part of
| Linux, as an effort to make the cost of keeping drivers
| closed-source high and the cost of kernel refactoring low. It
| also has... disadvantages, in the form of a massive wasteland
| of only-supported-once snapshot-in-time devices. I am sure
| this comment thread will happy expound on this in great and
| painful detail.
|
| Secondly, there was an entire effort by Google called
| "Project Treble" to build a stable Android HAL/ABI over the
| top of these unstable kernel interfaces. Unfortunately it
| would/will require essentially an Android-specific rewrite
| from vendors in order to fully implement, so many drivers are
| not yet operating in this model.
| garaetjjte wrote:
| >as an effort to make the cost of keeping drivers closed-
| source high
|
| I don't think it is intentional. Linux development is very
| pragmatic, they just want to have freedom to refactor
| anything without caring about stable kernel APIs.
| young_unixer wrote:
| Ironically, they care a lot about stability towards user
| space interfaces, to the point that bugs become features
| if someone depends on them, but they don't care about
| driver interfaces being stable.
| kevincox wrote:
| This seems like a win-win. The kernel developers are free
| to refactor as they need to keep the quality and velocity
| high and companies are incentivized to upstream patches
| including making drivers in-kernel.
| fakename11 wrote:
| It's somewhat pragmatic for the Linux developers. Support
| a stable kernel API probably wouldn't be that expensive.
| It's clearly a political decision against writing close
| source code that does anything low level.
| [deleted]
| ClumsyPilot wrote:
| I am not sure why the comment is being downvoted - thats
| exactly what it is, a political decision to force
| companies to produce open drivers.
| joelellis wrote:
| Because of this unsubstantiated and baseless claim:
|
| > Support a stable kernel API probably wouldn't be that
| expensive
| alisonkisk wrote:
| How is it clear?
| teddyh wrote:
| > _This is a conscious and opinionated strategy on the part
| of Linux_
|
| If anyone wants to read the Linux developers' explanation
| directly, here it is:
|
| https://www.kernel.org/doc/html/latest/process/stable-api-
| no...
| codewiz wrote:
| Project Treble is already fully supported by Qualcomm and
| other SoC vendors, that's not the issue.
|
| The issue is that Treble simply shifts the compatibility
| issues from on from one layer (kernel) to another (Android
| HAL). There's still a compatibility horizon, because newer
| Android systems will eventually want to use newer kernel
| features and HAL APIs which were not present on ancient
| HALs which have been abandoned by the vendor.
|
| And even if the OS could theoretically maintain backwards
| compatibility with older HAL APIs for 10 years, in practice
| the System + HAL combinations which aren't fully tested
| tend to break for various unforeseen reasons, making it
| unwise to push OS updates to devices which aren't fully
| supported by their vendor.
| baybal2 wrote:
| > is a conscious and opinionated strategy on the part of
| Linux, as an effort to make the cost of keeping drivers
| closed-source high.
|
| And Qualcomm is probably very, very happy with this
| arrangement. They can put a gazillion devs to maintain
| their BSPs using any means possible, but a small 2nd tier
| SoC fabbless don't.
| dathinab wrote:
| Or you just push it upstream, which solves your problem
| because whoever is refactoring kernel code is also likely
| doing the appropriate changes in your code if
| necessarily.
| cwyers wrote:
| This assumes that the person making the SoC owns all the
| rights to the code for their drivers, instead of
| licensing them from other firms.
| bluGill wrote:
| You can demand those terms when you negotiate the
| license.
| cwyers wrote:
| And they can say "no" or "money please."
| PixelOfDeath wrote:
| Didn't some Linux maintainers had very clear legal words
| for NVidia when they tried to make a kernel HAL/ABI?
| dathinab wrote:
| NoyesNo, Nvidia tried to make a doggy legally
| questionable workaround for license aspects, so it's not
| quite the same.
|
| Also as far as I remember (I might be wrong) the google
| HAL isn't a abstraction/redirection in the low level
| kernel module layer it lives on a higher abstraction
| level and was meant to make the amount of ways braking
| less but never planed to add abstractions on top of which
| you could build a graphics driver or CPU support (which
| doesn't only affect drivers but potential also kernel
| compiler time conditional compilations).
| koolba wrote:
| Still not as a bad as Linuxant:
| https://lwn.net/Articles/82305/
| Something1234 wrote:
| I'm having trouble understanding the issue was here.
| Linuxant produced a module that lied to the kernel about
| being a non-binary blob. Am I correct, but I'm still
| having trouble understand how the company survived since
| they seem to have a website up still.
| corty wrote:
| Linux kernel license enforcement is very lax. Most binary
| blob drivers probably violate GPL in one way or the
| other, as do the "GPL-condom" half-open-source "drivers"
| that do most of their stuff in a userspace blob.
|
| When asked about it most kernel developers point to
| closed-door negotiations that are being kept
| confidential. Usually also saying "trust us, we know what
| we are doing, we'll get more source opened our way".
|
| Those who actually try to enforce GPL publically are
| ignored or shunned, e.g. Harald Welte/LaForge of gpl-
| violations.org
| detaro wrote:
| With new Android versions come new kernel versions, and the
| interfaces to drivers are not stable, and I assume Android-
| specific interfaces also do change.
| [deleted]
| CameronNemo wrote:
| The whole point of the patent system is that you do not keep
| the technique obfuscated.
| AdmiralAsshat wrote:
| It's mind-boggling to me that Qualcomm only guarantees 2-3 years
| of support for their chipset. Compare that to the PC processor
| space, how much does AMD/Intel provide? 10 years? More?
|
| Somehow people seem to be running on 15 year-old Thinkpads
| without a problem, yet a $1000 phone apparently can't scrape by
| for more than three years due to vendor support?
| zokier wrote:
| That got me thinking, why aren't Dell, HP, Lenovo etc selling
| "enterprise" Android phones? They could get probably pretty
| good margins on basic devices if they'd have good well-defined
| support periods. Bonus points for good MDM compatibility and
| various silly standard compliances that nobody cares about.
| Just being able to do purchases from same supplier as
| workstations seems like a major benefit for IT depts. They
| could probably do some bundle deals ("buy/lease workstation and
| get phone for free").
| blackoil wrote:
| Long term support for client side machine isn't a requirement
| for enterprises. Most companies typically refresh laptops
| after 3-5 years.
| zokier wrote:
| 3-5 years is long-term for a phone.
| tw04 wrote:
| Because most IT departments now get the best of both worlds.
| They won't pay for phones for employees but still insist
| employees install their spyware to "byod".
| MikusR wrote:
| Samsung has enterprise versions of some phones/tablets with 5
| year security updates
| coder543 wrote:
| Minus the bundle deals, it sounds like you're describing
| iPhone.
| boring_twenties wrote:
| When Intel released the microcode updates for the MDS family of
| vulnerabilities, in May 2019, they declined to support my
| Westmere Xeon, which launched in May 2010.
|
| So, not quite 10 years. Still a hell of a lot better than
| Qualcomm, though.
| rubatuga wrote:
| HP Z400 series got the microcode updates, so it was actually
| up to your vendor.
| boring_twenties wrote:
| Hmm, don't think so. Vendors cannot create CPU microcode,
| Intel has to do that. And the relevant Intel document[1]
| clearly stated that they weren't going to do that.
|
| The HP400 specs I found only list Bloomfield processors[2],
| not Westmere. Perhaps that is the source of your confusion?
|
| 1- https://www.intel.com/content/dam/www/public/us/en/docum
| ents...
|
| 2- https://support.hp.com/us-en/document/c01709672
| rubatuga wrote:
| X5690 (Westmere) works well in Z400. Here's another
| article specifying the BIOS update:
|
| https://www.techpowerup.com/forums/threads/new-microcode-
| for...
| scaladev wrote:
| Jesus, what a pain. Why the hell do you need to wait for
| your proprietary OS vendor or BIOS vendor to update
| anything? On Linux the kernel does that for you, just
| configure your bootloader to point the kernel to a
| microcode image and that's it. Why can't windows do the
| same?
| rincebrain wrote:
| You only really need the "early" microcode loading
| procedure (the one where you pass it in the bootloader)
| if you have a microcode problem that is so broken the
| system won't boot with it unfixed (...or you're toggling
| feature bits off and the kernel will break if you
| originally booted with those bits and then they go
| missing - e.g. the broken TSX implementations on
| Haswell/Broadwell).
|
| Otherwise, just loading the microcode update once you get
| into the running OS is fine. I've never actually had a
| system that needed to use the former, but I've certainly
| used the latter.
| ac29 wrote:
| Microsoft does release microcode updates for windows,
| here's an example: https://support.microsoft.com/en-
| us/topic/kb4494454-intel-mi...
| boring_twenties wrote:
| That's a Meltdown and Spectre update from 2018. I'm
| talking about Microarchitectural Data Sampling, from
| 2019.
| gruez wrote:
| >Compare that to the PC processor space, how much does
| AMD/Intel provide? 10 years? More?
|
| They don't "provide" anything. It's the software (eg.
| linux/windows) that's providing backwards compatible support.
| Vendor support for pc hardware lasts a few years at most.
| dyingkneepad wrote:
| Well, Intel's employees are fixing Intel drivers for Intel
| hardware released >15 years ago on the Linux Kernel main
| repository, among other trees such as the Mesa project. So
| yes they are providing support. Other companies do that too.
| boring_twenties wrote:
| They provide microcode updates.
| ZiiS wrote:
| Amd and Intel CPUs are still 100% backwards compatable with
| 40 year old chips. Not just their own chips but also nearly
| all the features of their competitor's chip too.
| gruez wrote:
| >Amd and Intel CPUs are still 100% backwards compatable
| with 40 year old chips
|
| The CPUs might be, but the chipset drivers definitely
| aren't. You'll have a hard time booting windows 95 on a
| ryzen system, for instance. Hell, ryzen doesn't officially
| support windows 7. Still, I get your point, standardization
| in the PC space (mainly stemming from the "IBM compatible"
| standard) has made backwards/forwards compatibility much
| easier.
| zokier wrote:
| Somewhat controversially at the time, Kaby Lake from
| Intel dropped Windows 7 support:
| https://arstechnica.com/information-
| technology/2016/01/skyla...
| zrm wrote:
| What anybody wants is the other way around though. If you
| want to run Windows 95 on modern hardware you run it in a
| VM; running it on bare metal isn't that interesting.
|
| And the current versions of various Linux distributions
| _do_ run on 25+ year old PC hardware, if you really want
| to.
| josephg wrote:
| True, but old hardware can run windows 10, or modern
| Linux just fine.
|
| Windows and Linux (and others) seem to hold the policy of
| drivers for old hardware being maintained and supported
| seemingly indefinitely. This work isn't free, but there's
| no reason Qualcomm and Samsung and others couldn't do the
| same.
| ClumsyPilot wrote:
| I am not sure about win95, but applications compiled 15
| years ago still run on windows 10. That's stability.
| DebtDeflation wrote:
| >yet a $1000 phone apparently can't scrape by for more than
| three years due to vendor support
|
| The OEMs came up with a simple solution. Make batteries non-
| replaceable so that given the limited charge/discharge cycle
| life of a Li-ion the phone becomes almost useless after 2-3
| years anyway.
| willis936 wrote:
| There's something else to this story people don't talk about:
| write endurance of nand. Phone performance degradation over
| time can be explained by a combination of (in decreasing
| outlandishness) TGMLC, nand wearing out, throttling due to
| battery peak current being lower, and some secret throttling.
| I haven't seen nand performance over time discussed or
| tested.
|
| Replaceable batteries might be moot if after two batteries
| the device was unbearably slow. Consumers would still replace
| their phones within a few years.
| ClumsyPilot wrote:
| Whule I also hate the status quo, the batteries can still be
| replaced, in the same way that a car's exhaust can be
| replaced, you just need to have the tools and skills" or pay
| a repairshop to do it for you.
|
| If the phone still had years of milage, its worth doing
| mmastrac wrote:
| It will be interesting to see what Project Treble brings to the
| table w.r.t. long term support for Android devices. It should
| help with the bitrot problem, though it pushes a bunch of stuff
| into blobs instead of creating long-term maintainable kernel
| source code.
| ArkanExplorer wrote:
| Google has been promising to 'solve' fragmentation and long-
| term support for almost a decade, and it doesn't seem like
| there is any real solution.
|
| If you interested in long-term updates, the answer is simple:
| buy an iPhone.
| lawl wrote:
| > If you interested in long-term updates, the answer is
| simple: buy an iPhone.
|
| I would, if apple wouldn't dictate what i can and cannot
| install on my phone.
|
| Is there a smartphone that's usable as a daily driver, lets
| me have root _and_ provides long term updates?
| loa_in_ wrote:
| > Is there a smartphone that's usable as a daily driver,
| lets me have root and provides long term updates?
|
| A touchscreen notebook with a GSM/LTE modem and a decent
| microphone running Linux is the closest you can get today
| as far as I know
| ChuckNorris89 wrote:
| Or, you know, almost any Android phone from a reputable
| brand like Oneplus for example.
| hansel_der wrote:
| cheeky comment considering the premise was long-term
| updates.
|
| while there are android phones that are supported by
| custom rom's up to ~5 years (exceptions even longer), the
| majority isn't.
|
| meanwhile a 5year old iphone se is seamlessly supported
| by the manufacturer and probably will be for a few years
| to come.
| fuzxi wrote:
| Longterm official updates? Not that I've found. Your best
| bet is likely to buy a high-specced device that allows root
| + unlocking the bootloader and flashing a custom ROM.
| That's probably what I'm going to do (minus rooting), even
| though I'd greatly prefer manufacturer support.
| swiley wrote:
| The answer is a monolithic GPL kernel that forces
| manufactures to publish driver source code but they don't
| want to admit it.
| someperson wrote:
| Or a Windows-style stable ABI with drivers remaining
| closed-source. That's what Google are doing with their new
| Fuchsia OS and Zircon kernel, which is expected to replace
| the GPL-licensed Linux kernel on Android and ChromeOS
| devices.
|
| Basically their moving away from the copyleft Linux kernel.
|
| Given Google's awful track record with Android and security
| updates, and their lack of ability to force companies like
| Qualcomm to provide longer support windows, I'm not sure
| their new strategy will be successful.
|
| Inevitably they'll be severe vulnerabilities found in the
| drivers including eg, Cellular radio / baseband drivers,
| Bluetooth driver, Wifi driver, and the vulnerabilities will
| never get patched.
|
| Hopefully Google's capability-based microkernel approach
| with Zircon will stop this ever happening. But again, given
| Google's atrocious track record with Android and security I
| highly doubt it.
|
| Even Windows doesn't support eg, i586 and i686 CPU
| architectures yet the Linux kernel does, so it seems like
| copyleft drivers are the only way to get security updates
| decades later.
| kevincox wrote:
| This will allow the same blobs to keep working but won't
| get those blobs essential security updates.
|
| This isn't a technical problem, it is an economic (and
| social and legal) problem.
| someperson wrote:
| Well it is a technical problem: it can be solved by
| reverse engineering and re-implementing every driver.
|
| But yes, it's an economic problem because that's pretty
| expensive (but has been achieved before eg, nouveau
| driver)
|
| Google could easily use their monopolistic position to
| force all SoC vendors to provide greater software
| support.
|
| Heck, Google could even simply pay every SoC vendors to
| open source their drivers. It's unlikely to even cost
| that much.
|
| But today's Google is simply too incompetent to ever fix
| Android's security update problem. They've been making
| silly excuses for decades.
| someperson wrote:
| > Hopefully Google's capability-based microkernel
| approach with Zircon will stop this ever happening.
|
| Just a correction, I meant "Hopefully Google's
| capability-based microkernel approach with Zircon will
| reduce the incidence and severity of vulnerabilities
| being exploited once they are inevitably discovered".
| chickenbane wrote:
| We agree that Google hasn't completely solved the support
| problem, but it's not to say Treble hasn't improved things.
|
| Android Pie: https://www.androidauthority.com/project-
| treble-2019-1045370... Android 11:
| https://9to5google.com/2020/12/16/android-updates-4-years/
| pjmlp wrote:
| For the lucky ones buying flagship phones, it has hardly
| changed in the traditional models used by pre-paid
| customers.
| gruez wrote:
| Hasn't treble been around for years now?
| phh wrote:
| I, as an OSS community contributor, have been using Treble
| for years now, and I have devices who got let down by their
| OEMs on Android 8, that I pushed up to Android 11, and that's
| been pretty cool.
|
| I, as an OEM, am still NOT allowed (by Google) to use Treble
| to provide upgrades. This "legality" issue is being fixed (
| https://android-developers.googleblog.com/2020/12/treble-
| plu... ), but its effect won't reach users for at least 2
| years.
| rincebrain wrote:
| I don't see anything in your second link that explains what
| the "legality" issue is, could you clarify that for me,
| please?
| yuuta wrote:
| Compare mobile phones to PC today, you will find that a PC made
| like five or more years ago can run the latest software without
| issues while for mobile devices, they can hardly survive for more
| than three years (I guess?) since the ability to support a new
| Android version completely depends on the SoC manufacturer. You
| may also upgrade part of the hardware of PC or install whatever
| OS you like on them if you want to. However, look at those
| "smart" phones, which are not smart at all: you are limited to a
| few Android versions and you are forced to install all these
| proprietary userspace drivers (HALs for example). Moreover, if
| you want to have full access to your device (Root), you have to
| bag the vendor for that privilege (Xiaomi, Huawei, etc. OnePlus
| is way better), which should be the right for everyone.
|
| This is because the PC market is standardized (I guess, correct
| me if I'm wrong), compared to the phone market which has all of
| these proprietary blobs, private interfaces and lockdown. I hope
| we could have open source drivers, standardized hardware and
| software interfaces (like UEFI) for mobile smart devices just as
| PC does. Thus we can install whatever operating system or
| software without limitations. Also there will be less e-waste
| just as PC.
| mannerheim wrote:
| Battery is also an issue. I'm two for two on destroying (my
| own) Android phones trying to replace the battery myself, but
| I've been able to replace two iPhone batteries without issue.
| yuuta wrote:
| Yeah. That's why replaceable battery is a good idea but they
| disappeared in the recent years.
| kogir wrote:
| Qualcomm is only able to obstruct in this way because Linux
| doesn't keep the kernel driver ABI stable for any fixed period of
| time.
|
| If Android used FreeBSD and Qualcomm shipped drivers for the
| latest build when the SoC was released, you'd have up to five
| years of support from that kernel release.
|
| Windows Phone 10 was actually in a position to support phones for
| years and even got Qualcomm onboard. It's a shame the platform
| was never competitive, and they'd burned all their goodwill on
| the 7 and 8 fiascos.
| kogir wrote:
| I'm going to reply to a few sibling comments at once:
|
| Yes, they could upstream drivers, but they won't. It's not in
| their best interest. I'm taking about what could be done _in
| spite_ of this.
|
| Given that they won't upstream drivers, if the blobs they
| release keep working for the reasonable life of your device,
| your phone can get other software updates, including major OS
| updates. I don't expect or need the camera or radio driver to
| change across various android versions. The hardware is the
| same!
|
| And if you want a newer phone, you're free to buy one! It's
| just sad that you can't safely use older devices just because
| the blobs break compatibility with OS security and feature
| updates. This need not be the case.
| kevincox wrote:
| > I don't expect or need the camera or radio driver to change
| across various android versions. The hardware is the same!
|
| You probably don't. But a serious security vulnerability
| could be discovered that lets apps get root. So yes, it
| likely is fine, but I want a _promise_ from my manufacturer
| that I will be able to keep using my phone for 5-10 years. I
| want to take the guaranteed lifetime into account when I am
| buying a phone.
|
| Ideally it would be legally binding such that I can get a
| refund if they don't uphold it.
| wyldfire wrote:
| Qualcomm upstreams tons of support for their SoCs.
| PurpleFoxy wrote:
| You can use older devices safely. Switch to iOS. My iPad Air
| 2 from 2014 still receives every update. It's clear that
| android vendors have no interest in long term support and
| apple does. So I send my money to the company that works the
| way I want.
| muststopmyths wrote:
| I heard one of the reasons Microsoft had to ruthless kill
| support for phones when switching from WP7 to 8 to 10 was
| Qualcomm not willing to ship chipset drivers for the older
| devices with the new kernels in each of those iterations.
|
| It would have gotten Microsoft a lot of goodwill if they had,
| but strangely enough Microsoft at that time did not seem to be
| interested in the goodwill of Windows Phone users anyway :-)
|
| I'm still hanging on to a 950XL for some weird reason.
| toast0 wrote:
| From WP7 to WP8 was WinCE kernel and single core to WinNT
| kernel and multicore. Maybe the WP7 devices could do it, but
| not with good performance. That one just wasn't going to
| happen.
|
| Most of the WP8 devices were able to run WM 10, but the
| experience was really poor on the low memory devices, so
| those didn't get a release outside of the public insider
| builds. There was one or two devices that didn't get upgrades
| for some reason, other than those and the low memory devices
| upgrading to 10 was available, but it took a long time for
| them to get around to fixing things; it actually got a lot
| better in the release after they officially gave up. Possibly
| if there was a focus on mobile during development of 10, they
| could have made the first release good, and maybe even got it
| to work OK on low memory devices; Edge was still going to be
| trash though.
|
| All of that said, a bigger problem was dumping goodwill of
| developers. WP7, WP8, and WM10 all had new frameworks for
| apps that were needed for new functionality and didn't work
| with prior Microsoft OSes; calling the WM10 one 'Universal'
| was darkly humorous.
| Marsymars wrote:
| > All of that said, a bigger problem was dumping goodwill
| of developers. WP7, WP8, and WM10 all had new frameworks
| for apps that were needed for new functionality and didn't
| work with prior Microsoft OSes; calling the WM10 one
| 'Universal' was darkly humorous.
|
| I think this was somewhat overstated, since compatibility
| in the other direction was great. I wrote a WP7 app that
| worked fine across WP7/WP8/WM10 that I supported until MS
| pulled the plug entirely on the ecosystem.
| rowanG077 wrote:
| This is not true. They could simply upstream the drivers.
| yokaze wrote:
| Two things:
|
| 1. There are longterm kernel releases, with up to 10 years
| support, and Android uses those exactly to avoid major support
| issues (https://en.wikipedia.org/wiki/Android_(operating_system
| )#Lin...).
|
| 2. That doesn't fix the issue that Qualcomm themselves do not
| want to release documentation and only want to support their
| hardware for up to two years. Ergo, you would run some outdated
| binary blob.
| kevincox wrote:
| Exactly, having the hardware _work_ is one thing. But to
| support a phone you need to _fix_ security issues. So every
| binary blob is a ticking time bomb that is just waiting for a
| security vulnerability to be found either in it, or that
| needs a firmware patch to solve or workaround.
|
| So either you need the source so that you can support it
| yourself, or you need a contract with Qualcomm to release
| security patches.
|
| Sure, a stable ABI may mean that it would be cheaper for
| Qualcomm to release version updates as well, but at this
| point I would be happy if I could get security updates for
| more than 3 years. We can start asking for feature updates
| next.
| ksec wrote:
| >Windows Phone 10......shame the platform was never competitive
|
| I still think there is some possibility of Microsoft releasing
| Windows Kernel as open source. But they will need Azure to be a
| competitive and stable business first. ( Which is not right now
| )
| CameronNemo wrote:
| FWIW I do not want to use a 5 year old kernel and I do want to
| use a 5 year old phone (LG V20).
| NullPrefix wrote:
| Just be happy that the kernel you get on your brand new phone
| is only 5 years old.
| foepys wrote:
| Example: the Nokia 7.2 was released at the end of 2019 and
| is running on Linux 4.4.194 on the newest available Android
| update. 4.4 was first released in January 2016 and is
| currently at 4.4.262. 4.4.194 was released in September
| 2019.
|
| The newest LTS release at the end of 2019 was 4.19,
| released in October 2018. 4.9 and 4.14 are also LTS
| releases. 4.4 is a bit special because it's a Super Long
| Term Support kernel but 4.19 is SLTS as well.
| CameronNemo wrote:
| Is that a fair example? Most phones sold are going to be
| from Samsung.[0] Their recent flagship, the Galaxy S21,
| is a 5.4.61 kernel.
|
| [0] https://www.appbrain.com/stats/top-manufacturers
|
| [1] https://github.com/mohammad92/android_kernel_samsung_
| sm8350/...
| Marsymars wrote:
| For a like-for-like example, the Galaxy S10 released in
| 2019 like the Nokia 7.2 is 4.14.212.
| yuuta wrote:
| If Android used FreeBSD...
|
| the only open source part (which is the kernel) will be closed
| source. No chances for customization and freedom now.
| toast0 wrote:
| > Windows Phone 10 was actually in a position to support phones
| for years and even got Qualcomm onboard. It's a shame the
| platform was never competitive, and they'd burned all their
| goodwill on the 7 and 8 fiascos.
|
| Regardless of how much goodwill they burned with 7 and 8, their
| handling of the WM 10 release nailed the coffin shut. They
| actually made a release that ran ok, but it was 18 months after
| the initial release. And Edge managed to be worse than mobile
| IE, but they were pretending to be Apple and disallowed
| competing browsers in WP. Grumble mumble, live tiles were nice.
| Joeri wrote:
| Yes, exactly that. I got onto windows phone with 8.0 and it
| was very nice to use even if app support was lacking. I
| steadily saw it decline. 8.1 took away much of what made it
| unique in the hope of getting better app support ( _narrator:
| it didn't_ ) but still remained fast and stable. Windows
| phone 10 was an outright disaster, slow and buggy, with no
| advantage to the user.
|
| Maybe microsoft was always doomed in the mobile space because
| of app support, but they did a lot of things wrong that
| sealed the deal.
| toast0 wrote:
| > Maybe microsoft was always doomed in the mobile space
| because of app support, but they did a lot of things wrong
| that sealed the deal.
|
| I don't think they really were. They were actually gaining
| market share in the 8.x days, in part because their low
| priced phones were a lot more usable than similarly priced
| Android phones. Had they continued that trend with 10,
| instead of making a terrible release and pivoting towards
| high priced phones, they might have gotten enough market
| share to change developer's minds. And it's not like
| Microsoft didn't have experience on breaking into a market;
| the first xbox was weird and different, but they became a
| top tier console.
| realusername wrote:
| Because the solution would be to actually upstream the
| necessary drivers or publish enough documentation that they
| could be created instead of doing hacks.
| swiley wrote:
| The Linux driver ABI doesn't need to be stable because the
| drivers are supposed to be published under the GPL. This way
| manufactures just need to help get their drivers upstreamed and
| are largely off the hook for support after that.
|
| Androids awful graphics API is hack that allows Qualcomm to
| keep the driver source closed which means the BSPs rot and you
| can't use your phone after 2-3 years.
|
| I'll happily buy a 10 year old SoC with half the clock speed
| but open source drivers over anything from Qualcomm because of
| how awful they are with this.
| bitmapbrother wrote:
| Qualcomm is allowing their GPU drivers to be updated via the
| Play Store. This started in 2020 so it will only apply to
| Qualcomm SoC's released from 2020 onwards.
| pantalaimon wrote:
| There is actually quite some upstream work happening for
| Qualcomm SoCs these days, it's just a lot of effort.
| swiley wrote:
| Last I checked the official work the graphics drivers were
| completely left out.
| pantalaimon wrote:
| That would be freedreno, not sure how complete it is yet.
| swiley wrote:
| Freedreno didn't come from Qualcomm and I've been through
| two Qualcomm based phones since it was started. Last time
| I checked (and I did give up a couple years ago) they
| barely had framebuffer support on a couple SoCs I didn't
| have.
| alex7o wrote:
| This has been a long time ago. One of the Pixel phones
| was running freedreno by default.
| bitmapbrother wrote:
| >Qualcomm is only able to obstruct in this way because Linux
| doesn't keep the kernel driver ABI stable for any fixed period
| of time.
|
| The Linux kernel used by Android is based on the LTS version
| that now has 6 years of support [1]. So by the time an OEM
| releases a new device the support window will be about 4 years.
| Google has also been working to stabilize the Android kernel
| HAL so that OS updates don't require a brand new kernel [2].
| Because of these developments Android devices can now offer 4
| years of support [3].
|
| >Windows Phone 10 was actually in a position to support phones
| for years and even got Qualcomm onboard. It's a shame the
| platform was never competitive, and they'd burned all their
| goodwill on the 7 and 8 fiascos.
|
| This is pure speculation and I highly doubt Qualcomm would have
| invested the time and money, to support a platform that had no
| chance of success, beyond their obligated 2 years of support at
| the time.
|
| [1] https://arstechnica.com/gadgets/2017/09/android-users-
| rejoic...
|
| [2] https://arstechnica.com/gadgets/2019/11/google-outlines-
| plan...
|
| [3] https://android-developers.googleblog.com/2020/12/treble-
| plu...
| j16sdiz wrote:
| 1. There are userspace blob too.
|
| 2. Android did change drivers architecture across version in
| the past. We are talking something as old as Android 6
| jokoon wrote:
| Interesting.
|
| It seems that open source can never really win.
| willtim wrote:
| Three years of support is very poor and encourages e-waste, I
| will not be buying a phone with Qualcomm hardware in it.
| ac29 wrote:
| That rules out iPhone as well, then.
| kevincox wrote:
| It seems like Apple is being enough that they can get updates
| for their blobs, or are writing their own blobs. Although
| even then there are no promises. Maybe if a critical
| vulnerability was found in a Qualcomm blob Apple wouldn't be
| able to patch it. So in practice they do very well despite
| containing Qualcomm parts, but it isn't clear how much of
| this is just luck.
| 2ion wrote:
| At this point Qualcomm should be pretty worried about
| getting replaced out of Apple hardware, so I suppose key
| account managers are scrambling to do Apples' bidding, at
| least to some degree. Apple has so much control over their
| embedded hardware now, they probably are already working at
| ridding themselves of everything that stops them from 100%
| control. This is unparalleled in other hardware/software
| ecosystems; there, the situation is often much the reverse.
| Decker87 wrote:
| I don't blame Qualcomm one bit. Why would they want to support
| old hardware long after 99% of people aren't using it?
| Naac wrote:
| People aren't using it because it is no longer receiving
| updates. 2-3 year old hardware should not be considered "old",
| or obsolete.
| PurpleFoxy wrote:
| Android hardware ages really poorly. I have an iPad and a few
| android tablets from around 2014 and the iPad is on the
| latest version of iOS 14 and feels almost new while the
| android tablets are basically unusable and on 2015 versions
| of android.
| fuzxi wrote:
| My 4 year old S8 is doing just fine. I'd be happy to
| replace the battery and use it for another 2+ years, but I
| only get one more quarterly security update.
| jokoon wrote:
| If the software doesn't get updated, it doesn't mean the
| hardware is not aging well.
| phh wrote:
| What about Google? The issues fairphone mention are passing
| Google certification suites. They should be relaxed to help those
| cases. As far as I know the major issues are around GLES. It
| passed older CTS, so GLES was good enough back then. Surely it
| could be good enough now.
| PurpleFoxy wrote:
| Isn't gles replaced by vulkan since about 5 years ago? Google
| wouldn't want so much fragmentation for app developers to deal
| with.
| ashneo76 wrote:
| Completely. No doubt.
| BenoitEssiambre wrote:
| This has been my main gripe with my Google phones. If a phone
| lasts half as long, it should cost half as much. Otherwise it's
| not very good value.
| dkdk8283 wrote:
| Having been through a project where we built a mobile OS both the
| carrier demands and baseband blobs are huge barriers to market.
| flas9sd wrote:
| some Qualcomm SoCs (410c and 845c) are seeing mainline support. I
| booted a 5.11 kernel on an 2015 device yesterday and had
| surprisingly good working handheld with the pmOS/Phosh stack. Of
| course this is still a raw experience for enthusiasts, but one
| can use an AOSP distribution instead.
|
| The Fairphone concept of easily replacing common problems with
| screens and battery complements the longterm chipset support, one
| needs both. It wouldn't help the repair/replace decision if the
| screen needs 2 hours and heatguns to replace. Making it difficult
| to unlock the bootloader is another barrier manufacturers and
| mobile operators are guilty of.
|
| Mainline phones can be used until their counterpart antennas fall
| from the operators towers - and for 4G I think this is well into
| 2030.
| fsflover wrote:
| If you want lifetime updates for your phone, consider Librem 5
| [0] or Pinephone [1] instead. They do no rely on Android but use
| GNU/Linux as OS.
|
| [0] https://en.wikipedia.org/wiki/Librem_5
|
| [1] https://en.wikipedia.org/wiki/PinePhone
| judge2020 wrote:
| IIRC there are still some binary blobs on there which might not
| work after some breaking change down the line, right?
| swiley wrote:
| Everything on the application processor is open source (think
| your laptop running debian.)
|
| The only thing that could break are the radios
| (wifi,bt,modem) becoming incompatible with the networks they
| communicate with but they're separate components anyway and
| the modem speaks a standard protocol so I'm sure it could be
| replaced.
| jamiek88 wrote:
| >Everything on the application processor is open source
| (think your laptop running debian.)
|
| Even GPU?
| blendergeek wrote:
| > Even GPU?
|
| The Librem 5 uses a Vivante GPU that is supported by the
| open source Etnaviv driver.
| coder543 wrote:
| The ancient Mali-400 GPU in the Pinephone seems to have
| an open source driver, yes. It also looks like it has
| been upstreamed into the kernel for years now.
| Qwertious wrote:
| If you want a "just works" phone, don't buy a Pinephone. The
| PinePhone is great for it's intended purpose but it is _not_ a
| good consumer-phone.
| bgorman wrote:
| Why would a company which holds an effective monopoly over
| Android chips in the US do anything in order to discourage the
| sale of new chips? Providing support for older chips would hurt
| sales.
|
| Qualcomm is abusing its monopoly position and the laws/patents
| that allow this need to be changed. Qualcomm is a great example
| of how IP laws can hurt progress and competition.
|
| In the future China and other countries will leapfrog the US in
| areas where competition is banned, because the only possible
| competitors will be in other countries.
| sto_hristo wrote:
| But Qualcomm doesn't have a monopoly on the market. There's
| Apple too. Sure, Android mostly uses Qualcomm in higher end
| models, but that is not the reason why Qualcomm can do anything
| they want.
|
| The reason things are the way they are is simple - users
| doesn't care. Users will happily throw cash the for next
| groundbreaking, awesome possum camera innovation that is just
| so totally worth the $1000 upgrade, because fabulous selfies
| are what people care about.
| kelnos wrote:
| Apple is only another player in "the market" if they start
| selling chips, or licensing their designs, for use in non-
| Apple products.
| angryasian wrote:
| Ok an oligopoly, does that make it better. Apple has a
| monopoly on Apple silicon.
| zepto wrote:
| Apple doesn't have a monopoly on Apple silicon nobody buys
| it.
| jillesvangurp wrote:
| Apple uses Qualcomm as well for their 4G/5G modem. They've
| started work on fixing that (by buying Intel's business unit
| that was working on that in 2019) but iphones still contain
| Qualcomm modems for now.
|
| Most of the industry, except some Chinese vendors, use
| Qualcomm technology. There just are not a lot of 4G and 5G
| implementations out there.
|
| In most markets, you end up licensing their patents
| regardless of whether you use their hard and software too.
| They have a near monopoly because building a replacement is a
| non trivial exercise and even if you succeed, you'll still
| have to license the patents. So, even when Apple ships their
| replacement, they'll be licensing patents from the likes of
| Nokia, Qualcomm and a few others for quite some time.
|
| https://www.bloomberg.com/news/articles/2020-12-10/apple-
| sta...
| _Microft wrote:
| (Controversial?) opinion: patents encourage innovation because
| they force competitors to find new solutions instead of only
| copying existing solutions.
|
| That doesn't mean that it could not go terribly wrong as for
| example when patents blocked progress in 3D printing for
| decades.
| rorykoehler wrote:
| Most innovation comes from building on existing solutions.
| You're advocating reinventing the wheel
| esclerofilo wrote:
| Unfortunately, many patents are intentionally written to make
| them as broad as possible, minimizing the possibility of
| designing alternatives.
| ocdtrekkie wrote:
| Google holds a far stronger monopoly than Qualcomm ever will.
| If Google required the driver support as a condition of
| allowing Android devices to be distributed with their hardware,
| Qualcomm would have to comply overnight.
|
| Every single Android device from every manufacturer that wants
| access to Google apps must be approved by Google, and compliant
| with Google's terms. The "poor Google is at the mercy of other
| companies" narrative about Android's product line just doesn't
| square with the reality.
| [deleted]
| izacus wrote:
| That's a strange take considering millions of devices sold
| across the world running AOSP Android without any kind of
| Google software. From Huawei/Oppo phones in China, car
| infotainment systems, tablets used in Enterprise
| environments... Your own post doesn't really square with
| reality.
| ocdtrekkie wrote:
| Phones in China alone and some infotainment systems won't
| keep Qualcomm afloat.
| sitkack wrote:
| Time is now for an unencumbered SoC with fully available
| documentation, 1k+ pages downloadable as a complete set of PDFs
| along with a reference design.
| userbinator wrote:
| If you count what's been leaked, Mediatek ones would qualify.
|
| 1k pages is underestimating by quite a bit. 3-4k pages is
| closer to the norm, and that's just most of the
| programming/registers documentation. The complexity in these
| SoCs is astonishing.
___________________________________________________________________
(page generated 2021-03-27 23:02 UTC)