Did you realize that your are talking with the legitimate choice of French citizen ? For sure there are not your enemy, even if you disagree on how to act.As a Swiss citizen I would be more than happy to see France in a better political health. This could be a bit harsh to read for you, but I describes actual French political system as a "monarchie républicaine" that are not so far from the old "monarchie constitutionelle" and "monarchie absolue". Basically the the president have far too much power in the whole government system. This lay down to basic math:
When you have only a single party that can win the election, the system tend to make 50% peoples against the other 50%. The frustration is high, so any problem will make the believe that the opposition party will be better, so the system will oscillate near 50% frustration. After some cycle the peoples eventually realize that the two main parties never meet there goals, so a other one will gain support as the situation degrade. At some point you have 3 parties, and whenever to one that win he is almost granted to have near 66% of frustration against it. So it look like having 50% frustration is the best possible score? Wait!
In Switzerland, instead of a president, we experience since more than 150 years a federal council composed on 7 peoples from a range of leading parties. This make the vast majority of the peoples with different political orientation represented up to the head of state. The frustration is then lowered to the the peoples that don't have representation, probably below 20%.
Just winning an election is not enough, you still have to negotiate with the others to make a positive move.
I tested kernel up to 4.2 with earlyprintk=efi and everything is ok up to the point where the console take over the earlyprintk. Seem to be something wrong at setting the screen, but nomodeset i915.modeset=0 don't help.
I just buy a cheap notebook based on the Atom Z3735F 1.3GHz, 2G of DDR and 64G of eMMC. While the processor is 64 bits, the UEFI is for 32 bits only, so no easy way to install a 64 bit Linux distribution on it. First step was to go into the UEFI setup to disable the secure boot, then... I tried Ubuntu 15.10 32 bits, and the installer don't even boot from a USB memory. I tried Debian 8.2 32 bits, the installer booted from the USB memory up to the selection menu, but whenever I chose the text or graphic installer, the screen go black with flashing small white lines across the screen, a bit like a old CRT that lost the synchronization. I tried the last daily Debian installer without more success. So no chance for me. The workaround was to install Debian 8.2 32 bits inside VirtualBox on top of Windows 10. My conclusion is that very cheap notebook are designed for 32 bits Windows 10 only and that nothing is tested to allow installing a Linux distribution.
GPS and PTP both broadcast TAI and UTC-TAI that sum up the past leap seconds, so your claim is not completely correct. I will add that GPS and PTP both lack a method to broadcast the leap second history table required to safely compute time in the past at the second precision. NTP need a major protocol upgrade to fix his multiples issues, or PTP need to be broadcasted as NTP is today.
It's not the usual process of ITU decision that is the cause of the rejection. The cause is the fact that the proposition itself is stupid and make the problem even worst. To be certain that the programmers take seriously the fact that the duration of day is variable the adjustment code path must occur more often. The most effective way will be to define the civil time by a day counter and a offset since the start of that day. The day duration can be adjusted periodically. The programmed will know that the day is not 86400 second and the day increment code path will be tested every night.
1) Will lead to many more confusion between the two type of seconds. 2) Will break the ancestral definition of time in all the civilization that ever existed. 3) The only way and nobody is seriously make any other proposition. The discussion is how to improve it because the leap second is rare enough to make too many programmers not taking it seriously enough and testing is enough.
So the solution is certainly not to make the adjustment more rare, but more often. My proposal is to define the civil time by a day counter and a offset since the start of that day. The day duration can be adjusted periodically to match the average earth rotation and the day increment will occur every night so the programmed need to be aware of it and can test it every night. As a bonus it will work on any planets.
Yes this will make the programmer lazy about the problem and a big mess when the first change take reality. I largely prefer a model with a day counter and a time offset since the start of that day, so the day duration can be adjusted to the physical reality of the earth rotation. The advantage is that the programmer can test the day increment every night.
The current leap second system is still enough for many centuries and even several thousand of years is the leap seconds are allowed every months or weeks.
Is you think about this more deeply you will realize that the best model will be to have what we actually call UTC defined in term of days counter since a epoch date and a second counter since the start of that day. This will allow to adjust periodically the day duration to the reality of the average earth rotation. Not only this model work with the earth rotation any time in his history, but it will work with any planets.
But no matter what, programmer that can't directly use TAI only will have to deal with variable day duration and historical day duration table. At least it will be more easy to test because the difficult part occur every day.
Yet no one have found a better way to coordinate some important aspect of the worldwide telecommunication infrastructure. Keep in mind that there have to deal with governments with opposed sensibility or in conflict.
The industrial/embedded systems you describes must use TAI, not UTC or local time. Actually only the GPS broadcast the TAI in a direct usable form nearly everywhere. NTP broadcast UTC only and fail to send the TAI to UTC offset. PTP doe the right thing but is actually not broadcasted as NTP or GPS is.
Sorry, in the previous comment I have wrote "Nexus 5P" while I must have wrote "Nexus 5X". I was confused by the Nexus 6P, but the one I own is the Nexus 5X. That said, I don't think this will affect the observations.
I have the N770 N800 N810 N900 N9 Nexus S, and now the Nexus 5P since a week. Of course the technology of the Nexus 5P completely surpass the N9, but from the UI point of view I found the Nexus S unusable even after upgrading to Android 4.3. The Nexus 5P is much better in many point but still far far away from the N9 UI design. Some random observations:
* The N9 always display the time and important status when his proximity sensor don't detect light reflection from a pocket. I just have to look at it to know the time and if I have a received a message, not even to touch it. The N9 laminated OLED display on curved edge glass have a ultra low power mode that allow to let some pixels in on state while the main processor is in sleep mode. The Nexus 5P need a least to be inclined for a least 1 second to make it display something. The Nexus 5P seem to be a LCD screen with a backlight on the the full surface even when displaying only the time.
* The N9 is outrageously conformable to hold in the hand. It has no corners in the contact of the hand and the transition from the case to the curved screen edge is almost imperceptible. Never found a better phone case design to date.
* The N9 react to a double tape on the screen with a finger by displaying a home screen and give direct access to the other main screens with a swipe in the good direction. The Nexus 5P is not reacting to any touch screen solicitation, the only way is to touch a button or the fingerprint scanner.
* The N9 UI navigation is deadly simple and extremely effective. Simply swipe from the edge of the screen from any application to go to the application menu, application switching menu, or the status feed screen. The Nexus 5P Marshmallow Android have the round and square button to do almost the same but it's less comfortable because there are at the bottom of the screen. The swipe of the N9 can be done anywhere along the edge of the screen, and when you use a single hand to hold and operate the device it's more quick and comfortable to swipe on the region near the top of the screen.
* The N9 allow to close an application by simply swipe it from the top to the bottom direction, so effective. The Marshmallow require to first go to the application switching menu.
* The N9 present a small view of the full applications screens in the application switching menu, in two selectable size. This make the selection of applications far more quick and easy than the rolling applications selector of Marshmallow.
* The N9 can act as a fully normal and very fast USB memory. I have not yes tried this with the Nuxus 5P (because his box don't include a USB type A cable), but I Android killed this feature sometime after the Nexus S. I found the two replacement protocols unstable and boringly slow on the Galaxy S3 for example.
* The N9 fully integrate the socials network into this core feature applications like only the last Android try to do. Still the way Skype is integrated into the N9 is vastly superior as the contacts and messages notifications are fully merged with the system. With the N9, the application or protocols used to send and receive call and messages are just a details on the configuration of the accounts settings. After that, the core system take care of the detail for you and present all the protocols with the same framework. From my point of view this was the most advanced feature of the N9, still far away ahead of the last Android.
Overall, the N9 is still a reference in surprisingly number of points even 5 years after his release and murder.
I don't see your points about who needs to participate and skipping, those was never the problem in the situation I observed.
The point is that if "agile" is not the solution, then we have to use an other method, proving by the way that "agile" is not related to "scrum". I was not talking about "agile", you introduced the notion in this context.
Real life is something different. There is a lot of situations where it's critically required to deliver a exploitable solution in a few days, if not in a few hours. In that stress it's unthinkable to talk about changing the design. And this is exactly in this kind of stressed situation that managers call for everyday scrum. I have observed that a number of times, and even, as a project leader, was sometimes contractually obliged to make this kind of scrum and to report the progress to the customer.
I agree. The reality is that not all tasks can be easily break down into smaller task before starting the development. An example is porting and integrating a existing code on a new platform. The only way to get the relevant information is to start working on it.
While scrum could be effective to prioritize a lot of small tasks that can be complete in a few hours, we found it useless in situation where a long task must be developed. In the later case the peoples try to say the minimum because there are afraid of hitting unexpected difficulties that will slow there work, and scrum is not a place to change the design, so there feel like in a trap.
As about a fork of systemd, the discussion could be constructive if a such fork will gain enough momentum to be analysed in real condition and give enough advantage to be considered. While the systemd haters have generated probably the most biggest forums pollution ever in the Linux community, there actually yield nothing that reach the level of something considered to be an alternative. A good chunk of them still believe that systemvinit should be enough for everyone. It's absolutely clear to me that nobody will use in 10 years the systemd we use today. Either because system will evolve, or because an other project will overtake it, exactly like it overtake upstart, that itself overtake systemvinit. Fact is that only projects where motivated peoples work on it could yield some result. I have yet to see something like a good systemd fork. As you claim to be an insider, give a reference.
You view of the chip manufacturer market is wrong. His client choose the OS, not him. I can't count the number of meetings with chip manufacturer representatives where I explained the minimal conditions to make there chip considered. On some projects I need a micro-controller to offload the main processors, or because low power operation mode can't be done with a processor with the capability to run something like Linux, like a 250 mico ampere mode in one project. For those micro-controller I don't even think using Linux. Even the manufactures development environment for micro-controllers need most of the time to be hacked to meet all the criteria, not counting the high bugs count to solve in the process. In 20 years I have never see a chip changed to be able to run Linux. What I have always see is that manufacturers roll out new chips family to meet many market segments, some of them requiring to run something like Linux.
There was gigantic advancement on how to design space rad hard technology in 30 years. Follow Actel (MIcrosemi) news, follow Xilinx news, follow Atmel (Dialog) news... and I am certain there is many others. Linux is not more space grade compliant that systemd, or than busybox or anything you might found in you busysbox or openebedded folders. If there eventually find a place in a space probe, it will only be for a auxiliary function that can tolerate to fail at a acceptable rate for the intended task. Simply because of the quality assurance process, it will be completely impossible to use Linux for anything close to the essential operations of a space probe. So your beat probably fail to even see his context become a reality.
Yes, the embedded ecosystem sometimes benefit from Linux, but not because Linux is done for embedded, but because some embedded systems reach the minimum feature to be able to run it. Contrary to your view, I see the device tree story a clear prof that Linux is really not driven by embedded. It toke more than 10 years to make Linus notice of the embedded platform configuration mess, simply because he absolutely don't care about it. But a some point the conditional configuration noise of the embedded platforms was unavoidable and exactly because the embedded contributors to Linux proved to be totally unable to agree on a solution, Linus put a definitive end on accepting any more commit until a clean solution is found. This very very clearly show that the embedded part of Linux is just a noise barely perceived from the real contributing part that drive the future of Linux.
15 years ago there was already a strong market for Linux embedded. We was selling routers, collaborate to make it run PBX, gateway etc.Intel was trying really hard to make there StrongARM the standard for routers running Linux. IBM was making the best ever support I have see in my carrier for Linux from big iron down to embedded chips. I don't know what you was doing 15 years ago, but from my side this was fantastic years. Was IBM called a "disruptive change" was really was we experienced on the terrain. A this time I managed a R&D department selling embedded Linux solutions, from small business, to telecom and space agency. This was the new stuff that everybody wanted, fast, primary because Linux was the best solution to add Internet capability to products.
The biggest part of Linux in term of line of code is the drivers support. So when I say "full Linux mainline support" this definitely includes the drivers for all the chips peripherals. That and a proper boot solution is what the manufacturer need to support.
You confuse the micro-controllers world withe the Linux world. The controllers you describes don't all uses processors, and most that use a processor don't run a full operating system like Linux but a very minimum task scheduler and memory allocation. If a few of them eventually run Linux, this is only because there was enough hardware resources to support it, really not because Linux shrink down to be able to run on a even more limited hardware. I actually don't know any example of controllers in your list running Linux. Please provides some references.
The Debian glibc story is far more complex, remember the EGLIBC project ? Actually now Debian is back to glibc, fully proving my point of view. The Device Tree Linux support is an implementation of the Power Architecture Platform Reference and initially not only for embedded system. His future is not so bright because ACPI for ARM i actively developed to replace it. It's a decade long term effort, but this show again that the future of Linux is not to stay with the minimum required to run a simple application on a minimal processor. You are right that the obligatory change for the embedded market go into the kernel, but don't rewrite the history in case of the device tree as it was Linus himself that set a total end definitive stop the the embedded support mess and strictly required that the embedded community start work on a coherent solution.
15 years ago I was talking to chip manufacturers that didn't know that Linux exists, and I followed closely how the situation changed over the years. There was a lot of wast in the process. Only a limited of manufacturers understand that the only things really needed today is full Linux mainline support and a full support to a good boot loader. If those is two parts are done the right way, making any build system or distributions run on it is very easy.
Yes there is a lot of embedded systems, but in number, only a fraction of them run Linux. Linux will not change in a fundamental way to replace the smallest of them, at least in the case of your description of "your PC at least a dozen different OS installations start up in various controllers" (I have big doubt that you can prove that on my PC).
Yes a lot wants to run Linux, and there pay close attention to make this possible by changing the way there design there chip, not by changing Linux to run on underpowered chip. Now there understand that there need to support a lot of memory compared to microcontrollers. Now there understand that there need a MMU. It's not a hazard if the ARM926 with MMU was one of the biggest success story.
Of course systemd will continue to change. It's already fairly modular despite what most reluctant claim. I have no problem with the documentation. 'man systemd' have the details and link to all the others useful related man page like 'man systemd.service'. From my experience the point where systemd really need a fast improvement is the log coherency. It's usable, bring good feature like the per unit log in ram, but can in some situations miss messages or combine them out of order between services and this can be annoying. This temporarily drawback is not enough to overcome all the advantage it bring to me.
We are now close to understand each other. The remaining difference is probably how much the market size of a embedded system do influence the community that develop Linux distributions. My observation is that this relation is actually insignificant and I see no sign that this will change in a near future. Even the vast android market have yield very small architectural change to the kernel, and most of them was just a way to merge back a feature duplicate that was developed independently of the mainline. On the layer above the kernel, Android basically just reuse the minimum of some existing projects to support his massive stack of almost everything. Andriod is without doubt the most extreme why to just use the Linux kernel and ditch almost all the rest, consequently it play no role in the definition and development of the future Linux distribution. The embedded projects you are talking about are somewhere in that direction from a Linux distribution point of view, while not as so extreme I agree. The market size is big, the project reuse what exists to support his precise applications, but make no influence to the future of Linux distributions. It this case just don't use systemd if don't bring advantage to you, but this yield no argument about the future of systemd evolution. Only the community that use systemd will play an roe in his evolution.
You can do it the other way by unpack the minimal set of package with bootstrap or multistrap. You might see how small a base system can be. Actually the dependencies help to remove (or not unpack) the libraries that are not required, exactly as in buildroot or openembedded, but far more faster as there are already compiled and ready to use. There are also more tested in a standard distribution, a important point to reach some quality in a system. I remember having to passed hours searching some breakage in buildroot because there is not enough testing done on it. I have not this problem anymore since I use a standard distribution.
Good for you if you have a such simple system to manage, but I design systems far more complex than that, requiring constant monitoring of every applications, low power operation mode, automatic restarting in case of unexpected events, remote management, and dynamic adaptation on hardware events. systemvinit is a total failure for this kind of system. systemd is really was I expected for years and in fact the parent management applications that was build over the time have some of basic features similar to upstart and to systemd, like the dependencies, dynamic mode, autorestart and monitoring. Gut it was not written to be generic.
Please understand that if you work on really simple system where systemd features bring nothing to you, the vast majority of others developers (not only for embedded systems) works on more complex systems that require something like systemd. One of the main benefit of systemd is that now the distribution developers and the applications developers have a nearly standard way to define there requirement and capabilities. It's a big step forward compared to the unsustainable systemvinit mess.
Slashdot Mirror
Did you realize that your are talking with the legitimate choice of French citizen ? For sure there are not your enemy, even if you disagree on how to act.As a Swiss citizen I would be more than happy to see France in a better political health. This could be a bit harsh to read for you, but I describes actual French political system as a "monarchie républicaine" that are not so far from the old "monarchie constitutionelle" and "monarchie absolue". Basically the the president have far too much power in the whole government system. This lay down to basic math:
When you have only a single party that can win the election, the system tend to make 50% peoples against the other 50%. The frustration is high, so any problem will make the believe that the opposition party will be better, so the system will oscillate near 50% frustration. After some cycle the peoples eventually realize that the two main parties never meet there goals, so a other one will gain support as the situation degrade. At some point you have 3 parties, and whenever to one that win he is almost granted to have near 66% of frustration against it. So it look like having 50% frustration is the best possible score? Wait!
In Switzerland, instead of a president, we experience since more than 150 years a federal council composed on 7 peoples from a range of leading parties. This make the vast majority of the peoples with different political orientation represented up to the head of state. The frustration is then lowered to the the peoples that don't have representation, probably below 20%.
Just winning an election is not enough, you still have to negotiate with the others to make a positive move.
I tested kernel up to 4.2 with earlyprintk=efi and everything is ok up to the point where the console take over the earlyprintk. Seem to be something wrong at setting the screen, but nomodeset i915.modeset=0 don't help.
I just buy a cheap notebook based on the Atom Z3735F 1.3GHz, 2G of DDR and 64G of eMMC. While the processor is 64 bits, the UEFI is for 32 bits only, so no easy way to install a 64 bit Linux distribution on it. First step was to go into the UEFI setup to disable the secure boot, then...
I tried Ubuntu 15.10 32 bits, and the installer don't even boot from a USB memory.
I tried Debian 8.2 32 bits, the installer booted from the USB memory up to the selection menu, but whenever I chose the text or graphic installer, the screen go black with flashing small white lines across the screen, a bit like a old CRT that lost the synchronization.
I tried the last daily Debian installer without more success.
So no chance for me. The workaround was to install Debian 8.2 32 bits inside VirtualBox on top of Windows 10.
My conclusion is that very cheap notebook are designed for 32 bits Windows 10 only and that nothing is tested to allow installing a Linux distribution.
Seriously, there is no knives in any kitchens in those jurisdictions ???
Every children could take a knife in a kitchen, and most of those knife will probably be more lethal than a plastic gun, without any building effort.
GPS and PTP both broadcast TAI and UTC-TAI that sum up the past leap seconds, so your claim is not completely correct. I will add that GPS and PTP both lack a method to broadcast the leap second history table required to safely compute time in the past at the second precision. NTP need a major protocol upgrade to fix his multiples issues, or PTP need to be broadcasted as NTP is today.
It's not the usual process of ITU decision that is the cause of the rejection. The cause is the fact that the proposition itself is stupid and make the problem even worst. To be certain that the programmers take seriously the fact that the duration of day is variable the adjustment code path must occur more often. The most effective way will be to define the civil time by a day counter and a offset since the start of that day. The day duration can be adjusted periodically. The programmed will know that the day is not 86400 second and the day increment code path will be tested every night.
1) Will lead to many more confusion between the two type of seconds.
2) Will break the ancestral definition of time in all the civilization that ever existed.
3) The only way and nobody is seriously make any other proposition. The discussion is how to improve it because the leap second is rare enough to make too many programmers not taking it seriously enough and testing is enough.
So the solution is certainly not to make the adjustment more rare, but more often. My proposal is to define the civil time by a day counter and a offset since the start of that day. The day duration can be adjusted periodically to match the average earth rotation and the day increment will occur every night so the programmed need to be aware of it and can test it every night. As a bonus it will work on any planets.
I think we need to switch to a day counter and a offset since the beginning of that day to match the physical reality of the earth rotation.
Yes this will make the programmer lazy about the problem and a big mess when the first change take reality. I largely prefer a model with a day counter and a time offset since the start of that day, so the day duration can be adjusted to the physical reality of the earth rotation. The advantage is that the programmer can test the day increment every night.
The current leap second system is still enough for many centuries and even several thousand of years is the leap seconds are allowed every months or weeks.
Is you think about this more deeply you will realize that the best model will be to have what we actually call UTC defined in term of days counter since a epoch date and a second counter since the start of that day. This will allow to adjust periodically the day duration to the reality of the average earth rotation. Not only this model work with the earth rotation any time in his history, but it will work with any planets.
But no matter what, programmer that can't directly use TAI only will have to deal with variable day duration and historical day duration table. At least it will be more easy to test because the difficult part occur every day.
Yet no one have found a better way to coordinate some important aspect of the worldwide telecommunication infrastructure. Keep in mind that there have to deal with governments with opposed sensibility or in conflict.
The industrial/embedded systems you describes must use TAI, not UTC or local time. Actually only the GPS broadcast the TAI in a direct usable form nearly everywhere. NTP broadcast UTC only and fail to send the TAI to UTC offset. PTP doe the right thing but is actually not broadcasted as NTP or GPS is.
Exactly, you got it right. What's depressing is that, even after decades, POSIX is still unfixed.
Sorry, in the previous comment I have wrote "Nexus 5P" while I must have wrote "Nexus 5X". I was confused by the Nexus 6P, but the one I own is the Nexus 5X. That said, I don't think this will affect the observations.
I have the N770 N800 N810 N900 N9 Nexus S, and now the Nexus 5P since a week. Of course the technology of the Nexus 5P completely surpass the N9, but from the UI point of view I found the Nexus S unusable even after upgrading to Android 4.3. The Nexus 5P is much better in many point but still far far away from the N9 UI design. Some random observations:
* The N9 always display the time and important status when his proximity sensor don't detect light reflection from a pocket. I just have to look at it to know the time and if I have a received a message, not even to touch it. The N9 laminated OLED display on curved edge glass have a ultra low power mode that allow to let some pixels in on state while the main processor is in sleep mode. The Nexus 5P need a least to be inclined for a least 1 second to make it display something. The Nexus 5P seem to be a LCD screen with a backlight on the the full surface even when displaying only the time.
* The N9 is outrageously conformable to hold in the hand. It has no corners in the contact of the hand and the transition from the case to the curved screen edge is almost imperceptible. Never found a better phone case design to date.
* The N9 react to a double tape on the screen with a finger by displaying a home screen and give direct access to the other main screens with a swipe in the good direction. The Nexus 5P is not reacting to any touch screen solicitation, the only way is to touch a button or the fingerprint scanner.
* The N9 UI navigation is deadly simple and extremely effective. Simply swipe from the edge of the screen from any application to go to the application menu, application switching menu, or the status feed screen. The Nexus 5P Marshmallow Android have the round and square button to do almost the same but it's less comfortable because there are at the bottom of the screen. The swipe of the N9 can be done anywhere along the edge of the screen, and when you use a single hand to hold and operate the device it's more quick and comfortable to swipe on the region near the top of the screen.
* The N9 allow to close an application by simply swipe it from the top to the bottom direction, so effective. The Marshmallow require to first go to the application switching menu.
* The N9 present a small view of the full applications screens in the application switching menu, in two selectable size. This make the selection of applications far more quick and easy than the rolling applications selector of Marshmallow.
* The N9 can act as a fully normal and very fast USB memory. I have not yes tried this with the Nuxus 5P (because his box don't include a USB type A cable), but I Android killed this feature sometime after the Nexus S. I found the two replacement protocols unstable and boringly slow on the Galaxy S3 for example.
* The N9 fully integrate the socials network into this core feature applications like only the last Android try to do. Still the way Skype is integrated into the N9 is vastly superior as the contacts and messages notifications are fully merged with the system. With the N9, the application or protocols used to send and receive call and messages are just a details on the configuration of the accounts settings. After that, the core system take care of the detail for you and present all the protocols with the same framework. From my point of view this was the most advanced feature of the N9, still far away ahead of the last Android.
Overall, the N9 is still a reference in surprisingly number of points even 5 years after his release and murder.
I don't see your points about who needs to participate and skipping, those was never the problem in the situation I observed.
The point is that if "agile" is not the solution, then we have to use an other method, proving by the way that "agile" is not related to "scrum". I was not talking about "agile", you introduced the notion in this context.
Real life is something different. There is a lot of situations where it's critically required to deliver a exploitable solution in a few days, if not in a few hours. In that stress it's unthinkable to talk about changing the design. And this is exactly in this kind of stressed situation that managers call for everyday scrum. I have observed that a number of times, and even, as a project leader, was sometimes contractually obliged to make this kind of scrum and to report the progress to the customer.
I agree. The reality is that not all tasks can be easily break down into smaller task before starting the development. An example is porting and integrating a existing code on a new platform. The only way to get the relevant information is to start working on it.
While scrum could be effective to prioritize a lot of small tasks that can be complete in a few hours, we found it useless in situation where a long task must be developed. In the later case the peoples try to say the minimum because there are afraid of hitting unexpected difficulties that will slow there work, and scrum is not a place to change the design, so there feel like in a trap.
As about a fork of systemd, the discussion could be constructive if a such fork will gain enough momentum to be analysed in real condition and give enough advantage to be considered. While the systemd haters have generated probably the most biggest forums pollution ever in the Linux community, there actually yield nothing that reach the level of something considered to be an alternative. A good chunk of them still believe that systemvinit should be enough for everyone. It's absolutely clear to me that nobody will use in 10 years the systemd we use today. Either because system will evolve, or because an other project will overtake it, exactly like it overtake upstart, that itself overtake systemvinit. Fact is that only projects where motivated peoples work on it could yield some result. I have yet to see something like a good systemd fork. As you claim to be an insider, give a reference.
You view of the chip manufacturer market is wrong. His client choose the OS, not him. I can't count the number of meetings with chip manufacturer representatives where I explained the minimal conditions to make there chip considered. On some projects I need a micro-controller to offload the main processors, or because low power operation mode can't be done with a processor with the capability to run something like Linux, like a 250 mico ampere mode in one project. For those micro-controller I don't even think using Linux. Even the manufactures development environment for micro-controllers need most of the time to be hacked to meet all the criteria, not counting the high bugs count to solve in the process. In 20 years I have never see a chip changed to be able to run Linux. What I have always see is that manufacturers roll out new chips family to meet many market segments, some of them requiring to run something like Linux.
There was gigantic advancement on how to design space rad hard technology in 30 years. Follow Actel (MIcrosemi) news, follow Xilinx news, follow Atmel (Dialog) news... and I am certain there is many others. Linux is not more space grade compliant that systemd, or than busybox or anything you might found in you busysbox or openebedded folders. If there eventually find a place in a space probe, it will only be for a auxiliary function that can tolerate to fail at a acceptable rate for the intended task. Simply because of the quality assurance process, it will be completely impossible to use Linux for anything close to the essential operations of a space probe. So your beat probably fail to even see his context become a reality.
http://blog.aurel32.net/175
Yes, the embedded ecosystem sometimes benefit from Linux, but not because Linux is done for embedded, but because some embedded systems reach the minimum feature to be able to run it. Contrary to your view, I see the device tree story a clear prof that Linux is really not driven by embedded. It toke more than 10 years to make Linus notice of the embedded platform configuration mess, simply because he absolutely don't care about it. But a some point the conditional configuration noise of the embedded platforms was unavoidable and exactly because the embedded contributors to Linux proved to be totally unable to agree on a solution, Linus put a definitive end on accepting any more commit until a clean solution is found. This very very clearly show that the embedded part of Linux is just a noise barely perceived from the real contributing part that drive the future of Linux.
15 years ago there was already a strong market for Linux embedded. We was selling routers, collaborate to make it run PBX, gateway etc.Intel was trying really hard to make there StrongARM the standard for routers running Linux. IBM was making the best ever support I have see in my carrier for Linux from big iron down to embedded chips. I don't know what you was doing 15 years ago, but from my side this was fantastic years. Was IBM called a "disruptive change" was really was we experienced on the terrain. A this time I managed a R&D department selling embedded Linux solutions, from small business, to telecom and space agency. This was the new stuff that everybody wanted, fast, primary because Linux was the best solution to add Internet capability to products.
The biggest part of Linux in term of line of code is the drivers support. So when I say "full Linux mainline support" this definitely includes the drivers for all the chips peripherals. That and a proper boot solution is what the manufacturer need to support.
You confuse the micro-controllers world withe the Linux world. The controllers you describes don't all uses processors, and most that use a processor don't run a full operating system like Linux but a very minimum task scheduler and memory allocation. If a few of them eventually run Linux, this is only because there was enough hardware resources to support it, really not because Linux shrink down to be able to run on a even more limited hardware. I actually don't know any example of controllers in your list running Linux. Please provides some references.
The Debian glibc story is far more complex, remember the EGLIBC project ? Actually now Debian is back to glibc, fully proving my point of view. The Device Tree Linux support is an implementation of the Power Architecture Platform Reference and initially not only for embedded system. His future is not so bright because ACPI for ARM i actively developed to replace it. It's a decade long term effort, but this show again that the future of Linux is not to stay with the minimum required to run a simple application on a minimal processor. You are right that the obligatory change for the embedded market go into the kernel, but don't rewrite the history in case of the device tree as it was Linus himself that set a total end definitive stop the the embedded support mess and strictly required that the embedded community start work on a coherent solution.
15 years ago I was talking to chip manufacturers that didn't know that Linux exists, and I followed closely how the situation changed over the years. There was a lot of wast in the process. Only a limited of manufacturers understand that the only things really needed today is full Linux mainline support and a full support to a good boot loader. If those is two parts are done the right way, making any build system or distributions run on it is very easy.
Yes there is a lot of embedded systems, but in number, only a fraction of them run Linux. Linux will not change in a fundamental way to replace the smallest of them, at least in the case of your description of "your PC at least a dozen different OS installations start up in various controllers" (I have big doubt that you can prove that on my PC).
Yes a lot wants to run Linux, and there pay close attention to make this possible by changing the way there design there chip, not by changing Linux to run on underpowered chip. Now there understand that there need to support a lot of memory compared to microcontrollers. Now there understand that there need a MMU. It's not a hazard if the ARM926 with MMU was one of the biggest success story.
Of course systemd will continue to change. It's already fairly modular despite what most reluctant claim. I have no problem with the documentation. 'man systemd' have the details and link to all the others useful related man page like 'man systemd.service'. From my experience the point where systemd really need a fast improvement is the log coherency. It's usable, bring good feature like the per unit log in ram, but can in some situations miss messages or combine them out of order between services and this can be annoying. This temporarily drawback is not enough to overcome all the advantage it bring to me.
We are now close to understand each other. The remaining difference is probably how much the market size of a embedded system do influence the community that develop Linux distributions. My observation is that this relation is actually insignificant and I see no sign that this will change in a near future. Even the vast android market have yield very small architectural change to the kernel, and most of them was just a way to merge back a feature duplicate that was developed independently of the mainline. On the layer above the kernel, Android basically just reuse the minimum of some existing projects to support his massive stack of almost everything. Andriod is without doubt the most extreme why to just use the Linux kernel and ditch almost all the rest, consequently it play no role in the definition and development of the future Linux distribution. The embedded projects you are talking about are somewhere in that direction from a Linux distribution point of view, while not as so extreme I agree. The market size is big, the project reuse what exists to support his precise applications, but make no influence to the future of Linux distributions. It this case just don't use systemd if don't bring advantage to you, but this yield no argument about the future of systemd evolution. Only the community that use systemd will play an roe in his evolution.
You can do it the other way by unpack the minimal set of package with bootstrap or multistrap. You might see how small a base system can be. Actually the dependencies help to remove (or not unpack) the libraries that are not required, exactly as in buildroot or openembedded, but far more faster as there are already compiled and ready to use. There are also more tested in a standard distribution, a important point to reach some quality in a system. I remember having to passed hours searching some breakage in buildroot because there is not enough testing done on it. I have not this problem anymore since I use a standard distribution.
Good for you if you have a such simple system to manage, but I design systems far more complex than that, requiring constant monitoring of every applications, low power operation mode, automatic restarting in case of unexpected events, remote management, and dynamic adaptation on hardware events. systemvinit is a total failure for this kind of system. systemd is really was I expected for years and in fact the parent management applications that was build over the time have some of basic features similar to upstart and to systemd, like the dependencies, dynamic mode, autorestart and monitoring. Gut it was not written to be generic.
Please understand that if you work on really simple system where systemd features bring nothing to you, the vast majority of others developers (not only for embedded systems) works on more complex systems that require something like systemd. One of the main benefit of systemd is that now the distribution developers and the applications developers have a nearly standard way to define there requirement and capabilities. It's a big step forward compared to the unsustainable systemvinit mess.