A monopolistic stock exchange could, off the top of my head: increase fees, engage in rentseeking behaviour, impose unfair rules, discriminate (against companies and traders) or reduce the quality of service.
Listing on different (or multiple) exchanges ensures that they engage in proper competition.
> compared to the actual extractions you are subjected to in the UK
An apt example of why it's healthy to have competition. A working professional or business could relocate to a country where less of their wealth is taken from them.
But your parent comment's point is that the harm from lack of competition among exchanges is a possible future thing, while the harm from being domiciled in a business-unfriendly jurisdiction is far greater and happens right now.
The rule (edit: in Europe) is now 25 hours for aircraft over a certain weight, though it is not (currently) retroactively applied to existing equipment.
That document is an in-progress proposal to amend a rule, no? I think there was strong opposition to this rule before this accident flight, and the blowback from the missing data here might be strong enough to be able to get it passed anyway.
> the blowback from the missing data here might be strong enough to be able to get it passed anyway
Nice pun.
What do you think would have been gained from the CVR data in this case? Do you think pilot error had anything to do with the door-plug failure? Do you think the CVR was left running on purpose/accident?
If I were one of those pilots, the first words out of my mouth probably would have been, "what the $&#*?!" followed by whatever procedure had been drilled into me for rapid-depressurization. Given the scenario, I wouldn't lose any sleep over forgetting to shutoff the CVR in the mess of getting everyone to safety.
I'm not an accident investigator and don't know what exactly would turn out to be useful, but I think changing your intuition for why we study the CVR away from "because there might have been a large pilot error" to "so that we can learn more about how pilots react to emergencies with a goal of seeing if we can come up with process improvements" may help. If there was some aspect of the response that was not perfect, we could develop training on it for other pilots, right?
That's not what is at stake here though. CVRs are not intended for improving process like a call-center recorded line. "Both recorders are installed to help reconstruct the events leading to an aircraft accident." [ntsb.gov]
This creep of intended-use is exactly why many people oppose surveillance in the first place.
I don't understand. You're saying that the purpose of cockpit voice recorders is not to improve aviation safety via allowing a thorough investigation of accidents? If there is any other purpose, I don't know what it would be.
You don't need to necessarily be looking for pilot error to want the recording. Maybe it picked up the sound of the plug separating and that could be useful. Maybe it records an alarm, a call from the cabin, whatever. Maybe the way they work the checklist for decompression reveals some problem that should lead to a change in the checklist. Maybe it corroborates or disagrees with the FDR.
Of course I think it's most likely that it wouldn't be that relevant in this particular case.
Storing CCTV footage on-prem is at odds with preserving said footage. It’s usually easier for an intruder to destroy or steal the physical storage device on site compared to gaining access to an off-site storage device in an unknown or practically inaccessible location. This is especially true for residential properties.
Do you hide it in a wall or in an attic somewhere?
If we're considering the adversaries here as both a centralized provider for recording access and storage, and the intruder who might look for a DVR and destroy it, then it's reasonable to want a way to decentralize all copies of the data and also not want untrusted individuals from having access to the decentralized copies. The argument GP provided wasn't that off-site storage was bad, but that off-site storage in a SaaS platform that is easily identified as a destination to subpoena by virtue of seeing the Ring brandname on the doorbell and/or cameras is risky and in their opinion undesirable.
It really depends on your threat model, like anything else with privacy and security. Storing the tapes out of site would probably work, honestly on-prem is so uncommon that I'd expect any intruder to think the cameras are connected to an online service anyway.
If I wanted to get clever I'd have a dummy setup of some kind. Stash a few real enough looking and literally label it "cameras". I'm not worried about defeating Danny Ocean here, I'd be surprised if an intruder even looked for the storage system let alone would recognize it.
> your config becoming more and more complex until it inevitably needs its own config, etc. You wind up with a sprawling, Byzantine mess.
We're already there with Helm.
People write YAML because it's "just data". Then they want to package it up so they put it in a helm chart. Then they add variable substitution so that the name of resources can be configured by the chart user. Then they want to do some control flow or repetitiveness, so they use ifs and loops in templates. Then it needs configuring, so they add a values.yaml configuration file to configure the YAML templating engine's behaviour. Then it gets complicated so they define helper functions in the templating language, which are saved in another template file.
So we have a YAML program being configured by a YAML configuration file, with functions written in a limited templating language.
But that's sometimes not enough, so sometimes variables are also defined in the values.yaml and referenced elsewhere in the values.yaml with templating.
This then gets passed to the templating system, which then evaluates that template-within-a-template, to produce YAML.
At the end of the day, Helm's issues stem from two competing interests:
(1) I want to write something where I can visualize exactly what will be sent to Kubernetes, and visually compare it to the wealth of YAML-based documentation and tutorials out there
(2) I have a set of resources/runners/cronjobs that each require similar, but not identical, setups and environments, so I need looping control flow and/or best-in-class template inclusion utilities
--
People who have been working in k8s for years can dispense with (1), and thus can use various abstractions for generating YAML/JSON that don't require the user to think about {toYaml | indent 8}.
But for a team that's still skilling up on k8s, Helm is a very reasonable choice of technology in that it lets you preserve (1) even if (2) is very far from a best-in-class level.
I would recommend implementing a similar API to Grafana Tanka: https://tanka.dev
When you "synthesise", the returned value should be an array or an object.
1. If it's an object, check if it has an `apiVersion` and `kind` key. If it does, yield that as a kubernetes object and do not recurse.
2. If it's an array or any other object, repeat this algorithm for all array elements and object values.
This gives a lot of flexibility to users and other engineers because they can use any data structures they want inside their own libraries. TypeScript's type system improves the ergonomics, too.
I don't see any practical difference w.r.t. cybersecurity between "I blindly applied this pile of YAML to my production kubernetes clusters without looking at it" and "I blindly downloaded and ran this computer program on my CI runner without looking at it".
A supply chain attack on the former means that your environment is compromised. So does the latter.
GitHub actions isn't going to run your Python code on its orchestration infra. Nor is DigitalOcean or Fly.io or CircleCI. They all convened around "YAML" because it's a very limited set of instructions.
I'm quite sure you cannot write a bitcoin miner (or something that opens a backdoor) in Liquid inside YAML in the DSL that Github Actions has. I am 100% sure you can write a bitcoin miner in Python, Javascript, Lua, or any programming language that Github would use to replace their YAML config.
What? GitHub Actions, at the very least, isn't strictly yaml. I run arbitrary code in whatever language I want all the time. I'm pretty sure third party workflows can, too.
A monopolistic stock exchange could, off the top of my head: increase fees, engage in rentseeking behaviour, impose unfair rules, discriminate (against companies and traders) or reduce the quality of service.
Listing on different (or multiple) exchanges ensures that they engage in proper competition.
> compared to the actual extractions you are subjected to in the UK
An apt example of why it's healthy to have competition. A working professional or business could relocate to a country where less of their wealth is taken from them.
reply