If I understand you correctly, this confirm the possibility that Microsoft have the possibility to manage 2 classes of keys: the first keys class is the current one where Microsoft is willing to sign binaries not from them; the second keys class could be for 'lock in' machines where Microsoft keep full control on.
To be fair, I think that the 'lock in' keys class it's a logical step for Microsoft branded machines. But this could go very wrong if OEMs start to do the same by using the argument 'designed for Microsoft OS' because this will add 'and nothing else could run on it' to the argument. I suspect that the goal is to reserve top machines specifications to Microsoft and to only allow degraded specifications machines to run other OS. The market already have products with this kind of bias.
And yes, you are right. This evil plan was draw decades ago with the deep knowledge that it will only work at the time when the security feature will be so standard that no chip will be manufactured without it anymore.
The fact that Windows 10 is announced to be virtually free for almost everyone having a previous copy of Windows somewhere is a clear singe that the time have changed. The OS have no value anymore. The number of new software that only run on a single OS will drastically shrink, exacerbating the OS value problem. So the 'lock in' machines with exclusive specifications will be the only market where Microsoft could make money from the OS.
From my analysis, the Microsoft message is dual: 1) you don't need anything other that Windows 10 as it's virtually free for everyone; 2) You need Windows 10 to run top specifications machines. OEM market will almost certainly split the product range accordingly if no reaction prevent this.
Yes. Microsoft could release a special version of his OS for 'lock in' machines with a new key that only boot on secure BIOS from this machines. This will make this machines unable to run any previous OS, including Linux. Or did I miss something ?
What prevent Microsoft to change the key in the future ?
Thank for your post.
New code, see why here:
http://slashdot.org/comments.p...
http://slashdot.org/comments.p...
Please provides some reference to back your claims.
systemd-timesyncd goal is to provides a very simple NTP client to very simple systems like diskless machines or tiny embedded systems. The fact is that having a system time set to something close to the actual time is a desirable feature, not only to get log with usable timestamp, but also for some security protocols.
You are right. Maybe the list should be GMST, GAST, LMST, LST ? Taken from "Astronomical Times" page here: http://www.cv.nrao.edu/~rfishe...
systemd-timesyncd is a completely independent an optional application. His 'systemd' prefix only exists because his code is part of the systemd repository and because it use the libsystemd interface. See by yourself: https://github.com/systemd/sys...
It do exactly what you expect: it is not part of the systemd initialization code, but work with systemd interface library like any applications that want to work with this new interface. See for example this situation on a custom ARM board running Debian jessie:
root 1 0.0 0.5 4364 3008 ? Ss Mar12 0:04
root 605 0.0 0.4 7360 2472 ? Ss Mar12 0:03
root 909 0.0 0.4 9964 2268 ? Ss Mar12 0:00
systemd+ 924 0.0 0.3 12104 1564 ? Ssl Mar12 0:00
Please verify some basic information before making critic to systemd-timesyncd, because from what I understand it is designed precisely the way you recommend.
Why ? The purpose of systemd-timesyncd is to provides a simple time synchronization client for diskless machines (without
Aside of the systemd purely emotional polemic, having a full NTP service into the systemd repository will at least make it potentially in a position to get some more care from a larger set of developers than in the actual situation of the venerable ntpd.
Fully agree.
Technically all GPS receiver have internally a clock signal that could relatively easily generate a PPS signal, if not already the case. But not all receivers don't expose this signal to a user available pin.
The real types that matter to computers are:
(1) TAI: Don't depend on the Earth rotation or on the position on the Earth surface. The only time safe to compute any past and future time as log as you have enough bits to store the number.
(2) UTC: Depend on Earth rotation but don't depend on the position on the Earth surface. Require the leap second table to safely compute some past time. Unsafe to compute future time because of the Earth rotation instability that make future leap second unpredictable.
(3) Local time: Depend on the Earth rotation and on the position on the Earth surface (and local government decision). Require leap second table and timezone database to compute some past local time locally on the Earth surface. Unsafe to compute future time because of the Earth rotation instability and future timezone changes impossible to forecast.
Astronomers more likely uses one of UT, UT0, UT1, UT1R, UT1D, or UT2: something that is more bond to the real physical angular rotation of the Earth.
It would be a giant step forward if NTP will be able to broadcast TAI, the leap second table, and the timezone database.
The leap second table and the timezone database are dynamic informations that need to be updated at least 2 times per years. You can arg that this can be done using the operating system upgrade, but the reality is that many machines will not be updated for whatever bad reasons. So carrying the informations using NTP (or PTP or GPS for that matter) will be an clear advantage.
get a cheap GPS unit and attach it to a local server.
GPS signal availability can depend on bad local whether condition.
systemd-timesyncd
http://www.freedesktop.org/sof...
It's only the client side of NTP, but enough for diskless machines it is designed for.
To do nothing is to be nothing.
