Curiously, though, we don't really know it is coded in DNA.
Michael Levin has been discovering lately that biology is more complicated than we thought. His YT videos are mind-boggling. Flatworm genetics are a dog's breakfast that the cells work around by means nobody understands.
What do you mean by this specifically? What claims does he make? It's hard to respond to this just based on what you wrote. I don't think biologists have claimed that biology isn't complicated, and I don't think anyone claims that DNA isn't complicated either. Unless you are referring to genetics? That is still caused by DNA, just not by gene expression.
Strontium-90 has advantages. At density 2.6 vs 12, you can afford to loft more of it to compensate for its 28y half-life, and still come out ahead provided you can dispose of the extra heat at first. Few missions need to run decades.
Arrayed as a thin film on a substrate, you can use the kinetic energy of the alpha particles directly for thrust. The substrate will need to dissipate some heat from nuclei emitted in the wrong direction.
Those use strontium-90, which decays much faster than americium-241. That makes it hotter, at first, but its useful life is less. Being more than 4x less dense, you might carry enough more to make up the difference (and discard the extra heat, at first) if you have the room.
Strontium-90 decays by beta emission, ending up as stable zirconium, meaning you don't have to vent helium.
I think SDCC has weird bitfields, originally due to a bug but now baked into the ABI for some of its platforms?
But there are only a handful of ways to lay out bitfields:
* Use little-endian or big-endian bit order? (this need not match the byte order, but usually does - IIRC recent GCC no longer supports any platforms where it doesn't?). This is the only one you can't control. Networking headers rely on a 2-way preprocessor branch so no other ways are really possible, at least up to `unsigned int` (may be 16) bits.
* If padding is needed, is it on the left or on the right? or, on the top or on the bottom? (this might always be tied to bit-endianness, but theoretically it is detached). For maximum portability, you must add explicit padding, doing math with `CHAR_BIT`.
* What exactly happens if an over-sized bitfield is attempted? (beware, there is no stable ABI for this in practice!)
* Do zero-sized bitfields align to the next unit?
* Can bitfields cross units? Is perhaps a larger-than-user-specified unit used? Consider `struct {uint8_t a:4, b:8, c:4};`
* If a mixture of types is used, do they get aggregated unconditionally, by size, by type? Ignoring signedness or not? Consider `struct { int a:1; long b:1; long long c:1; }`
* Is `int` the same as `signed int` or `unsigned int`, and for what widths?
It's unfortunate that testing some of these can't be done at compile time (a few can via `sizeof`), so you may need to either manually inspect assembly code, or else rely on optimization to do the emit-constants-via-strings trick when cross-compiling (C++, if supported on your platform, may do better than C at accessible compile-time optimization).
The doesn't say whether the C-145As built in Poland for the US Air Force still had the fault, or the SkyTrucks built until 2019. We might guess that since the fault wasn't in the plans, they would not get it, but that might depend on whether they were built in the same factory as HA-LAJ, with the same practices.
It seems as if were both engines to fail, either one prop would be feathered and the lift spoiler on that side extended, or neither prop would be feathered. Presumably the pilot could feather the props himself. It is not apparent whether this would extend both lift spoilers too, or if those were controlled separately.
The design drawings did not have the fault, but the engineering drawings used for building may have. They were done by different teams in different organisations at different times.
I doubt they have the same fault. It's common practice in NATO air forces to use lock wire or another type of anti-backoff mechanism on screws and bolts subject to vibration.
If the original design lacks this it would likely have been embodied as a fleet wide modification/design change.
It would be also quite normal for design plans to just specify that it should be "screwed here", depending on standard practices to use the standard screw locking.
The original design supposedly had two screws, but was manufactured with one. When you have two fasteners (typically nuts, as opposed to screws...) they can be mutually secured with lock wire. That is very common.
It is decidedly not common to lock wire electrical terminal fasteners in aircraft, or anywhere else for that matter. Typically lock washers and self-locking nuts are used. I'm not a certified aircraft electrical system designer, so I can't say definitively, but there are some pretty obvious reasons: First, these are typically small fasteners: lock wiring is hard enough on large fasteners. Lock wiring tiny little nuts with small gauge wire approaches the unreasonable. Second, lock wire is not insulated, so you would end up with a rats nest of exposed conductors leading to your terminals. Clearly unworkable. I suppose someone, somewhere has done something that involved insulated lock wire, but I've never seen it, wouldn't know where to buy it, and can't imagine how you'd employ it without abrading the insulation.
The problem here is the shared ground terminal. Stacking wires on ground terminals is common, stupid and a plague on electrical systems. The clamping force on a wire's ring terminal (and, thus, it's contact resistance, mechanical friction, ability to inhibit corrosion, etc.) is distributed among all of the ring terminals stacked on a stud, screw, whatever. Stack just one new terminal with another and you've cut the clamping force on both in half.
Half.
You are now the "engineer" and when someone dies as a result of your field engineered electrical system it's your fault.
I don't follow how stacking two terminals cuts the clamping force in half.
If a screw provides 10lbs of clamp force, the equal and opposite reaction is that the thing it is screwed into must resist with 10lbs.
If you put one terminal in between it must transmit all 10lbs through itself or else the forces don't balance out and something must be accelerating.
If you then stack another one in there all the force must be transmitted through it also. So the screw clamps with 10lbs of force and both terminals feel 10lbs of clamp force.
I just can't figure out where you got the idea of "it cuts the clamp force in half" but I'm interested to hear.
The clamping force is distributed over an area: \sigma = F/A. Adding ring terminals increases the total clamped area, reducing the pressure seen at any point on the surface. Since increasing from 1 to 2 doubles A (assuming each has the same contact area) these surfaces see half the distributed force at every point.
It's easy to visualize if you replace the two rings with one enormous ring (and fastener, etc.) while F remains the same: obviously the distributed force at any point will be low.
The distributed force is crucial. Friction in real mechanical systems is non-linear. Conductors made of real materials vary in yield strength. A correctly engineered terminal must account for force, yield strength, area, vibration, dissimilar metals and other factors to prevent back off, gas ingress (thus corrosion,) high resistance etc. Real engineers don't do all the materials science involved here and no one would trust it if they tried: they rely on published standards, authored in blood.
Stacking ring terminals torpedoes all that: what was (relatively) simple with one ring becomes unanalyzed and prone to failure when stacked.
Ah I see. That analysis works if you neglect the free body diagram of the system. I agree with your analysis if one larger terminal were analogous to two smaller ones. But it is not.
When a bolt applies clamp force it does so to every thing in between the bolt head and the anchoring threads. All of the force is transmitted along the bolt shaft from the mating threads to the head of the bolt and then back down whatever is in between the bolt head and the mating threads.
If this were not the case no fasteners would work. The only exception is when you have multiple mating threaded regions, rust, etc.
If you put one washer in between the bolt head and the threads obviously it must feel the full force of the clamping, or else some force went missing.
If you put two washers in between they're both still trapped in this identical clamp force situation.
This can be extended by induction about as far as you'd like. Certainly 2,3,5,10 washers. Even to 100. Eventually gravity and other things start to creep in at much, much larger scales. If you wanted to clamp 1 million washers this simple analysis would fall apart of course.
Given that withoutboats is a long-time major contributor to Rust, I suspect they titled the blog post with the audience of regular readers of their blog in mind rather than a more general audience like Hacker News
> Btw this is the beginning of me trying to shift away from blogging about rust to blogging about PL design in general. I find that I have very little to say about Rust that I haven’t already said.
Right, this is a post which kinda assumes you know Rust, but AFAICT it isn't a post specifically about Rust.
In 2014 that would be extremely presumptuous or targeted at a very niche audience, however in 2024 a lot of people know Rust and so it seems much more reasonable.
Indeed. Rust is the language that the smart kids are using to think about higher-order programming concepts. It has begun to supplant Lisp and Haskell in that regard.
My reference point is Rust because I've worked on or in Rust for most of the past decade, but I think the relevance of Rust for programming language design more broadly is that it is the most well-typed widely deployed imperative programming language. In this way it has an advantage over Lisp or Haskell if you're trying to think about how we might statically analyze imperative programs, which is what I'm personally most interested in.
Michael Levin has been discovering lately that biology is more complicated than we thought. His YT videos are mind-boggling. Flatworm genetics are a dog's breakfast that the cells work around by means nobody understands.