kevincox

joined 3 years ago
MODERATOR OF
[–] kevincox@lemmy.ml 141 points 1 month ago (8 children)

Allowing showing different domains than the actual click target is wildly reckless and should be punishable.

"Oh but our poor advertisers want to use click tracking and it is too hard to set up on their main domain". Oh boo hoo, I'm sure if it is important to them they will figure it out.

[–] kevincox@lemmy.ml 4 points 1 month ago (1 children)
[–] kevincox@lemmy.ml 1 points 1 month ago

If they control the app they can read what they want anyways. If they are the end then E2EE doesn't matter.

[–] kevincox@lemmy.ml 15 points 1 month ago

Since doing so allowed them to see other data. Then they can use it for making offers that are as low as possible.

Basically it raises their bargaining power. They know how much you make now and will use that to scale their offer.

Capitalists will minimize costs. It is their job.

[–] kevincox@lemmy.ml 9 points 1 month ago

everyone knows that writing assembly is a fool's errand

I think this is misrepresenting the advice. I would argue the following:

  1. Writing your whole program in assembly typically won't result in faster code than C or Rust. This is because well-written, readable, maintainable assembly will usually be slower than what a compiler produces. Even if you try to be fairly clever the compiler will almost always do a better job unless you are taking the time to carefully profile every line that you write.
  2. The compiler will evolve over time, your hand-written assembly will not. So even if your assembly is faster initially you will need to revisit it as hardware evolves.
  3. Obviously you will need different assembly for every instruction set.

I don't think anyone ever said "don't try to optimize small sections of code you won't beat the compiler". Of course you can beat the compiler. But it will require significant upfront and maintenance cost to beat the compiler over time. That cost isn't worth it for 99.9% of code. But when applied judiciously it can be used for improvements where it matters.

The conclusion should be start by writing everything in a high level language. Then optimize your algorithms and eliminate performance bugs. Then once you have eliminated the low-hanging fruit consider spending the time to profile and optimize your hottest code in assembly.

[–] kevincox@lemmy.ml 4 points 1 month ago (4 children)

I regularly consider doing this. Obviously it is great from a privacy perspective. But I hate dealing with cash, especially change. With cards I just have one thing in my wallet and it just works forever. My bank account is automatically charged at the end of the month. With cash I need to keep refilling my wallet and carry around annoying change.

I would love to have something digital but also private (like Monero). But so far I have been picking convenience over privacy.

[–] kevincox@lemmy.ml 8 points 1 month ago* (last edited 1 month ago) (3 children)

This is sort of a scam though. Credit cards give rewards, but then charge the business for the processing fees. So the business needs to raise prices to cover the fees. So really no one is getting that 2% except for the card network. And if you don't use a card you lose 2%.

It is basically a protection racket. "It would be a shame if you didn't use our credit card and had to pay 2% more everywhere"

Yes, I know it is complicated. Handling cash also costs non-trivial amounts. I know that the EU has limits on fees (and that is why basically no credit cards have rewards there). I also know that some businesses see the fee as more of a marketing costs because higher spenders tend to use cards and people tend to spend more on cards.

[–] kevincox@lemmy.ml 2 points 1 month ago

Yeah, I'll believe in Tesla shipping self-driving cars when I see it.

[–] kevincox@lemmy.ml 2 points 1 month ago (1 children)

Yeah, the nice thing about per-app is that you can configure it for each app separately. But I'll be honest that isn't something that I regularly do. If I am voice chatting with friends that will usually be a superset of what I want to send to a game's voice chat.

[–] kevincox@lemmy.ml 4 points 1 month ago

I found https://github.com/cyrinux/push2talk implements this idea for proper PTT on all apps.

[–] kevincox@lemmy.ml 6 points 1 month ago (9 children)

Instead of system wide PTT per-app you may consider some software that mutes your mic for all apps as PTT, then just leave the mic "active" per-app.

I don't know if a tool that will do this but on my mouse I have configured a mic mute toggle. So I push to start and stop. However technically I don't think there is any restriction to setting up PTT via this mechanism.

[–] kevincox@lemmy.ml 23 points 1 month ago (1 children)

This is my dream. However I think my target market is smaller and less willing to pay (personal rather than business). However maintenance is low effort and I want the product for myself. So even if it doesn't make much or anything I think I will be happy to run it forever.

The ultimate dream would be to make enough to be able to employ someone else part time, so that there could be business continuity if I wasn't able to run it anymore.

view more: ‹ prev next ›