Hacker Newsnew | past | comments | ask | show | jobs | submit | yobbo's commentslogin

He's not hired to code. He has taste for "what works" in these types of things. They want him to apply that taste - maybe making new services or fixing old.

See: Rick Rubin.

"Rick Rubin says he barely plays any instruments and has no technical ability. He just knows what he likes and dislikes and is decisive about it."

https://www.cbsnews.com/news/rick-rubin-anderson-cooper-60-m...

https://en.wikipedia.org/wiki/Rick_Rubin_production_discogra...


> it costs almost nothing to build an app, it costs almost nothing to clone an app.

For the types of apps that AI can clone on its own, this has always been true. It's the eternal bookstore example, recipe collection, or my-dvd-collection app. The type of apps that Basic and Visual Basic were designed for.

If there was value in selling subscriptions to an app like this, it was probably coincidental.


Watermark files per unique user and go after whoever leaks them.

Diff two copies and remove the diff.

I doubt they'd just add a UUID in a file header somewhere. If they uniquely modify the actual audio samples in a way that is inaudible during casual listening, that would be much harder to "diff", I think.

If it is inaudible then I can just remove the diff from both or overlap them or...

Can you guys catch up on the absolute basics of the last twenty years of audio watermarking research before continuing this conversation please dear god

That seems shaky in a lot of jurisdiction.

Watermarking might not be enough to prove that the person doing the distribution is the same one responsible of the leak. I fear at most it will be a contractual dispute between the person who received the watermarked file and the original distributor without the ability to easily link the overall counterfeiting charges.

But anyway, I don't think they really need to do that. They just need to shutdown any unauthorized distributors that make things too easy. As long as the friction introduced can convince people to pay a low subscription fee, they will be fine.


I think a latent embedding is almost equivalent to the article's hypernetwork, which I assume as y = (Wh + c)v + b, where h is a dataset-specific trainable vector. (The article uses multiple layers ...)

Hard-to-fire typically means only specific and provable reasons are valid.

"Shrinking the org" is a valid reason.


On page 41 you can find average, median, and top10 salaries for Germany by experience levels. Junior/regular/senior medians are 52.5k/60k/67.5k.

Average is 62.4k.


> because EU throws regulatory obstacles at every step.

No, the gatekeeping is done by local banks and governments to protect their oligopolies/cartels.

There are many instant-pay apps across Europe and they are intentionally not interoperable outside of local markets. Each local banking oligopoly is trying to fence off competition. The main fear is from smaller neo-banks.


>>No, the gatekeeping is done by local banks and governments to protect their oligopolies/cartels.

If you are pointing the distinction between gatekeeping at the EU level and country level I am not contesting that. It's clear though that the gatekeeping is the problem here (and in many other industries in EU).


How dare you point that out on a discussion about gatekeeping being treated like a good thing.


Agile solves the problem of discovering a workable set of requirements while the environment is changing.

If you already know the requirements, it doesn't need to come into play.


While the environment is changing. That's the key.

If you already know the requirements, and they aren't going to change for the duration of the project, then you don't need agile.

And if you have the time. I recently was on a project with a compressed timeline. The general requirements were known, but not in perfect detail. We began implementation anyway, because the schedule did not permit a fully phased waterfall. We had to adjust somewhat to things not being as we expected, but only a little - say, 10%. We got our last change of requirements 3 or 4 weeks before the completion of implementation. The key to making this work was regular, detailed, technical conversations between the customer's engineers, the requirements writers, and our implementers.


They mean google docs/gmail or office365.


Email-marketing tools present these numbers as if they were ground truth.

Arguing with non-tech users means you are challenging the legitimacy of their tool, and they typically can't let go of faith in the tool. It's like Trueman trying to convince the actors that everything is somehow fake. There's no "script" for that.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: