GNU Hurd 0.6 released

If all-bits-zero is such for pointer (which is implementation-defined, not undefined), the effect of memset() will leave you in a state where if (p) will, indeed, trigger undefined behaviour. Conversion from integer is unrelated - it's not required to produce the same value and it _can't_ produce a trap representation by definition - its result is not a stored value of an object at all.

Processor traps are only tangentially related to that - basically, implementation is not required to avoid them (or any other behaviour) in such situation. And on sufficiently weird architecture it might make sense to declare all-bits-zero to be trap representation for pointers in order to avoid serious overhead.

Rust shows that it's possible to prevent use-after-free bugs in the language without requiring GC, in almost all cases.

We've learned a lot about language design, compile-time checking and optimization over the last 30 years, and at the same time hardware behaviors have become a lot less diverse; you don't see non-2's-complement machines anymore, or machines where "char" isn't 8 bits, or machines where NULL isn't all zero bytes, and even big-endian hardware is on the way out. This means we can now have languages that are just as fast and portable as C, but eliminating most or all of the undefined behaviors.

In fact we have..considerable evidence..that Einstein's intuition with regard to quantum mechanics was flawed. He hated the theoretical QM concept of "spooky action at a distance".... otherwise known as quantum entanglement.. the very concept utilized in current applied research into quantum crypto and quantum computing. Einstein thought quantum entanglement impossible. It's been experimentally confirmed to happen and we are now even starting to build physical applications which rely on its existence to do useful things.

Einstein was wrong, God plays dice. I had a nice chat with him at the craps table at the Tropicana in Vegas while I was at CES in January. Nice guy.

And you have the experimental proof and evidence logic sort of backwards. Not seeing the Higgs particle is not proof that it doesn't exist. Creating a Higgs particle, like all nuclear reactions.. in inherently a game of dice. You smash some fast moving particles together, with enough energy, and very rarely, you get a Higgs particle pooped out of the collision. So its a game of dice... a handful of 1 billion sided dice....and you are looking to roll the 1 billion sided dice equivalent to snake eyes.

Under certain conditions, there a finite probability that a particular nuclear interaction will produce a Higgs boson. Under certain other conditions the probability of it happening is different. The probability of a Higgs boson...its nuclear cross-section... is theoretically quite small even at the high energy of our biggest collider. The LHC was designed to produce enough energy to make sure the target particle mass as predicted by the standard model was obtainable. But really, how many collisions would be needed to be done to observe a Higgs particle was effectively unbounded beyond being able to say it was a highly unlikely outcome of for any collision.

Highly improbable things are hard to produce experimentally. So to produce a Higgs boson, you smash things into each other again and again and again hoping to see the improbable happen. Einstein would have thought the entire concept of experimental particle physics insane. Here let me quote Einstein again... "The definition of insanity is doing the same thing over and over again, but expecting different results.” But that is exactly what particle physics experiments do. Do the same bloody thing over and over again...expecting different outcomes with every throw of the dice..err i mean accelerated molecular beams.

