Parallel execution must be explicitly enabled. When enabled, JUnit uses a fork-join thread pool, so tests may run concurrently on different worker threads. Because these threads are reused, a ThreadLocal value left behind by one test could be visible to a later test that happens to run on the same thread.

Setup and teardown methods can be used to create and clean up test-specific state. However, developers must still ensure that test data is unique to the test so that concurrently running tests do not interfere with each other. This uniqueness is unfortunately called "isolated", and has led to much confusion like in this thread. Certainly, the Test Execution Framework cannot guarantee data-isolation.

Parallel and randomized test execution can also help expose application-side problems involving shared or order-dependent state. Such failures may only appear when tests happen to exercise the application under the relevant ordering or concurrency conditions. When I was a junior developer teaching myself Java Servlets in 2000, I had to learn this lesson the hard way. A Test Execution Framework would not be able to guarantee any "isolation" of test data and of workflows if the server-side state is mis-managed by the tech stack and/or by the developer.

[1] https://docs.junit.org/6.1.3/writing-tests/parallel-executio...

Kent Beck is co-creator [1] of the JUnit Testing Framework and has most definitely heard of static and global variables.

[1] https://junit.org/junit4/project-info.html

I’ve looked here: https://github.com/earendil-works/pi/blob/main/packages/codi...

[1] https://github.com/apple/container

MIT license.

You have an opportunity to be continue to be taken seriously like you have been so far.

Surely there must be some way to avoid mis-leading clickbait titles.

Separately, asking your fellow community-members to not bother, and that too with an unaffected shrug, just kills the conversation we would want to have with you.

I am a fan of Asimov and the three laws of Robotics. Itlooks like in OpenAI's world, the three Laws of Robotics would be added later if they were to develop the positronic brain. It may also explain how US Robotics from Asimov's books would have been able to design Robots that only partially adhered to the 3 laws (e.g. the robots in iRobot - the book - which were programmed to allow a human to come to harm through inaction so that the humans could complete their work on the plains of Mercury).

I'm going to take a look.

I find it acceptable to allocate tax money for a system that we as a country can use as an alternative to the Visa and MasterCard duopoly. With UPI as it is today, there are no margins added and passed to the customer, no transactions that are denied, no commissions cut. Payment is very fast, transactions can be proven. We are not at the mercy of any economic attack that the US would subject us to. Many are able to bank, are able to receive payments.

I find it not necessary that the UPI must show a profit. The direct and indirect benefits to the nation are far more important.

Also, "whataboutism" does not help. The suitcases and paintings and other such corruption examples that you cite require a separate investigation and redressal. One must not stop UPI or start charging the everyday person because some of the rich are corrupt. They will continue to exchange suitcases of cash for favours regardless of whether the UPI is chargable or if it even exists.

When a ZFS snapshot is marked, then changes to existing blocks in the snapshot as well as new writes all go to free space in the disk. There is no pre-allocated space within which these COW changes are written to.

Thus, we could have a single ZFS snapshot marked today followed by years of data being written to. This is not the intent of an LVM snapshot and the warning that I had quoted above is worth reviewing once.

ZFS snapshots use Copy-on-Write differently and have no such allocated space limit. Thus, we can do interesting things like snapshotting a file system after an OS is installed, and then roll back to that snapshot upon an OS upgrade failure, or even clone a new file system from that snapshot to have a different copy of the OS.

Essentially, the nature of the snapshots are different in both.

[1] https://docs.redhat.com/en/documentation/red_hat_enterprise_...

I would request the author to consider something that does not distract us from this educational and informative website ( I have bookmarked it ).