TomTom like Here and Garmin are fighting to try to stay relevant in a market that has been seized by Android Auto and CarPlay.
The issue is the car vendors do not want to surrender their navigation and entertainment to Google and Apple as navigation system options at >$1500 and ongoing updates are precious margin and recurring revenue that they all desire.
With Android Auto or CarPlay they give that all up.
They are both dead men walking but like to do a full court press like this every few years to remind us all they still have the lights on.
i860 did well in embedded applications and for awhile was the mainstay in most RAID controllers and network communication processors. Not what Intel wanted from it but it did have a long life in such applications. I spent many years working on the i860 and i960 and learned to live with its oddities.
As for the Cell it was overly complex architecture and had remarkable performance under very optimized code. The hope was hand tuned libraries would address this; and compiler optimizations would take care of the rest. Neither happened in a meaningful way. We did two major projects with the Cell using it for real-time HDTV compression/direct broadcast applications.
Another one not on the list was the inmos Transputer. Again similar to the Cell; very complex and fast for its time; but not easy to achieve this performance. That was my first job as an EE - we used it on a GPS receiver ISA card in the early days of GPS. It was a good choice as very fast and could keep up with the signal processing that allowed us to roll code updates to add major features as various changes to GPS signals were rolled out (P-code on L2, SA being turned off, and later CA code on L2 being unencrypted). Our competitors had to redesign ASICS to get these new features which means long product cycles and hardware replacement.
Today I find myself doing a lot on the M1 series, as well as Epyc. Now you can give zero shits about clean optimized code and it still runs amazingly fast. Last time I had to do assembler or intrinsics was many many years ago - and I sort of miss that intimacy with the hardware to get the most out of it.
Good point and 10% is low. Let’s say you are in Bay Area and 1 hour commute each way - so 2 hours a day.
Even if you put in 10 hours at the office it’s still 20% lost time in the commute. 20% is a lot of your “working time” to be non-productive. And that is not quality time - that is stressful time that leads to burn out over time.
A RTO concept should factor this in. RTO for many people means working more and the employer getting less of your brains best output. It is a loss/loss. Why would either side of the equation wants this?
My team is fully WFH - 700 people globally - and the only time anyone is required to come into the office is when a job task can not be done remotely.
We’ve also reduced our office footprint 70% in the process; with the savings going to a WFH monthly stipend. We also arrange two social events a month to keep the in person connections alive; with numerous smaller groups having TGIF’s or other sorts of activity clubs.
Regus membership has given all the WFH folks a place to grab an office if they need to get out of the house for whatever reason.
To get over the “are my employees slacking off?” We’ve put in a simple peer review system that is working well:
1) If you are assembling a team for a very challenging and demanding project who are your top 5 choices?
2) If you could give out a spot bonus who would you give it to and why?
3) Is there anyone you feel should be reduced from your team and why (optional)?
This was bumpy as hell to get rolling but now working well. And yes, Q2 does drive quarterly spot bonuses based on responses.
Up42 only exist due to discounting pricing below commercial rates with some loss-leader pre-purchase discounting model.
History has shown that when you sell something for less then you pay for it; hoping that users don’t fully use their credits to cover that loss; that time is not on your side.
Banks, credit card issuers, and many brokerages suck from a tech stack perspective.
During the y2k times I did a lot of contract work porting old COBOL code to be y2k compliant. The number of seriously spooky security things was mind boggling.
Having mocked API's like you found is not a surprise. The fact they even bothered to use API's was a step in the positive direction versus telnet and ssh tunnels to pipe data around with hard-coded ip's and accounts.
Cruise has been a disaster inside GM for awhile now with a lack of progress to bring Super-Cruise to all models all across the US.
They have had several tenders for the data required to build out the Super-Cruise maps but these have all been a disaster as clear the critical knowledge is gone.
Hey Robbie - glad to see you. Yes, the iOS app was transferred prior to Nabu Casa ramping up their current approach.
Too bad; if you hung on you could have gotten some $$$ for it. It would have made me happy to see you financially rewarded as you did contribute a lot early on.
We've had 5 such approaches in the past 6 weeks of which 2 we have taken over.
It is going to get very very bad inside the next 6 months. We're still in the pre-swell phase before the tidal wave hits.