acheron9383

Man that is a lot of computer to put into that product for as little money as possible. I'm not intending to excuse the products with likely bad firmware causing most of these issues, especially Ethernet PHYs. Though, in my professional experience doing embedded device firmware, Ethernet PHYs are always the biggest pain, hands down. The firmware included with them has many many ways to configure it wrong, and the defaults are typically just random settings, not a reasonable configuration. Just getting the drivers even running sometimes involves just knowing a few tricks. Anyways, it doesn't surprise me many have trouble working right, especially when they indicate they are all running OEM firmware essentially.

When you design electronics you have to produce millions of, it takes a couple of dev 'spins' and usually a couple of prod 'spins' to get to the mass market board. Usually the PMs, EEs, MEs and SWEs get together and spec out a schematic, then the EEs will create the first draft of the board. There is usually extra connectors and test points on this board to ease testing and development. Once they verify it powers on, I as an embedded software engineer, start producing the software to get it running, or 'brought up'. While that is happening EE testing is going on for all sorts of things like EMI, power, communication speeds, etc. Besides the software I actually write, the chipset vendor's drivers need to be added and tested as well, there are always little things that take longer than they should. I've lost a lot of schedule to very subtle issues with chips. As we progress along, the schematic or layout gets updated and new versions are produced. Maybe the traces need to change to reduce EMI, maybe a chipset isn't workign well or we find a cheaper equivalent and swap it out. Then once everything looks good we move to a production version, all the test points are removed, and we start putting in orders for the parts we need in volume. If you want a million of something you usually have to order in advance. Then you start bringing the factory online, helping with factory test software...and well the point is the cycle time for all this is like 6 months for a tight ship. More like a year if the kind of thing your making is novel to the team since you need a longer dev time.

I mean the EEs / MEs can certainly turn out a board and housing in under 6 months, certainly on a yearly cycle. Though for the current automakers, they don't have a team for this so it would take them probably 3 iterations to get good enough to actually scale it to a mass market car, and that is if their team has good talent and strong leadership.

As someone who works professionally on embedded software devices that update over the internet, car companies are stuck not because they can't get software talent, but because they have no ability to actually build the electronics alongside the software, which is ultimately what constrains embedded software. Without the right hardware, the constraints are just insurmountable, you can not do X feature because board A doesn't have the API to your MCU, or it runs some dogshit speed communication system that means you have 500ms lag. The feature is just unworkable, and if the PMs push it anyways you get what happens for the legacy car makers, terrible underpowered infotainment systems with no central design philosophy, stuck in an awkward, bad, middle between a full software stack and all buttons for everything. Their model of integrating 3rd party vendor computers just doesn't really work for this kind of thing; Tesla, Rivian, and the Chinese EV makers all manufacture all their own electronics, which lets them achieve the outcome. But you can not just roll all your own electronics in a year.

It is likely that Rogers agrees to pay Starlink a fee when Starlink acts as a roaming provider for one of their customers, where Starlink has slow and limited speeds but universal coverage. The industry has similar arrangements with roaming networks when you leave your country; some cell providers don't operate any towers at all. Starlink gets the fees, plus the right to transmit the LTE signals in a spectrum owned by Rogers, similar to the T-Mobile deal in the US, and Rogers gets to market that they have universal coverage.

The satellite emulates a cell tower, just one that is hundreds of miles away and moving very fast. So some tricks with the timing will need to happen since LTE expects the tower to be close and not moving. How big a cell is depends on how powerful the phased array beam former is on the satellite. The achievable data rates aren't very high so this is more a network of last resort when you are out of range of a tower.

Honestly, to just get moving, installing Doom emacs and selecting evil mode during setup. The basic keybinds are all Vim then, works great for me with minimal headache.

Seems like begging the question, they assume it is a CCP honeypot and then push the false dichotomy with the voice back end? *edit s/video/voice/

It seems like, if you wanted to help stop the wealthy from ducking paying taxes, one should just stop providing a special long term capitol gains tax and tax capitol gains the same as income. It simplifies the tax code, stops punishing workers who receive a wage over those who earn investment income, and doesn't require a bunch of new accounting to implement. My cynicism hat tells me the reason it isn't the policy goal is that it could actually pass in the US, the wealth tax likely never will.

I see the resale value of the recycling as subsidizing the cost of the recycling service. We pay for,(or your taxes do, depends on where you live) trash/recycling because then someone comes on regular intervals to take it. Part of that cost is "paying" them in the recyclables as well. Honestly the reduced complexity of the current system is nicer then having to pay me back like some sort of recyclables consignment scheme.

For sure, the FDA employs pharmaceutical engineers to regulate the companies. The FAA employs pilots and aviation engineers. Do we have a corollary for software? Sort of, in specific domains, but not really.

Well, people expect a company to not try to ride the high horse down the low road. I don't personally think Mozilla has really done anything bad, I get it, they are a real company, with real employees who work for a living. Sometimes the realities of running a company clash with their PR of being some sort of public good. FWIW, I like Mozilla, and a lot of their values, and the products they put out, but their marketing does leave them open to ridicule in ways that a company who always answers "money" to the "why did you do this?" question is not.

The metaphor seems apt to me, if anything, we should have and do have a much greater interest in regulation of automotive products, which themselves are absurdly complex. How is a regulator to know about various emissions, chances of explosion/fire, engine longevity and warranties? Engines can kill you with fuel leaks, poor materials engineering, or unknown manufacturing bugs. I'd argue that your car engine is much more likely to harm you in a significant way. Car engines had, and continue to have, albeit at a much lower rate,issues related to these things, and we came up with various bodies to help manage it. The people writing the legislation need to better surround themselves with people to advise them on the topics related to Google and Facebook, that is their job as a representative of their constituents; instead they come to the meeting barely prepared and ask a series of poorly worded and unimaginative questions, showing they didn't ask their aides to do even basic research on their behalf, while Google and Facebook bring Harvard lawyers to their corner.

In my opinion, a big thing many developers forget, especially those that are obsessed with design patterns and code rules, is that simple machines to solve complex problems are actually harder to design than convoluted ones. Leave a designer to their own devices, they immediately start spitting out way to many levels of indirection, it takes real thought to collapse those levels of indirection to something simple. Many less-experinced devs think that if they keep slapping on more layers, hide the problem more, more abstraction, they will reach some sort of inception-like base-case nirvana where the complex problem will magically become simple. But they are running the wrong directions. Simple, powerful, abstractions that make great tools great are generally pretty thin. They don't mask the actual problem, instead they provide good hand holds on it. C is a decent abstraction of assembly because it simplifies it, not because it hides it. All that being said, OOP, like many patterns, is perfectly fine if it makes a good abstraction. There is no one great pattern to rule them all.