HN user
The 737 example is actually quite fitting. Sure, a long time pilot will perceive the interface as invisible.
But if you contrast it with the complexity of the same functions on other aircraft, you start to see how complicated it really is. The F-22 for example handles a lot of faults (like engine fires) automatically.
Regen doesn't even persist with kia. You have to press the paddle to add it every time you start the car.
Not on my ev3. The only time it changes Regen is when I hook up a trailer.
The latest video in the saga
There is a Bambu p1s on its way to me. I will exclusively print ASA and my impression was that the p1s has a good track record with ASA. My prints will be mounted in glider cockpits and require the UV resistance.
Money is a bit tight, so I decided against prusa as my first printer.
I am curious if anyone has good experiences with alternatives for the p1s with regards to ASA printing?
Any experiences printing ASA with it?
This is also used in laser communication systems to find your peer.
Since we can't really formally prove most code, I think property based testing such as with hypothesis[1] would make sense. I have not used it yet, but am about to for stuff that really needs to work.
The F150 has an EV variant that will probably be affordable by Dutch road standards, given the general price of the average EV.
The government is ramping up the tax rates for EVs. They will pay road tax based on their weight in a few years.
All of the things you mentioned are designed and tested incrementally.
In a different way that what is proposed in this thread. We don't build a small bridge and grow it. We build small bridges, develop a theory for building bridges and use that to design the big bridge.
I don't know of any theory of computing that would help us design a "big" program at once.
Not saying you're wrong, but I wonder what is the differentiating factor for software? We can build huge things like airliners, massive bridges and buildings without starting small.
Incremental makes less sense to me when you want to go to mars. Would you propose to write the software for such a mission in an incremental fashion too?
Yet for software systems it is sometimes proposed as the best way.
Very cool, thanks for sharing!
Gliders utilize Laminar profiles, while airliners use turbulent profiles.
The Laminar profiles perform better, but only when uncontaminated (no bugs or rain). Contaminated turbulent profiles perform better than contaminated Laminar profiles. Since regulations state that you should carry fuel for the worst case scenario, it does not yet make sense to design airliners with Laminar profiles.
Naturally, manufacturers are looking for ways around this.
Weight affects speed with minimum sink. That affects the diameter of the circle you fly. Since thermals have more lift towards the center (assuming perfectly circular thermals), you are not able to circle in the strongest lift. So you climb more slowly.
You can glide faster with the same L/D, so that might be worth it if you try to optimize for speed.
The same angle, but at different speeds. The speed is multiplied by the square root of the weight ratio (new/reference).
The minimum speed, at which the critical aoa is reached, increases. And therefore the take off and landing speeds.
Glide ratio and weight are not related. Weight shifts the glide Polar to higher speeds and theoretically improves it slightly due to Reynolds effects.
In agile circles I have seen this exercise:
Have two people sit next to each other, each with a blank piece of paper and a pen.
Have them both simultaneously write down the numbers from 1 to 1: one time in decimal, one time in roman numbers and one time as letters of the alphabet (a=1, b=2...)
One person goes about it system by system (first decimal, then Roman... ). The other goes about it number by number (1,I,A,2,II,B...)
Time them both and compare their times.
One instance that crosses my mind often is the airbus a320 incident at Hamburg in 2008. Everything was done right there, but the requirements were wrong.
Despite all the procedures and tests, the software still managed to endanger the lives of the passengers.
I'd nominate modern fighter cockpits, such as: - Saab Gripen: https://www.youtube.com/watch?v=4QVIMD3DA7I - F-35 JSF: https://www.youtube.com/watch?v=88vCjQ8fCb0
My understanding of Taoism is that it's all about moderation, balance.
There is probably a lot of long-term value in your process. Given my understanding, I would expect you to look at your employer holistically too, and realize that short term results are also valuable in their own way.
Like with yin-yang, short-term results hold within them the long term results: the money earnt enables the company to exist in the long term. Lessons learnt from delivering value can spark insight for architecture in the future.
Vice versa, the long term enables the short term. A codebase with little technical debt allows you to quickly implement changes in the short term.
The system dispensed with a passive common bus and replaced it with an active switching hub to which hosts were attached.
I get the impression that the standard still allows hubs to exist, but that you just don't see them in practice.
I would be interested if anyone has ever used a 100mbit hub.
Alan Kay has once said that you get simplicity by choosing a slightly more complicated building block.
It appears to me that erlang does this.
And in some/most cases -Os is faster than -O3 This surprises me. Can you please elaborate?
Think about the consequences for companies that rely on the now reduced cost per KG to orbit. Should SpaceX disappear, other companies will also perish.
I think the difference lies in how you move from iteration to iteration. As long as you have a goal for each iteration - to fix what you learnt the last time, or to change something to get a new data point on it - that sounds like allowing failure. I would expect you to converge towards a working state, on a large scale. If you are trying stuff without any hypothesis or deliberate plan, that sounds to me like the second.
But you already do. Unless you're working for a tiny startup, your CEO or the Board probably doesn't understand the specifics of your code.
From what I understand, Elon Musk previously spent his time on the line in Tesla.
Xflr5? OpenFOAM?
I've used neither but I hear others in the gliding and model airplane scene talk about those.
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.