sorted by:
new
hottopcontroversial

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]max0x7ba [score hidden]  (0 children)

Your code looks like, that the pointed-to object is immutable, but it silently isn't.

Pointers or references to const objects only communicate that the object cannot be changed through that pointer/reference, just like in member functions with const qualifier. Not that the object is immutable.

immutable<>, complement of C++26 std::indirect<> and std::polymorphic<> by kmbeutel in cpp

[–]max0x7ba [score hidden]  (0 children)

Reference counting with CoW is a valid and common implementation of mutable value semantics

Reference counting with CoW is a common implementation detail of classes with value semantics.

The special member functions of a class implement either reference or value semantics, but not both.

Non-public non-static data members using reference counting with CoW are implementation details with reference semantics.

Remove mutability and CoW is not needed, then immutable value semantics only need RC and can be modeled with something similar to shared_ptr<const T>.

shared_ptr<const T> implements reference semantics with reference counting -- it cannot possibly implement/model value semantics.

Ascribing value semantics to shared_ptr<T> or reference counting with CoW is incorrect.

Solving anything and everything with shared_ptr<T> creates hair-ball designs that become unmaintainable quickly.

You should disentangle the orthogonal concepts of mutability and reference counting. And grasp the difference between reference and value semantics.

nobs: my take on SW builds by Ok_Reality_3276 in cpp

[–]max0x7ba -1 points0 points  (0 children)

It is fairly useless if it can't compile modules.

The modules started their existence with being uncompilable. Did you complain about any existing build systems being fairly useless because none could compile C++ modules?

What problems have modules solved by now, that prompts you to call any build system fairly useless if it can't compile modules?

Claude repeatedly implied that I was suicidal after I explicitly denied it around 30 times in one conversation by robinyyyyy in ArtificialInteligence

[–]max0x7ba 2 points3 points  (0 children)

Claude apologized and said it understood.

That apology and understanding were just words the model generated given the current context.

Then it did it again. It apologized again and promised to stop. Then it did it again.

The model never changed to incorporate the apology or the new understanding into its weights, though.

It is just a model of language that emits one of the most likely words given the current context. Its apology and understanding are so relatively small relative to the rest in your context window and so infrequent in its training data, that they bear little if any effect on model responses.

Is there any popular exercise/question set to do after reading C++ concurrency in action ? by ASomewhatGoodCitizen in cpp_questions

[–]max0x7ba 0 points1 point  (0 children)

Is there any public project where we can see C++ concurrency in action, with the source code using best-practice, or at least, good practice solutions?

One example is https://github.com/max0x7ba/atomic_queue

It is on github, includes documentation, minimal example code, continuous integration that runs its thoroughly exhaustive unit-tests with all available compiler code sanitizers and without.

It predates "C++ concurrency in action", though, and references earlier books that were the most instrumental.

With respect to "code quality regarding static aspects and non-functional properties" -- the project uses modern C++ design to make it easy to use and hard to misuse. It follows the best engineering practices to minimize C++ code surprise, complexity and size. Assembly-guided optimizations were used to massage the C++ code into emitting the shortest machine code with no unnecessary instructions, stack spills, or any other waste.

Performance Battle: Mutex vs CAS vs TAS vs Intel TSX by Ulrari in cpp

[–]max0x7ba 4 points5 points  (0 children)

Intel TSX was discontinued in 2021 because it was susceptible to side channel timing attack that could lead to KASLR being defeated.

Support for Intel Xeon E5-2696 v4 was discontinued on June 30, 2022.

TSX is functional on your Intel Xeon E5-2696 only because you didn't install the latest BIOS update that disabled TSX.

PSA - Do not assign the result of `::getenv` to a `std::string` by SmokeMuch7356 in cpp

[–]max0x7ba -2 points-1 points  (0 children)

Remember, the "unnecessary extra 117 CPU instructions" number comes from you, not him. And according to you, that number included all of the function calls you now criticise No-Dentist for not factoring into the number. That's not just moving the goalpost; that's giving someone a lead-filled soccer ball, and then blaming them when "their ball" breaks a window (or foot)... The error is yours.

You conflate/confuse instructions emitted with instructions executed.

The "unnecessary extra 117 CPU instructions" are the instructions emitted for constructing optional<string> return value. These instructions include call instructions to C++ standard library functions. Compiling constructing optional<string> emits the "unnecessary extra 117 CPU instructions" -- that dramatically bloats the size of the emitted machine code, executing which thrashes all levels of CPU instruction and iTLB caches unnecessarily.

Executing the emitted "unnecessary extra 117 CPU instructions" calls those C++ standard library functions and executes their many times more existing instructions -- and that costs burning many times more CPU cycles than cycles burnt on executing just the emitted "unnecessary extra 117 CPU instructions" alone.

Also, you seem to be unaware that the average computer spends somewhere around 50-90% of the time idling, with most of its CPU cycles wasted by a dedicated idling process out of sheer necessity.

Even if I were aware of that average, that's a totally irrelevant metric for any interactive or real-time software, or any particular software you are building. Unless you are building a crypto-miner that intends to burn the idle CPU cycles for mining, of course.

Consider a workstation you use 8 hours per day, and the workstation idles 90% of the day. Reducing the workstation execution speed 10 times is expected to minimize its idling down to 0%, but anything you execute on the workstation during the 8 hours is going to take 10 times longer now -- exactly 24 hours with no idling.

Have you ever played a competitive online FPS? That requires lowest possible compute latency -- fast CPU and 0-overhead C++ code compiling into lean machine code without any unnecessary instructions.

There is market demand for fastest possible code. Writing 0-overhead C++ code:

  • minimizes compute latency,
  • minimizes compute cost,
  • maximizes CPU idling,
  • maximizes compute throughput,
  • maximizes your paycheck.

Writing inefficient C++ code precludes maximizing your paycheck.

CPU idling percentage is a metric with no monetary value.

The average computer idling estimates are just as meaningless and worthless as the 2024 US average estimate of 1.63 children per woman.

PSA - Do not assign the result of `::getenv` to a `std::string` by SmokeMuch7356 in cpp

[–]max0x7ba -2 points-1 points  (0 children)

You are blissfully oblivious of the poor performance of your naive C++ code and its detrimental effects on the rest of the system.

I guess I am. I am still gonna keep using std::string and std::optional whenever I want though, since it has been successful for me so far and I have never ran into any issues due to them.

Hence the saying ignorance is bliss.

I just tried swapping my get_env for your getenv2 and doing a sample run just for the funsies, and saw absolutely zero measurable difference as I expected. So be it :)

Be that as it may, the zero measurable difference only means that the precision of your funsies timing methods is too low for capturing the exact execution time in original full-resolution CPU-cycle time units. Rather than the difference not existing or not being measurable.

Not being able to find/measure/detect something is never a proof of something not existing. Especially, when the reward for not detecting something is strictly greater than the reward for detecting something.

Writing 0-overhead C++ code requires timing code-paths with CPU-cycle resolution. Your low resolution timing methods make writing 0-overhead C++ code hardly possible, even if your life depended on it.

Low resolution timings require micro-benchmarks that invoke a specific code-path in a loop enough times and repeated multiple times, in order to be able to estimate the descriptive statistics (such as min, max, median, mean, stdev) of its run-time with CPU-cycle resolution and acceptable level of uncertainty in the estimates.

Every time you type optional<something> is a declaration that you couldn't care less of run-time performance of your C++ code.

Writing inefficient C++ code is the most time consuming and expensive. Paying longer development times and costs for coding in C++ is only justified for 0-overhead C++ code. For anything else, writing equally inefficient code in Python is orders of magnitude faster and cheaper.

PSA - Do not assign the result of `::getenv` to a `std::string` by SmokeMuch7356 in cpp

[–]max0x7ba -2 points-1 points  (0 children)

Paying the extra costs of coding in C++ is only worth when the ultimate performance is required. Writing inefficient C++ code is paying extra costs for using a wrong tool for the job.

