标签：#VM

This week's Java roundup for August 31st, 2026, features news highlighting: the GA release of TornadoVM 6.0; point releases of JReleaser, LangChain4j, Java Operator SDK, JHipster, Kotlin Toolchain and Yupiik Fusion; and maintenance releases of Micronaut and GraalVM Development Kit. By Michael Redlich

GitHub热门项目 | The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. | Stars: 40,155 | 35 stars today | 语言: LLVM

Broadcom admits it put “too big a focus on VCF.”

Pro soccer team's CTO points to "issues with the Broadcom takeover."

DoorDash has moved engineering agent workloads from developer laptops to its Flux cloud platform. The platform automated 130,000 engineering tasks in one month and supports more than 25,000 automated code reviews weekly. Flux uses isolated Firecracker microVMs, an MCP gateway, reusable playbooks, and multiple invocation surfaces to run agent workflows with scoped access and centralized auditing. By Leela Kumili

This week's Java roundup for August 24th, 2026, features news highlighting: the GA release of Atmosphere 4.0; point releases of GraalVM, Azul Payara and Quarkus; a maintenance release of WildFly 41; milestone releases of Jakarta Data and Eclipse JNoSQL; a beta release of the September 2026 edition of Open Liberty; and the release of Docker images for GlassFish 8.0.4. By Michael Redlich

This article is to update VMware appliance ovf properties through command line. Sometimes we cannot access VC and only can access VMs through ESX UI. Check over properties exists in VM login to VM as root and execute ovfenv command root@vcf91-installer [ ~ ]# ovfenv [vm.vmname]=VCF-SDDC-Manager-Appliance-9.1.0.0300.25536191 [ROOT_PASSWORD]= [LOCAL_USER_PASSWORD]= [vami.hostname]=vcf91-installer.mylab.com [guestinfo.ntp]=172.30.20.3 [vami.ip_address_version.SDDC-Manager]=IPv4 [vami.ip0.SDDC-Manager]=172.30.20.12 [vami.netmask0.SDDC-Manager]=255.255.255.0 [vami.gateway.SDDC-Manager]=172.30.20.1 [vami.ipv6.SDDC-Manager]=null [vami.ipv6_prefix.SDDC-Manager]=null [vami.ipv6_gateway.SDDC-Manager]=null [vami.domain.SDDC-Manager]=mylab.com [vami.searchpath.SDDC-Manager]=mylab.com [vami.DNS.SDDC-Manager]=172.30.20.2,172.30.20.3 Change the directory to the VM scripts folder where all the firstboot and subsequent boot scripts are stored. cd /opt/vmware/vcf/commonsvcs/scripts/ Example to change NTP server details cd /opt/vmware/vcf/commonsvcs/scripts/ntp/ root@vcf91-installer [ /opt/vmware/vcf/commonsvcs/scripts/ntp ]# ls -ltr total 12 -r-xr-x--- 1 root vcf 853 Jun 27 02:53 update-ntp_server.sh -r-xr-x--- 1 root vcf 231 Jun 27 02:53 setup-ntp.sh -r-xr-x--- 1 root vcf 45 Jun 27 02:53 refresh-ntp.sh ./update-ntp_server.sh 172.30.20.250 reboot the VM

JEP 401, integrated into JDK 28, introduces value objects. These new class instances feature final fields, altered behavior for equality checks, and stricter construction and synchronization rules. It aims to enhance efficiency and reduce memory allocation costs. However, the preview is disabled by default and requires specific configuration at compile and run time. By A N M Bazlur Rahman

MVVM with swiftUI When learning SwiftUI, one of the first architectural patterns you'll encounter is MVVM (Model-View-ViewModel). In this tutorial, we'll build a simple weather application that consumes the OpenWeather API while applying MVVM, dependency injection, and protocol-oriented programming. By the end, you'll understand not only how to structure the project, but also why each layer exists. This is the link for the OpenWeather API https://openweathermap.org/api . What you'll learn By the end of this tutorial you'll know how to: Structure a SwiftUI project using MVVM. Consume a REST API using async/await. Apply dependency injection using protocols. Display loading and error states. Keep Views focused only on UI. This is how the data flow looks. User taps "Search" │ ▼ ┌──────────────┐ │ ContentView │ └──────┬───────┘ │ await fetchWeather() │ ▼ ┌────────────────────┐ │ WeatherViewModel │ └─────────┬──────────┘ │ ▼ WeatherServiceProtocol │ ▼ ┌─────────────────┐ │ WeatherService │ └──────┬──────────┘ │ ▼ OpenWeather API Project Structure WeatherApp ├── Configuration │ └──AppConfig.swift ├── Models │ ├── Main.swift │ ├── Weather.swift │ └── WeatherResponse.swift ├── Services │ ├── WeatherService.swift │ └── WeatherServiceProtocol.swift ├── ViewModels │ └── WeatherViewModel.swift └── Views └── ContentView.swift Configuration contains application-wide constants such as the API key and base URLs. Models contains the data structures used to decode the API response. Services is responsible for networking and fetching data. ViewModels contains the presentation logic and exposes data to the UI. Views contains the SwiftUI interface. On the AppConfig file, we are going to keep static info, just like the base URL, API key, etc struct AppConfig { static let apiKey = "YOUR API KEY" static let baseGeoCodingAPIURL = "https://api.openweathermap.org/geo/1.0/direct?q=" static let baseURL = "https://api.openweathermap.org/data/2.5/weather?&units=metric&lat=" } Designing the UI Befo

This week's Java roundup for July 27th, 2026, features news highlighting: OpenJDK JEPs targeted and proposed to target for JDK 28; the GA release of GPULlama3.java 1.0; point releases of Micronaut, Quarkus and JobRunr; a maintenance release of JDKUpdater; the sixth release candidate of Maven 4.0; and the first milestone release of Jakarta Agentic AI 1.0. By Michael Redlich

Andrea Peruffo discusses the evolution of WebAssembly beyond the browser and its growing role on the server-side JVM. He covers performance advancements in Wasm runtimes, moving from interpreters to efficient JIT compilation, and explores real-world production use cases ranging from edge computing platforms to modular plugin architectures. By Andrea Peruffo

Quando eu decidi aprender como a JVM funciona por dentro, eu precisava de uma linguagem simples o suficiente pra não atrapalhar o aprendizado. Algo onde eu pudesse focar na mecânica do compilador sem me perder na complexidade da linguagem fonte. Brainfuck foi a escolha óbvia. Esse é o primeiro post de uma série de três onde a gente vai construir, do zero, um compilador que transforma código Brainfuck em bytecode JVM executável. Sem dependências externas, sem framework, só Node.js puro. No final da série, você vai ter um compilador que gera arquivos .class válidos que rodam direto no java . O código completo está no GitHub . Nesse primeiro post, a gente vai construir o interpretador - que é a base pra tudo que vem depois. O que é Brainfuck Brainfuck é uma linguagem de programação esotérica criada em 1993 por Urban Müller. Ela tem 8 comandos . Oito. E ainda assim é Turing-completa - ou seja, em teoria, você pode computar qualquer coisa que qualquer outra linguagem computa. O modelo de execução é simples: Uma fita de memória com 30.000 células, cada uma armazenando um byte (0-255) Um ponteiro que aponta pra célula atual Entrada e saída (stdin/stdout) Os 8 comandos: Comando O que faz + Incrementa o valor da célula atual - Decrementa o valor da célula atual > Move o ponteiro uma célula pra direita < Move o ponteiro uma célula pra esquerda . Imprime o valor da célula atual como caractere ASCII , Lê um byte da entrada e armazena na célula atual [ Se a célula atual é zero, pula pro ] correspondente ] Se a célula atual não é zero, volta pro [ correspondente Qualquer outro caractere é ignorado - o que significa que você pode escrever comentários livremente no meio do código. Um exemplo simples Pra imprimir a letra "A" (código ASCII 65), você precisa colocar o valor 65 na célula e usar . : +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ . São 65 sinais de + seguidos de um . . Funciona, mas é feio. Uma forma mais elegante: ++++++++ [ > ++++++++ < - ] > +. O qu

The conveneince store chain will use StorMagic instead.

This week's Java roundup for July 6th, 2026, features news highlighting: the GA release of TornadoVM 5.0; point releases of JHipster, Keycloak and Google ADK; maintenance releases of GraalVM Native Build Tools and Micronaut; the OmniFish Build of Payara and introducing Vidocq, a new implementation of the Jakarta EE 11 Core Profile and MicroProfile 7.1. By Michael Redlich

Every Java engineer who has connected JConsole — or JDK Mission Control — to a server in another network segment knows the ritual. Open the JMX port. Discover that RMI quietly opened a second port — random by default. Pin it with a system property nobody remembers without searching. File a firewall ticket for both. Wait. What fewer people know: the JMX specification shipped with the second remote transport that has none of these problems. One socket, one port, TLS underneath if you want it. It's called JMXMP — the JMX Messaging Protocol. It lost for the least mysterious reason in software — RMI shipped by default, JMXMP was a separate download, and defaults win — and its reference implementation has been effectively abandoned since around 2008. Yet, it never quite died. Code that refuses to die usually knows something. I didn't set out to resurrect it. I fell into it. The port dance, briefly The default remote JMX stack rides on RMI. The connection URL tells you most of the story: service:jmx:rmi:///jndi/rmi://host:1099/jmxrmi I'll spare you the full anatomy behind that URL — there's a JNDI lookup in it, and that second, dynamically assigned port from the ritual above; few people ever learn the details, which is rather the point. Dynamic ports were a reasonable design for 1999's flat networks. Between today's firewalls, NAT, and containers, they're friction — not because RMI is bad, but because the network it was designed for no longer exists. The JMXMP URL: service:jmx:jmxmp://host:9875 One socket. TCP in, TCP out. That's the whole networking story. How I ended up in this codebase I maintain JConsoleBooster , a modernized JConsole. It shipped fine for years on the 2008-era JMXMP jar — the one historically distributed as jmxremote_optional / jmx-optional , out of Sun's OpenDMK project, republished over the years by several parties because people kept needing single-socket JMX. Then I moved the app to a jlink -built runtime. An automatic module from 2008 does not coo

The incident that taught me to respect pinning looked like nothing. A service freshly migrated to virtual threads, a load test that plateaued at about 420 requests per second no matter how much traffic we threw at it, CPU sitting at 9%, zero errors, zero warnings, nothing in the logs. The machine had 8 cores, and the one downstream HTTP call in the hot path took about 19 ms. Do the arithmetic: 8 × (1000 / 19) ≈ 421. The service that was supposed to scale to millions of virtual threads was serving exactly one request per CPU core. Loom had quietly handed us back a bounded thread pool, and the code looked perfectly innocent. That failure mode has a name — pinning — and this is the field guide I wish I'd had that night: what it is, the two (and only two) things that cause it, what JDK 24 changed, and how to catch it before your throughput graph does. What pinning actually is A virtual thread doesn't own an OS thread. It runs on a small pool of platform threads called carrier threads — concretely, the workers of a dedicated ForkJoinPool living in a thread group named CarrierThreads , with default parallelism equal to Runtime.availableProcessors() . When a virtual thread blocks — on I/O, a lock, a queue — it normally unmounts : it saves its stack, steps off the carrier, and frees that carrier to run another virtual thread. That unmount is the entire trick that lets a handful of OS threads serve millions of virtual ones. Pinning is when the unmount can't happen. The virtual thread blocks but stays mounted, and its carrier sits there doing nothing useful for the whole duration. One pinned carrier is a rounding error. But the default carrier pool is only as big as your core count, so if a hot path pins routinely, you pin every carrier at once — and then no virtual thread anywhere makes progress. That's not a slowdown; it's scheduler starvation, and from the outside it looks a lot like a deadlock. You can raise the ceiling with -Djdk.virtualThreadScheduler.parallelism=N , bu

Broadcom accuses Allstate of dodging VMware audits.

Originally published on bckinfo.com How to Install VMware ESXi: Step-by-Step Bare-Metal Setup Guide Table of Contents ESXi vs. VMware Workstation: Which One Do You Need Hardware Compatibility Check Downloading the ESXi Installer Creating a Bootable USB Installer BIOS/UEFI Preparation Installing ESXi: Step by Step Configuring the Management Network Accessing the vSphere Host Client Creating Your First Virtual Machine Post-Installation Checklist Common Issues and Quick Fixes Closing Notes If you've read our complete guide to VMware virtualization , you already know ESXi is the bare-metal hypervisor underneath vSphere. This guide is the hands-on counterpart — installing ESXi directly on physical server hardware, from hardware compatibility checks through booting your first virtual machine. ESXi vs. VMware Workstation: Which One Do You Need Before starting, it's worth confirming you actually want ESXi and not VMware Workstation. They solve different problems: VMware Workstation is a Type-2 hypervisor — it installs on top of an existing OS (Windows, Linux, macOS via Fusion). Good for running a VM or two on a laptop or desktop you also use for everything else. If that's your case, our guide on installing VMware Workstation on CentOS Stream 10 is the right starting point instead. ESXi is a Type-1, bare-metal hypervisor — it installs directly on the hardware with no host OS underneath it. This is the right choice for a dedicated server running multiple VMs, a home lab, or anything that needs to scale beyond "a VM running alongside my desktop." The rest of this guide assumes you're installing on dedicated hardware that won't run anything else. Hardware Compatibility Check This is the step most worth not skipping. ESXi has a defined Hardware Compatibility List (HCL), and installing on unlisted hardware is the single biggest source of installation failures and post-install driver issues. Check your exact server model and component list (NIC, storage controller) against VMware'

T-Mobile wants Broadcom to keep supporting its VMware perpetual licenses.

TL;DR I built a personal VPN using AWS Lambda MicroVMs. Your traffic exits from AWS. When you disconnect, the MicroVM terminates — zero cost, nothing running. When you reconnect, a fresh MicroVM launches in about 20 seconds. ./vpn.sh start # All Mac traffic now exits from AWS ./vpn.sh stop # Back to your real IP Here is what I learned across 12 image builds — dead ends, kernel limitations, and what finally worked. The Idea Lambda MicroVMs launched in June 2026 (4 days ago). They are Firecracker VMs with: Full Linux OS — your own binaries, eBPF, iptables, network namespaces Suspend/resume — state preserved on snapshot, resumes in ~1s per GB (or terminate for zero ongoing cost) Hardware-level isolation — every session gets its own sandbox Per-second billing — ~$0.13/hr for a 2GB ARM64 (Graviton) instance 8-hour max lifetime (active + suspended combined) I wanted to run a VPN inside one. Connect when I need privacy. Disconnect and pay nothing for compute. Resume instantly when I reconnect. Took 12 image builds to get there. What I Tried (and Failed) Attempt 1: NAT Gateway Replacement (The Original Idea) This is actually where the project started. I was paying $32/mo for a NAT Gateway and thought: what if a MicroVM running nftables could replace it? Serverless NAT. Pay only when traffic flows. Why it failed: Lambda MicroVMs cannot act as VPC route targets. Their networking is ingress-only (HTTPS + JWT). Other VPC resources cannot route through a MicroVM. The VPC egress connector gives the MicroVM its own internet access. It does not make it a transit device. That killed the NAT idea. But it made me think — if I cannot route VPC traffic through it, what about routing my own laptop's traffic through it? That is how Serverless VPN was born. Attempt 2: VPC Egress Connector I created a VPC, subnets, security groups, and a network connector. One hour wasted. MicroVMs have INTERNET_EGRESS by default. The connector is only needed for reaching private VPC resources (RDS, interna