hvindin

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....

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...

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...

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....

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...)

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.

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.

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?

No shit speed and meth are stronger than coffee. I don't think that was the point being made. Or at least its probably safe to assume the commenter you are replying to didn't indend to imply that.

Sorry to be do blunt but casually ignoring things like modafinil which seems to be the go to drug for staving off sleep if you want to be able to pass drug tests is a bit of a mistake.

Subjectivly most users of modafinil find it "weaker" than coffee because there is no rush associated with it as there is with coffee, you just can't sleep when you take it.

So if the point you're making is actually just virtue signalling with the "well some drugs are worse than others because I guess they are classified as controlled?" bullshit then please provide an actual reason why the comment was disagreeable.

I suspect the problem most people end up trying to solve isn't "how do I technically scale my tools", because the author points out that tools and techniques for this already exist and its an already solved problem.

Instead my experience has largely been that the problem to solve is "how do I make some few hundred developers behave in a predictable way" in the scenario where you have many ok developers, but that you can't really be sure that none of them will break stuff because you are trying to solve organisational problems of keeping people with merge rights to only the people who wont break things but at the same time not bottle necking development on to small a number of people then sure, split your repos up so that people can only break stuff that they 'own'.

But at least be honest about the fact that most of the technical issues of having a monorepo have been solved already so the issues you are probably trying to solve are actually people problems.

Not sure how the specifics of this works on amazon but when I read it initially I assumed the results were returned as images which seems to make a little bit more sense, although possibly not that much.

Although reading it again it does seem to be quite unclear...

As an Australian I always struggle with the idea that healthcare would cost money above a couple of dollars for things that aren't essential.

But almost every American I've ever spoken to who hasn't experienced decent national healthcare seem to have a bizzare view that "if it's free then obviously it will be abused", not realising that it's just as open to abuse as a system where end customer are also involved because shockingly customers arent usually the ones committing the fraud.

It genuinely feels like theres a view that some people might not "deserve" healthcare, and the way we determine who "deserves" healthcare is not the very humane "well they need it, therefore they deserve it" but rather "capitalism. Definitely the answer."

Makes me a little sad, but I guess when you have nothing else to compare it to...

Interesting comment:

Selling drugs is much more convenient and profitable, for example.

I know its not related to the original topic, nor the core point of your comment but I'd be fascinated to know why you think this.

Based on my knowledge of the market WRT wholesale prices/retail (street) prices/legal risks/product expiry/supply chain reliability as well as just the statistics around anyone towards the bottom few levels of the pyrmaid on this I'm almost certain that this is roughly never the case.

I find it interesting that this assumption seems to still exist, and suspect that a suprising number of people would harbor a fallback position of "if shit gets really bad I could just sell drugs" which makes a lot of assumptions about how profitable it could possibly be.

I find it interesting that there seem to be things called out as features which conflict:

1. Recording all requests in a database - feels like only very low value targets could do this. Exposing a database record of requests within the same software stack as your gateway (ie. First line of defense sort of space) feels like its immediately risky. This is why large enterprises tend to rely on their backends to do full white box auditable records keeping but as you move closer to the edge the amount of information stored gets stripped back until you should really only have correlation ID's and time stamps which should be getting shifted off-box in a hurry so they can be ingested internally. 2. Guaranteed immutability of requests which is specifically called out as useful to financial institutions. While I won't deny this is probably a nice thing to have, its also really only valuable in reducing load on your systems of record by removing duplicate requests or refiring them only as needed. As mentioned above, its the core systems of an enterprise like a bank that will be doing all the record keeping. So it will likely also be this core system that is in charge or recognising and rejecting duplicate transactions, otherwise you're throwing a lot of really important decision making about what requests those core systems should see a long way away from those core systems, meaning you are almost definitionally less able to make a sensible decision about if that request should be sent again or not. But then again, you're also that much closer to the client application so might be able to pick a lot up from context that your systems ot record would be oblivious to.

I'm not really sure I can see perfectly clearly where this particular gateway would sit in the ecosystem...

Personally I'd be pretty sure that, at least at the bank I currently work at, this would rarely ever work.

I mean, other than the attempts to foster a relationship between bank staff and the tech people through things like days of letting tech people hang out and try and be helpful at branches in order to "see what real difference they could make" - and that laegely ending up being a fairly regular educational exercise for everyone involved theres two problems I see:

1. All the phone calls into branches are monitored (you may have noticed so many "we will record this call and it may be monitored" messages - they arent kidding) and if certain key words, or even key tones of voice are picked up someone from a relevant team silently dials onto the call to listen in. 2. The general process for anyone not in it interacting with any IT system is to click a button on their screen which generates a 6 digit pin and if you cant match that pin with the person talking to you and dont confirm success then alerts go out immediately.

