> I want a stable platform that will host my small static website blog at a very low cost, with high stability and uptime, no questions asked.
Maybe try the neocities supporter plan[0]? They allow custom domains, offer decent bandwidth and put a lot of effort into open source and encouraging people to write their own sites from what I can tell.
It seems like a better option than dealing with the Great Amorphous Corporate Centralizing Mass that is Cloudflare.
It's their entire MO; their name indicates the idea is that they are also a successor to geocities. No backend support whatsoever, just HTML/CSS/JS and whatever other files you need to host a site (images).
Their AUP isn't unreasonable: don't use them to host scams/spam people, don't abuse their services for an SEO farming operation, don't infringe on people's copyright, don't get their IPs blacklisted and don't use their services to harass or threaten people. All fairly standard as far as "we don't want to get sued/get in trouble" is concerned.
There's also an API to upload files to, shouldn't be too difficult to use it to rig up an SSG deployment script for it, or alternatively you can use their web interface to upload the resulting files. (Although it is on the assumption that you shouldn't abuse it.)
It's because of Google Play Services and the subsequent years long gutting of AOSPs application list. Google enforces OEMs to bundle their entire suite if they want to ship with Play Services and then uses that as an excuse to kill the basic AOSP phone apps that are outside of their ecosystem. That in turn harms the ability for Custom ROMs to ship basic apps like SMS readers, phone dialers and similar such, all of which used to be (maybe some still are, but they're all very much not well maintained) part of AOSP. If there's any silver lining, the upcoming play service blockade to install your own software on Android is likely going to at least create a burst of users for older devices.
The actual numbers are frankly even more disappointing - these numbers are heavily pushed up up by waydroid, which is an emulator for Android apps on Desktop Computing. More than half of the US installs is running Waydroid, with the actual most used real device in the US being nx_tab... which is LineageOS for the Nintendo Switch. That's a difference of 180k and 12k btw. The most used actual phone in the US for LineageOS is beyondx, which is the codename for the Galaxy S10 5g, a device that at a glance stopped being sold last year.
China by contrast fares much better when it comes to LineageOS (as Google Play Services isn't allowed in the country by export controls, the control from Google isn't nearly as strong there); the most used device there is actually a phone, the Xiaomi Mi 8 (dipper) and right behind it, the Xiaomi Mi 10T(/Pro) codenamed apollon.
Final country worth mentioning is Brazil, which apparently really likes the moto g7 power (ocean), a phone from roughly the same period as the Galaxy S10 5g.
Vietnam is also relatively high, with the Galaxy S7 (herolte) being the most used device. Russia is just a case where it's basically all waydroid users - not real phones.
At least from my understanding of the world, most of these numbers make sense if you consider them in proximity to US power, financial capabilities making phones last longer than their official support dates and just a rough idea of what phone brands are popular in which country.
Because the conversation is incomplete if we're talking internationally.
The cost of living in the US is much higher compared to most other first world/rich countries for one. Count up someone's basic living expenses in the US and those in another country (so taxes, rent and fixed costs) and the US often ends up much higher in terms of absolute values. In other countries, taxes usually soak up more of those fixed costs, reducing them more across the board for most people. The US also has very little protection against surprise fees at checkout (to the annoyance of non-Americans when ordering stuff online from the US), so a lot of stores sell on higher markups relatively speaking, making the same goods more expensive in the US. There's also healthcare, which needs little elaboration because the US is to my knowledge the single most expensive country to live in when it comes to that.
That applies to the US as a whole; it's why someone can say they're making 300k USD a year, say they're apparently barely able to stay afloat and then the rest of the world pretty much regards the US economy as being fundamentally wrong in some form. In most places, 300k USD a year is living in the upper class (as in, "work this job for a decade and you can retire early" money), not scraping the bottom of the barrel. By modern conversion standards, that's about 263k euros, or about 21k euros each month.
Then there's the tech sector specific problems. San Francisco is expensive to live in, and most US tech companies are in SF. Take the US cost of living problem, amplify it specifically for the tech sector (which is usually not talked about, since it's hard to vocalize). Second is that the US tech sector has more creative ideas and money than business sense - throwing money at a problem like the purse doesn't exist is a very US tech thing that doesn't apply anywhere else. It means that it's possible to hire people at far more inflated prices than the job is realistically worth.
Whether a wage is good or bad is pretty much entirely dependent on the local economy. Someone making 2000 EUR a month in Europe makes just above/right below the poverty line. Someone making 2000 EUR a month in Brazil is living an upper class lifestyle. That's an extreme comparison, but is a good indicator.
One other point: tastes expand to fit your income. You learn how much many you get every month and then how to spend that much.
My local Mercedes dealer will lease me a car for $4000/month (+ insurance) - somebody must have enough money to make that payment. If that is too much maybe the 18 year old Honda Civic with 300k miles for $1000 (cash price) is more your style? Probably you fit in between those. (note that we are talking about the US so we can assume there is no useful transit)
You're probably thinking of the Steam debacle. Nintendo wasn't responsible for that.
What happened was that Dolphins developers wanted to release the emulator on Steam. Valve, independently from anyone else, send a message to Nintendo's legal team asking if they think it's permissible to distribute Dolphin on Steam. Nintendo's lawyers essentially responded with the company's policy on emulation ("third parties doing emulation is not okay") and that they might consider looking into their options should Dolphin release on Steam. After that, Valve told the Dolphin developers that the game was banned from Steam.
Nobody send any legal threats or anything; no C&D was issued, no DMCA invoked, no lawsuits, nothing. As far as the legal side of things is considered, the only thing that happened is that a business refused to do business with someone. (Which is generally their right to do, as long as it's not because that someone belongs to a protected class and being an emulation developer is not a protected class.) That's why Dolphin's devs also effectively had no recourse, even if they could pay the necessary lawyers. You can't force someone else to sell/publish your stuff.
Great post. Redis is just kinda overkill whenever I've had to use it. Memcached by contrast is very simple, fast and works without needing to do much fiddling with it.
One big tip I should recommend is to increase the default memory size limit to something more realistic for modern hardware (and arguably this should just be increased on the upstream's side as well, instead of making everyone reconfigure shitty defaults). It's very easy to exceed the memcached default key value, since it's just 1mb; the maximum size of memcached as a whole is 64mb, which is similarly very low. Outside of that, it works very well and the lack of persistence is great at making it not do things it's not supposed to do (which is a big problem with Redis' feature creep, the projects mainpage promoting AI drivel alone should point towards that.)
It's also worth noting that some of those trillion dollar companies have had staggeringly bad responses when confronted with the fact child predators are running amok on their platform.
The CEO of Roblox is probably the single easiest example to point at; when confronted about his platforms issues when it comes to enabling child abuse, the first response he had was to claim that child predators were an untapped market and then claim to be interested in adding a dating site feature to Roblox.
That's the kind of rethoric these bad laws are a response to, and is the elephant in the room that a lot of the tech industry fails to recognize. (Including the privacy advocates, for whom every nail looks like it has a hammer shaped solution.) Age verification isn't a good solution to this problem, but it at least forces the hands of these companies to address it if they don't want to face jailtime for knowingly abetting predators - they can't pretend to have clean hands anymore if they're mandated to verify user ages.
There's almost certainly better solutions, but that's also why attestation (where the source device transmits the user's age, rather than storing a ton of PII of them elsewhere) misses the mark. Attestation doesn't fix that problem.
Attestation won't solve the problem of a predator also claiming to be a child, but what if attested children could only talk to friends added by the linked parent account? There are in between solutions that don't involve total surveillance.
> The closest vision back then to what we're getting now is the moody ship's computer from hitchhiker's guide.
It's not the ship computer, but the door AIs, which had this marketing blurb in the brochure:
> All the doors in this spaceship have a cheerful and sunny disposition. It is their pleasure to open for you, and their satisfaction to close again with the knowledge of a job well done.
Tellingly, the main characters respond with annoyance whenrver the doors speak up.
Hitchhikers Guide should not have been as prophetic as it ended up being, but here we are.
It's somewhat fascinating to me that we are so far out in the weeds of stupidity in the modern era that the only things that were predicted accurately have to come from satire about "Nobody would ever be so stupid as to build or create this"
To be fair, the advice very rarely is for people to jump onto Arch based distros.
The problem is more that the Arch value proposition kinda presupposes the sort of user that's going to "feel superior" about having it installed[0]. It leads to people that have no business installing Arch Linux (as it doesn't match their usecase) installing Arch Linux because it makes them feel cool.
I don't have a good answer for this, besides making it more apparent what people should expect from having Arch installed. My recommendation usually goes something like this:
* Do you want to have the latest version of all software, regardless of the question if it's well-tested beforehand?
* Do you want to have all software distributed in an as-close-to-upstream approach as possible? Be aware that "upstream" configuration can sometimes significantly differ from defaults most people expect. (Sometimes there's reasons for this, sometimes upstream are a bunch of obstinate jerks.)
* Are you comfortable with a terminal?
* Are you comfortable with needing to suddenly learn how to troubleshoot a broken system after a routine update?
Only if the answer to all of those is "yes", then Arch is suitable for you.
And finally, more specific to servers, where the answer should be "no" if you want to use arch:
* Do you have the expectation to never have to touch the OS after it's been configured correctly besides routine maintenance (ie. installing security updates) and maybe a big update twice a year?
I used to use Arch, before realizing that my system was gradually morphing into a bespoke mess that didn't really serve my needs and that while doing something very specific was possible, I also had to configure a bunch of mundane stuff you aren't normally required to think about - there's never a "just install, activate and adjust as needed" with Arch. All I actually wanted was a distro with more recent software than "3 years old" (Debian/Ubuntu's sluggish package inclusion is not really useful for desktops).
So I looked around and realized Fedora worked better for me: professional, clean, recent software (every 9 months updates, feature freezes are smart enough to account for ie. New Python releases) and not prone to sudden surprises.
To be honest, it took me way too long to figure the Arch etc crowd are hobbyists who enjoy having something which always 'needs maintenance' over the weekend. (And maybe they don't want to admit they are hobbyists because what they are doing seems Very Important.)
Sorta like 'car guys' who recommend some old thing you can wrench on.
For what it is worth, while I'm sure it is right on target for some, I think that's incorrect model of a mean arch user. Updates are once a month thing for me (and the maintenance for that rarely exceeds 10m if that). I barely do any distro level tinkering, after all, I need to spare some time to improve my emacs config ;).
Basically, my model of a mean arch user would be closer to a DIYer -- likes to follow clear manual instructions, likes sturdy and non-ephemeral things, likes to know what the sausage is made of, but prefers if maintenance costs are minimized (since they will be bearing those costs and are responsible for the thing), so makes choices according to that.
Hey, your response improves my opinion of 'car guys'. Because the analogy is thin and they are looking directly at what is coming out of the 'sausage machine'. And if the result is good, they could sell the machine for profits! (Unlike computer nerds.)
I'm sticking with "hobbyists/dabblers" here, because almost nobody runs Arch in real production scenarios. Its just a fun high-touch thing people can enjoy fucking around with. Nothing wrong with that.
(That is why someone could trivially trojan hundreds of packages and it's NBD. Because "Nobody Cares." Wipe it and start over, funguy.)
Browsers have an absolute insane level of relatively unchecked permissions to do whatever they want on a client.
There's a lot of effort by browser developers to scope creep the browser into essentially being an OS-agnostic tech stack (one where, conveniently, code can be shipped across the network "as necessary", removing a lot of user agency for the software being ran); Chrome being the biggest driver of this, while Firefox has an extremely weak spine in trying to limit it.
It's fairly dire and I wouldn't be surprised if there's a lot more of these side channel attacks in a lot of web APIs.
Unfortunately, real apps and native tech stacks can not only write data to your SSD, they can usually write data to the user directory however they want and they can read it as well!
This is a Linux-centric take. It does not apply for example to iPadOS or to AluminiumOS (coming soon to a Googlebook near you). It applies less and less over time to MacOS.
Yes, if one is committed to the standard Linux desktop, then one must hope that any proprietary apps one might need will continue to be available through the browser, but I'm ready to let the standard Linux desktop go (not right now, but eventually).
It very much applies to macOS, or do you know of a way to know what permissions a sideloaded macOS application will have before opening it that's accessible to regular users?
The very fact that you've qualified your question with "sideloaded" suggests that you are already aware that a non-sideloaded MacOS app is installed into a sandbox that is much more secure than anything available on a standard Linux desktop excepting possibly Qubes and Secureblue, and hardly anyone uses Qubes or Secureblue -- probably for very good reasons.
Yes, and I'm also aware that most macOS apps are still only available as a sideload, where sandboxing is optional and importantly not user visible before the app runs.
I don't know, maybe something about backwards compatibility, maybe nobody can agree on how to do it correctly. It hasn't happened for decades, so I'm not going to hold my breath.
Except you’re not going to install native apps for the vast majority of things you use a browser for. You’re going to use the browser for content consumption and native apps for a few things that need system access.
It's also the technology that will allow software to run without a continuous connection to the server. If you want to break out of a world where companies own your data it's the tech that is needed.
(In case it's not obvious: rethorical question, Google just wants to do platform lock-in with Android and sees this as a useful means to bludgeon it.)