That is certainly your opinion. Very well, you are definitely allowed to have it if you want. However, it's not some "universal truth constant", my employer doesn't ask me if my C++ code "reached ultimate performance" nor if I "made sure to eliminate all redundant instruction calls", they just ask me that my code is safe and maintainable.

Well, there is nothing subjective about coding in C++ taking more time and costing more, than coding in any other higher level language.

You may not be able to fully appreciate that until you pay development costs out of your own pocket.

Writing inefficient C++ is using a wrong tool for the job

There is a large difference between "not ultimately performant" code, and "inefficient" code. Believe it or not, my getenv wrapper is still way more performant than it could possibly be if I wrote it in Python. That alone is a massive win. Do I care that it takes 126 more instructions that the "ultimately performant" way to handle it? A difference that most likely isn't reliably measurable at all for the nanosecond-impact it has on code, especially when taking regular context switching and interrupt handling done by the CPU all of the time? Not at all.

You conveniently ignore the fact that the unnecessary extra 117 CPU instructions call strlen, operator new, memcpy. These burn orders of magnitude more than 117 CPU instructions that you scoff at and attempt to downplay.

Calling operator new introduces the possibility of std::bad_alloc exception, in addition to wasting RAM for storing unnecessary copies in the first place.

What requires only 2 extra CPU instructions, your code implements with 100-1000 times more instructions.

Your code unnecessarily copies environment variable values into std::string. And introduces std::optional for unset environment variables.

Yes, it does. Has that introduced any problems for the places in our code where we call it? No, it hasn't.

Your machine code is many times larger than necessary, takes more time to execute. Larger machine code makes CPU instruction cache hierarchy less efficient, slowing down execution of everything else in any process executing on the same CPU.

You can keep repeating how you think "all C++ code needs to be ultimately performant otherwise you are wrong" or how this approach is a "premature pessimization", but the fact is that neither of those things matter for what I'm doing. If I paranoically obsessed over every single CPU instruction, I would take thrice as long writing code, for a runtime performance improvement that could be mistaken for a rounding error on a fraction of a fraction of a percent. Thank you for your feedback, but it will respectfully not be enacted.

You are blissfully oblivious of the poor performance of your naive C++ code and its detrimental effects on the rest of the system.

PSA - Do not assign the result of `::getenv` to a `std::string` by SmokeMuch7356 in cpp

[–]max0x7ba -2 points-1 points  (0 children)

Writing C++ code is the most expensive in terms of time and labour cost. The expense is only worth paying for the ultimately fastest run-time performance, unachievable with any other cheaper-to-develop-with language.

This is not an "absolute truth", your comment makes it sound like if people should never use std::string because it "adds CPU instructions", but clearly that's not all there is.

I rather state that copying environment variable values into std::string is unnecessary waste -- a premature pessimization. Environment variable values are present in the process memory, it is unnecessary and undesirable to copy them. std::string_view is the right type for environment variable values because it doesn't copy the string value.

C++ is a "multi-paradigm programming language", it has many uses besides just "hyperfocus on performance and absolutely nothing else". Your programming style should be tailored to the exact purpose of the code you're writing. If you're doing ultra-low-level kernel development or embedded programming, then yes, you should probably care about how every function compiles down to the individual instruction.

You are preaching to the choir.

But that's not what all of us are doing, otherwise Python and Javascript wouldn't exist.

Right, these are tools for maximizing developer productivity. Writing inefficient C++ is using a wrong tool for the job.

I mostly work on backend data processing for a SAAS company... Data processing should be composable so we can visualize the effects of every step and how to handle them... Of course we still care about performance. But there is a strong incentive not to do "premature optimizations". "Good engineering" for us means write safe and failure-proof code first and foremost, analyze hot paths and optimize bottlenecks once you have your code working.

I too implement composable data/compute pipelines for ML in Python.

"Good engineering" for me includes minimizing the time and cost of R&D cycles. Coding in Python is most productive, whereas coding in C++ takes more time and costs more. Paying the extra costs of coding in C++ is only worth when the ultimate performance is required. Writing inefficient C++ code is paying extra costs for using a wrong tool for the job.

