We're not talking about an air ship where you can take a leisurely stroll on the pool deck admiring the Venetian sunset. We're talking about a space ship that is suspended in a convection stove.
Or a sauna. On the plus side, you get plenty of solar power to run your AC with.
The article states that Venus gets 40% more solar irradiance than Earth and 240% more than Mars. I wonder where these numbers come from. From the inverse-square law, Venus would get about twice the solar irradiance of Earth, and about four times the irradiance of Mars...
The airship idea is a great idea. Not with astronauts (there wouldn't be much to do for them, unlike on Mars, where they could look at rock formations, dig holes and play golf), but a robotic airship would get a much closer look at Venus than any satellite.
Hmm... upon reading my comment, I realize that C *IS* guides
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.
BS. Embedded development still happens on 8-bit controllers
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).
I found that compared to having separate files for functions in assembly (that are then called from C), inline assembly is usually more hassle- and bug-prone.
C is important because it directly presents the actual machine memory model.
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.
Depends mostly on compiler and toolchain availability on those platforms.
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).
Football wasn't always played in full body armor.Perhaps it's time to redesign based on a scientific understanding of the risks and how to mitigate them.
It's actually very simple. The brain is soft. The skull is hard. When the two collide due to the head experiencing too much acceleration, it's easy to guess which of the two will be damaged more.
The are dozens of types of sport that don't involve the participants head and neck experiencing large forces as a normal part of the game.
RFID, chips, cards, etc. have the SAME "problem" as IP addresses: they don't identify the PERSON, they just identify the identification. If someone else is holding the identification, all bets are off.
The author of the article mentioned using a simple login/password, but rejected the idea because it was too much hassle - not because someone else could use the login/password combination. This means that the employees can be trusted not misuse their credentials.
They could. In fact, a space probe on a trajectory that will not get anywhere near Earth within the nex 30k years is probably the closest thing to a safe place for a nuclear reactor that we can find.
The Soviet Union launched some reactor-powered radar satellites (RORSAT) that now sit in graveyard orbits. Some of them crashed, too.
No, it works by turning atoms into other atoms. What you do with the resulting heat and radiation is up to you. Whether you use it to drive a steam turbine, a Stirling engine or a thermocouple is up to you.
Slashdot Mirror
Or a sauna. On the plus side, you get plenty of solar power to run your AC with.
The article states that Venus gets 40% more solar irradiance than Earth and 240% more than Mars. I wonder where these numbers come from. From the inverse-square law, Venus would get about twice the solar irradiance of Earth, and about four times the irradiance of Mars ...
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).
I found that compared to having separate files for functions in assembly (that are then called from C), inline assembly is usually more hassle- and bug-prone.
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).
C is the high-level language there. If you want actual control over your target, you'll need to use assembly.
Not getting the TSA/DHS/ZXY treatment at the airport is worth a few hours of driving.
He was working for an oil company. Burning more gas means more profit for oil companies.
News at 11 ...
It's actually very simple. The brain is soft. The skull is hard. When the two collide due to the head experiencing too much acceleration, it's easy to guess which of the two will be damaged more.
The are dozens of types of sport that don't involve the participants head and neck experiencing large forces as a normal part of the game.
Then don't play football.
Avoidable brain damage is stupid. Avoidable mechanical brain damage twice so.
... they should return their "security expert" certification.
The author of the article mentioned using a simple login/password, but rejected the idea because it was too much hassle - not because someone else could use the login/password combination. This means that the employees can be trusted not misuse their credentials.
Can't you just (wirelessly) scan an ID card/badge?
History disagrees with you.
http://en.wikipedia.org/wiki/B...
Not really. That far from the sun, the human eye would not get enough light to capture an accurate image.
Send the best instrument: a Mark I Eyeball.
Darwin says it's actually the latest iteration in a line of millions of eyeballs.
And AI is to biological intelligence what airplanes are to birds.
"Oh, your product is so secure that our services can't crack it? Well, then you can't sell it here, and possession will be made illegal."
And since you can't find enough of these atoms in nature, you'll need to produce them ... by turning other atoms into these atoms.
They could. In fact, a space probe on a trajectory that will not get anywhere near Earth within the nex 30k years is probably the closest thing to a safe place for a nuclear reactor that we can find.
The Soviet Union launched some reactor-powered radar satellites (RORSAT) that now sit in graveyard orbits. Some of them crashed, too.
No, it works by turning atoms into other atoms. What you do with the resulting heat and radiation is up to you. Whether you use it to drive a steam turbine, a Stirling engine or a thermocouple is up to you.
... what size RTG do you want to stick on it?