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

It's Europe; salaries suck across the board. That's the market, so there are no competing offers. Then again it's incredibly hard to fire people. Maybe they should start a union after all.

I don’t give employees (and stable freelancers/contractors) the minimum I can get away with; I give them a fair share of the profits on top of their regular salary.

I’m not sure how common this model is in Europe, but it has certainly helped me keep my best employee with me throughout the entire journey and feel much less alone in my decisions—especially at the beginning, when things are harder.

Plus, it's just more fun to share when you can.


What are you even referring to? Salaries in many European countries are perfectly fine when compared to the costs of living etc. Inflated salaries with inflated prices for everything else aren‘t just better because the number is higher ^^

There's more to it than just "inflated salaries with inflated prices".

I took a 70% pay cut moving from Silicon Valley back to Europe. Sure, my monthly expenses were also about 70% less, and I was able to save roughly the same relative proportion of money.

The main difference is that, in absolute terms, what I was saving in the US before I moved amounted to more than what I was taking home after tax in Europe, let alone saving. That buying power went much farther (for a variety of reasons). Whether it was electronics, trips, a new car, etc, I could afford way more luxury there, with much less impact to my bottom line.

I have no regrets. My perceived quality of life is much better now.


They can get away with it because iOS users have a higher propensity to pay than any other platform. So it's often not a good idea to stop caring about iOS, assuming you want to make money, anyway. Even if you don't, iOS users are just different from Android and web, so they're often desirable regardless.

Many problems in article are specific to old versions of iOS which is only in old versions of iPhone. Most old iPhone users are not potential paying customers. iOS need to be supported but old versions of iOS don't.

> They can get away with it because iOS users have a higher propensity to pay than any other platform.

It used to be true, but the last time I saw evidence was in 2015 or thereabouts.

Is it still true in (almost) 2026, though?


Linus and Luke talked about this recently during the WAN show. The gap shrunk a little, but is still huge, on the order of 5–6 times the spend per user, when it used to be 8–9 times.

End-to-end types and a single(-ish) binary simplifies a lot of things. Plus you can always just .clone() and .unwrap() if you want to be lazy/prototype something.

> These do not have to be separate services, but they are separate enough to warrant it.

All of this arises from your failure to question this basic assumption though, doesn't it?


> All of this arises from your failure to question this basic assumption though, doesn't it?

Haha, no. "All of this" is a scenario I consider quite realistic in terms of what needs to happen. The question is, how should you split this up, if at all?

Mind that these concerns will be involved in other ways with other requests, serving customers and internal users. There are enough different concerns at different levels of abstraction that you might need different domain experts to develop and maintain them, maybe using different programming languages, depending on who you can get. There will definitely be multiple teams. It may be beneficial to deploy and scale some functions independently; they have different load and availability requirements.

Of course you can slice things differently. Which assumptions have you questioned recently? I think you've been given some material. No need to be rude.


I don't think I was rude. You're overcomplicating the architecture here for no good reason. It might be common to do so, but that doesn't make it good practice. And ultimately I think it's your job as a professional to question it, which makes not doing so a form of 'failure'. Sorry if that seems harsh; I'm sharing what I believe to be genuine and valuable wisdom.

Happy to discuss why you think this is all necessary. Open to questioning assumptions of my own too, if you have specifics.

As it is, you're just quoting microservices dogma. Your auth service doesn't need a different programming language from your invoicing system. Nor does it need to be scaled independently. Why would it?


Diagnosing "failure" in other people is indeed rude, even if you privately consider it true and an appropriate characterization. It's worse if you do that after jumping to the conclusion that somebody else has not considered something, because they have a different opinion than you. At least that's my conclusion of why you wrote that. (And this paragraph is my return offering of genuine and valuable wisdom.)

Of course you can keep everything together, in just very few large parts, or even a monolith. I've not said otherwise.

My point is that "architecture" is orthogonal to the question of "monolith vs separate services"; the difference there is not architecture, but in cohesion and flexibility.

