needusername

Doesn‘t he hack the ship and confuse the Unix epoch with the moon landing?

Ignoring time zones, the Boris Johnson approach to time zones.

> using the JDBC™ protocol

JDBC is not a protocol, JDBC is an API, hence the need for a different JDBC driver per RDBMS. I doubt the author is a developer, I see this misunderstanding often with architects who don’t code.

You forgot that the deployment also got more complicated.

You can’t expect part time open source contributors to work for free for you. Instead volunteer to take over maintenance by reviewing PRs and traiging user bug reports.

That or ASM devices. To my knowledge io_submit and io_getevents only really work with raw partitions anyway.

> - Temp files.

O_TMPFILE should do this.

> - Unit files.

O_TMPFILE together with renameat2 and RENAME_EXCHANGE should do this.

It’s my general impression that software is not one of Intel´s strengths.

Looks like you’re correct and I was wrong.

> I don't think there 17.0.3 ever will be available from openjdk.java.net

https://adoptopenjdk.net/upstream.html

These are the official upstream builds by the updates project built by Red Hat. Not to be confused by Red Hat Java, not to be confused by the AdoptOpenJDK/Adoptium builds. These can‘t be hosted on openjdk.java.net because they host only builds done by Oracle, not to be confused by Oracle JDK.

I believe Oracle 11 is affected.

> now because I don't know why they disabled it when it was there

E-cores (Gracemont) don't support AVX-512, only P-cores (Golden Cove) support AVX-512

memfd_secret is probably what you want

No. The JAR could be inside a WAR inside an EAR.

Did I misunderstand the approach or is it sort of risky as it uses escaping instead of bind parameters to create the query to be explained, potentially opening itself to SQLi?

Note that they are on JDK 14.0.2. An old, unsupported version of Java which doesn't get any security patches anymore. Being on a non-LTS version of Java forces them to upgrade to a new major version of Java every six months to get security patches, which they apparently don't do.

Getting Java through apt-get gives you more or less the worst quality builds https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0...

You get mystery bits that haven't been put through the TCK.

Why did it take projects and Google so long to migrate?

> The GIL.

How does the the GIL prevent interleaving? My understanding is that if an "operation" takes several steps, eg. reading from a dict then IO or a C extension and finally writing to a dict the GIL will not make this atomic.

> For example, in CPython multiple threads can append to a list without a lock or insert items into a dict without a lock, and the data structure will never become corrupted.

How is this achieved?

> Though it is worth pointing out that Java has a well-defined memory model, and Python doesn't.

Wouldn't you have to at least issue an mfence when a thread enters / exists the GIL?

> Currently Python only allows certain thread interleavings, because those are the points where the GIL is released.

How is this currently avoided? My understanding is that anything that accepts a callback / lambda is potentially subject to interleavings as the code can call a C extension which releases the GIL. Moving code to C extensions is often recommended when Python performance is brought up. Am I misunderstanding something?

> It's also unclear how tractable it is to retain current garbage collection semantics without a GIL

Why is it important to retain current garbage collection semantics? Why does Python prescribe a certain garbage collection implementation and does not allow for others like Java?

Where is the connection to locking and the GIL?

> Multithreaded Python currently does not

How do you prevent interleaving of different threads then?

> and must remain that way to maintain compatibility.

Why? Python 3 broke a whole lot of applications and libraries.

Why? Which different semantics cause a problem?

Why? Java has no GIL and runs faster than Python.

Good. I don't think anybody should use them and I hope nobody actually uses them.

If over a decade of doing Java on Linux has taught me anything then it is to avoid using anything Java related from any Linux distribution and instead "install" (unzip or untar) what you need yourself.

I don't see why Fedora needs to build their own versions of JARs instead of using the ones the projects builds. The only answer I heard is "this is how we roll". It seems like they have this one process built for C system libraries and try to use it for everything whether it makes sense or not.

The only exception I can think of is if you're on RHEL and want to use the RHEL Java because of the support contract.

> perhaps they just have it all compiled for M1

That won't work because of the missing W^X support in upstream releases. You need to backport patches.

Officially there is no upstream release of Java that supports macOS on ARM64 due to the lack of W^X support. You have to manually backport the patches or build from master.

> Hasn't Nashorn been superseded by GraalJS?

It depends, do you want support for your JVM? If so:

* Graal CE has no support

* Graal EE requires either running on Oracle Cloud or calling Oracle Sales for a custom quote. These are non-starters for many.

* JVMCI requires `-XX:+UnlockExperimentalVMOptions` which often voids support.

* I believe Mandrel is supported but requires RHEL

> emulate most of Oracle database functionality

What is the basis for this statement?

* MATCH_RECOGNIZE isn't supported

* reference partitions aren't supported

* TIMESTAMP is incompatible and the default compile options are comically bad

These are the first three things that came to mind and none of them are supported so I stopped looking further.