Where is the power grab? Everything is voluntary except for the requirement to support child mode.
9,555 karma · joined August 20, 2015
Your video actually has the opposite effect: it shows that there are no (easy) ways for parents to protect the children and government regulation is necessary.
The UI should be a single checkbox named "child mode" and small, gray link "configure" that opens the menu from the video. The parent just clicks the checkbox, and sets up a password, a fingerprint or paired device to unlock the mode. That's all. After this only government-approved apps and websites can be opened (parent may edit the white list if they are ok with navigating through a maze of ten thousand menus) and children are perfectly safe. Government may white-list only apps and sites that implement measures for content safety and may not add non-compliant apps.
Also I hate watching vertical videos on a laptop.
The mobile and desktop OS should have a checkbox "child mode" in the onboarding stage. Switching device to "child mode" allows only installing white-listed apps from the government list and opening white-listed websites from the government list. Parents may edit the white lists but not required to do anything other than checking a box and setting a password, or registering a fingerprint, or a paired device.
The white-listed apps and websites (who volunteered to be included into the white list) must implement measures to ensure safety. Another option for a website to opt-in is to add a HTTP-header claiming safety. White-listed sites may be subject to additional regulations.
Non-white listed apps and websites are not required to implement anything, including checking age, asking for selfies etc. If the parents add a website to the white list, it becomes their responsibility to ensure that it does not contain any harmful content. For example, if parents allow their child to use Telegram, Telegram is not obliged to do any age checks and content restrictions.
My proposal achieves safe environment for all ages, but at the same time:
- based on liberal principles of voluntary participation rather than on totalitarian principles like most other proposals
- doesn't require any age checks, selfies or passports
- doesn't require adult websites to do anything and spend money for compliance, unlike most other proposals which assume that every business must spend money on moderation and compliance
- only those sites and apps that want to be in the white list, have to spend resources
- doesn't require banning VPNs as VPNs will not be approved for inclusion into a white list
For men, I assume?
It requires a yearly payment and can get quite expensive [1]. There are application, examination, issuing and publishing fees for each patent. In contrast, publishing ideas online is free.
[1] https://www.uspto.gov/learning-and-resources/fees-and-paymen...
For example, I would publish the idea of a "self-driving car" that can drive without or with minimal human supervision using a computer. I believe this is pretty novel and can be called an invention.
Also I hope this patent is valid only in US and cannot be enforced in China.
Of course one could optimize this - for example, while fsync is being executed, we could accept the queries from other clients and execute them, and once previous flush finishes, flush multiple transactions at once. However, I am not sure if Redis can do this due to being single-thread.
And obviously maybe there are problems with drivers, or with my consumer-level SSD and maybe "professional" SSDs can do more flushes per second.
Writing the code took less than a minute. I often do microbenchmarks now because it is so easy.
> do not use throwaway placeholder rows to imitate a single item
The point of using multiple rows for one product is to distribute the locks.
In case with shopify, they want to decide whether the user may place order or not, at the moment when the user clicks "Pay" or some other button. If the user cannot place an order, they are shown the error, if they can, the items are reserved and the user is redirected to the payment page. So payment is processed only after successful reservation, and reservation is made only if the user wants to pay. The similar system works for buying train tickets online in my country, for example.
In you case, when user A clicks a button, following happens (as I understand):
1 the server increments the counter
2 the server calculates available amount as (amount_in_stock - amount reserved by carts with time < counter)
3 if the amount is large enough, the server updates the "time" field for user's cart thus reserving the item
Imagine that at step 2 the user A sees that there is one item left. However before user A does step 3, another user B might reserve the item (complete all 3 steps), and proceed to the payment. Then user A then completes step 3 and proceeds to the payment too. Now we end up with both user A and B paying for the last remaining item which doesn't solve the stated problem. Shopify's solution doesn't have such issues.
This is a classical TOCTTOU situation. There were exploits against Linux kernel based on similar issues.
RDB snapshots can cause multiple page faults due to use of fork() and CoW.
> It's easier to scale
The company in question manages online stores and they could easily scale by allocating a separate database for each store (sharding).
> But I think using Redis is much more elegant.
I cannot agree because I think using a single database for all the data is more elegant, than multiple different databases and there are less problems to deal with. I dislike microservice-style architecture strongly and believe it is mostly good for wasting company's money.
> 'Use only MySQL as a solution to the distributed transaction consistency problem between two different storage systems, Redis and MySQL!'
I read it as "do not create unnecessary work by using a single database".
Furthermore, the RDB snapshot mechanism (when Redis forks and forked process writes the snapshot) can double memory consumption and cause thousands of page faults in Redis process if there are many writes happening.
The docs contains corresponding warnings. "Cloud backups" are marketing terms and not ACID guarantees.
As one more disadvantage, Redis has no SQL and you cannot easily view the data.
As for transactions, indeed it seems to have them, but their execution is serialized, i.e. when MySQL can prepare 100 transactions in parallel, Redis will execute them sequentially.
[1] https://redis.io/docs/latest/operate/oss_and_stack/managemen...
You reserve the product by creating an "active_cart" entry. Your solution has a problem, that when you run the check, it might say the product is available, but before you create an "active_cart" to reserve it from thread A, another thread B reserves it and you end up reserving a product that is not available anymore. You end up with SUM(active_cart.quantity) > inventory.available_units.
That is exactly why the database has locks - to prevent this situation. With locks, thread A decrements inventory.available_units and that row is locked until the end of transaction. Other threads (if they do SELECT FOR UPDATE instead of SELECT) cannot see the old, invalid value until thread A either commits and the value is updated or rollbacks. However, locks cause performance issues and that is why shopify uses the architecture from the article - instead of 100 users fighting for the lock on the same row with available amount, each user locks only rows with units they plan to buy.
Interestingly, MySQL docs has the documentation page with a similar case: https://dev.mysql.com/blog-archive/mysql-8-0-1-using-skip-lo...
No persistence means the data gets lost if machine shuts down or process crashes. Furthermore, after restart you will need to regenerate the data which can take time. That's why Redis is a cache and not a database. You can fix the persistence issue (Redis can write WAL log, don't remember if it does fsync or not), but then Redis won't be able to handle those thousands of concurrent connections.
Redis (and other NoSQL storages) don't have some magic architecture that gives them advantages over SQL databases. They just cut corners on ACID guarantees and skip fsync. Once you start doing fsync, your transaction throughput will drop to SQL database level.
Redis also doesn't have transactions which means every app error damages the data. You will spend engineer hours investigating and fixing the problems. Transactions save so much time and worries.
Also you might not understand the original problem. Imagine if 100 customers want to buy product A. One thread starts a transaction, searches for amount of product A and UPDATE's it and goes searching for other products. The database locks the row until the end of transaction and other 99 treads cannot continue until first transaction commits (they can read but cannot update the rows).
This is why they made a row per item. In this case, transaction 1 hopefully locks only several rows with items of product A. Transaction 2 instead of waiting for lock release skips them (due to SKIP LOCK) and locks several next rows. And so on.
Obviously you do not need to make a row per item - if the available amount is really large (10 000 items), you could have for example 100 rows having 100 items each. In this case each transaction locks the whole row (100 items) even if it wants to reserve just one item. The problem though is that now every row might have different amount of available items and you have to do more work to reserve the amount you want.
Also, I wonder why they could not have a row status (available/reserved) and UPDATE it instead of deleting the rows.
What can be done to mitigate this? One option would be to buy a large FPGA and flash it with an open-source CPU. Another would be to emulate a CPU, working with encrypted data and commands, so that even if the backdoor in a host CPU tries to overwrite memory, it would only crash the emulated OS. One more option would be to run the code in a Virtual Machine like QEMU which translates the code and prevents issuing unknown instructions.
Also, in Muslim countries and regions it is typically expected for a woman to have zero previous partners to get married, or at least having relationship only within a marriage.