I was thinking of this in terms of aerial refueling.
It's always better to take off with less than a full tank of fuel. Once you're airborne, the aircraft can top off its tank to complete its journey. Of course, it may even be more economical to top off at multiple legs as the journey proceeds. To your point, a "reverse" refueling would also be ideal in order to lower the weight of the aircraft.
In certain contexts, it's already being done. It'd likely need to be much safer in order for civilian aircraft to carry out aerial refueling though.
I'm reminded of the OPM breach back in 2015 [0]. Practically everyone that even applied for a security clearance was compromised. In addition, millions of sets of fingerprints were recovered by the entity that carried out the hack.
I have 5Gbps symmetrical. I love having it, but the biggest use-case has been bragging about it to my colleagues. I haven't even had the full bandwidth available at my desk for a while now (I've had a terrible time terminating cat6a for reliable 10Gbe, so I'm usually on wifi), and it hasn't really bothered me much.
For me, with upgraded networking it's been huge. Much faster downloads and uploads, I can share more with family members, and when multiple people are using my bandwidth, no slowdowns. Most of my equipment is 2.5g, but still is a fairly significant upgrade, and the per month additional cost is $30/month so makes it worth it to me.
The author mentions Rust's portable SIMD library [0]. The only issue with portable SIMD is it's only available on nightly. I used it in my FFT crate, but we had to switch to the fearless_simd crate in order to get a portable SIMD solution that works on stable [1].
It's been annoying to me as an end user that so many basic things require nightly. I use nightly as my main toolchain, but enabling unstable features makes a project nightly-only, which is undesired for crates that don't already revolve around the unstable feature.
I most often encounter unstable features when I reach for a basic common-sense utility method and discover that it's not stable. Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago! but some unstable methods have been sitting around for years.
And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete. So they will taunt me forever, perfect little helpers just locked away.
> It's been annoying to me as an end user that so many basic things require nightly
It used to be the case a decade ago, but now I wouldn't agree that any "basic" things require nightly (I wouldn't call portable SIMD "basic" at all for instance).
> Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago!
This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release. The 6-weeks release cadence with beta in between means there's always at least 6 weeks and up to 3 months between the time a feature land on nightly and the day it reaches stable, even if the feature is as consensual as this one.
> And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete.
Can't you tell it to use stable as the default target, and use nightly manually in cargo?
> This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release.
Easy example of a basic method that has been unstable for a really long time: [T]::as_slice [0] since 2024 [1]. Apparently, stabilization was attempted earlier this year [2] but was then rolled back [3]. While clearly it was not yet ready for stabilization, it still took over a year before the first attempt.
Another one: Option::zip_with [4] since 2020 because nobody's figured out if it's worth having over .zip(...).map(...). Option::zip was actually stabilized [5] later in 2020 but Option::zip_with has since been sitting in limbo for over five years.
Another one: <*const [T]>::as_ptr also since 2020 [6]. I can't remember if there's an alternative now but dealing with slice pointers without relying on unstable methods has historically been very difficult/annoying. I ran into a bunch of this kinda stuff while working on a crate for iterating over rows/columns of image buffer subregions, because I wanted to use and support slice pointers. (Specifically I think getting the length of the slice pointer was nearly impossible without invoking UB, because constructing a reference (which was the only safe way to access a len method) could break aliasing rules. However I think the len method on slice pointers was stabilized a while ago so that particular problem is no more.) Speaking of which, <*mut [T]>::split_at_mut has been unstable since 2022 [7]...
I'm not saying there's no reason for any of this, just that as a Rust developer it's been frustrating. There are enough of these all over the place that it feels like a real occurring problem, even if it's not reasonable to expect a volunteer open-source project to pay full attention to everything ever.
> Are you saying it doesn't suggest unstable features when using a stable toolchain? That was not my experience before I started using nightly.
Oh really? I've never used any Jetbrain product so I don't know but if it's indeed the case even when you don't even use a nightly toolchain that sounds like a very bad design.
For these sort of things, I wish they would have some semi-stable beta or prerelease tracks other than just nightly so you could use the new features on a somewhat stable branch. If something is in nightly that is too crazy for a lot of projects to really try and exercise it because so much is changing constantly. Like a monthly or quarterly stabilization would be amazing, that may still have experimental features not making it into stable, but has a period of bugfixing w/o intentionally breaking changes to settle down.
Eh, it's hard to prove absence, and time is a beneficial quantity here. The longer something sits on nightly, the greater the chance that bugs are identified before it reaches stable and its usage significantly increases.
A lot of bugs with SIMD libraries are in the domain of interactions, not functionality--e.g. SIMD malfunctions on rare chips, chips with previously-unseen combinations of hardware/userspace firmware/microcode behavior, compilers run in weird harnesses that lie about hardware capabilities, and so on. I assume that's the case with Rust's portable SIMD as well.
If your QA is unpredictable individual use-cases (as with most OSS projects), then there's no way to measure "testing complete" or "coverage"; letting it bake for awhile is the best approach available.
This argument usually depends on how you quantify defense spending, no? [0] In terms of PPP, the U.S. is falling behind. To be perfectly clear, that doesn't somehow absolve the size of U.S. defense spending. If anything, it's damning of all these wunderwaffe projects defense contractors take on and the taxpayer funds.
Going back to Clausewitz, war is a continuation of politics through other means. Moreover, victory is achieved by using force to compel one's opponent to carry out one's will.
> intact and combat capable
On its own, this claim is likely true. Nevertheless, this does not mean one's opponent is going to carry out one's will. Hence, one cannot declare victory. It follows that anything short of achieving one's goal is a loss. A loss doesn't have to be complete and utter destruction. It's fair to say that Argentina did not achieve its strategic objectives during the Falklands War, no?
> Losing is what happened to Germany after both World Wars.
Yes, but Germany is not as good of an example in this case as Japan during WWII. Japan would have likely accepted something short of unconditional surrender much sooner than August 1945, but the U.S. insisted on unconditional surrender. As such, the U.S. did not win until Japan agreed to unconditional surrender.
Have you taken a look at Iran's targeting capabilities and the assets they were able to destroy? More importantly, have you considered who facilitated those targeting capabilities?
Thank you - didn't see that yet, not surprising but very disappointing. Still, unless China is gonna start giving kinetic support to Iran, Iran's ability to be "doing great" in the war is still limited by its crippled, single-commodity-based economy and the US and allies' ability to blow a lot of their shit up.
I screw up the square knot constantly! It's not like I practice but each time I focus, try a few times and then just rage quit and tie 47 half-hitches.
I always remember it as the opposite of what I think is typically called the granny knot. In the case of the square knot, it's just right over left, then left over right.
Wow. I was not expecting that topic when I clicked on the link you provided.
When I went through such a selection process years ago, we took all sorts of tests before and even after the selection process. Towards the end, the head instructor told us they don't really have a good way to measure who will make it through. What he did tell us though is that top physical fitness test scores were not indicative that a candidate will make it to the end.
Is there a PDF version or instructions for building your thesis? I'd like to read it.
It's always better to take off with less than a full tank of fuel. Once you're airborne, the aircraft can top off its tank to complete its journey. Of course, it may even be more economical to top off at multiple legs as the journey proceeds. To your point, a "reverse" refueling would also be ideal in order to lower the weight of the aircraft.
In certain contexts, it's already being done. It'd likely need to be much safer in order for civilian aircraft to carry out aerial refueling though.
reply