No need to scream at other user we try to help and cant change anything really, so best is, you check the bug tracker if there is an open issue, else open one.
Sorry, did not mean to shout, just wanted to emphasize. Thanks for the issue tracker.
Theoretically, in an ideal world with sufficient software quality, yes.
But then the hardware might stop working suddenly, this possibility still remains.
And ideally place the additional alarm device out of your reach so you have to get up first to turn it off .
Sorry, don’t want to offend anyone, but you don’t use an alarm clock if it is so unreliable that it is being proposed to use backup alarm.
The backup could break as well. So backups for the backups? Where is the limit? How many backup devices are needed before you reliably get a wakeup call?
What would you do with an alarm clock purchased in a store that does not wake you up on 1 - 3 mornings PER WEEK? How would you react if the dealer then tells you “if you want reliability, just buy two of them?”
This “reasoning” is out of this world…
In fact, I do.
I just accept that a smartphone is not 100% reliable in what it does. It can’t be according to my subjective perception of nowadays software quality (or lack thereof), and then there’s still objective stuff like bitflips. I can’t find a reference even for current smartphones having ECC memory.
That is correct.
But the probability wouldn’t be too high I guess. But not zero.
You set the limit with a personal assessment of how secure you want to feel with your alarm solution.
Your current trouble should give you a hint in that regard.
I would return it. And I wouldn’t compare a probably hardwired simple alarm clock with a computer device running overly complex layers of software. It’s quite a stretch.
I would say that’s a sound advice, and I wouldn’t buy two identical ones (same brand + same model = could have the same flaws) .
I wonder which reasoning here is more rooted in visible reality.
Anyway, back to being constructive …
With @OldRoutard’s suggestion it should be possible to find out whether it’s just the stock clock App acting up for you.
“I just accept that a smartphone is not 100% reliable in what it does. It can’t be according to my subjective perception of nowadays software quality (or lack thereof),”
So you admit that FPOOS, which Open Source, lacks the software quality it needs?
How about improving it? Reliable software can be written.
Your words are nothing short of a capitulation.
Why should anyone want to buy a phone (or install this OS on it) if even the people close to it’s development say that it cannot be trusted?
If you don’t even set yourself higher goals, how could you ever achieve them?
I work in the IT department of a large international airport. Believe me, reliable software is possible and it does exist. Both commercial an Open Source. Without it, operating air travel would be dangerous for passengers and people on the ground. Todays jet airliners are operated solely by computers and software, they control everything on board, and so is ATC, air traffic control.
Thank god reliable software does exist.
“I would return it. And I wouldn’t compare a probably hardwired simple alarm clock with a computer device running overly complex layers of software. It’s quite a stretch.”
is just far away from reality. If the alarm clock isn’t mechanical, anything showing digital numbers is also just a piece of software. But a reliable piece of software.
" If all else fails … Installing the Fairphone 2 from scratch"
As the unreliability is new to alarm clock (wasn’t there before A9 level), simply undo the damage done to it’s source code. Regress and go back to earlier, reliable code revisions, and learn where the mistake was done.
In my point of view that is true for the largest part of any halfway complex software running today.
It could be different, as luckily you attest to yourself.
Perhaps you can help me out a bit.
Is better software quality in aviation achieved by applying best development practices from the ground up, or just by rigorously cleaning up after industry “standard” development practices because strict regulation in aviation defines that in the end somebody will have to take responsibility for mistakes instead of treating software malfunction like an act of God?
I lack the insight to perhaps draw some hope out of it.
Because customers readily do this because of other priorities, there’s not much choice anyway, and if there would be a realistic choice, would customers prioritise the better approach? The better concept doesn’t automatically win, IT is full of examples of this. Or to phrase it better, the market decides the better concept in hindsight and not entirely based on conceptual priorities.
And I’m not close to development, just to say.
For this it would first need to be established that there is in fact something wrong with the clock App and the issue is not caused by other influences.
Given that, this should of course be fixed, and then on to the next bug.
This has nothing to do with FPOOS and is a general problem regardless of the system installed and starts with Apple and Google. You cant compare with important software used in other circumstances, we are talking about a Smartphone, and the FP2 is an old smartphone and keeping it alive is cost intensive and difficult due to the old Hardware.
And a digital alaram clock has nothing else to do than showing the time and waking you up, a Smartphone has a lot more responsibilities, so a comparison of apples with oranges.
Overall I guess we will not agree here, you dont want to accept and I accept such obstacles as not important for me. Fight your fight and accept I will not attend this fight.
I understand you are unhappy and I cant change this ,so please get in touch with Fairphone.
We are not Fairphone, so telling us what you expect will not help you.
“Because customers readily do this because of other priorities, there’s not much choice anyway,”
What other priorities would make anyone accept an untrustworthy device? And “not much choice” in smartphones, this must be a joke of yours.
“For this it would first need to be established that there is in fact something wrong with the clock App and the issue is not caused by other influences.”
I already established that. The alarm clock app was reliable up until the upgrade to Android level 9.
Theoretically, the root cause (to speak in ITIL terms) could be something else. And my assumption (being an ISTQB certified software tester) is that it is not only the alarm clock app, but something in the OS around that changed - and the app was not properly adapted to. Because FPOOS since the upgrade to Android level 9 does have problems with crashing apps all around. Commercial, open source, there seems to be no common denominator. Which does lay proof to a fundamental flaw. And no, it’s not about my device. There are numerous bug reports from users that have problems with apps crashing since A9. And most of those users hoped it could go away with A10. Because most bug reports on A9 got closed with remarks like “why don’t you upgrade to A10?”. But it did not go away.
“This has nothing to do with FPOOS and is a general problem regardless of the system installed and starts with Apple and Google.”
Why is it then that there are no reports of unreliable SW with Google’s Android? If the alarm clock in Googles Android would have been as unreliable, surely we would have read tons of complaints, because of a user base in the hundreds of millions… So it does have something to do with FPOOS and only with FPOOS.
“You cant compare with important software used in other circumstances, we are talking about a Smartphone, and the FP2 is an old smartphone and keeping it alive is cost intensive and difficult due to the old Hardware.”
Of course you are right the HW is old. But the HW is the one thing totally innocent in this regard.
“And a digital alaram clock has nothing else to do than showing the time and waking you up, a Smartphone has a lot more responsibilities, so a comparison of apples with oranges.”
Sorry, no. Android is built on a fork of the Linux kernel, and the Linux kernel is known to be very effective in process isolation and memory protection. Which is why today the critical IT systems in airline industry are built on Linux and not on Windows…
“I understand you are unhappy and I cant change this ,so please get in touch with Fairphone.
We are not Fairphone, so telling us what you expect will not help you.”
I did open a ticket on the issue tracker, thanks for providing the link.
Btw dont see any report here except yours, so…
I’ll make a clarification, so this doesn’t take on a wrong twist: I do not blame anyone, especially not in here.
But from my perspective, there is nothing that could be more important than stability and reliability. Without them, there can be no performance, there can be no feature that could be counted as an asset. Without stability and reliability, everything (!) you may strive for in software will come tumbling down.
A system with only few features, but with stability, is a much (!) better base for development and growth than a feature packed, but instable system. Which is why such a system must always be preferred.
So from my (ISTQB) perspective I would like to give the advice to put stability at the top of all demands directed at any (!) SW. Or HW.
Then please enlighten me. I am a HW specialist, and I don’t see it. What leads you to the assumption that the HW could be an issue regarding the alarm clock?
“Btw dont see any report here except yours, so…”
Then please look again. Regarding the alarm clock there is more than just mine. Not many, yes, but mine isn’t the only one. And regarding crashing apps on A9 und up there numerous reports. And: Even if there would be only one report: That is not a valid proof, not even a basis for an assumption, that it would be that devices fault. Technically just not the case. I analyse problems professionally. In 30 years such a connection could only rarely be discovered. If there is a HW problem leading to instability, it almost never shows itself in some apps crashing. If HW problems lead to that you get much more severe crash scenarios.
HW instability in most cases comes from cold solder spots, broken PCB traces, connector problems or - most prominently - problems with proper thermal management. I can rule out all of them here.
It’s expensive (to show off).
It has [insert the next best feature here].
You name it. Who overall cares about software quality/reliability in the scope of the general public?
Not much choice in software quality/reliability in this context. Sorry for not being clear.
Ok, but how many affected users upgraded to a newer basic OS version in-place via the updater, a tricky procedure which on any OS and not only on smartphones will always leave some users with the short straw of something not working right after the procedure? And how many installed from scratch, which should establish a well-defined and tested state of the phone?
Anyway, apart from the things already offered in this topic, this should be for Fairphone to sort out …
It’s expensive (to show off).
It has [insert the next best feature here].
You name it. Who overall cares about software quality/reliability in the scope of the general public?"
I am speechless. Do you really believe these should be goals in any development to follow? And yes, I know many people caring about reliability. I see them every day. As soon as people depend on software (i.e. the use it to do their job/earn a living etc.) they do care. In fact, they demand this with full force given to them. Have you ever witnessed a hotline? I mean, from the operator side?
Of course not. You still argue from a standpoint of what would be desirable in an ideal theoretical situation.
While I guess we wouldn’t have many differences about what would be desirable, I’m arguing from a standpoint of what I see in reality in front of me. And I’m simply dealing with that reality.
Good for you. Doesn’t seem to improve the default modus operandi of the software industry and thus overall software quality much, though?
“Good for you. Doesn’t seem to improve the default modus operandi of the software industry and thus overall software quality much, though?”
Software manufacturers that do not deliver or even refuse to correct bugs will simply get kicked out. Depending on their conduct, this may range from being blacklisted to being sued.
Now I want to look optimistically towards the future and happily revisit this in let’s say 10 years from now to see whether we are then in a better place overall in this regard, or whether the software industry still gets away with declaring alpha/beta states as market-ready products, mixing in blatant and totally preventable security missteps now and then for thrilling excitement, forever patching and fixing issues which shouldn’t be there in the first place. I’m not holding my breath, but I like positive surprises.
No need. We are doing this for the last 50 (!) years. No one delivers nonfunctioning SW to my employer. Some have tried. And failed. It seems to me that you only have the view of a personal user of IT, is that possible? Professional IT is very different. Pacta sunt servanda. You have to deliver what you promised your customers.
A naive question from me, do you test the software with all the use-cases possible, with all the different settings? Because it seems to me software bugs depend of how you use the software, and I think there’s a difference between software done to operate planes that should always work more or less the same for the same tasks, and software of mobile devices which you can customize at will.
To come back to the topic, have you tried clearing cache or storage of the clock app? Have you tried #dic:safemode?
Well, I was never affected by any bugs on any software versions of FPOOS concerning alarms on my testing FP2 (on A9 and A10), and I used it every day for two years. It means it’s not general. There is a use-case (I mean by that a set of variables) where it works. To be able to say a problem seems general, you need really many reports, which doesn’t seem the case to me about the alarm clock. Crashing apps may be a different problem, or even different problems for everyone with a similar consequence.
How can you know it’s not a specific app you installed that creates a bug stopping the alarm from working well, that was updated simultaneously? Then it wouldn’t be FP’s fault. And there are many other variables.