roeles

> Application of theory is key.

What works for me is deliberately testing something that I recently read in a project. Even if it is something that works, rewrite it from the perspective of what you just learnt.

This makes you look at problems from different perspectives. And if you get stuck, it's easy to ask for help.

Work only permits wsl1. I use vs code with the wsl1 plugin. The editor runs on windows, but it is as if you're on Linux. Terminal is Linux, Filesystem looks like native Linux...

> No bug has ever been found in the “released for flight” versions of that code.

I thought that at least his crash was a result of bad constants in flight software: https://www.youtube.com/watch?v=SWZLmVqNaQc

The first comment appears to agree with me.

My grandmother was hit with a ruler on the left hand. She learnt to write with both hands as a result.

With the right hardware this might work for you: https://github.com/OpenHantek/OpenHantek6022

As a candidate, I was asked once "tell me something about yourself that I can't read on your cv". I could not help but tell what was on my mind outside work.

I have used this question for candidates as well. I received responses about hobbies, families, quirky preferences... It's a great way to get to know someone personally. I imagine it works well for getting to know future team members and bosses too.

I tried editing my area to reflect road closures due to construction. It was surprisingly difficult. Spent an hour searching online. My edit was denied by the reviewer (I used the wrong method) and the closure was not reflected in the map.

Google maps was a one minute process and it was reflected in the map after about an hour. OSM stayed outdated for weeks.

From this experience I am tempted to conclude that OSM needs to make mapping easier.

Even if it makes just you happy, it's impactful. You are the person others have to put up with. Making yourself happy improves the world for those around you.

I don't see any incentive to move away from C. I was discouraged to use C++ even. The amount of extra work is huge.

I don't know a lot about Rust myself, but the impression I get is that it is a bit less obviously deterministic than C.

Things boil down to (IMHO): - every requirement must be traceable to code - every line of code must fulfill a requirement - any dynamic behavior (for example heap allocation) must be proven to work under all circumstances

I currently work on certified avionics. I don't see rust used there in the next 10 years.

Even using OO over plain C adds a huge amount of extra work already.

Related talk by Alan Kay: https://youtu.be/D43PlUr1x_E

> You'll always stall if you go too slow to get enough lift.

The amount of lift needed is determined by the load factor. In a turn, or when a glider launches via a winch, the load factor is higher than in level flight.

This means that the stall speed varies with load factor.

On the other side, you can still not be stalled below the straight and level stall speed, if the load factor is low enough. In parabolic flight you can see this, and with a load factor of 0 you cannot stall.

Please Google udp hole punching

This thread has so much valuable information! I fly gliders, and our avionics use bright backlights to make the screens usable in direct sunlight. We need about 1200 nits. Since everything is powered by 12 volt batteries, the backlights are a large factor of the total energy consumption. In the past the ipaq 3825 series was liked due to its transflective screen.

I would recommend replacing macros with constexpr to allow type checking.

I don't think you can make general statements about STL. I have seen a Pi4 outperform a core i7 in very specific cases. That was really unexpected.

In other cases I saw a lot of runtime spent on std::map.

I think the best advice is: learn to use a profiler.

Why not rent one for a week and see if you really like it that much?

Recent tests with link time optimization give me the impression that code which is not actually called is not included (or even resolved). If you can convince the compiler that the destructor is never called, it might not include it.

Given that you are most likely to use the horn to prevent an collision, and that during collisions the airbag deploys.. I would say that the center of the wheel is just about the worst place to put the horn button. Slapping yourself in the face somehow seems worse than the airbag deploying properly.

For gliders the naca airfoils have been abandoned around 1970, when the first glasfiber composite gliders were made. We mostly use airfoils from German professor Wortmann (FX) , Quabeck (HQ) or Boermans (DU). The naca airfoils are still used in wind turbines though.

Do these devices allow for effortless OTA updating?

> and I think KiCad plays a major role in that

I'm not trying to rain on your or KiCad's parade, but what did it for me was EasyEDA's integration with JLCPCB's part library. Combined with JLCPCB's assembly service. For just a bit of extra money I now don't have to worry about footprints, availability, exporting the right files, creating a BOM, etc. I can just order at JLCPCB right from EasyEDA.

I really wanted to use KiCad instead of yet another online tool, but for my first steps this just makes more sense.

That would be great!

Thanks for the book recommendations!

Thanks! Will check those projects out.

Thanks for your insights!

So that's what it's called! Thanks!

In the past decades research has been done about the sonic boom and how aircraft shape influences it. This is one of the reasons new companies are looking into supersonic flight again.

Lots of complaints about stream performance here.

std::sync_with_stdio(false);

Helps with that a bit.

There is "the tao of leadership" by John Heider, which is specifically aimed at this