Thank you for the interlacing-preserved files!! For archival's sake I hope you have some sort of Lagarith/ProRes/etc versions stashed instead of just h264, although those would be prohibitively large to share.
The tapes are not in good enough condition that any intermediate codec would contain any extra information. In most cases, they’re not master tapes, they’re copies Stewart made for his own collection.
The crash in question was in January of that year, and this article in May is talking about passengers “starting” to get items back. Important items that I'm forced to go without for six months may as well be lost. Could you make it six months without using your ID for anything?
Do we need to wait for a tragedy before we do something? Good on the airlines and regulators for recognizing a burgeoning problem and taking action before (hopefully) it leads to unnecessary deaths.
> Do we need to wait for a tragedy before we do something?
Yes, absolutely. It isn't pleasant to think about, but laws and regulations are meaningless if they aren't based on actual numbers. If I wanted to propose some new feature at work, people would understandably want to see some numbers and not just “feels nice” lol
You should "trust, but verify" and not shoot the messenger. If raising valid concerns that were not addressed by the linked website is FUD for you, so be it. Sourceforge was also a major brand back in the day and nowadays it raises an anti virus alarm if a user visits that website.
In this case it's because the mass-market operating systems with which QNX could compete already do the things you're “concerned” about. QNX could only be an improvement in that regard.
I'll bite. There's linux distros popping up left and right and even established distros and major OSS projects have significant security risks attached due to core developers residing in non-free countries. These countries wage hybrid warfare against democratic countries, and it is naive to think that software projects are out of scope. When push comes to shove this access will be utilized.
As someone who has not worked in automotive QNX is a totally unknown brand and based on the linked website I had trouble finding out what it actually is. Also the wikipedia source just stated RIM and might not have been updated at all. Also RIM/Blackberry is not a brand that is positively recognized.
With something like Ubuntu it was an easy, verifiable story who is behind it and what they are doing. That's what the linkd QNX page was missing, and I pointed it out because I actually tried to do the due diligence and see what company is behind it and where it is located.
I totally get where you're coming from—due diligence can be a daunting task, especially with the amount of misinformation out there. It's crucial to dig deep and verify claims to make informed decisions. I've found that using tools like DREA (Digital Real Estate Analyzer) has really streamlined my process for evaluating digital assets. Just remember, trust your instincts, but always back them up with solid research!
I really enjoyed using them for my Ruby file-matching library where I wanted to read `shared-mime-info` XML source package files directly and on the fly as opposed to using the pre-processed secondary files that the upstream `update-mime-database` tool spits out. The problem is that a type definition can be spread out over multiple XML packages in both system and user paths, so the naïve implementation of reading them all at once wastes a massive amount of memory and a massive number of object allocations (slow) when most people use maybe 5% of the full set of supported types (the JPEGs and HTMLs and ZIPs of the world).
I wanted to read the source package files directly because I always found `shared-mime-info`'s usual two-step process for adding or editing any of the XML type data to be annoyingly difficult and fragile. One must run `update-mime-database` to decompose arbitrarily-many XML packages into a set of secondary files, one all-file-extensions, one all-magic-sequences, one all-aliases, etc. System package managers usually script that step when installing software that come with their own type data. I've accidentally nuked my entire MATE session with `update-mime-database` before when I wanted to pick up a manual addition and regenerated the secondary files while accidentally excluding the system path that had most of the data.
I ended up doing it with four Ractors:
- a Ractor matching inputs (MIME Type strings, file extensions, String or Pathname or URL paths for sniffing) against its loaded fully-formed type definition objects.
- a Ractor for parsing MIME Type strings (e.g. "application/xml") into Hash-keying Structs, a task for which the raw String is unsuitable since it may be overloaded with extra syntax like "+encoding_name" or fragment ";key=value" pairs.
- a fast XML-parser Ractor that takes in the key Structs (multiple at once to minimize necessary number of passes) and figures out whether or not any of those types are defined at all, and if so in which XML packages.
- a slow XML-parser Ractor that takes the same set of multiple key Structs and loads their full definition into a complete type object, then passes the loaded objects back to the matcher Ractor.
The cool part of doing it this way is that it frees up the matcher Ractor to continue servicing other callers off its already-loaded data when it gets a request for a novel type and needs to have its loader Ractors do their comparatively-slow work. The matcher sets the unmatched inputs aside until the loaders get back to it with either a loaded type object or `nil` for each key Struct, and it remembers `nil`s for a while to avoid having to re-run the loading process for inputs that would be a waste of time.
The last pre-Ractorized version allocated around 200k objects in 7MiB memory and retained 17k objects in 2MiB of memory for a benchmark run on a single input, with a complete data load. The Ractorized version was twice as fast in the same synthetic benchmark and allocated 20k objects in 2MiB of memory and retained 2.5k objects in 260KiB of memory for its initial minimal data load. I have it explicitly load `application/xml` and `application/zip` since those combined are the parent types for like a third of all the other types, and a few other very common types of my choosing.
I think a lot of the barrier to entry for Ractors isn't the API for the Ractors themselves but in figuring out how to interact with Ractorized code from code that hasn't been explicitly Ractorized (i.e. is running in the invisible “main” Ractor). To that end I found it easiest to emulate my traditional library API by providing synchronous entry-point methods that make it feel no different to use than any other library despite all the stuff that goes on behind the scenes. The entry methods compose a message to the matcher Ractor then block waiting for a result or a timeout.
I also use Ractors in a more lightweight way in my UUID/GUID library where there's a Ractor serving the incrementing sequence value that serves as a disambiguator for time-based UUIDs in case multiple other Ractors (including invisible “main”) generate two UUIDs with the same timestamp. Speaking of which, I'm going to have to work on this one for Ruby 4.0, because it uses the removed `Ractor.take` method.
reply