Adrian Cochrane @alcinnz@floss.social

I need to build libgccjit so that I can try out the native-compilation in Emacs.

I learnt that OpenBSD maintains its own fork of GCC. I tried and failed after many attempts to get the mainline GCC compiled.

What's the easiest way in which I can check out a particular version of OpenBSD's fork of GCC compile libgccjit and install it. I'm guessing if I want a particular version of GCC I need to checkout a particular version of OpenBSD...

#emacs #openbsd #gcc #jit

what does it take (in terms of hosting) to make my own #gemini capsule ?

In constructor theory a stricter conception of universality is possible, because when a
programmable constructor is programmed to mimic another constructor C, it may begin by constructing an instance of C, to which it directs subsequent inputs, so that from then on it performs C’s task using much the same resources that C would. (Deutch 2012)

One of the most glaring shortcomings of the Turing Machine as a conception of universal computer is that it doesn't self-replicate. Since it's self contained, it's obvious that the whole - the head and the tape - cannot be contained in the tape some. A Turing Machine could emulate a Turing Machine ad nauseum, but it isn't self replicating unless it breaks sandbox and writes to the tape of its parent machine. Since we clearly do have self-replicating systems, the Turing Machine doesn't describe computing in a universal way

The basis of constructor theory is that there are counterfactuals, things which are intrinsically true about what can or cannot occur in the universe. Since a constructor can only act on the possible state changes, no property of the constructor is essential to understand the universe, but the universe with its counterfactuals is the substrate on which the constructor operates. This improves understanding of computing provides a basis to reason about agent-based modeling and other patterns that frequently do exist, but that can't be derived from the nominal foundations of our existing theory

Interesting to come across this from 2012: https://gizmodo.com/googles-broken-promise-the-end-of-dont-be-evil-5878987 Turns out, society loses respect for those who fail to live up to their stated principles. And fair enough too.

#GavinMueller puts forward the case for the Luddite strategy in the labour movement in this excerpt from his book 'Breaking Things at Work: The Luddites Are Right About Why You Hate Your Job':

https://logicmag.io/commons/decelerate-now/

#LabourMovement

This thought brought to you by discovering Android Native Development Kit and my stomach giving a horrible lurch and saying "welp, here we all go again".

Even though its been out since 2009.

But Augmented Reality seems like a use case that really wants lots of performance and so....

It's a glorious circle of life. Native, Managed, Native, Managed, back to Native again...

https://developer.android.com/ndk/guides

@alcinnz

And it's probably back up to two VMs now, what with "Javascript" plus also "WASM".

@alcinnz

Yep. We now trust the browser to be both Java and Flash for some reason.

I guess at least having only one virtual machine to exploit rather than three makes the attack surface a little smaller? But I'm not sure that that's true.

1997: With enough eyeballs, all bugs are shallow.

2021: With enough eyeballs, all human relationships are shallow.

Back in 2010 I submitted a conference paper called 'Free to Know or Free to Own', in which I referenced Kirkpatrick Sale's re-examination of the Luddites, and suggested that interventions like the software freedom movement could be seen as digital era Luddism. 10 years later, it seems Sale is not the only writer celebrating the Luddite legacy and I'm not the only one suggesting it has contemporary relevance:

https://www.currentaffairs.org/2021/06/the-luddites-were-right

#Luddites #KirkpatrickSale

It wasn't even "proprietary code" because the Java Applets security disaster continued and accelerated long after the code was open-sourced and many eyes began making the bugs shallow, as the myth goes.

Do we still believe that many-eyes thing?

But I think we still don't know what that thing was that we did.

And I don't think the industry really cares about finding out.

Probably because whatever that thing was that we did that we shouldn't have, that killed Java Applets, we're still doing it today.

But, we still keep wanting that super fast efficient code, and so we keep thinking "well just this once, I'll compile to native code, it'll be just this one extension, it'll be fine..."

sigh.

I want there to be a whole big industry-wide Truth and Reconciliation Commission just on how the Java web plugin became such a security nightmare, when it was for a "managed" and "memory-safe" language.

I mean how do you screw up that badly? We should find out, and we should not do that thing next time.

Ideally, no machine of any kind would ever run raw machine code. Because raw machine code just isn't safe. I don't know why but we've just never managed to do that and we should probably stop pretending that anything at (Intel/AMD compatible) CPU level could ever be made safe. We keep adding more and more opaque and sprawling CPU-level hardware to do a thing that maybe just is not possible under our current designs.

I don't even think that threaded Forth words could ever be made truly safe.

Linux Live USB arriving in 3, 2, 1...