bobsomers

Just so we're all clear here, there is a lot of gobbly-gook in this answer which is either off target or irrelevant.

> a standalone device (the panda) that provides and enforces the safety model

What the actual safety model is that is being enforced is far more important here. The safety model could be "there is no safety guarantee whatsoever" and this sentence would still be true.

> All code is written in C to automotive safety standards including ISO26262, ISO11270, ISO15622, and MISRA-C.

26262 says practically nothing about software, what you really want is 21448. And 11270 and 15622 are super low targets for the amount of control authority available here.

MISRA-C is mostly a waste of time when it comes to safety. It gives software developers the warm blanket of having a checklist they can tick items off of, but does little to prevent unsafe systems from being built. Programmers have gotten pretty good about at least using tests and other analysis tools to make sure they're not doing the wildly stupid things that MISRA tries to prevent.

> 100% line coverage for all safety unt tests

100% like coverage is also rather trivial to achieve and doesn't say much. Branch coverage would be better, but being able to make some claims about state space coverage with exposure numbers would be what I'm expecting here.

Perhaps we disagree on semantics here, but IMHO I wouldn't call this "reasoning". It's essentially just data compression, which is exactly what you get by constructing an encoder network that minimizes loss while trying to maximally crunch down that data into a handful of geometric dimensions.

"Mankind doesn't quite yet understand the geometry of logic" is laying it on a bit thick with the marketing speak, IMHO. It's just data compression whose result is somewhat obvious given what the loss function is optimizing for.

If a structure capable of real reasoning was being built, I wouldn't expect LLMs to get tripped up by simple questions like "How many Rs does the word Strawberry have in it?". There are only two simple reasoning systems you need to solve this question. You need to learn the English alphabet and you need to be able to count to a handful of single digit numbers, both tasks that kids of age 3-4 have mastered just fine. Putting together these two concepts allows you now to reason your way through any such question, with any word and any letter.

Instead, LLMs perform how we would mostly expect a stochastic parrot to react. They hallucinate an answer, immediately apologize when it's called out to be wrong, hallucinate a new, still incorrect answer, immediately apologize again, until they eventually get stuck in a loop of cursed context and model collapse.

I'm not suggested that an LLM couldn't learn such a reasoning task, for example, but it would need to look at many training examples of such problems, and more importantly, have an architecture and loss function that optimized for learning a mechanical pattern or equation for solving that kind of problem.

And in that regard, we're very, very far away from LLMs that can do any kind of generic reasoning, because I haven't seen any evidence that those models are generic enough that you can avoid learning lots and lots and lots of specific ways to approach and solve problems.

One thing I think it's critical to keep in mind is that improvisation upon contextually relevant data in your compressed knowledge base is not reasoning. It might sound convincing to a human reader, but when it's failing at much simpler reasoning tasks the illusion really is shattered.

> I think the phrase "stochastic parrot" is misleading and has fooled millions of people into thinking that LLMs can't do genuine reasoning about situations they've never seen before, nor been trained on, which is wrong because LLMs definitely are doing genuine intelligent reasoning.

Can you describe specifically which part of an LLM architecture does the "reasoning" and how it works? Because every architecture I'm familiar with is literally just a fancy way of predicting the likelihood of the next token given the stream of previous tokens and the known distribution of token based on the training data. This is not reasoning. This is simple statistical prediction, making the "stochastic parrot" analogy actually quite accurate.

> What model training is doing is building up a semantic space of vectors from which astronomically large numbers of true facts and ideas can be derived during inference. I mean like a number of facts larger than the number of molecules in the known universe. A googolplex more facts than the sum of all of humanity has ever "thought".

Sort of. It's like an extremely lossy compression process which has absolutely no guarantee that "truth" was maintained in the process. Also I'm extremely dubious of your claim that it can accurately encode "a number of facts larger than the molecules in the known universe" given that it's trivially easy to get the best LLMs to give you an incorrect answer to a question any human would easily get right.

In my experience, Bazel is great if you are a Google-sized company that can afford to have an entire team of at least 5-10 engineers doing nothing but working on your build system full time.

But I've watched it be insanely detrimental to the productivity of smaller companies and teams who don't understand the mountain of incidental complexity they're signing up for when adopting it. It's usually because a startup hires an ex-Googler who raves about how great Blaze is without understanding how much effort is spent internally to make it great.

Just because the argument is "common" or "uninspired" doesn't make it wrong.

Certainly different "NIMBY" complaints can have differing levels consequences based on whether we're talking about sweeping changes to the skill level of most GA pilots vs. do we build this new apartment building here or not.

When I worked at iFixit ~12-13 years ago most of the site was already aggressively cached whenever possible, and I’m sure it’s only gotten better since.

They are no strangers to bursty traffic. We would get insane bursts of traffic many, many times greater than typical wherever a teardown of a new iDevice was published shortly after release.

If Kyle and the devops folks there are noticing it, it’s definitely disruptive behavior.

Amen to that. Software Engineering as a discipline badly suffers from not incorporating well-known methods for preventing these kinds of disasters from Systems Engineering.

And when I say Systems Engineering I don't mean Systems Programming, I mean real Systems Engineering: https://en.wikipedia.org/wiki/Systems_engineering

> How is mission-critical software designed, tested, and QA'd? Why not try those approaches?

Ultimately, because it is more expensive and slower to do things correctly, though I would argue that while you lose speed initially with activities like actually thinking through your requirements and your verification and validation strategies, you end up gaining speed later when you're iterating on a correct system implementation because you have established extremely valuable guardrails that keep you focused and on the right track.

At the end of the day, the real failure is in the risk estimation of the damage done when these kinds of systems fail. We foolishly think that this kind of widespread disastrous failure is less likely than it really is, or the damage won't be as bad. If we accurately quantified that risk, many more systems we build would fall under the rigor of proper engineering practices.

I don't think it is, to be honest. All three of those examples are clearly official acts. The President is commander-in-chief of the military, and is also responsible for granting pardons. The key piece of the ruling which lends credibility to her examples is that any motive or details behind the official acts are immune from scrutiny.

The only real difference is whether the acts are official or not. So the President is allowed to order the military to assassinate a political rival, but not to pay a private hitman to do so.

It's a pretty ridiculous and indefensible stance from the majority opinion.

> I'm forced to use a Macbook for work, but would never use it if given the choice. MacOS is for people that value style over substance and non-technical people, just like everything else Apple.

You’re obviously free to prefer whatever platform you please for whatever personal reasons you please, but the conclusion that macOS is for non-technical people is insanely ignorant.

No, it’s not. Identifying which problems are worth solving (regardless of their complexity), and solving those is worth promotion.

Lots of engineers have a fascination with solving complex problems purely for the sake of solving them. When you make that your criteria for promotion you end up have to do many rounds of layoffs in harder times because you’re staffed to the gills with people solving complex problems that deliver little to no actual value.

> How is it demonstrable that they aren't worth $1m per year?

Probably because of this:

> How does any company burn $36 billion on a headset they got handed a prototype for?

Calling California a “failed state” over this seems absurd when the most extreme example in recent history is the Texas freeze power outage in 2021 which left 4.5 million homes without power for several days during winter storms. Somewhere between 250-700 people died because of it.

The problem with Bazel is that a sandboxed build environment is useless unless you also have a hermetic runtime environment, and Bazel does nothing to solve this problem. While you may be able to consistently build, your runfiles tree can easily be un-runnable on any system except the one that built it.

When I was heavily using Bazel ~3 years ago we had made substantial changes to the Bazel source to try to support this, but ultimately couldn't get it across the finish line without making changes to Linux's dynamic loader. After talking to a few folks familiar with Blaze, it seems that's exactly what they've done inside Google to solve the problem.

Perhaps the situation has improved in the last 3 years, but my general experience with Bazel is that it made extremely lofty claims and delivered on very few of them.

Everyone makes mistakes, it's about learning from them and what you change to try to make things better in the future.

Generally speaking, the west has been significantly improving the living conditions and human rights protections for its citizens over the last several hundred years, many times in direct response to some horrible mistake that was made and then subsequently learned from (slavery, Vietnam, etc.)

The same cannot be said at all about Russia. All the intelligent, brave people who could see through the propaganda or who had the bravery to do something about it have largely either been killed off or emigrated away at this point. The country has been in a continuous cycle of totalitarian suffering for hundreds of years, with no end in sight.

> Yes there are some exceptions like Bucha, Belgorod, Charkov, Yalta or Maripol events

It's pretty disgusting to reduce what happened to civilians in those cities to "some exceptions".

You can't drive if you only use the current "frame" of data as the basis for your decision. Imagine driving on the highway, a comfortable distance behind a lead vehicle.

The planning software would want to slam on the brakes without predicting that the blob of sensor data in front of you is going to continue moving forward at highway speeds. That motion prediction enables the planning software to know that the space in front of your vehicle will be unoccupied by the time you reach it.

A similar prediction error was the reason Cruise rear ended the bendy bus in SF a while back. It segmented the front and rear halves of the bus as two separate entities rather than a connected one, and mispredicted the motion of the rear half of the bus.

> Art can become a craft again, not a career.

This sounds nice, but having worked with many artists in the past a lot of them do it because they're good at it, it's enjoyable enough, and it pays their bills so they can eat.

Telling them, "You're now free to make the art you really wanted to make!" doesn't bring much comfort when you're taking away their ability to put food on the table.

> The same people that minimize what people like Musk have accomplished.

Oof, I agree in general with what you're saying but Musk is a bad example. His companies have been successful in spite of him, rather than because of him.

> No matter how you calculate it, 737 Max been through more crashes than A380, unless you ignore the previous two crashes, obviously.

Correct, but again this is too simplistic of a view and it's not a question that gives you any real information.

Consider a brand new airplane that has never flown. It's also been in zero crashes. Is it obviously safer than the 737 Max? Clearly not, so what is the real question you want to answer?

What you really want to know is, based on the existing data, how likely is it that I will crash if fly on an A380 vs a 737 Max? This is question that ultimately hinges on the predictive power of the existing data, and when you are dealing with rare events, the data volume makes a huge difference in your confidence intervals.

Without drowning the conversation in details, if you modeled crashes as a Poisson process (which may or may not be appropriate), there are absolutely situations in which a 737 Max with 2 crashes is the obvious statistical choice over an A380 with none, simply because you have so much more data for the Max that you have tight confidence intervals around the flight not ending in a crash.

With much less data on the A380s side, the confidence intervals are wider and it's possible that it's actually more likely that your A380 becomes the first crash than that you experience the third 737 Max crash!

I'm not saying this is definitively the case, it would require lots of specific data I don't have access to and a subject matter expert to sign off on the modeling, but X is not safer than Y simply because X has a fewer total number of events.

> It already has two crashes under its belt, compared to other models that never had any crashes (like the A380).

You can't come to any conclusions from simple math like that because it isn't corrected for flight hours and exposure. There are literally 10x more 737 Max's delivered so far than there are total A380s left flying, and they're constantly booked doing short to medium haul flights all day long rather than a single long-haul flight per day. And given that takeoff and landing are the riskiest phases of flight, it should also probably be corrected by flight cycles, not pure flight hours.

It's nowhere close to as simple as you make it out to be.

> How about stop putting lipstick on a pig and retire the whole 737 entirely?

What? The 737 NG family (along with the Airbus A320 series) have been the workhorse of short to medium haul air travel for decades now. Throwing out the 737 entirely is a nonsensical, knee-jerk reaction suffering from serious recency bias.

> A large percentage of the MAX faults are due to Boeing doing everything to make a plane that the original design simply cannot accommodate. At what point somebody says: "No, enough!" ?

And your solution to that is to throw out all the perfectly functional and flight-proven-over-decades aspects of the design and start completely fresh? If you're concerned about the process which produced the Max, what gives you any confidence that a fresh design wouldn't have 10x the issues that the Max does?

  - No additional consumption of land
  These benefits are comparatively minuscule

I think that benefit is significantly less minuscule than you make it out to be. For rural installations, sure, but in high density areas the cost of land can be absolutely insane, and those high density areas tend to have high power demands just due to the density of humans that live there.

You can put all the ground mounted panels out in the countryside hundreds of miles away from the density, but high power transmission lines are also expensive and dangerous to maintain. Generating the power right where it's used completely eliminates a problem which has serious negative consequences like wildfires.

