As for the SPI flash size: they are almost always given in Mbit, so 16Mbit is 2MB hence the confusion if I were to guess. You would be looking for a 128Mbit one to get 16MB.
Kind of makes you think that the subject at hand is quite complex in its nature, thus untrained people might do best to steer away until properly trained.
Not necessarily more than any other card. As long as it's been running within component specs (especially temperatures), I wouldn't be worried.
It's obviously been running fine under high loads, so why would it just decide to stop working fine?
I think the major issue is that many cards have been running outside of specs for a long time. High loads tends to increase the risk of that, so the problem lies in figuring out the case for the card you're interested in.
As someone who used this feature every single day, for every single text input on the phone: I 100% agree.
The replacement method works, but it is indeed subpar. It annoys me that my 3 generation newer phone is a downgrade in this regard, but I can live with it.
Sure, but from a "high level" or "sockets" perspective, especially as a beginner it shouldn't be something you need to care about. A bit simplified, the basic stuff you need to know is:
1) UDP uses packages/messages which may or may not reach its destination. If it reaches its destination the data is intact. Normally connectionless.
2) TCP is a stream protocol. There is no package/message boundary unless you create it yourself (my tip is to do a simple binary TLV (type length value) protocol using say a fixed 4 byte header). Requires a connection to be setup first.
3) Network byte order - really important to read about.
4) Nagles algorithm (TCP_NODELAY) and SO_KEEPALIVE - those are a couple of things to read about.
5) Start with the simple select() approach to handle the socket activity.
You can then go ahead and get more advanced by doing nonblocking I/O or do blocking I/O with each client in its own thread, figuring out pros and cons for your use case. You can add SSL/TLS on top of your TCP connection etc.
EDIT: The SO_KEEPALIVE part is perhaps least important thing to start reading about. I'm a bit biased due to NAT traversal problems as I wrote a secure remote access solution for a major company several years back, utilising STUN/TURN servers, public key authentication (basically certificate pinning), TLS etc.
I think there's a confusion of terms, there's a big difference between 'deprecated' and 'obsolete'. They sure can be deprecated, which can be read as "not recommended for use and _may_ be removed in a future release", but that doesn't mean it has been removed/made obsolete.
Not a loss but a cost/expense. A loss is, to put it simple, when money in - money out < 0. Without having looked it up, I would imagine that most of his wealth is tied to amazon stock.
I’d assume it’s a ”typo” as well. Most likely it’s not the same person hiring and writing the job ad. So a qualified guess would be that a character got lost during communication/translation.
I did. The springs wearing out very much means bad contact at the contact points, we do agree there. However the receiver end with gold plated contacts points do also wear out. I’ve yet to see anything pointing towards springs wearing out before the gold plated areas (that is being worn by friction each insertion/removal) do.
I’ve got a Lightning cable with worn out gold plated contact points, the springs in the phone are perfectly fine.
My point being that without some reliable statistics pointing to springs being way more susceptible to wear than gold plated contact points, it doesn’t make any difference.
(FWIW: I currently work with factory equipment for PCB production testing and bad contact due to oxidation and wear is a much bigger issue than springs going bad, but that’s just my experience.)
I guess what we see is in part due to the transition towards more and more ”highlevel”. Now don’t get me wrong here, ”high level” in general is supposed to make life easier for developers, more rapid development and for corporate a better ROI. The downside is that it requires less understanding of the underlaying foundations (it hides it on purpose) from the developers/engineers.
Now I’m not saying that ”high level engineers” are less engineers than others, but it’s not surprising that we’re moving in the direction we’re moving. It’s by design.
(Now this doesn’t explain everything, far from it, but IMO it’s why we see an image writer weighting in on 300MB compared to a C/C++ version at <1MB)
Long story short:
Unexpected OpenSSL hard crashes in our application. Turns out our HW was reporting support for unaligned access where as it was actually disabled in CPU due to buggy hw (arm platform).
As for the SPI flash size: they are almost always given in Mbit, so 16Mbit is 2MB hence the confusion if I were to guess. You would be looking for a 128Mbit one to get 16MB.
Nice work and keep on tinkering!