One of the router I build was for the European Space Agency, a special version with a GPS/Glonass receiver that was designed to sustain lightning strike on jis antenna.
I also designed the software Linux software stack, and now maintaining the electronics, of a railway computer rack operating every day in extreme temperature range and that sustain not only severe EMI interference but up to 1KV surge on the main supply.
The development and production cost of this kind of system was in the 1e6 EUR range. For the router I used an in house system build infrastructure because in 2001 there was no existing project to do that, especially for the PPC405GP processor ( I remember that one member of the team wrote an early MMU Linux support for that chip and discovered a new silicon bug doing so, confirmed the next day by IBM on there simulator ). For the railway system I used a standard Debian with the minimum required packages, a quick removal of the man pages and of the internationalization files. The systemvinit already sucked for those projects, to the point that a parent application was designed to manage and monitor all the children services that can be executed depending on specific modes of operation and configuration. If systemd existed at this time it would have saved a significant amount of time.
Why did you think I would run unnecessary deamons? If you don't need something, simply remove the unused package, it's very easy. A Debian Jessie for example can quickly be shrink down to something similar to default buildroot in the number of deamons running. You can very quickly switch from systemd to systemvinit or even upstart is you wants. And contrary to buildroot, the test coverage is vastly superior. And this take just a few minutes to do, not hours of compilation as with OpenEmbedded. Now if you need only Bluetooth and SPI, there is a bunch of chips that integrate everything, including CPU and memory. If the software stack is small enough to fit into one of them, don't even try Linux, it's just a wast of time. If the software stack is complex enough to require a Linux kernel, then you will need external memory chip, and so you can probably run a minimal distribution, even if you think it's overkill.
Now the very point I try to make you aware of is that all those embedded projects almost only uses exiting build solution and play a insignificant role into the community that design the future of leading Linux distribution and consequently the infrastructure that applications will gradually rely on. It's not a new process: devfs and udev was a similar move, the posix thread was a similar move, D-Bus was a similar move, and you can certainly find others examples.
$20 saving because you use a tiny kernel, busybox and systemvinit? You obviously never designed embedded system architectures from the electronic to the software by taking the real costs in account. Any leading distributions allow to remove packages down to a very small set to support simple applications, providing update without any additional work. On advantage of sysemd is that the logs can be in RAM only if you worry about the size of log file. Leading distributions includes by default log rotation and compression that help to mitigate the risk in case of problem. More end more embedded system use eMMC memory or Flash with wear leveling to not write to the same sector. Serious embedded system use read-only root filesystem and eventually an other read-write memory is required. Systemd is far far more easy to learn than the over complex multiple configuration layers of Yocto/Openembedded, yet provides better management and analysis tools that anything the systemvinit several decades old community have ever produced.
I work actually on a embedded system that includes multiple SDcard, FPGA, DSP, high end analog front end, big battery charging, isolated RS-485, GPS, GSM 2G/3G/4G, PCIe slot, WiFi, 868MHZ RF modem, OLED screen, 100BASE-T ethernet, 100BASE-FX ethernet, and high power semiconductor relay. It don't fit in a thumb drive package but in a shoes box size heavy industrial case. But it run Debian Jessie armhf on a small single core Cortex-A7 processor at ~500MHz, including realtime processing, Postgresql database and the various thirds parties node applications for the webui and cloud integration. Your theory about quad-core >1.2GHz show that you have no clue about what processor is required for a Linux design. That say all the current Linux capable CPU I know on the market can very easily handle your feature set, really no need for a quad-core >1.2GHz, for sure. Finally the peripheral integration will have no influence on the systemd/systemvinit choice: memory package is standardized across a width range of capacity, only the price vary.
I have not lost the big picture. I have for years designed PowerPC Linux routers, some with as low as 8MB of RAM and 8MB of flash, and I remember how hard it was. I have designed multiple systems with the infamous Blackfin MMU-Less CPU and just a few more memory, and I remember the nightmare it was. I have also used many different BSP and there are all outdated and polluted with bad hack. Seriously this must end as soon as possible as this is a so big vast of time. Today we can enjoy standard leading quality core thanks to the ARM cortex domination of the market, and standard leading quality distributions thanks to Debian/Ubuntu/Linaro/Fedora/openSuSE projects and the like. All of that run very well on very small and cheap processors like the SAMA5D35 or i.MX6UL for example.
You definitively fail to understand that a core processor like a Cortex-A7 is so small that is play a minor impact on the cost of a system. You fail to understand that the price of memory chip is fixed by the mass production batch instead than by the memory capacity. As soon as you have external components for the flash and the SDRAM, you can run a standard distribution at the lowest cost. There is incredible peoples working on making Linux running on Cortex-M4 or such odd core. Fun for them if there enjoy doing do, but I predict that this will stay confined into extremely small Linux market, like many less popular core like the AV32 or the Blackfin for example.
The system you seem to dream on is more like what QNX or the like provides. It can run some UNIX applications without heavy modifications and run on core that are smaller than what mainline Linux can, in some case even without external memories. If it's for a mass market device, the license cost is not an issue.
I know Yocto and OpenEmbedded, I have used them before. Compared to using a standard distribution that work immediately and run all the applications without any problem, this is a vast loss of time for no gain. I will not that this route anymore for my clients, granted. The cheapest memory in not the smallest size memory, but the actively mass produced size memory, and his size is only growing since several decade, so the days of limited memory system is counted. In addition the developers that pass time tuning there system build infrastructure are always behind the leading developers that take decision of what the future of a Linux system will look. There take all the changes by surprise because in fact there just try to follow what the leading distributions brings on the table. I have passed more that 10 years in that situation, Now I more than happy to get out of this and work on embedded systems that run exactly the same distribution than my workstation and my servers.
Yet all of this "growing busybox community" is unable to yield any significant progress in a proper long term support of systemvinit ecosystem from the applications point of view. The reality is very basic: most of the devices you count are developed using board support package from processors manufacturers, and many manufacturers only make the minimum to present a Linux BSP. For them the most easiest is to use buildroot or similar system build infrastructure that use busybox by default. This schema can continue for applications that don't need more that systemvinit, no problem. The fact is that those developers are only picking existing projects and try to shrink them down. I know the process, I have done this many times for a number of projects using by the way almost all the system build infrastructure that was available. The crud reality is that the developers that do this kind of jobs are almost invisible on the community that build the future of Linux distributions. It's not an hazard if the systemd roll out take most of them by surprise.
The community that build the future of Linux is strongly supporting systemd. If you don't get this fact by now, sorry for you. A lot of developers like me don't use system build infrastructure anymore because it just a such big loss of time. Why continuing tuning a system build infrastructure to make your applications set working when you can pick up a standard distribution that work immediately and run you applications set without any problem out of the box ? The only valid reason to not use a standard distribution today is because of the components cost at large scale, especially the memory reach a sufficient cost saving to cover the time passed to build the system. Now if you know a bit the economy of the memory chip market, you should know that the lowest price point is not the smallest memory size, but the memory size actively in mass production. Decade of verifiable observation of this market only show that the lowest price memory only grow in size. So the days of the schema "shrink down to save memory" is counted and it's a highly irreversible evolution.
If you wants to see the future of Linux in embedded systems,.take a look at Linaro or all the RaspberryPI like boards that flood the market. Full distribution with systemd on a processor with enough memory is what most developers use today to build the devices that will go to the market in the future. Slowly, some processors manufacturers understood the change and replace there crappy BSP, often based on a system build system, by a support for the drivers on the mainline kernel, letting the choice open for the distribution. In all the projects I actively supports today, the clients compile directly on the target running a full distribution, even on a small Cortex-A7.
While I agree that there is probably an opportunity for systems using only the smallest possible Linux configuration, there require far more knowledge to get them supporting the required applications compared to using a already available standard distribution. This seriously limit the possible audience.
I will not comment on your off-tropic "frontier is moving" theory.
It's not a problem to have very limited systems using a minimal Linux configuration without systemd. The audience of this kind of system is already small and will continue to shrink. While the original Busybox goal was to make a Debian installer that fit in a floppy disk, the possible useful future Busybox goal will be more en more confined to very special systems. This is why I call it a dead end: there can do whatever there wants, this will change absolutely nothing to the leading distributions.
Maybe I should have used the words "dead branch" to get a version control analogy. It will continue to live, but in a isolated space from the master, and will never merge something back to it.
Agree, this is why I use the words "majors Linux distributions" and not "all Linux distros". From what I can observe, the systemvinit supporters seem to have trouble to bring up a modern distribution without systemd that will enjoy a large user base.
I don't say there are going away, I say there will be limited to more and more limited devices. Just look how the RaspberryPI and similar boards run standard distributions.
Don't rewrite the history because you are ignorant. Busybox was from the start a project targeted for Linux, and more precisely for the Debian installer. BSD compatibility was added a decade later if I remember correctly. And Busyboy will probably dead if he remove this: http://git.busybox.net/busybox...
Linux provides a UNIX compatible interface for the applications that want it, that all. Linux has a lot of system calls completely incompatible with UNIX since many many years and this will continue for sure. All the applications that uses the Linux only system calls are de facto incompatible with UNIX. This is really not new: udev is not the UNIX way, the/sys interface is not the UNIX way, netfilter is not the UNIX way, etc...
Busybox is not a distribution, but a set of minimal tools designed for memory limited systems. For this kind of systems, it logic to not add systemd support.
There is no systemd drama, but a few systemvinit addict unable to maintain his support at a level required by all the leading distributions.
An other point is that now that all majors Linux distributions support systemd, applications developers will gradually make there project compatible with systemd. So BSD would probably get some benefit if there are able to bring up an API that is compatible with systemd from the applications point of view.
Busybox is a dead end. It was a nice project for systems with very small memory, but now even small systems have enough memory to run a standard distribution. Busybox future is probably bound to extremely limited system like MMU less Cortex-M4 or similar, on projects where it's not a problem to pass time cutting down memory consumption. For this kind of extremely limited system, removing systemd is a logical choice. This is a special case that will make no influence at all on the mainstream support on systemd by all leading distributions.
I do make embedded systems that integrate many applications, and systemd is a big step forward, even if the log need of some fixes.
Toyota seem to like relatively small NiMH battery for now as there use it on hybrid and fuel cell cars. There is maybe ecological and economical reasons to limit the quantity of the battery that will need to be recycled. Toyota officially plan to recycle nearly all the NiMH battery there sold, and at least the European program seem to be on track to archive this goal. Don't know about Tesla on this question as searching returns mixed results.
The Prius, on the other hand, uses a touch screen interface. Look. Touch to change screen. Look for setting. Touch. Eyes shifting back and forth between screen and road, or just looking at screen.
My Prius II have all the important settings directly on the steering wheel: http://www.motorauthority.com/... After a few practice, I don't even have to look at them.
From the page 487: Received: December 16, 2014 Revised: May 4, 2015 Accepted: September 11, 2015 Published: October 8, 2015 Add to that the time needed to redact a 30+ pages paper in coordination with all the authors. That said, I don't know if it's a normal timing or not in that research field.
Even if the capacity factor of the wind and solar plants will remain low in the worst case, there absolute capacity will continue to increase as this is cheap energy. This is a logical economic choice by the energy producers. This move alone is enough to lower the capacity factor of the plant that need to buy combustible.
That said, I think that the capacity factor of the wind and solar plants will still increase a bit in the future as there take advantage of wider geographical conditions and take advantage of any kind of energy storage.
Difficult to tell is this will be enough to provides the base load, but it's undeniable that this will make the price of electricity changing very fast compared to today variation. The electricity will be very cheap when wind and solar are producing large amount, sometime even more than what the consumers can take making the price negative if there is no good interconnect to more consumers. On the contrary the price will go more higher than today when the wind and solar plant are producing only a low ratio of the demand because the combustible plants will run with a lower capacity factor.
One way to see the transition is to see it as a multiple steps process. The following schema is very general and not specific to a country (It's somewhat from the German situation, the country that is probably the leader in that transition in Europe): 1) Before nuclear plant, fossil plants take the big part, hydro for most of the rest if geographically possible. 2) Nuclear well in place: some fossils plant go uneconomical, hydro pumping economically possible because nuclear difficult to adjust to the demand. 3) Renewable ramp up: Reduce the fossil plant usage but still needed because of weather change on the renewable. Price start to change quickly. We are actually here now. 4) Energy storage ramp up: because the price change will make is economically possible. More fossil plants go uneconomical.
Nuclear is still an open question as it will also greatly take advantage of an increase of storage energy capacity, even if it's for the exact opposite reason of the renewable energy. I believe that the future of nuclear will have to take in account some difficult society perception regarding risks in exploitation and in long term wast. Probably that some countries will increase it, some will maintain it, some will reduce it, and some will even stop it.
"For the first time, widespread adoption of renewables is effectively lowering the capacity factor for fossil fuels. That's because once a solar or wind project is built, the marginal cost of the electricity it produces is pretty much zero—free electricity—while coal and gas plants require more fuel for every new watt produced. If you're a power company with a choice, you choose the free stuff every time. It’s a self-reinforcing cycle. As more renewables are installed, coal and natural gas plants are used less. As coal and gas are used less, the cost of using them to generate electricity goes up. As the cost of coal and gas power rises, more renewables will be installed. "
Slashdot Mirror
One of the router I build was for the European Space Agency, a special version with a GPS/Glonass receiver that was designed to sustain lightning strike on jis antenna.
I also designed the software Linux software stack, and now maintaining the electronics, of a railway computer rack operating every day in extreme temperature range and that sustain not only severe EMI interference but up to 1KV surge on the main supply.
The development and production cost of this kind of system was in the 1e6 EUR range. For the router I used an in house system build infrastructure because in 2001 there was no existing project to do that, especially for the PPC405GP processor ( I remember that one member of the team wrote an early MMU Linux support for that chip and discovered a new silicon bug doing so, confirmed the next day by IBM on there simulator ). For the railway system I used a standard Debian with the minimum required packages, a quick removal of the man pages and of the internationalization files. The systemvinit already sucked for those projects, to the point that a parent application was designed to manage and monitor all the children services that can be executed depending on specific modes of operation and configuration. If systemd existed at this time it would have saved a significant amount of time.
Why did you think I would run unnecessary deamons? If you don't need something, simply remove the unused package, it's very easy. A Debian Jessie for example can quickly be shrink down to something similar to default buildroot in the number of deamons running. You can very quickly switch from systemd to systemvinit or even upstart is you wants. And contrary to buildroot, the test coverage is vastly superior. And this take just a few minutes to do, not hours of compilation as with OpenEmbedded. Now if you need only Bluetooth and SPI, there is a bunch of chips that integrate everything, including CPU and memory. If the software stack is small enough to fit into one of them, don't even try Linux, it's just a wast of time. If the software stack is complex enough to require a Linux kernel, then you will need external memory chip, and so you can probably run a minimal distribution, even if you think it's overkill.
Now the very point I try to make you aware of is that all those embedded projects almost only uses exiting build solution and play a insignificant role into the community that design the future of leading Linux distribution and consequently the infrastructure that applications will gradually rely on. It's not a new process: devfs and udev was a similar move, the posix thread was a similar move, D-Bus was a similar move, and you can certainly find others examples.
$20 saving because you use a tiny kernel, busybox and systemvinit? You obviously never designed embedded system architectures from the electronic to the software by taking the real costs in account. Any leading distributions allow to remove packages down to a very small set to support simple applications, providing update without any additional work. On advantage of sysemd is that the logs can be in RAM only if you worry about the size of log file. Leading distributions includes by default log rotation and compression that help to mitigate the risk in case of problem. More end more embedded system use eMMC memory or Flash with wear leveling to not write to the same sector. Serious embedded system use read-only root filesystem and eventually an other read-write memory is required. Systemd is far far more easy to learn than the over complex multiple configuration layers of Yocto/Openembedded, yet provides better management and analysis tools that anything the systemvinit several decades old community have ever produced.
I work actually on a embedded system that includes multiple SDcard, FPGA, DSP, high end analog front end, big battery charging, isolated RS-485, GPS, GSM 2G/3G/4G, PCIe slot, WiFi, 868MHZ RF modem, OLED screen, 100BASE-T ethernet, 100BASE-FX ethernet, and high power semiconductor relay. It don't fit in a thumb drive package but in a shoes box size heavy industrial case. But it run Debian Jessie armhf on a small single core Cortex-A7 processor at ~500MHz, including realtime processing, Postgresql database and the various thirds parties node applications for the webui and cloud integration. Your theory about quad-core >1.2GHz show that you have no clue about what processor is required for a Linux design. That say all the current Linux capable CPU I know on the market can very easily handle your feature set, really no need for a quad-core >1.2GHz, for sure. Finally the peripheral integration will have no influence on the systemd/systemvinit choice: memory package is standardized across a width range of capacity, only the price vary.
I have not lost the big picture. I have for years designed PowerPC Linux routers, some with as low as 8MB of RAM and 8MB of flash, and I remember how hard it was. I have designed multiple systems with the infamous Blackfin MMU-Less CPU and just a few more memory, and I remember the nightmare it was. I have also used many different BSP and there are all outdated and polluted with bad hack. Seriously this must end as soon as possible as this is a so big vast of time. Today we can enjoy standard leading quality core thanks to the ARM cortex domination of the market, and standard leading quality distributions thanks to Debian/Ubuntu/Linaro/Fedora/openSuSE projects and the like. All of that run very well on very small and cheap processors like the SAMA5D35 or i.MX6UL for example.
You definitively fail to understand that a core processor like a Cortex-A7 is so small that is play a minor impact on the cost of a system. You fail to understand that the price of memory chip is fixed by the mass production batch instead than by the memory capacity. As soon as you have external components for the flash and the SDRAM, you can run a standard distribution at the lowest cost. There is incredible peoples working on making Linux running on Cortex-M4 or such odd core. Fun for them if there enjoy doing do, but I predict that this will stay confined into extremely small Linux market, like many less popular core like the AV32 or the Blackfin for example.
The system you seem to dream on is more like what QNX or the like provides. It can run some UNIX applications without heavy modifications and run on core that are smaller than what mainline Linux can, in some case even without external memories. If it's for a mass market device, the license cost is not an issue.
I know Yocto and OpenEmbedded, I have used them before. Compared to using a standard distribution that work immediately and run all the applications without any problem, this is a vast loss of time for no gain. I will not that this route anymore for my clients, granted. The cheapest memory in not the smallest size memory, but the actively mass produced size memory, and his size is only growing since several decade, so the days of limited memory system is counted. In addition the developers that pass time tuning there system build infrastructure are always behind the leading developers that take decision of what the future of a Linux system will look. There take all the changes by surprise because in fact there just try to follow what the leading distributions brings on the table. I have passed more that 10 years in that situation, Now I more than happy to get out of this and work on embedded systems that run exactly the same distribution than my workstation and my servers.
Yet all of this "growing busybox community" is unable to yield any significant progress in a proper long term support of systemvinit ecosystem from the applications point of view. The reality is very basic: most of the devices you count are developed using board support package from processors manufacturers, and many manufacturers only make the minimum to present a Linux BSP. For them the most easiest is to use buildroot or similar system build infrastructure that use busybox by default. This schema can continue for applications that don't need more that systemvinit, no problem. The fact is that those developers are only picking existing projects and try to shrink them down. I know the process, I have done this many times for a number of projects using by the way almost all the system build infrastructure that was available. The crud reality is that the developers that do this kind of jobs are almost invisible on the community that build the future of Linux distributions. It's not an hazard if the systemd roll out take most of them by surprise.
The community that build the future of Linux is strongly supporting systemd. If you don't get this fact by now, sorry for you. A lot of developers like me don't use system build infrastructure anymore because it just a such big loss of time. Why continuing tuning a system build infrastructure to make your applications set working when you can pick up a standard distribution that work immediately and run you applications set without any problem out of the box ? The only valid reason to not use a standard distribution today is because of the components cost at large scale, especially the memory reach a sufficient cost saving to cover the time passed to build the system. Now if you know a bit the economy of the memory chip market, you should know that the lowest price point is not the smallest memory size, but the memory size actively in mass production. Decade of verifiable observation of this market only show that the lowest price memory only grow in size. So the days of the schema "shrink down to save memory" is counted and it's a highly irreversible evolution.
If you wants to see the future of Linux in embedded systems,.take a look at Linaro or all the RaspberryPI like boards that flood the market. Full distribution with systemd on a processor with enough memory is what most developers use today to build the devices that will go to the market in the future. Slowly, some processors manufacturers understood the change and replace there crappy BSP, often based on a system build system, by a support for the drivers on the mainline kernel, letting the choice open for the distribution. In all the projects I actively supports today, the clients compile directly on the target running a full distribution, even on a small Cortex-A7.
While I agree that there is probably an opportunity for systems using only the smallest possible Linux configuration, there require far more knowledge to get them supporting the required applications compared to using a already available standard distribution. This seriously limit the possible audience.
I will not comment on your off-tropic "frontier is moving" theory.
It's not a problem to have very limited systems using a minimal Linux configuration without systemd. The audience of this kind of system is already small and will continue to shrink. While the original Busybox goal was to make a Debian installer that fit in a floppy disk, the possible useful future Busybox goal will be more en more confined to very special systems. This is why I call it a dead end: there can do whatever there wants, this will change absolutely nothing to the leading distributions.
Maybe I should have used the words "dead branch" to get a version control analogy. It will continue to live, but in a isolated space from the master, and will never merge something back to it.
A real embedded developers will have more rational arguments.
Busybox was designed for the Linux Debian installer. Don't rewrite the history.
Agree, this is why I use the words "majors Linux distributions" and not "all Linux distros".
From what I can observe, the systemvinit supporters seem to have trouble to bring up a modern distribution without systemd that will enjoy a large user base.
I don't say there are going away, I say there will be limited to more and more limited devices. Just look how the RaspberryPI and similar boards run standard distributions.
Don't rewrite the history because you are ignorant. Busybox was from the start a project targeted for Linux, and more precisely for the Debian installer. BSD compatibility was added a decade later if I remember correctly. And Busyboy will probably dead if he remove this: http://git.busybox.net/busybox...
I have more than 15 years of Linux embedded system experience. Please use more rationals arguments.
How much trouble someone need to have to elaborate and write as such post ?
Linux provides a UNIX compatible interface for the applications that want it, that all. Linux has a lot of system calls completely incompatible with UNIX since many many years and this will continue for sure. All the applications that uses the Linux only system calls are de facto incompatible with UNIX. This is really not new: udev is not the UNIX way, the /sys interface is not the UNIX way, netfilter is not the UNIX way, etc...
Busybox is not a distribution, but a set of minimal tools designed for memory limited systems. For this kind of systems, it logic to not add systemd support.
There is no systemd drama, but a few systemvinit addict unable to maintain his support at a level required by all the leading distributions.
An other point is that now that all majors Linux distributions support systemd, applications developers will gradually make there project compatible with systemd. So BSD would probably get some benefit if there are able to bring up an API that is compatible with systemd from the applications point of view.
Busybox is a dead end. It was a nice project for systems with very small memory, but now even small systems have enough memory to run a standard distribution. Busybox future is probably bound to extremely limited system like MMU less Cortex-M4 or similar, on projects where it's not a problem to pass time cutting down memory consumption. For this kind of extremely limited system, removing systemd is a logical choice. This is a special case that will make no influence at all on the mainstream support on systemd by all leading distributions.
I do make embedded systems that integrate many applications, and systemd is a big step forward, even if the log need of some fixes.
Toyota seem to like relatively small NiMH battery for now as there use it on hybrid and fuel cell cars. There is maybe ecological and economical reasons to limit the quantity of the battery that will need to be recycled. Toyota officially plan to recycle nearly all the NiMH battery there sold, and at least the European program seem to be on track to archive this goal. Don't know about Tesla on this question as searching returns mixed results.
The Prius, on the other hand, uses a touch screen interface. Look. Touch to change screen. Look for setting. Touch. Eyes shifting back and forth between screen and road, or just looking at screen.
My Prius II have all the important settings directly on the steering wheel:
http://www.motorauthority.com/...
After a few practice, I don't even have to look at them.
http://hackaday.com/2015/10/10...
At least a step in that direction.
Now that the paper is out, did you think there archived sometime or not ?
From the page 487:
Received: December 16, 2014
Revised: May 4, 2015
Accepted: September 11, 2015
Published: October 8, 2015
Add to that the time needed to redact a 30+ pages paper in coordination with all the authors.
That said, I don't know if it's a normal timing or not in that research field.
Even if the capacity factor of the wind and solar plants will remain low in the worst case, there absolute capacity will continue to increase as this is cheap energy. This is a logical economic choice by the energy producers. This move alone is enough to lower the capacity factor of the plant that need to buy combustible.
That said, I think that the capacity factor of the wind and solar plants will still increase a bit in the future as there take advantage of wider geographical conditions and take advantage of any kind of energy storage.
Difficult to tell is this will be enough to provides the base load, but it's undeniable that this will make the price of electricity changing very fast compared to today variation. The electricity will be very cheap when wind and solar are producing large amount, sometime even more than what the consumers can take making the price negative if there is no good interconnect to more consumers. On the contrary the price will go more higher than today when the wind and solar plant are producing only a low ratio of the demand because the combustible plants will run with a lower capacity factor.
One way to see the transition is to see it as a multiple steps process. The following schema is very general and not specific to a country (It's somewhat from the German situation, the country that is probably the leader in that transition in Europe):
1) Before nuclear plant, fossil plants take the big part, hydro for most of the rest if geographically possible.
2) Nuclear well in place: some fossils plant go uneconomical, hydro pumping economically possible because nuclear difficult to adjust to the demand.
3) Renewable ramp up: Reduce the fossil plant usage but still needed because of weather change on the renewable. Price start to change quickly. We are actually here now.
4) Energy storage ramp up: because the price change will make is economically possible. More fossil plants go uneconomical.
Nuclear is still an open question as it will also greatly take advantage of an increase of storage energy capacity, even if it's for the exact opposite reason of the renewable energy. I believe that the future of nuclear will have to take in account some difficult society perception regarding risks in exploitation and in long term wast. Probably that some countries will increase it, some will maintain it, some will reduce it, and some will even stop it.
Clam down, I don't insult you.
From the article:
"For the first time, widespread adoption of renewables is effectively lowering the capacity factor for fossil fuels. That's because once a solar or wind project is built, the marginal cost of the electricity it produces is pretty much zero—free electricity—while coal and gas plants require more fuel for every new watt produced. If you're a power company with a choice, you choose the free stuff every time.
It’s a self-reinforcing cycle. As more renewables are installed, coal and natural gas plants are used less. As coal and gas are used less, the cost of using them to generate electricity goes up. As the cost of coal and gas power rises, more renewables will be installed. "