As it stands... with Higgs production cross-sections at picobarn levels (that's a super tiny nuclear cross section btw). .. it took trillions of collisions in the LXC to reach the previously agreed on levels of statistical significance..to be able to claim experimental validation of the existence of the Higgs particle being observed amongst all the other much more probable nuclear interactions resulting in similar particle relativistic mass. Though designing experiments like this with open ended number of trials until you reach a desired significance level is a nuanced problem with frequentist approach to probability.

<cut and past standard Bayesian inference rant here>

If they had just performed a measly billion collisions it would not have been validation that the Higgs particle did not exist, but it wouldn't have been proof of non-existance either. Highly improbable things are not disproved just because you don't see them happen in your finite set of observations.I do one smashing experiment and if I don't see a Higgs particle.. I don't get to claim it doesn't exist. All I can say is that its not guaranteed to be produced. If I run N such experiments, for any value of N and don't see it all I can claim is that if it exists, I just put a bound on its nuclear cross section.

When you don't produce enough Higgs boson observations to reach statistical significance within a certain regime inside a specific number of experimental runs..you've just reduced the probability bounds of being able to produce it. But you haven't proved it doesn't exist. You'd have to repeat the experiment an infinite number of times to _prove_ that the higgs boson does not exist. Infinity and beyond!

The lack of existence of something, is generally quite difficult to prove. Not experimentally seeing it is not proof. Just like the lack of affirmative results in experiments designed to look for CPT violations currently going on do not prove that CPT violations do not occur. These CPT null results just set tighter bounds on CPT violations if they are occurring. Should all those CPT violation experimenters just pack it up and give up hunting for it?

In a Curry–Howard isomorphism types correspond to formulae. Type inhabitation correspond to provability. A function returning value of type X and terminating in finite amount of time corresponds to a proof of a formula X. E.g. having a function you have a proof, having a proof you have a function.

When a type system is simple the fact that type is inhabitable is not very exciting. But when a type system is complex the problem of inhabitability of type is not trivial.

> If you don't mind my saying, that feels like a massive cop-out: "all programming is math, except for programs that interact with the real world". That's so trivial as to be useless.

But that's the point. A program is A LIST OF INSTRUCTIONS. It's symbolic, abstract. The data you feed into the program is A BUNCH OF NUMBERS. It's symbolic, abstract. IT'S ALL MATHS.

Feed that program, that data, into a physical computer, that carries out those instructions, and you have your interaction with the real world. The *instruction* "print a 0" is maths. The machine that does it, is not.

Start at the very beginning. Let's draw a distinction between the symbol and the meaning. Let's cut out a cardboard "P". You've just cut out the letter "pee", haven't you? Actually, no, you've cut out the letter "ar"! Okay, cut out a "B". You've just cut out the letter "vee". Our Eastern European members will know exactly where I'm going :-) Mathematics is the manipulation of meaning. We don't care what the symbols are, so long as they're consistent. Does "2" "0" mean 20, or space? The computer doesn't give a monkeys, it's a symbol to be manipulated.

Let's go back to a very simple computer. It has three i/o interfaces, I'll assume they're punch tape. Input 1 reads a program tape. Input 2 reads a data tape. Output 1 outputs a data tape. Our machine reads "2" then "4" from the input data tape, and "multiply" from the program tape. It outputs "8" on the output tape.

Why paper tape and not a disk drive? Is it EBCDIC or ASCII? What processor is it, MIPS or x86 or SPARC? IT DOESN'T MATTER. And it doesn't matter BECAUSE IT'S MATHS. This *is* a Turing Machine. It's also the Arithmetic Logic Unit that you find inside a Central Processing Unit that you find inside what, in modern parlance, is known as a computer. Actually, if you have a person who can read the punch marks on the tape, there's no reason why it shouldn't be said person ... it just DOESN'T MATTER.

A modern CPU manipulates electric charges instead of holes in paper tape, but that's all irrelevant. That paper tape could then go to a machine that prints the number VIII, that is your i/o. Or as I said, someone could read the tape directly ...

When you're programming, you're manipulating symbols, be they variable names, instructions, whatever. Manipulating symbols according to logic is what maths is. A Turing Machine is an abstract machine that takes in a string of abstract symbols, carries out the instructions contained therein, and spits a string of abstract symbols out. A computer is a physical machine, that takes in a string of physical symbols, carries out the instructions contained therein, and spits a string of physical symbols out.

Your i/o occurs where your brain converts the logical symbols to physical symbols for input to the computer, ie the keyboard, or where your brain converts the physical symbols output by the computer into meaning in your brain.

It is hard to grasp, but you need to separate the meaning from the representation. It's why, from the mathematical point of view, a load of pits in a CD are THE SAME THING as a load of north and south poles in a .wav file on the hard disk are THE SAME THING as a bunch of + and - charges being fed to a soundcard.

(And it's why current patent and copyright law are such a clusterfsck because they're written by politicians who keep trying make distinctions between two different REPRESENTATIONS of THE SAME THING.)

And it's why, in the early days, it was perfectly normal for computer programmers to write programs when they didn't have access to a computer to run it. They would run it in their head, and many of these programs, when transcribed onto a computer, ran perfectly first time. TeX springs to mind as a likely example, and I know my first boss did exactly that, too. A program, is a string of logical instructions, is maths.

Cheers,
Wol

It contains data that's loaded onto a device. That is not kernel code, it's driver data.

The driver may execute some of the data, it may use it to define a state table, it may use it as config info, or it may be the 'hardware' definition of a fpga.

In no case is it code that executes as part of the kernel.

Now, why this data is deemed "EVIL" by some people if it's in the git tree where it can be changed/replaced by the kernel developers, but is "Good" if it's in a flash chip on the device makes no sense to many of us. The first case makes it easier for the user to replace it, and the data is exactly the same in either case.