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

I guess people are just a few days from starting to earn $30k/yr on their model 3s, as musk said it years ago? lol


To be fair, he's completely right. I have a lot of experience with IE6 and safari on iOS, and while IE6 was bad and did weird shit, Safari is much worse. It's amazing that things can work in any browser, without ever even thinking about it, but then on Safari you get weird behaviour, straight up rendering bugs because of some weird race conditions with the engine or even crashes.

The latest issue that I've noticed yesterday is the button nav bar on the screen when running PWAs. The button is over the bottom navbar of the PWA, and despite apple themselves coming up with the API to inform the browser about safe display areas, it doesn't work in PWAs on iOS. PWA mode on iOS != non PWA on iOS. They often behave completely different and you often have to use JS for basic things to work, like clicking a link(yup, this was a thing for years).


I've been using GitLab since the early days, but a week ago I switched to Forgejo. Power usage on the server dropped by 10%, despite both being idle most of the time.

As the author says, GitLab feels sluggish, and is bloated with 1001 thing I'd never use that just makes the UI a pain. Despite all the features I don't need, some that I would benefit from are disabled in the free version.

Forgejo is simpler. It allows me to hide features per project that I don't need. Bit there are some tradeoffs. Updates on GitLab was great. I've been letting it self update for years with no issues. This does not work on Forgejo. Forgejo is also a lot less polished, and some features just doesn't seem to work like they should.


I do t have time to test myself now, but it would be interesting to see a proper benchmark. We all know it's not suitable for high write concurrency, but SQLite should be a very good amount faster for reads because of the lack of overhead. But how much faster is it really?


as an in memory database, I got around 40,000,000 reads per second. Using WAL and a file rather than in memory, around 900,000 reads per second. This is single threaded, for a simple integer ID to string Value query, and a few years old at this point, and only minor config optimizations eg not even using memory mapped io and a ~3gb database with a million or so rows on a Windows machine. The performance really is amazing.


40 million reads per second, on a single core? 40 million reads/s is 25 ns per read, that is faster than any RAM I know of.


It's not like every read would make a separate trip all the way to RAM, caches are a thing and SIMD pipelines/parallelizes comparisons within a hash bucket quite well. Lookups from a hash map should amortize to something like 5-20ns per lookup these days. Abseil's Swiss Tables for C++ and Rust's Hashbrown both should reach that.


If you're looking up values from a 3 GB DB, most would have to hit RAM. Lookups form a hash map can be fast, but SQLite does quite a bit more than just a hash map lookup, and it would usually hit RAM, not L3 cache.


Parent comment said "with a million or so rows". I looked up numbers for benchmarks with ~1M entries in the hashmap.

1M 64-bit integers is only 8MB, that's still a small keyspace.


Perhaps relevant is that probably only 25% of the IDs that get passed to the select actually have values and this is using one thread for the benchmark. It's too convoluted to share, but indeed when using the in memory database on a lower spec laptop currently I still get up to 20-30m reads per second, pretty close to the 40m on the big box.


In some informal benchmarks I wrote using queries + data from a web app I develop, sqlite queries were about 5x faster than postgres.


Orders of magnitude I would imagine. Very significantly faster.


SEK, not EUR.


No, I calculated the exchange.


As a game developer myself, I think young kids should not be able to make purchases on their own.

But some of the ideas on what needs to be done is just silly.

Here is some of the ideas the Norwegian Consumer Council suggested: - All things in games should be shown in real money value, not in game currency that you have to but for real money, and the price should reflect the most expensive way to get the currency. - All transactions in games should have the same rights as in real life(if you buy an item in game, you could use your right of withdrawal). - Users should be able to choose how much the want to buy of premium currency/spend.

While it might have good intentions, they have serious issues. I sell bundles of in game currency. I don't allow users to select just how much they want to buy. I don't do this as part of an evil plan, but because it makes sense. Bigger purchases give more, because the percentage lost to fees are lower. Tiny amount can not be bought, as it would not make sense considering the per transaction cost.

