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.
> 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.
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?
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).
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?
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.
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").
>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.
>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.
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!
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.
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.
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.
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.
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.
> 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.
Because the solution would be to actually upstream the necessary drivers or publish enough documentation that they could be created instead of doing hacks.
>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 )
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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.
> 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?
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.
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.
[+] [-] dathinab|5 years ago|reply
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.
[+] [-] codewiz|5 years ago|reply
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.
[+] [-] techrat|5 years ago|reply
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?
[+] [-] ntauthority|5 years ago|reply
[+] [-] xvilka|5 years ago|reply
This is precisely why open source libcamera[1] exists.
[1] https://libcamera.org/
[+] [-] nobodywasishere|5 years ago|reply
[+] [-] CameronNemo|5 years ago|reply
[+] [-] diegs|5 years ago|reply
[+] [-] AdmiralAsshat|5 years ago|reply
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?
[+] [-] boring_twenties|5 years ago|reply
So, not quite 10 years. Still a hell of a lot better than Qualcomm, though.
[+] [-] zokier|5 years ago|reply
[+] [-] DebtDeflation|5 years ago|reply
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.
[+] [-] gruez|5 years ago|reply
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.
[+] [-] nanna|5 years ago|reply
[+] [-] imiric|5 years ago|reply
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.
[+] [-] luckylion|5 years ago|reply
[+] [-] kogir|5 years ago|reply
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.
[+] [-] yokaze|5 years ago|reply
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.
[+] [-] kogir|5 years ago|reply
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.
[+] [-] toast0|5 years ago|reply
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.
[+] [-] realusername|5 years ago|reply
[+] [-] j16sdiz|5 years ago|reply
2. Android did change drivers architecture across version in the past. We are talking something as old as Android 6
[+] [-] CameronNemo|5 years ago|reply
[+] [-] ksec|5 years ago|reply
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 )
[+] [-] rowanG077|5 years ago|reply
[+] [-] muststopmyths|5 years ago|reply
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.
[+] [-] swiley|5 years ago|reply
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|5 years ago|reply
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...
[+] [-] yuuta|5 years ago|reply
the only open source part (which is the kernel) will be closed source. No chances for customization and freedom now.
[+] [-] yuuta|5 years ago|reply
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|5 years ago|reply
[+] [-] flas9sd|5 years ago|reply
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.
[+] [-] zozbot234|5 years ago|reply
[+] [-] kelnos|5 years ago|reply
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.
[+] [-] mmastrac|5 years ago|reply
[+] [-] bgorman|5 years ago|reply
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.
[+] [-] ocdtrekkie|5 years ago|reply
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.
[+] [-] sto_hristo|5 years ago|reply
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.
[+] [-] _Microft|5 years ago|reply
That doesn’t mean that it could not go terribly wrong as for example when patents blocked progress in 3D printing for decades.
[+] [-] k_sze|5 years ago|reply
[+] [-] fsflover|5 years ago|reply
[0] https://en.wikipedia.org/wiki/Librem_5
[1] https://en.wikipedia.org/wiki/PinePhone
[+] [-] phh|5 years ago|reply
[+] [-] surround|5 years ago|reply
Why is it so easy to boot any linux distro on almost any desktop computer? What makes it more difficult for phones?
[+] [-] rektide|5 years ago|reply
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...
[+] [-] grumpyprole|5 years ago|reply
[+] [-] traverseda|5 years ago|reply
I presume that there's a good reason why that isn't being enforced, but I would like to better understand why.
[+] [-] BenoitEssiambre|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] sitkack|5 years ago|reply
[+] [-] dkdk8283|5 years ago|reply