Phones are the flagship product. They will always get the latest and greatest first, including cores, die shrinks, etc etc.
583 karma · joined November 5, 2020
I suggest you try wired before blaming the CPU.
I mean, just start with a cleanup session and proceed from there. Work on bit at a time and don't get too far from a working system.
Plenty of children benefit from hard work with their families. When the relationships are toxic then that time becomes toxic probably along with the activity. When there's love, they may not do that thing forever, but they will not hate it like this.
With my children, I encourage exploration of their skills, desires, and I've started them on paths towards lifelong careers from youngish ages (12-13). Which includes learning skills and testing things out. But I keep a keen ear open to their desires and an eye on their actual aptitudes and try really hard to match them up with useful work that they will like long term. I also try not to push so hard I kill the joy in the exploration and discovery while trying to keep expectations up and providing on-level material for them to level up at their own pace.
Children want expectations. They need expectations. Just also fill their lives with love — especially active love involving your time and attention. So that they thoroughly know that they are loved and valued well above and beyond any of these things or activities, and it will generally go well.
In any application, you have to have a good front end. To most users the app/page is the UI.
Having the majority of your concerns in one place will help you develop with smaller teams. Certain SPA architectures can bring nearly ALL of the concerns into the front end. Particularly with databases that are simply port open to the world like say couchdb. Your backend needs almost effectively disappear. If this is a reasonable data model, SPA looks and feels much faster to use and develop.
When you attach a backend, you often attach other specialists, languages, techs (python, ruby, Java). Have to deal with separate teams, which often means a formal API and all the handshaking between. This pretty much triples the required work with development and the communication overhead.
My experience with GraphQL was a pain. We could have reduced queries if we changed our front end dev patterns, but we didn't and had the same number of queries as a REST pattern would have provided. Our GraphQL backend was a cobbled together mess of microservices that struggled with performance and stability. Queries could fail and we often wouldn't know why and bugs persisted for months despite work on them. We couldn't do simple things like cache queries to be reused between application launches without backflips and juggling expertise, Apollo client and all... And on and on and on.
Granted, not the best engineering shop. But in poor shops I find REST is simpler and thus less broken in practice.
When iterating on new systems, especially one with live users. I can keep users at different document schemas. If I'm careful I can make it so that all document schema changes don't break old ones yet also allow for new functionality not requiring mass migrations of documents.
CouchDB allows the db to just be exposed to the world directly. Projects where it's reasonable (user owned/controlled data particularly), I can stand up the system with 97% front end code 3% backend. Having the near entirety of your application stack in one place means you can use smaller more specialized teams and your overall areas of concerns are smaller without needing to draw up a formal spec for your data transport.
The whole GraphQL vs REST debate is meaningless when you don't even have to think about your transport stack between the server and the browser. There are other perks to this model such as providing a fully functional website/webapp even while offline. It's trivial to switch between a couchdb backend and local pouchdb copy of your db. Potentially lower bandwidth use while just transferring updated docs instead of consistent queries or asset fetching where the same data moves across the wire over multiple uses (not a win for single visits to a single page style sites). Keeping multiple clients on the same document set in sync without socket.io work.
Also, there is a LOT of resource congestion for the arm systems. Be prepared to try every day to fire up new instances for a couple of weeks until you can find free capacity.
You would be better off with a like-new Dell Wyse 5070 off ebay for ~100 (and occasionally less if you're patient). Supports up to 32GB ram and an M.2 SATA slot.
You'll have much better IO, stability, and capacity compared to RPI4 for not much more cost. Power envelope of the system is pretty similar, the 5070 idles around 5W and loaded down it goes up to ~15W and is fanless which is in the neighborhood of the pi.
> Most storage mediums won't have problems lasting that long if they're stored well. Particularly flash and SSD storage shouldn't take issue: tape and HDD has a small chance of mechanical failure even if you don't use them.
I think you're overstating the durability of these systems.
I saved most every HDD I've used dating back to the early 90s. I wanted to get rid of the box of drives, so I got an adapter and tried to see what I could salvage from them before throwing them out. Ages varied from about 8 to 28 years. None of the ancient drives (>15 years) worked. I could usually hear them spin up, but I couldn't get anything off them. Several had the dreaded click of death present. I got some of the newer (<12 year old drives) to work. Even the newer 8 year old drives had really high failure rates. They were all working when I pull them out of service.
My old USB flash drives have also had high failure rates for me.
From my experience, expecting an HDD that isn't in use, to go for more than ~5 years totally idle is asking to lose the data on it. The data might still technically be there, but the mechanical+electrical system that makes up an HDD does not have high longevity.
To the original question. I actually just researched this topic extensively to make purchases for my back up systems and my conclusion is: If I really want data to go 30+ years. I'm using archive grade Blu-ray discs (M-disc and LTH). I burn multiple of the data I want, and I store them in dark places at separate locations.
It's generally a really good form factor for a small server. The only things most people sometimes wish they had in them is 2.5-10GBE instead of the stock 1GB, and formal ECC support.
I've been disappointed in the general reliability, terrible IO, and heat/power of the RPI4. I'm getting rid of them in favor of second hand thin clients.
ECC is about long term stability and data integrity. For a router, meh, the network protocols will deal with any flips. For a file server or database it's better if those random bit flips don't happen to critical data.
AMD based systems can sometimes be forced to use ECC mode even if the BOIS doesn't support it.
ECC is more important in systems with very large ram footprints because there's that much larger of a memory footprint area for cosmic rays to corrupt. If you've got one-two sticks of ram, and you're not running vital business data, meh, it's not required.
I really like ECC. But I'm not really willing to pay a significant premium for it.
I run companion systems to production out of my house, mostly development lanes comparable to production deployments. If they're down, it's really not mission critical. I also run my home security/surveillance systems. The other significant systems are those related to my children's computer lab.
It's the same problem if you run your own server or on someone else's systems. You need a backup and restore plan either way.
Affirm might well be correct that the bank has not really resolved the chargeback despite what Chase is telling him.
I prefer to not have the trackers, but sometimes I'm just impatient to get on with things.
PWAs, for example, can have downloadable bundle sizes < 5 MB, run in < 50MB ram, and have plenty of headroom for lots of features. You only need electron with it's own copy of a browser if the browser sandbox is unacceptable for your use case.
$100/service. Is that top level service? To cover a 100 endpoints at one service each is going to be 10k/mo?
Gracemont is such a huge departure from previous atom offerings I don't really consider them as having the same design goals. These new e-cores would be really nice for my use cases, better density and power efficiency than Ryzen.
Maybe with AMD dragging their feet on the V2000 and V3000 lines of low power offerings, I can get these sooner...
Something I don't often see, but it does come up here and there. One nice thing about the M1 is the performance is consistent as it doesn't have a massive auto-scaling boost involved. An Intel or AMD chip might start off at top speed single thread, but then something else spins up on another core, and you take a MHz hit on your primary thread to keep your TDP in spec. The background task goes away, and the MHz goes back up. Lots of performance jitter in practical use.
Interconnects and IO also consume power. You can't just scale small e-core counts without also hitting power walls there too.
All that said, I'd love to see some E-core only chips come out of intel targeted at thin clients and long battery life notebooks.