Technically, the 32-bit signed integer that holds the Unix seconds value overflows and goes negative! It does not overflow to zero. Which means some systems will jump back in time to 1970 - 68 = 1902.
Note that Y2038 failures will start to manifest themselves when attempts are made to set timers past the overflow date. Therefore, failures will start to appear before the actual overflow date.
Any system calls, protocols and file systems that use 32-bit signed absolute time fields will also be impacted. Therefore, 64-bit systems are not immune to Y2038 due to inter-operability support for other systems and non-compliant 32-bit applications.
In particular, the automobile industry is going to be at high risk of hitting Y2038 failures as vehicles built today may still be on the road in 2038.
I note that Linux v5.0 introduced some Y2038 compliant fixes which removed get_timeofday(). This promptly broke a 3rd party kernel loadable module that relied on the now non-existent get_timeofday(). Therefore the Y2038 havoc has already started...
Also it is not possible to set a smartphone past the year 2036. So currently Y2038 on smartphones has been "fixed" by not allowing the smartphone to get too close to the year 2038!
In fact, it's natural gas that's killing off nuclear power as we know it now.
... and revenge is coming as grid battery storage is killing off natural gas peaker plants due to batteries having faster response times and lower cost. The energy coming from nuclear and renewables.
Also distributed battery storage will benefit nuclear power such as electric vehicles during the night as the off-peak baseload level will increase.
I work in the embedded Linux software industry and many of the engineer's run a Linux desktop with VMware Workstation Pro providing access to a Windows 10 VM on the rare occasions that either our customers or corporate IT has used a non-cross-platform solution for something.
Each engineer does their own thing despite local IT providing the possibility of supplying Ubuntu, RHEL, CentOS or SuSE. The issue with these Linux distributions is that they tend to be for servers and can be far from the bleeding edge of technology so not being compatible with the latest Dell laptops.
Our local IT does attempt to support Linux desktops and contacts their 3rd party suppliers to get at least support for an Ubuntu desktop and other Linux based servers.
For work, I am using 64-bit Fedora 28 KDE but I sometimes find it is too near the bleeding edge which can break 3rd party programs. For example, Fedora 28 KDE is now using Linux v5.0.5 which now breaks my VMware Workstation Pro 15 because the VMware kernel modules fail to compile for kernel v5.0.5. I will stick with v4.20.17 as VMware works for that kernel.
I personally use 64-bit Mageia 6 as it is in the middle ground of being recent but far enough away from the bleeding edge so things remain working.
The other issue of selecting a Linux distribution is that there are 2 main package management systems; RPM vs DEB and each distribution has their own high-level tools to manage the installation of packages. So if you switch distributions then you have to get to grips with the distribution's suite of tools which can take some efforts.
I am waiting for corporate IT to fall into the trap of specifying "Windows Subsystem for Linux" as being a Linux solution that will "help us" engineers, NOT.
A hydrogen car has an electric drivetrain, a small battery, a fuel cell and a hydrogen tank.
A battery electric car (BEV) has an electric drivetrain and a big battery.
Hydrogen cars are losing the battle against BEVs for the following reasons:
1. The fuel cell and hydrogen tank are not needed in a BEV so this cost and mass are avoided. Instead a BEV is dependent on deploying a battery with a high storage capability (up to 100kWh) with a high power output.
2. A BEV will have a better 0 to 60 MPH rating than a hydrogen car because the fuel cell cannot provide the needed high power output for fast acceleration. Hydrogen cars use a small battery to supply power during periods of high power demand. As battery technology improves, the hydrogen car becomes nearer to being a pure BEV which increases the risk of the fuel cell and hydrogen tank being redundant.
3. A BEV can be charged from anywhere there is a suitable power socket including a domestic house. A hydrogen car requires a hydrogen refuelling station which are rare. Therefore, BEVs already have a better charging infrastructure than hydrogen refuelling stations.
4. Hydrogen needs to be compressed which takes energy and also the hydrogen tank must be designed to be safe during car crashes. BEVs can catch fire in a car crash due to the battery being damaged, however, the probability of a BEV catching fire is less than the probability of an ICE car catching fire.
5. Hydrogen takes energy to be created such as via electrolysis. This energy reduces the overall efficiency of a hydrogen car. If water is used to generate hydrogen using electrolysis then a source of water is needed which will have an environmental impact. Hydrogen can also be generated from industrial fossil fuel processes but this hydrogen would need to be transported to the hydrogen refuelling stations so having an environmental impact.
6. Only a handful of car manufacturers are building hydrogen fuel cell cars and these cars have a very small share of the electric car market. The race to hydrogen fuel cell cars has already been lost to BEVs.
7. There is a race in the electric semi-tractor market between hydrogen fuel cell and BEV. This market has not yet decided which technology will win. Hydrogen may get a foothold in this market because sending freight travels along defined routes so only a few hydrogen refuelling stations are needed to support a freight route. But on the other hand, battery technology is continuing to improve which could eliminate the fuel cell.
The reason people stay with the coal, natural gas, and fossil fuels is COST! Oh electric cars? Yeah you recharge them from what? an outlet? Where is IT getting it's electricity. Oh yeah form one of those big bad coal, natural gas or fossil fuel electric plants. So tell me how they are saving the environment?
The accuracy of this claim depends on which country you are in. The biggest market per capita for electric cars is Norway where the electricity grid is 98% hydro-electric. Therefore, this claim fails for Norway. In France the electricity grid is 75% Nuclear and so your claim is also invalid for France. Renewable energy deployment in Europe is increasing each year which means your claim becomes more inaccurate each year. There are countries in Europe such as Poland that have a high percentage of electricity generated from coal but even for Poland it is better to generate the pollution at the rural coal fired power station than in the cities where the population lives. Therefore, electric cars will still benefit countries that use coal as pollution from ICE cars in cities will be reduced.
Peak electricity demand during the 24 hours of a day will still decline when electric cars are widely deployed. Electric car owners will be incentivised to use cheaper off-peak electricity tariffs during the night. Therefore, the minimum electricity demand will increase during the night to charge up electric cars. This will benefit the Nuclear industry and wind industry by allowing the baseload limit to be increased to accommodate electric cars. It is likely that the number of power plants will go down despite electric cars being deployed.
If a battery is deployed in a domestic house then this house battery can be charged via solar panels and / or using a cheaper off-peak electricity tariff. This house battery can be used to charge an electric car during periods of peak grid electricity demand but the owner will be not be paying the higher peak electricity tariff due to the time displacement provided by the house battery, Also the owner may be able to sell some of the electricity stored in the house battery and electric car back to the grid during peak grid electricity demand.
The key to making the electricity grid more efficient is to deploy storage such as batteries onto the grid. Grid batteries will also kill off natural gas peaker plants as was observed in Australia after the Tesla grid battery was deployed.
Power can be transferred via microwaves from a satellite. Alternatively, use a big mirror in space to beam light down to the surface and collect this light using a solar furnace or a solar farm. In this case, solar will work during the night!!
However, it is a bit too close to being a James Bond villain's weapon.
In the UK it is legal to drive a car if you only have 1 good working eye. Therefore, from a legal point of view, you don't need 2 eyes to drive. Of course, there may be a performance impact to using only 1 eye, but the law allows those affected people to still drive.
Also we don't know how our brains work but we still use our brains.
If you go back in history, many technologies have been deployed without the knowledge of how the technology works.
Just look at how medicines are created, if a compound was shown to improve a patient's outcome and had an acceptable level of side-effects then doctors can use the medicine. The doctors don't need to know how the medicine works to deploy treatments that scientifically are known to work.
Therefore, black box Neural Nets can be treated just like a human driver by presenting data inputs and evaluating the outputs. The innards of the system don't need to be understood to demonstrate their capabilities in the real-world. As long as the Neural Net has a higher probability of success than a human driver then the Neural Net will reduce deaths. The Neutral Net does not need to be 100% safe, it just needs to be better than a human.
In the UK at least, councils monitor where people are killed on the roads and where possible, modifications to road layouts are done to reduce the likelihood of future fatal crashes at those locations. The same processes will happen for autonomous vehicle fatal crashes. Designs of roads will gradually evolve over the years as has always been the case in the UK.
The Boeing MCAS system is used when autopilot is OFF. Boeing's MCAS system is an aid to manual flying to make the plane behave similar to the older generation of 737s. Boeing's design flaw was to use a single input to provide the angle of attack value which caused a garbage in garbage out scenario. Worse still, the MCAS system repeatedly triggered causing the vertical elevator to eventually reach maximum end of travel.
Boeing's design flaw could easily be predicted as having a potential for crashing the plane based on only 1 sensor having been used. In fact, the plane had 2 angle of attack sensors available and the black box data shows that there was a difference of 20 degrees in the 2 sensors when the plane was on the ground! So even without simulating the design, best engineering practise shows that Boeing was negligent in designing a fit for purpose system.
Boeing's "bug fix" is now to use both angle of attack sensors, to not allow the system to repeatedly trigger and to flag up on the instruments that a data anomaly had been detected so that the pilots in future could become aware of a system malfunction.
I would agree that a similarity between Tesla's autopilot and Boeing's MCAS system is that the users do not understand how these system work at the extremes of their design envelopes. A user needs to experience the system's limitations in order to be ready to take over but then it could be too late and fatal.
In terms of specific protocols, NTP isn't actually that bad since it works on timestamp deltas, not absolute values. Depending on how badly the client is written you can still get problems going to the native date encoding if it's 32-bit, but it's not the hard-fail that it would appear to be.
The NTP Y2036 issue can become a hard-fail as follows:
NTP v4 uses an EPOCH of 1 January 1900 and rolls over on 7th February 2036. This is a time range of 136 years (2^32 seconds). NTP can cope with time deltas that span +/- 68 years (68 x 2 = 136 years). After the roll-over occurs in 2036, the NTP client needs to know that it is in the new time era (new NTP EPOCH date of 7th February 2036) but old software may assume the original NTP EPOCH of 1 January 1900. NTP only passes time deltas but flags in the protocol may be used to identify the NTP EPOCH era, however, old NTP clients might not of implemented this workaround.
It was standard practice for Linux systems to initialise the system clock to the UNIX EPOCH date of 1st January 1970 (system clock starts at 0) which subsequently got updated during boot-up via a real-time clock (RTC) and/or NTP. The 68 year maximum delta + the UNIX EPOCH date of 1st January 1970 gives a maximum resolvable date in 2038. But if the NTP client assumes the original NTP EPOCH of 1 January 1900 due to the Y2036 role-over then 1900 is more than 68 years from 1970 and this gap cannot be correctly represented. There are many embedded systems that do not have an RTC so without mitigation (see below), these systems cannot set correct dates after Y2036 hits.
To compound this issue, Y2038 hits preventing correct dates from being used anyway. Systems may be using erroneous dates around 1900 or 1970.
The NTP v4 failure mode has been mitigated against by no longer initialising the system clock to the UNIX EPOCH date of 1st January 1970 during boot-up, instead the system clock is initialised to the build time and date of the kernel. This reduces the risk of the NTP 68 year maximum time delta from being exceeded as it is unlikely that the same kernel is in use for 68 years (but you never know). Some systems also save the system clock value upon shutdown and set the system clock back to this value when booting-up. This migration should cause the NTP client to use the new NTP EPOCH because dates earlier than the build date are invalid as the build date can be relied upon as being a valid snapshot in time.
I agree with you, you repeated my point. I should of been clearer that the 7th January was the Gregorian date which is equivalent to 25th December in the Julian calendar.
To be pedantic, 110v AC is the average voltage using the RMS (Root Mean Square) equation. RMS represents the equivalent DC voltage of the AC voltage by averaging out the sinusoidal AC curve into an equivalent steady straight DC curve.
You are imprecise, the peak voltage for 110v AC is not 110v..
110v AC is an RMS (Root Mean Square) value which represents the equivalent steady DC value of the voltage. In other words, the peak voltage of 110v AC is 110 x square root of 2 = 156v peak.
RMS is used because old analogue voltmeters averaged out the AC voltage and could not display the peak voltage. Also RMS is used so you can calculate the power output (voltage x current) of a resistive electrical heater and it is equivalent to feeding in a DC voltage and current of the same values as RMS. In other words, a 1kW resistive heater can produce that same average power at 110v AC at 9.1A AC and 110v DC at 9.1A DC.
It is all to do with areas under a sinusoidal curve versus the area under a steady line curve. RMS converts the area under the sinusoidal curve into the same area under a steady line curve.
kilobyte being 1000 is a marketing term used by hard disk manufacturers to make their drives look bigger. kilobyte being 1024 is a scientific mathematical term used to represent 2 power of 10 (2^10) commonly used for computer memory sizes. It uses the binary system used in digital computers.
You missed out the UK which uses miles per hour (MPH) for traffic speeds. I think you will find that MPH is a British Imperial measurement.
In the UK, both Imperial and Metric systems run in parallel except where it is too expensive to convert to metric such as traffic speed and distance signs. For example, supermarkets have to put both Imperial and Metric measurements on their goods. However, if you go to a town market place, food is often only sold in Imperial measurements because it is traditional. Some things are only sold in metric units such as petrol which is sold in litres. The UK can be a confusing place.
If your CCTV relies on NTP (Internet time protocol) then NTP rolls-over in 2036 and this is called the Y2036 issue. Then Y2038 hits on top of Y2036. Good luck with getting the correct date after that.
The Y2038 issue is not restricted to time_t 64 bits so a simple upgrade to using 64-bit operating systems helps but is not the full solution. For example, filesystem timestamps and Internet protocols that use timestamps will need validating for Y2038. In other words, there will be inter-operability issues to be fixed such as the NTP Internet time protocol (Y2036 + Y2038 issues).
The work on Linux includes modifying the 32-bit Linux system calls to use 64-bit time variables. In the future, this will allow 32-bit glibc to be modified to use these new Y2038 tolerant system calls. But in addition, 32-bit applications will need modifying to use the new glibc library calls.
Linux has not missed the opportunity. Linux will be supporting upgraded 32-bit applications to run on a 32-bit or 64-bit Linux kernel via a 32-bit glibc.
Due to the closed source binary only nature of the Windows Eco-system, I expect many 32-bit applications will not be compliant for Y2038.
I am guessing that the reference to 1753 is the switch-over from the Julian calendar to the Gregorian calendar but depending on your country the switch-over happened on different dates over a period of 3.5 centuries.
I presume that computers use the Gregorian calendar for all dates including before the Gregorian calendar was invented in October 1582. I always wondered whether historians converted historical dates to the Gregorian calendar. For example, Christ's birthday of 25th December is the Gregorian calendar date but some counties such as Russia use the 7th January as Christ's birthday because that is the old calendar equivalent date.
Also 0001-01-01 never was a real date because the Gregorian calendar never existed at that time. 1 BC used the Julian calendar and there is a mismatch in days between the Gregorian and Julian calendars due to the different lengths of each of their "years" plus various leap days. I suspect that 0001-01-01 is in 1 BC because of this mismatch.
The so-called "mole" is an impact pile driver. A small mass is moved up inside the "mole" to gain potential energy by compressing against a spring. After releasing the mass, the potential energy is converted to kinetic energy due to acceleration by the spring. Upon impact with the inside of the base of the "mole", the kinetic energy is converted into work done (force x distance) by a change in momentum (force x time = mass x velocity (before impact) - mass x velocity (after impact)) which causes the "mole" to apply a force (impulse) into the soil to cause the "mole" to move further into the soil.
The amount of electrical power (rate of change of energy) is low to compress the spring over say 20 seconds. But when the mass is released, the mechanical power is high due to the short time period say 0.25 seconds for the stored potential energy to be converted. This solution has the benefit of using a sustained about of low electrical power to arm the "mole" so the electrical power budget can be low. A disadvantage is that burrowing will be slow due to the low repetition rate per minute of firing the "mole".
Advantages of the "mole" over a drill is that the "mole" has no moving external parts and can change angle due to hitting rocks as it burrows down. The tail of the "mole" has temperature sensors so a temperature profile of the soil can be acquired.
You mean LHD (Left-hand drive) in Western Continental Europe. The UK is still waiting for RHD (Right-hand drive) Model 3s to start production which is expected to start in the 2nd quarter this year.
Slashdot Mirror
Technically, the 32-bit signed integer that holds the Unix seconds value overflows and goes negative! It does not overflow to zero. Which means some systems will jump back in time to 1970 - 68 = 1902.
Note that Y2038 failures will start to manifest themselves when attempts are made to set timers past the overflow date. Therefore, failures will start to appear before the actual overflow date.
Any system calls, protocols and file systems that use 32-bit signed absolute time fields will also be impacted. Therefore, 64-bit systems are not immune to Y2038 due to inter-operability support for other systems and non-compliant 32-bit applications.
In particular, the automobile industry is going to be at high risk of hitting Y2038 failures as vehicles built today may still be on the road in 2038.
I note that Linux v5.0 introduced some Y2038 compliant fixes which removed get_timeofday(). This promptly broke a 3rd party kernel loadable module that relied on the now non-existent get_timeofday(). Therefore the Y2038 havoc has already started...
Also it is not possible to set a smartphone past the year 2036. So currently Y2038 on smartphones has been "fixed" by not allowing the smartphone to get too close to the year 2038!
In fact, it's natural gas that's killing off nuclear power as we know it now.
... and revenge is coming as grid battery storage is killing off natural gas peaker plants due to batteries having faster response times and lower cost. The energy coming from nuclear and renewables.
Also distributed battery storage will benefit nuclear power such as electric vehicles during the night as the off-peak baseload level will increase.
I work in the embedded Linux software industry and many of the engineer's run a Linux desktop with VMware Workstation Pro providing access to a Windows 10 VM on the rare occasions that either our customers or corporate IT has used a non-cross-platform solution for something.
Each engineer does their own thing despite local IT providing the possibility of supplying Ubuntu, RHEL, CentOS or SuSE. The issue with these Linux distributions is that they tend to be for servers and can be far from the bleeding edge of technology so not being compatible with the latest Dell laptops.
Our local IT does attempt to support Linux desktops and contacts their 3rd party suppliers to get at least support for an Ubuntu desktop and other Linux based servers.
For work, I am using 64-bit Fedora 28 KDE but I sometimes find it is too near the bleeding edge which can break 3rd party programs. For example, Fedora 28 KDE is now using Linux v5.0.5 which now breaks my VMware Workstation Pro 15 because the VMware kernel modules fail to compile for kernel v5.0.5. I will stick with v4.20.17 as VMware works for that kernel.
I personally use 64-bit Mageia 6 as it is in the middle ground of being recent but far enough away from the bleeding edge so things remain working.
The other issue of selecting a Linux distribution is that there are 2 main package management systems; RPM vs DEB and each distribution has their own high-level tools to manage the installation of packages. So if you switch distributions then you have to get to grips with the distribution's suite of tools which can take some efforts.
I am waiting for corporate IT to fall into the trap of specifying "Windows Subsystem for Linux" as being a Linux solution that will "help us" engineers, NOT.
Now Hydrogen cars are the solution!
A hydrogen car has an electric drivetrain, a small battery, a fuel cell and a hydrogen tank.
A battery electric car (BEV) has an electric drivetrain and a big battery.
Hydrogen cars are losing the battle against BEVs for the following reasons:
1. The fuel cell and hydrogen tank are not needed in a BEV so this cost and mass are avoided. Instead a BEV is dependent on deploying a battery with a high storage capability (up to 100kWh) with a high power output.
2. A BEV will have a better 0 to 60 MPH rating than a hydrogen car because the fuel cell cannot provide the needed high power output for fast acceleration. Hydrogen cars use a small battery to supply power during periods of high power demand. As battery technology improves, the hydrogen car becomes nearer to being a pure BEV which increases the risk of the fuel cell and hydrogen tank being redundant.
3. A BEV can be charged from anywhere there is a suitable power socket including a domestic house. A hydrogen car requires a hydrogen refuelling station which are rare. Therefore, BEVs already have a better charging infrastructure than hydrogen refuelling stations.
4. Hydrogen needs to be compressed which takes energy and also the hydrogen tank must be designed to be safe during car crashes. BEVs can catch fire in a car crash due to the battery being damaged, however, the probability of a BEV catching fire is less than the probability of an ICE car catching fire.
5. Hydrogen takes energy to be created such as via electrolysis. This energy reduces the overall efficiency of a hydrogen car. If water is used to generate hydrogen using electrolysis then a source of water is needed which will have an environmental impact. Hydrogen can also be generated from industrial fossil fuel processes but this hydrogen would need to be transported to the hydrogen refuelling stations so having an environmental impact.
6. Only a handful of car manufacturers are building hydrogen fuel cell cars and these cars have a very small share of the electric car market. The race to hydrogen fuel cell cars has already been lost to BEVs.
7. There is a race in the electric semi-tractor market between hydrogen fuel cell and BEV. This market has not yet decided which technology will win. Hydrogen may get a foothold in this market because sending freight travels along defined routes so only a few hydrogen refuelling stations are needed to support a freight route. But on the other hand, battery technology is continuing to improve which could eliminate the fuel cell.
The reason people stay with the coal, natural gas, and fossil fuels is COST! Oh electric cars? Yeah you recharge them from what? an outlet? Where is IT getting it's electricity. Oh yeah form one of those big bad coal, natural gas or fossil fuel electric plants. So tell me how they are saving the environment?
The accuracy of this claim depends on which country you are in. The biggest market per capita for electric cars is Norway where the electricity grid is 98% hydro-electric. Therefore, this claim fails for Norway. In France the electricity grid is 75% Nuclear and so your claim is also invalid for France. Renewable energy deployment in Europe is increasing each year which means your claim becomes more inaccurate each year. There are countries in Europe such as Poland that have a high percentage of electricity generated from coal but even for Poland it is better to generate the pollution at the rural coal fired power station than in the cities where the population lives. Therefore, electric cars will still benefit countries that use coal as pollution from ICE cars in cities will be reduced.
Peak electricity demand during the 24 hours of a day will still decline when electric cars are widely deployed. Electric car owners will be incentivised to use cheaper off-peak electricity tariffs during the night. Therefore, the minimum electricity demand will increase during the night to charge up electric cars. This will benefit the Nuclear industry and wind industry by allowing the baseload limit to be increased to accommodate electric cars. It is likely that the number of power plants will go down despite electric cars being deployed.
If a battery is deployed in a domestic house then this house battery can be charged via solar panels and / or using a cheaper off-peak electricity tariff. This house battery can be used to charge an electric car during periods of peak grid electricity demand but the owner will be not be paying the higher peak electricity tariff due to the time displacement provided by the house battery, Also the owner may be able to sell some of the electricity stored in the house battery and electric car back to the grid during peak grid electricity demand.
The key to making the electricity grid more efficient is to deploy storage such as batteries onto the grid. Grid batteries will also kill off natural gas peaker plants as was observed in Australia after the Tesla grid battery was deployed.
Power can be transferred via microwaves from a satellite. Alternatively, use a big mirror in space to beam light down to the surface and collect this light using a solar furnace or a solar farm. In this case, solar will work during the night!!
However, it is a bit too close to being a James Bond villain's weapon.
In the UK it is legal to drive a car if you only have 1 good working eye. Therefore, from a legal point of view, you don't need 2 eyes to drive. Of course, there may be a performance impact to using only 1 eye, but the law allows those affected people to still drive.
Also we don't know how our brains work but we still use our brains.
If you go back in history, many technologies have been deployed without the knowledge of how the technology works.
Just look at how medicines are created, if a compound was shown to improve a patient's outcome and had an acceptable level of side-effects then doctors can use the medicine. The doctors don't need to know how the medicine works to deploy treatments that scientifically are known to work.
Therefore, black box Neural Nets can be treated just like a human driver by presenting data inputs and evaluating the outputs. The innards of the system don't need to be understood to demonstrate their capabilities in the real-world. As long as the Neural Net has a higher probability of success than a human driver then the Neural Net will reduce deaths. The Neutral Net does not need to be 100% safe, it just needs to be better than a human.
In the UK at least, councils monitor where people are killed on the roads and where possible, modifications to road layouts are done to reduce the likelihood of future fatal crashes at those locations. The same processes will happen for autonomous vehicle fatal crashes. Designs of roads will gradually evolve over the years as has always been the case in the UK.
The autopilot of Boeing 737 Max 8 is fine, but the MCAS system used as an aid in manual flight is flawed.
The Boeing MCAS system is used when autopilot is OFF. Boeing's MCAS system is an aid to manual flying to make the plane behave similar to the older generation of 737s. Boeing's design flaw was to use a single input to provide the angle of attack value which caused a garbage in garbage out scenario. Worse still, the MCAS system repeatedly triggered causing the vertical elevator to eventually reach maximum end of travel.
Boeing's design flaw could easily be predicted as having a potential for crashing the plane based on only 1 sensor having been used. In fact, the plane had 2 angle of attack sensors available and the black box data shows that there was a difference of 20 degrees in the 2 sensors when the plane was on the ground! So even without simulating the design, best engineering practise shows that Boeing was negligent in designing a fit for purpose system.
Boeing's "bug fix" is now to use both angle of attack sensors, to not allow the system to repeatedly trigger and to flag up on the instruments that a data anomaly had been detected so that the pilots in future could become aware of a system malfunction.
I would agree that a similarity between Tesla's autopilot and Boeing's MCAS system is that the users do not understand how these system work at the extremes of their design envelopes. A user needs to experience the system's limitations in order to be ready to take over but then it could be too late and fatal.
In terms of specific protocols, NTP isn't actually that bad since it works on timestamp deltas, not absolute values. Depending on how badly the client is written you can still get problems going to the native date encoding if it's 32-bit, but it's not the hard-fail that it would appear to be.
The NTP Y2036 issue can become a hard-fail as follows:
NTP v4 uses an EPOCH of 1 January 1900 and rolls over on 7th February 2036. This is a time range of 136 years (2^32 seconds). NTP can cope with time deltas that span +/- 68 years (68 x 2 = 136 years). After the roll-over occurs in 2036, the NTP client needs to know that it is in the new time era (new NTP EPOCH date of 7th February 2036) but old software may assume the original NTP EPOCH of 1 January 1900. NTP only passes time deltas but flags in the protocol may be used to identify the NTP EPOCH era, however, old NTP clients might not of implemented this workaround.
It was standard practice for Linux systems to initialise the system clock to the UNIX EPOCH date of 1st January 1970 (system clock starts at 0) which subsequently got updated during boot-up via a real-time clock (RTC) and/or NTP. The 68 year maximum delta + the UNIX EPOCH date of 1st January 1970 gives a maximum resolvable date in 2038. But if the NTP client assumes the original NTP EPOCH of 1 January 1900 due to the Y2036 role-over then 1900 is more than 68 years from 1970 and this gap cannot be correctly represented. There are many embedded systems that do not have an RTC so without mitigation (see below), these systems cannot set correct dates after Y2036 hits.
To compound this issue, Y2038 hits preventing correct dates from being used anyway. Systems may be using erroneous dates around 1900 or 1970.
The NTP v4 failure mode has been mitigated against by no longer initialising the system clock to the UNIX EPOCH date of 1st January 1970 during boot-up, instead the system clock is initialised to the build time and date of the kernel. This reduces the risk of the NTP 68 year maximum time delta from being exceeded as it is unlikely that the same kernel is in use for 68 years (but you never know). Some systems also save the system clock value upon shutdown and set the system clock back to this value when booting-up. This migration should cause the NTP client to use the new NTP EPOCH because dates earlier than the build date are invalid as the build date can be relied upon as being a valid snapshot in time.
I agree with you, you repeated my point. I should of been clearer that the 7th January was the Gregorian date which is equivalent to 25th December in the Julian calendar.
To be pedantic, 110v AC is the average voltage using the RMS (Root Mean Square) equation. RMS represents the equivalent DC voltage of the AC voltage by averaging out the sinusoidal AC curve into an equivalent steady straight DC curve.
You are imprecise, the peak voltage for 110v AC is not 110v..
110v AC is an RMS (Root Mean Square) value which represents the equivalent steady DC value of the voltage. In other words, the peak voltage of 110v AC is 110 x square root of 2 = 156v peak.
RMS is used because old analogue voltmeters averaged out the AC voltage and could not display the peak voltage. Also RMS is used so you can calculate the power output (voltage x current) of a resistive electrical heater and it is equivalent to feeding in a DC voltage and current of the same values as RMS. In other words, a 1kW resistive heater can produce that same average power at 110v AC at 9.1A AC and 110v DC at 9.1A DC.
It is all to do with areas under a sinusoidal curve versus the area under a steady line curve. RMS converts the area under the sinusoidal curve into the same area under a steady line curve.
kilobyte being 1000 is a marketing term used by hard disk manufacturers to make their drives look bigger.
kilobyte being 1024 is a scientific mathematical term used to represent 2 power of 10 (2^10) commonly used for computer memory sizes. It uses the binary system used in digital computers.
You missed out the UK which uses miles per hour (MPH) for traffic speeds. I think you will find that MPH is a British Imperial measurement.
In the UK, both Imperial and Metric systems run in parallel except where it is too expensive to convert to metric such as traffic speed and distance signs. For example, supermarkets have to put both Imperial and Metric measurements on their goods. However, if you go to a town market place, food is often only sold in Imperial measurements because it is traditional. Some things are only sold in metric units such as petrol which is sold in litres. The UK can be a confusing place.
Nope, you have 18 years plus some months until Y2038 hits world-wide at 03:14:07 UTC on 19 January 2038. If you wait 19 years, you will be too late.
Imagine simultaneous world-wide failures predominantly in Embedded Systems when Y2038 bites.
If you try to set your smart-phone to 2039, you will find that you can't get past 2036. Why is that ? Answer Y2038.
If your CCTV relies on NTP (Internet time protocol) then NTP rolls-over in 2036 and this is called the Y2036 issue. Then Y2038 hits on top of Y2036. Good luck with getting the correct date after that.
Please be precise, Y2038 occurs world-wide at 03:14:07 UTC on 19 January 2038. Therefore, there is less than 19 years to go!
The Y2038 issue is not restricted to time_t 64 bits so a simple upgrade to using 64-bit operating systems helps but is not the full solution. For example, filesystem timestamps and Internet protocols that use timestamps will need validating for Y2038. In other words, there will be inter-operability issues to be fixed such as the NTP Internet time protocol (Y2036 + Y2038 issues).
The work on Linux includes modifying the 32-bit Linux system calls to use 64-bit time variables. In the future, this will allow 32-bit glibc to be modified to use these new Y2038 tolerant system calls. But in addition, 32-bit applications will need modifying to use the new glibc library calls.
Linux has not missed the opportunity. Linux will be supporting upgraded 32-bit applications to run on a 32-bit or 64-bit Linux kernel via a 32-bit glibc.
Due to the closed source binary only nature of the Windows Eco-system, I expect many 32-bit applications will not be compliant for Y2038.
I am guessing that the reference to 1753 is the switch-over from the Julian calendar to the Gregorian calendar but depending on your country the switch-over happened on different dates over a period of 3.5 centuries.
I presume that computers use the Gregorian calendar for all dates including before the Gregorian calendar was invented in October 1582. I always wondered whether historians converted historical dates to the Gregorian calendar. For example, Christ's birthday of 25th December is the Gregorian calendar date but some counties such as Russia use the 7th January as Christ's birthday because that is the old calendar equivalent date.
Also 0001-01-01 never was a real date because the Gregorian calendar never existed at that time. 1 BC used the Julian calendar and there is a mismatch in days between the Gregorian and Julian calendars due to the different lengths of each of their "years" plus various leap days. I suspect that 0001-01-01 is in 1 BC because of this mismatch.
Hopefully you are not a software programmer because it is LESS THAN 19 years away. So 12 in hex is correct eg. 18 whole years away.
You are too late already, it is 18 years and so many months. It is definitely not 19 years....
The so-called "mole" is an impact pile driver. A small mass is moved up inside the "mole" to gain potential energy by compressing against a spring. After releasing the mass, the potential energy is converted to kinetic energy due to acceleration by the spring. Upon impact with the inside of the base of the "mole", the kinetic energy is converted into work done (force x distance) by a change in momentum (force x time = mass x velocity (before impact) - mass x velocity (after impact)) which causes the "mole" to apply a force (impulse) into the soil to cause the "mole" to move further into the soil.
The amount of electrical power (rate of change of energy) is low to compress the spring over say 20 seconds. But when the mass is released, the mechanical power is high due to the short time period say 0.25 seconds for the stored potential energy to be converted. This solution has the benefit of using a sustained about of low electrical power to arm the "mole" so the electrical power budget can be low. A disadvantage is that burrowing will be slow due to the low repetition rate per minute of firing the "mole".
Advantages of the "mole" over a drill is that the "mole" has no moving external parts and can change angle due to hitting rocks as it burrows down. The tail of the "mole" has temperature sensors so a temperature profile of the soil can be acquired.
You mean LHD (Left-hand drive) in Western Continental Europe. The UK is still waiting for RHD (Right-hand drive) Model 3s to start production which is expected to start in the 2nd quarter this year.