If you do things right, even inside a monolith you will have things clearly separated into different concerns, with clean interfaces. There are natural service boundaries in your code. (If there aren't, in a system like this, you and the business are in for a world of pain.)

The idea is that you can put network IO between these service boundaries, to trade off cohesion and speed at these boundaries for flexibility between them, which can make the system easier to work with.

Different parts of your system will have different requirements, in terms of criticality, performance and availability; some need more compute, others do more IO, are busy at different times, talk to different special or less special databases. This means they may have different sweet spots for various trade-offs when developing and running them.

For example, you can (can!) use different languages to implement critical components or less critical ones, which gives you a bigger pool to hire competent developers from; competent as developers, but also in the respective business domain. This can help your company off the ground.

(Your IoT and bike people are comfortable in Rust. Payments is doing Python, because they're used to waiting, and also they are the people you found who actually know not to use floats for money and all the other secrets.)

You can scale up one part of your system that needs fast compute without also paying for the part that needs a lot of memory, or some parts of your service can run on cheap spot instaces, while others benefit from a more stable environment.

You can deploy your BI service without taking down everything when the new initialization code starts crash-looping.

(You recover quickly, but in the meantime a lot of your IoT boxes got lonely are now trying to reconnect, which triggers a stampede on your monolith, you need to scale up quickly to keep the important functions running, but the invoicing code fetches a WDSL file from a slow government SOAP service, which is now down, and your cache entry's TTL expired, and you don't even need more invoicing right now... The point is, you have a big system, things happen, and fault lines between components are useful.)

It's a trade-off, in the end.

Do you need 15 services? You already have them. They're not even "micro", just each minding their own part of the business domain. But do they all need their own self-contained server? Probably not, but you might be better off with more than just one single monolith.

But I would not automatically bat an eye to find that somebody separated these whatever-teen services. I don't see that as a grievous error per se, but potentially as the result of valid decisions and trade-offs. The real job is to properly separate these concerns, whether they then live in a monolith or not.

And that's why that request may well touch so many services.


At least in my place of work, my non-technical manager is actually on board with my crusade against complex nonsense. Mostly because he agrees it would increase feature velocity to not have to touch 5 services per minor feature. The other engineers love the horrific mess they've built. It's almost like they're roleplaying working at Google and I'm ruining the fun.

> Most habitual pirates couldn’t pay for what they are pirating

Seems questionable. You can cover almost everything with a handful of monthly subscriptions these days. In fact I often pirate things that I otherwise have access to via e.g. Amazon Prime.

> but who is going to finance the creation of new content if everything is just reliant on completely optional donations?

Well this is an appeal to consequences, right? It's probably true that increased protectable output is a positive of IP law, but that doesn't mean it's an optimal overall state, given the (massive) negatives. It's a local maxima, or so I would argue.

Plus it's a bit of a strange argument. It seems to claim that we must protect Disney from e.g. 'knock offs', and somehow if we didn't, nobody would be motivated to create things. But then who would be making the knock-offs and what would be motivating them?


> You can cover almost everything with a handful of monthly subscriptions these days.

Maybe for you that's something you can afford. I can't. I just consume less music. Or sail the high seas if I really want something.


If we're purely talking about music then almost everything is on YouTube, which has a subscription cost of $0/mo.

> You can cover almost everything with a handful of monthly subscriptions these days.

The majority of people on earth cannot afford more than two or three of these subscriptions.

> But then who would be making the knock-offs and what would be motivating them?

Ten years ago there was a popular blog that got posted on /r/anarcho_capitalism with some frequency. IP was a contentious topic among the then-technologically literate userbase. At some point, a spammer began copying articles from the blog and posting them to /r/anarcho_capitalism himself. This caught the attention of some users and the spammer was eventually banned. A few days later, I followed a link back to his site and found all the articles he had stolen now linked back to a page featuring the cease and desist letter he had received from the original blog, the URL being something like: “f*-statists-and-such-and-such.”

Without any* copyright law, any content that is generated effectively gets arbitraged out to the most efficient hosts and promoters. This might be a win for readers in the short term, but long-term tends towards commodification that simply won’t sustain specialized subject matter in the absence of a patronage model. YouTube and the wave of Short Form Video Content are the two most obvious case studies, though it happens on every social platform that moves faster than infringement notices can be sent.


> The majority of people on earth cannot afford more than two or three of these subscriptions.

I would guess the majority of people on earth don't even have good enough internet to pirate HD video, nor the technical skills to do it, so we're not really talking about global averages here.

> Without any* copyright law, any content that is generated effectively gets arbitraged out to the most efficient hosts and promoters. This might be a win for readers in the short term, but long-term tends towards commodification that simply won’t sustain specialized subject matter in the absence of a patronage model.

I don't think you understand my argument. I don't deny that this may be true. I deny that it is ipso facto the best outcome to have high-quality creator content, or whatever we are talking about here, at the cost of the massive benefits of free use. You might as well tell me New Jersey gas pumping laws lead to nicer service experiences, and getting rid of them would ruin that.

We can arbitrarily prop up any industry to make it cushy and a 'nice experience'. That doesn't make doing so the greatest overall good.

I would argue that even if all that we achieved with the abolition of IP law was the provision of cheap generic drugs, long out of research, it'd be worth far more than the YouTube creator economy.


> I would guess the majority of people on earth don't even have good enough internet to pirate HD video

Why is that the qualification you’re using? There are plenty of people in the developing world who have benefitted from access to e.g. LibGen who would never be able to afford to legally access the materials hosted there.

My point is that under the abolitionist model there is no financial incentive to create anything because the profits get arbitraged away by the most efficient copy services. This wouldn’t be relevant for saturated mediums like music or literature, but it does create a free rider problem in scenarios where the intellectual property has a high cost of production and not many people qualified to produce it (e.g. technical manuals, pharmaceutical research, well-produced films, etc.)

Pirates effectively have their usage subsidized by those who actually pay for the content. A huge amount of human potential is unlocked when works are freely available through legitimate platforms; neither of us are disputing this. The reason I can’t get on board with copyright abolitionism over copyright term reduction is because I don’t see how certain works will be produced at all under an abolitionist model that can only sustain itself via voluntary donations.


The worldwide median internet download bandwidth is about 100 Mbps, which is far enough for HD or bluray video. The technical barrier can be as low as 'click to search, click to download' in some user-friendly BT clients. That being said, the price of these subscriptions is a problem that actually needs to be solved.

Anyone is free to release under free use in our current system. You already can live with the benefits of no IP law by just limiting yourself to those people that chose to to release this way.

> This argument requires us to believe that AI will just asymptote and not get materially better.

That's not what asymptote means. Presumably what you mean is the curve levelling off, which it already is.


This seems overly pedantic. The intended meaning is clear.

Hardly, asymptotic behavior can be anything, in fact that's the whole question: what happens to AI performance as we tend to infinity? Asymptoting to `y = x` is very different to levelling off.

Because modern cookie directives and browser configs neuter a lot of the worst XSS outcomes/easiest exploit paths. I would expect all the big sites to be setting them, though I guess you never know.

I would not be that confident as you can see: on their first example, they show Discord and the XSS code is directly executed on Discord.com under the logged-in account (some people actually use web version of Discord to chat, or sign-in on the website for whatever reason).

If you have a high-value target, it is a great opportunity to use such exploits, even for single shots (it would likely not be detected anyway since it's a drop in the ocean of requests).

Spreading it on the whole internet is not a good strategy, but for 4000 USD, being able to target few users is a great value.

Besides XSS, phishing has its own opportunity.

Example: Coinbase is affected too though on the docs subdomain and there are 2-step, so you cannot do transactions directly but if you just replace the content with a "Sign-in to Coinbase / Follow this documentation procedure / Download update", this can get very very profitable.

Someone would pay 4000 USD to receive 500'000 USD back in stolen bitcoins).

Still, purely with executing things under the user sessions there are interesting things to do.


> some people actually use web version of Discord to chat, or sign-in on the website for whatever reason

Beside this security blunder on Discord’s part, I can see only upsides to using a browser version rather than an Electron desktop app. Especially given how prone Discord are to data mining their users, it seems foolish to let them out of the web sandbox and into your system


Again, here you have not so much sold a vulnerability as you have planned a heist. I agree, preemptively: you can get a lot of money from a well-executed heist!

Do you want to execute actions as logged-in user on high-value website XXX ?

If yes -> very useful


Nobody is disputing that a wide variety of vulnerabilities are "useful", only that there's no market for most of them. I'd still urgently fix an XSS.

There is a market outside Zerodium, it's Telegram. Finding a buyer takes time and trust, but it has definitively higher value than 4k USD because of its real-world impact, no matter if it is technically lower on the CVSS scores.

Really? Tell me a story about someone selling an XSS vulnerability on Telegram.

("The CVSS chart"?)

Moments later

Why do people keep bringing up "Zerodium" as if it's a thing?


I understand your perspective about the technical value of an exploit, but I disagree with the concept that technical value = market value.

There are unorganized buyers who may be interested if they see potential to weaponize it.

In reality, if you want to maximize revenue, yes, you need to organize your own heist (if that's what you meant)


Do you know this or do you just think it should be true?

> understand your perspective about the technical value of an exploit

Going out on the world’s sturdiest limb and saying u/tptacek knows the technical and trading sides of exploits. (Read his bio.)


AIU this feature is SSS, not XSS, so XSS protections don't apply.

How would you make money from this? Most likely via phishing. Not exactly a zero-click RCE.

What happens in all these discussions is that we stealthily transition from "selling a vulnerability" to "planning a heist", and you can tell yourself any kind of story about planning a heist.


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

Search: