I've been watching the Flying for Money videos on this. He has interesting insight. It's a bit disappointing he just threw the data into an LLM for processing since it doesn't seem that hard to process, but otherwise he's been pretty good at bringing up likely possibilities based on Occam's razor. Mostly around negligence and most recently about junior vs senior pilot shyness vs ego.
What I don't understand from his analysis though was early on he said the tail wind increased a minute before landing which is too quick to have communicated. If that's true, we need to get better about this. A minute to send a message is ages. It should be automatic between the airport and the aircraft.
This is why I like it here. Somebody does irrefutably incredible work outside of their comfort zone, and somebody else goes "yeah actually I was born in that zone. Moulded by it. Here's how to improve it" (in a positive way)
Oh no, I wasn't, and that's definitely not my comfort zone. I mess with the printers and printing stack due to anger, not because I like it.
It's bugs on bugs, with bugs chasing bugs! So little developers, so complex stack with 25 years of technical debt, and little community around because it's not a sexy technology to be involved in.
That's why I have to dive deep and fix my bugs myself if I want to make it work properly as I would like it to. I also ended up making my own print server device, because China did not make a proper one for some reason for all these years.
This thread made me laugh. I worked on network printing software in Banyan VINES a century or two ago, and my wife always wondered why I hated printing software so much. Everything about the printing software stack, especially in Windows, is terrible.
> The solution is so elegant it’s still being used today. The newest versions of the CH-53 of fiber optics to detect faults in the newest all-composite blades. The older variants? They’re still going with the nuclear option.
Huh? So it's not really in use today as much as hasn't been retrofit out. Those are very different. This also doesn't read well. Maybe rewritten without proofreading
If it hasn't been retrofitted out, then it's still in use today. That sentence would only be incorrect if the new solution was retrofitted on all aircraft.
I think it's the "so elegant" part that's wrong. It's not still being used today because it's so elegant. It's still being used today because the old helicopters haven't replaced it.
I think elegance has to do with the technology of the time. Some clever design that is cheaper/better than you would otherwise think possible given the era. There are probably many elegant aspects to Roman aqueduct engineering, but they would still get replaced with modern materials during a retrofit.
I've done this for a cortex-m in qemu (meaning I wrote the chip and peripheral emulation code too for the timer, uart, sd controller with dma, and rcc). But I used buildroot. So much easier to keep track of everything and it's very easy to start with (unlike yocto). I recommend taking a look at buildroot.
You also don't need an MMU to run Linux. Just helps compatibility.
For me, it was reverse engineered. I am not an expert or even conversant in decompiling Android APKs. It took the decompiled Java (app was apparently written in Kotlin) and extracted all the necessary information.
Call it what you will, the point is I do not have the necessary skills to accomplish this task, but I was able to go from an APK to a working implementation that was controlling the lights in my RV in a couple of hours back in early April using whatever was the current version of Opus at the time. While I understand what it did to accomplish this, it might as well be magic for me, because it would take me months of free time to get to where it got.
It also wrote out documentation of the protocol so subsequent work would not require reading decompiled Java code.
Yeah simply put. The main thing I've focused on are precisely selecting output settings based on source quality, organizing downloads by channel and playlist automatically, keeping a searchable library, in-app player, and maintaining dependencies so others don't have to. The tools under the hood are great. I wanted to make the workflow easier to use and just get the best option without thinking about it.
Cheaper than an entry level human. But I've never used a model that size for development so idk if they could replace it. The work I do with even nemotron 550b, it's so dumb it's infuriating. Same with the free Google one (for anything sanitized/generic)
I have it on my 7900xtx but haven't compared it just yet. I might though. Honestly what I need is a lack of knowledge trained into the model. Maybe 27b will be better. I need it to want ground truth data, not hallucinate based on quantized distilled documents from training.
They're 60 years old. The amount of training data on them is endless. Books, textbooks, videos, blog posts. The problem is when you want you do something that doesn't have 60 years of freely available documentation of their functions and applications
Like software, there's going to be a lot of pressure to use well documented tools within the model's training set. Innovation on the outputs may increase, but infrastructure and tooling will slow down.
If I'm making a PCB and I see anything older than 20 years, even glue logic, I'm very suspicious. Last time that happened (inherited design) the FETs didn't saturate and the LDO was just a DO... If the tool wants 7400 series logic, I'm not using the tool. None of my work is >= 5v signaling
What I don't understand from his analysis though was early on he said the tail wind increased a minute before landing which is too quick to have communicated. If that's true, we need to get better about this. A minute to send a message is ages. It should be automatic between the airport and the aircraft.
reply