We allow people to self-identify their religious beliefs. The government doesn't declare you to be a Catholic or a Buddhist and force your driver's license to say such.
Unless you're proposing making the military- and the rest of society- radically gender neutral, than as soon as a person interacts with a driver's license, passport, social media account, or bathroom, they will have to adopt a gender identity . Why should a third party's "gender beliefs" about a person be elevated above their own?
(I also can't see a justification for denying hormone replacement therapy treatment- it's cheap and ridiculously beneficial for mental health. But, for the same reasons, I advocate its availability over-the-counter.)
Rustup downloads toolchains from third-party (to the distro) repositories; distros do not want to be in a position where they can no longer build packages because of an external service going down.
So, if you are developing something you want to see packaged in distros, it needs to be buildable with the tool versions in the distro's repositories.
(Not just rustup- Debian requires repackaging Cargo dependencies so that the build can be conducted offline entirely from source packages.)
For context: since a base64 character represents 6 bits, every block of three data bytes corresponds to a block of four base64 encoded characters. (83 == 24 == 64)
That means it's often convenient to process base64 data 4 characters at a time. (in the same way that it's often convenient to process hexadecimal data 2 characters at a time)
1) You use = to pad the encoded string to a multiple of 4 characters, adding zero, one, or two as needed to hit the next multiple-of-4.
So, "543210" becomes "543210==", "6543210" becomes "6543210=", and "76543210" doesn't need padding.
(You'll never need three = for padding, since one byte of data already needs at least two base64 characters)
2) Leftover bits should just be set to zero; the decoder can see that there's not enough bits for a full byte and discard them.
3) In almost all modern cases, the padding isn't necessary, it's just convention.
If you want your function to block until the promise resolves, then the function calling it also has to block, and the function calling that has to block, and so forth.
At the top of the chain, this ultimately blocks the entire event loop (Javascript semantics are generally not concurrent), so no UI/network events can be processed until that promise resolves and the page/server is left non-responsive.
(And that's assuming you can somehow define clear semantics to run any Javascript code involved in resolving the promise; otherwise, you're deadlocked!)
It's not easy to divorce "culture war" from "problem solving", since the question of whether problems even _exist_ and need to be solved is frequently a culture-war issue.
For example, you can't pursue "energy modernization and decarbonization" in the USA without taking a side in the "does anthropogenic climate change exist?" culture war.
Any infrastructure plan, whether heavy-infrastructure or social-infrastructure, touches the culture-war questions of "should the government subsidize industry?" and "should the government subsidize the working class?"
This macro lets you embed an entire folder of assets in your binary at compile time, to simplify distribution.
Taking the concept further, I could also imagine build macros that compile Typescript or SASS files at build time, or generate data structures from a Protocol Buffers definition file, or in general operations that ingest non-Rust source code and use tools outside the repository.
tl;dr: Hyperbeam is roughly a netcat tunnel that connects via a DHT topic instead of network address; use it where you want a secure one-off tunnel. (for example, to transfer a key for Wireguard)
Wireguard:
+ Can tunnel arbitrary IP traffic
~ Has stricter encryption, with full asymmetric keys (and optionally adding a symmetric key)
- requires permissions to load a kernel module and configure the network stack
Hyperbeam:
+ Only needs userland UDP sockets, not a kernel module
~ Derives its keys from a passphrase, so does not require transferring a full cryptographic key between devices
- is a single application-layer pipe, applicable in shell workflows but not transparently tunneling arbitrary applications
Most drivers in Linux are loadable modules- see the output of `lsmod`.
They are built (usually) at the same time as the kernel, yes, due to the lack of ABI stability guarantees, but most drivers you don't use won't take up any RAM.
If there's "too much" lag or packet loss, delay-based netcode will also become unplayable; the difference is that rollback has more tools to address bad connections, so that rollback is often not even visible:
- predicting that the buttons held down in frame X will be the buttons held down in frame X+1 is actually a pretty good heuristic
- in fighting games, changing directions and attacking generally have windup animations, so if a correction skips a few of the initial animation frames, it still hasn't diverged the overall game state much
- even in bad connections, you still have control of your character; the game doesn't freeze and take you out of the flow (this can be subjective)
- hybrid approaches are possible, where a small fixed delay is used in addition to rollback; short enough to not be obvious to the player, but long enough to avoid rollback in the cases where delay would be sufficient. (delay-based netcode is not good intercontinentally anyways due to the necessary delay for synchronization becoming obvious input lag)
As for why rollback is rarer, yes, it is more difficult; it usually requires a fully deterministic game engine with the ability to snapshot and restore game state, which can be a very intensive retrofit if you didn't design it in from the start.
It was possible with the early, finite-world-creative-only "Minecraft Classic", but as long as I remember (I started playing mid-Alpha, a few months before the Nether was added) the game was played through the launcher.
Data in a dat, just like data in a torrent, only lives as long as there are peers interested in seeding that particular dat; it's not a blockchain-style "everybody has to replicate everything".
You can't unilaterally withdraw content somebody else is also seeding; the best you can do to my knowledge is publish a new version that replaces all the dat's content with a "please delete your history of this archive" message, but as with any distributed system you have no real way of knowing if that was respected.
Moving accounts is supported; your old account posts a machine-readable "moved to x@y" message, which tells your followers to automatically switch to the new location.
You can commit code that doesn't compile onto a feature branch so people can see what you're up to, I guess, but I don't see that helping with bisecting later, and I wouldn't expect the commit messages to be useful.
To be clear, my typical approach is certainly to commit every time I return to a working state. But in more experimental modes, I often reach that the long-way-around and have ended up with multiple semantic changes I wish to break apart for study.
Unless I'm missing something and Fossil has gained the ability to cherry-pick selective lines from a commit.
It's reasonably common for me to start exploring a problem space, stub out a concept, and have a long drawn-out conversation with the compiler that touches many files, before finally reaching a point that is working enough to be interesting.
At that point, I can take a step back and note that actually, not all of those changes have to be made all at once, and I can break that patch up into a bunch of simpler pieces.
In Git, I have two essentially-equivalent choices:
1. stage the commit in small chunks, adding a separate descriptive comment for each.
2. commit everything as a WIP commit so this working state is in the reflog, then break it up into smaller commits with interactive rebase.
In either process, I'm able to get a better comprehension of my own thoughts along the way.
Fossil, refusing both staging would force me to commit the proverbial 500-line blob all at once, which is less helpful to the reviewer trying to discern my thought process.
If rebasing isn't important to your workflow, Fossil probably is a better choice for you than Git. It has a lot of comforts that I really appreciated even eight years ago when I did frequently use Fossil (distributed wiki and tickets are really nice, the web interface serving raw artifacts from any point in time is great for HTML5 game jams, SQLite is a very portable repository format, etc. etc. etc.), and I'm sure it's only improved in that regard. The only reason I use Git for personal projects is because rebase is that helpful to my process.
I love much about Fossil and used it a lot several years ago, but my workflow have mental model have since come to rely heavily on interactive rebase, a philosophy that Fossil abhors.
Unless you're proposing making the military- and the rest of society- radically gender neutral, than as soon as a person interacts with a driver's license, passport, social media account, or bathroom, they will have to adopt a gender identity . Why should a third party's "gender beliefs" about a person be elevated above their own?
(I also can't see a justification for denying hormone replacement therapy treatment- it's cheap and ridiculously beneficial for mental health. But, for the same reasons, I advocate its availability over-the-counter.)