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

Right now, any other payment company could hold your money, kill your cat, fill your car with stinky waste, spoof rude emails to your friends and family, and finally blow raspberries at you, and it would still be heads and shoulders above the stinkfest of paypal.


I am paying my payment processor 10% - 15% of each transaction in processing and cross border fee, because, I am told:

1. They are small, and don't get good exchange rates 2. My location makes for a long money route, so I pay between 4% - 8% in cross border fee on every transaction

The above fee doesn't even include the final transaction and conversion fee when I withdraw the USD balance to my home currency.

From where I stand, I would be saving 3% - 5%, or more with PayPal, on every transaction. I am willing to take the risk.


Transferwise when I just looked only charge 1% off interbank for USD to INR. Maybe use Stripe (2.9% + 30¢) for USD and then that?


Stripe isn't available in my country.


At least they stick with one tech longer than five minutes. The ADD-riddled folk that sometimes post on here, changing their tech stack based on the newness in milliseconds of the latest craptastic JS framework is astounding.


The kids have no cost of switching to something new because they probably don't know much already. As you get older, re-learning everything 6 months feels weird since any random 14 year old can know as much (or more) than you do about the new system. Your API-level experience gets invalidated rapidly, so it's almost better to start from scratch, which only the unknowing youths can do.

Then there's a whole "stake you claim" mentality. Want to be the best C person in the world? You can't. It's too wide spread. What to be the best Go person? Sure, fight that battle for your own glory since it's new and you can take part in everything.

Lack of education/experience also creates a great breeding ground for new, duplicate, half-implemented versions of things that already exist. The older a developer gets, the more they see things they already know re-implemented as completely new but with unfamiliar interfaces they'll have to re-learn again every 6 months. It's a huge waste of human capacity to always be "new new new" instead of creating a stable and reasonably extensible base to work from. But, at the same time, we don't want to be stuck on Perl 4 and CORBA forever.

There's a tradeoff between building new things for advancing the future versus building new things just because you think you're better than all the previous research/experience that has come before you. See the case of Cathedral v. Bazaar.


Data loss is not critical? Wow, remind us not to trust your firm with our data.


Every filesystem contains edge case bugs that lose data. The answer to whether everyone reading this story should go upgrade their kernel right now to avoid this one depends on factors like how probable it is that users will hit this one, and how risky the fix is.

The project maintainers are in the best position to make that call.


Delayed extents is probably a normal thing that happens in daily I/O operations. The possibility of it not actually hitting the platters permanently is a scary scenario.

"A single extent in ext4 can map up to 128 MiB of contiguous space with a 4 KiB block size."


The whole bug sounds similar to a problem we had on XFS back in the 2.6.16 time frame. Certain operations were delayed for hours meaning that it was possible for renames/writes not to hit the platter if the machine experienced power loss instead of a clean shutdown, even if sync's were performed.


I think JFS still has that problem, if Wikipedia is accurate.


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

Search: