Friday, April 21, 2017

Blog Updates:

Blog Updates:

Minor updates:

- Update labels on some old posts

Will continue to make minor improvements for this blog!

- wong chee tat :)

JC mergers: Equal representation of staff in merged JCs, say principals

JC mergers: Equal representation of staff in merged JCs, say principals
By Lianne Chia Posted 21 Apr 2017 00:07 Updated 21 Apr 2017 13:23

SINGAPORE: Teaching staff in the junior colleges affected by the JC mergers will be equally represented in the merged JC, said principals of two JCs slated to merge in 2019.

Earlier on Thursday (Apr 20), the Ministry of Education (MOE) announced that four pairs of JCs would merge in 2019. Staff in the affected JCs may go on to teach in the merged JC, or be redeployed - either to teach at primary or secondary schools, or to a posting at the ministry's headquarters (HQ).

But Innova JC principal Michael de Silva stressed that the merged JC will comprise staff from both JCs in “substantial numbers”. Innova JC (IJC) will form a merged pair with Yishun JC (YJC), with the site of the merged JC to be located at YJC.

But in determining which staff will be redeployed, he added that there are some “structural issues” that need to be considered

“This is multi-faceted,” he said. “It’s not so simple to say that we’ll take the best teacher because teachers have different strengths.

“Some teachers teach math, some don’t, and you can’t have a GP teacher that teaches math ... so as in all teacher deployments, it begins with the students, and the courses and what they need. From there, we decide the teachers that will be put there,” Mr de Silva added.

Nonetheless, he reiterated that his teachers will have a choice in the matter.

“We will be having conversations with them on a one-to-one basis to find out what their preferences are,” he said. “But we will work with MOE on the deployment, taking their choices into account.”

The same goes for staff at YJC. Its principal, Mrs Edelweis Neo, noted that before news of the merger broke, some teachers had already approached her indicating their interest in a different posting.

“One teacher wants to do something else, like a stint in HQ, and a few told me they wanted to try going to secondary or primary schools,” she said. “So we’ll work with them; the majority will move on to the merged JC, and for those who want to try other posts, we will help them to achieve this.”

QUESTIONS REMAIN: TEACHERS IN AFFECTED SCHOOLS

Speaking to Channel NewsAsia on the condition of anonymity, some teachers in the various affected JCs said news of the merger did not come as a big surprise, citing persistent rumours that have been floating around for some time.

But even after the news officially broke, questions still remain, according to a teacher in one of the affected schools.

The teacher said that for some of the staff, issues like what was the criteria used to select the schools for merger, the conditions of the merger and how does the school decide who stays and who leaves were topmost on their minds. Others were concerned over what is going to happen to the merged school’s identity, and how it will affect the students.

“There is a certain level of anxiety, sadness and discomfort, maybe a bit of vulnerability," the teacher said.

It will take some time for people to come to terms with the mergers and its implications, the teacher noted.

A teacher in another JC said staff appear to be “re-evaluating their options”.

“But there is always the concern that we will be redeployed to another school,” she said. “There’s already a surplus of JC teachers and now there will be even fewer JCs with the merger.”

The teacher added that she enjoyed teaching her subject and the cognitive challenge of teaching it at the JC level.

Another teacher, who has more than a decade of teaching experience, said it is likely that the teachers most “vulnerable” to being re-deployed are those in the mid-tier, with about eight to 12 years of experience.

“We know very well that, for example, some staff like the key personnel and heads of department will certainly stay, unless they prefer not to. So where does that leave the rest of us normal, ordinary teachers?”

The teacher added that younger staff are likely to be more secure in their position, given their higher levels of energy and newer skills.

The teacher added that if she ends up being re-deployed against her will, she will consider leaving the teaching service.

“Even though teaching gives me this stability and security, it seems like the security is no longer there,” she said. “I think the real beneficiary will be the tuition industry.”

BEST OF BOTH COLLEGES

At IJC and YJC, effort has been put in to reassure staff and explain the rationale for the merger.

IJC’s Mr de Silva said explaining the reasons for the merger is “the biggest challenge faced by the school at this moment”.

He said: “Like the students, many staff would also have an emotional attachment to the place. But they understand the need for the change.

“I called to their attention why we are teachers and why we joined teaching. At the end of the day, it’s about the education of students, not just the current cohort but also future cohorts. I think if one is a teacher - and we go to the heart of why we are a teacher - one would do the right thing via the students. And I think the teachers see it that way.”

