$RecallEnabled = Dism /online /Get-FeatureInfo /FeatureName:Recall | findstr /B /C:"State" If ($RecallEnabled -Match 'State : Enabled') { DISM /Online /Disable-Feature /featurename:Recall }else{Write-Host "Recall Disabled" }

Heads up: the new AMD AI laptop CPUs have soldered RAM and Mediatek wifi. AMD has an exclusive partnership for this generation with them. That means all new AMD laptops will have broken WiFi on BSD systems.

Download at https://www.midnightbsd.org/download/

Release notes at https://www.midnightbsd.org/notes/ or https://github.com/MidnightBSD/src/releases/tag/3.2.0

Project update:

We've been working on restoring the UK mirror after a complete loss of the OS on the server after an update. (it was a freebsd box at ovh) It's been rsyncing for over a week now. We're only getting about 500kbps for some reason. Very slow. At this point, it should have everything but snapshots. 900 files to go.

We've updated amd64 and i386 3.1 packages recently with the latter being the first update since November. We're currently working on building packages for 3.2 amd64.

A 3.2 stable branch was created recently and we plan to fix a few bugs and get updated packages and then do a release off this branch. The original timeline was may but several issues have slowed us down.

One of our VM servers died suddenly in May. It was a consumer Ryzen 5700x box 64GB 3 SSDs. We've replaced it with an HPE dl360 gen9 with e5 xeon v3 24 cores / 48 threads 160GB RAM and 6 SAS SSDs.

We had to do a large refactor on how we handle perl for the new 3.2 version and this caused a lot of 3.1 ports to break. We've fixed these for folks on the latest 3.1.x release, but if you are on an early release, you may experience issues with man page paths for perl ports. We recommend updating to the latest 3.1.5 as of writing. (if you install via packages, it should work OK with other 3.1.x releases)

I bought a cheap Dell Inspiron with a qualcomm snapdragon cx gen2.  

First, the laptop couldn't get out of Windows s mode for two days.  That meant I couldn't install any third party programs like chrome, firefox, vscode or java.  it also failed to install many apps from the windows app store until today.

Gaming doesn't work fully.  While I expected many games to not be ported to arm, the game services installer needed for the xbox app fails on this CPU.  It throws dll errors constantly on login/reboot of windows or when trying to launch the xbox app. I reported this to microsoft.  A few games were installable on the device such as the microsoft jigsaw app and minecraft.

Thunderbird and virtualbox are not available on windows/arm64.  In fact, there are no VM apps available from third parties so far.  I found that hyper-v is available, but requires a pro windows license. I haven't paid the 99 dollars to find out if it works.

Battery life is good.  I'm seeing about 25% per 2-2.5 hours of use.  I'm down to 30% remaining since I got the device on saturday.  I've only charged it once.

This arm chip is not the new snapdragon elite x with the AI crap.  It's an older ARM chip so there are possibilities for some things to work on the upcoming platform that don't here.  Still, it's interesting to see the state of arm on windows.

Edge and chrome are fast on the device.  Firefox feels a little slugish compared to using it on windows x86_64 or linux. 

I was able to setup wsl on the device with debian.  None of the ubuntu installers worked despite some listing arm64 support.  I had to go cli and run the wsl --update and wsl --install -d Debian to get there though.

RavenPorts has done a big update with MidnightBSD packages. Highlights include: Xorg Server: 21.1.13 Mesa 24.0.6 Firefox 125.0.3 Thunderbird 115.9.0 LibreOffice 24.2.2.2 Gimp 28.10.38 LLVM 18.1.5 Rust 1.77.2 Go 1.22.2 There's also been a lot of progress on wayland support.

I just updated unbound to 1.19.3 in the stable/3.1 branch.  This fixes a number of CVEs. Anyone using it on 3.1 should consider updating the base system or use the mports version.

MidnightBSD 3.1.4 release

Fixes issues with mport and updates timezone data.

https://github.com/MidnightBSD/src/releases/tag/3.1.4

I've updated the xz version in 3.2-current to 5.4.x and avoided the known vulnerable releases. This aligns with recommendations from several sources.

As far as the calls to switch off xz for everything, that's unlikely in the short term. A lot of software distributed in mports uses tar.xz files. Further, package files generated by mport use it.  Early releases of mport used bzip2 but we migrated many years ago to tar.xz.  We're investigating the possibility of migrating to zstd and are working on updating libarchive to a newer release in base for this purpose.  It will likely not happen for the midnightbsd 3.2 release and will need to happen during a major release cycle.  (4.x? 3.3?) 

The long term risk is that xz isn't taken over or forked by a trustworthy source and CVEs start piling up.  The actual linux specific issues with 5.6.x are not a concern for BSD platforms aside from the real risk of something like this happening again.  (the supply chain attack piece is a danger)  

The harsh reality of open source is that there is a lot of code and it's difficult to review it all.  Companies have been bitten by issues like Amazon Music getting crypto mining node modules years ago or the recent attack on Notepad++ plugins.  It happens.  How we deal with it is what's important.

We've tagged 3.1.4 in git for the stable/3.1 branch and have an amd64 ISO on the FTP.  Still need to build i386.  

This includes updated timezone data and some major fixes to mport package manager.  There were a lot of issues in the 3.1.3 release of MidnightBSD with installing and using packages.

I'm uploading a 3.2 amd64 snapshot to the primary FTP server for MidnightBSD

github has blocked the xz repository which makes it more difficult for OS projects to track what is going on with the malware. Instead of blocking the repo, they should have put a warning up and blocked downloads of the affected tarballs.

We just released mport 2.6.2; it fixes two bugs with mport list and mport list updates that would cause no output to display.

This has been imported into current and stable/3.1 branches

There is an xz vulnerability in 5.6.0 and 5.6.1 that was caused by a malicious payload added via a commit.  https://boehs.org/node/everything-i-know-about-the-xz-backdoor

At this time, I am unaware of anything in libarchive that is considered dangerous as mentioned on that website.  MidnightBSD does not use the affected versions of xz in base. We have 5.2.9 right now.

There's two security vulnerabilities in the base system unbound.

We've updated unbound to 1.19.1 in 3.2 CURRENT and 1.19.3 in mports.

We're working on getting mports back in shape on 3.2-current.  At the moment, work is underway on the devel/llvm15 port so we can update mesa

I've been working on migrating my PS3 to a WD red 500GB ssd from the original 80GB toshiba hard drive.  The hardware part is easy.  For the software, you have to download the PS3 update from Sony's playstation website and then put it on a USB flash drive on PS3/UPDATE/ with the file named as downloaded.  It will pick it up and load.  Then you do an initial setup and then start the restore process.  (assumes you have a backup from old drive ahead of time)

It takes like an hour to backup and another hour to restore

We're in the process of migrating to perl in mports from base.  Perl went into midnightbsd many years ago (around 0.4 i think) 

There are a few reasons for the change but here are a few:

• Difficulty in updating 

• Delays between releases

• Security fixes are easier

• Less software requires Perl now than when we made the decision

The biggest downsides are with mports as a lot of it still uses Perl.  We're working on that.

It seems that mport install doesn't work sometimes and gives no output.

Workaround:

mport download pkgname

/usr/libexec/mport.install /var/db/mport/downloads/pkgfilename.mport

where pkgname is something like gmake and pkgfilename.mport is something like gmake-3.8.1.mport

perl is not correctly setting enabling man pages if a system uses mandoc. It kind of guesses if nroff is present. This causes many perl ports to not build man pages. Fixed in stable/3.1

We're now forcing man1dir/man3dir and man1ext/man3ext settings in build (missed)