This sort of mistake is easy to make when you're mixing up your units; if they kept to one system of measure, it would've been trivial to catch, before or after release.
We need to standardize on using Earth circumferences as the unit of length. Or better, football fields! (the type of football of course being implied by the website's ccTLD)
We _have_ standardized on Earth circumferences for length, only we divide by 40 million to make the numbers more sane, and got the measurement slightly wrong!
How hard would it be to fix this? Could we theoretically add or subtract enough material or make whole thing slightly more dense or less dense to compensate?
Per Wikipedia, the discrepancy is approximately 74 km, so digging a ditch with an average depth of approximately 74/2π ≅ 12 km around the circumference of the Earth would theoretically fix the problem.
Feasibility and geological implications are left as exercises for the reader.
Regardless, I suspect a more cost-effective fix would be to redefine the meter to be a couple "legacy" millimeters longer.
You jest, but times around the Earth is the actual origin of the Meter. Kinda.
The history is quite interesting and well worth checking out.
I can't recommend a book on the subject, but I do heartily recommend "Longitude", which is about the challenges of inventing the first maritime chronometers for the purpose of accurately measuring longitude.
Some people just prefer to listen. I read well and I read quite quickly -- I don't know how many books I've physically read, but it's gotta be in the high hundreds at least -- but over the past ~10 years I've switched primarily to audiobooks. Rather than being something that I enjoy while I'm doing something else, I typically do something mindless with my hands (weave chainmail, cross stitch, sew) in order to give my full attention to the book.
Some audiobooks also seem to gain over the book; for instance, IMO, James Saxon's narration of "Blandings Castle" is truly excellent and gets out the most of Wodehouse.
The astronaut in question may choose to disclose that they had the medical emergency and possibly its nature, but it seems wholly reasonable to not single them out (when it affects the whole mission) or disclose their medical status.
Especially since every movement up and down from space is expensive and risks the life of the crew, it'd be a bad idea for NASA to name the astronaut ahead of time.
Disagree; this is completely taxpayer funded and we deserve to know every detail relevant to mission status. In this scenario knowing what illness and why it's grounds for a return is very relevant. That said, I can see NASA delaying information release to figure out a good strategy for it while still respecting any wishes of the sick astronaut with regards to disclosure.
When you drive on a taxpayer funded road, should you disclose publicly your medical history? When the taxpayer funded US military kidnap a foreign president on your name, should you disclose publicly your medical history ? When you use the taxpayer funded GPS etc...
What a strange take. Does this also apply to every soldier in the armed forces? Seems your criteria is equally applicable there.
The relevant people that can do the research and write future policies based on the data obviously will have the information. Not sure what good you think that you personally having it can do.
> What a strange take. Does this also apply to every soldier in the armed forces? Seems your criteria is equally applicable there.
Why? There are different rules for different endeavors, specializations, and roles. NASA is ostensibly for exploration, in an expansive sense. Hiding information of any kind, seems antithetical to the over-arching mission.
> The relevant people that can do the research and write future policies based on the data obviously will have the information.
Given recent events, this assumption of fidelity is not something I can subscribe to, for the rest of my days.
A single soldier having a medical issue generally doesn't cancel a multi-month mission costing some X large sum of money, requiring another Y large sum of money to even finish cancelling it (returning their unit home).
Therefore it's not relevant and not needed for the public to know.
Yes, I’m sure aircrew never get so violently sick as to affect millions or billions of dollars in crew and and supporting assets due to an emergency, and armed service members are never transported by emergency transportations for eye-watering costs. Technical inequity that ignores facts is the argument of those without arguments.
The specifics of “who” has zero relevance to what is necessary for an ongoing situation; you don’t get to dictate your access and timeline to information just because you contributed a fraction of a penny to something.
I've been working in security for more than 20 years and have seen the deleterious effects of security through obscurity first-hand. Why does "adversarial engineering" rely on obscurity?
I love (and heavily use) source generators, but the development experience is godawful. Working with the raw Roslyn types is painful at best and this is compounded by them having to be written against .NET Standard, severely limiting the use of newer .NET functionality.
Eventually I want to write a good baseline library to use for my source generators -- simplifying finding definitions with attributes, mapping types to System.Type, adding some basic pattern matching for structures -- but haven't found a way to do it that's general enough while being very useful.
I agree, .NET Standard limitation unnecessarily complicates development experience. I think it's because some tools (Visual Studio) is still use legacy .NET Framework. I don't understand why they didn't integrate them via out of process architecture into these tools, since source generators didn't exist in the legacy framework anyway.
I sometimes generate code from plain CLI projects (avoiding source generators altogether), as whole debugging and DX is so much better.
Yeah, I went with that approach for most of the code generation in the emulator I'm currently working on. Source generators handle a few core things, but more advanced compilation tasks went to just ahead of time generation; couldn't get my parser combinator library to play nicely with .NET Standard, so that was just a dead-end.
.NET standard isn’t the biggest issue with making source generators. You can’t add dependencies to your project, which is an absolutely huge oversight IMO.
I feel the exact same way. They can be insanely powerful, but the syntax is insanely off-putting.
And the documentation is still pretty sparse.
> Eventually I want to write a good baseline library to use for my source generators -- simplifying finding definitions with attributes, mapping types to System.Type, adding some basic pattern matching for structures -- but haven't found a way to do it that's general enough while being very useful.
I'd use it in a heartbeat. The new ForAttributeWithMetadataName function has been a big help, but everything else feels like a totally different language to me.
Boo and Nemerle both were really showing what was possible in .NET back in the early days. I still miss the metaprogramming they had, not to mention their pattern matching (which C# has closed the gap on, but is still way, way short.)
Back in 2005 or 2006, I was working at a little startup with "DVD Jon" Johansen and we'd have Quake 3 tournaments to break up the monotony of reverse-engineering and juggling storage infrastructure. His name was always "xor eax,eax" and I always just had to laugh at the idea of getting zeroed out by someone with that name. (Which happened a lot -- I was good, but he was much better!)
The vast majority of non-text editing in game development isn't done in modeling or image manipulation apps, it's done via the game engine's editor. That's true whether you're using Unity, Unreal, Godot, or a homebrew engine.
There are the rare engines with no editor to speak of -- where things are either done programmatically or other textual definitions -- but they're very very very few and far between.
The engine itself doesn't have a UI, but working with any major engine without using their editor is functionally impossible.
So, it is possible to use the machine consumable forms of the ISA, but realistically you'll spend way longer fighting it than finding other strategies.
It doesn't have perfect support, but it has served as an incredibly useful resource. I've since generalized it to work for other architectures, and that same repo has definitions for MIPS (specifically the PSX CPU), DMG, and the groundwork for an x86 core. The goal is to be able to define these once, then generate any future targets automatically.
> A qualifying mini app within the Mini Apps Partner Program is one that’s put out by a person or entity that’s not directly or indirectly controlled by you, nor under common control with you.
I don't understand; if it's put out by someone else, how do I participate?
As I understand it: Your app is a virtual arcade, that supports “mini app” arcade games published by other developers, that run inside your virtual cabinet.
I make a game for your arcade, and players pay cash to add credits to my game.
The status quo: Player pays £1, Apple takes their 30% cut, you get 70p, take another 30% cut, and give me 49p
What this programme entails: player pays £1, Apple takes a 15% cut, you get 85p, and hopefully pass on some of that extra money to me too.
The gotchas are:
1. it has to be your app and my mini game. This is about lightening the load of all the intermediaries, not about you cheesing an extra 15%
2. It has to be the player buying credits for my game specifically. If you sell “ArcadeBux” redeemable for credits on any game at your arcade, you’re not an intermediary, you’re the vendor.
I have not had a chance (or, frankly, the desire) to read the full Ts&Cs, but I wouldn't be surprised if you (as an app host), will shoulder some of the accountability for bad mini-apps.
