Recent submissions

Comment · 2 years ago
This sounds a bit like the fallacy of the beard; the existence of ambiguous behaviours that exist somewhere on the spectrum between "listening to an entire podcast with ads" and "automatically downloading the podcast, editing out the ads, and reuploading to a personal RSS feed so you can listen to it ad-free" shouldn't prevent us from contrasting the behaviours at the extreme ends of the spectrum.

That said, "unethical" was clearly a poor choice of words, as that's quite a loaded term. However, this technology is designed to systematically circumvent the mechanism by which many podcast creators earn money for their effort, and even if "unethical" is the wrong word, we should still discuss whether putting these technologies out, and using them, is a good move - particularly if we care about rewarding creators and supporting the podcasting industry. (And there's an argument that goes even further, around whether doing something like this is systematically violating an implicit contract with creators, even if it's more of a moral contract than a legal one).

Comment · 2 years ago
This is interesting as a technical PoC but also feels a bit unethical.

The moral case for ad blocking on the web seems pretty clear: online advertising is built on massive exploitation of user privacy, has horrible UX, and is often implemented so poorly that it tanks pageload performance. In short, I understand why people use ad blockers on the web.

Podcasts though? In RSS-based podcasting, which is what this tool targets, you're typically getting a reasonable quality audio ad, with limited tracking, targeted broadly at the category of people who might listen to a particular podcast; it's about as unobtrusive as advertising gets. Widespread circumvention of those ads could really hurt the ecosystem, which would be particularity frustrating given that podcasting appears to still be a viable space for small scale creators to do great things (e.g. San Charrington and the TWIML AI podcast)

TLDR cool demo but everyone should please think carefully about if or when to use this tool.

Comment · 3 years ago
Really miss Divvy (RIP). At the risk of causing a good thread on Apple's weird inability to lauch a really valuable OS feature devolve into a list of workarounds, Hammerspoon (a generic automation tool) plus this script (https://gist.github.com/artburkart/15b62f1a741eef0f74492860a...) offer a really good equivalent, with the added ability to change hotkeys, extend behaviour, modify behaviour, etc. since it's just a script. I was devastated for a brief while when Divvy (and then ShiftIt) stopped working, but haven't looked back for a while.
Comment · 3 years ago
I think the main difference is that a 1 month sabbatical is typically over-and-above your normal holiday allocation. This can make a huge difference for some people, particularly people with families.

With a normal "x weeks" of holiday those weeks quickly get committed. Vacations with your partner, childcare during school holidays, etc. Having an extra month above that can free up time for learning, pursuing hobbies, travel, etc. that is much more selfishly focused on your own interests, which can be massively invigorating - essentially exactly what a sabbatical is supposed to do, even if I agree that it would be nice to be even longer.

Comment · 3 years ago
According to these numbers the combined cost of replacing the battery and the screen is 22.99 + 44.99 == 67.98, which is less than half (~45.3%) of the cost of the original new phone. Comparing that to the market value of a used phone is a bit unfair, since screens and batteries drive the depreciation of used phones more than any other components (ignoring EoL timelines for OS security updates, etc), and in this example you're getting new ones. Plus not everyone needs a new screen and battery every year.

This definitely isn't going to be for everyone but, for what they're trying to do, IMO the numbers seem reasonable.

Comment · 4 years ago
I think this assertion from them is misleading (in the same way that it is when Facebook et al make it). If Apple is allowing micro targeting then they are implicitly sharing data. E.g. let's say they let me buy targeted ads for "dog lovers aged 34-39", and then you show up on my website as a lead via that campaign, then Apple has just implicitly sold me demographic/interest information about you, even if it wasn't done as explicitly as if they sent it over in a spreadsheet. I fundamentally think that microtargeting and privacy are incompatible.

(I'm open to bring shown, however, that Apple's new ad marketplace explicitly eschews microtargeting, but I haven't seen that so far)

Comment · 4 years ago
Unless I'm massively misunderstanding your setup, that Docker image contains an entire OS and runtime, not just your website. Reasonable people can disagree about whether that entire paradigm is sensible but, having chosen to use Docker, complaining about image size in this way seems an odd choice. More to this point, most of what is in the image will be little to do with Node or its build systems..
Comment · 4 years ago
This kind of point comes up a lot in these discussions. I'd suggest a slight alternative:

"Death per million person kilometers, broken down by car age and road type."

The expectation of death in modern cars during highway driving should be very low. Given that tools like Autopilot are only installed on new cars and only enabled in highway driving risks spurious comparisons if all miles of driving are treated equally...

Comment · 4 years ago
Bit late to the party but I just wanted to put one top level comment saying: this is awesome! I'd never have thought that putting a Fortran codebase like this into WASM was so possible. And doing so in this way surfaces great, battle-tested information, that would be herculean to reimplement and test in another language. Really awesome stuff!
Comment · 4 years ago
I always find this to be a funny point in these conversations. The entire discipline of "agile development" exists because it's so hard to have foresight into the requirements of a software product up-front. By extension, I don't see how we think it's possible to define expectations for employees up-front and then pay them only based on results. If you look at agencies within our industry, for instance, about 0% of them will work on fixed-price contracts - it's always time-and-materials. Knowing what we know about software development, I don't see how individual employment can fundamentally be any different...
Comment · 4 years ago
Strangely I think that might actually be less of a concern with BAYC? From the article:

> A growing number of NFT projects are granting owners the right to commercially adapt their works, which has been a useful strategy for increasing brand visibility but has consequently introduced a host of legal disputes. Bored Ape Yacht Club was among the first to adopt these terms, which led to an explosion of Bored Ape merchandise and derivative NFT collections but also set the stage for bitter copyright lawsuits.

IANAL though, and also "bitter copyright lawsuits" doesn't sound exactly like where you'd want something like this to end up :)

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton