weberc2

I’m not familiar with that. I’m familiar with the notion that social media giants should behave more like utilities, but that view is based on the sheer volume of speech that they can manipulate even to manipulate our democracies. However, even that view is not ubiquitous here. The other meme that is more widely held that seems similar to what you are describing is support for net neutrality, which again asks private ISPs to behave as utilities, but for different reasons than those given for social media giants.

I don’t see how this can be anything but a good thing. If you are certain that there is discrimination against women in physics, then this is a great opportunity to convince the world of it.

I never understood the attitude of “trust us, it exists, but no one is allowed to question it”. I think Feynman said something like “I’d rather have questions I can’t answer than answers I can’t question”.

EDIT: I don’t understand the downvotes. Why would someone not want an opportunity to present evidence of their claims and rebut arguments to the contrary? Why are we so adamantly opposed?

To be clear, I didn't say "less than 1 out of every 100 lines", but in any case I don't consider yours to be a reasonable definition of "everywhere". Especially since such a low frequency doesn't support your claim that "you see runtime type errors too many times to count". Perhaps you're using libraries that are far, far below the ecosystem's average quality?

It's not an important distinction at all. A "program" isn't well-defined; it's inherently abstract. A container is a manifestation of a running program as is a Unix process; both are "runtime environments" differing in their isolation properties (Unix processes provide memory isolation, containers provide memory as well as other kinds of isolation, at least to the extent that the underlying operating system supports).

> There's a lot going on between a K8s pod, a container, and the actual program. It's just not Unix-y at all.

The Unix philosophy pertains to composition, not implementation.

> I don't see the strawman here.

You picked someone else's definition of "operating system", generalized it, and then attacked it for being too general.

> K8s and containerization is frequently mischaracterized as the operating system of the future. The technical details matter and speaking in generalities is misleading (IMO).

Yes, again, this is an analogy. If you interpret analogies as a guarantee that the operands are identical instead of simply "similar", you will be misled.

> Containers are not programs. And even they were, they absolutely do not adhere to the Unix philosophy.

They are programs (barring some semantic nitpickery about "programs run in containers"), and like programs, we can't make blanket statements about whether or not they implement the Unix philosophy. Some do and others don't.

> I've heard this enough times and seen enough K8s systems in production that I'm labeling this "fluff". K8s is an operating system in the same way that "everything is everything". K8s is software that manages containers and their resources.

Yep, like I said, an analogy: "An operating system is software that manages processes and their resources". By definition, the operands of an analogy are different, so if your thing is taking any analogy and calling "gotcha!" because you found some differences, then I'm afraid you're missing the point.

> From Wikipedia: >> An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs. > You can generalize "software resources" as container resource limits. You can generalize "common services" as the network and filesystem layers. And you can generalize "computer hardware" as kernel configuration on the control plane. > All of these are purpose built abstractions built on top of the real operating systems. By that logic you could call any virtual environment or virtual machine an operating system. And if that's the true then the comparison isn't useful at all.

That's quite the straw man.

Yeah, veteran sysadmins probably aren't its target audience. Orgs probably want to be able to enable their dev teams to deploy/operate production infrastructure without hiring a legion of sysadmins with decades of experience. Kubernetes, like all technology, is meant to lower the bar.

Kubernetes is the operating system in this analogy, and it’s quite a modular operating system at that. Specifically, it schedules the programs that themselves should adhere to the Unix philosophy. I don’t think the Unix philosophy ever extended to the OS (although microkernels seem to be driving in that direction).

I don’t think this extends to libraries, which are units of composition and each unit comes with a more-or-less fixed amount of overhead for managing the trust relationship with the maintainer (as well as other things, like managing the version to pin against, etc).

I imagine it’s easier to persuade people who are used to and depend on trains that they should build more train lines. For better or worse, most Americans are happy with their cars and train transit is at best a nice-to-have.

It is used for things like printf and JSON marshaling. I’ve been using Go regularly since 2012 and this isn’t a real problem. The reflection in the standard lib and popular third party libs (and most unpopular third party libs for that matter) is rock solid. Moreover, reflection probably accounts for less than 1% of Go code—not sure where you’re getting “everywhere” from. So I guess I’m calling your bluff.

Ah, that would make sense. I’ll have to take your word for it.

How do you arrive at that conclusion in light of his grievances with Holmes/Theranos? Seems pretty obvious that he is distinguishing between the degree of damage between different scams, believing it is worse to harm low or middle class sick people (with their inherent lack of safety nets) than wealthy investors. Whether or not you or I agree with this assessment, we should be able to distinguish between that point and your interpretation.

Go doesn’t rely heavily on runtime reflection. Putting it in the same category as C or JS is disingenuous. Rust has a great static type system, but I’ve never seen a Go program fail on a runtime/reflection type error before.

Rust has its own -rs thing going on.

Not sure who "many people" are, but no one in this thread is claiming that git is unworkable, only that it is confusing. A collaboration tool like git is highly subject to network effects. The usability delta between git and a given alternative must be very, very high before people will leave git for the alternative. Ergo, git can be both awful and "good enough" to have a majority market share (although I don't think anyone is even saying git is awful in this thread).

> And where are they now?

https://en.wikipedia.org/wiki/Survivorship_bias

> I'd venture a guess that your familiarity with hg is interfering because the conventions are different.

Git users also need to answer questions like "What changes are in my feature branch?" (e.g., a PR) and "What changed in this commit?" (e.g., GitHub's single-commit-diff view). These aren't Mercurial-specific questions, they're applicable to all VCSes including Git, as evidenced by the (widely-used) features in GitHub.

Even with Git, I've never wanted to know how my workspace compares to another branch, nor how a given commit compares to my workspace (except when that commit is a small offset off my workspace).

> In other words, if you elide the second argument, it defaults to wherever HEAD is.

Yeah, I get that, but that's not helpful because I still need to calculate the second argument. For example, `git diff master..feature-branch` is incorrect, I want something like `git diff $(git merge-base master feature-branch)..feature-branch` (because the diff is between feature-branch and feature-branch's common ancestor with master, not with HEAD of master).

One of the cool things about Mercurial is it has standard selectors for things. `hg log -b feature-branch` will return just the log entries of the range of commits in the feature-branch (not their ancestors in master, unlike `git log feature-branch`). Similarly, `-c <commit>` always returns a single-commit range (something like <commit>^1..<commit> in git). It's this consistency and sanity in the UI that makes Mercurial so nice to work with, and which allows me to recall with better accuracy the hg commands that I used >5 years ago than the git commands that I've used in the last month.

> If they had built their own framework, the team that produced it could just as easily published a security patch that was ignored.

I believe you're just making the inverse assumption from Cox. He seems to assume a monorepo-esque setup where everyone depends on HEAD, and you seem to assume a microrepo-esque setup where everyone declares their own dependency revisions.

/u/samatman is definitely mistaken, and I think you are correct (although I'm not sure about "the set of changes since that commit"). As far as I can tell, `git diff <commit>` and `git diff <branch>` both just diff your current workspace against the commit/branch respectively.

In the case of the branch, the correct result is something like "what has changed since my branch diverged from its parent"--basically what you see in a PR. I think this is unnecessarily obscure in Git because a "branch" isn't really a branch in the git data model; rather it's something like "the tip of the branch".

I don't think I've ever wanted to compare my workspace against a branch, but clearly diffing the branch is useful (as evidenced by PRs). Similarly, I'm much less inclined to diff my workspace against a particular commit, but I often want to see the contents of an individual commit (another common operation in the Github UI).

In essence, if Github is any indicator, Git's data model is a subpar fit for the VCS use case.

If your achievements came about by luck then how do you get off claiming credit for their success? I don’t think git was purely luck—it is a formidable tool in its own right, but there are better tools out there, and that was especially true at the time when git really took off, which is to say when GitHub began to be popular.

I don’t think those examples were meant to be an exhaustive list of git’s UI warts. There are many that are harder to remember and creating aliases and functions for each of them require building a full alternative UI. For example, how do you see all of the changes in a branch (IIRC the equivalent of ‘hg diff -b branch-name’)? How do you see the changes for just one commit (I.e., ‘hg diff -c $commit’). These things are all feasible in git, but I can never remember the incantation, so I have to Google every time. I haven’t used hg in 5 years and I still have an easier time remembering those commands.

I can still never remember the git equivalents for things like ‘hg log -r default:feature-branch’ or ‘hg diff -c <commit>’. People who haven’t used Mercurial really have no idea how pleasant a VCS interface can be.

I doubt Git would be popular without GitHub. Had the GH founders instead been more familiar with Mercurial, we would all be using the latter. Having used both extensively, I think we would all be better off in that alternate history, but such is life.

I'm not coming from INI files. :) I actually always felt they did a poor job of representing anything more than key value pairs and they weren't standardized, so I always managed to avoid learning the grammar(s). I'm sure if I put much effort into it, I could figure out TOML, but I don't want to ask my users to figure out yet another configuration language.

If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like.

> That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this.

I'm not really familiar with this. I'll have to read up.

I meant that the review score should tell you whether or not you need to read between the lines. If you don't want to read between the lines, stick to results with 4+ star reviews (maybe 4.5+ star reviews). I _also_ read other reviews out of an abundance of caution and to give some insight into how the top results differ. We should be able to agree that this is not meaningfully "reading between the lines" even if we don't agree about the reliability of average review score as an indicator.

> need to read "between the lines" of misleading representations of properties.

I've never had a problem with this, but I also don't bother staying anywhere that doesn't have a 4-star or better average. If you just set your filter at >= 4 stars, then these problems go away, and we also comb through the reviews of our top picks to make sure there's nothing unexpected. Consequently, we've had nothing but good experiences.

Because there is very little supporting evidence for discrimination of any kind that could justify the “privilege” hoopla, and every time you press someone on their meaning of “privilege” they retreat from the “discrimination” definition to some abstract, probably circular definition (e.g., “men are privileged because there is no sexism against them; you can’t be sexist against men by definition because men are privileged”).

You’re welcome to your opinion. I disagree that XML is ideal for representing tree structures or anything else for that matter. I’ve used XML a lot (including for UIs and other tree-like data structures), but ever since JSON became popular I haven’t found myself missing it.

I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)

I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human use cases. YAML works well for human-to-machine (JSON could fill this use case as well if it would support comments and multi line strings). I don’t use TOML much, and good riddance to XML.