He added that communication channels will be kept open for staff and students, and the school will also be engaging parents and alumni.

In terms of programmes and opportunities for students, the merged JC will also comprise the best of both colleges, with YJC’s Mrs Neo describing it as “an equal fusion of both JCs”.

In the interim, plans are in the pipeline for both JCs to field joint sports teams for competitions, and hold a joint open house next year.

“Next year’s batch of JC1s is shared between us and IJC,” she explained. “So even though IJC will not have a JC1 cohort next year, their JC2s can team up with our JC1s to field teams or go for competitions together.”

“Michael ( IJC’s principal) and I already work very closely, and in fact we go back a long way to when we were in school division together. Our staff also work very closely with each other,” she added.

“So I think we will have a good working relationship for this.”

- CNA/lc

- wong chee tat :)

8u131 Update Release Notes

8u131 Update Release Notes

April 18, 2017



Java™ SE Development Kit 8, Update 131 (JDK 8u131)

The full version string for this update release is 1.8.0_131-b11 (where "b" means "build"). The version number is 8u131.

IANA Data 2016j

JDK 8u131 contains IANA time zone data version 2016j. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u131 are specified in the following table:
JRE Family VersionJRE Security Baseline
(Full Version String)
81.8.0_131-b11
71.7.0_141-b11
61.6.0_151-b10

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u131) will expire with the release of the next critical patch update scheduled for July 18, 2017.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u131) on August 18, 2017. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.


Changes


security-libs/java.security
MD5 added to jdk.jar.disabledAlgorithms Security property
This JDK release introduces a new restriction on how MD5 signed JAR files are verified. If the signed JAR file uses MD5, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:
  • Applets or Web Start Applications
  • Standalone or Server Applications that are run with a SecurityManager enabled and are configured with a policy file that grants permissions based on the code signer(s) of the JAR file.

The list of disabled algorithms is controlled via the security property,jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

To check if a weak algorithm or key was used to sign a JAR file, one can use the jarsigner binary that ships with this JDK. Running "jarsigner -verify" on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use the following command:

jarsigner -verify test.jar

If the file in this example was signed with a weak signature algorithm like MD5withRSA, the following output would be displayed:

The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled. Re-run jarsigner with the -verbose option for more details.

More details can be displayed by using the verbose option:

jarsigner -verify -verbose test.jar

The following output would be displayed:
- Signed by "CN=weak_signer" 
    Digest algorithm: MD5 (weak) 
    Signature algorithm: MD5withRSA (weak), 512-bit key (weak) 
  Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 
    Timestamp digest algorithm: SHA-256 
    Timestamp signature algorithm: SHA256withRSA, 2048-bit key

To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size. Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JARs, the existing signature(s) should be removed from the JAR file. This can be done with the .zip utility, as follows:

zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA' 

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap athttp://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components.
JDK-8171121 (not public)



core-libs/java.net
New system property to control caching for HTTP SPNEGO connection.
A new JDK implementation specific system property to control caching for HTTP SPNEGO (Negotiate/Kerberos) connections is introduced. Caching for HTTP SPNEGO connections remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.

When connecting to an HTTP server that uses SPNEGO to negotiate authentication, and when connection and authentication with the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP server using SPNEGO usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP SPNEGO (Negotiate/Kerberos) protocol in order to force requesting new authentication with each new request to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP SPNEGO connections. If jdk.spnego.cache is defined and evaluates to false, then all caching will be disabled for HTTP SPNEGO connections. Setting this system property to false may, however, result in undesirable side effects:
  • Performance of HTTP SPNEGO connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
  • Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

JDK-8170814 (not public)



core-libs/java.net
New system property to control caching for HTTP NTLM connection.
A new JDK implementation specific system property to control caching for HTTP NTLM connection is introduced. Caching for HTTP NTLM connection remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.

On some platforms, the HTTP NTLM implementation in the JDK can support transparent authentication, where the system user credentials are used at system level. When transparent authentication is not available or unsuccessful, the JDK only supports getting credentials from a global authenticator. If connection to the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP NTLM server usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP NTLM protocol in order to force requesting new authentication with each new requests to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP NTLM connections. If jdk.ntlm.cache is defined and evaluates to false, then all caching will be disabled for HTTP NTLM connections. Setting this system property to false may, however, result in undesirable side effects:
  • Performance of HTTP NTLM connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
  • Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

