cybrexalpha

Rowling is a bigot and it's unethical to promote her works, even indirectly.

She uses her wealth and fame, legitimized by continued engagement and spending with the Harry Potter IP, to attack, demonize, and spread hatred about entire groups of LGBT+ people.

This isn't a branded product, and I know no money directly ends up in a bigot's pocket because of this, but every time her works are referenced it endorses her hatred.

The visibility is a huge part of it. It signals "it's okay to be yourself here" when most professional life, even in tech, is dominated by keeping up "professional" appearances.

You can't compare a decision made in possession of all of the facts in a calm environment with full hindsight, with decision made in the moment with limited information and hundreds of lives on the line.

Go's module system got a lot right, but it's a complete nightmare to work with. The author actually highlighted one of it's very worst traits:

> Go got it right from the beginning and didn't use a centralized package registry to manage dependencies, but instead you have to directly point to the source code of the packages.

Directly coupling the identity of a package to its location means that you can't change one without the other. Need to rename to a fork of a dependency? You'll have to touch every single file that imports it. Need to use a organisational local cache for deps? It better be a transparent proxy or you can't do that. The only support for this is replace statements in go.mod files, but those tie you even further in knots when you need to pull in a dependency that has a replace statement in it.

It's even worse on the maintainer side. If you want to rename a git repository, rename a GitHub organisation, migrate a repo to a different owner, or even move git hosting providers then you risk breaking every single downstream. The only solution is to host a proxy for your packages on a custom URL that redirects to the backend hosting provider, and set your Go module's name to be on that custom URL. Which requires you to do this ahead of time before the package is widely used.

Cargo and crates.io could be better but Go is the worst place to draw inspiration from as it's full of ideas that seem clean, work at first, and break in hard to fix ways once you do anything complex.

The big thing is that dealerships do not have new cars sat around on the lot waiting to be sold. They usually have second-hand cars available, but new cars are always built to order.

Ignore the advice of anyone who doesn't have ADHD, or a medical degree with a speciality in ADHD treatment. Anyone that tells you that you just need to try one "trick", a planner, a mindset change, default mode networks, "try sleeping more", whatever, can either never understand what it's like or is trying to sell you something. Or both. If someone neurotypical gives you advice, just smile and nod, and ignore it. If someone tells you ADHD is a "superpower" promptly ignore them. Unfortunately, this often applies to generalist doctors who don't specialise in ADHD.

The reality is that there is no single thing that will help. You'll have to try shit and see what works for you. What one person swears "fixed" them might do nothing for you.

That said, the one thing that is the most likely to work out is medication. Get yourself a diagnosis, try the meds, see if it helps. Caffeine is fine, but it's no substitute for the real stuff.

This isn't a tangential discussion. Ring has shown they're willing to work with law enforcement without due process, that's the entire point of the EFF's article.

> you're mistaken about what the terms allow. When you paraphrased the terms as saying

I didn't paraphrase. I quoted them directly. Feel free to check them yourself https://ring.com/terms

> you neglected to account for the clause: "as required or permitted by law". Under the Stored Communications Act, 18 U.S. Code § 2702 (b), there is only a short and narrow list of circumstances under which it is permissible for a provider to disclose communications content without a warrant.

There are so many exceptions it doesn't matter. From the same code, (b) (8) states "if the provider, in good faith, believes that an emergency involving danger of death or serious physical injury to any person requires disclosure without delay of communications relating to the emergency", and (b) (7) (A) (ii) "to a law enforcement agency if the contents appear to pertain to the commission of a crime".

This is exactly how Ring shared content with the cops previously. https://www.cnet.com/home/security/ring-google-and-the-polic...

The feature doesn't exist yet. Ring have said it'll be user consent, but we don't know that for sure. My point is that Ring can change their minds about this at any time without informing you, so it doesn't matter how they say it will work if this possibility is still there.

The two are very different.

If you are subpoenaed then you're obligated to respond, and the same is true for Ring. But that's not what we're talking about here. This is law enforcement requesting access, and Ring doesn't require a formal subpoena or warrant. They can decide to comply to nothing more than "someone from a .gov email asked nicely".

It's written out in their terms of service:

> you also acknowledge and agree that Ring may access, use, preserve and/or disclose your Content to law enforcement authorities, government officials, and/or third parties, if legally required to do so or if we have a good faith belief that such access, use, preservation or disclosure is reasonably necessary to: > > (a) comply with applicable law, regulation, legal process or reasonable preservation request; (b) enforce these Terms, including investigation of any potential violation thereof; (c) detect, prevent or otherwise address security, fraud or technical issues; or (d) protect the rights, property or safety of Ring, its users, a third party, or the public as required or permitted by law.

So Ring is quite happy to hand over your footage to anyone so long as Ring believes it's "reasonably necessary" to protect the rights or property of anyone.

This isn't about Ring complying with a legal request. This is about Ring undermining the fourth amendment entirely by saying "we'll give law enforcement whatever they want".

Yes, but they have to subpoena you. That means process, that means getting a judge to sign it, and it means you can limit scope (i.e., if the incident under investigation occurred outside your home, you're not going to need to provide any footage from inside).

That also jumped out to me as pretty weird. Buildkit as a library is nice, but there's no way it's good enough to justify throwing out the entire project. It feels like there was some big change internally, and the new team either wanted to rewrite and didn't know Rust, or ideologically prefer Go to Rust.

Edit: Although looking at it, maybe not?

Both the new project railpack[0] and the older one nixpacks[1] are both started by and mostly written by the same person[2], who is also the author of the article in question. So it doesn't look like a team change.

It still feels... odd? Less that they made the change, projects go from Rust to Go all the time. But usually it's because of issues with Rust (hard to hire for, learning curve, etc.), describing it like this feels unusual?

[0] https://github.com/railwayapp/railpack

[1] https://github.com/railwayapp/nixpacks

[2] https://github.com/coffee-cup

> Do you have some political goal?

Again, what political goal or agenda do you think I’m pushing?

> Changing does not bring any advantages.

Sometimes, progress requires fundamental change.

> So why waste any time with them?

Can you not envision a business model that is not a high-growth startup?

> What is your real motivation? You seem more focused on some political agenda than you are focused on making a profit.

What agenda do you think I'm focused on?

I disagree with the implication that flat structures "don't scale" or can never work. To be effective in a flat environment requires a fundamental shift in perspective. Hierarchy is so baked in to every other company, organization, and education system that people just don't know how to operate absent it.

ICs will need time to adjust to a flat structure, and some people will do anything to fight the absence of the restrictions they've always known. Hiring a bunch of senior ICs from traditional industry roles and saying "we're not going to have managers!" is always going to fail.

For a CTO/founder it's even easier: If you're building a VC-funded start-up where the plan is to grow fast exit in a few years — what's the point? Why invest the effort and energy to making flat work when the moment you get bought out the hierarchy is back anyway.

There are examples of stable large companies with flat org charts that do work, they're just not the hypergrowth scale-ups. The book "Reinventing Organizations" covers several in depth, and is a good intro to the topic. So my objection is the implication that a flat structure can never work, or that there is something fundamental about a flat org and human nature that means it's unstable. It is simply that it requires long-term investment to get right, and the market isn't setup to reward long-term investment.

Yes.

H. P. Lovecraft is a good example from literature. He was profoundly racist, even beyond the cultural norms of his time. However, as he has long since passed away buying and amplifying his works do not further his views and causes.

A modern counterexample would be J. K. Rowling. Where supporting her works and properties does directly contribute to furthering her prejudices in a very real way.

In the long run, in many cases, it probably would be cheaper. It's just that the incentive structures between the long-term health and executives are not aligned .

> wouldn't there be a huge competitive advantage to being the CEO who said, "hey, we can get rid of all our expensive SaaS, free up a bunch of cash for productive investments, and make a bunch more money"?

Unfortunately, this isn't how large org CEO compensation works. CEOs of large publicly traded companies are mostly compensated by the stock price. Either directly as it increases the value of their significant stock grants, or indirectly as their cash bonuses are tied to stock performance. Stock performance is mostly a result of quarterly financial performance. Therefore, directives that take a long period of investment are much less attractive.

Say you were the CEO of a multi-thousand person organisation. Your SaaS bill is through the roof, and so you want to in-house everything. Not only do you need to disrupt nearly every employee by changing the way they work (depending on what you're replacing), you need to enter into co-location contracts, buy hardware, and hire staff to mange that hardware. It's a very large up-front cost (likely in the tens of millions on hardware alone) that in theory will pay off in the long term, but investors and the market will see a spike in your assets on your P&L, and will question why you're tying up capital in hardware instead of building the stuff that you sell. That's assuming you have the cashflow to buy all that hardware in the first place.

There's a difference between identifying areas where a new technology (AI) can solve a problem in a better way, and just slapping "Now with AI!" on an existing product purely to chase investor dollars.

One of my soft requirements for engineering roles is "no agile". Usually if a hiring manager tells me that team is an agile one it's a very clear sign that I don't want to work there.

Of course, this pickiness is only if I'm in a situation where I don't need to move. I can think of plenty of cases, for example being laid off, where I'd take a role in a scrum team.

Minecraft is still pretty opaque. It's gotten a lot better with the recipe book and advancement list giving some guides. But if you'd never played or interacted with Minecraft before and were dropped into the game I'm not sure you'd ever understand how to do certain things without outside help - be that the wiki or watching another player. Are the ruined portals dotted around enough to make you realise that you can craft a nether portal? How would you figure out how to make eyes of ender? Even if you made one would you understand what it does? Once you found a stronghold it's not unreasonable that you'd figure out how to open the portal, and once in the end the fight with the dragon should be pretty obvious (even if it takes you a while to figure out an effective strategy). But what then, would you find the end gateway and see the outlying end islands? Would you wander around enough to find a city and a ship? Would you understand what Elytra do, or what Shulker boxes do? Both of those elements (Elytra and Shulker Boxes) are so fundamental to how the game is actually played that it's a different game without them.

The whole concept is so fundamentally flawed that no amount of tweaking or improvement can save it. Of course the implementation is terrible, but even if the implementation was perfect it would be awful. Even if it ran locally-only, even if the implementation were pure free software, even if the LLM used was guaranteed to operate in your best interest.

Even then, we're still talking about a perfect surveillance engine that allows any future person to observe your behaviour across your past. Imagine what it would mean for the police to retroactively search your entire life for the past 30 days when they arrest someone. Or how this might affect people living with abusive partners, or LGBTQ+ kids in non-supportive households.

This technology, no matter the implementation, puts vulnerable people at risk.

I'm getting increasingly nervous about baking in assumptions on software that doesn't have a strong guarantee of staying open source. Foundations like the CNCF help here, where projects are assigned ownership to the foundation.

There is a middle ground though. It's not practical to only build on top of foundation-owned software. So a metric I use these days is to consider the cost of replacement or fork maintenance, combined with how likely I think a license change would be, as part of evaluation.

Which of those options do you view as 'the style'? One block, two blocks (core library and others), or three (core library, 3rd party, same-source-tree).

For an internal-only dependency it's possible. But if you've got a lot of active branches, or long-lived feature branches, it'll create chaos in merge conflicts. Even worse if you've got multiple supported versions of a product on release branches (e.g., `main-v1.0`, `main-v1.1`, `main-v1.2`, and `main` itself for the yet-to-be-released `v1.3`) you either make backports awful (by only changing the import path on `main`) or have to change even more things (by changing the import path on the release branches too).

It's effectively impossible for pubic-facing dependencies. Imagine if https://github.com/sirupsen/logrus wanted to change their Go modules import path, for example to move to another git hosting provider. (Logrus is great by the way, I'm only 'picking' on it as a popular Go library that's used everywhere.) GitHub tells me that almost 200,000 Go projects depend on it (https://github.com/sirupsen/logrus/network/dependents), so all of them would need to change every source file they do logging in (probably most of them) in order to handle that.

GitHub seems like it's going to be eternal for now, but when the industry moves on in 10 years time every single Go project is going to break. This would be a problem for any source dependency management solution of course, it's not like any of the others are immune to this issue. But because Go has you encode the Git path in every source file you import it into, the level of change to fix it is an order of magnitude higher.

It does a lot well. For example it correctly pins dependencies by hash in go.sum. It's by no means the worst dependency management system I've ever used.

IMO the biggest miss with Go modules is conflating the identity of a dependency with how you get it. This means that renaming a repo not only breaks the module itself (as you self-import other modules in the same source tree using the full path), but all of your dependencies. I've seen repos be renamed from github.com/foo/proj to github.com/bar/proj as part of organisational reshuffles, and then there's a big warning somewhere that says "never make a github.com/foo/proj repo or it'll break GitHub's automatic forwarding for renamed repos, and you'll break every package that depends on us."

There are workarounds like using replace directives. But that makes an even worse situation where you can read a source file and assume a dependency is at github.com/foo/proj but actually it's elsewhere. But ultimately a real fix involves touching every single file that imports your dependency. If Go modules left the way of pulling a dependency in go.mod alone it wouldn't.

You should use a Go modules proxy to solve this, and a custom import path. But by the time most orgs realise they need this it's too late and adopting one would be a huge change. So you end up with a patchwork of import issues.

Yeah I get it. I've found workarounds in the past. But it's always involved some friction.

In general, Go's generics are a huge step forward though. So I'm not that annoyed about it.

> Not sure what you mean by "no generics on interfaces"?

I didn't word this very well. You can have a generic interface, and functions on that interface can refer to generic types. But you can't have a generic method on an interface that uses a different generic type. For example you can't have:

``` type YieldThing[T any] interface { Yield() T DoOperation[U any](U) } ```

Go fmt is pretty good, but it's not ideal. My biggest gripe is imports. Go fmt will just sort imports alphabetically in lists that aren't separated by a blank line. Goimports will separate out core from 3rd party imports, unless you run it with the local flag then it'll add a third block of "local" imports.

But this spread means that it's not consistent across projects which style is preferred.

Some examples, based on cursory looking at big Go codebases: - Kubernetes, one of the biggest public-facing Go projects, uses the 3-block style https://github.com/kubernetes/kubernetes/blob/master/pkg/con... - TIDB uses 2-block style https://github.com/pingcap/tidb/blob/master/pkg/ddl/placemen... - MinIO uses 2-block https://github.com/minio/minio/blob/master/internal/grid/con...

In all of those cases if you make a change and just run 'go fmt' it very well could inject any new imports in the first block, which would be wrong and you wouldn't know until project CI picks it up.

I've been coding in Go for over five years. I like Go, but I don't love it. It's never my first choice, although I don't advocate for rewrites just to move away from it.

The tooling is a mess. Go modules still feel like a 'first pass' implementation that never got finished. There's no consistency in formatting or imports (even though Go claims there is). Generics are a good step but are still very primitive (no generics on interfaces, no types as a first-class object).

It still feels very unfinished as an ecosystem. I hope it'll get better as the Go team mature things, like iterating on generics. But I can't see Go modules continuing without a fundamental rewrite.

> Why are we generating a structured language (YAML), with a computer, by manually adding spaces to make the syntax valid?

Yep, it sucks. It's not like nobody has tried to do better, but nothing else has the adoption of Helm. Ultimately text is, as always, universal.

If you want a fun fact: the communication between kubectl and the kube-api-server is actually in JSON, not YAML.