I paid happily for monokai pro vscode since it was a one time payment. However I will not purchase a subscription for jetbrains intellij because per year it'll cost me the same amount as the intellij idea ultimate and that just doesn't seem like a fair price.
Yes, but not everybody builds the next social network or complex commercial app with 50 pages and 150 forms.
It used to be that svelte was the perfect choice to build simple spa fronts to backend services, there already was react for complex applications. Now we have 2 additional reacts with svelte and vue and no mainstream simple framework for smaller stuff.
Why does everybody feel they need to build eventually the same thing, but slightly different?
Drivers licence as a personal ID is not really a thing in Europe. It's accepted at some places, but either passport or your state provided ID-card is much preferred.
Very few Americans have personal ID so if they intend to do business in America, they should be prepared to accept drivers licenses.
Maybe they just don't want to sell to Americans, which is always allowed I guess, but setting up an American VPS provider and not accepting the standard American KYC verification methods would be a rather incompetent way of doing business. It'd be no different from doing business in Europe and only accepting drivers licenses and not accepting passports/ID cards for identity verification.
In the US, DL works as an ID for almost anything other than voting in an election. You can fly to almost any US territory with that plastic card. And it is state-provided ID -- nobody questions that.
And we are talking about 300M people here, which is about 4 times the population for Germany.
If they hate US residents they should declare that clearly on their website, not wasting customers' (and their own) time.
But you don't just have one type of drivers license for 300M people, do you? As far as I'm aware each state has their own. So it's not 300M vs. 80M, but 80M vs. 50x 6M people (incredibly simplified and wrong numbers, but you get the gist). Far more effort to verify each document.
That would still exclude non-driving customers, which means allowing at least one additional form of ID per state - suddenly you have to support at least 100 IDs for US customers, while German customers have exactly 1.
Not sure how you arrive at them "hating US residents", that's a weird conclusion to get to.
Contrary to the belief of a lot of Americans, just because it works in the US doesn't mean it works elsewhere. In the rest of the world a driver's license is used for proving your right to drive and we have a thing called passports for proving your identity. Hetzner isn't an American company so why should they accept American drivers licenses?
Thank you for working on light theme, it seems that 90% of themes are dark nowadays. Depending on languages I switch between dark and light themes and for the latter there's lot less choice. My brain has gotten used to that Java and R must have light themes, most other languages dark. I even have different color theme for each language. It's how my brain works.
It had been a community request from the beginning. Personally I still use the default Monokai Pro, but dark themes aren't suited for coding in very bright environments, like outside for example. Then a light theme really works better, and I'm glad I can offer that now.
yes, when it's possible. but guis may not exist or may be not better than console, like in case of ffmpeg. the best, of course, is smart assistant who can take verbal commands. either human or llm.
but my post was about doing complex tasks in general. try to offload. another advise for developers is to write comments, even in your small hobby projects. this way you don't have to memorize it all. this was learned hard way. i usually also have a separate documentation with plans, ideas, algorithms, useful info. remind: this is for hobby projects.
and important thing: touch typing is must have. this makes it all much easier
I do think these are good suggestions for anyone getting started with CLIs. Initially they struck me as a bit redundant, but only because the point I meant to make was that because I've already been doing most of that for ages, I'm happy to delegate that to a good gui if one comes along, since that is both more enjoyable, less error prone (mostly), and less tedious. Notes, comments, and LLM generated commands are lovely, but needing to rely on them less, particularly in situations where you can perform some common subset of tasks with better information layout, interface, and progress/state feedback, is worth paying for sometimes.
FFMpeg is a good example though of one I'm happy to just have my notes on, but since I do literally only ever use it for one or two types of tasks, I'm happy to have that sit behind the scenes. Others might use it in many versatile ways, for which I'd be grateful to have those options readily available in my terminal.
It's simple and there is less overhead. Since PHP runs directly within the Apache process, there is no need for inter-process communication (no TCP, no sockets), reducing the overhead. This can lead to lower latency for individual requests.
mod_php does give you better response times for individual requests, but at the expense of being able to handle a higher load of traffic; you'll run out of memory and/or experience timeouts on mod_php way before you do with php-fpm.
With mod_php, every Apache process has the PHP engine embedded in it, even if PHP isn't needed, e.g., to serve a request for a .css file. When Apache gets a bunch of requests for flat files, it forks all those processes and fills up RAM with copies of the PHP engine that aren't used. That's not only wasteful, but it dramatically increases the chances that you'll run out of memory. You can limit the number of Apache children of course, but you'll see timeouts sooner when you get a traffic spike.
By having Apache proxy over to php-fpm for PHP requests, you can configure Apache to use mpm_event for serving static files, which allows for much leaner Apache workers (memory-wise) since they aren't carrying PHP around on their backs.
While you're at it, you can use haproxy on the same machine for TLS termination, then you can disable mod_ssl thus making Apache workers even lighter.
> With mod_php, every Apache process has the PHP engine embedded in it, even if PHP isn't needed, e.g., to serve a request for a .css file. When Apache gets a bunch of requests for flat files, it forks all those processes and fills up RAM with copies of the PHP engine that aren't used. That's not only wasteful, but it dramatically increases the chances that you'll run out of memory. You can limit the number of Apache children of course, but you'll see timeouts sooner when you get a traffic spike.
Yes, that is true. But most high-traffic websites will cache static files such as CSS files and images, using a reverse proxy (e.g. Varnish, a CDN, or usually both). So I don't think this is a real problem, most of the time (99.9%?), a request for a static file will not hit Apache.
I'm not saying mod_php is better for all scenarios, of course, but I think it can be ok.
I tend to agree with you - using in "default" setup with mod_php and mpm_prefork is known to be far from optimal (still fine for blog about you and your cat).
With reverse proxy in front of such setup is - much better in terms of performance. For shared hosting - yet again, may be not optimal if one needs to support multiple system users.
From top of my head: reports and multiple projects. Also I kept getting weird "fetch failed" errors when creating rules or adding users from gui working behind reverse proxy so I gave up on the end.
