sauercrowd

That's an amazing thread, thanks for sharing

The A220 is an absolute treat. Can't put exactly my finger on why, but it just feels right in size, noise, the little screens at the top.

Flown it once or twice with AirBaltic, and would love to take it again.

I agree, it's a cool idea but I actually think the lack of mantainability of shell languages are a coincidental feature not a bug, making sure that once you hit a certain complexity you're forced to switch to a full programming language.

> In other words, our disagreement comes down to a difference in values. I don't think that's the whole story.

Us humans are not very good at recognizing it, but we all model and understand the world slightly differently.

So that even if you fundamentally agree with someone's values, you might prefer other code to that person because it fits better in the way a problem is modelled in your brain than in someone else's.

it's a rejection of the thesis that it "does not work". It does, but it requires investing into a suppression file.

I can think of two reasons - it's a browser engine, not a browser - it was created and maintained for the longest time by mozilla, before the linux foundation took over a couple years ago. That creates history and governance that I could image puts of contributors or the broader excitement

That only matters if you're parsing the same yaml file with different parsers, which GitHub doesn't (and I doubt most people do - it's mostly used for config files)

but should it then even be listed there?

question how does your product help in these situations? I imagine it'd require for someone to report a compromised package, and then you guys could detect it in my codebase?

That's definitely not what I've seen from people around me with an iphone.

Almost all of them complain about the device getting hot, batteries being short lived (even when replaced) and apps being sluggish.

there's a lot of affordable examples such as hetzner - what's missing?

That was exactly my experience using it. Great at first, and then hitting real-world and being stuck with the lack of sharing styles (in my case).

Shadow DOM was an absolute pain in reality.

causes a bunch of things to no longer work though - slots, style encapsulation, ...

It's "the rest". More complex projects, existing context (like infrastructure, code, business context, ...).

Building a small script is easy for chatgpt, but actually leveraging the workforce consistently turns out to be a lot harder than the hype promised.

Hardware support in the last years has really improved significantly. I was using arch a lot back around 2016, and it was a nightmare. On every kernel update had to recompile a kernel driver cause my laptops chipset was something bizarre, nvidia drivers were mostly half working and it all just felt like a fragile card house.

Ubuntu was by far the best option to actually use my system rather being constantly distracted by another little piece that fell out the wall

Interesting. So you guys share a realtime location but its anonymized to attractions? That's cool

"intern" and "entry level" are proxies for complexity with these comparisons, not actual seniority. We'll keep hiring interns and entry level positions, they'll just do other things.

Why's that? What does it do?

Prot - the author - is a pretty incredible guy. He maintains a bunch of nice Emacs packages and themes.

But maybe even more remarkable: he got kicked out of his flat in Greece, couldn't afford a new place, bought a small plot of land in the mountains and started building a hut from materials he was able to afford or from things neighbours gave him. Really the bare minimum (he often sat in his hut with a jacket in winter cause it wasn't well isolated/heated)

Absolutely inspiration, all documented on his YouTube channel https://youtube.com/@protesilaos?si=MnjV7MhKtsT5RDSM

Which part?

In my experience performance issues in React also creep in without it being obvious when developing, especially across a larger team. It tends to be more obvious with server-side frameworks like django or rails.

I'd argue it is possible. If a person pirates an album of an artist, that person now owns the album as if they would have paid money for it (from back in the itunes times). Same for an ebook, a game, a movie, ...

You are describing mostly services, where the intellectual property of the product is of no interest to the buyer (e.g. the average Spotify user has no desire to access their codebase or recommendation engine).

Buying a game after pirating has no impact on the product you have today, you already own the intellectual property as is.

I'm not really sure I understand what's being proposed instead.

I agree with the premise that that comparison between Tiffany's and piracy doesn't hold, but

> It’s a lot more like taking a picture, which Tiffany’s probably encourages. Win-win cooperation.

That doesn't make sense. Pirating something means you gained the whole value of the product. In Tiffany's case that's not remotely the case. In fact, they will pay large sums of money to marketing companies to make sure you get a photo.

If the entire value of a product can be taken, there's no incentive for it to be created in the first place other than intellectual curiosity - as another commentator said: effectively academia.

Our society has never found a way to deal with digital products in a way that doesn't skew incentives

This is my current setup, and I love it. To me it brings together the best of vim with the richness of Emacs.

Setting up Emacs from scratch is quite the project though if you want all the bells and whistles

Adding red tape to processes is a decision, not a consequence of digitalization.

We don't live in the same world as the 1990s, we live in a world that's faster than ever before.

We can't achieve what's possible by sending in handwritten forms, it's just not gonna do it. and while governments are anything but efficient they are more efficient with digital workflows.

This won't work

if a response is meant to swap out a div, the first response completing will swap it out - if this response isnt compatible with the same selector (e.g. a #response is not available) a second completing response won't be able to update the UI

Very much agree with you on this - htmx (turbo, hotwire, alpine,...) are not trying to replace all your client side logic.

It's a spectrum of interactivity, and we should try to pick the best (whatever that may mean) tool possible for the job - sometimes that's hx-boosted links, sometimes it's a react app

> The default queuing mode is bonkers

> By default, Htmx will cancel requests that are in-flight if you trigger another request on the same queue (element).

This seems like the only default that's reasonable to me

don't know if the author has a specific example in mind, but if a user submits an input, changes that input mid-request and submits again the request needs to be cancelled, otherwise the UI will be inconsistent by showing a response to an outdated input

Just processing one response after the other won't be possible if a response swaps out content with different IDs, so a second response won't be able to be swapped out in the same way

strongly disagree here. This works if - your IDE/language server is performant - all the tools are fully set up - you know how to query the specific semantic entity you're looking for (remembering shortcuts) - you are only interested in a single specific semantic entity - mixing entities is rarely supported

I dont map out projects in terms of semantics, I map out projects in files and code - That makes querying intuitive and I can easily compose queries that match the specificity of what I care about (e.g. I might want to find a `Server` but I want to show both classes, interfaces and abstract classes).

For the specific toolchain I'm using - typescript - the symbol search is also unusable once it hits a certain project size, it's just way too slow for it to be part of my core workflow

Open source as a byproduct of a company absolutely works - it's been proven by tons of tech companies.

But if you open source your revenue-generating parts, and only charge for support/managed version/enterprisey features you'll end up with quite weird incentives, particularly with infrastructure tools, in which the big cloud providers will happily compete with you, using the version you open sourced and providing and ecosystem to their customers that one simply cannot compete with