Legal requirements on technology companies are often poorly written, and not actually sensible, as the lawyers involved may not properly understand the internet.
It's quite plausible that they used standard boilerplate 'Do not delete, modify, or...the file at http://.../ which could not reasonably be read as allowing them to be pulled offline, as that would be a modification.
If the vendors are in true free competition, arguably. The current vendors are basically not funded in general as rocket launch companies. They are funded as aerospace/military welfare organisations. Any launches that happen are a side-effect.
If your primary goal as a legislator is to get jobs for your constituents, it's quite easy to insist that technology X must be included in the vehicle - because you have a massive plant in your constituency doing X.
This does not result in good values for purchasers of the rockets launch capabilities.
"and on the fourth launch it lost an engine and couldn't deploy a secondary payload successfully and the mission was not a complete success." - a couple of points. Firstly, the secondary payload was launched on this basis, with the understanding it was not a guaranteed launch, for a reduced fee. Secondly, the rocket was actually capable of doing the secondary mission, but was prevented due to NASA rules precluding it. (The rules were there to eliminate even the theoretical possibility of the relit second stage hitting ISS. They were arguably a bit tough).
Reliability isn't everything. At some point, if you're a third the cost, even if you lose one vehicle in five, you start getting a lot more business.
To paraphrase part of TFA 'We can save money by developing X with components from Y', this is why it's cheaper to now spend money on Y.
Versus a clean-sheet design.
Combine that with SpaceX's largely integrated workflow, with minimal external contractors, and you have extreme problems for traditional aerospace to meet the costs.
Contracts are granted not on the basis of what would make the overall system cheaper, but electoral politics.
Current thoughts seem to be simply that the sun just happens to be one of the stars that flickers less. Most'sun-like' stars flicker more. Before Kepler, it wasn't really possible to measure stars brightness variation other than the sun to the levels required.
Flickering was probably a bad word to choose. Flickering of stars as observed by the eye (or ground-based telescopes) is utterly dominated by atmospheric effects. The phenomena Kepler is observing is brightness variations of the star on the level of seconds to hours.
As I understand it, the brightness variations between the popularion of near and far similar stars in the kepler field of view is similar. It's unlikely to be any effect of space.
Well - sort of. The aim of the kepler primary mission was to detect earth-like planets, in earth-like orbits, around sun-like stars. Unfortunately, as one of the scientists working on the project pointed out, an early discovery was the sun wasn't a sun-like star.
The sun turns out to flicker rather less than most stars in the sun-like population. This does unfortunate things when you're trying to pick the tiny, tiny signals of planets crossing the stars disks, as the noise swamps the signal. It means that it can't be picked up in the primary mission length, and you need longer integration periods - hence the extended mission. It's not to get more data than was intended, but to get back to the baseline that was assumed, before we realised that stars twinkle rather more than we thought.
(It will have the side-effect of picking up some planets in non-earthlike orbits that couldn't have been seen too - very tiny and very long orbit ones.)
The above points are of course true, to a degree. Many peoples expectations about hardware engineering are unfortunately lead by software engineering - the two fields differ dramatically. Is there a point in open-source hardware - of course! It makes deriving working designs a _lot_ easier. Does it make it easy - no. Small batch production of anything more complex than a 2 layer board (cellphones will need 8) with relatively relaxed component density is expensive and unreliable, especially when you're not doing this day-day, with proper equipment.
The same issue can occur with commercial code too.
It's basically a risk for any non-completely-free licence, including explicitly non-paid-for ones.
You can be put in exactly the same position by being accused by a commercial vendor of using their code. And the solution for the vendor is the same - sue for copyright infringement, and it'll come out if the code is infringing or not.
I should have stated it was copy-pasta. (But I am the original author). Is it useful - certainly - and lightly modifying an existing design without touching the core can give you considerable confidence that the design will work. Also, it can mean that you need limited or no software mods to get it booting, and confirm at least basic functionality, at which point you can start hacking on the drivers for your integrated cheeseboard.
Why open-source software works is: Widely available repository of code. Many people able to review it, or sections of it, and understand it. Ease of submitting tested patches.
Hardware has problems that don't really fit well with this. The open schematic is the trivially easy part, and not really a problem. (though in practice, you need a schematic with copious links to design documents, which isn't well solved by open tools).
The number of people who can review it is rather smaller - as you can't open up a c file, and see a clear error or awkwardness in code that can be edited.
For all but the most basic errors, you are going to have to sit down and read several hundred pages of hardware documentation about how the chips in question work, in addition to having in-depth knowledge about the circuit design, and costings of likely changes.
Now, you've done this, and generated a patch that you think (for example) lowers the supply current by 1%.
Compile - test. On a PC, this takes a couple of minutes.
For something of a smartphone class, a one-off PCB may cost several hundred dollars. Then the parts will cost another several hundred dollars in small quantities, as well as being difficult to obtain. Now, you have to solder the parts onto the board, which is a decidedly nontrivial thing - and if you decide you want someone else to do this, it's probably another several hundred dollars.
So, you're at the thick end of a thousand dollars for a 'compile'.
Now, you boot the device, and it exhibits random hangs.
Neglecting the fact that you are going to need several hundred to several thousand dollars of test equipment, you now have to find the bug.
Is it: A) The fact that unlabled 0.5*1mm component C38 is in fact 20% over the designed value, as the assembly company put the wrong one in. B) C38 has a tiny bridge of solder underneath it that is making intermittent contact. C) The chipmaker for the main chip hasn't noticed that their chip doesn't quite do what they say it will do, and the datasheet is wrong. D) You missed a tangential reference on page 384 of the datasheet to proper setup of the RAM chip, and it is pure coincidence that all models up till now have booted. E) Because you're ordering small quantities, you had to resort to getting the chips from a distributor who diddn't watch their supply chain really carefully, and your main chip has in fact been desoldered from a broken cellphone. F) Though the design of the circuit is correct, and the board you made matches that design, and all the parts are correct and work properly, the inherent undesired elements introduced by real life physics means it doesn't work. G) A completely random failure of a part that could occur with even the best design, and best manufacture.
G - may mean that it's worthwhile making two or more of each revision - which of course boosts costs.
Hardware is nasty.
This gets a lot less painful of course for lower end hardware. For very limited circuits, which can be done on simple inexpensive PCBs, and be easily soldered at home - costs of a 'compile' can be in the tens of dollars, or even lower.
The brain shifts in the skull, especially during impact. Any rigid strong wire risks being ripped out, as the brain stretches, or doing the cheese wire thing. Cheesewired brain is bad.
In principle, there are two trades to be made. With a smaller geometry, you can either go high frequency, or lower power. (both are of course possible). If 3D manufacturing became cheap enough, then we might see (for example) 2048 core 300MHz processors using a comparable amount of power to a 10 core 5GHz processor.
Openmoko screwed up by the numbers. (originally posted in 2009)
Openmoko dropped the ball in a big pile of manure, and then asked the community to lick it off.
A quick outline of the process - from someone who has been active in #openmoko on IRC forever, and bought the early version when I really could not afford it.
Openmoko is a perfect example of how not to do an 'open source - community involved project'.
Firstly, in march 2007 or so, we had a working phone with hardware available, with somewhat clunky but more-or-less usable basic phone and SMS. Battery life was not great - 12h or so.
Basic kernel stuff was unreliable - suspend diddn't work right, clock frequency changing diddn't work,...
Fix the kernel bugs, get the software 50% faster in 6 months, which is not implausible, and you could have had a phone selling for christmas 2007, that had a somewhat clunky phone, SMS, application, bluetooth working, you can play nethack on it (with an external bluetooth keyboard), run any X app, with a several day standby time...
One year before Android hit, and six months after the first iphone. Clearly it wouldn't have been as polished as the first iphone, but it would be a platform to hack on.
So, the logical thing to do at this point is of course to after no consultation with the community drop a different - though similar - software stack on the community, with no notice other than the CEO saying 'Something really cool is coming up!!!!!!!!!!!!!!!!!!!!!' at a conference some weeks before.
This software gets sort-of polished over the next yearish, with still the underlying kernel problems unfixed, and during this period new 'better' hardware is being worked on.
The new slightly evolved hardware arrives, and at the same time the CEO pops up saying 'Something really cool is coming up!!!!!!'.
And yes, another drastic software change with no notice - from X to Qt.
The kernel bugs are still not fixed, and worse, the new better hardware that was supposed to fix everything turns out to have a graphics accellerator that is at best usually a wash, compared to the earlier version with a processor with half the speed.
Shortly after this - another UI change - this time back to X, and an explosion of 'community' distributions, some of which mostly work.
And some of the kernel bugs are even fixed - but by this time openmoko-corporate has run out of money, at least to do phones, as a new model is going to take a large slice of a million to make a stab at developing.
There is even a gta02-core project - which is a community phone project based on the schematics. But, this again would require a large slice of a million for a 'real' launch.
And the elephant in the room is the n900 now. It makes users think 'For $150 more, I can get the n900, which does x,y,z,...', which is impossible to counter from a small production run as you don't have the margins to slash the price.
Openmoko-corporate never really talked to the community, which was a fundamental failing.
They diddn't say 'We are not working on a,b,c,d,e' - so of course people assumed they were, as they must be - they'd have to be insane not to...
So kernel bugs that made the device unusable went unfixed, and it all kind of went very very wrong.
Openmoko-corporate is now out of the mobile market - they are not employing any engineers on designing new phones or fixing the software stack. They are continuing to sell the hardware - but not even in a fully bugfixed form.
FPGAs are always going to be more expensive, and less power efficient for given tasks than comparable single function silicon. There is, even in the most efficiently implemented design in a FPGA, considerable area wasted by interconnects, and suboptimal use of resources.
It's like making a working device from lego. Yes, you may be able to do it, but if you make it as one moulded piece, it's going to be lots cheaper.
FPGAs are essentially not used in mobile phones, for power efficiency and other reasons. Nor is opening up the code for any hardware you can get source for (nothing) useful, as making your own chips from them will cost at best many tens of thousands.
This is totally ignoring the software and patent problems.
To elaborate on why open-source hardware is hard, and why making a single phone will cost you over $10K.
Why open-source software works is: Widely available repository of code. Many people able to review it, or sections of it, and understand it. Ease of submitting tested patches.
Hardware has problems that don't really fit well with this. The open schematic is the trivially easy part, and not really a problem. (though in practice, you need a schematic with copious links to design documents, which isn't well solved by open tools).
The number of people who can review it is rather smaller - as you can't open up a c file, and see a clear error or awkwardness in code that can be edited.
For all but the most basic errors, you are going to have to sit down and read several hundred pages of hardware documentation about how the chips in question work, in addition to having in-depth knowledge about the circuit design, and costings of likely changes.
Now, you've done this, and generated a patch that you think (for example) lowers the supply current by 1%.
Compile - test. On a PC, this takes a couple of minutes.
For something of a smartphone class, a one-off PCB may cost several hundred dollars. Then the parts will cost another several hundred dollars in small quantities, as well as being difficult to obtain. Now, you have to solder the parts onto the board, which is a decidedly nontrivial thing - and if you decide you want someone else to do this, it's probably another several hundred dollars.
So, you're at the thick end of a thousand dollars for a 'compile'.
Now, you boot the device, and it exhibits random hangs.
Neglecting the fact that you are going to need several hundred to several thousand dollars of test equipment, you now have to find the bug.
Is it: A) The fact that unlabled 0.5*1mm component C38 is in fact 20% over the designed value, as the assembly company put the wrong one in. B) C38 has a tiny bridge of solder underneath it that is making intermittent contact. C) The chipmaker for the main chip hasn't noticed that their chip doesn't quite do what they say it will do, and the datasheet is wrong. D) You missed a tangential reference on page 384 of the datasheet to proper setup of the RAM chip, and it is pure coincidence that all models up till now have booted. E) Because you're ordering small quantities, you had to resort to getting the chips from a distributor who diddn't watch their supply chain really carefully, and your main chip has in fact been desoldered from a broken cellphone. F) Though the design of the circuit is correct, and the board you made matches that design, and all the parts are correct and work properly, the inherent undesired elements introduced by real life physics means it doesn't work. G) A completely random failure of a part that could occur with even the best design, and best manufacture.
G - may mean that it's worthwhile making two or more of each revision - which of course boosts costs.
Hardware is nasty.
This gets a lot less painful of course for lower end hardware. For very limited circuits, which can be done on simple inexpensive PCBs, and be easily soldered at home - costs of a 'compile' can be in the tens of dollars, or even lower.
One problem. Even assuming this is correct, we don't have that long. Sometime around 2020-2030, conventional transistors stop working, as feature lengths approach 5nm.
Even neglecting that, in another 10-15 years of moores law, you'd expect gate lengths to hit 0.5nm. Oops. Silicon atoms are spaced at 0.5nm. You can see the problem.
3D is one partial solution, but it just lets you put more transistors on a die, not let them use less power, or be faster.
Slashdot Mirror
Your inbuilt stereo supports bluetooth - great.
Does it also support IRDA?
Legal requirements on technology companies are often poorly written, and not actually sensible, as the lawyers involved may not properly understand the internet.
It's quite plausible that they used standard boilerplate 'Do not delete, modify, or ...the file at http://.../ which could not reasonably be read as allowing them to be pulled offline, as that would be a modification.
Slide rules teach lazy approximations.
Abacus should be every child's first toy!
A 1% chance of the relit stage not performing to target performance, as I understand it.
Far from a 1% chance of it hitting ISS.
If launch costs go down, it becomes more economic to make the spacecraft cheaper.
If the vendors are in true free competition, arguably.
The current vendors are basically not funded in general as rocket launch companies.
They are funded as aerospace/military welfare organisations.
Any launches that happen are a side-effect.
If your primary goal as a legislator is to get jobs for your constituents, it's quite easy to insist that technology X must be included in the vehicle - because you have a massive plant in your constituency doing X.
This does not result in good values for purchasers of the rockets launch capabilities.
"and on the fourth launch it lost an engine and couldn't deploy a secondary payload successfully and the mission was not a complete success." - a couple of points.
Firstly, the secondary payload was launched on this basis, with the understanding it was not a guaranteed launch, for a reduced fee.
Secondly, the rocket was actually capable of doing the secondary mission, but was prevented due to NASA rules precluding it.
(The rules were there to eliminate even the theoretical possibility of the relit second stage hitting ISS. They were arguably a bit tough).
Reliability isn't everything.
At some point, if you're a third the cost, even if you lose one vehicle in five, you start getting a lot more business.
To paraphrase part of TFA 'We can save money by developing X with components from Y', this is why it's cheaper to now spend money on Y.
Versus a clean-sheet design.
Combine that with SpaceX's largely integrated workflow, with minimal external contractors, and you have extreme problems for traditional aerospace to meet the costs.
Contracts are granted not on the basis of what would make the overall system cheaper, but electoral politics.
And if SpaceX gets even limited reusability working - http://phys.org/news/2012-11-spacex-story-reuseable-grasshopper-rocket.html - the price crashes further.
Current thoughts seem to be simply that the sun just happens to be one of the stars that flickers less.
Most'sun-like' stars flicker more.
Before Kepler, it wasn't really possible to measure stars brightness variation other than the sun to the levels required.
Flickering was probably a bad word to choose.
Flickering of stars as observed by the eye (or ground-based telescopes) is utterly dominated by atmospheric effects.
The phenomena Kepler is observing is brightness variations of the star on the level of seconds to hours.
As I understand it, the brightness variations between the popularion of near and far similar stars in the kepler field of view is similar.
It's unlikely to be any effect of space.
Well - sort of.
The aim of the kepler primary mission was to detect earth-like planets, in earth-like orbits, around sun-like stars.
Unfortunately, as one of the scientists working on the project pointed out, an early discovery was the sun wasn't a sun-like star.
The sun turns out to flicker rather less than most stars in the sun-like population.
This does unfortunate things when you're trying to pick the tiny, tiny signals of planets crossing the stars disks, as the noise swamps the signal.
It means that it can't be picked up in the primary mission length, and you need longer integration periods - hence the extended mission.
It's not to get more data than was intended, but to get back to the baseline that was assumed, before we realised that stars twinkle rather more than we thought.
(It will have the side-effect of picking up some planets in non-earthlike orbits that couldn't have been seen too - very tiny and very long orbit ones.)
The above points are of course true, to a degree.
Many peoples expectations about hardware engineering are unfortunately lead by software engineering - the two fields differ dramatically.
Is there a point in open-source hardware - of course!
It makes deriving working designs a _lot_ easier.
Does it make it easy - no.
Small batch production of anything more complex than a 2 layer board (cellphones will need 8) with relatively relaxed component density is expensive and unreliable, especially when you're not doing this day-day, with proper equipment.
The same issue can occur with commercial code too.
It's basically a risk for any non-completely-free licence, including explicitly non-paid-for ones.
You can be put in exactly the same position by being accused by a commercial vendor of using their code.
And the solution for the vendor is the same - sue for copyright infringement, and it'll come out if the code is infringing or not.
There is.
(or was).
http://maemo.org/community/maemo-users/ovi_map_download_on_n900_how_to/
I've done this - I can't say if it still works properly.
Well, I could, but I won't, as I can't be bothered to check.
And as long as the provider of the data allows them to - for example - not in Japan.
I should have stated it was copy-pasta.
(But I am the original author).
Is it useful - certainly - and lightly modifying an existing design without touching the core can give you considerable confidence that the design will work.
Also, it can mean that you need limited or no software mods to get it booting, and confirm at least basic functionality, at which point you can start hacking on the drivers for your integrated cheeseboard.
On forking, however.
To elaborate on why open-source hardware is hard.
Why open-source software works is:
Widely available repository of code.
Many people able to review it, or sections of it, and understand it.
Ease of submitting tested patches.
Hardware has problems that don't really fit well with this.
The open schematic is the trivially easy part, and not really a problem.
(though in practice, you need a schematic with copious links to design documents, which isn't well solved by open tools).
The number of people who can review it is rather smaller - as you can't
open up a c file, and see a clear error or awkwardness in code that can be edited.
For all but the most basic errors, you are going to have to sit down and
read several hundred pages of hardware documentation about how the chips in question work, in addition to having in-depth knowledge about the circuit design, and costings of likely changes.
Now, you've done this, and generated a patch that you think (for example) lowers the supply current by 1%.
Compile - test.
On a PC, this takes a couple of minutes.
For something of a smartphone class, a one-off PCB may cost several hundred dollars. Then the parts will cost another several hundred dollars in small quantities, as well as being difficult to obtain.
Now, you have to solder the parts onto the board, which is a decidedly nontrivial thing - and if you decide you want someone else to do this, it's probably another several hundred dollars.
So, you're at the thick end of a thousand dollars for a 'compile'.
Now, you boot the device, and it exhibits random hangs.
Neglecting the fact that you are going to need several hundred to several thousand dollars of test equipment, you now have to find
the bug.
Is it:
A) The fact that unlabled 0.5*1mm component C38 is in fact 20% over the designed value, as the assembly company put the wrong one in.
B) C38 has a tiny bridge of solder underneath it that is making intermittent contact.
C) The chipmaker for the main chip hasn't noticed that their chip doesn't quite do what they say it will do, and the datasheet is wrong.
D) You missed a tangential reference on page 384 of the datasheet to proper setup of the RAM chip, and it is pure coincidence that all models up till now have booted.
E) Because you're ordering small quantities, you had to resort to getting the chips from a distributor who diddn't watch their supply chain really carefully, and your main chip has in fact been desoldered from a broken cellphone.
F) Though the design of the circuit is correct, and the board you made matches that design, and all the parts are correct and work properly, the inherent undesired elements introduced by real life physics means it doesn't work.
G) A completely random failure of a part that could occur with even the best design, and best manufacture.
G - may mean that it's worthwhile making two or more of each revision - which of course boosts costs.
Hardware is nasty.
This gets a lot less painful of course for lower end hardware. For very limited circuits, which can be done on simple inexpensive PCBs, and be easily soldered at home - costs of a 'compile' can be in the tens of dollars, or even lower.
Carbon fibres modulus, while perhaps low by some measure, is very, very high compared to that of the brain.
The brain shifts in the skull, especially during impact.
Any rigid strong wire risks being ripped out, as the brain stretches, or doing the cheese wire thing.
Cheesewired brain is bad.
In principle, there are two trades to be made.
With a smaller geometry, you can either go high frequency, or lower power. (both are of course possible).
If 3D manufacturing became cheap enough, then we might see (for example) 2048 core 300MHz processors using a comparable amount of power to a 10 core 5GHz processor.
Openmoko screwed up by the numbers.
(originally posted in 2009)
Openmoko dropped the ball in a big pile of manure, and then asked the community to lick it off.
A quick outline of the process - from someone who has been active in #openmoko on IRC forever, and bought the early version when I really could not afford it.
Openmoko is a perfect example of how not to do an 'open source - community involved project'.
Firstly, in march 2007 or so, we had a working phone with hardware available, with somewhat clunky but more-or-less usable basic phone and SMS. Battery life was not great - 12h or so.
Basic kernel stuff was unreliable - suspend diddn't work right, clock frequency changing diddn't work, ...
Fix the kernel bugs, get the software 50% faster in 6 months, which is not implausible, and you could have had a phone selling for christmas 2007, that had a somewhat clunky phone, SMS, application, bluetooth working, you can play nethack on it (with an external bluetooth keyboard), run any X app, with a several day standby time ...
One year before Android hit, and six months after the first iphone.
Clearly it wouldn't have been as polished as the first iphone, but it would be a platform to hack on.
So, the logical thing to do at this point is of course to after no consultation with the community drop a different - though similar - software stack on the community, with no notice other than the CEO saying 'Something really cool is coming up!!!!!!!!!!!!!!!!!!!!!' at a conference some weeks before.
This software gets sort-of polished over the next yearish, with still the underlying kernel problems unfixed, and during this period new 'better' hardware is being worked on.
The new slightly evolved hardware arrives, and at the same time the CEO pops up saying 'Something really cool is coming up!!!!!!'.
And yes, another drastic software change with no notice - from X to Qt.
The kernel bugs are still not fixed, and worse, the new better hardware that was supposed to fix everything turns out to have a graphics accellerator that is at best usually a wash, compared to the earlier version with a processor with half the speed.
Shortly after this - another UI change - this time back to X, and an explosion of 'community' distributions, some of which mostly work.
And some of the kernel bugs are even fixed - but by this time openmoko-corporate has run out of money, at least to do phones, as a new model is going to take a large slice of a million to make a stab at developing.
There is even a gta02-core project - which is a community phone project based on the schematics. But, this again would require a large slice of a million for a 'real' launch.
And the elephant in the room is the n900 now. It makes users think 'For $150 more, I can get the n900, which does x,y,z,...', which is impossible to counter from a small production run as you don't have the margins to slash the price.
Openmoko-corporate never really talked to the community, which was a fundamental failing.
They diddn't say 'We are not working on a,b,c,d,e' - so of course people assumed they were, as they must be - they'd have to be insane not to...
So kernel bugs that made the device unusable went unfixed, and it all kind of went very very wrong.
Openmoko-corporate is now out of the mobile market - they are not employing any engineers on designing new phones or fixing the software stack. They are continuing to sell the hardware - but not even in a fully bugfixed form.
FPGAs are always going to be more expensive, and less power efficient for given tasks than comparable single function silicon.
There is, even in the most efficiently implemented design in a FPGA, considerable area wasted by interconnects, and suboptimal use of resources.
It's like making a working device from lego.
Yes, you may be able to do it, but if you make it as one moulded piece, it's going to be lots cheaper.
There are also no CPLDs in mobile phones.
FPGAs are essentially not used in mobile phones, for power efficiency and other reasons.
Nor is opening up the code for any hardware you can get source for (nothing) useful, as making your own chips from them will cost at best many tens of thousands.
This is totally ignoring the software and patent problems.
To elaborate on why open-source hardware is hard, and why making a single phone will cost you over $10K.
Why open-source software works is:
Widely available repository of code.
Many people able to review it, or sections of it, and understand it.
Ease of submitting tested patches.
Hardware has problems that don't really fit well with this.
The open schematic is the trivially easy part, and not really a problem.
(though in practice, you need a schematic with copious links to design documents, which isn't well solved by open tools).
The number of people who can review it is rather smaller - as you can't open up a c file, and see a clear error or awkwardness in code that can be edited.
For all but the most basic errors, you are going to have to sit down and read several hundred pages of hardware documentation about how the chips in question work, in addition to having in-depth knowledge about the circuit design, and costings of likely changes.
Now, you've done this, and generated a patch that you think (for example) lowers the supply current by 1%.
Compile - test.
On a PC, this takes a couple of minutes.
For something of a smartphone class, a one-off PCB may cost several hundred dollars. Then the parts will cost another several hundred dollars in small quantities, as well as being difficult to obtain.
Now, you have to solder the parts onto the board, which is a decidedly nontrivial thing - and if you decide you want someone else to do this, it's probably another several hundred dollars.
So, you're at the thick end of a thousand dollars for a 'compile'.
Now, you boot the device, and it exhibits random hangs.
Neglecting the fact that you are going to need several hundred to several thousand dollars of test equipment, you now have to find
the bug.
Is it:
A) The fact that unlabled 0.5*1mm component C38 is in fact 20% over the designed value, as the assembly company put the wrong one in.
B) C38 has a tiny bridge of solder underneath it that is making intermittent contact.
C) The chipmaker for the main chip hasn't noticed that their chip doesn't quite do what they say it will do, and the datasheet is wrong.
D) You missed a tangential reference on page 384 of the datasheet to proper setup of the RAM chip, and it is pure coincidence that all models up till now have booted.
E) Because you're ordering small quantities, you had to resort to getting the chips from a distributor who diddn't watch their supply chain really carefully, and your main chip has in fact been desoldered from a broken cellphone.
F) Though the design of the circuit is correct, and the board you made matches that design, and all the parts are correct and work properly, the inherent undesired elements introduced by real life physics means it doesn't work.
G) A completely random failure of a part that could occur with even the best design, and best manufacture.
G - may mean that it's worthwhile making two or more of each revision - which of course boosts costs.
Hardware is nasty.
This gets a lot less painful of course for lower end hardware. For very limited circuits, which can be done on simple inexpensive PCBs, and be easily soldered at home - costs of a 'compile' can be in the tens of dollars, or even lower.
One problem.
Even assuming this is correct, we don't have that long.
Sometime around 2020-2030, conventional transistors stop working, as feature lengths approach 5nm.
Even neglecting that, in another 10-15 years of moores law, you'd expect gate lengths to hit 0.5nm.
Oops. Silicon atoms are spaced at 0.5nm.
You can see the problem.
3D is one partial solution, but it just lets you put more transistors on a die, not let them use less power, or be faster.
One is too many. Zero is the optimal number.