The degree isn't about "getting a high-paid job", it's about knowing what the hell you're doing once you get a job. Although, fair enough, it's quite plausible that not many degrees would meet that standard either.

There is a possibility of a short-circuit causing an engine shutdown. Apparently, there is a known fault whereby a short can result in the FADEC "fail-safing" to engine shutdown, and this is one of the competing theories as the wiring apparently runs near a number of points in the aircraft with water (which is a really odd design choice).

Now, I'm not going to sit here and tell you that (a) the wiring actually runs there (the wiring block diagrams are easy to find, but block diagrams don't show actual wiring paths), (b) that there is anything to indicate that water could reach such wiring in a way that could cause a short, or (c) that it actually did so. I don't have that kind of information.

All I can tell you, at this point, is that aviation experts are saying that a short at such a location would cause an engine shutdown and that Boeing was aware of this risk.

I will leave it to the experts to debate why they're using electrical signalling (it's slower than fibre, heavier than fibre, can corrode, and can short) and whether the FADEC fail-safes are all that safe or just plain stupid. For a start, they get paid to shout at each other, and they actually know what specifics to shout at each other about.

But, if the claims are remotely accurate, then there were a number of well-known flaws in the design and I'm sure Boeing will just love to answer questions on why these weren't addressed. The problem being, of course, is that none of us know which of said claims are indeed remotely accurate, and that makes it easy for air crash investigators to go easy on manufacturers.

It's easy to have unique keys in your spreadsheet so that you can easily relate information on different sheets to one another. The problem is, actually doing the processing that a SQL server would do trivially is irritating, and then it will be processed slowly every time. Whatever Excel does or doesn't cache, it isn't enough. You can do big complicated things, but they work slowly, and maintaining it is irritating at best. When you do complicated things either your formulas get long, or you wind up having to write code, or in fact often it's both. At that point you're way better off IMO doing it in something else so that at least performance is good when you're done, and you never have to screw with editing a long formula.

That's exactly why it should be in a database and not a spreadsheet. Spreadsheets are best when you have a reasonably limited number of columns. It's also a horrible PITA to use them as a relational database (it's more or less possible, but you don't want to do it) so hiding pieces of that complexity in other sheets in order to limit the data the user interfaces with on the main sheet is just a lot of extra work you wouldn't have to do if you used another solution.

It doesn't really matter where it fails, if Excel can do it and Sheets can't then Google has to admit inferiority to Microsoft which is never a good look.

It's far from indisputable. Indeed, it's hotly disputed within the aviation industry. That does NOT mean that it was a short-circuit (although that is a theory that is under investigation), it merely means that "indisputable" is not the correct term to use here. You can argue probabilities or reasonableness, but you CANNOT argue "indisputable" when specialists in the field in question say that it is, in fact, disputed.

If you were to argue that the most probable cause was manual, then I think I could accept that. If you were to argue that Occam's Razor required that this be considered H0 and therefore a theory that must be falsified before others are considered, I'd not be quite so comfortable but would accept that you've got to have some sort of rigorous methodology and that's probably the sensible one.

But "indisputable"? No, we are not at that stage yet. We might reach that stage, but we're not there yet.

This is a company IT initiative. IT can damn well unlock it. Had a customer with lots of Word and Excel users refusing to switch. The owner told them as of X date, MS tools would be removed, and Libre Office installed. They could train for the transition, or be fired for failing productivity metrics. Strangely, all were able to transition to Libre within the time frame. Their "huge spreadsheet" effort took me all of half a day to move to Postgres and PHP with data retention and history.

Due to a fundamental lack of understanding of what acting like a Christian is.

> It did happened before, but not on this scale and speed.

Check out Meltwater Pulses 1a and 1b.

Biden went around congress to fund a different genocide. Pretty words, but living up to them is another matter.

The problem is that the LLM only does one trick. When you start integrating other software with it, the other software's input has to be fed in the same way as your other tokens. As the last paragraph of TFS says, "every clock check consumes space in the model's context window" and that's because it's just more data being fed in. But the model doesn't actually ever know what time it is, even for a second; the current time is just mixed into the stew and cooked with everything else. It doesn't have a concept of the current time because it doesn't have a concept of anything.

You could have a traditional system interpreting the time, and checking the LLM's output to determine whether what it said made sense. But now that system has to be complicated enough to determine that, and since the LLM is capable of so much complexity of output it can never really be reliable either. You can check the LLM with another LLM, and that's better than not checking its output at all, but the output checking is subject to the same kinds of failures as the initial processing.

So yeah, we can do that, but it won't eliminate the [class of] problem.

Every tech company needs at least three things to start with: The business guy, the brain, and the lawyer. Ideally there should also be a marketing guy, but you can add them in later. Also, none of them have to be male, I just like saying "guy", buddy.

Yes and no, depending. If you are building an application in Excel, yes, all you said is true. If you are using one, no, none of it is. Spreadsheets can be set up such that the user just stuffs data into them where they are supposed to, then clicks a button to get results. Or maybe they don't even have to hit a button.

For the simplest useful example I can think of, I put together a spreadsheet which produces a table we use for asset valuation. This spreadsheet changes every year. If you load my spreadsheet, it will be correct for the current year. No user has to think about that at all, they just load it and get a correct table. You can extrapolate this to basically any level of complexity because Excel has VBA and you can script everything. The user just follows instructions, and they aren't even allowed to edit any cells which could break anything.

In case anyone is going this far down the hole, it turned out great. Even though the item was shipped from the US, because the seller didn't respond I got a refund without having to return it.

So far Aliexpress has been responsive to 100% of my issues and I only have needed to be a little patient and not expect everything to be solved immediately or arrive immediately.

I agree that a database-backed application is the right way to go for that much data. However, Finance used Excel because they could. We all like to talk about how bad an idea it is to do that, but Excel brought financial computations on large data sets to people who can't write any code. It has enabled thousands upon thousands of businesses to do things they couldn't do before without paying a programmer to develop a solution they cannot maintain. The fact that other spreadsheets regularly crater when handed data that Excel has no trouble with is exactly why we have so much Excel.

I like to use Drupal to rapidly create database applications which can handle a lot of data without writing code. But I wouldn't expect someone in accounting to be able to do that at all, and that just shifts the problem domain. Instead of getting stuck with Excel, now I'm getting stuck with Drupal. All of the logic just winds up in a different system that you can't trivially transfer it out of, so you have the same exact maintainability problem, except more people know how to work with Excel.