Using Chat GPT to encroach on the lucrative search/advert market would have been fine if Google hadn't been able to catch up. But they have. So why would everyone keyed into the Google eco-system bother switching over to Open AI adverts/search now?

It's surprising Altman didn't push for this while he was ahead - that would have been a decent strategy. But instead he went on this crazy train about how they would have the super-intelligence blah blah blah.

The big problem he has now is that if open Ai employees see that their stock options might end up being worthless, they won't stay around, especially since Google/Apple/Meta can give them big $$ right now, not at some hypothetical IPO that might not happen anymore. If he starts bleeding the best employees he is screwed and the end will come quickly.

Even when I studied in the late 90s it was like this for anything applied. There was a push to make the degree more 'industry relevant' - i.e. companies want people who could do Java or Protel, not solve partial differential equations or analyse matrix decomposition techniques. The university wasn't really setup for this, so some of the younger professors who had used those tools as part of their research would run the courses.

Most of the faculty at my school were pretty switched on, so I think it was fine as an introduction. Fortunately outside a few of these introductory courses, most of the course was extremely theoretical (kinda the point of going to university but whatever).

I imagine in the mean time university has become much more vocational, so the demand for these sorts of 'end of the pipeline' skills has grown. The latest thing is AI, so here we are.

This is an embedded system in a high reliability environment. The way these things work is keep-it-simple to an absurd level. I bet you this is some dinky 8-bit RISC CPU that's built on a crazy big process node, and the production QC trace on it will be insane. On these sorts of systems, if you want ECC, you add it to the firmware, but only in the areas you need it, and only after a thorough analysis of (a) the problem it is solving (b) the amount of ECC required to solve that problem (c) the best algorithm to meet the identified objectives. There are many ways to do ECC - including just duplicating variables n number of times - which has the advantage of being very easy to implement and formally verify while being less efficient at RAM utilisation vs a Hamming Code, but even that depends on the statistics of your error conditions.

The point is that, sure, they could add some generic hardware ECC, but that ECC can fail (if there are too many bit flips, if the ECC logic itself gets bit flipped, or there is a design error for a particularly input sequence, etc etc). Maybe you win out overall, maybe you don't - the problem is that you'd have to run a complete analysis to know. That means you have to now add ECC hardware failure modes to pieces of software that did not need ECC before. I mean, sure, maybe you win, but maybe you make it worse, and have to develop extra software to deal with the new hardware failure modes. Whatever the outcome you'll have to do a boat load more documentation to make sure.

I bet you it took them less than a day to identify a fix for the code and update it. It would have then been thousands of hours of work to update all the documentation and thoroughly verify the new code against all the other requirements on the system.

If you want a good example of how quickly these supposedly simple systems can get complicated, look into the CAN bus CRC bug. This fault is present on EVERY system that uses the CAN bus (basically any vehicle since the 1990s). It is an extremely subtle bug involving the error detection system that is obvious once you're show it, but the very smart people who designed it, along with thousands of engineers who worked with it, didn't spot it for around a decade. Even worse when they developed CAN 2.0 they tried to fix the bug, and didn't even get that right.

You needed a handbook for that?

Anyone who ever went to a business meeting could've told you that.

By my experience, it takes only 4 things to make a meeting productive: a) someone is in charge of the meeting and moderation, b) that someone had time to prepare, c) everyone in the meeting has received an agenda with enough lead time to have read it and (if necessary) prepare their part, at least a bit and finally d) there is at least a simple protocol of the meeting for those who couldn't attend, those who dozed off in the middle, and those who claim next week that something else was agreed on.

As long as that greedy boss pays you enough to live ,who cares

It'd make my year if he went back to that. Ever since Hasbro bought them, they've looked like these useless contraptions made by Dr. Seuss; we need to get back to the CPS2000 and the other turn-of-the-century models that were actually effective at their intended purpose.

It's only a horrible business plan if you're not being subsidized by people who like the idea of capturing that freedom.

Many people don't actually read emails. I sympathize with people who hate meetings, and I admit many are unnecessary. But acquiring information from other places in the company is an essential part of most jobs, even if you don't want to. Half of the problem with many meetings isn't that they're not needed, but that the participants wish they didn't have to do that part of their jobs, and instead would rather be doing a different thing.

Time for the US to nationalise all things vehicle. Registration and taxes. Emissions and smog checks. Safety inspections. Dealership laws and regulations. Driver licensing (including for trucks, busses etc). Road rules. The lot.

It is possible to preserve previous structures for compatibility while accepting changes for newly compiled software. For example to support 64-bit time_t on x86 build add the compiler flag D_TIME_BITS=64. Decades ago similar changes were made to allow for handling of large files in Linux without breaking backwards compatibility.

My son works for his high school newspaper. He brought in a battery powered Panasonic cassette recorder to do interviews, complete with the cheesy chrome microphone it came with. It got people more interested in the interviews and he got some good copy out of them. He also brought in a portable typewriter we found on the side of the road being thrown away. He fixed it up and uses it to type notes in newspaper class. Everyone in that class loves it.

The theater I go to has none of those problems. Tickets are cheap, munchies are also not obscenely priced, the picture and sound are great and the closest I have come to distractions and noise was when I went to see Moana 2 with a bunch of kids in the theater (and even then it wasn't distracting enough to be a problem)

And the experience of seeing a movie on the big screen is going to be far better than watching it on my 32" 1080i TV with inbuilt speakers or my 1080p computer monitor and somewhat basic Creative Labs speakers.

If it was a cheaper, had a notchless and holeless IPS display and was able to boot OS images from SD card like the PinePhone I would pick one up. Would also love to see one with an integrated LoRa radio.

No because at any reenable speed they would have to totate rather faster than ideal, or are you talking about wheel thickens not diameter?, well on that subject would a 2mm thick weel be able to carry enough weigh? For passenger coaches maybe, for duoble stacked intermodal cargo, I doubt it. Disclaimer: I'm not an engineer so if anyone with the relevant exoertese would like to correct me I would appreciate it

seriously, slashdot? It's 2025 and you still can't do the Euro sign?