JDK-8163520 (not public)


tools/visualvm
New version of VisualVM
VisualVM 1.3.9 was released on October 4th, 2016 http://visualvm.github.io/relnotes.html and has been integrated into 8u131.
See JDK-8167485


Bug Fixes


The following are some of the notable bug fixes included in this release:

client-libs/java.awt
Introduced a new window ordering model
On the OS X platform, the AWT framework used native services to implement parent-child relationship for windows. That caused some negative visual effects especially in multi-monitor environments. To get rid of the disadvantages of such an approach, the new window ordering model, which is fully implemented at the JDK layer, was introduced. Its main principles are listed below:
  • A window should be placed above its nearest parent window.
  • If a window has several child windows, all child windows should be located at the same layer and the window from the active window chain should be ordered above its siblings.
  • Ordering should not be performed for a window that is in an iconified state or when the transition to an iconified state is in progress.

These rules are applied to every frame or dialog from the window hierarchy that contains the currently focused window.
See JDK-8169589



security-libs/javax.net.ssl
Correction of IllegalArgumentException from TLS handshake
A recent issue from the JDK-8173783 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves
The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified.
See JDK-8173783

This release also contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see theJDK 8u131 Bug Fixes page.



Installed!

- wong chee tat :)

New complex for DSO - Singapore's largest defence R&D organisation

New complex for DSO - Singapore's largest defence R&D organisation
By Nur Afifah Ariffin Posted 21 Apr 2017 17:43 Updated 21 Apr 2017 17:50
The new DSO National Laboratories complex at Science Park Drive opened on Friday (Apr 21). (Photo: Nur Afifah)

SINGAPORE: The DSO National Laboratories (DSO) - Singapore's largest defence R&D organisation - officially opened its new complex in Science Park Drive on Friday (Apr 21).

The eight-storey twin buildings house more than 1,000 research engineers and scientists from across 200 offices and laboratories. They are also equipped with facilities that can further research in areas of robotics and artificial intelligence.

The new DSO National Laboratories complex consists of two eight-storey buildings. (Photo: Nur Afifah)

This includes the Playground - a shared space where researchers and scientists can access a wide suite of technology and tools. It also comprises an Artificial Intelligence (AI) hub, which aims to raise awareness of AI and promote innovative applications of the technologies to Singapore's defence systems.

Some of these innovations include using data for maritime security and analyzing social media to determine and extract intelligence to support counter-terrorism efforts.

Another key facility in the new complex is the Robotics Laboratory, a one-stop shop for engineers to embark on prototyping, integration, simulation and testing of robotic systems prior to field tests.

It's the first of its kind in Singapore, and is focused on making unmanned systems smarter and faster.

A demonstration of an unmanned air-to-ground teaming of a drone and driverless vehicle at the opening of the new DSO Complex on Friday (Apr 21). (Photo: Nur Afifah)

In his opening address, Defence Minister Ng Eng Hen acknowledged the importance of the DSO National Laboratories' role in the defence landscape, especially in building up new capabilities for the Next Gen Singapore Armed Forces.

"As it did before, DSO's work must help us better prepare for challenges ahead. DSO's past efforts in AI and robotics since the 1990s have helped provide the SAF with unmanned platforms for land, sea, and air," said Dr Ng.



A demonstration of an unmanned air-to-ground teaming of a drone and driverless vehicle at the opening of the new DSO Complex on Friday (Apr 21). (Photo: Nur Afifah)

"With our increasing dependence on technology, the new DSO complex has been designed to encourage collaboration and spur innovations to meet SAF's future requirements."

Dr Ng also went on a tour of the Playground and the Robotics Laboratory, where he witnessed a live demonstration of an unmanned air-to-ground teaming of a drone and driverless vehicle, capabilities which could soon be deployed in SAF operations.

- CNA/mn


- wong chee tat :)

A Wet Friday Morning!


A Wet Friday Morning!




- Pic from Internet


- wong chee tat :)

McAfee DAT version = 8504 (apr 20th 2017)

McAfee DAT version = 8504 (apr 20th 2017)

Link: here ( Select Yes. And it keeps getting updated daily. Region=US)

- wong chee tat :)