jdub

Licensing and testing is not an inevitable consequence of unionisation. Those are more closely associated with professional associations or guilds, which don't tend to represent the same kinds of workers as unions.

When you see the phrase "it's worth mentioning" in a press release, you can be pretty sure it's not worth mentioning.

Please don't mischaracterise the point: The solar storm is not more likely than a software bug. The effect of the solar storm is more likely than a similar effect by a software bug (particularly in the context of AWS).

That's just ideology.

It does both. Linting and fixing are done at different times.

Yeah, you need to read more of the sqlfluff documentation. :-)

I've been using sqlfluff with dbt for a while now, and not only has it been a delight to use, the maintainers are incredibly responsive.

Ask a Googler about the size of their environment variables.

Revolutionary incremental improvement?

Cloud Control provides a direct API to the primitive functions that underpin CloudFormation resources. So, if you look closely at what it's doing (hint: "desired state" parameter), Cloud Control is declarative on the resource side.

I don't think that replaces other AWS resource schedulers like Terraform and Pulumi, but it could, uh, embrace them into a more CloudFormation-oriented ecosystem, which is clever.

It's mind-boggling* that a company can be entirely aware of their negative impact on teenagers and think, "We have to go deeper".

Everyone knows that a richer file chooser is a desirable, highly requested feature and has been for years. There's no question about that, and no one's being dismissive about that. Actually fixing it is a whole other matter.

Genuine user requests are not made in bad faith. Stupid internet abuse is bad faith. Like I said: This issue, and others like it, mostly comes up as thoughtless abuse, not genuine user requests.

You seem like you're trying to convince me that it's a legitimate issue. I already know that. GNOME developers already know that.

Votes in a bug tracker don't represent the priorities of developers or even a representative audience of users. Yes, it's a known issue, but there are trade-offs and a lot of work involved. Most people just aren't aware of the complexity involved in file chooser implementations and APIs.

The file chooser issue is more often raised in the context of internet abuse than good faith user requests. That doesn't mean it's not real, it just means it's fodder for precisely the kind of document we're responding to.

You may have heard the rumour that GTK/GNOME developers make software for simpleton users that don't exist. But you've just run into a power user feature that you don't understand.

Now, what do you think will happen if the GTK/GNOME developers get rid of that "bizarre textbox" so it doesn't get in your way? Yes, they'll get a torrent of abuse for "removing the last power user feature" or something. :-)

This issue is almost never raised in good faith. Just look at this document. Disingenuous, trolling, contemptuous of the work of FLOSS developers. Then look at the comments in this thread, repeating and escalating the same nastiness.

Crap like this contributes to burnout, people leaving the community, etc. Why spend your time on a volunteer effort if you're just going to be abused by non-contributors?

There's a reason behind the problem should anyone care to find out...

Most people reading this thread should have at least some sympathy (empathy, even) for architectural and social challenges in large, long-running software projects.

GNOME is a 22 year old project, and for much of that time its underlying toolkit, GTK (formerly GTK+), was intentionally maintained very separately. The consequence is that, broadly speaking, GTK could not depend on GNOME features.

So, shoving GNOME's Nautilus-powered file management in a GTK file chooser? That's tricky. Other GTK users would not appreciate GTK depending on, well, almost all of GNOME.

A point of integration was required, to allow the outside environment to provide the file chooser user interface. Turns out that's also tricky, especially when your toolkit is providing API/ABI guarantees. Consider that GTK 2.x maintained API/ABI compatibility for almost half the entire lifetime of the GTK project.

But no one gave up. More recently, the XDG portals work provides an opportunity to solve this (and quite a few other problems) cleanly and, more importantly, securely. This will also allow a KDE environment to provide the file chooser interface for a GTK application. Nice! Why isn't it already supported everywhere? Because there are a lot of people and projects involved.

It's entirely legitimate to ask, in good faith, why this wasn't done 10, even 20 years ago.

Consider that building a complete FLOSS desktop system is an immense amount of work, and that's what GNOME (even before 2.0) was focused on. Not just "a user interface for Linux", but making the entire stack work for real people. So many improvements in Linux desktop systems came from GNOME developers deciding that the status quo wasn't good enough. We wanted to fix the kernel, device discovery and enablement, dynamic wired and wireless network configuration, rich input devices, accessibility, etc., etc.

Remember, 20 years ago just getting X to work with your bloody monitor to work was enough of a pain.

