Neither what lisper actually says nor what hans1729 replied with are random assertions, and, furthermore, they are each entitled to assert whatever axioms they like - but anyone wanting others to accept their axioms should be prepared to assume the burden of presenting reasons for others to do so.

I'd agree they shouldn't get into CDS and other esoteric instruments, and I also would put crypto investments in the 'esoteric' bucket.

Do you have a source for this? I feel like some details are lacking.

The tldr is that they bought credit default swaps for debt owed by Codere SA, and then offered the company financial assistance to restructure with the requirement that they pay their existing debt late to trigger a default.

He discusses the morality of this particular issue, as part of a discussion on a proposal for the SEC to regulate it, here: https://www.bloomberg.com/opinion/articles/2021-12-16/the-se...

Basically, Levine's argument is that as a result of these sorts of shenanigans, one giant investment fund (in this case, I guess, Black Rock, though again I don't know about this specific instance) gave money to an actual company that was employing people and doing something in the real world and that was in some kind of financial trouble. And it did that because it wanted to make even more money from some hedge fund somewhere, sure, but look at who was harmed (a hedge fund that was in the business of buying and selling Credit Default Swaps) and who benefited (a real company with a whole bunch of employees who would otherwise be laid off, and another hedge fund that was in the business of buying and selling Credit Default Swaps) and I'm not sure that the whole thing is that bad?

Something happens that harms some party, the event is studied and regulations are sometimes updated.

Let's say the option expires worthless. You make money having done nothing but collect my premium.

I take the option, and because it's positive gamma, when it goes up I make money, and I flatten. When it goes down, I'm short, and I make money and buy. I keep doing this buying low and selling high until I've made more than the premium.

---EDIT

My point is there can be reasons for both sides to do the trade. Nobody needs to be "harmed". The line of reasoning that says one of you must lose misses the point. If you buy insurance, either your house burns down or it doesn't. That doesn't mean either you or the insurance company was harmed.

Each individual options trade is zero-sum (one side wins exactly as much as the other side loses, barring transaction fees), as is the total of all options trades.

The whole point of having financial instruments is that you can mix risks. Whether each individual one results in heads or tails is not actually the point, the point is entities can shape the risks they want to be exposed to.

This isn't THE only issue with FFMPEG. There are many many problems with FFMPEG, but it's the best thing we have in this area. Warts and all, I would probably, no, definitely would not have been able to achieve many of the career accomplishments I have without it.

As you start to reveal the multitude of switches/options/etc available to FFMPEG via GUI, the GUI becomes gnarly and complicated very quickly. This then becomes just as daunting to the avg user as trying to build the command itself. There are many practical uses for a very simplified GUI to achieve a limited set of functionality. There's nothing wrong with it. In fact, I'd be willing to guess that if a UI came along that exposed every single thing that FFMPEG could do, fewer people would use it than a much more simplified version.

There are infamously a lot of tasks that "look easy upfront but have a lot of underlying complexity" and ffmpeg is not one of them. It's a task that looks hard upfront and then when you get down into the weeds it's an eye-bleeding eldritch monstrosity.

The consensus around MP4 and MKV containers and some relatively small number of codecs (H264, H265, VP1, AV1, etc) has substantially eased things but video codecs, audio codecs, and container files are just complicated af.

And believe it or not - this is still way, way better than it used to be! Flaskmpeg was never stable, Virtualdub was nice but development ended with avi container files, there were some forks that added various features, etc, but ffmpeg and OBS Studio both actually just work incredibly well compared to what came before.

except not everyone has decided to use that easing of the things. it seems like they go out of their way to make things difficult

My favorite is in how MP4s are not all the same. A video captured on a DSLR or other acquisition camera source might have +/- in the video/audio sync when imported into an NLE. Yes, the container utilizes PTS syncing to playback the video/audio streams in sync, but this +/- slop in sync is annoying AF to professionals capable of seeing the sync slop. Average consumers probably never notice. I thank all the gawds in all the heavens that I no longer have to edit MP4 source captured content and all of the manual slipping in the NLE.

But...sometimes you want one particular thing, that thing is relatively simple (compared to e.g. H.264 decoding), and you have needs ffmpeg doesn't meet. Then you probably can do better. A couple examples that have come up for me:

* specialized .mp4 muxing. My NVR project does this in a way where it can do HTTP range serving, so put the moov up front, produce the length quickly, and produce a given byte range without iterating through all the bytes before. ffmpeg can't do that, understandably. Hard to do in a general-purpose library; the container muxing input interface doesn't expect all the necessary information is available up front. But it's not that bad as a one-off. As you say, the consensus around a small number of containers really helps.

* RTSP. Consistent with your "modules that mostly work, usually, mostly", ffmpeg has various long-standing bugs in its RTSP handling (e.g. https://trac.ffmpeg.org/ticket/5018), has the risk associated with protocol handling in a non-memory-safe language, doesn't have much of a test framework for this, etc. This problem is relatively approachable (though hardly trivial), so I had success making my own library.

http://bropages.org/ffmpeg

The antidote to ffmpeg's arcane command-line has always been finding someone else who already did it and seeing what they did differently. There are, of course, many ways to skin the cat in ffmpeg, but you often just need to see some finished, working commands and start from there.

You could of course build that on a wiki somewhere, ffmpeg does have various examples in their docs, but bropages is a place to curate that sort of stuff.

You'll need a client for it (tldr itself is just the database). I recommend tealdeer [2].

Example:

    $ tldr tar

      Archiving utility.
      Often combined with a compression method, such as gzip or bzip2.
      More information: <https://www.gnu.org/software/tar>.

      [c]reate an archive and write it to a [f]ile:

          tar cf target.tar file1 file2 file3

      [c]reate a g[z]ipped archive and write it to a [f]ile:

          tar czf target.tar.gz file1 file2 file3

[2]: https://github.com/dbrgn/tealdeer

    Often combined with a compression method, such as gzip or bzip2.

    [...]

    [c]reate a g[z]ipped archive and write it to a [f]ile:

       tar czf target.tar.gz file1 file2 file3

There's no real problem, but I never like it when I'm given an example that seems to be going out of its way to suggest something untrue.

One thing I hate about CLI tool though, is that it's very hard to edit long commands in terminal.

For example, to replace the input filename from the previous command. I can do it in one second with my keyboard + mouse (use the mouse to select the old one, and type in the new one which would replace) in editor but you can't do so in terminal.

Another example is to change the order of some switches. Again very easy in text editor, not so much in terminal.

So, everytime I use FFMPEG for some complex one (especially when I need to go through trial and error, I have to write the thing in a text editor and them paste them into terminal.

> It's a small key sequence: ctrl-x e . What's this do? It takes the existing command that you currently have on your command line and opens it in your shell's editor

Apart from the "wrap it in a shell script" advice, I would also note that in a bash-like terminal, home and end will jump to the start or the end of the current command buffer, and ctrl-del (or alt-del maybe?) or ctrl-arrow keys usually delete or move the cursor a whole word at a time, which makes it somewhat quicker to work rather than sitting there holding an arrow key or backspce.

Many here probably already know this, some may not!

Now this got me thinking: the main problem with terminal is that it doesn't seem to support "cut" (and consequently, "paste to replace selection"). So re-arranging a command string is always gonna be a pain regardless the complexity.

I can see why it was this way historically, but not exactly sure why no modern terminal emulator gives this feature, even as optional.

Only a madman would do this. I don't know anyone that's in the middle of R&D that builds directly in the CLI that's sane. Everyone tries it, and just at the point of losing sanity, does the rational thing of building the command in a text editor for a simple copy&paste into the CLI later.

Your doctor may have many patients, but they are not making the same decision for all of them. Same with any lawyer you retain.

Your elected rep has to represent people with diametrically opposed desires. Also, you don't pay them directly and you have no principal-agent relationship.

In the analogy, the doctor's patient or the lawyer's client represents the electorate as a whole.

They are going to listen to the squeaky wheel in their base.

You need to be able to trust that your doctors guidance is genuinely what they feel is best based on their training and experience rather than a sponsored treatment they have been paid to prescribe.

Yes, let's blame the consumer. First of all, the consumer has no idea how their specific spending habits contribute to an issue. For instance, an educated consumer (many consumers are not educated btw) might understand that eating meat causes deforestation, but they have no way of knowing if their specific purchase is contributing to that. Second, blaming the consumer makes any solution almost impossible because organizing a very large group of disinterested people is very hard. It would be much more effective to regulate the relatively small number of meat producers that are perpetuating deforestation and let the market work out decreasing consumption through increased costs.

Yes, let's. I don't think an argument can be held against this. As a meat eater, I understand I'm the driving force of this issue. It's an inconvenient truth, but it is the truth nonetheless. I'm rooting for alternatives like lab-grown meat to thrive, but no amount of wishful thinking allows me to skirt the fact that eating less meat would probably be not only good for the planet, but specifically for my own health.

> the consumer has no idea how their specific spending habits contribute to an issue

Let me point it out: in the developed world it's almost 100% guaranteed that it contributes significantly. You have to go to pretty far edge cases to find really sustainably produced meat. A case can be made that not all industrial farms contribute to deforestation per se, but they are all part of a system that has a high cost for our environment. Deforestation is bad, but it's not –and should not be– the only issue.

How did you come to that understanding? Did you dedicate your free time to studying the impact of meat eating, or was it part of your legally mandated education? A lot of people scrape by, barely able to make ends meet. They have children that require attention, or problems that require immediate action. They may have debts to pay, and no social safety net to help. At a fundamental level, they may have poor critical thinking skills. It's not realistic to expect every consumer to take the time to understand the consequences of every purchasing decision.

> A case can be made that not all industrial farms contribute to deforestation per se, but they are all part of a system that has a high cost for our environment.

But the package says it was humanely raised by family farms? Your trips to the grocery store are going to take a very long time if you need to do a supply chain analysis of every purchase.

If a person cuts down a tree for profit, and the removal of that tree is problematic, then that person is to blame. It doesn't make sense to blame someone many steps removed from the crime just because they, in a very indirect way, provided a very small incentive to commit the crime. The impact of the individual's consumption on the entirety of the industrial farming system is so small that, even if the individual consumer were to blame, they would be guilty of nothing more than the tiniest infraction. The issue with industrial farming arrises from the collective sum of demand, and thus requires a collective solution, i.e. centralized regulation.

But the parent commenter has an important point that should not be dismissed. It is far more effective to regulate/improve centrally at the producer side rather than "wait" for the goodwill of consumers.

You can't flood the world with cheap unsustainable meat (or other products), next put a far more expensive sustainable option next to it and think all of this will just magically play out.

Ideally, there should be no unsustainable goods being offered at all. The very word unsustainable pretty strongly suggests that ending the practice is a must.