In general integer division is implemented using a form of long division, in binary. There is no base-10 arithmetic involved. It’s a relatively expensive operation which usually requires multiple clock cycles to complete, whereas dividing by a power of two (“bit shifting”) is trivial and can be done in hardware simply by routing the signals appropriately, without any logic gates.

The metric standard is to measure information in bits.

Bytes are a non-metric unit. Not a power-of-ten multiple of the metric base unit for information, the bit.

If you’re writing “1 million bytes” and not “8 million bits” then you’re not using metric.

If you aren’t using metric then the metric prefix definitions don’t apply.

There is plenty of precedent for the prefixes used in metric to refer to something other than an exact power of 1000 when not combined with a metric base unit. A microcomputer is not one one-thousandth of a computer. One thousand microscopes do not add up to one scope. Megastructures are not exactly one million times the size of ordinary structures. Etc.

Finally: This isn’t primarily about bit shifting, it’s about computers being based on binary representation and the fact that memory addresses are stored and communicated using whole numbers of bits, which naturally leads to memory sizes (for entire memory devices or smaller structures) which are powers of two. Though the fact that no one is going to do something as idiotic as introducing an expensive and completely unnecessary division by a power of ten for every memory access just so you can have 1000-byte MMU pages rather than 4096 also plays a part.

It would be a nominal charge for storage, bandwidth, and indexing. Book stores carry public-domain titles, for profit, and most have no issue with that. You can always procure the same files somewhere else—they are public domain, after all. Those who pay are doing so for the convenience, not because they’re forced to.

They could stick to public domain & indie titles. They won’t, but they could.

In what sense do you think this isn’t following the email standard? The plus sign is a valid character in the local part, and the standard doesn’t say how it should be interpreted (it could be a significant part of the name; it’s not proper to strip it out) or preclude multiple addresses from delivering to the same mailbox.

Unfortunately the feature is too well-known, and the mapping from the tagged address to the plain address is too transparent. Spammers will just remove the label. You need either a custom domain so you can use a different separator (‘+’ is the default but you can generally choose something else for your own server) or a way to generate random, opaque temporary addresses.

If you want to talk about non-compliant address handing, aside from not accepting valid addresses, the one that always bothers me is sites that capitalize or lowercase the local part of the address. Domain names are not case-sensitive, but the local part is. Changing the case could result in non-delivery or delivery to the wrong mailbox. Most servers are case-insensitive but senders shouldn’t assume that is always true.

CVS and E*Trade both refused to accept my fairly standard user@mydomain.info address during initial registration, but had no issue changing to that address once the account was created. It would be nice if their internal teams communicated a bit better.

The full email address syntax described in the RFC cannot be precisely matched with a mere regular expression due to the support for nested comments. The need to track arbitrarily deep nesting state makes it a non-regular language.

If you remove the comments first the remainder can be parsed with a very complex regex, but it will be about a kilobyte long.

deleted by creator

If someone said to me: we will meet two weekly…

You’re essentially assuming the conclusion by grouping it like that. There are three parts to “biweekly”, “bi-”, “week”, and “-ly”. “Once per biweek”, i.e. once per 14 days (or per fortnight), makes at least as much sense as “two” × “weekly”.

I have no idea how anyone thinks that meaning semi-weekly means twice weekly.

Meeting semiweekly (semiweek-ly, if you must hyphenate it) means meeting every semiweek, or every half-week (3.5 days). Which is an odd internal to meet at if taken literally but would result in meeting twice each week. “Semiannually” is a more common example, and I’ve never seen or heard it used to refer to anything but a 6-month (half-year) interval.

bi-sect: cut into two parts; from Latin “bi-”, two, and “secare”, to cut.

The “sect” part is critical. “bi-” on its own doesn’t imply division.

bi- means two, as in bicycle: two wheels (circles)

semi- means half, as in semicircle: half of a circle

The problem is that the prefixes can be parsed as affecting either duration/interval as in (bi-week)ly, every two weeks, or frequency as in bi-(weekly), two times weekly. The same applies to semi-.

Personally I find the frequency interpretation a bit of a stretch—“two” is not the same as “two times” or “twice”—so I would tend to read e.g. bimonthly as every two months rather than twice each month.

Cx File Explorer supports SMB, FTP, SFTP, and WebDAV remotes out of the box. There is an option to browse the local network.

Look up the legal principle of estoppel. In general you can’t turn around and sue someone for doing something after informing them (in writing no less) that you’re okay with it, even if you would otherwise have had a valid basis to sue.

Cx File Explorer has a similar feature, along with a built-in FTP client. Another option would be to run an SSH server like SimpleSSHD on the device you want to share files from so you can access them via SFTP, which Cx File Explorer also supports. This permits more secure public key-based authentication rather than just a password.

They ruled that people acting together have all the same rights that they would have acting individually, and that preventing someone from spending money on producing and promoting their speech effectively prevents them from being heard. Which are both perfectly true, common-sense statements.

I’ve seen “cash discounts” in many places but that’s a bit of a false economy as cash can cost just as much to handle as an average credit card in the form of security and “shrinkage”. I’ve never seen a business charge a higher rate based on what kind of card you use, which is what it would take to have an impact on the rewards system.

If you can read emails sent to a given address, and send replies from that address, it basically is your email address for all practical purposes no matter who was meant to be using the account. This is not necessarily a good thing and better end-to-end security would be nice but it is what it is. Odds are the app itself would let anyone change the password and log in provided they can read the emails, unless it’s using some form of 2FA.

You’re not wrong… but as you said, those are external costs. While it’s fine to wish for a simpler, more equitable system, given that the prices are mostly the same no matter how you pay, wouldn’t you rather be part of the group receiving the benefits? Paying with cash or check or a non-reward card is leaving money on the table. The cost of handling cash and checks isn’t necessarily any lower than credit card processing fees and people don’t have much tolerance for strange new forms of payment, which leaves merchants without much leverage to push back against rules which prevent them from passing on the higher costs of the reward cards to those using them.

What “increased risks as far as csam”? You’re not hosting any yourself, encrypted or otherwise. You have no access to any data being routed through your node, as it’s encrypted end-to-end and your node is not one of the endpoints. If someone did use I2P or Tor to access CSAM and your node was randomly selected as one of the intermediate onion routers there is no reason for you to have any greater liability for it than any of the ISPs who are also carrying the same traffic without being able to inspect the contents. (Which would be equally true for CSAM shared over HTTPS—I2P & Tor grant anonymity but any standard password-protected web server with TLS would obscure the content itself from prying eyes.)

No, that’s not how I2P works.

First, let’s start with the basics. An exit node is a node which interfaces between the encrypted network (I2P or Tor) and the regular Internet. A user attempting to access a regular Internet site over I2P or Tor would route their traffic through the encrypted network to an exit node, which then sends the request over the Internet without the I2P/Tor encryption. Responses follow the reverse path back to the user. Nodes which only establish encrypted connections to other I2P or Tor nodes, including ones used for internal (onion) routing, are not exit nodes.

Both I2P and Tor support the creation of services hosted directly through the encrypted network. In Tor these are referred to as onion services and are accessed through *.onion hostnames. In I2P these internal services (*.i2p or *.b32) are the only kind of service the protocol directly supports—though you can configure a specific I2P service linked to a HTTP/HTTPS proxy to handle non-I2P URLs in the client configuration. There are only a few such proxy services as this is not how I2P is primarily intended to be used.

Tor, by contrast, has built-in support for exit nodes. Routing traffic anonymously from Tor users to the Internet is the original model for the Tor network; onion services were added later. There is no need to choose an exit node in Tor—the system maintains a list and picks one automatically. Becoming a Tor exit node is a simple matter of enabling an option in the settings, whereas in I2P you would need to manually configure a proxy server, inform others about it, and have them adjust their proxy configuration to use it.

If you set up an I2P node and do not go out of your way to expose a HTTP/HTTPS proxy as an I2P service then no traffic from the I2P network can be routed to non-I2P destinations via your node. This is equivalent to running a Tor internal, non-exit node, possibly hosting one or more onion services.