583 karma · joined November 5, 2020
But I don't like this franken chip. I would much rather 7800X3D. But then, I don't play games, so the scheduler would just be terrible.
Similar problem to big.little but less differentiation between the cores. It's big.big. Kind of a mess outside of the primary use case that is games on windows with a static tuned scheduler.
If it was literally just SOA, I wouldn't have issues with it as you can reasonable have conversations about where divisions should be placed. Maybe you are surrounded with more reasonable advocates, but that is not the norm in my experience.
When you have orgs assigning a team to build and maintain 20+ services... It's gone into full self destruct mode.
The money isn't there for offline ability on most websites. So... I can appreciate it from a distance.
Web apps/spa/pwa can be a great value choice if you need to hit a lot of platforms on a budget.
Angular definitely started out as kind of a dog. Some modern frameworks I'd put up there with ruby, maybe better. Don't chase the hype. Lots of great tooling out there. Prove something out before you run with it. It's not THAT hard.
This is an indirect no. We can do that, it will cost X and take Y time and have Z impact on the code base and our long term velocity. Is this what you would like to do?
Quite often, they will say no themselves. If you have no trust with management and they ignore your warning, the org is already at high levels of toxicity and there isn't much you can do anyway. Realize that and navigate the position accordingly.
Managers have issues too, particularly good ones who care about their direct reports and getting projects done without death marches. The incentive structure is off. They are rewarded for the wrong metrics, things like number of reports (top tier metric and is a primary basis for getting titles like senior manager, director, VP, CTO, etc), which encourages growing your kingdom. Politics, credit for accomplishment when you're only a proxy for work and don't have control of all the constraints.
It's not uncommon to find yourself in the position where making the right call will be bad for your prospects for internal growth. Which means when you don't corrupt yourself, after a time you dust off your resume and try to make the next step at the next position instead of internally.
Still, you work with where you are and what you have and do your best. I want to be able to take a hand on the business side as I'm tired of projects falling apart due to bad business underpinnings I can identify from the outset. That means playing the management game from the inside so I can get to CTO where I hope to be able to make a bigger difference.
Faster -> more responsive. The client's cores are faster, even on mobile. If that's such a great trade, SPAs are potentially better than dynamic SSR.
It's the engineers and orgs, not the tools.
If you can reasonably cache the response, SSR wins on first page load, no question. On the first page dynamic render "it depends", can be SPA or SSR. 2nd page render a well built SPA just wins.
"it depends....." Server CPU cores are slower than consumer cores of similar eras. They run in energy efficient bands because of data center power concerns. They are long lived and therefore are often old. They are often segmented and on shared infrastructure. And if the server is experiencing load, seldom an issue on the client's system, you have that to deal with also. Your latency for generating said page can easily be multi-second. As I've experienced on many a dynamic site.
Using the client's system as a rendering system can reduce your overall cloud compute requirements allowing you to scale more easily and cheaply. The user's system can be made more responsive by not shipping any additional full page markup for a navigation and minimizing latency by avoiding network calls where reasonable.
On dynamic pages, do you compress on the fly? This can increase latency for the response. If not, page weight suffers compared to static compressed assets such as a JS ball that can be highly compressed well ahead of time at brotli -11. I never brotli -11 in flight compression. Brotli -0 and gzip -1.
This is for well built systems. Crap SPAs will be crap, just as crap SSR will similarly be crap. I think crap SPAs smell worse to most - so there's that.
> Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser.
If you use features the end client doesn't support, regardless of where you generate the markup, then it won't work. Both servers and clients can be very feature aware. caniuse is your friend. This is not a rule you can generalize.
> Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.
Meh. Debatable. What's hard is mixing the two. Where is your state and how do you manage it?
If you're primarily a backend engineer the backend will feel more natural. If you're primarily a front end engineer the SPA will feel more natural.
When I spent 2x as much from a US vendor from Amazon, they worked. No messing around. Probably they are built in the same regions, but US designs by US vendors I've had much much better luck with.
I don't buy lots of things from Amazon for fear of fakes. When you're on niche products that nobody cares to duplicate it's much safer.
It's almost comical the supply chain understanding you have to have to make sure you get the right thing.
Benchmarks are fine and good, but immaterial. I don't really care about 50% more or less speed. It's a server. If I do my job right +/- a few 10s of ms for response time is immaterial. The speed delta between the EMMC and SATA M.2 may well make up for raw processor speed in my use cases which tend to use the I/O.
Your particular board is very niche. I mean, yeah, you have nice ethernet. But that's it. I need my M.2 slots. I need more ram. I could get an x86 board with everything for more $$$, nvme, 2.5-10GBE. It's a compromise.
The J4105 is like 1/3rd the price of the rk3588/rk3588s.
I could go on. To each his own. I'm glad you like your board :) Enjoy it.
If you really want to deep dive on this topic see parky towers https://www.parkytowers.me.uk/thin/
The RK3588 is a 4 big core 4 little core design, so throwing out 8 cores as a point of difference is kind of misleading. Yes, there are 4 extra small cores in there.
If you just want a small cheap system, used ebay systems are pretty hard to beat. J4125 class CPUs are an excellent choice. At this point "faster" is less important than "works" I think. And the RK3588 isn't even touching the price you can get a used J4125/J4105 for. $55 https://www.ebay.com/itm/115671002802
Claiming a J4125 is "big" and "noisy" is similarly misleading. J4125 is a 10W TDP. RK3588 is a 12W TDP. You can passively cool either. N5105 and N6005 are similar power profiles. My J4105 idles at 3-5W, runs proxmox with my firewall and a bunch of VMs for databases and servers. 32GB RAM.
I couldn't find a Rock5 with case and power supply for anywhere near $150, and not even a bare board with 8GB for that. Let alone your claimed $140 for the full package.
Then there's architecture... A lot of packages you can find off the shelf for x86 just aren't built for arm. It bites you in the random places and burns time. Lots of time. I've burned far too much time trying to make ARM servers work.
Again. If the state policies prevent proper management of the resources, the money doesn't matter. It's misapplied.
The point that they don't have the resources. No, they don't have the resources to replicate what the state is doing. Parent's point is correct in that. But my point is that they don't WANT to replicate what the state is doing. It's misapplied. Thus, making the cost of the state programs irrelevant. You are assuming that everything on the budget is required to create a functional government. It's not.
Predator controls. Forest and fire management. Being able to defend oneself (guns). State and federal control of school curriculum. These are all important to most of these rural counties and are not performed well or to their liking. Nor are they empowered to go their own way because these regulations are created at the state level.
It is quite logical for them to ignore "benefits" and money being offered for the things that could be life changing for the better.
They would be rather governed by Idaho, where many more people who live similar lives write those policies that affect them the most.
Creating functional software engineering orgs is hard. Between dysfunctional management, lack of support from other business departments, or problems originating from the devs themselves.
It's pretty easy to feel when it's not working properly and know roughly where the problem lies. But solving it properly is hard stuff.
The best place for such boundaries is at the team/division/org level, not team-internal or single dev-internal like microservices implies with its name. Embrace Conway's law in your architecture, and don't subdivide within a service.
Why would I try to do that? Seems authoritarian and wrong to tell people they can't try to live some place. The issue is economics and risks. Let them assume them as they will, no need force move anyone.
Water has always been an issue in the west. I'm rather familiar with it as I have researched water rights and live in this region. There is nothing untenable about living in the south western US.
Going into the nuance here you seem to be missing. Water rights for the region are principally based on who arrived first. This was intentionally done by the first settlers to insure their own access. As little as 10 years ago you couldn't even collect rain water because you would impede the water access of a water right's owner down stream.
Over time this has been tweaked and oh so slowly modernized. It's time for a major overhaul as the quantity is based on the flows that just aren't there anymore.
So the water is over allocated, and the costs paid by the water rights owners often do not reflect its scarcity. So you have people with lots of water rights using it to grow animal feed and otherwise farm the desert in a region that is increasingly water scarce.
There is plenty of water in the region to support the population if the use cases are allowed to be more elastic. A system needs to be put in place that ALL users pay based on availability, which would provide funds to maintain and build more capacity.
If we really value humans then miscellaneous environmental concerns should not be allowed to block large scale water projects.
Making such moves would allow people to live there as they desire by removing the cheap water away from mostly farmers and some industrial uses in the region. Which will disrupt a lot of food supplies.
This is why I believe our efforts are best centered around food and water, not emissions.
The critiques make me more interested, not less. One man's cherry-picking is another's identification or isolation of important signals.
We can live most anywhere on the planet, and that isn't going to change. Though relocating from higher risk areas to lower has a cost that will be inflicted on those who are in an area where the risk shifts. If it happens on a long enough timescale the effects won't be that great as we're generally rebuilding our infrastructure on regular intervals anyway.
I always wonder why we focus so much on prevention instead of mitigation the actual risk cases. Instead of curbing emissions, which seems to have no effect (see economic down turns with corresponding dips in emissions as evidence with no apparent results in CO2 levels).
Why don't we invest in better water distribution systems and food production resilience? Instead of making it hip to have a lower carbon footprint, why don't we change what being "green" means to, say gardening?