Even Malaysia Airlines Flight 17 was downed by surrogate forces offering a certain amount of deniability.
Was that actually confirmed somewhere? It's not that easy to train people to use the AA system and IIRC they shot down plane within days of the system arrival in Ukraine, which would suggest that it was controlled by russian forces.
Most people use CO2 meter at home to measure air quality. If you're in room that is not well ventilated, depending on the size of the room, CO2 will reach pretty high levels within minutes. Unless it's really bad, it's not high enough to kill you (which is why people have CO detectors) but spending long time in the environment (hours) might cause issues with how well you can focus, trigger headache or migraine, cause tiredness if this is your bedroom, etc..
Yeah it's pretty amazing system all things considered. It's kind of as if 8-bit home computer systems continued to evolve, but keep the same principles of being really closely tied to the HW and with very blurry line between kernel and user space. It radiates strong user ownership of the system. If you look at modern systems where you sometimes don't even get superuser privileges (for better of worse) it's quite a contrast.
Which is why it reminds me of Emacs so much. You can mess with most of the internals, there's no major separation between "Emacs-space" and userspace. There are these jokes about Emacs being OS, but it really does remind me of those early days of home computing where you could tinker with low level stuff and there were no guardrails or locks stopping you.
I couldn't help but think of Emacs when I was reading A Constructive Look At TempleOS. It's like TempleOS that is actually finished, it just lacks kernel.
I definitely can. It would be a completely different topic in russia where they draft people to sustain occupation. If Ukraine stopped defending now, you'd have Buchas and Mariupols all over Ukraine with many dead. So I don't really see it as immoral as much as it sucks for everyone involved.
Compared to that, taking bribes from desperate people is next level fucked up and it's effectively profiteering on genocide.
If it's really early 2000s, you might want to put it on eBay. There are retro gamers out there that could use it as good Windows 9x era gaming PC. You could give that HW a new life in someone's retro setup.
It's great HW for occasional gaming, but it's very inefficient for 24/7 operation. You want to be somewhere after 2015-ish for something that is supposed to run constantly.
Perhaps it's kind of inevitable to have some bloat. For example apps these days handle most of the languages just fine including emoji, LTR/RTL and stuff. Some have pretty decent accessibility support. They can render pretty complicated interface at 8k screen reasonably fast. (often accelerated in some way) There is a ton of functionality baked in - your editor can render your html or markdown side by side with source code as you edit it. You have version control, terminal emulator, language servers, etc..
But then there's Electron, which just takes engine capable of rendering anything and uses it to render UI, so as a result there's not much optimization you can do. Button is actually a bunch of DOM elements wrapped in CSS.. Etc.. It's just good enough for the "hardware is cheap" approach.
I think Emacs is a good example to look at. It has a ton of built in functionality and with many plugins (either custom configuration or something like Doom Emacs) you can have very capable editor very comparable to the likes of VS Code. Decades back Emacs had this reputation of being bloated, because it used Megabytes of RAM. These days it's even more "bloated" due to all the stuff that was added since. But in absolute numbers it does not need as much resources as its Electron based peers. The difference can easily be order of magnitude or more depending on configuration.
Yeah, it's really fucked up once you zoom out a bit. You wouldn't even do this to POWs and these people are civilians that are being treated even worse.
Moving off from port 22 is effectively just security by obscurity. It will save you some logs but the bandwidth and CPU time saving is negligible - especially with fail2ban.
That comment is just spreading FUD. One of the links is just link to someone's message saying they hate systemd. The other is just link to random (resolved) bug.
People aren't disliking the comment, it's actually terrible comment with no value.
The author is upset that btrfs RAID arrays don't function as he anticipated. However, btrfs isn't ZFS or mdadm; it's its own system and should be understood as such.
I'd say it's quite reasonable critique, because RAID1 is kind of industry standard. I can't think of any other RAID (HW or SW) that would do RAID1 in this way. If btrfs decided to call their implementation raid1 while it really isn't raid1 in some major way, it was very bad idea. I don't agree it's documentation issue, it's really bad name choice. ZFS has raidz that does something similar to btrfs raid1 and the name does not lead to confusion. RAID1 system should never lead to decreased reliability with increasing number of drives.
The author points out that btrfs won't auto-mount an array if a drive fails, while ZFS will. This is actually a protective measure. By not auto-mounting, it minimizes the risk of further drive failures, prioritizing data preservation.
RAID is uptime preserving mechanism. If anyone uses RAID for data preservation purposes, they are setting themselves for a nasty surprise. RAID system that does not mount in reduced redundancy situation is very bad design. It effectively sacrifices usability of RAID to serve other purpose that RAID system does not really need nor should be used for.
He attempts ZFS recovery methods on btrfs and is surprised when they don't work.
I felt that way as well, but I think they raised one important point - there was no indication that the array was still in reduced redundancy state after their "attempt at recovery". ZFS is very clear about the state of array at every step. Same for other RAID systems including some HW based ones. Every single one I've used were very clear about the fact that array isn't fully redundant.
In summary, the article's author seems primarily upset that btrfs isn't a ZFS clone.
FWIW I didn't have that impression. I have experience with multiple RAID controllers and multiple SW RAID systems and his points would be valid with any of those.
Anyways thank you for your reply. It's not the answer I was hoping for and I don't agree with your views on some of these issues. But it gives me pretty good idea of the current state of the filesystem.
Out of curiosity in your experience, are issues mentioned in this article actually fixed now? They mention the write hole, so that was fixed. What about the rest?
I'd say it's more about elasticity. Scaling is just very narrow aspect of elasticity.
To give you some specific example, there's a company (that I won't name) that by law has to have all data on premises. They have local cloud in their own datacentre. Part of that cloud is a set of powerful servers with ton of GPUs. Daytime they spin up VMs that employees can log into and have remote desktop for graphically intensive tasks.
Now you might be thinking "wait a second, they can't easily add GPUs in the morning as employees log in, there is no scaling and thus no cloud!" And by that definition you'd be right. But what they do with their cloud is that as the demand for VDI drops in the evening, they will start allocating the GPU and CPU resources to completely different kind of VMs that do overnight data crunching. (think geospatial data) It's completely different OS, the servers are in server subnet, not VDI network, etc.. So they are using the elasticity, but it's not just scaling.
Another counterexample is pretty frequent issue on AWS, where they momentarily run out of specific instance type in specific region. AWS support "will do their best" but you're often looking at hours of wait time before you get your instance. Now depending where you live you could go buy a server and deploy it in your own DC faster than that. Has AWS stopped being cloud provider? No, you can use the elasticity and either spawn different instance type (if your workload allows that) or in different region/AZ. You might have been just trying to replace one instance with another, not even trying to scale up, it's just the capacity for replacement wasn't there.
Was that actually confirmed somewhere? It's not that easy to train people to use the AA system and IIRC they shot down plane within days of the system arrival in Ukraine, which would suggest that it was controlled by russian forces.