I've wondered for a while whether it would make sense to split the CPU into a "IOPU" and a "SPU"
- The IOPU would be responsible for directing other hardware on the system. It doesn't need to be very performant.
- The SPU would be optimized for scalar and branch-heavy code that needs to run fast.
The SPU could have minimal security, just enough so it can't read arbitrary memory when fetching from RAM. It would only run one program at a time, so speculation shouldn't be an issue.
At least on my system few programs need a lot of processing power (and even then only intermittently), so little task switching should occur on an SPU.
This precedent definitely won't be abused. Or at least most people here seem to think that?
I wish the article would go into detail what exactly the "transgressive behaviour" is, because now it is unclear to me how far I can take criticism that is either directly or indirectly linked to an individual.
For example, what if I have an extremely poor experience with a seller?
Does it matter if this seller is a business or some random individual getting rid of 2nd hand items?
What if the user being criticized is also anonymous?
In any case, I shall be using throwaway accounts more frequently just to be safe.
I am very glad I get to use open-source software at no cost. There are profiteers, sure, but I believe in the end open-source software will be more beneficial for society as a whole as it is much easier to reuse code.
My suspicion is that Prigozhin got recruited by a Western agency (CIA?) with the intent to destabilize Russia from the inside.
Key here is to discredit the Kremlin, by e.g. exposing or at least making them seem incompetent. Later a coup/revolution is staged to cause internal conflict and make Russia unable to continue the war in Ukraine.
Given how short this "coup" was and how easy Wagner seemed to get off with this stunt I suspect Prigozhin instead informed the Kremlin (or Putin directly) and played along. He would likely get supported during the coup by whoever recruited him. If this is the case those assets are probably arrested by now.
I find it fascinating that people defend censoring "misinformation" because people (supposedly) cannot discern it from "real" information.
If we cannot trust the judgement of the common folk, why have a democracy at all?
It is not. Even long/"complicated" passwords usually do not have much bits of entropy, which is why you need an expensive hash to make bruteforce attacks difficult.
I do not believe such OSes can ever be secure given how often vulnerabilities are found in web browsers's JS engines alone. Besides, AFAIK the only effective mitigation against all Spectre variants is using separate address spaces.
For an I/O heavy application (not in C++) I avoid threads for the main "loop" as there is a central cache that is accessed often. Synchronizing access to it is likely more expensive and error-prone than using just a single thread. It is also possible a few hundred or thousand tasks are running concurrently, which becomes very expensive very quickly with threads.
There are a few CPU-intensive tasks but those are easy to isolate and send to a threadpool.
Project description: I'm designing a custom filesystem with compression, error correction (with mirroring) & encryption.
The aim of the project is to have a filesystem with these features while remaining considerably simpler & easier to use than ZFS, btrfs etc. In particular, I aim to make it easy to use with removable media as I got a bunch of old drives that I don't want to have powered on 24/7.
I'm looking for people willing to test the filesystem. While the filesystem appears stable I believe more issues may pop up when used for long-term storage (e.g. backups). With more people using it I hope to find these issues quicker.
There are currently only (FUSE & tool/"mkfs") binaries for Linux[1]. If you want to test it but don't have a Linux installation, please let me know and I'll see if I can create a build for your OS.
> Maybe it's unfair of me, the retort is always "it's open source, contribute back!" but alas that is how I felt as a USER before I considered being a CONTRIBUTOR.
Even as a contributor I've found it very frustrating to contribute to Godot.
I've found lots and lots of bugs while working on my own projects using Godot. I spent a lot of time digging in the engine code to figure out the cause, make an issue and a patch if I could.
However, even small changes take a lot of time and effort. While I used Godot 3 for my own projects most of the PRs had to be based against 4. At the time Godot 4 was in a very sorry state and I ran in many, many issues that made it hard to test if the same fix for Godot 3 also works in Godot 4.
I wrote some libraries to work around issues that I (or others) could not get fixed or reverted (e.g. I replaced the physics engine with Rapier3D because I really needed more stable and working joints) but I eventually threw in the towel and decided to focus on other hobbies.
- The IOPU would be responsible for directing other hardware on the system. It doesn't need to be very performant.
- The SPU would be optimized for scalar and branch-heavy code that needs to run fast.
The SPU could have minimal security, just enough so it can't read arbitrary memory when fetching from RAM. It would only run one program at a time, so speculation shouldn't be an issue.
At least on my system few programs need a lot of processing power (and even then only intermittently), so little task switching should occur on an SPU.