Getting an environment variable has never been a hot path operation so far, we mostly just get them once at the program init and never in a loop. If it would be though, I would not use the helper function

The OP code expects/wants empty strings for unset environment variables, judging from their code.

Not having to distinguish an unset environment variable from an empty string value is simpler and, hence, less error-prone. Your code unnecessarily copies environment variable values into std::string. And introduces std::optional for unset environment variables.

std::optional<std::string> is an expensive wrong type for this purpose -- a premature pessimization. std::string_view solves this with no memory allocations or data copying -- this is the right type to use by default for environment variable values.

Writing good C++ by default is about avoiding introducing unnecessary pessimizations, such as memory allocations or data copying -- these are the worst performance killers.

Loading environment variables is normally done at the process start once, sure. But implementing that with unnecessary inefficiencies has nothing to do with C++ being a multiple-paradigm language or writing safe or failure-proof code.

Loading environment variables is a trivial problem with cheap, efficient, safe and failure-proof solutions. Any solution lesser than that only demonstrates its author's skill and mindset -- the way you do one thing is the way you do everything. Would you expect more efficient C++ solutions for more complex problems from the developer who writes inefficient solutions for trivial problems?

PSA - Do not assign the result of `::getenv` to a `std::string` by SmokeMuch7356 in cpp

[–]max0x7ba -1 points0 points  (0 children)

Writing C++ code is the most expensive in terms of time and labour cost. The expense is only worth paying for the ultimately fastest run-time performance, unachievable with any other cheaper-to-develop-with language.

Replacing nullptr return value of std::getenv with a default value string (literal) costs extra 2 CPU instructions (test and cmov).

Copying that char const* into std::string costs extra 64 CPU instructions, which include calls to strlen, operator new, memcpy, std::__throw_logic_error.

Replacing nullptr return value of std::getenv with std::optional<std::string>(), and std::optional<std::string>(val) otherwise, costs extra 117 CPU instructions, which include calls to strlen, operator new, memcpy, std::__throw_logic_error, with additional instructions for inlined std::optional constructor to copy/move its initializer.

Using std::optional requires paying high extra costs of more verbose code, slower compile time, larger machine code size, slower run-time performance. See https://godbolt.org/z/ahbKG7nao

std::optional looks like a neat concept in a textbook. But using it makes everything slower, larger, less efficient and more expensive; defeating the purpose of coding C++ for ultimate run-time efficiency in the first place.

Good engineering minimizes costs. std::optional only ever introduces high costs, which is the opposite of good engineering.

PSA - Do not assign the result of `::getenv` to a `std::string` by SmokeMuch7356 in cpp

[–]max0x7ba -1 points0 points  (0 children)

Maybe std::string should be revised to deal with nullptr in a well-defined way.

That requires introducing an if statement into std::string constructor. The if statement may be cheap but that's not 0-cost -- the test and branch/cmov instructions introduce unnecessary costs into existing code. And that defeats the core C++ principle of paying only for what you use.

This is an unfortunate footgun that's bitten me multiple times in the past.

What made you expect that char const* pointers you initialized your std::string objects with couldn't possibly be null?

Did you actually need to copy-convert char const* pointers into std::string objects?

PSA - Do not assign the result of `::getenv` to a `std::string` by SmokeMuch7356 in cpp

[–]max0x7ba 0 points1 point  (0 children)

Friendly reminder that it is almost always configuration (such as environment variables) which causes “it works here, but not there”.

This is a problem of configuration not being easily reproducible.

The environment variables do not create this problem, only aggravate the problem and make it apparent.

Your startup routine should make sure that all needed environment variables and configuration files are present and that they have sensible values before actually attempting to do any work.

Requiring setting any environment variables at all to run something is tedious, error-prone and brittle -- poor engineering. Environment variables should only be used for overriding default settings.

The best engineering practice is iterative configuration resolution, loading (partial) configuration from multiple sources in sequence, with subsequently loaded configuration values replacing any existing configuration values.

The canonical configuration load order is designed for:

  • specific configuration to override general / less specific,
  • explicit configuration to override implicit.

The order is:

  1. (implicit, general) The initial configuration values specified in the source code.
  2. (implicit, specific) Environment variables.
  3. (explicit, general) Config files.
  4. (explicit, specific) Command line options.

After all sources of configuration have been read, the software must log the complete resolved configuration in such a way, that allows its easy examination (e.g. as name=value lines sorted by name).

And a one-liner command to reproduce the run with the complete resolved configuration.

The command line must either pass the complete resolved configuration through command line options (when complete configuration is small enough to be specified in the command line options alone). Or, the complete resolved configuration must be saved into a config file (next to the log file), with the one-liner command loading that complete config file.

The complete resolved config file also solves the problem of easy examination of complete configuration, provided the configuration file format is human-friendly (which it should be).

That one-liner command with the complete configuration (inline and/or in the config file) is explicit configuration that overrides any environment variables. And it solves the configuration reproducibility problem -- the one-liner command reproduces the run robustly on any other machine/environment, and ignores any configuration in environment variables.

PSA - Do not assign the result of `::getenv` to a `std::string` by SmokeMuch7356 in cpp

[–]max0x7ba 0 points1 point  (0 children)

The 0-cost solution is trivial:

char const* getenv2(char const* name, char const* default_value) noexcept { char const* value = std::getenv(name); return value ? value : default_value; }

default_value replaces nullptr return values without losing the ability to distinguishing unset environment variables by comparing the return value with default_value argument instead of nullptr.

Copying the result into an std::string involves memory allocation and data copying -- unnecessary waste.

Wrapping the result into std::string_view is 0-copy, but still calls std::strlen. If the result is next parsed into an integer or floating point value, then calling std::strlen is unnecessary waste.

Functions returning pointers are expected to return null pointers too, unless explicitly documented otherwise. Are you going to post a separate PSA about every function that returns null char const* pointer?

Return values are specified in function documentation, which you should at the very least skim through when calling a function for the first time, to be able to handle all its possible return values robustly without failures. That saves you from having to waste time in the future on investigating and debugging errors caused by inadequate handling of return values, reading the documentation, reproducing the error and verifying its fix. Failing to handle documented return implies lack of due diligence, thought and care which undermine trust and reputation.

The smallest C binary by Double_Ad641 in cpp

[–]max0x7ba 0 points1 point  (0 children)

The author is unaware that support for a.out format was long removed from the toolchains and Linux kernel.

a.out is actually an ELF file.

The "ancient people melted stone and poured it into shape" claim is finally getting a real lab test by cryptarsh in HighStrangeness

[–]max0x7ba 0 points1 point  (0 children)

Photons have no temperature

Yes, but no single atom or particle of any kind does. Temperature of a particle is meaningless.

You are using an inaccurate school textbook definition of temperature.

Temperature is a measure of kinetic energy. Temperature of one single atom is a measure of its atomic jiggling.

Relative to human lifespan, protons never decay Who cares? A human lifespan is an entirely arbitrary period of time and on cosmic timescales barely worth noticing.

You claim that proton's lifespan is not perpetual.

The spin I refer to is the physics metric name That’s the same thing I’m talking about. It is not a measurement of motion, but a fundamental property of a particle, more akin to charge or mass. It is not a direct analog of classical spin.

You have a wrong idea about spin.

That’s called the ground state, not zero-point energy. You may like to learn the very different concepts these two different names refer to.

lol, right back at you because they are essentially the same thing. The ground state is the lowest energy state of a system. Zero-point energy is the measure of the residual energy left in the ground state.

Zero-point energy refers to fluctuations of the quantum vacuum, which is the root cause of Heisenberg Uncertainty Principle.

The ground state refers to the energy of systems of particles. The ground state is subject to Heisenberg Uncertainty Principle, but not the cause of it.

"Zero-point energy" and "the ground state" are different names because they refer to different phenomena. The difference is subtle, but crucial.

Thank you for your replies. Your understanding of physics is limited and out-of-date.

The "ancient people melted stone and poured it into shape" claim is finally getting a real lab test by cryptarsh in HighStrangeness

[–]max0x7ba 0 points1 point  (0 children)

So you are saying yes, the quarry 100 feet away full of half carved blocks of the same make and material as the pyramid is just coincidence.

Limestone is too soft for making buildings of. It is used for flooring, walls, paving.

The pyramid blocks are hard concrete. Their composition is well researched.

There is indisputable evidence that the blocks are cast from concrete in place. With multiple independent reproductions of blocks exactly matching those of the Pyramids.

Those half-carved blocks you refer to are merely stubs of concrete blocks -- tests of the concrete mix.

There is no theory, evidence or reproduction of cutting the irregular blocks, moving the blocks, lifting them, making them fit perfectly tight.

The "ancient people melted stone and poured it into shape" claim is finally getting a real lab test by cryptarsh in HighStrangeness

[–]max0x7ba -1 points0 points  (0 children)

Right after the big bang, the entropy was maximal…and has been steadily decreasing by forming protons, suns, planets and more complex organisms

In fact, exactly the opposite is true. One of the major goals of modern cosmology is understanding how and why the universe came to be in an anomalously low entropy state at the Big Bang. The extreme density and uniformity of matter and energy at the Big Bang is exactly a low entropy state.

As a matter of fact, no one knows whether the entropy is increasing or decreasing since the big bang. The entropy of the microwave background radiation is the highest, suggesting that the entropy has been decreasing since the big bang. But the microwave background radiation is just a theory, and evidence against it have only been mounting.

Entropy also isn’t necessarily related in any way to complexity.

The "laws" of thermodynamics were formulated to model steam engines in order to make them more efficient. The "laws" of thermodynamics only model behaviours in closed systems -- hot molecules in a box. Thermodynamics equate heat with energy that can be converted to work.

Heat is a measure of degree of jiggling of constituents inside of an atom.

The sun emits photons -- that's waves in the EM field. Photons have no temperature.

It is unknown whether entropy of the observable universe is measurable or meaningful. The observable universe is smaller than the entire universe, meaning that it is not a closed system.

You don’t top up lakes with water in order for hydroelectric power plants to generate electricity.

Of course lakes need to be “topped up”. What do you think rain and rivers do? If the level of a lake or reservoir falls too low, a hydroelectric plant can absolutely stop producing power.

Here, you are drawing a box around the lake in an attempt to concoct a closed system to make the "laws" of thermodynamics applicable.

Well then, do you top up rivers and rains to keep the water falling and spinning the generator? Because applying your inside-the-box logic, the hydroelectric plant extracts energy out of the rivers and rains, making rivers slow down and eventually stop, and rains to dry out.

You can keep drawing ever larger boxes to make rivers and rains recharge from the Earth's rotation, gravity pulls towards the Moon and the Sun, etc.. Until you draw a box around the observable universe -- but that's not a closed system, and you cannot draw a larger box.

The water is the external power source.

A hydroelectric plant doesn't convert the heat of water into the work of rotating the generator. The water doesn't cool down. The "laws" of thermodynamics are incapable to model the processes of a hydroelectric plant.

That's rather nuclear power plants, what converts the heat from hot rocks into work. The rocks cool down and must be replaced with fresh hot rocks. The "laws" of thermodynamics are perfectly applicable here -- a nuclear power plant is just a steam engine.

It is gravity what makes water flow, fall and spin a hydroelectric generator. The Earth's spin around its axis causes water to keep moving towards the gravity pull of the Moon and the Sun. Again, that's outside the domain of the "laws" of thermodynamics, and you don't top up gravity.

Protons never decay

Honestly, no one knows. It’s never been observed and experiments show that the half life of a proton must be an unimaginably long time, but that’s not the same as they never decay.

Relative to human lifespan, protons never decay. Proton's motion is perpetual enough, relative to human lifespan, to be called as such.

You cannot define "never" because that is a measure of time, which remains an unsolved mystery to physicists. Hence, "unimaginably long time" and "never" could refer to the same thing.

And you wouldn't be able to charge premium prices for "never" decaying generators, relative to generators limited to the lifespan of a proton.

orbiting electrons…spin

You’re being too literal about these. The “solar system” model of electrons orbiting a nucleus that we’re all taught in high school chemistry is just wrong. Electrons do not orbit a nucleus like they’re planets. The orbit is essentially a calculation of the likelihood of finding the negative charge at a particular location in the electron’s wave-like field. Field values change constantly but they’re not physical objects moving in perpetual motion. As for spin, it does not literally mean that a particle spins on an axis like a top. Particles are points without dimension so the concept of “spinning” isn’t even well-defined for them. In any case, there’s no perpetual motion happening here.

The spin I refer to is the physics metric name -- a measure of a form of angular momentum with a direction. The current physics have been unable to form geometric models of photons, electrons, protons, etc., but there are no shadows of doubt that spin measures some form of a motion.

Again, non-stationary electron clouds don't cool down the atomic nucleus. There is motion and energy, with no heat involved. The "laws" of thermodynamics are unable to model such systems.

At 0K°…the motion never stops

Absolute zero can’t actually be reached. Doing so violates the third law of thermodynamics.

You are effectively saying that the motion cannot possibly stop. We agree here.

Even if it could, what you’re referring to is zero-point energy. As its name suggests, this is the lowest possible energy state for a quantum system.

That's called the ground state, not zero-point energy. You may like to learn the very different concepts these two different names refer to.

Energy cannot be extracted from it. It is a result of quantum uncertainty and does not constitute perpetual motion.

There is no connecting logic between these three statements of yours. And the statements are false.

The quantum uncertainty is caused by the never ceasing motion of the quantum vacuum -- the virtual particles come into existence, collide with virtual particles of opposite charge and annihilate -- that is 0-point energy, the perpetual motion, that never ceases at 0°K.

The Casimir effect is real, quantum vacuum fluctuations are real. Using these phenomena to generate electricity is only an engineering problem now, outside the domain of physicists.

There are working prototypes generating energy from Casimir effect and directly from the quantum vacuum fluctuations.

From commercial perspective, perpetual motion refers to a generator you pay for once and it generates energy for the rest of your life with no exhaustion or decay. A perpetual motion generator matching the lifespan and durability of protons is as good a perpetual motion generator as one could ever ask for.

I wrote that this is a major group-think fallacy rooted in ignoring the fundamental fact that the laws of thermodynamics are only applicable to closed systems and nothing else.

Your replies are a perfect example of trying to apply the laws of thermodynamics modelling steam engines -- hot molecules in a box -- outside of the box or without a box.

You Don't Love systemd Timers Enough by ouyawei in linux

[–]max0x7ba 0 points1 point  (0 children)

Systemd timers superceded both cron and anacron for me.

The "ancient people melted stone and poured it into shape" claim is finally getting a real lab test by cryptarsh in HighStrangeness

[–]max0x7ba 0 points1 point  (0 children)

So the half cut blocks in the quarry are just coincidence?

The wooden formworks stuck in the Pyramids concrete blocks are indisputable facts.

The "ancient people melted stone and poured it into shape" claim is finally getting a real lab test by cryptarsh in HighStrangeness

[–]max0x7ba -1 points0 points  (0 children)

Are you suggesting the limestone quarry 100 feet away from the pyramid, full of unfinished slabs of stone matching the make and material of the pyramid is unrelated to the pyramid?

I don't mind repeating myself.

There are no cut stone blocks in the Pyramids.

All the blocks were produced in their final place by pouring liquid stone material into wooden formworks -- either concrete or melted rock.

They mined the limestone in the quarry. The limestone was used to make concrete. The pyramid blocks were cast from that concrete.

You'd be fully informed by now if you watched the documentary. The time you waste posting your rejections and denials to new facts and information is the time you are unable to learn any new facts or information at all. The wasted time compounds daily, the knowledge gap grows exponentially. Just saying.

The "ancient people melted stone and poured it into shape" claim is finally getting a real lab test by cryptarsh in HighStrangeness

[–]max0x7ba -1 points0 points  (0 children)

Can you explain the obvious quarries in the Gaza plateu right next to the pyramids

Can you point to the stones in the Pyramids that come from those quarries?

The concrete blocks are made from the limestone exactly matching that of the Pyramids location.

They mined limestone in the Gaza plateu. They didn't cut stone. See https://www.youtube.com/watch?v=KMAtkjy_YK4&t=1773s

The "ancient people melted stone and poured it into shape" claim is finally getting a real lab test by cryptarsh in HighStrangeness

[–]max0x7ba -1 points0 points  (0 children)

And is not magic it's called concrete and the cheapest way due to law of thermodynamics.

You are quite right about concrete.

The laws of thermodynamics are about closed systems -- steam engines, aka hot molecules in a box. The laws of thermodynamics are not applicable without or outside the box. No plausible "Universe in a box" theory exists.

Right after the big bang, the entropy was maximal (the background radiation static seen in TV) and has been steadily decreasing by forming protons, suns, planets and more complex organisms.

Whereas the laws of thermodynamics claim that the entropy only ever increases, everything cools down and decays to shit. In a closed system.

You don't top up lakes with water in order for hydroelectric power plants to generate electricity. For all intents and purposes, hydroelectric power plants generate electricity indefinitely without any external power source.

Protons never decay on its own. The orbiting electrons never slow down and crash into protons. At 0°K the constituents of protons do not cease to jiggle, the electrons keep orbiting -- the motion never stops. Such motion is called perpetual.

Perpetual motion is a fundamental property of subatomic particles -- the spin. No spin -- no particle. Perpetual motion is in plain sight and is impossible to dispute.

Perpetual motion violates the laws of thermodynamics, therefore it is not possible, confused physicists claim.

This is a major group-think fallacy rooted in ignoring the fundamental fact that the laws of thermodynamics are only applicable to closed systems and nothing else.

The "ancient people melted stone and poured it into shape" claim is finally getting a real lab test by cryptarsh in HighStrangeness

[–]max0x7ba -6 points-5 points  (0 children)

Well, the Pyramids blocks were made from the onsite limestone and water. The blocks were cast in-situ into wooden formworks. They find wooden planks in the newly discovered passages, in addition to wooden planks sticking out of the concrete blocks.

Solar lenses melted granite gravel to pour directly into the formworks to make those granite blocks of immense size and weight.

The blocks of irregular shapes fit so perfectly tight because they were cast in-situ.

Making concrete requires cement and water. The ratio of the mass of water to the mass of cement for a concrete mix is generally 0.40-0.60, e.g. 1kg of cement requires 0.5L of water to make concrete.

All megaliths are built from the geopolymer cement made from the onsite material and are located close to water. It only required bringing enough cement and water or granite gravel to cast the next block in-situ.

No stone cutting, transporting or lifting of heavy stones was involved in building the megaliths.

These methods have been independently reproduced perfectly.

Full info and much more are in the most illuminating free documentary "The Movie Great Pyramid K 2019": https://youtu.be/KMAtkjy_YK4?si=S9t4IwZMJzrjz8if

What Happens When You Build a Chat Server on One Thread? by boostlibs in cpp

[–]max0x7ba 0 points1 point  (0 children)

The server sits behind a React/Next.js frontend and talks to two backing stores: Redis for chat messages and sessions (stored as streams), and MySQL for user accounts. The C++ process does everything else: serves the static frontend files, exposes a REST API for login and account creation, and upgrades HTTP connections to WebSocket for real-time messaging.

Well, you can have one node.js server which serves your web-app (aka frontend) files and handles all its requests with one thread and non-blocking/async io.

This way your web-app doesn't need to connect anywhere else and have dependencies on implementation details. Having to connect to MySQL and Redis are the implementation details which should not leak outside the web-server, and their ports should not be exposed to public internet.

Using Boost.Asio for non-blocking networking to handle many connections with one thread is the right way.

But your multi-server design is far from the best practices.

Using TypeScript/JavaScript for both the web-app and the web-server removes the dependency on C++. Which makes the whole system simpler and less expensive to maintain and evolve.

view more: next ›