I have to wonder if there is a way for clients to glom together duplicate posts across your subscribed communities into one, and if you reply to a thread in that post it passes it back to the correct discussion.
I mean, you'd still see repetitive stuff in the post's comments from your point of view, but everything would be in one place from your perspective and it would be semi-transparent, at least for the communities you subscribe to.
All the information is there, it should be doable......
Splitter is fine as long as there is somewhere for the water to go after it exits the regulator. You need that flow for it to work.
Just know that you also need a bit of back pressure so the regulator can actually reach the point of regulation, I mentioned sprinkler heads but this back pressure can be a hose with a nozzle, or just your thumb on the end even, as long as there is a bit of flow 😄
Hey there.
Pressure regulators typically only work when there is flow and also back pressure they can work against.
If you try and measure with the gauge like in the picture you will basically end up measuring input pressure as any tiny leakage of water through the regulator will have nowhere to go afterwards and pressure will build up.
If you want to test the regulator, you need to put it in a line with a few sprinkler heads on it so that there is both flow and back pressure and then put your gauge in a tee piece on that line so it can measure the pressure of the water flowing past.
Have a look here at the ICMP source code in the Linux kernel at line 400. That is the ICMP reply code.
At lines 433/434 you can see the collection of the source and destination MAC addresses from the incoming packet. The source is just lifted directly from the packet, the destination is done with a helper function that presumably looks at which interface it arrived on and returns the MAC address of that interface.
Lines 441 onwards construct the reply packet and push it to the generic ICMP transmit function (which is a bit higher up in the source code), which then pushes it on to the network stack.
Hope that gives you an idea of how it works internally! It's really only a slightly more detailed version of the actual standard, there are a few checks to make sure that we are not exceeding network rate limits in the stack and etc, but it's a quite simple bit of code.
Added edit: it's "simple" at this point because a lot of the work has already been done. The packet has arrived via the network stack, it has been determined to be an ICMP packet, and it was sent here to this function. There are already functions that send packets out via the network stack, so this chunk of code just builds an appropriate packet and hands it on to be sent.
You don't need a three stage Apollo rocket that can lift 150t to LEO for your ICBMs.
That area of launch ability was functionally complete in 1960 with Redstone and possibly a bit of showing off in the guidance phase with Gemini.
There's plenty of custom ROMs for cars from all major manufacturers, you just don't know where to look.Google "ECU remap" or "dpf delete" for an idea. ECU remapping has been done by bold individuals ever since there were programmable ECUs, around 1985.
Apart from engine/drive line tinkering, there are also plenty of third party software that can tinker with body computers for "lifestyle" adjustments.
Is it easy and accessible? No. Because of environmental laws - and vendor lock in - you can't generally and easily dick around with the control software in your car. But it does exist.
What you have linked to is a high level overview of what happens in an ICMP response, regardless of what OS or network stack you are using.
If you ask me to describe what Linux would do at that kind of level, well, exactly that.
Bought the app, still get the ads...
That.... sounds like something that you should reach out to @rmayayo@lemmy.world and talk about.
The bell is scaled to match thrust though. If you get too much expansion the flow peels away from the inside of the bell and you get turbulence, pressure variations and then usually a big kerboom, especially on startup as you're trying to ramp up to steady state conditions. I'm guessing the bell is more high-altitude optimised than true vacuum optimised.
You can see how the three outer vacuum engines are greatly over expanded giving you a collapse of their exhaust after exiting the bell and then the Mach diamonds.
Where the inner sea level engines are a much closer expansion match and don't really form visible Mach diamonds in view of the camera.(Edit: you can faintly see them. But the compression rebound that forms the visible diamond is much less)
It's quite interesting that they can light and run those vacuum engines on the ground, usually the combustion instability from an over expanded exhaust at sea level results in a hard start.
Right now, conditions are not right for liquid water to exist on the surface of Mars. Atmospheric pressure is too low, water goes from ice directly to vapour with no liquid phase in between. "Life as we know it" requires liquid water as a medium. Possibly at the bottom of the deepest valleys on Mars or deep (like km) underneath the surface we might still find remnants of life.
What we will most likely find on Mars with our rovers is a history of life once existing. Life, from a billion years ago when it was warmer and wetter and plate tectonics still worked and essential chemicals weren't locked up in rocks.
I shall counter with a hypothesis:
It could be that extended lower temperatures at night slow battery chemistry to the point where the voltage sags below the trigger threshold. It would take quite a few hours to cool the battery down from day time ceiling temps, so this would naturally occur in the early hours of the morning just before temperatures rise again.