Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Free for Developers

free-for.dev

Post reply on HN
Print view View original

101–110 of 206 posts

Re: Free for Developers

#101

Post by Twirrim »

MightyOwl13 wrote: post #70

My 2 cents on this - I have used the Oracle Cloud free tier trying to get the VMs running. The default resource usage seems higher than what you would get on Hetzner/ionos/digital ocean and the resource monitors are a good chunk of that usage. Configuration was also considerably more difficult for someone with little experience such as myself... Achieving the same task (setting up a BookStackApp server) took consider…

I'm sorry that you experienced that. I work on the team responsible for the instance agent. We're aware that there have been performance and resource issues with it, and are always trying to drive down resource usage. If you're okay without any metrics for the instance, you can always completely disable the agent.

Over the last several months we've migrated most things to Go (which was always the ultimate goal), and introduced a plug-in based approach with it. Recently we enabled a feature to allow you to enable or disable plug-ins used by the instance agent dynamically.

Re: Free for Developers

#102

Post by duskwuff »

dvfjsdhgfv wrote: post #83
judge2020 wrote: post #34

Earlier quoted context omitted.

It's not inherit to the card, rather it's pulled via info from the card network (visa/mc/amex/etc). Stripe, for example, returns `card.funding` which is either credit, debit, prepaid, or unknown - blocking anything other than credit or debit isn't bad for SaaS businesses who doesn't want prepaid cards anyways[0]. Outside of that, you can use the IIN/BIN (first 6 digits) to build a blocklist of virtual-card-issuing ba…

> blocking anything other than credit or debit isn't bad for SaaS businesses who doesn't want prepaid cards anyways It's not clear to me what you mean here: do you suggest SaaS businesses should reject those customers who prefer paying with prepaid cards? Hello, this is me! When I see a prepayment option or even Paypal, I gladly pay, but when you want my credit card info, I wave you good bye!

> do you suggest SaaS businesses should reject those customers who prefer paying with prepaid cards

Not the parent, but: yes, absolutely. Prepaid cards are for making one-time payments. They are not suitable for setting up ongoing subscriptions, and it is entirely appropriate for a merchant to reject them in this context.

Re: Free for Developers

#103

Post by duskwuff »

vallas wrote: post #61
aspaceman wrote: post #28

I got a kick out of this list. Especially this sublist: > (note: You must pay if you use .casa, .cf, .click, .email, .fit, .ga, .gdn, .gq, .loan, .london, .men, .ml, .pl, .rest, .ru, .tk, .top, .work TLDs due to spam) Makes me want to search my spam folder for .gq out of curiosity alone.

What is wrong with these TLDs?

They all have very few legitimate users, and are frequently used by email spammers (typically because registrars have offered the domains at a steep discount or entirely free for the first year).

Re: Free for Developers

#104

Post by dvfjsdhgfv »

duskwuff wrote: post #102
dvfjsdhgfv wrote: post #83

Earlier quoted context omitted.

> blocking anything other than credit or debit isn't bad for SaaS businesses who doesn't want prepaid cards anyways It's not clear to me what you mean here: do you suggest SaaS businesses should reject those customers who prefer paying with prepaid cards? Hello, this is me! When I see a prepayment option or even Paypal, I gladly pay, but when you want my credit card info, I wave you good bye!

> do you suggest SaaS businesses should reject those customers who prefer paying with prepaid cards Not the parent, but: yes, absolutely. Prepaid cards are for making one-time payments. They are not suitable for setting up ongoing subscriptions, and it is entirely appropriate for a merchant to reject them in this context.

> Prepaid cards are for making one-time payments. They are not suitable for setting up ongoing subscriptions

Why? Because from the point of the view of the customer, they are the best fit for that purpose.

Re: Free for Developers

#105

Post by duskwuff »

dvfjsdhgfv wrote: post #104
duskwuff wrote: post #102

Earlier quoted context omitted.

> do you suggest SaaS businesses should reject those customers who prefer paying with prepaid cards Not the parent, but: yes, absolutely. Prepaid cards are for making one-time payments. They are not suitable for setting up ongoing subscriptions, and it is entirely appropriate for a merchant to reject them in this context.

> Prepaid cards are for making one-time payments. They are not suitable for setting up ongoing subscriptions Why? Because from the point of the view of the customer, they are the best fit for that purpose.

> Because from the point of the view of the customer

From the point of view of a legitimate customer who intends to pay for a service, a prepaid card is a poor fit for an ongoing subscription, as it will stop working unpredictably when its funds are exhausted (causing it to start rejecting all charges).

Optimizing for customers who intend to ditch a service without paying for it is not a goal.

Re: Free for Developers

#106

Post by [deleted] »

MightyOwl13 wrote: post #70

My 2 cents on this - I have used the Oracle Cloud free tier trying to get the VMs running. The default resource usage seems higher than what you would get on Hetzner/ionos/digital ocean and the resource monitors are a good chunk of that usage. Configuration was also considerably more difficult for someone with little experience such as myself... Achieving the same task (setting up a BookStackApp server) took consider…

[deleted]

Re: Free for Developers

#107

Post by timClicks »

jholman wrote: post #98
neogodless wrote: post #92

Earlier quoted context omitted.

I haven't. That looks super promising! I find AWS/Azure almost intentionally obtuse in their pricing and setup/configuration. This looks like they focus on the opposite!

In the context of AWS Free Tier, the non-obtuse option is you do the EC2 t3.micro with Linux on it, maybe also the RDS t3.micro, and you ignore all that make-things-harder-so-consultants-can-charge-more nonsense. Install your own nginx, install your own node or python or whatever, ignore all their obtuse crap. Heroku is cool, too, though.

There's no "always free" AWS tier though, correct? You're still going to end up paying for the app after 12 months, or am I missing something?

Re: Free for Developers

#108

Post by Twirrim »

valzam wrote: post #80
MightyOwl13 wrote: post #70

My 2 cents on this - I have used the Oracle Cloud free tier trying to get the VMs running. The default resource usage seems higher than what you would get on Hetzner/ionos/digital ocean and the resource monitors are a good chunk of that usage. Configuration was also considerably more difficult for someone with little experience such as myself... Achieving the same task (setting up a BookStackApp server) took consider…

I would argue that Oracle had more to do with that than the fact that it was free... Using the paid version would probably have been even more difficult.

I appreciate there's an uphill battle here to gain HN user trust. It is Oracle after all. OCI is a very different from what you've seen from Oracle in the past. It was created by ex-AWS, Azure, and GCP engineers, based on our collective experiences within those platforms. From some regards you might say we are to Oracle, what Azure was to Microsoft earlier on. A wildly different way of doing things.

Using standard / paid instances should be no more difficult or hard than using free-tier ones, other than the obvious need to have converted to a non-free account and, I believe, sorted out payment methods. They launch and run the same way, just when you have a paid account you can launch on larger instances. We've got enough things we want to do with the cloud, without having to resort to building lots of separate experiences and code paths for free tier accounts.

Disclaimer: opinion is entirely my own, may not reflect the opinions of my employers, etc.

Re: Free for Developers

#109

Post by jldugger »

justin_oaks wrote: post #47
kencausey wrote: post #39

Please point it out if I've missed it, but any list like this, of information that is changeable, should really have a publicly posted date of when the information was last confirmed.

Indeed. They rapidly go stale. Many of these lists are out-of-date by the time anyone finds them. Maybe it's different for services, but lists of software often list projects that aren't maintained. I've never found anything useful from any of these lists. What I do find useful is people on HN talking about what software/services they use.

In my experience this specific one is well maintained, via community contribution.

Re: Free for Developers

#110

Post by Jedd »

tyingq wrote: post #63
Jedd wrote: post #57

Earlier quoted context omitted.

When a measure becomes a target, it ceases to be a good measure.[0] Refer also the law of unintended consequences. [1] Conveniently we have a natural experiment from a year or two ago we can refer to. Stellar Lumens offered some free cryptocurrency to existing users, via Keybase accounts that leveraged external auth-equivalence (such as HN). It backfired spectacularly for all involved. [2] [0] https://en.wikipedia.or…

Did the Stellar Lumens offer extend to brand new accounts? Edit: Ah, I see, people tried to find dormant HN and GitHub accounts. https://www.coindesk.com/stellar-tried-to-give-away-2b-xlm-t...

Yup, I couldn't find the details, but IIRC it was a combination of people generating new accounts in the hope of catching a second round, and the fact some people had signups for Keybase auth on only one or two systems, and also IIRC even if your Keybase account pre-dated the cutoff date, you needed three associated auth systems configured in order to qualify for the coin drop. So there was a huge surge in signups for Github & Hacker News to tick that box. Doubtless some surge was related to people hoping to get in on a (speculative) second drop date.
Post reply on HN