I don't price things in real currencies, cause after the purchase is made, it's not real money, and if it were, I'd be a financial institution and break the rules of all major card networks. It also would cause issues when it comes to inflation adjustment. If an user buys 100 "coins", they can buy something for 100 coins. If I adjust for inflation then I adjust the price of coins, not how many coins are needed to buy something in game. That would not work with real money.

Regulation is welcome, but don't do something dumb. Let most thing be as they are, but put strict rules in place on kids making purchases, that way a grown up who hopefully understands money can approve or deny the purchase.


In game purchases are a dumb thing in itself and need to go away. You can sell add-ons for your game as additional packages, like DLC. Users go to the store (e.g. Steam) and buy an add-on to the game. It's priced like a normal article and you can offer discounts if you want.

If you offer something that cannot be handled like that and absolutely has to be "in game", it's probably because you're trying to extort the players by frustrating them or try to exploit psychological weaknesses to make users pay more than they want to and you should stop that.


You do have some weird takes on why I'm doing things. The game is free. Not because I'm trying to exploit someone, but because it's much harder and more expensive to market a paid game. I don't have DLCs, cause all content is free for everyone, and forcing players to pay to play by putting content behind paywalls is not something I want to do, and also something the same Norwegian Consumer Council says should not be allowed in games.


> I sell bundles of in game currency. I don't allow users to select just how much they want to buy. I don't do this as part of an evil plan

So if I look at your in-game purchases, I’m going to find that they aren’t all priced to make the user buy the next-larger increment of currency… right?


Didn't I just say that it wasn't part of some evil plan? Prices of things have no relattion to that the different bundle sizes are. In-game prices are constant to ensure that people get what they pay for. The price in real money for the in-game currency is adjusted for inflation every now and then.


> As a game developer myself, I think young kids should not be able to make purchases on their own.

As a gamer, I don't think they should ever feel the need to purchase anything with real world money in a video game, even with a parent. Purchasing the game should be the last time a parent ever has to worry about spending actual money on it.


A one time payment for an ongoing service is not sustainable. Infrastructure and content isn't free, the same way you don't pay a one time payment for netflix.


> Bigger purchases give more, because the percentage lost to fees are lower.

So you sell $100 of in game currency for $85. It's all the same except 1 coin equals one cent when you buy it in the smallest bundle.

> I'd be a financial institution and break the rules of all major card networks.

It's measured in dollars but it is a gift card. It's not that serious.


> Bigger purchases give more, because the percentage lost to fees are lower. Tiny amount can not be bought, as it would not make sense considering the per transaction cost.

