HN user

interblag

243 karma
Posts5
Comments50
View on HN

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).

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.

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.

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.

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.

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)

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..

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...

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!

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...

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 :)

This is probably a cliched comment by now, but it never ceases to amaze me how quickly many crypto users appeal to centralized authorities as soon as they accidentally lose ownership of an asset. From one of Seth Green's linked tweets:

Got phished and had 4NFT stolen. @BoredApeYC @opensea @doodles @yugalabs please don’t buy or trade these while I work to resolve

Just a continuous, incredible endorsement of the fact that in certain situations intermediaries, however imperfect, are actually very desirable...

I think they address some of the reasoning behind this pretty clearly in the write-up as well?

The potential risks of misuse raise concerns regarding responsible open-sourcing of code and demos. At this time we have decided not to release code or a public demo. In future work we will explore a framework for responsible externalization that balances the value of external auditing with the risks of unrestricted open-access.

I can see the argument here. It would be super fun to test this model's ability to generate arbitrary images, but "arbitrary" also contains space for a lot of distasteful stuff. Add in this point:

While a subset of our training data was filtered to removed noise and undesirable content, such as pornographic imagery and toxic language, we also utilized LAION-400M dataset which is known to contain a wide range of inappropriate content including pornographic imagery, racist slurs, and harmful social stereotypes. Imagen relies on text encoders trained on uncurated web-scale data, and thus inherits the social biases and limitations of large language models. As such, there is a risk that Imagen has encoded harmful stereotypes and representations, which guides our decision to not release Imagen for public use without further safeguards in place.

That said, I hope they're serious about the "framework for responsible externalization" part, both because it would be really fun to play with this model and because it would be interesting to test it outside of their hand-picked examples.

Out of curiousity, have you looked at the paper or read the Forbes article linked in one of the other top-level comments? (https://www.forbes.com/sites/kionasmith/2018/08/30/katherine...)

The paper itself has only two listed authors - that's also visible in the linked YouTube video and in the paper itself here: https://ntrs.nasa.gov/citations/19980227091

Further, the Forbes article has a quote from the paper's other author:

[the other author] told [their boss], 'Katherine should finish the report, she's done most of the work anyway.'

With that in mind, I don't think it's a stretch to refer to this as her calculations, even though I'm sure Ted Skopinski (the other author) made significant contributions as well.

I see where you're going with this, but a reasonable counterpoint would be that this is a CS teaching role. Most people with the skills to teach university level CS, who also live in the Bay Area, can probably earn much more than $107k/year, which is the choice she's clearly making as well. I'd also note that, from my read, she's not saying it's immoral or anything, she's just saying "I could personally earn more, so I'm leaving"...

There might be some value in opening these algorithms up but, also, the moment you reveal how they work you will immediately start to see them gamified. Aspects of content recommendation/moderation will always be adversarial, and there are many good arguments in favour of some opacity in these types of systems.

Just to note, there are many reasons to not want to "require identification to use the site" that aren't related to "[wanting] bots on there". Cost, friction, safety/protection, etc. - the list gets quite long with a trivial brainstorm.

Also note: that's not the same thing as saying "Twitter shouldn't require identification to register" (though personally I don't think that it should). It's just to say that it's WAY more complicated than "bots vs. ID".

For anyone wondering what this was ... looking at the last Archive.org link here:

https://web.archive.org/web/20220401002723/https://www.devan...

...it looks like this might have had playable versions of daily Wordle puzzles going back to the start of the game? (Which would be pretty trivial since IIRC Wordle is entirely client-side and they just update the JS each day with the new word?) If so then his statement - "to be honest, I was wondering what took them so long" - would sort of make sense.

EDIT - Github repo before NYT-inspired deletion: https://github.com/DevangThakkar/wordle_archive/tree/23cfba6...

I think that, at the margin, very few people make a decision about whether to have kids based on global food supply projections. And, at any moment, a lot of population growth is just "baked in" by the birth rates of previous generations. Taking those two things together, I think there is a good argument for the "prevented starvation" interpretation.

Aside from a lot of the other good advice on this thread I just wanted to remind the OP and anyone else feeling similarly right now to not forget about the covid situation. The last two years have not been normal. Social rhythms, relationships, work ... a lot of things have been disrupted. A degree of malaise is an incredibly common response.

Nothing in my post indicates what to do if this is your situation. But I think am accurate problem statement is a starting place to most good solutions in life, and the pandemic has become so much a part of like that it's easy to forget just how disruptive it has been to the normal trajectory of many of our lives.

I suspect what’s happening from here is that API Gateway is in front of a Lambda function (indeed, this is a common design pattern that AWS documents) that does minimal-to-no processing of the JSON blob and puts it in a database, likely DynamoDB given the overall managed services flavor of this implementation. At that point, backend processes can take over...

A bit of an aside, but since this is an article about architecture, wouldn't the more common pattern here be APIGateway->Lambda->MessageQueue->BackendServices rather than APIGateway->Lambda->Database->BackendServices? Or does DynamoDB have something like a queue that backend processes can subscribe to? (Non-AWS user here).

I wonder whether you can also incorporate puzzle usage in this.

Unfortunately the article itself states that data on puzzles, lessons, etc are not available from the Lichess API, so all that they can really look at are games played... (Though agree this would be cool!)

Congrats on the IPO - Amplitude is a great product and the team behind it seems genuinely awesome.

I had a question about your view on the enterprise software sales process? Currently I am avoiding upgrading from the free tier of Amplitude due to fatigue with negotiations - the whole "contact us for higher volumes model" is a bit exhausting.

As someone who does this pricing model, I wanted to ask if you think it's optimal? Have you ever considered making your volume discounts transparent and allowing users to quickly understand how Amplitude pricing will work at scale? Are you just going along with the crowd on opaque pricing or do you genuinely think it's a better model?

Appreciate your thoughts!

Yeah, lol - I guess I mean that they were "considerably more true than I expected them to be, based on my previous prejudices about .NET"

Before I was forced to try it, if you had asked me whether having a "normal" development experience using .NET was possible I would have said "no way". After being forced to do it I was pleasantly surprised to see that it didn't feel particularly different to most other compiled languages that I've used. YMMV.

I can share some insight here. I got into .NET (Core) by virtue of joining a company that used it, after previously focusing mostly on Python and JavaScript (with a self-taught background in C going back to childhood prior to that).

Initially I had the same tribalism that a lot of people seem to have towards .NET, for whatever reason. Eventually though, my conclusions:

- .NET Core is pretty reasonable. Platform agnostic, easy to work with, decent command-line tooling, and doesn't force you into an IDE vertical unless you want to. - C# can be a nice language for certain types of business applications. I think it has a lot of the good modeling properties that once made Java the de-facto language for enterprise development, without some of the verbosity and other drawbacks (though maybe Java has changed too since I last looked at it :) ). It plays very nicely with Domain Driven Design and event sourcing, both of which are patterns that I find valudable on large-scale systems for managing business transactions.

Overall TLDR: I probably wouldn't use .NET if I started a company tomorrow, but when I start coding non-trivially sized things in Python I sometimes miss elements of what .NET/C# brings (particularly interfaces, which obviously also exist in other languages).

The term "callback" is usually used to refer to a function that you want called after the completion of an async operation (like a database read, a file read, a network call, etc).

This article uses the term callback but then uses functions passed to "map" as its examples; "map" is synchronous and so this usage of the term "callback" is atypical, probably atypical to the point that we can just say it's incorrect :).