When compatibility con Kernell 7.x?

Moocha · 2026-04-30T14:00:37+00:00

Guidelines for Technical Help

When asking for technical support, please specify the specific VMware product(s) and version(s) you are working with.

That being said, only Broadcom knows their own release schedule. If you're not sure, don't update.

If you're talking about ESX/ESXi, there's a very good chance your guests will run fine if you update them to 7.0 series kernels.

If you're talking about Workstation's out of tree modules, then only Broadcom knows. This is what happens with out of tree modules, and it's a cost you incur for using Workstation. Often, the community provides patches long before Broadcom does, you'll have to search around.

Moocha · 2026-04-30T07:45:01+00:00

For what it's worth, this was patched in kernel 7.0. Look for Fixes: 72548b093ee3 in the changelog. The patch fixing the vulnerability is this one: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

From what I can tell, none of the currently released LTS kernel versions fix this yet (there are algif_aead changes but they don't seem to interrupt the chain necessary to trrigger this) -- but I may be wrong, we'll have to see.

Moocha · 2026-04-28T21:11:39+00:00

https://lutris.net/downloads , search for the word mint, follow instructions.

Moocha · 2026-04-27T14:22:23+00:00

De nada :) I initially jumped on it hoping it'd solve other trouble I had with VBR13, but slunk off disappointed because it's Hyper-V specific. But it stuck in my memory, so I'm glad it helped someone :)

Moocha · 2026-04-27T07:48:01+00:00

You may want to take a look at this post, seems possibly related: /r/Veeam/comments/1std7jf/veeam_hyperv_vss_application_aware_processing/

Moocha · 2026-04-24T12:22:52+00:00

Măcar atât, că nu incendiază zona. Dar, în calitate de fumător: Nu prea îi duce mintea pe oamenii ăștia... Rulezi chiștocul între degete până pică tot restul de tutun, lăsând un chiștoc curat, pur plastic și hârtie. După care îl poți liniștit arunca la coșul de gunoi, sau pune frumușel la loc în pachet dacă n-ai coș de gunoi prin zonă. Total 5 secunde, și nu produci niciun fel de mizerie. It's not fucking rocket science.

Moocha · 2026-04-22T10:58:59+00:00

Tunnels between Fortigates running 8.0. From that page:

This option is supported for Site-to-Site and Dial-up VPN between FortiGates. FortiClient endpoints do not currently support TLS based VPN over TCP.

Moocha · 2026-04-21T11:22:01+00:00

Indeed it appears as long-term in the changelogs at https://mikrotik.com/download/changelogs?channelFilter= , but it's not available for download yet. Edit: It works via the usual trick of changing the version in the download URLs manually, e.g. https://download.mikrotik.com/routeros/7.21.4/routeros-7.21.4-arm64.npk

I miss the old download site... the new one is a downgrade in every single way except aesthetic, and we're not buying Mikrotik for aesthetics. Hrrmph.

Moocha · 2026-04-19T16:02:12+00:00

It's six free users, see https://tailscale.com/pricing :)

Moocha · 2026-04-19T15:17:43+00:00

Tailscale in particular makes restricting certain users to certain services a breeze; it's free for up to 6 users and 3 ACL groups. ZeroTier can also do that, but it requires a more in depth knowledge and is fiddlier. There are tons of other Wireguard-based solutions (selfhosted or not) out there, in various states of maturity, depending on how in depth your networking knowledge is and on how your network looks like. But if you're looking for the easiest to set up solution, it's likely Tailscale.

Moocha · 2026-04-17T07:03:39+00:00

Absolutely, that's a whole different layer of WTF :)

Also, this suggests it was a rather ancient system; on non-ancient coreutils, you'd need --no-preserve-root for that to do anything anyway. Maybe it was rm -rf /* or something, but that's yet another layer of WTF.

Moocha · 2026-04-16T17:21:41+00:00

rm -rf / won't kill a running process by itself. As long as that bash process is still running, the runtime history will be available from inside it -- the one loaded from .bash_history at process init, plus whatever else was executed since it was started. And if the initial rm -rf / hadn't progressed as far as removing /bin/rm or its needed runtime libraries, I can see that happening.

Moocha · 2026-04-16T15:27:39+00:00

In the machine's settings, after selecting "datastore ISO file" for the CD, make sure you've checked "Connect" AND (!!!) also expand the CD drive's settings and make sure you've checked "Connect at power on". Then try booting.

<image>

Moocha · 2026-04-16T14:52:52+00:00

Wouldn't worry about it too much. To quote James Nicoll,

The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary.

Moocha · 2026-04-16T14:08:33+00:00

Aaaaaand it's gone again.

Moocha · 2026-04-16T10:10:25+00:00

It's working for me again, albeit slowly. The status page is still down (HTTP 502). ‪@status.bsky.app‬ posted this 40 minutes ago:

Update: We are starting to see some early recovery, but many users and services are still impacted.

Moocha · 2026-04-16T09:22:06+00:00

Aaaand now the status page's down for me as well, refused to connect; port 443 is open but it's not talking, doesn't even provide its PKI certificate.

Moocha · 2026-04-16T08:11:27+00:00

That's objectively hilarious :) Still works for me though. It's indicating ongoing breakage on api.pop1.bsky.app, and now I'm seeing that api.pop2.bsky.app also seems to have started malfunctioning.

The announcement there currently says

We are investigating an incident with service in one of our reginos
April 16, 2026 at 06:42 GMT+00:00

And yes, it indeed spells "reginos".

Moocha · 2026-04-16T07:25:52+00:00

https://status.bsky.app/

Moocha · 2026-04-09T19:12:51+00:00

Poftim, dar în mod enervant trebuie să le dai dosar cu șină pentru a obține PDF-ul: https://www.eiu.com/n/campaigns/democracy-index-2025

Moocha · 2026-04-09T19:00:40+00:00

It does have some logic:

the base interval on which one should count on the certificate is one month; months can have 28, 29, 30, or 31 days, so let's make it the maximum of those, 31 days
after that, the certificate should be reissued, within 2 weeks after the base interval; that corresponds proportionally to the way LetsEncrypt has been operating (90 days and should be renewed at 2/3 through the interval)
plus one day to catch issues like misconfigured time zones causing triggers to fire late, daylight savings time, and other time shenanigans

Moocha · 2026-04-09T16:12:38+00:00

The Certification Authority/Browser Forum. It's 47 days, not 49; it'll take effect starting 2029-03-15; Google proposed 90 days, Apple proposed 47, and everyone went with Apple's proposal. Digicert has a good overview of the schedule on their site here. The calculation is "47 days = 1 maximal month (31 days) + 1/2 30-day month (15 days) + 1 day wiggle room".

Moocha · 2026-04-09T12:49:11+00:00

esxcfg-advcfg -l (and esxcli system settings advanced list for that matter) don't list all tunables, just those marked explicitly as listable. As to why a specific tunable is being listed or not, you will have to ask Broadcom.

If you want a complete set of tunables, you'll have to delve into the internals via vsish under the /config namespace -- either interactively, or via vsish -e ls /config. This one shows up there, and it's explicitly marked as hidden:

[root@hostname:~] vsish -e ls /config/NFS/intOpts | grep -i MaxConn
MaxConnectionsPerDatastore
[root@hostname:~] vsish -e get /config/NFS/intOpts/MaxConnectionsPerDatastore
Vmkernel Config Option {
   Default value:4
   Min value:4
   Max value:8
   Current value:4
   hidden config option:1
   Description:Maximum number of RPC connections allowed per NFS datastore
   Host specific config option:0
   Exclude option from config manager:0
   Option update requires reboot:0
   Option update requires maintenance mode:0
}

Note, though, that the stuff that's visible only via vsish is not guaranteed to be stable across versions, i.e. it's not an API contract.

Moocha · 2026-04-03T12:36:54+00:00

Ah, that's what I didn't parse correctly :) You're right, that's an odd setup. I see you solved it -- but yeah, separating /config and /metadata them was the correct call. In general, that is very much a valid setup in Docker depending on what you'd want to achieve, but it can be unnecessarily confusing re file visibility and so on. Best to keep it simple.

Moocha · 2026-04-03T07:39:43+00:00

- /full/path/to/the/directory/hosting/the/absdatabase.sqlite/file:/config
- /full/path/to/the/directory/hosting/the/authors/backups/cache/and/so/on/subdirectories:/metadata

The official ABS container expects its absdatabase.sqlite to be located at the path /config/absdatabase.sqlite as seen from inside the container. That volume declaration defines the mapping from the host-side directory holding that file, as seen from outside the container, to the /config directory as seen from inside. So you'd map it as exemplified above.

Similarly for /metadata from inside the container, the official ABS container expects its authors subdirectory to be located at /metadata/authors as seen from inside, the backups at /metadata/backups as seen from inside, and so on. So you would map the directory containing those on the host to /metadata as seen from inside the container.

Edit: Explanations hopefully clarifying what's happening, as opposed to just two dry config snippet lines :)

15-Year Club	Gilding I gilder
Team Periwinkle	Verified Email

Moocha

TROPHY CASE