WC: Privateer is a little bit like that, especially if you played the WC (wing commander) games first. Moving from a military, "we have budget for everything" (ammo, missiles, fixes) to a "oh, should I fix my auto pilot or buy an extra missile?" setting feels a little bit like that.
Plenty of low-brow there as well, and basically being forced into the plot against your will is very on-point for a "I just want to make a buck" character.
Yeah - Privateer 2, the darkening got me into the whole genre. Five CD-ROMS in a multi disc case, Clive Owen, Mathilda May, Jürgen Prochnow, John Hurt, Christopher Walken, Brian Blessed and Amanda Pays and Dani Behr playing in the cutscenes. If you could have walked around the space stations and planets in3D it would have been as close as it gets to this.
> Some countries, such as Israel, have purely party based parliamentary systems with no geographic representation ... Some nations have fine-grained representation of ideas but course-grained representation of land
Before putting this on a pedestal, it's worth noting that Israel:
1. Has smaller some power blocs which have non-proportional power at the parliament due to being the "swing vote".
2. Had other smaller political parties completely eliminated (voter desertion) due to ineffectiveness.
3. Had 4 elections in 2 years due to inability to form a ruling government with more than 50% of the parliament approval.
4. Had a government average run-time of 2.5 years since 1999 due to "no confidence" votes that force re-election.
Less than ideal. The American system, with its flaws, significantly more stable.
The Netherland has pretty much the same system as Israel, there is slight geographic representation but nationwide party votes do dictate the composition of parliament.
All the Nordic countries also use a proportional system with multi-member districts and measures to make the overall party representation in parliament align with their national share of the votes.
Maybe the problems with Israel are just problems with Israel rather than their particular system of voting.
From what I understand, Netherland has practically the same system as Israel. There's no regional representation at all, you vote on the party, and although you do vote on a specific candidate from that party, seats are assigned in the order of the list that the party determined, unless a candidate receives enough individual votes to reach the threshold for a seat on their own (which is rare for anyone not on the #1 or #2 spot for their party).
As a result, Dutch parliament currently has 16 parties, and the senate 13. And although governments do fall, and sometimes have trouble forming a new government, the system is very stable. Every government is a coalition, a compromise between enough parties to hold 50%+1 seat in parliament, and that means you generally see the same big parties in government. Sometimes one of the big parties loses popularity and thus seats, and doesn't govern. Other, possibly fairly new, parties can take their place. Parties that most other parties think are terrible (like the racist parties) still won't be able to form a government even if they're large, because nobody wants to work with them.
My one mega-annoyance is no mute button. Not being able to mute a Zoom call (or a phone call) using just the Airpod hardware interface is... annoying. I don't use Siri that often and would honestly remap long click as mute/unmute. I'm willing to pay premium for that feature alone. Hell, I'm willing to subscribe that feature. Apple, "take my money", just give me a mute button that works without the phone (or watch, or laptop).
The worst part about the click is that it hangs up your call. I was on hold with the IRS for 3 hours and hung up on the representative when I adjusted my airpod. Rage inducing!
I tried the query "databricks series b valuation" on Kagi (just a beta user there) and the results were:
1. Databricks Funding Rounds, Valuation and Investors (https://craft.co/databricks/funding-rounds) - not directly to the point but does include information about all rounds.
2. Databricks Raises $1B at $28B Valuation, Plans Massive - not answering the question at all.
3. *Databricks Closes $33M Series B Funding - FinSMEs* (https://www.finsmes.com/2014/07/databricks-closes-33m-series-b-funding.html) - Direct hit! didn't even have to click into the page.
In my mind this is yet another proof of Google's search quality decline. I remember being so excited when I saw the first structured search result but now I tend to use other engines first.
The short-short is: how to manage granular config for over 10k customers, 500k users and still make dev, pe, support and pmo happy. Lots of performance optimizations discussion and some interesting (to me at least) requirement analysis.
AMA.
Also, We're hiring!
Local at SF bay area, US / Mumbai India / Poznan, Poland.
Remote anywhere in the US, Poland, India.
Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence.
1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators) lives complicated.
2. Tags are (mostly, best practice) immutable pointers to commits. Tag are "this is this thing FOREVER*."
3. Branches are named, mutable (by design) pointers to commits. Branches are "this is this thing FOR NOW. Later it'll be something else."
4. HEAD is special "branch" that moves around automatically.
5. Origin is the local snapshot of the remote. Origin is "what did it look like when I last looked."
6. (fundamental but not critical) Remote is the current remote state (queried by RPC).
7. Index (aka stage) is where you put changes you want to make into commits. (this is somewhat simplified). Index is "My current and immediate plan. Scrub as needed."
That's (mostly, for non advanced use cases) it. Everything else are commands to query or manipulate the various state. Every action (until it becomes instinctual knowledge) should follow the same recipe: 1. Figure out the current state (current commit graph, relevant branches). 2. Figure out the target state (desired commit graph, new branches positions). 3. Mutate using ANY command you want.
I think that's the issue really. Inexperienced dev / people who don't understand git look at commands as "this is how to do a thing". No. In Git there isn't "how to do the thing". It's exactly like writing code - so many ways to achieve the goal, just choose your own. It might be efficient and elegant, or bumbling and ugly, but it'll get there.
Sorry, but what? Specifically: what about your writing justifies the assertion that git is simple? Git is a horrible convoluted set of commands to make a lot of different data structures [1] interact. And if you do it wrong you can get into very weird states. This is not simple in any meaningful sense of the word!
Heck, "a monoid in the category of endofunctors" is simpler.
[1] From the top of my head: The working tree, the index, the stash, the repo ADG, the local remote repo ADG, the remote repo ADG. Of course the branch labels are further state, and working with the commits directly is discouraged. Oh and files can be either tracked or not, and they can either be ignored or no. And one isn't a subset of the other. And that also interacts with the various state transitions.
Any system with a limited amount of concepts is simple. Emergent properties are easy to predict and explore. Physics of "perfect friction-less sphere in vacuum" is so easy to understand we teach in grade schools and toddlers grasp it by instinct.
I can't (yet) reason about monoids easily. But I can reason about Git, even if I can't figure out the single command to change the state the way I want it and have to resort to multiple commands. I guess it's easier for me to think in graphs.
But it's not a limited amount of concepts. One sphere in a vacuum is easy, three spheres is hard. Git has half a dozen subtle interacting data structures. But because people have built up a lot of experience working with them (and don't coach beginners and non-programmers) they shout "it's just an ADG, so simple!" and pretend like everything is fine...
Agreed. I have a couple of things to make my life slightly easier.
I could never understand what kind of twilight zone stashes go into or remember which stash is which when I had too many of them. So I never use stashes any more, I just make a branch instead.
I largely use git add -A, so I can pretend that the index does not exist.
3. Branches are named, mutable pointers to commits, that you can "ride". While you "ride" a branch it keeps moving to always point to your latest commit.
4. HEAD is an implicit branch that you "ride" at all times.
afaik, the commit a tag points to is immutable unless you delete and recreate (and then nothing is immutable really).
re "ride" - that's exactly what I'm trying to avoid. It's an additional concept that isn't needed to understand Git. You need to understand the model. The "ride" is an emergent property of the model and commands that you eventually understand, but not a core part.
Without the concept of "riding", terms "tag" and "branch" would become exact synonyms. In that case you can just remove point 2 (consider it just a syntactic sugar) and thus simplify your list.
If a tag has any attempt at immutability at the data structure level, I know nothing of it.
It's all about how other clients treat branches and tags.
Once you've pushed a tag, no other clients will be willing to update their definition of that tag unless the users on those other devices force the issue.
So operationally, "tags are immutable once pushed" is a pretty reasonable way to look at things.
Remotely pushed branches of course also won't allow you to do anything but append without forcing on remote clients, so mutable and immutable isn't quite right, here.
So I guess I agree with your original contention, branches are mutable-and-you-can-ride where ride means "the remote client's porcelain will be happy with append mutations".
As far as I know, tags don't have an identity beyond their name. The CLI tries to steer you away from replacing tags (by naming the option --force rather than, e.g., --modify), but that doesn't make them immutable.
Sometimes you just want your tool to get out of your way and get the job done, instead of deeply understanding it. No shame in that. There are limited hours in the day and sometimes other things are more important.
I get what you mean, but git is basically a tool for manipulating the .git directory (and a working directory checkout).
I think understanding what .git dir contains and represents is as important as understanding the tool.
It's not like you need to understand how the tool works internally, or how it's built.
Analogy would be that you want to understand how to use a hammer, sure, but also the characteristics of material you manipulate with it. You don't need to understand how the hammer is built.
I work with some very good programmers who don't worry about code. Past a certain point it bites. You have to be thinking about scalability early so someone else doesn't have to refactor someone else's pride and joy because it's become full of overly concrete logic.
Like a lot of things Linus, it's very pretentious and aloof but right at the core of it. Code matters a lot and bad code can tank performance, stop evolution and introduce security issues. But with Git, this is a mostly truthful statement.
I remember reading a quote where he states, that when looking at new code he starts with data structures, to get an understanding of what's going on. Or something to that effect.
That would be more applicable here. But I couldn't immediately find it, so I pasted this one instead, which is somewhat close but not perfectly related to the OP.
Git is definitely not simple. It's simple if you have a solid understanding of data structures (trees, graphs), and know the concept of a pointer. Not everyone has that background. The concepts are learnable, but the commands have complex behavior that often require reference to use properly. The commands aren't simple by any measure because of all of the edge cases that exist.
We do have regular humans using git internally - godsend for remote work. They manage fairly well because they don't really need to anything complicated.
There are some funny neologisms like "check it out on the git" since they don't know what git actually is Vs how to use it but still.
So what's your conclusion from this failure? That everyone else is stupid? You're a bad teacher? Or it's not actually simple and the above explanation includes a ton of implicit understanding of the subtle interactions of the various moving parts?
For the majority of programmers I think it's lack of experience with data structures of any kind. C programmers have to understand pointers and most (I assume) would have implemented at the very least their own linked list at some point and maybe even a tree. But there are so many programmers who simply lack this experience so talk of pointers, links, graphs etc. is unfamiliar.
Then there are those whom I'm sure should have the necessary experience (because they are C programmers, for example), but still don't seem to get it. These people I think just don't care. They don't care about version control and therefore it's irrelevant what git is trying to represent. They just want to get their code merged.
That reminds me about the old joke about monads: At the moment you finally understand them, you lose the ability to explain them.
Seriously, I too find the basic concepts of git quite simple. But whenever I want to do anything slightly out of the ordinary, I find myself wasting a lot of time searching the docs. In fact, I find the naming of commands and their options almost the opposite of intuitive, given my understanding of the basic model.
I can't use the command line at all. It's horrendous and makes no sense. I use magit for everything if I can. If I can't then, like you, I have to spend ages searching the docs.
The way I tried to understand Git at first was like Subversion. Horrible. I almost deleted everything my team worked on for weeks.
Then I read "git inside out" [1] (not to be confused by "git from the bottom up" which I think is not as good), had a "aha!" moment, my view changed and everything became clear and easy. Transformation from graph to graph is something I do every day, so why not in Git?
More directed acyclic graph (DAG), which I suppose is still a type of graph. That said I'm not sure if "graph" is conceptually better than "tree with cross connections". People that struggle with git may not have a good enough grasp on the differences between these structures that insisting on using the "proper" names is immediately helpful.
Can only echo parent. 3 places of work in varying sizes, 4 projects in varying maturity, not a single RMQ administration staff that was competent enough to reliably run the cluster.
Which of course leads me to believe the problem isn't with the people but with the ridiculously high threshold of knowledge, experience and app developer self-control needed to run RMQ successfully.
As parent said, many meltdowns later, I'm now firmly in the "No Rabbit!" camp. Redis pubsub/queues for immediate lossy delivery, kafka / gcp pubsub / aws sqs for less latency sensitive flows that require more consistency guarantees.
I concure. I like RMQ because I know how to configure and administer it but I would never trust anyone with it. My first exposure to it was on a project where the lead architect failed to read the documentation let alone understand any of it. Several years later I was able to fix it and then left it in the hands of some other incompetents.
Personal theory: they're like juggling. Satisfying but ultimately useless.
Many clicker games are perpetually-changing resource-balancing and short-vs-long-term-tradeoff games under the hood. Do you spend your [_] on something linear and replace it soon, or exponential but you'll be waiting longer for the next thing? Do you spend [#] to support more passive styles, or do you go full [%] and spend 30m micro-optimizing by hand to save hours later?
That same kind of thing exists in the core of lots of games. E.g. look at StarCraft - Zergling rush, or get more resource gatherers? Early and mid game is super heavily focused on this, and the players and community spend incredible amounts of effort micro-optimize their setup to get even one more unit in a time window. Through this lens, the combat is primarily evidence of your superior resource management, and whether you investigated your opponent's plans well enough.
---
They're of course not all homogeneous, but if I had to pick one thing they overwhelmingly share in common, it's this resource-balancing aspect. And they go a heck of a lot further in it than most other kinds of games do.
Plenty of low-brow there as well, and basically being forced into the plot against your will is very on-point for a "I just want to make a buck" character.