And given the hit rate on the "generate pin" api, tellers are definitely using it properly.

So i'd be inclined to go pretty small if I where to bet at all.

Not sure why the assumption that you can social engineer your way onto any half way competent institution still persists,but nowadays, as far as I know, you have to pick the really low hanging fruit for someone to let you in so easily.

I'm curious, when is server time ever worth more than developer time?

I mean, sure, if you're doing something as a hobby and consider your own time free but have to pay $5 for a VM somewhere, then maybe.

But especially at large companies, my experience has always been that for any work done the cost of infrastructure is basically a rounding error compared to the cost of developer time. And that doesn't even begin to include the cost of support team time for the eternity that everything seems to need to be maintained for in larger companies.

As a recent example, I know that the amount each developer on a team I've worked on costs (not how much they are paid, all contractors from various companies), per person, more than it would cost to buy a mid range server, colocate it in a data center etc - per day. So after a year, if we just bought infrastructure instead of developer time, we could have had a handy ~15,000 mid range servers racked and ready to go.

I feel like a less confusing title would be something like "Github to discontinue support for weak cryptographic standards Feb 2018 (2017)"

I saw this with the original 2018 in the title and immediately had a pretty bad "what the f* Github? Deprecation periods aren't a thing?" reaction..

I would question the incentives for an insurance company to reject claims arbitrarily or to not make the process for submitted claims at the very least adequate for two reasons:

1. If you insure a bunch of people against, in short, stuff that can kill them, then it's really in your best financial interests to be making sure that as many of those people as possible are seeing a doctor as regularly as possible (within reason) because that's how you avoid situations where someone makes shitty healthcare decisions for 3 decades then suddenly needs every imaginable treatment for every imaginable ailment that said person, who is obviously not a healthcare professional, would have never seen coming because they weren't regularly attending to their health in a low cost consistent kind of way, instead they just let their health deteriorate until it was an emergency. Which, from my understanding, especially in America, is where the vultures pounce to ensure your insurance companies pays top dollar for critical drugs and treatment.

2. On a purely accounting note, wouldn't this just fuck up your cash flow figures? I mean, if someone needs to get their insurer to pay for something because they don't have another option and they try and claim for that thing, isn't it in your best interest to make sure you pay out the amount at least reasonably quickly because, especially if you're acting in bad faith, their going to eventually break their way through the system to the "submit claim button" through sheer hours of trying, or their going to end up in court because they don't have other options. Then you've suddenly got a massive lump sum payout that probably wasn't in your forecasted expenses. To me, that just sounds like unpredictable silliness.

But then again, I live in a country with free health insurance so I genuinely could be entirely missing the mark here and it could genuinely be more profitable to pinch your pennies as an insurer.

kpatch was a Technology Preview in 7.1 and only became officially supported in 7.2

https://access.redhat.com/documentation/en-us/red_hat_enterp....

Ah, I completely missed that it was a technology preview in 7.1

Presumably what that snippet is actually saying is "there will be no way to avoid a reboot due to the nature of this change" rather than "rhel 7.2+ will require a reboot but 7.0 and 7.1 won't"

Thanks for the clarification.

Is someone more informed on the workings of the Linux kernel (specifically redhats flavour) able to point me in the direction of some more detail about this:

Due to the nature of changes required, a kpatch for customers running Red Hat Enterprise Linux 7.2 or greater will NOT be available

Just wondering what changed between 7.1 -> 7.2 that made this something that couldn't be updated live and there doesn't seem to be a ton of obvious extra information about the nuances of this change around.

As long as the patch is all anyone notices then it looks great from AMD marketing. But I'm fairly confident (and a quick browse through the patched in the latest RC confirms at least one instance of this) where comments call out that AMD CPUs do things that should be considered bugs, so there's probably not going to be a lot of PR people telling the masses to read the source code. It's not exactly flattering to anyone.

One thing I can definitely respect about the kernel developers is that they don't seem to make any effort to be nice about the fact that they need to deal with undocumented nonsense from vendors all round.

They own all the actual cable in Australia. So are essentially our only tier 1 ISP. Everyone else just needs to buy services from them.

Just my cynical view, but I'm thinking it's because is got a friendly looking whale as a logo and the developers took the approach of making it friendly to use for someone who doesn't understand the underlying quite complex technology.

I was involved in making the decision about introducing containers to my workplace, my original recommendation was to just go with chroots or buy into something that we could get vendor support for on RHEL6 (so not docker) and when asked to explain how this would benefit out desired outcome, the docker website basically had copy-pasteable words that did that job for me, chroots however just described he technical implementation of a chroot.