Correct, but I've seen a lot of confusion that its a systemic problem (ala MCAS) with the Max family. It doesn't look that way. It looks like a manufacturing problem on one particular variant.

FWIW, it's only the Max 9s which have this issue. The Max 7s and 8s don't have an exit in that location (too few seats) and the Max 10s require an exit door to be installed in that location, not the door plug.

It's only the Max 9s that have the option of the door plug, if the installed seat count is below the threshold where an additional exit is required.

I don't understand why you think a search engine requires the use of "real engineering skills" like picking and choosing libraries and identifying which opportunities will yield fruitful optimization.

Literally all of the listed projects, text editors, compilers, operating systems, and ray tracers, can exercise the exact same activities.

I'm more inclined to think that your comment is really more revealing about what kind of knowledge is in your own personal wheelhouse. Having worked on a ray tracer that was subsequently used on many feature films, I can assure you that all of your bullet points apply to that project, too.

It's much more a matter of whether you want to do something small scale and fun, or whether you want to suck all the joy out of it by applying the same soul crushing constraints we already get paid to do in our day jobs. Bleh.

> Cruise did the wrong thing by lying to government regulators.

This is exactly the core problem. It wasn't the crash. Regulators expect there to be problems with new technology, but they want to do deep investigations when they happen so everyone can learn from them. This could had been a great learning moment for Cruise, the regulators, the rest of the AV industry, and the general public.

But then Cruise lied to the regulators, which is a HUGE no no. They don't take kindly to industry trying to hide information like that.

> Sennheiser is the last decent manufacturer of headphones.

Are you just not familiar with many headphone manufacturers? I had Sennheisers years ago and they were fine, but since then I've had headphones from Sony, AudioTechnica, and Shure (just to name a few) which I've much preferred to the Sennheisers I had.

> It's more about lower management becoming less needed. If a dude managing a team of 5 and not contributing anything can't have f2f meetings all day he suddenly feels obsolete and fears for his future at the company.

I don't know about that. In my admittedly limited experience as an EM of 4 ICs, I'm drowning in work, mostly because they all do great work and are now double and sometimes triple booked on projects because we haven't been allowed to hire anyone. It's more than a full time job to keep a small team supported and I don't remotely feel like I'm obsolete because the company could chose to WFH.

I've personally noticed, since we've been back in office, it's been easier for those ICs to have conversations with other people in the company that they need to work with, as well as have informal brainstorming sessions with each other. This is great for me, because simply being a conduit of information between other people isn't the most efficient use of my time, so I don't really feel threatened by that. All of them have told me they've actually appreciated the hybrid schedule and the time in office for some of the week, and some of them told me that when I was a peer IC (before being their manager).

Our work is definitely more experimental/R&D/unproven though. Frequent communication, collaboration, and brainstorming is critical for success. If you're doing the kind of work where you can sit down today and create a year's worth of feature tickets then maybe it skews in favor of the office being more of a distraction.

> Of course he will sacrifice his 5 reports to feel more important so he communicates up the chain that it's absolutely vital that they return to the office. 5 guys will commute for a combined 50 hours per week so that 1 guy who doesn't do anything can keep his job.

I don't get the impression anyone at the executive level of a BigCo is collecting feedback from low level managers about whether they should RTO or not. And even in the Bay Area, 2 hours a day of commuting is on the extreme end. Everyone on my team has a total of a 1 hour commute or less, and in my case that includes a day care drop off and pick up. Personally speaking, my commute wouldn't change even if we were 100% WFH because my home and the office are equidistant from day care.

We do have a peer IC who has a long commute though and it's not great for him. I do wish there was more flexibility on a case-by-case basis to tweak the number of days he's in the office.

Look at the 1010music Bluebox. It's about twice the size of the TX-6, half the price, and infinitely more usable as an actual mixer and multitrack recorder.

Eh, I feel like most people would never use 80% of the "features" of the TX-6, which mostly feel like bolt-on justifications for its price tag. If you want a super portable mixer, something like the 1010 Bluebox is infinitely better at being a proper mixer than the TX-6 is, for half the price.