HN user
So many ways for splitting across multiple discs... git bundle, split tar files, etc.
Now if it came with a userfs layer that lets users disc jockey and use the repo without copying it first, with some smart mapping making disc swaps seldomly needed, then serious respect would be in order.
Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...
C++ is used by a lot of different people with a lot of different background, and... expectations...
My point is that "sort" is ambiguous and having expectations on ambiguity and arguing that a certain one is better is like arguing little endian being better or worse than bit endian.
It's not so simple that you can just declare what is surprising. Surprise depends on context, and not everyone will have the same context as you. You say you would expect the term 'sort' to mean a stable sort, and I would expect it to always mean in-place sorting, others may expect it to use the absolute fastest way to get something sorted... Different users will have different priorities and therefore expectations.
Sort stability does not matter when the sorting key is the only thing in your data being sorted. E.g. When I sort my M&Ms by color, I never keep them in the same order, because it doesn't matter. A red M&M is a red M&M. Nobody expects their red M&Ms to remain in the same order after sorting. I do tend to expect my M&M sorting to happen in-place. I expect to not need to provide additional candy holding bowls to later clean up that were used for temporary storage while my M&Ms were getting sorted. But I'll optionally grab additional bowls when I'm in a time crunch it if it speeds things up...
Now, if we're sorting all the cars on a parking lot by color, it may be more important to keep all the red cars in the same order where they started, for example if they were previously already sorted by brand, it /can/ be useful if that is preserved. But it's not guaranteed to be important or useful. Maybe the rich owner just want to torch all their red cars all together. I typically won't have access to additional temporary parking lots only used during sorting, or maybe the owner is coming with a flame thrower at 1PM and it has to be done as fast as possible whatever the cost. There is a tradeoff, rent additional parking lots during sorting, or take more time and do in-place stable sorting, or jumble up the car brands.
So what I want is control. That's all. Whether or not the ambiguous term 'sort' is stable or unstable, or in-place or not is just semantics. The only way to get clarity is to either use prior agreement, or to not use ambiguous names. Maybe a language should ban 'sort', and only allow 'foo_sort_bar' names with stability of memory usage postfixes or prefixes to 'inform' the developer. Neither choice is ideal and will satisfy everyone. It's like being a DJ at a high school party.
I'm not saying that the STL is great in practice, since it appears to optimize for usage flexibility with defined algorithmic and memory complexity at the big-O level, and mostly disregards actual real-life metrics. Arguing, however, that a language or library is better because an objectively ambiguous choice was made differently than your expectations is like arguing for fundamental superiority of either endianness over the other.
Why? Just for this edge case? It could be faster and/or allow smaller code size to allow this to be undefined.
Undefined is also different from "depends on the compiler", because which behavior is chosen can even depend on the circumstances, whatever code appears before and/or after it.
That said, UB in code, such as this example of ordering of reads of volatile parameters being undefined, does not automatically mean that code that uses it is bad. It may very well be that the function being called doesn't misbehave either way.
Many interesting ideas in there.
To move forward, I suggest thinking less about the implementation details and more about the concepts around your approach in this system.
For example a database storing files accessible remotely by multiple users is really a file server and can be implemented in multiple ways. And that's not the problem you're trying to solve here.
Depending on where your sandboxes live, a bind or network mount and a gitwatcher outside of the sandbox would accomplish something very similar with less customization.
You mentioned not having a solution for concurrency. So think about that first, without limiting yourself to a single implementation.
Maybe the storage should not be per file, but be a knowledge graph that is presented as a file to the LLM in the sandbox. Concurrent mutations in knowledge graphs may be easier to solve, especially with the help of LLMs.
Or perhaps it starts to work well already by simply showing the git merge conflicts to an LLM and having it reconcile the separate writes. Maybe even let it "post feedback" to the LLMs in the container, when a concurrent write has happened to a memory or skill to tell it "hey while you were working I also learned this potentially related update".
There is a disconnect in ownership between roads and sidewalks that makes it all very political: "Sidewalks in front of homes can be a source of puzzlement over just who or what owns them. Generally, each state sets its own laws about ownership of property, including sidewalks in front of homes and buildings. Certain states say that sidewalks are owned by the cities, towns or other municipalities having jurisdiction. In California, for example, sidewalks in front of homes and businesses are owned by their municipalities, but their upkeep is to be handled by those homes and businesses."
http://homeguides.sfgate.com/sidewalks-considered-homeowners...
/dcc send instructions.txt
Systemd is the hammer and the problem looks like a nail to the systemd developers.
In this case systemd seems to be reinventing process groups, in a totally different way, instead of fixing whatever the reason is why GUI sessions don't use session leaders.
So it's pretty obvious there really is a problem that needs to be fixed, and apparently so far nobody else has made a real or successful attempt to do so.
The Rhine does not flow through Denmark.
Wikipedia disagrees with that: "The term "brutalism" was originally coined by the Swedish architect Hans Asplund to describe Villa Göth in Uppsala, designed in 1949 by his contemporaries Bengt Edman and Lennart Holm.[citation needed] He originally used the Swedish-language term nybrutalism (new brutalism), which was picked up by a group of visiting English architects, including Michael Ventris. In England, the term was further adopted by architects Alison and Peter Smithson.[3][4] The term gained wide currency when the British architectural historian Reyner Banham used it in the title of his 1966 book, The New Brutalism: Ethic or Aesthetic?, to characterise a somewhat recently established cluster of architectural approaches, particularly in Europe.[4]"
https://en.wikipedia.org/wiki/Brutalist_architecture#History
Absolutely go for it! Post it even if you feel uncertain about it, just be clear about that, and about what your patch is trying to achieve, when the unexpected behaviour happens, and try to include a way for others to reproduce/investigate (as simple as possible, perhaps a program that demonstrates the bug). Also be clear about how you feel about whether or not the patch is the right approach and about what you would like list members to do with it (are you looking to confirm that what you're seeing is a real kernel bug, or a misunderstanding, or an application bug, and/or are you looking for help solving the bug/issue you're seeing, and/or are you looking to get it merged, etc). Can you demonstrate/quantify how your patch improves/fixes things, etc.
This just begs for some hardware with an e-ink display for a tabletop xkcd...
Ghosting is with three keys pressed: If there is a key A that is in the same row as a key B plus and also in the same column as a key C, then a fourth key (the 'ghost') appears to be pressed in the column of key B and the row of key C due to the shorting of the rows and columns, also in your scheme.
The money spend where '1/10 the money' was needed to save their lives is additional money spent, not 'instead money'.
In this particular case, the 'instead money' was pure profits for a company (and some taxes for the government).
Do you really think that the 'instead money' would have been a better choice?
Money is just money and is completely replaceable. Actually, we have machines to make it: it's printable. Actually, we don't even have to physically print the money to 'print the money'... It's a number in a computer file.
Every dollar is the same as every other dollar.
Each and every life, on the other hand, is unique.
With your reasoning, for example, the private prison companies would be valued incorrectly high (as do the companies that make the green lights for traffic intersections, the doors to stores, the electric power company, the wireless/phone/cable company, any company with any kind of monopoly, etc). What you're forgetting is to weigh for the difficulty to replace the company with another (that in some cases may already exist and only needs to move into the now vacant market).