Leap Computer Requirements
Jan Dominquez
The LEAP Alliance now includes three cohorts of universities focused on computer science doctoral programs. Many of the graduate application deadlines are rapidly approaching, especially for the consideration of assistantships. Many of the institutions offer application fee waivers for particular communities of students. It is essential to check the requirements for GRE, as many institutions no longer require the GRE or have suspended this requirement during the pandemic. All LEAP institutions have a faculty advocate for the LEAP Fellows.
Suppose you find that additional time is needed to complete your application. In that case, we strongly encourage you to reach out directly to the institution to identify possible flexibility with the given deadlines.
In meantime, occasionally W10 updates, for reason unknown, disable log-in to Windows using fingerprint reader/Windows Hello. Log-in options then no longer show fingerprint as an available choice for logging in & the light in the keyboard fingerprint reader no longer lights up. However, in Settings, after I get logged in to Windows by another method, it indicates that I am already set up for fingerprint, & it will not allow me to 'add' that option. Online info indicates others have experienced same problem & that prob relates to lack of active TPM 2.0!
"Reason for failed automatic device encryption: TPM is not usable, PCR binding is not supported, Hardware Security Test Interface failed, and the device is not Modern Standby, Un-allowed DMA-capable bus/device(s) detected, TPM is not useable". I wonder, does that indicate TPM is present but not enabled or not working for other reasons?
This package contains the HP SimplePass Identity Protection Software for the supported notebook models and operating systems. This software protects identity information and account access using the computer owner's fingerprint.
I will not be bypassing the MS's requirements for updating to W11, as my research indicates that I would be denied W11 updates, which would increase my laptop's security vulnerability, as compared to sticking with W10 until being forced to retire my HP Envy 17t-j100 LM when support will cease for W10 in 2025.
Your swift answer was nevertheless very much appreciated, this being the first time I have posed a question on the HP Community; it is pleasing to know how responsive the Community is & how readily I might access it in future when I hit problems.
However, it is disappointing to note that, despite my many past software & hardware rectifications to my HP Envy laptop (W10 updates have repeatedly caused problems & my primary HDD failed ...1GB SSD replacement by me), my current primary computer hardware is going to have to be trashed simply for lack of a reliable & secure O/S. By contrast, my iPad Air 2 (bought the same year as my HP Envy 17t-j100, the iPad then running iOS 7.0.4, I think) continues to be regularly updated to the latest O/S version - currently iOS 15.6.1, with no hardware issues or outdatedness at any time, apart from poor range of connection to WiF - about 10 to 15 feet ever since i got it but getting no worse.! I would not, however, be prepared to have the iPad as my main computer.
I have been running W11 on around 15 HP and Dell notebook and desktop PC's since it was released to market last October and I can attest that every one of the PC's have gotten every security and cumulative W11 update that Microsoft has released.
I second the part about windows 11. First of all, they have awesome memory management (which you can actually notice only if you disable all the new features that "consume" it) and also, the part about NOT getting updates is just the usual Microsoft scare tactics (mostly aimed at businesses imho). As for 2025, who knows what exactly M$ is planning for the ""unsupported"" systems -probably not even Microsoft.
Many thanks again Paul for your helpful replies. Regret my slow acknowledgement due other pressures on my time. Will experiment with W11 implementation through check bypass method when I have time. Fingerprint sign-in on W10 Hello has magically come good again, of its own accord this time!
The java function System.currentTimeMillis() apparently returns the number of seconds since 1st January 1970. However, according to wikipedia.org/wiki/Leap_second, since 1972 there have been 25 leap seconds. This means the actual number of seconds since 1st January 1970 has been 25 more than a naive calculation would suggest. Does System.currentTimeMillis() do the naive calculation and ignore the leap seconds?
Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine. Nearly all modern operating systems assume that 1 day = 24 60 60 = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a "leap second." The leap second is always added as the last second of the day, and always on December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. Most computer clocks are not accurate enough to be able to reflect the leap-second distinction.
I suspect you'll find that although your computer clock is roughly aligned to UTC, that's done via NTP or the like correcting the clock periodically, rather than the OS really implementing leap seconds.
I believe the JRE libraries typically do assume the 86400-second day. It makes life so much simpler, and if you're going to correct for an inaccurate system clock anyway, you might as well correct for leap seconds that way too.
You really want to work out what you're interested in. If you need a way of representing dates and times which use leap seconds, the standard Java libraries may not work well for you. Even JSR-310 no longer supports leap seconds as far as I can tell (which is a very sensible decision for most developers).
POSIX requires that the system clock not admit the existence of leap seconds. MS Windows cannot guarantee the quality (nor existence) of the system clock hardware, and it has eschewed guarantee of 1-second accuracy. Java cannot easily do anything that the underlying system refuses to do. The operating systems are hamstrung by the history of the international regulations that result in one IEEE standard (PTP) that requires leap seconds and another (POSIX) that denies them.
Current CDF_Epoch time scheme is nominally continuous Gregorian time from 0AD with noleap seconds or defined coordinate system. In practice, it generally holds UTCtimes, but leap seconds are overloaded onto the first second of the next day.Also mission data generally have ill-defined times, sometimes including leapseconds and sometimes only UTC at start of mission with no leap secondsafterwards. Science data should have well-defined times to enable more accuratecross-comparison between missions and as documentation for future archive use.The leap second issue does not generally affect data before 1972.
TheCDF project currently supports specialized time variables: CDF_EPOCH (8-bytefloat) and CDF_EPOCH16 (two 8-byte floats). CDF_EPOCH is milliseconds from 0AD(a leap year) in an undetermined coordinate system; and CDF_EPOCH16 is secondsfrom 0AD and picoseconds within that second. At present, the CDF libraryroutines for converting between Epoch and YMD HMS is reversible in the sensethat they will return the same HMS as was used on input, but don't allow enteringan actual leap second. Simple subtraction of Epochs does not include leapseconds in between. Strictly speaking, CDF Epoch (as it stands) is time from0AD with no leap seconds, but in practice time values are usually entered inUTC, whether they included leap seconds during the mission or not. Epochassumes the Gregorian calendar leap year scheme into the past (even though theyshould probably be Julian days before 1582). Since Epoch conversion routinesignore leap seconds, a leap second and the first second of the next day are setto the same EPOCH value and converting back returns the first second of thenext day. It also ignores the varying lengths of seconds in UTC from 1961 to1972 (both UTC second longer than SI second and leaps added in sub-secondunits).
GPS,SOHO, THEMIS, C/NOFS and other missions don't add leap seconds, while WMAP,Wind, Geotail, Polar, TRACE, RXTE do. To further complicate things, missions updatetheir spacecraft clocks over a period of time around the leap seconds, as muchas days off, and some slew the spacecraft clock over time and some increment atonce but not always on time. Missions carry time in CDFs in EPOCH/EPOCH16, ASCIIvariables as strings, ISTP-like PB5 values, or in double-precision variablesfor seconds since some base time (such as THEMIS Unix time). These various schemesgreatly hinder cross-comparison of data with other missions and hinder use bygeneral data analysis tools (CDAWeb, Autoplot, etc.), requiring custom softwaredevelopment and attendant errors.
CDF_EPOCH/CDF_EPOCH16and their conversion routines will continue to be supported (including fortimes outside the range of CDF_TIME_TT2000) and will have variable attributesfor defining the Time_Scale, Reference_Position, Resolution, andLeap_Seconds_Included (as well as Epoch's fixed Time_Base=0AD andUnits=milliseconds). These attributes may also be applied to other timevariables such as THEMIS times and for returning to mission times (which maylack some leap seconds).
c80f0f1006