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.
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.
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.
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. 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.
> 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)".
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.
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.
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.
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.
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.