This is a solved issue in basically any real life commerce. (Depends on the country if it's enforced) You say what your transaction fee is and add it on top. Then people can decide for themselves.


It's not solved if you're not allowed to bill for fees seperatly. The end result is the same, so it's a dumb rule. It just makes it less clear what you're actually paying for.


I'm not sure the legislation is good, but I'm not sure I follow some arguments. FWIW the ideas you're referring to are these I think: https://www.forbrukerradet.no/report-on-virtual-currencies-i...

> Bigger purchases give more, because the percentage lost to fees are lower.

Encouraging bulk purchases seems like an orthogonal problem to allowing users to choose the amount. You could always allow users to choose the amount and just include the transaction fee.

> after the purchase is made, it's not real money, and if it were, I'd be a financial institution and break the rules of all major card networks

If card networks are operating in the country, they'd have to abide by the country's rules too.

But also, I don't think that's how it works. It says "Developers must be obligated to provide an equivalence in real currency clearly and transparently next to the premium virtual currency before each transaction." (translated to English, but) - IIUC this means that if you sell a skin for "10 coins" you have to show the cost in real world money at the same time, e.g. maybe $1.9 one day, maybe $2.2 another day, based on the cost to purchase said coins. Or you could change the skin price from 10 to 11 or whatever if you want to keep the real money cost the same. It's not forcing any financial changes on you, just making you display a number.


> You could always allow users to choose the amount and just include the transaction fee.

I'd be happy to do that, but it's not really as simple as it seems. Multiple of my payment providers have fees I'm not allowed to disclose, and the same Norwegian Consumer Council has also repeatedly stated that they do not want payment fees to be passed on to the consumer as that might be unfair to those who can't use specific payment options. They are passed on to the consumer either way, so... That's the only reason I don't provide tiny purchases, as the fees will result in negative value of the sale. But again, I'd be happy if I could just add fees to the price so that people could just buy exactly the amount they want.

> If card networks are operating in the country, they'd have to abide by the country's rules too. Yes, but currently the laws are not compatible. You can't follow one without breaking the other.

The problem isn't displaying a price, but how to do it in a way that makes sense. It doesn't really make anything more clear when it's called the same thing as the currency in game and has no fixed conversion because of fees making up a larger cut for small purchases. The Norwegian Consumer Council want's users to be able to buy the smalles unit of currency if thwy want, but that must be relatively very expensive because of the fees. They alsy want prices to reflect the most expensive method of acquisition of the currency. This will 100 % result in totally unrealistic prices, that are easy to confuse with the in game currency. It's clearly easier if you buy a fixed bundle of 1000 "gold coins" for $10, and the price is listed as "Buy a $500 paiting for 100 gold coins" instead of "Buy a $500 paiting for 100 gold coins($50 real money)".


I don't know from your gripes it sounds like it is the right approach to rein in the lawless world of in-game purchases.


How freaking expensive do you think infrastructure is? It's not that expensive, and certainly not anywhere close to the point where it would make a noticeable impact on GDP.


Every little bit counts. At cloudflares scale it could be the difference between a DC having to close up shop or not.


The simplest way to prevent CSRF is to use the Referer header, and that has been used since forever. If the header is missing, you no-op the post. Origin is similar, and can be used with referer as fallback, but it's not needed for most sites.


NO. Please don’t spread wrong solutions.

Your attempt has similarities to the idea behind Checking Sec-Fetch-Site. Implementing that header is the same amount of work. But this header is exactly meant for this purpose, and referer is haunted with problems.

So for officially intended protections, implementing this header and samesite cookies gets you a very long way without any complexity, assumptions, or tricks of old lore.


It's not a wrong solution. It's been commonly used since forever, tens of years before the sec-fetch-site header existed, and it stops CSRF. Sec-fetch-site is not supported in old browsers, so relying on that is unsafe without any fallbacks.


Fetch Metadata headers, as discussed in this post, are just as simple and much more effective. There's lots of issues with referer, and even some with origin.


I worked on an legacy application that did this as a stop-gap as CSRF tokens were being implemented and it just kept both approaches.


To be fair, Gmail asks for a phone number, but you dont have to add one.


This might depend on the country you're in, but I'm quite certain I've gotten locked out of the signup flow in the past when I refused to provide a phone number.


It depends what you do it from. If you do it from an android device you don't have to. If you do it from the web you do.


I just tried it from my Android phone (GrapheneOS) and it still asks to verify a phone number when trying to create an account via a web browser. (Strangely, even though it's a private browser session it just asks to confirm my number by sending an SMS, not asking me for my phone number like it does on desktop -- I wonder how that works...)

If you're saying that the account creation flow through the system accounts application doesn't require a phone number, how are you sure that Google doesn't just collect the phone number directly from your device (they could even silently verify it through a class-0 silent SMS)?

Does it also not ask for a phone number if you factory reset, remove the SIM card, and do not register the phone with a Google account? Maybe they track the IMEI instead?


This is very misleading. The secure defaults for sqlite is changed, so commits are not actually written to the disk. Running sqlite like this will cause data loss on os crash or power loss.


I've added numbers for synchronous FULL to the article for those who are interested.


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

Search: