If you search for pictures of "Original Lisa Keyboard" you can see that the layout is the same. However, in the pictures I found the key that corresponds to the small '=' in the screenshot in the article is labelled '-' and there appear to be some other differences. I don't remember these differences or any rationale for them.

Update: They screenshot in the article exactly matches the Macintosh Plus keyboard -- which is a keyboard I actually owned. Although I used Mac XL before getting my Plus, it's probably this keyboard that I'm remembering:

https://en.wikipedia.org/wiki/Apple_keyboards#Macintosh_Plus...

  void main() {
      IO.println("Hello, World!");
  }

If you want to use 3rd-party libraries, I highly recommend trying JBang [3].

[1] https://jdk.java.net/25/release-notes

[2] https://openjdk.org/jeps/512

[3] https://www.jbang.dev

  void main() {
      CompletableFuture<String> future = CompletableFuture.supplyAsync(this::asyncMethod);
      future.thenAccept(result -> IO.println(result));
      IO.println("Prints first");             // prints before the async result
      future.join();                          // Wait for future to complete
  }

  String asyncMethod() {
      try {
          Thread.sleep(10000);
      } catch (InterruptedException e) {
          return "Interrupted";
      }
      return "Data Fetched";
  }

1. Move the asynchronous function called in the CompletableFuture to its own method

2. Use Java 25 "instance main method" (see JEP 25: https://openjdk.org/jeps/512)

3. Use Java 25 IO.println() to simplify console output

4. Instead of throwing a fatal exception on interruption, return "Interrupted" immediately.

5. Use future.join() so the main method waits for the future to complete and the "Data fetched" output is printed.

This program can be run directly from source with `java Example.java`. (If you're using Java 24 or a version of Java 25 prior to EA 22, you need to use `java --enable-preview Example.java`)

Here is a modified version of the example that interrupts the thread:

  void main() {
      ExecutorService executor = Executors.newSingleThreadExecutor();
      CompletableFuture<String> future = CompletableFuture.supplyAsync(this::asyncMethod, executor);
      future.thenAccept(result -> IO.println(result));
      IO.println("Prints first");             // prints before the async result
      executor.shutdownNow();
      future.join();                          // Wait for future to complete
  }

  String asyncMethod() {
      try {
          Thread.sleep(10000);
      } catch (InterruptedException e) {
          return "Interrrupted";
      }
      return "Data Fetched";
  }

"Regulation by enforcement" has been a real thing and a bad thing. You can't expect people to obey the law if you won't tell them what it is.

I would like to see the government prosecute actual fraud, so if the article goes on to say they will not prosecute that, then maybe the headline is accurate.

> You can't expect people to obey the law if you won't tell them what it is.

Good thing this wasn't happening with crypto fraud. Wire fraud is pretty much the same even with blockchain.

That's an excuse the crypto community dreamed up. The SEC's position, pre-Trump, was quite clear: crypto assets are securities. File an S-1, as you would for an IPO, with all the usual disclosures, under penalty of perjury. A very few crypto issues did that.

This new statement is mostly about crypto "exchanges". Pure exchanges aren't so bad. At no point in a trade does the NYSE own the asset. It's that crypto exchanges are usually not just exchanges, but brokers, dealers, custodians, and lenders. All of which can lose assets.

Actual memo: [1] It doesn't really change much. Frauds against investors can still be prosecuted.

[1] https://archive.is/Td0Fn

If you a writing libraries for the JVM, Java is preferred to Kotlin because it does not drag along a standard library dependency.

To be fair there is Kotlin Multiplatform where this is not the case. https://kotlinlang.org/docs/multiplatform.html

It is no different than writing C code across UNIX, Windows, mainframe, microcomputers and embedded, consoles, and somehow work across all of them.

I think you were proven right at least a decade ago. As you said, this is just the final whimper.

Has anyone done that?

Asterinas is such an experiment. Purely written in Rust and Linux ABI compatible.

It's not a fork of Linux but a ground up effort to write a kernel in Rust. Still they're trying to make it compatible with Linux/BSD

And, of course, drivers run in userspace and interact with the system through a clearly defined API.

Other systems like this include Robigalia, Lions OS and Genode.

They would likely quickly overtake Linux if they got 1% of the resources Linux receives.

Robigalia is also an effort, but one that hasn't been touched in nearly a decade.

JEP 495: Simple Source Files and Instance Main Methods (Fourth Preview) https://openjdk.org/jeps/495

The parent article mentions and links JEP 477 -- the 3rd preview of the same feature-set. JEP 495 is the 4th preview and is included in JDK 24 which is in "stabilization" mode for release in March 2025.