|
Some Mazda owners in the Seattle area are stuck with bricked infotainment systems after listening to a particular radio station. Hopefully it's a good radio station
That's...an interesting bug.
|
|
|
|
|
Quote: "These customers should contact their local Mazda dealer, who can submit a goodwill request to the Mazda Warranty department on their behalf, order the parts, and schedule a free repair when the parts arrive," Surprising. The cynic in me says that American brands would have stuck to 'Out of warranty - pay up suckers' as a response to get the $1,500 from them. Of course, that quote doesn't guarantee such also won't be the case for those Mazda owners, but it makes it sound far more likely they will get it fixed without cost.
|
|
|
|
|
This got enough coverage that Mazda may be trying to ward off a NHTSA ordered recall on all Mazda vehicles with that head unit in it.
|
|
|
|
|
Doesn't seem to have much to do with NHTSA, but overreach is a thing nowadays. Besides, it's what they deserve for listening to NPR.
|
|
|
|
|
It's always NPR.
(I sense a fundraising opportunity; send us money or we'll brick your infotainment system. I mean, we'll stop it from happening. This isn't extortion.)
|
|
|
|
|
The Black Hawk is kitted out with Sikorsky Matrix autonomous flying technology. I vaguely recall this movie
Or am I just confounding "Stealth" with "Blue Thunder"?
Either way: "how could this go badly?"
|
|
|
|
|
Yes, Blue Thunder was a manned helicopter, Sheriff Brody got tired of them damned sharks.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
|
I don’t do creepy, crawly bugs, but software bugs are a different story. I relish the opportunity to hunt and kill particularly nasty software bugs. Step 0: apply for funding
|
|
|
|
|
Open-source software has always been more secure than proprietary software, but that doesn't mean it's "secure." Mo' eyes, mo' dough
|
|
|
|
|
Sorry, but open source software security has always been on par with proprietary software. The real problem with open source security is that far too many open source systems either depend on poorly or non-maintained components that never get updated or even if every component is updated, the system itself is never updated because of fears that something will break during the update. This actually reduces open source security.
|
|
|
|
|
Given the severity of security problems with open source, his premise falls flat.
(To be fair, it seems the worst breaches we're due to incompetent implementation.)
|
|
|
|
|
Threat actors have started distributing fake Windows 11 upgrade installers to users of Windows 10, tricking them into downloading and executing RedLine stealer malware. As opposed to the real upgrade installers?
I know, I know - I actually like 11 for the most part (mostly as I have trouble telling it from 10 until I try right clicking on the task bar to get the task manager)
|
|
|
|
|
Kent Sharkey wrote: until I try right clicking on the task bar to get the task manager Does CTRL+MAYS+ESC not work in Windows 11?
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Which is the "MAYS" key
Probably, but my "finger memory" is the right click method. I suppose I need to unlearn my old, useful habits.
TTFN - Kent
|
|
|
|
|
Sorry... MAYS is the spanish version of SHIFT
My brain was already
CTRL+SHIFT(left one)+ESC
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
As productivity tools get more plentiful, using the right ones can make or break your company’s retention plan. "It's a poor craftsman that blames his tools"
Is this really where we are these days?
|
|
|
|
|
Enterprises use the Microsoft 365 environment. If I had been the hiring manager in that opening scenario case I would have been breathing a sigh of relief for not having hired "Tony". He would have been a continuing pain in my side. Any one who would rather not make the adjustment to what the employer uses I'd rather not have working for me.
|
|
|
|
|
Time is your most precious asset and slow build is high in the list of developer’s productivity killers. They missed one option, "Whine to your boss until you get a faster computer."
|
|
|
|
|
A former employer was very good at testing, literally taking days to complete. So we started a clean 'release' system rebuild when leaving work Friday afternoon, and it would be complete on Monday morning, ten days later.
So we bought the very fastest machine available, which got all tens of thousands of regression tests complete executed for Monday morning, three days later.
Needless to say: The management never regretted the investment. (Most likely, it paid for itself in a single product release.)
|
|
|
|
|
I'm surprised they didn't get 3 or 5 more of them so they could do nightly test builds by splitting the test suite into parallelizable parts.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
The main time stealer was a huge (and I really mean huge) collection of regression tests. But for releases, the established procedures required that all of them should be run on the final, fully integrated release candidate, which should be a 100% clean build.
We didn't have any issue with nightly builds: The unit, module and subsystem tests completed overnight. We did have subsets of tests for that purpose. For a release, piecewise regression testing would not be 100% trustworthy.
I fully support the release test regime practiced by that company. The regression tests had grown to a big bottleneck in the release procedures, and it was cured by that investment. There were no similar bottlenecks in other areas.
Additional note: Every now and then a proposal came up to reduce the size of the shipped code by removing test related code inserting conditional compiling directives. Every time that was suggested, half a dozen senior developers each produced a handful stories of where the test code had been extremely useful in diagnosing issues at customer sites. Furthermore, the test regime depended on this code: Running all the tests on a a system built with this code, and then shipping a system without it meant that you were shipping a system that hadn't been tested.
|
|
|
|
|
WTF are these people building? None of our apps (most are largish ASP.Net web sites, circa 2009) take more than 30 seconds to build, and most of them take less than 10, and most of those take less than 5. VS Build performance has never been an issue with me.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I have asked myself the same question, but it happens, so it must be possible.
First time I was really shocked was when I learned that the first, limited release of the software for the ITT System 12 digital phone switched counted one hundred million lines. (I heard rumors that when the project was terminated, the code base had grown twelve times, to 1.2 billon lines.)
A friend of mine worked on the toolset used for this code: The linker ran on a 16 bit machine (this was in the late 1970), but hit one implementation restriction: The table for exported symbols from a single module was indexed with a signed int, limiting the size to 32768 symbols. What the elephant? I can imagine a single module importing more than 32 ki symbols, but not exporting! They made a quick fix changing the index to a uint, but the next major linker release allowed the export of 4 Gi symbols, which should be enough for everyone. At least for a few years.
Also, there was a struct definition - with variants, that explains it - filling 8300 lines. Make a hardcopy printout of that definition, and you have a book of 115 pages!
This was 40+ years ago. The software world have had lots of time to develop even more extreme examples.
When I today hear about extreme build times, the compile and link time is usually a tiny little fraction of the total. Almost all of the time is spent in unit tests, module tests, integration tests. (For System 12, the compile time was in the order of days and weeks.) Pressing F5 is just doing the required compile/link work; testing is a different matter. And it recompiles only what is needed - 'make' is 40+ years old.
Most test frameworks I have seen never discovered 'make' They rerun the same tests again and again, a unit test is rerun for every module where the unit is used, a module test for every subsystem including the module. All tests are run again, even if not a single code line affecting the unit or module has been changed since the last test run. So for total build times, I think there is a lot to be done on the test part.
Disclaimer:
Maybe there are test frameworks handling such issues nowadays; I haven't really studied them for 2-3 years.
|
|
|
|
|
Seeing as how he's complaining about 43 second builds, I think it's not really a problem. Unless he's hitting F5 at the end of every line.
Quote: Our main solution for NDepend consists of 37 projects, including test projects. Compiling them all takes 43 seconds on my beefy laptop (64GB RAM, Xeon 6 Cores, 2x 1TB SSD). Btw, developing with a powerful machine is essential. Each saving done on hardware will likely costs a hundred more in terms of developer time and focus wasted.
TTFN - Kent
|
|
|
|