> If you make money putting stuff into the stream of commerce, you're liable for unintended and evenunforseeable downstream damages
So if you’re a business offering poor quality services, and I come along and start offering higher quality services, I owe you damages for the impact I have on your business?
Morally, maybe? It's what people tend to implicitly assume when a large chain displaces local mom & pops. You can argue it's for the greater good in the long-term, but that doesn't settle the question of the immediate injuries. Is it the fault of the stock boy who lost his job that he worked for a less efficient employer? Maybe?
The whole encyclical's argument is that morality requires an accounting and response to the pain inflicted upon each individual, and human morality is a distinct set of rules and norms than economic, physical, or even civil laws. I think it also follows that it's not just, e.g., Walmart or OpenAI who bares some responsibility for ameliorating temporary suffering. And to the extent people use the encyclical as fodder in the usual anti-corporate rhetoric, then that's unfortunate.
And this is coming from the Catholic church. It turns alot of people off who in isolated contexts often perceive hypocrisy, but in its charity it has always considered the personal responsibility of those receiving it. It understands the struggles and inherent tensions that comes from trying to square individualized justice & mercy, selflessness, and the "greater good".
This sounds like a great approach to me. I've thought some kind of pi zero 2w based smart speaker system would be an awesome project for a while. I am having a difficult time imagining a cheaper option, especially if you want something like the hat ecosystem.
I think you have this pretty backwards. Private equity does not exist because of pensions. Private equity is investment that has not taken additional steps to be a part of regulated public markets.
It's true that private equity is dominated by institutional investors. One reason for this is that the investments are generally deemed too complicated, illiquid, and risky for retail investors (although the Trump administration is trying to change this).
Additionally, if we added the kinds of regulations, reporting requirements, standardization, etc, that would be necessary to scale this model to hundreds of thousands or millions of investors participating in an informed manner, we would simply recreate public markets.
PE has two definitions, the first is its structure as a private business investment.
Pensions did not create this business structure, it has existed forever.
The second definition is the subset of PE that is systemically buying businesses and extracting wealth from consumer and worker to asset and shareholder.
The article is not talking about the first definition and neither am I.
To regulate private businesses equity is not what I’m going for either, it’s regulating the large PE firms doing this specific business model en masse.
You can literally jump into a commit and edit its contents directly, and everything is auto-rebased on top.
There are no modal “sorry rebase failed, best of luck” gotchas. There are no “oops I put the wrong thing in the wrong part of the rebase and now I have to abort and start all over” gotchas.
It’s rebase, but without all the extra work, mental overhead, failure cases, and effort.
How does it just auto-rebase everything without failing though? If you edit something later commits depend on, then you get merge conflicts. Are you implying that jj just automatically handles all this?
I see. It doesn't deal with the conflict, it just proceeds regardless. I'm curious about how it works internally. Does it do something like commit the conflict and soft reset later?
The conflict markers are a first-class citizen in the repo. jj tells you when a commit has a conflict, and you can go edit it at your leisure. It also does prevent you from doing some things with branches in a conflicted state, like pushing them.
You might not think this is that big a deal, but this also means you don’t have to resolve the entire thing in one go. Plenty of times with complicated rebases in git, I’ve not been 100% certain about the path towards resolving it. But jumping around to view various commits when you’re in the rebase-conflict state is painful. In jj you can just switch to an earlier commit, tweak it there, jump to a later commit, see how it looks, etc. It removes 98% of the pain.
It also dovetails nicely with other aspects of jj. Since rebases happen automatically and constantly, they are usually tiny. If there’s a conflict, it’s caught right when you do the thing and not four hours later when that part is no longer fresh in mind. And the op log lets you restore and undo actions atomically, which makes undoing a fuck-up a no-op.
I've come to the opinion that conflicts should be committed and merge fixes should be in another commit afterwards. Arguably even if the merge fix is trivial.
A merge conflict means that some automated tool couldn’t figure it out. But all a merge is is a commit with two parents and an accompanying diff that shows the process of combining them. A merge conflict isn’t really in any way special. It just means whatever algorithm was used couldn’t do it unambiguously without human help.
About 7.6%.[1] That's Changxin Memory Technologies.
That makes them #4 in DRAM, after Samsung, Hynix, and Micron.
They're still only a third the size of Micron, the last US manufacturer.
They have a lot of scaling up to do, but they can make current-generation DRAM.
Changxin just became very profitable, due to high DRAM prices. They're planning an IPO. And, of course, building more fabs.
Yangtze Memory Technologies isn't as far along, but they're building a new fab and planning an IPO.
Both of these companies were created in 2016 as part of a national effort to become a force in the DRAM industry. It took a while to get the technology working. Now it works, and they can scale up.
Couldn’t we say that any market rewards prediction? And that this is generally seen as a beneficial quality that results in more accurate valuations with better liquidity?
I don't mean to suggest you're doing something wrong, but it's not clear to me why you need three separate branches for this? Why not have these related changes as individual commits on a single branch?
First: even though the logic is connected the work happens in different packages, with different test suites and logically it’s seperate. I want the ability to traverse history of each feature separately even though they’re connected and I develop them at the same time. So package #1 has moved forward but I actually changed my mind about API for package #2 and want to roll it back. If all work happened on one branch I don’t see a simple way to do it, without rewriting history and cherry picking particular changes.
Secondly: I want to push changes separately for ease of review. Big PRs wait longer for reviews and the longer they wait the more conflicts I can get because something else has been merged while I was waiting for review.
I've also seen teams struggling to review massive PRs as a single diff, but when I've seen that it's always because they aren't structuring commits to be individually reviewable.
So if you’re a business offering poor quality services, and I come along and start offering higher quality services, I owe you damages for the impact I have on your business?
reply