zemo

HN isn't really a bastion of media literacy or tech criticism. If you ever ask "does [some technology] affect [something qualitative] about [anything]", the response on hn is always going to be "technology isn't responsible, it's how the technology is used that is responsible!", asserting, over and over again, that technology is always neutral.

The idea that the mechanism of how people communicate affects what people communicate is a pretty foundational concept in media studies (a topic which is generally met with a hostile audience on HN). Slack almost certainly does play a role, but people who work in technology are incentivized to believe that technology does not affect people's behaviors, because that belief allows people who work in technology to be free of any and all qualitative or moral judgements on any grounds; the assertion that technology does not play a role is something that technology workers cling to because it absolves them of all guilt in all situations, and makes them, above all else, innocent in every situation. On the specific concept of a medium of communication affecting what is being communicated, McLuhan took these ideas to such an extreme that it's almost ludicrous, but he still had some pretty interesting observations worth thinking on, and his writing on this topic is some of the earlier work. This is generally the place where people first look, because much of the other work assumes you've understood McLuhan's work in advance. https://en.wikipedia.org/wiki/Understanding_Media

on the one hand this is pretty funny. On the other hand: if you want to experience the entirety of a game without traveling, why play a location-based game at all?

arguing that "you should be able to get the whole experience regardless of your location" is basically arguing against the entire category of location-based entertainment products. The experience is related to your location. That is literally the product.

> game development is also game engine development

not necessarily. Loads of games and game developers do not engage in any engine development at all, they just use an off the shelf engine and make their game, treating engine developing about as close as web devs treat database development.

that's definitely what I hear from people who leave academia and go into industry, but that's not a representative sample. Are the people you're referring to as academics all people who left academia before you talked to them?

> Altman and his ilk believe they're the new Leonardo Da Vincis, but they're little more than petty kings and rent-seekers trying to steal the world's magic.

what’s sad is they don’t even compare themselves to historical patrons. Would we have Bernini without Borghese? Perhaps, perhaps not, but the genAI peddlers aren’t trying to grow artists and grow culture, they are trying only to grow content and sell it. It is a structure that is far less enriching for society than the patronage model.

> I know we likely disagree on the usefulness of those, but if you are privacy concerned why would shotspotter even be on the same level of concern as cameras that don't need a gunshot to start filming?

I think that is also bad. Two things can be bad! That's just not the topic of the post.

> It just says a signal if there is a loud noise in public.

as a community we really ought to be suspicious of claims like this. There's another word for "acoustic sensor" and it's "microphone". When a corporation says "trust us, we only use the data for good", we should collectively raise our eyebrows, knowing that when data is collected for one stated purpose and stored, that the data at rest will always be used for additional purposes. Once data is collected, the number of things it may be used for is always unbounded; any claims to the contrary should not be taken at face value.

Apple’s take on the VW Bus would be very on-brand imho

begging people to recognize that a person who sells a solution is going to view these problems through the lens of being rewarded for applying their solution to your problem, even if it's not appropriate.

> Yet, per my own experience it’s still extremely hard to explain what does Charity meant by “logs are thrash”, let alone the fact that logs and traces are essentially the same things. Why is everyone so confused?

Charity is not confused, Charity is incentivized. What she means by "logs are trash" is "I do not sell a logging product". (and, to be clear, I'm only naming Charity individually here because that's who the author named in their article.)

> When I was working at Meta, I wasn’t aware that I was privileged to be using the best observability system ever.

The observability system that is appropriate for Meta is not necessarily appropriate for your project. Those tools are cool but also require a pretty serious investment to build and operate correctly. It's very easy to wade into a cardinality explosion problem when tagging and indexing everything you can imagine, it's very easy to wade into problems regarding mixed retention policies when some events are important and others are less-important, it's very easy to wade into a latency-sensitivity issue if you're building a log/event collection infra that you don't allow to ever lose data, etc. As it turns out, observability is a large topic.

The idea that there's one "best" way to do observability is a little ridiculous. Like when I worked at Etsy some of the data was literally money, when I worked at Jackbox Games we made fart joke games (Quiplash, Drawful, Fibbage, You Don't Know Jack, etc) and the infrastructure was nothing but pure cost. The observability needs of those two orgs were phenomenally different, because the products were different, the revenue models were different, the needs of the users were different, etc.

Also this notion that "all you need is wide events" is the answer seems ... really shallow. A data point is an unordered set of key-value pairs? That's how ... a LOT of logging, metrics, and tracing infra expresses things at the level of an individual record/event. The difference is in the relationships between the keys and values, the relationships between the individual records, etc.

and "stop sampling" is just a bizarre marketing angle. If you have 1 million records or 10 million records and you get the same squiggly line out of analyzing it, congrats you have inflated the size of the data that nobody ever looks at. There is only one person who this benefits and it's the person who charges you for the pipeline, which is exactly why people who sell a pipeline are incentivized to tell you that sampling is bad: if you are sampling, you are sending and storing and querying fewer data points, so they are charging you less money. They are getting paid to tell you that sampling is bad. Sampling is not good or bad, sampling is sampling. The reality is that in a lot of these systems, the vast majority of the information will never, ever be looked at or used. Whether or not that matters is entirely context dependent.

the places where I've seen people leverage the folder-level permissions in Perforce (in the games industry) would be like: a contractor that provides art would only have access to the portions of the project that relate to the art they're working on but not the code; translators might have read access on one directory and write access on another directory. In academic settings I've seen Perforce used such that an instructor has read-write access on a directory and students have read-only access on the directory, and then each student has a subdirectory where they have read-write access and everyone else has read access, so that everyone can play each other's games. You can do stuff like this in git with submodules but it's somewhat complicated and difficult to teach to non-programmers. It's not really clear what the target audience is for the project. The mathematical/theoretical foundations are clear, but the target audience is unclear, so I'm not sure if these are use-cases that you consider to be within the project's scope or not; just sharing how I've seen the permissions models used in the games industry.

oh and nearly everyone hates using perforce and its clients p4v and the p4 command line, so it’s not like there’s no appetite for change. There’s very much an appetite to see Perforce unseated, because it costs money and is also bad.

some indies use Subversion, but Perforce is the industry standard.

> what is the motivation for making distributed VCS?

it depends on if you're asking about the motivations for distributed version control for linux kernel development in 2005 or the motivations for distributed version control today. git predates AWS and predates the state of the industry being that it's very easy and cost-effective for people to make central servers and web apps and things of that nature. My understanding is that "emailing a patch to a mailing list" was a more reasonable workflow then, since it piggy-backed off of people's email hosting providers (which, at that time, wasn't even "everyone using gmail", since back when git was created, gmail was invite-only; git predates gmail having open signups). Plus Subversion's branching model wasn't particularly great, so having different people work on things on different branches and giving them feedback and merging the branches when they were ready wasn't really a great experience.

The distributed nature of the version-control system facilitates branches, since a branch and a copy of the repo somewhere else are abstractly the same thing. Practically speaking, people don't push and pull code between their workstations and the network topologies are typically centralized in nature, but on a data level the distributed model is dual to the branching model, and the branching model is the thing that people actually care about. Although I _do_ think it's pretty neat that you can use a thumb drive or NAS as a remote instead of needing a server, it's probably not a core use-case for most people and most projects.

> Even I have to use git because who uses anything else?

It's pretty widely not used in the games industry because its support for media files is poor, it's pretty difficult to train artists to use it, the integration with game engines is pretty poor, git LFS is a layer of complication on a system that already has UX that's difficult for artists, git LFS hosting is an additional can of worms, there's essentially no file/directory-level permissions for managing contract work (and doing so with submodules+LFS is complicated).

> Open models feature free access to the model weights, but terms of use, redistribution, and variant ownership vary according to a model’s specific terms of use, which may not be based on an open-source license.

does a model being "open" say anything about how it was trained?

or people will stop reading online because of declining signal to noise ratio. Why should I bother to spend the time reading something that a person couldn’t bother to spend the time writing?

I think most people consider "history" to mean "things that have actually happened" and not "the aesthetic of the past" as you seem to be suggesting.

that would never happen because someone owns the robots and rich people can afford more robots than poor people and rich people aren’t rich people if poor people aren’t poor

yeah I think a tech company showing how their tech can be used to cause damage to a humanities field as one of their leading product demos is bad

> Prompt: Historical footage of California during the gold rush.

this is the opposite of history

> The founders that work in defense are mission driven

That's not really saying anything, since it doesn't say anything about what their mission is. Sure, you have to be mission driven to get things done and lots of good and necessary things have been accomplished by people who were mission driven, but every villain in history was mission driven too. To point at someone and say "they are mission driven" as if being mission driven is on its own evidence that someone is good is at best naive.

> they see nation-state preservation as a moral issue.

hmm, surely at no time in history was a bad thing done by a leader who believed that nation-state preservation was a moral issue.

> They would fail to “make a buck” if that was their only goal

A somewhat peculiar and unsubstantiated claim about an industry that famously makes enormous amounts of money.

> See “American Dynamism”

I'm not really sure what sort of point you're trying to make here other than "VCs like defense companies".

I’m not confused about what it is, I just don’t like it. It’s a lot of ceremony for very little gain.

The options for the thing being constructed are all separate types from the thing being constructed; the options aren’t a facet of the definition of the type they mutate.

I just use a struct literal, and then I have the type define a `func (t *Thing) ready() error { ... }` method and call the ready method to check that its valid. I prefer this over self-referential options, the builder pattern, supplying a secondary config object as a parameter to a constructor, etc.

I used that pattern for a while but stopped using it. I first encountered it from this blog post: https://commandcenter.blogspot.com/2014/01/self-referential-...

It's a lot of boilerplate to create something that's not actually immutable. It also makes it harder to figure out which options are available, since now you can't just look at the documentation of the type, you have to look at the whole module package to figure out what the various options are. If one of the fields is a slice or map you can just mutate that slice or map in place, so it's not really immutable. The pattern as Pike describes it has the benefit that supplying an option returns an option that reverses the effect of supplying the option so that you can use the options somewhat like Python context objects that have enter and exit semantics, but in practice I've found that to be useful in a small portion of situations.

> func NewServer(... config *Config ...) http.Handler

one of my biggest pet peeves is when people take a Config object, which represents the configuration of an entire system, and pass it around mutably. When you do that, you're coupling everything together through the config object. I've worked on systems where you had to configure the parts in a specific order in order for things to work, because someone decided to write back to the config object when it was passed to them. Or another case was where I've seen it such that you couldn't disable a portion of the system because it wrote data into the config object that was read by some other subsystem later. The pattern of "your configuration is one big value, which is mutable" is one of the more annoying patterns that I've seen before, both in Go and in other languages.

yeah weirdly the Wikipedia page right now says it's 10% and its source is this article, which ... does not say that.

am I hearing things or at 6:28 does she call her dog "Browser"

> this is just replacing one silly measure with another

> Not to say anything of your research

The second statement isn't true just because you want it to be true. The first statement renders it untrue.

> I'd rather us start grading developers based on the outcomes of software. For instance, ... errors generated by a service

yeah you should click through and read the whitepaper and not just the summary. The authors talk about similar ideas. For example, from the paper:

> The more Churn becomes commonplace, the greater the risk of mistakes being deployed to production. If the current pattern continues into 2024, more than 7% of all code changes will be reverted within two weeks, double the rate of 2021. Based on this data, we expect to see an increase in Google DORA's "Change Failure Rate" when the “2024 State of Devops” report is released later in the year, contingent on that research using data from AI-assisted developers in 2023.

The authors are describing one measurable signal while openly expressing interest in the topics you're mentioning. The thing is: what's in this paper is a leading indicator, while what you're talking about is a lagging indicator. There's not really a clear hypothesis as to why, for example, increased code churn would reduce the number of production incidents, the mean time to resolution of dealing with incidents, etc.

check out the paper, not just the summary. They explain their methodology. The output has four data points because it’s a summary. The input is … more data than that.