Code: Select all
update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/jmod to provide /usr/bin/jmod (jmod) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/jps to provide /usr/bin/jps (jps) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/jrunscript to provide /usr/bin/jrunscript (jrunscript) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/jshell to provide /usr/bin/jshell (jshell) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/jstack to provide /usr/bin/jstack (jstack) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/jstat to provide /usr/bin/jstat (jstat) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/jstatd to provide /usr/bin/jstatd (jstatd) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/rmic to provide /usr/bin/rmic (rmic) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/serialver to provide /usr/bin/serialver (serialver) in auto mode update-alternatives: using /usr/lib/jvm/java-11-openjdk-armhf/bin/jhsdb to provide /usr/bin/jhsdb (jhsdb) in auto mode Setting up ca-certificates-java (20190405) ... head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or directory Error occurred during initialization of VM Server VM is only supported on ARMv7+ VFP dpkg: error processing package ca-certificates-java (--configure): installed ca-certificates-java package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.28-10+rpi1) ... Processing triggers for systemd (241-5+rpi1) ... Processing triggers for man-db (2.8.5-2) ... Processing triggers for ca-certificates (20190110) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Error occurred during initialization of VM Server VM is only supported on ARMv7+ VFP E: /etc/ca-certificates/update.d/jks-keystore exited with code 1. done. Errors were encountered while processing: ca-certificates-java E: Sub-process /usr/bin/dpkg returned an error code (1) pi@raspberrypi:~ $ java Error occurred during initialization of VM Server VM is only supported on ARMv7+ VFP
openjdk-11 does install without error when run on a Pi3. That error however doesn't seem to be the reason that java mail doesn't work on a Pi1 with openjdk-11. I'm going to start a new thread on that.knute wrote: ↑Wed Jul 17, 2019 2:13 pmSo there is an interesting fault when openjdk-11 is installed on a Pi0 or Pi1. The script that sets the ca-certificates doesn't run because it call java without the -zero option and fails. This causes it to fail doing some things that require use of the certificate (eg. java.mail).
Today I'm going to try installing the openjdk to the OS when it is running on a Pi3 and then taking the chip to a Pi1 and see if it works then.
Will report back.
Gotta love anybody who knocks Java for being "non-standard" and "proprietary" they seem to have missed the point that standards have moved on from the world of ISO and IEEE standards (which have their place) to community driven processes like RFC. In short we have moved on from standards as engines purely of stability to standards as being engines of stability with change. Whether JCP deserves the Community label is another debate - but like it or not, Java is a highly ubiquitous language and both has a reasonable variety of implementations with both open and closed source code and supports more platforms without tedious conditional recompilation or dead slow interpretation than any other language.
The meaning of "proprietary" is "relating to an owner or ownership."
There is no weakness in my comment. Just ask Google : "Google LLC v. Oracle America, Inc." : https://en.wikipedia.org/wiki/Google_LL ... erica,_Inc.mutant wrote: ↑Sat Oct 24, 2020 9:39 amThe clue to the weakness in the comment above is that this discussion is possible or has alternatives at all - if we were talking about a truly closed proprietary language, the answer here would be 'tough sh*t, suck it up and upgrade to the new M$ blueberry tart running Windoze 10 phone". Instead, there are options. You can compile versions from source. There are compiled Open Source alternatives.
Strangely enough in the year and a half since I wrote that post I have softened my stance on demanding ISO/IEEE and such standards.
+1, or even just the threat of the language being abandoned because its no longer profitable for that one single company. A proper standard provides independence.
Python has its 2/3 problems, and my last experience of Rust was that the repository version did not work and the nightly build had to be used. Once a strong standard appears (that everyone adheres to), stability improves and progress slows (except for C++ perhaps).
And look where that's got BASIC. More than 300 different and incompatible versions.
Of course. The popular standardized languages have that.
I'm curious to know what that was about.jahboater wrote: ↑Sun Oct 25, 2020 9:33 amPython has its 2/3 problems, and my last experience of Rust was that the repository version did not work and the nightly build had to be used. Once a strong standard appears (that everyone adheres to), stability improves and progress slows (except for C++ perhaps).
Yes, I guessed it was something like that. It was your code. People tried the Rustc from apt-get and it failed for some reason or other. You provided a script to download the nightly build each time.
Any serious language needs something where users can say that a certain behavior is expected according to the specification, or not - in which case everyone will accept that the compiler is at fault.
Does not surprise me. I had the same problem with node.js. Always many versions behind. I presume it is there because there are already other packages that depend on Rust, so an old, known to work in the system Rust is the Debian way. With good reason. Not only that you end up with a pile of Debian packages for old Rust crates and node.js modules that are required.
I agree. Luckily there are people working on a formal specification of Rust. It will come to pass
Credence is about all one gets from an ISO standard. The actual credibility of the standard comes from all those people from MS, Intel, Google, ARM and elsewhere the constitute the standards committee. They have a vested interest in a common standard to work to. I imagine that would all go along just fine if they just had some "C++ Foundation" and skipped the ISO part altogether.
I agree of course. Such standards have been essential to industry ever since British Standard Whitworth screw threads and the like.