So eventually I just went "fuck it, we'll run unsupported and take the risk, then well move N thousands of servers to RHEL7 because I don't want to have to explain to managers how cgroups and Linux kernel constructs work". About a year later most of the enterprise has a plan to move all their existing EL5/EL6 workloads to EL7 just in case they need to use docker some time in the future.

Which, if I'm honest, I kind of regret, but it doesn't impact me that much so meh.

Yes, and they do. Which is why people should rely on the gpg keys of vendors as well as watching forums and other buyers to work out if things have suddenly become suspicious.

This is why coin mixing services exist. Otherwise as soon as you cashed our your btc you would be obviously traceable to all your purchases.

As someone who genuinely believes that providing a legitimate (or as legitimate as possible) avenue for people to purchase drugs (I'm less sold on arms trafficking and sale of stolen credit cards) I was surprised to find how much a genuinely felt like I disagreed with the bulk of this articles content.

While I haven't been in the market for any drugs for a while I know enough people who regularly frequency DNM's and I tend to check in every now and then just because I find the whole ecosystem fascinating.

This article seems to imply that the entire dark net market thing is as simple as ebay or airbnb, but it's actually a lot more complicated. There's a ton of extra stuff you need to do to protect yourself not just from the vendor/buyer but also from the market places themselves, because they are also "untrusted" this means things like multisig transactions and the like are a must.

Additionally the view that a vendors pseudonym is important is just flat out untrue since people realised how much money there was to be made by hacking vendor accounts or claiming a known vendors name on a market that vendor does not yet have a presence on. The key thing is being able to do what is generally considered reasonably high degrees of security based validation, by verifying an identity out of band from the market. This means using GPG keys that you have sourced from previous interactions to communicate, double checking with vendors over wickr or secure anonymous email services to ensure they are the person you are dealing with on a marketplace.

Essentially once a vendor has a reputation the marketplace becomes irrelevant entirely. If it where me, I'd rather do a direct deal using GPG encrypted messages over wickr with a vendor I trust than buy from a vendor I don't personally know on a market that I shouldn't trust (exit scamming must be way to tempting).

I admit that I'm not entirely engaged with the current workings of the DNM's at the moment, but other than being a place where new vendors can earn some reputation, the value add isn't that high. And now that it's a mainstream activity (relatively to buying drugs in the open before silk road) I feel like it's only a matter of time before new vendors can earn enough reputation just frequenting reddit boards on the topic and making sure they have good opsec. As soon as they get one or two people happy with what they've bought, it's all word of mouth from there. (Obviously they need to deal with security of being on the clear Web, or just set up their own onion site)

With regards to a point that was mentioned about block chain history being useful here, it isn't. All it does is help law enforcement, unless you mix your coins appropriately through a trusted party in which case the history if your transactions isn't verifiable and it's useless anyway.

What are useful are services like grams, which (at least when I last checked) scraped reviews from market places, reddit, etc and aggregated them based on the vendors public key.

I feel like this article was either written about 5 or so years ago, or the information it contains simply hasn't been updated in a very very long time.

I just remembered a specific use case which we had where we where told no re: looking at code and it completely screwed us.

One of the banks owned by our parent company was using a system built by HP to determine loan rates. Now, being a bank that's kind of their core competency so letting someone else build it just seems silly.

But two years later I was on a project trying to hook a bunch of stuff up to this system and we noticed that we couldn't get a proper test run because it kept giving us different figures for the same inputs.

After asking again for the code, or even pseudo code that would explain the behaviour we again told no.

A bunch of lawyers got in a room and they explicitly threatened to sue us if we tried to decompile their code or monitor the system to learn the logic. My response to this was immediate alarm bells because that meant we where not allowed to actually test the system which paid for most of the development of and hosted internally.

A discussion with just our lawyer revealed that, because it was related to home loan rates, our liability was actually significantly reduced if it where technically possible to decompile the code and verify what it was doing because the cost of not being able to explain it to auditors would be so high and the amount we would be sued for might maybe max out in the 10's of millions.

After a bit of very low level analysis we found that their algorithm for determining a load rate included a random number generator to determine an arbitrary discount in the case that very similar data was input repeatedly.

We later discovered that a developer was trying to be clever and get more home lones sold and had entirely missed the point of risk profiling properly. Ie. We don't want to sell you a home loan at a low interest rate if the risk of you defaulting makes it less profitable.

Eventually the resolution we came to was that HP would fix this shit up and they would provide us with all of the original source they had access to.

But for the next 20 years or so we will be carrying the liability of potentiallt hundreds of loans (this system wasn't used by most business units at the time but we where thinking of expanding out its use, hence the project) that have an interest rate that is lower than it needs to be (like 1-1.5% lower!) to cover the risk profile of the person who got the loan.

And all we needed was the code and that wouldn't have happened.