Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)LE
Posts
15
Comments
2,750
Joined
2 yr. ago

  • It's just one person managing eu.org and at some point they seem to have been overwhelmed by all the requests and have either stopped approving them or taking very long to get to them.

    If you need a cheap domain there are other TLD you can get that function normally. .eu.org is not a regular TLD, it's just subdomains offered by the owner of that domain.

  • You can also delete the payment token that was issued to that website.

    My bank lists the currently valid recurrent tokens explicitly next to each card, and lets me revoke them individually (but I can also re-add a card to the merchant if I want to).

    In the Revolut app it's a bit wierder, you have to go to a card, tap on a past payment, and then you get a "block future payments" button that prevents that merchant from ever using that card, but there's also a "subscription payment" toggle that only revokes the recurrent token for that particular payment.

    The "block future payments" feature is severely limited on the free Revolut accounts, you can only do 3 blocks per month and can only have 5 total overall active. So you probably want to turn off the subscription toggle instead.

  • My bank will assign cards to specific accounts and only draw payments with that card from that account. And they let you make multiple cards and multiple accounts, naturally.

    So for me the easy solution is to simply not keep money in that account (because it's a debit account and will simply refuse payments when there's no money).

    The other simple solution is the fact that the bank also lists the tokens currently associated with each card, and lets you remove them. Once the token is gone the website has to ask for explicit permission again.

    For those not familiar, nowadays websites can no longer store actual CC details (it's a huge compliance violation) and in fact they never even get to see the CC details anymore. You enter the CC details on the processor's page (which is a separate entity), they send them to your bank, the bank verifies them, asks for a 2FA confirmation from you, and if everything checks out they issue a token to the website.

    The token can be good for a one time payment, or for recurring payments. If it's a recurring token my bank will list it next to the card involved and let me revoke it. The website can use the token for as long as it's still listed – if I delete it they have to ask for a new one.

    I suspect that this is the main shortcoming of Revolut's one-time cards, they issue one-time tokens (naturally) and it's easy for the website to see that it's not a recurring one.

    Edit: I should also mention that in the EU this token mechanism is NOT used for utilities. For utilities (and for other EU recurring payments) there's a similar but explicitly separate mechanism called SEPA. It's similar in the sense you can set up the payments and you see them listed next to your account, you can revoke them at any time, they also use a tokenization system, but they draw directly from an account, there's no CC involved and no CC processors, it's a system that works directly between EU banks.

    • You’ll see "DroidCam" in the list of webcams.
    • It works with Skype+Chrome without the need for exclusive_caps=1.
    • The install scripts will configure v4l2loopback-dc to auto-load after reboot.

    But you're right, it also works with the standard v4l2loopback module that comes with most distros.

  • Most online places are now aware of Revolut's disposable CC numbers and reject them. They haven't worked for at least a year now. They're basically useless.

    Edit: I should clarify: all CC payments nowadays use tokenization. The website doesn't get the CC details, they get a token issued by your bank. The token can be one-time use, or recurrent. Naturally, for one-time cards Revolut issues one-time tokens. The problem is that many websites have caught up to it and require indefinitely-valid, recurrent tokens for any payment. I don't think this is something that Revolut can solve on their side.

  • I like the way Bunny.net does paid DNS, 20M monthly queries for $1 and $0.1/M after that. With an API included, ofc. Now that's the kind of pricing I can get into as a self-hoster, not $20/mo.

    GoDaddy advertises a lot, basically. So whenever a person who's never owned a domain before searches for "get a new domain" they're gonna get GoDaddy, NameCheap and (ironically) Google Domains as the top results. That's pretty much all there is to it.

  • But you don't have to develop anything. There are plenty of ready-made excellent tools you can just drop-in. The main fallacy is that what Github does is actually useful, or that the pieces it integrates are useful. 90% of Github is subpar for any given purpose. Consider all the possible types of software being developed and all the different release flows and support/issue flows, how could they possibly be shoehorned into a one-size-fits-all? Yet people try their damnest to do exactly that.

    To do software development you need (A) issue tracking, (B) a clear release flow, and (C) a deploy mechanism that's easy to use. A is a drop-in tool with lots of alternatives, B is unrestricted since Git is very flexible in this regard, and C is typically included with any cloud infrastructure, unless you're doing on premise in which case there are also drop-in tools.

    A, B, C are three distinct, orthogonal topics that can and should be handled separately. There's no logical reason to shape any of them after the other. They have to work together, sure, but the design considerations of one must not affect the others.

  • It depends a lot on the setup you have, how many people, release flow etc. Issue tracking depends on the kind of software you do and whether you want a programmer-only flow or a full support flow.

    Deploy pipelines will usually depend on the infrastructure, cloud solutions usually can integrate with several and there's also common solutions and even FOSS ones, like Terraform vs OpenTofu.

    Git frontends are a very mixed bag, generally speaking their main purpose is to hide Git as much as possible and allow programmers to contribute changes upstream without knowing much beyond the nebulous "PR" concept. Basically they're mostly useless other than enabling people to remain dumb. A good Git tutorial and a good history visualization tool (git happens to include one called gitk out of the box) will do so much more to teach people Git, and there's really no substitute for communication – using annotations to discuss pros and cons for a PR is badly inadequate.

  • Again, like OP said, those are typically distinct functionality: issue tracking, source control, deployment etc. GitHub bringing everything into one platform is atypical and obviously done for the goal of centralization. The more stuff you add to a platform the harder it makes it to leave or replicate.

    But no, technically speaking you don't need to have all of it in one place. There's no reason for which you must manage everything together.

    I don't even understand why people like GitHub so much, its source management sucks. The fact it still doesn't have a decent history visualization to this day is mind-boggling.

    Look for ways to do things separately and you will find much better tools. GitHub's "one size fits all" approach is terrible and only holds because people are too lazy to look for any alternative.