Then, consider the priorities of the people contributing to the GNOME and GTK projects. Was it more important to break toolkit API/ABI compatibility to let GNOME replace the file chooser, or maintain that compatibility and work on other, arguably more fundamental problems?

Oh, and you know what happens when GTK/GNOME chose to break API/ABI compatibility for 3.x and 4.x? Everyone complained that FLOSS desktop developers can't maintain compatibility and that's the thing holding back "Linux on the desktop".

Anyway, if you're not already turned off by all the abuse that FLOSS desktop developers cop for literally everything they do, from people who don't know any better and people who should know better, I can still recommend it as deeply satisfying work. :-)

But I wanted to be a Terraform user. So an alternative interpretation is that, as designed, Terraform is slowing down adaptation of the known universe for Terraform users.

My biggest issue with Terraform is the impedance mismatch between HCL and the rest of the known universe.

When you write a provider, you spend half your time converting data structures from the HCL submitted to your provider into the JSON your target service inevitably expects, then you spend half your time converting the JSON your target service inevitably returns into HCL for Terraform to consume, and then you spend another half of your time fixing bugs and polishing.

It's okay when you're building simple providers, but anything reasonably complex becomes unwieldy. I had a go at building some providers for AWS services that were not supported by Terraform or CloudFormation... and I just retreated to cheesy Lambda custom resources for CloudFormation.

The real answer is that they're building filters on top of NTFS because that's precisely how it was designed to work.

The Raspberry Pi 4 is barely a real computer, and hardly comparable. The Honeycomb has faster interconnect with practically everything on the board, so can handle a video card, serious networking and storage performance, etc.

No, dude. Don't wave off entirely valid concerns as "twitter rage-baiting".

Here's three men who have had an immense impact on popular culture having a casual chat about statutory rape and a lot of racist stereotypes, and no one raises an objection. They didn't record this in the 1830s or the 1930s. It was 1978.

I've always loved their work, but wow, this is disappointing to read.

I hope you and the author realise that sockets are a library. And used to be products! They're not naturally occurring.

Migrating a 1500+ line CloudFormation template to Terraform (with some hope that a little extra flexibility would simplify the solution) only to keep using CloudFormation (through a Terraform-shaped hole) for the most complex parts of the problem... would not have been helpful.

Terraform often doesn't cover complex, less commonly used AWS services or features. For example, practically zero coverage of the entire Media Services suite of products.

I enjoy writing near-pristine CloudFormation. My only tweak is that I write "literate" templates in Markdown using ```yaml blocks, then strip everything else out before executing them.

I (re)use a lot of templates as "products", e.g. I have an RDS PostgreSQL template that I've been maintaining and using for years.

CloudFormation modules are great for encapsulation and reuse if you actually have anything you want to reuse at sub-template granularity. I rarely do. For example, we have a bunch of API services that all work the same way. In that case, the granularity of reuse is the template. I don't have a bunch of different services/products that all need to reuse a given resource in the same way.

For the same reason, I'm not very excited by CDK and other CloudFormation-producing tools.

I started mucking around with Terraform, but immediately discovered I needed to create a provider (custom resource). That's an incredibly manual process to begin with, but almost all of it is translating between Terraform representation (structures based on HCL2) and the JSON representation of whatever API you're using. So much translation when 99.999% of the APIs you'll use will be JSON. Aaaaaarrrrghhhh.

Sorry.

"taxation is a killer"... and yet, some of it is actually spent keeping people alive.

"Human Lambdas"… "Mechanical Turk"… you're fully aware these are horrible names for horrible ideas, right?

Are you suggesting I build and maintain my own global CDN with 200+ edge locations? Thank you, but no thank you.

It's especially useful for doing things during the Origin Request phase, which happens prior to the request from the CDN to the Origin.

In that phase you can change anything about the request itself, or the origin it will connect to. But the function only needs to run when there's a cache miss.

I have an application that needs to select an origin based on the request path (too many to use CloudFront cache behaviours), with a cache miss rate of less than 1%. It's a tiny amount of additional latency for cache misses, and a very small proportion of our CDN costs per month.

I'm not confused. It's possible to do the right thing in the large and in the small at the same time.

Using cross-cultural fluency to defend Richard Stallman, who doesn't care one iota about cross-cultural fluency, and constantly embarrasses people inside and outside his own culture, is weird.

He doesn't do the right thing. He becomes agitated and sometimes aggressive when anyone points out that they're uncomfortable with his behaviour. He is not interested in their perspective or comfort.