Hacker Newsnew | past | comments | ask | show | jobs | submit | hvindin's commentslogin

My personal S5 experience leads me to believe that there was some trickery afoot from Samsung's end.

When I realised that my S5 was starting to get a little bit dodgy (having owned it from April 2011 until around December 2018) I went and bought 8 of them. Surprisingly, they were still available for purchase on the Samsung website over 7 years after they were originally released, although they quickly ran out of stock and I needed to go trawling through mobile phone stores asking them to check their store rooms.

From here I noticed that every time I updated my phone to the latest software version, deleted all the extraneous bloatware that actually made no sense to have pre-installed, and go to using a device: it would start to behave weirdly within weeks. Apps that had previously run just fine (like, as an example, google maps) were laggy and constantly crashed.

After going through 6 of the 8 phones in just over 3 months (the rate of failure seemed to have more to do with the fact that they were S5's in 2019 than anything I was doing to them) I eventually just gave up and bought an S10+ (because I honestly just wanted to see what the hell one would do with a terabyte of Storage on their phone - turns out it's absolutely nothing, but the possibilities initially intrigued me, but I guess I'm not really creative enough to come up with something worth doing with all that storage space).

Now I'm still bitterly using the aforementioned S10+ waiting for someone to release a phone that I perceive to be as good as the S5....

So no hard data, just my experience with a large amount of S5's that all seemed to become unusable based on the date rather than actually being broken....


There are recent updates from LineageOS for the S5 (multiple variants).

https://download.lineageos.org/


Unless you got an exceptional price for those GS5s, I'm missing why you prioritized that particular model, which was five generations old by 2018.

I had two. One bought new, one bought off Ebay. Never had trouble with either, but I had abandoned them by 2016ish. I rooted one (to get around mobile hotspot limits), later unrooting it when Tmobile stopped treating tethering/hotspot punitively.

The GS5 was the last of the line with removable battery. The GS6 was the last with an IR port.

One impressive aspect of the Galaxy S has, for me, been reliability. Mine have dropped to hard surfaces many, many times with no damage (aside from cracked glass, with which it still performs fine).


Anecdata, but my S5 is still working after...6-7 years I guess. My brother also has one and his works. My charging port broke so I have to remove the battery to charge it, but I have three batteries that I rotate between so this isn't a big deal. However it hasn't received a software update since 2017 (I am on T Mobile), so there are probably all kinds of security issues lurking.

It will, however, be the last Samsung phone I buy.


I had the same happen on my Nexus 7, after aggressively disabling apps, including things like the Google app.


It's the Google services that do the slowing down.


Genuine question, do normal people pronounce ARM as "Arm" (like the limb) as in /ɑːrm/ or /ɑːm/, or do they pronounce it like A.R.M as in each letter individually.

I've always said ARM (as in each individual letter) when talking about ARM processors and it's never even occured to me to pronounce it like Arm.

That being said... I do pronounce RISCV as /rɪsk-viː/ (or, as I believe was the intention rɪsk-faiv depending who I am talking to) and that seemed entirely normal as opposed to pronouncing each letter in the Acronym...

So maybe I'm just weird here...


The company and CPU name has always been pronounced 'arm' like the body part.


My general rule is to pronounced any three letter Capitalised term as individual characters, so A/R/M and S/Q/L.

Since RISC-V is longer I pronounced it the same as you; /rɪsk-viː/, the same as to NASA and NATO.


Yeah, it's pronounced like the limb, and always has been, at least in English-speaking countries. Hence the StrongARM pun.


In English, I usually just say it as the body part. In French, however, I would pronounce every letter separately.


Dammit.. was hoping Australia could silently slip under the radar on this one.

The thing that I suspect that most people don't understand about Australia is that the laws don't really mean shit all unless the situation gets very serious very fast.

I know people who have received aa requests who have literally responded with "get fucked mate, why on earth would I do that?" and the response has (for every instance I'm aware of) been "yea, true. it was a bit of a stretch"

It's rather like the Australian constitution, I'm fairly sure I've seen a joke around about it, we have one but like... no one actually cares... if shit really hits the fan I'm sure we'll all go find a copy and figure it out, but otherwise we're doing only slightly less than alright just kinda playing it by ear...


This.

I'm kind of suprised that I can't see any other comments talking about GTM's (I assume you mean F5 Global Traffic Managers)

Where I am at the moment GTM's are used everywhere, and everywhere the TTL is set to 30s.

The only part of this that really annoys me is that the global default configuration, rather than serving up a subset of the list of IP addresses, only a single IP address is returned when you resolve down to the A record.

When I've pressed the issue that _at least_ on our internal GTM's we should just return a bunch of IP addresses every time someone resolves the address, I've been told that it would break load balancing... which blows my mind because who on earth is relying on DNS to load balance traffic with a 30s TTL, I would have thought that the normal thing to do, if you actually wanted load to balance, would be to result a subset of IP addresses in a different order and with a different subset each time. That way other DNS servers which resolvers that will cache that record can at least be returning multiple addresses to all the clients it serves, as opposed to everyone using that resolver getting stuck to a single address for 30 seconds...

But all of that being said, it would make perfect sense to me to just return like 4 IP addresses publicly for every resolution and rotating setting the TTL to like 30s so that clients could spend 30s iterating through the A Records they have cached, then hit your resolver up again and get a different sites addresses back if your site had gone down...


Both of those statements are correct in context.

RGB if a thing is emitting light.

CMYK if a thing is reflecting light.

So it is true to say "Red, green, and blue are the basic building blocks of other colours"

It is also true to say "When you were told in primary school that the primary colours for your paints were red, green, and blue, this was untrue"

I do actually think that this is an example of a somewhat muddled thought process that is jumping from one thing to a other pretty eratically, or perhaps of something being edited such that it is now confusing to a reader going over it for the first time, honestly the whole thing reads a little like it was written by someone who really enjoys stimulants and can't keep their focus on one thing. But _technically_ I don't think any of the content is _wrong_ (obviously this means excluding ~70% of the content because it's largely about how people feel, and this is probably never _wrong_ but it's also not a matter of fact...)


No, actually, my bad, I went back and read that bit over again for a third time and it does actually say red yellow blue aren't primary, but that the primary colours are red yellow and blue.

You were correct and I jusy managed to misread the article twice....


> It is also true to say "When you were told in primary school that the primary colours for your paints were red, green, and blue, this was untrue"

The reason that red, green and blue are sometimes stated as primary colors in the context of mixing ink layers is that red and green and blue are rather vague terms. What is meant by red in this context would more exactly be called magenta and green is used to designate cyan. Wikipedia puts it this way[1]:

> Before the color names cyan and magenta were in common use, these primaries were often known as blue and red, respectively, and their exact color has changed over time with access to new pigments and technologies.

Also I think education about primary colors is just a mess and the same Wikipedia article[1] talks about this too:

> Elementary art education materials, dictionaries, and electronic search engines often define primary colors effectively as conceptual colors (generally magenta, yellow, and cyan; or red, green, and blue) that can be used to mix "all" other colors and often go further and suggest that these conceptual colors correspond to specific hues and precise wavelengths. Such sources do not present a coherent, consistent definition of primary colors since real primaries cannot be complete.

[1] https://en.wikipedia.org/wiki/Primary_color


Where I am at the moment we're running clusters of 400-800 containers sitting behind nginx instances and even thought we own nginx+ licenses, we've found the consul-template + SIGHUP route to be totally fine, even at a churn of maybe a dozen contained a minute everything still seems to be working fine. If a particularly busy node dies then we occassionally see a few requests get errors back, but Nginx's passive healthchecking (ie. checking response codes and not sending traffic to an upstream with a ton of 500's being returned) seems to handle all of that ok.

The only time our tried and tested consul-template + SIGHUP method is every unsuccessful (and we've ended up jusy having to put processes in place to stop this) is if we have the same nginx handling inbound connections to the cluster under high load and we try and respawn all the containers at once. Then things start to go wrong for 5 minutes or so then back to normal.

While "the occasions error response" isn't perfect, I suspect that for most use cases it's good enough, so I'd still be interested in knowing more specifically what happened to that nginx...


I would be sceptical that anyone wouldn't want to join the dots if it meant that their most popular product stayed popular and they didnt end up with blood on their hands after many many people died because those dots remained unjoined.

At worst it might be plausible that in a very specific scenario some people knew about enough of those dots that they knew it would be a PITA to go back and make everything right, but they almost certainly didn't know about enough of those dots to actually understand the scale of their fuck up there.

In which case I would say it's still a matter of someone not joining the dots, it's just makes them moderately more culpible, then steeply more incompetent the more of those dots they knew about but still didn't flag as problems.


That's possible but unlikely.

I'd be willing to bet there are engineers who are experiencing a lot of guilt about this right now. Not many.. but maybe even a handful. These are people who might not have been able to do anything about the problem had they realised the true scale of the risk. But I'd guarantee they exist, even if only in a number one can count on one hand.

It's a failing of the company culture where these engineers were not made safe to speak up; a missing facility for those who knew, to get the message to those who would do something about it had they known. It was likely a function of unhealthy (toxic?) company culture which precluded this psychological safety.

I bet these folks feel pretty bad.. maybe even responsible. They won't speak up tho, lest being labelled or even targeted with the full blame. They will suffer in silence, in some ways like the many soldiers ordered to do things they didn't think were right, but did anyway.


I was actually pretty pleased with this as a proposal right up until Problem 8

I actually use the description of commit and the time of commit quite regularly to figure out how active a project is.

If everything but the readme and maybe a contrib folder hasn't been updated in 6 years, I have concerns. Unless the commit message on one of those, say the contrib folder, indicates that adjustments have been made because the repo I'm looking at considers its work now be a solved problem space and I can see few/no issues or pull requests then I'm backing right out and looking elsewhere for a project that might address my particular problem.

Replace that information with a commit history that doesn't indicate to me where those commits got made (ie. Was it core code changes? A spelling mistake? Where are people actively working?) and a bunch of stats that I usually don't care all that much about and which are already available if I did really want them. Now the repo landing page becomea a chore to navigate.

However literaly everything up to #8 I actually think makes a lot of sense and is a small enough deviation from what is there that users aren't going to be immediately shocked.


I do wonder if there is any chance that the reason that there is a spike in reports of abuse on the Saturday following report cards coming out on a Friday is because it is more likely to be reported?

It's not mentioned anywhere in the article, but if someone said to me that 2 things are true: 1. There is some correlation between report cards being returned and child abuse 2. There is a spike in reports of abuse on Saturdays when report cards are returned on Friday

I wouldn't immediately think "cool, lets return report cards earlier. Problem solved"

Other than not really solving the problem of abusive parents, this also doesn't actually rule out child abuse happening accross the board but not being reported on weekdays.


This isn't something designed to solve the problem. The actual problem is really, really complicated and solving it is difficult.

It is unlikely that all the abuse simply shifts to during the week and stops getting reported.

What it actually is, however, is a change schools can make to lessen child abuse, even if it is just a little. It isn't something difficult or expensive to do.


I'm curious if you could reason this out for me. If I drink a few hundred litres of tea a day to keep me alert then why is that different to me taking ritalin? I mean its obviously impractical and probably quite bad for me and I should absolutely take ritalin instead. But I'd love to know why the desire the stay alert to the extent that I need to seek drugs to help with that because I can't get enough sleep is any less alarming if my drug of choice is tea (ie. Caffeine) rather than ritalin?


Because caffeine consumption is usually a given in the general population, and significantly weaker than more specifically engineered and harder to acquire prescription drugs. Three pots of coffee in an hour is a poor equivalent to taking ritalin.

If I considered walking across the room as a form of workout, I could pretty confidently say that 99.99% of Americans exercise once a day. But that wouldn't yield me much in the way of insight.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: