Atomic nuclei are matter. Disassembling and reassembling atomic nuclei, however, is an entirely different beast (several orders of magnitude difference in energy) than disassembling and reassembling molecules.
Which is why we should stop dreaming about it and stark working on things that are feasible with our technology. Mass drivers, launch loops, laser propulsion, you name it.
Venus won't be of much use until we can disassemble and reassemble matter itself.
Actually, we don't need anything that exotic (matter generation) for starters. We need a universal chemical synthesizer, which can assemble chosen molecules from a set of given input compounds. Basically a very flexible chemical plant. It doesn't need to create matter, just rearrange given molecules into new molecules.
Some parts of it are. The higher your altitude, the less sulphuric acid you'll find.
Planets are just too darn hard to get on and off of.
Only if you use primitive launch technologies which require the ascent vehicle to carry all of the necessary energy and reaction mass for the ascent.
Seriously, you think that in your scenario, we'll still use rockets as the main way to get off planets?
The first thing we need is one or more ways to launch things into space where most of the energy and reaction mass is not carried by the launch vehicle.
None have proper gravity or pressure for us.
Venus could be cooled down with a solar shade in space (which could double as a power plant) and be transformed into something more habitable than its current state.
Also, some applications work in a wide range of gravity. You can have fairly normal kitchens, bathrooms, swimming pools, showers, sinks and toilets on Mars, despite only having a third of the gravity of Earth.
Err, I didnt?
The correct relationship is an inverse-square-distance (1/(d^2)) relationship. Compared to Venus, Earth is about 140% of Venus' orbital radius from the sun (and therefore gets 1.4^2 the solar irradiance) and Mars is about 240% farther from the sun (and therefore gets 2.4^2 the solar irradiance).
The numbers in the article give an inverse (not squared) relationship, which would be correct for distances, but not for solar irradiance.
Photons shouldn't be affected by magnetic fields. And the numbers given in the article correspond suspiciously well to an inverse-distance relationship.
Balloons are neither dirigbles, nor dirigible. They just provide buoyancy.
Or a sauna. On the plus side, you get plenty of solar power to run your AC with.
Plus, it would be a "first".
C doesn't really guard anything. It does keep you from having to roll your own multiword arithmetics or integer division algorithms, and from dealing with architecture-related things that are mind-boggling for a human, but just another set of rules to a compilers (pipelines, delayed instructions, etc.), and takes over things like optimizing register usage.
On a computer, all the guides come at the cost of performance. Sure, you can make a programming langugage where buffer overflows are alway caught, but that language will spend a lot of CPU cycles on checks.
And there's also plenty of ARM chips that don't run Linux (because they can't due to lack of a MMU), e.g. Cortex-M0...M4-based parts.
That's one of the nice things about small target embedded work. It covers everything from 8-bit to 32-bit, from simple (no hardware multiplier, no division in hardware) to loaded (hardware floating point support, MAC units, HW dividers), from slow (temperature logging) to fast (control loop running at 30 kHz requiring 3us latency).
Well, not really. There are some architectures that were basically designed to be used with C (68k, ARM), but there are others (8051) where a C compiler need to jump through some major hoops.
And the C compiler still shields the programmers from things like stack frames or worrying about CPU register allocation.
To clarify: "Small target" means memory (RAM/Flash) is measured in kB, sometimes even in bytes.
You still have Python-capable processors for embedded systems if you can't afford to learn C.
As far as target size goes, that thing does not qualify as "small target".
FWIW, I've been struggling with LPC4300 series processors.
Those chips look like they're on the large end of "small target". Cortex-M4s are already pretty beefy CPUs.
The open source toolchain is just so bad that your CPU hard faults on first attempted function call (most likely due to incorrect memory maps).
You can usually get pretty detailed reasons for a hard fault if you dig into the appropriate CPU registers (HFSR, etc).
I'd check the linker command file. Setting up a basic memory map isn't that hard - it's the not-so-basic stuff where things get interesting (copying functions to RAM for execution, etc).