macOS has become more reliable(eclecticlight.co)
eclecticlight.co
macOS has become more reliable
https://eclecticlight.co/2021/10/29/how-macos-is-more-reliable-and-doesnt-need-reinstalling/
151 comments
Anyone know why macOS updates take so long? It's nuts, I just upgraded to one of the new MacBooks and even on that it took about 20 minutes to upgrade from 12.0.0 to 12.0.1, so not even a major release upgrade. The CPU is wicked fast, the SSD is wicked fast, so why does it feel like I'm suddenly using a Pentium when upgrading?
In the last couple of version, updates are no longer differentials but full OS updates. They are shipped as a single signed package that is loaded into one of the protected volumes of the disk. This is supposed to be a security measure to prevent compromises of components of the OS. The downside is big slow updates. Hopefully they work on that and do more like the differential updates that they use for iOS.
They could still apply a tiny patch and then checksum the whole thing, surely?
Just divide the whole thing into read-only units and reuse the unchanged ones, a la nixos.
And if the checksum fails, what then?
Then fall back to downloading the full OS image. Then the worst case would be about the same as today, while the common (99.9%+) case would be fast and bandwidth-cheap.
(Optimization: hash tree, figure out which specific files are broken and download only those.)
(Optimization: hash tree, figure out which specific files are broken and download only those.)
Then abort the update? I'm not objecting to A/B partitions or filesystem snapshots or boot environments or however you want to implement it, I'm just saying that you can reconstruct the install image on the machine rather than downloading the whole thing over the wire.
Use a Merkle tree.
Maybe checksum before updating? Or revert the patch if it fails?
To be fair, iOS updates also feel ancient compared to the Android live-update method which just requires a slightly longer reboot. On Android, I sometimes ended up on major releases and didn’t even notice because it just showed up upon my next reboot. On iOS I’m stuck without a phone for 10-15 minutes, which isn’t usually a problem when planned but feels rather archaic.
To emphasize, this isn’t really a serious issue for most users, I’d imagine. I just wouldn’t want to see this as the model for improved Mac updates.
To emphasize, this isn’t really a serious issue for most users, I’d imagine. I just wouldn’t want to see this as the model for improved Mac updates.
iOS updates are not exactly fast either. I've never seen latest iPad or iPhone updating in less than ~10 minutes, even for minor changes with the ~200-300 Mb update size.
One reason is macOS updates are using LZMA, which is not exactly fast to decompress.
Yikes. As a Linux guy my instinct is to go in and fix that but I can't :( it hurts sometimes. I recall also that a guy hacking around with Linux on the M1 found a CPU feature for VM optimisation that isn't implemented in macOS. Again, would love to add support for that, but I can't.
I’ve been feeling that too as I’ve been trying to do little bits of open source. Windows has a ton of little bugs that probably wouldn’t take much to fix, but the feedback goes into a black hole. I asked someone at Microsoft about it one time on GitHub, they said “that’s broken, but even if we started the work now and fixed it, you won’t see it for a year”. I get there’s good reasons for that sometimes, but other times things just don’t work right.
Actually, for mature critical parts of a linux distro, even small changes can take years to reach end users.
I bet that changing the compression used by apt would need a little study of libapt, than understand the process to send the patch... in the specific case of apt, you'll have to write unit tests and persuade developers to accept your changes.
If it is accepted you'll may have to wait maybe even 3 years for it to finally reach an Ubuntu LTS when it will finally be deployed to end users who limit themselves to LTS versions by OEM vendors.
In the end, I understand them. A good balance between stability and new features is needed.
I bet that changing the compression used by apt would need a little study of libapt, than understand the process to send the patch... in the specific case of apt, you'll have to write unit tests and persuade developers to accept your changes.
If it is accepted you'll may have to wait maybe even 3 years for it to finally reach an Ubuntu LTS when it will finally be deployed to end users who limit themselves to LTS versions by OEM vendors.
In the end, I understand them. A good balance between stability and new features is needed.
Adding a new compression format is some work, but apt (like most package managers) supports a range of compression formats and you don't have to do anything to tell it to use a different one; it figures it out from the package archive file itself.
The dpkg patches required to add zstd support for .deb packages are pretty small, but they've also languished in Debian for a couple years.[1] But Debian's bureaucracy seems especially slow to move, and in general this kind of issue (inefficient compression in a packaging format) is not the kind of issue Linux distros suffer the worst from.
Ubuntu, Fedora, Arch, NixOS, GuixSD, Solus, and Void Linux are all already using zstd compression for OS installation, packaging, or both. That pretty much covers your bases for downstream distros and also oddball, niche things. openSUSE will presumably switch to using zstd compression for packaging when they change defaults from zypper to dnf for their high-level package manager.
A lot of Linux package managers just use FreeBSD's libarchive for all of their compression needs, which covers a ton of formats. Presumably Apple could do the same with their imaging tools.
—
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664
The dpkg patches required to add zstd support for .deb packages are pretty small, but they've also languished in Debian for a couple years.[1] But Debian's bureaucracy seems especially slow to move, and in general this kind of issue (inefficient compression in a packaging format) is not the kind of issue Linux distros suffer the worst from.
Ubuntu, Fedora, Arch, NixOS, GuixSD, Solus, and Void Linux are all already using zstd compression for OS installation, packaging, or both. That pretty much covers your bases for downstream distros and also oddball, niche things. openSUSE will presumably switch to using zstd compression for packaging when they change defaults from zypper to dnf for their high-level package manager.
A lot of Linux package managers just use FreeBSD's libarchive for all of their compression needs, which covers a ton of formats. Presumably Apple could do the same with their imaging tools.
—
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664
The advantage on Linux and friends is that if you really want or need the fix you can apply it yourself.
This is why I love using Gentoo. I'll sometimes see bug fixes hours after they are made.
>even if we started the work now and fixed it, you won’t see it for a year
So, fix it. Let it be fixed, and then no longer an issue. But because it won't be deployed until a year out, it's not going to be fixed. That's just dumb.
So, fix it. Let it be fixed, and then no longer an issue. But because it won't be deployed until a year out, it's not going to be fixed. That's just dumb.
You don't get your choice in compression technology used by a Linux distribution. If there's some linux distro out there that does offer that choice, that's a waste of resources.
Completely wrong. Initramfs compression is configurable on most distributions for example.
Most Linux distros have adopted zstd, and you almost certainly never need anything else. But even so, packages can be compressed in one of several different formats typically.
There could be a good reason for it not being implemented by Apple, but I agree. At least knowing why it’s not yet or if it will be implemented would be nice, but it’s generally a black box.
>Yikes. As a Linux guy my instinct is to go in and fix that but I can't :( it hurts sometimes
As if you could do that for a random distro you've used? Good luck trying to get them to change how they compress updates upstream, accept your patches, and so on.
More realistically you could just change to another distro with a different method of updating.
But then again if your issue was not with something distro-dependent, but something like a core tool you want to use (regardless of distro, say, Wayland, Gnome, or GIMP, or GCC), you'll again either have a hard time getting into the community, sending patches, and having them accepted and integrated, or a hard time maintaining them on your own branch.
There are issues with Gnome for example, with thousands of user complaints, that haven't been touched for years (e.g. preview in file picker, iirc is a classic example).
As if you could do that for a random distro you've used? Good luck trying to get them to change how they compress updates upstream, accept your patches, and so on.
More realistically you could just change to another distro with a different method of updating.
But then again if your issue was not with something distro-dependent, but something like a core tool you want to use (regardless of distro, say, Wayland, Gnome, or GIMP, or GCC), you'll again either have a hard time getting into the community, sending patches, and having them accepted and integrated, or a hard time maintaining them on your own branch.
There are issues with Gnome for example, with thousands of user complaints, that haven't been touched for years (e.g. preview in file picker, iirc is a classic example).
I don't know where you're getting this from but most userspace projects are very open to patches and change especially if it brings objective improvements. The only project I know of that is more conservative is GNOME. In that case I could always fork if I wanted to introduce something that wasn't accepted upstream.
It feels like it's rehashing and verifying every file in the OS.
Yet at the same time it doesn't feel like it's doing any work. It's an M1 Pro but I still don't hear the fans kick in or feel it warming up at all. So I feel like there is probably room for optimisation, whatever the update process does.
macOS schedules software updates on the "efficiency" cores of the M1, which is why it takes forever and doesn't seem to cause any slowdown.
It should probably use all cores while there is an Apple logo and a progress bar (and the user is essentially locked out).
Fun detail - newer IBM mainframes enable all cores (including the ones that are there but you didn't pay for) during the boot process to reduce downtime.
Fun detail - newer IBM mainframes enable all cores (including the ones that are there but you didn't pay for) during the boot process to reduce downtime.
That’s actually pretty amazing. But sometimes I’ve set aside time to do the update and I’d like it to go as fast as possible. I wonder if there’s a way to force it on the performance cores?
Yes, I agree entirely. Once I wasted a half work-day waiting for Xcode to install itself, which is how I came to discover and research this feature. I would have much rather used my four fastest-you-can-buy cores than waste a morning waiting.
That is just M1, it sure eat up all CPU when doing it on x86.
Pretty sure it does do this.
I had that same hypothesis as well until recently when I disabled some unnecessary daemons by 1. booting into Recovery with SIP disabled and 2. changing a handful of the /System/LaunchAgents/*.plist files to .plist.bak files, effectively disabling for all future reboots.
Since doing this, I've gone through a few security updates and was expecting the udpates to find that the original .plist files were missing and put them back in, but alas they did not as they remained as is.
Since doing this, I've gone through a few security updates and was expecting the udpates to find that the original .plist files were missing and put them back in, but alas they did not as they remained as is.
No different from any other OS, feature updates take forever on Windows.
Theyre much faster on Linux and Android.
They are pretty fast on my PC and I don't even have an NVMe SSD
I was just doing it on my Windows box and it maxed out the hard disk's IO for about an hour. I don't know what it was doing in the background, but, compared to what it was downloading, it was a surreal amount of work.
It's understandable Windows updates take longer because Windows offers the guarantee that a file path will always point to the same while the machine is running, as opposed to Unix environments where they only guarantee your file pointer will point to the same file. This makes upgrading a running machine a bit more complicated than replacing files from under running processes. I'm not even sure how I would implement such a thing. Probably file system overlays and collapse them on reboot.
It's understandable Windows updates take longer because Windows offers the guarantee that a file path will always point to the same while the machine is running, as opposed to Unix environments where they only guarantee your file pointer will point to the same file. This makes upgrading a running machine a bit more complicated than replacing files from under running processes. I'm not even sure how I would implement such a thing. Probably file system overlays and collapse them on reboot.
It’s imposible it maxed out your IO for an hour unless you have a mechanical disk.
It has a mechanical disk. It’s the machine I use to test and build things under Windows.
Still, it’s crazy when compared to the sister box that’s identical but runs Ubuntu, which remains usable through the whole upgrade process (and takes a lot less time unless it’s a full OS upgrade)
Still, it’s crazy when compared to the sister box that’s identical but runs Ubuntu, which remains usable through the whole upgrade process (and takes a lot less time unless it’s a full OS upgrade)
My theory - I believe that BigTech started releasing huge updates to normalise having an always-on internet connection during updates and normalised the slow update process for the opportunity it provides them to mine and analyse all data on your computer. Often an update is the only time when they can (and do) reset and toggle all the privacy settings back to their favour, and then do on device analysis (like collecting meta data of all your files or analysing your photos etc.). They can then send the data back to their servers to add to your profile they have on you unencumbered (no pesky application firewalls to deal with it). That's why I always make it a point to immediately switch off my router after downloading an OS update and starting an install.
(Both Windows and macOS spend a lot of time in indexing your files - processes which can also be done post-installation - and doing all sorts of on-device analysis on your files to provide some specific feature, for example facial recognition on photos. And both collect a lot of your data during this process.)
(Both Windows and macOS spend a lot of time in indexing your files - processes which can also be done post-installation - and doing all sorts of on-device analysis on your files to provide some specific feature, for example facial recognition on photos. And both collect a lot of your data during this process.)
There's a fun podcast episode from 2012 where Siracusa flogs HFS+ and praises ZFS, for two hours: https://5by5.tv/hypercritical/56
With a thorough explanation that filesystems shouldn't ever lose track of intact and corrupted data, in the 2010s—i.e. should have checksums of the data. Plus some discussion of WinFS/ReFS on top, and a story of how ZFS almost landed in OSX.
I listened to it a few years later, but before APFS properly arrived on my Macbook. Was just the right mix of indignation with fascination that someone can go on about it for two hours straight.
Which reminds me: perhaps I should look into receiving further rants about computing in audio format. Sitting on my ass before the screen does me no good.
With a thorough explanation that filesystems shouldn't ever lose track of intact and corrupted data, in the 2010s—i.e. should have checksums of the data. Plus some discussion of WinFS/ReFS on top, and a story of how ZFS almost landed in OSX.
I listened to it a few years later, but before APFS properly arrived on my Macbook. Was just the right mix of indignation with fascination that someone can go on about it for two hours straight.
Which reminds me: perhaps I should look into receiving further rants about computing in audio format. Sitting on my ass before the screen does me no good.
"rants about computing in audio format"
sounds like a lot of the podcasts I listen to :)
sounds like a lot of the podcasts I listen to :)
Happy to be unvisionary on this one, but the change log I wish for the next major release is this one:
- We changed nothing, but spent most our time on Bluetooth reliability, and remaining time on general reliability.
That’d meaningfully impact most working days, whereas most of the last few majors really haven’t.
- We changed nothing, but spent most our time on Bluetooth reliability, and remaining time on general reliability.
That’d meaningfully impact most working days, whereas most of the last few majors really haven’t.
OSX bluetooth is far more reliable than Windows. It's not even close, it's like comparing beer pong to shooting the moon with a rifle.
If I only had my Windows machines, I would have thrown out all my bluetooth peripherals.
If I only had my Windows machines, I would have thrown out all my bluetooth peripherals.
I've had the opposite experience; I've used the same Bluetooth headphones, mouse, and keyboard with two work machines (a MacBook and a Linux tower) and my personal Windows machine.
Windows is rock-solid, just works with no problems.
Linux works mostly fine, with occasional audio stuttering issues that go away after a few seconds.
The MacBook is an unusable nightmare. If I ever try to use a mic or webcam of any sort while the headphones are connected, the whole Bluetooth stack immediately crashes and doesn't recover for at least an entire minute, usually more like 2-3 minutes. Also, sometimes this happens just randomly anyways with no discernable pattern or cause. Also, sometimes the Bluetooth stack forgets my keyboard exists, and I have to walk back through the pairing process again (this happens 1-3 times per month). Then there are times when it randomly shuffles scroll speed on my mouse.
If it weren't so frustrating how unusable the macOS Bluetooth stack is, it would be almost funny in a "hidden-camera-prank-show" sort of way.
I've switched to working full-time on my Linux tower (also provided by my employer) and it's been a tremendous quality of life improvement. On the rare occasions that I have issues, I can usually get to the bottom of the problem and fix it. With the MacBook, I'm lucky if I get "Something went wrong :(", and all the voodoo remedies I've seen online haven't helped.
Windows is rock-solid, just works with no problems.
Linux works mostly fine, with occasional audio stuttering issues that go away after a few seconds.
The MacBook is an unusable nightmare. If I ever try to use a mic or webcam of any sort while the headphones are connected, the whole Bluetooth stack immediately crashes and doesn't recover for at least an entire minute, usually more like 2-3 minutes. Also, sometimes this happens just randomly anyways with no discernable pattern or cause. Also, sometimes the Bluetooth stack forgets my keyboard exists, and I have to walk back through the pairing process again (this happens 1-3 times per month). Then there are times when it randomly shuffles scroll speed on my mouse.
If it weren't so frustrating how unusable the macOS Bluetooth stack is, it would be almost funny in a "hidden-camera-prank-show" sort of way.
I've switched to working full-time on my Linux tower (also provided by my employer) and it's been a tremendous quality of life improvement. On the rare occasions that I have issues, I can usually get to the bottom of the problem and fix it. With the MacBook, I'm lucky if I get "Something went wrong :(", and all the voodoo remedies I've seen online haven't helped.
Linux is easily the worst (well, at least Ubuntu and Mint) with respect to Bluetooth pairing and remembering it for me.
I use a multi-device Bluetooth keyboard to switch between a Windows laptop, Ubuntu laptop and a MacBook Pro almost daily. So when I tap the button in the keyboard to switch, it takes 5 seconds to connect (if it connects) on Ubuntu, almost instantly in Windows, and couple of seconds on Mac.
And Ubuntu laptop cannot do wakeup from sleep with Bluetooth keyboard or mouse even with tons of tinkering with the /usb/devices/*/power/wakeup conf and in /etc/rc.local and /etc/init.d.
I use a multi-device Bluetooth keyboard to switch between a Windows laptop, Ubuntu laptop and a MacBook Pro almost daily. So when I tap the button in the keyboard to switch, it takes 5 seconds to connect (if it connects) on Ubuntu, almost instantly in Windows, and couple of seconds on Mac.
And Ubuntu laptop cannot do wakeup from sleep with Bluetooth keyboard or mouse even with tons of tinkering with the /usb/devices/*/power/wakeup conf and in /etc/rc.local and /etc/init.d.
>And Ubuntu laptop cannot do wakeup from sleep with Bluetooth keyboard or mouse even with tons of tinkering with the /usb/devices/*/power/wakeup conf and in /etc/rc.local and /etc/init.d.
Install powertop and disable the usb-sleep option.
Install powertop and disable the usb-sleep option.
I'm not sure what that saying means. Both sound absurdly unreliable, but I like it!
OSX bluetooth is reliable with Apple bluetooth products and vice versa. Bring anything else into that ecosphere and it can be a nightmare.
I have been running Debian on all of my laptop computers since 1999, just copying the whole file system to new hardware when upgrading. I only re-installed it once when switching from 32 to 64 bit.
Are you saying that you have been upgrading the same install since 1999 without having to ever reinstall from scratch? I find that to be impressive. Does it take a massive amount of effort?
The Debian upgrade process is very effortless, and if you're not running anything from an outside repository is just a matter of updating the release codename in your sources.list and doing an `apt update` then `apt dist-upgrade`
Obviously your mileage may vary, but the 8 upgrades of Debian 10 to 11 I did were exactly that for me.
Edit: realized I lied and the Canon driver wasn't ready for Debian 11 so rolled my print server back. You'll have to decide for yourself whether this is a Debian problem or not
Obviously your mileage may vary, but the 8 upgrades of Debian 10 to 11 I did were exactly that for me.
Edit: realized I lied and the Canon driver wasn't ready for Debian 11 so rolled my print server back. You'll have to decide for yourself whether this is a Debian problem or not
You need a bit of continuous effort to be thoughtful of how you install software - not letting random make installs scribble over your install.
Yes, this is my main issue with most Linux distros.
Building and installing stuff yourself using the default directory prefix is potentially dangerous. It can turn your installation into a mess, and there's no way to undo it (unless you're using a filesystem that supports snapshots, but even then it is tricky if the problems appear much later).
However, I suspect this issue also exists with macOS.
Building and installing stuff yourself using the default directory prefix is potentially dangerous. It can turn your installation into a mess, and there's no way to undo it (unless you're using a filesystem that supports snapshots, but even then it is tricky if the problems appear much later).
However, I suspect this issue also exists with macOS.
A modern way to work around this problem is using distro agnostic containerized packages like snaps, flatpaks, nix, guix or homebrew.
I've been using old Ubuntu distros which still get security patches with flatpaks. This gives me a good balance of stability and modern user space software.
As an experiment, I'm keeping a Debian 11 in which I installed flatpak and GNU Guix. I can use very recent GCC versions and still have a very stable system. I still plan to install homebrew on it to watch how the different parts will interact.
I've been using old Ubuntu distros which still get security patches with flatpaks. This gives me a good balance of stability and modern user space software.
As an experiment, I'm keeping a Debian 11 in which I installed flatpak and GNU Guix. I can use very recent GCC versions and still have a very stable system. I still plan to install homebrew on it to watch how the different parts will interact.
Do you also bump the kernel version? I think container managers make use of new kernel security measurements. Some functionality probably won't work(or silently disabled) if the kernel is way too old.
On my stable system, I leave the kernel to the package manager. On my experimental system, I compiled a recent kernel.
How do you install stuff that you compile from source?
Most things compiled from source default to /usr/local , so they may interfere but not break package manager installed packages. It is also possible to use --prefix while configuring, so I can install it without using sudo , but I have to change some environment vars to use it.
I still haven't tried it, but my next step will be to try homebrew.
I still haven't tried it, but my next step will be to try homebrew.
Homebrew also messes with /usr/local (it stores symlinks there), so this could interfere with the native package manager, I suppose. For example, if you install and then purge a package, it could overwrite symlinks and then remove them (also if the package is a dependency of the package you're interested in).
Also, how would you install Python wheels in a system-wide manner?
Also, how would you install Python wheels in a system-wide manner?
> Homebrew also messes with /usr/local (it stores symlinks there), so this could interfere with the native package manager, I suppose. For example, if you install and then purge a package, it could overwrite symlinks and then remove them (also if the package is a dependency of the package you're interested in).
This is the output of "tree /usr/local" on my non-experimental system:
> Also, how would you install Python wheels in a system-wide manner?
No sure, but I think it can be done with guix.
This is the output of "tree /usr/local" on my non-experimental system:
marco@marco-Inspiron-3421:~$ tree /usr/local/
/usr/local/
├── bin
├── etc
├── games
├── include
├── lib
│ ├── python2.7
│ │ ├── dist-packages
│ │ └── site-packages
│ └── python3.8
│ └── dist-packages
├── man -> share/man
├── sbin
├── share
│ ├── ca-certificates
│ ├── fonts
│ ├── man
│ ├── sgml
│ │ ├── declaration
│ │ ├── dtd
│ │ ├── entities
│ │ ├── misc
│ │ └── stylesheet
│ ├── texmf
│ └── xml
│ ├── declaration
│ ├── entities
│ ├── misc
│ └── schema
└── src
29 directories, 0 files
> Also, how would you install Python wheels in a system-wide manner?
No sure, but I think it can be done with guix.
Right - good hygiene is key here. Make proper use of /usr/local and /opt to get stuff separated, and sit on your hands before you type when it comes to pip and the like. When I suspect problems I usually run a few `debsums` to make sure my installed files are still the originals from upstream.
My current Intel Mac still has some remnants from running Mac OS X 10.2-10.4 on a G4 equipped Powermac 7300 using XPostFacto.
Every so often I run into very odd plists and remnants of long obsolete programs. I’ve used the migration assistant each time I moved from Mac to Mac. All the PPC only apps went away when Rosetta was removed and the 32bit Carbon apps were similarly discarded. Support files sometimes stick around but the transfer agent is generally pretty tidy.
Every so often I run into very odd plists and remnants of long obsolete programs. I’ve used the migration assistant each time I moved from Mac to Mac. All the PPC only apps went away when Rosetta was removed and the 32bit Carbon apps were similarly discarded. Support files sometimes stick around but the transfer agent is generally pretty tidy.
Time Machine quietly bridges these architectural transition. It's no mean feat to migrate PPC->Intel and then Intel->M1. It silently works and this is the Mac at its best.
I was managing many systems from 2012 to 2019, upgrading from Debian 6 to 10 in the process, and it was always smooth (I was hitting some bugs, but I would hit these with a clean install too).
I have written an article on this, unfortunately in Czech, but you can try Google Translate: https://www-abclinuxu-cz.translate.goog/blog/jenda/2020/12/2...
TL;DR:
- perform apt-get dist-upgrade, apt-get autoremove, apt-get clean
- migrate postgresql database to a new version, if installed
- run `aptitude search "?narrow(?installed,?not(?archive(stable)))"` to find leftover packages from older releases. Install alternatives and remove these old packages.
- once in a while, run
for p in `dpkg -l | grep ^ii | cut -d " " -f 3 | grep -E "^lib"`; do echo "if [ \`apt-get -s purge $p | grep -E \"^(Purg|Inst|Conf)\" | wc -l\` -eq 1 ]; then echo $p; fi" done | parallel
to find libraries that nothing depends on
- when taking over a system from a previous sysadmin, run debsums -c and maybe also a complete audit of all files that are not managed by a package manager (though this has lots of false-positives, so it needs an expert judgement)
# locate * | grep -vE "^/(home|tmp|mnt|boot|opt|root|srv|usr/local|var/cache|var/lib|var/log|var/tmp|var/mail|var/www)/" | sort -u > /tmp/allfiles
# sort -u /var/lib/dpkg/info/*.list > /tmp/allfiles2
# comm -23 /tmp/allfiles /tmp/allfiles2 |less
I have written an article on this, unfortunately in Czech, but you can try Google Translate: https://www-abclinuxu-cz.translate.goog/blog/jenda/2020/12/2...
TL;DR:
- perform apt-get dist-upgrade, apt-get autoremove, apt-get clean
- migrate postgresql database to a new version, if installed
- run `aptitude search "?narrow(?installed,?not(?archive(stable)))"` to find leftover packages from older releases. Install alternatives and remove these old packages.
- once in a while, run
for p in `dpkg -l | grep ^ii | cut -d " " -f 3 | grep -E "^lib"`; do echo "if [ \`apt-get -s purge $p | grep -E \"^(Purg|Inst|Conf)\" | wc -l\` -eq 1 ]; then echo $p; fi" done | parallel
to find libraries that nothing depends on
- when taking over a system from a previous sysadmin, run debsums -c and maybe also a complete audit of all files that are not managed by a package manager (though this has lots of false-positives, so it needs an expert judgement)
# locate * | grep -vE "^/(home|tmp|mnt|boot|opt|root|srv|usr/local|var/cache|var/lib|var/log|var/tmp|var/mail|var/www)/" | sort -u > /tmp/allfiles
# sort -u /var/lib/dpkg/info/*.list > /tmp/allfiles2
# comm -23 /tmp/allfiles /tmp/allfiles2 |less
At least in my experience, it's a matter of separation of data vs os. I can reinstall the os or upgrade as needed. Then copy my data over separately from the OS itself.
What probably helps is that I'm running Debian "unstable", which provides more or less a continuous flow of updates instead of dropping a full release periodically. I just apt-update/apt-upgrade every few weeks, usually resulting in tens or hundreds of packages getting updated. I had to resolve some minor issues with broken dependencies a handful of times, but for the rest it has been pretty much effortless.
Why would it? Software doesn't rot with time (unless it's made to).
One of the nicer things about Linux is that it's just software. It's not trying to implement any corporate ownership over your hardware.
How’s your init process looking?
Well they try. Almost all distros have tried/had someone try, over time.
I find it hard to believe (but give you the benefit of the doubt), as Debian on 1999 (I was using it from 1999 to 2004, professionally on servers and desktops) was a hot mess upgrading, with tons of crap from the package manager.
Same here, on a number of machines. One of them - an Intel SS4200, now retired - I migrated from 32bit to 64bit without a reinstall. This seamless upgrade path was my main reason to move from an RPM-based distribution to Debian somewhere back in 1998, having moved to Redhat from Slackware before than and from SLS to Slackware before that, from nothing to SLS somewhere in 1992.
I am running the same home folder on my M1 Mac as I started with on Red Hat Linux in 1998. The Linux, then FreeBSD, then Mac systems were each continuous upgrades within each OS, too.
So if you got malware the last 20 years your system could still be infected? Not saying that risk outweighs the pros, but that is something I think is nice each fresh install.
You can audit that the installed files match these from the packages (with the debsums program), though I don't know where to easily get the checksum file from an independent trusted source (as the checksums themselves can be tampered with the malware to match).
It is good to run this once a while even for non-security reasons: you can detect hardware problems (notoriously failing SD cards in Raspberry Pis) and mistakes, like installing a custom program to /usr instead of /opt and accidentally overwriting system files.
It is good to run this once a while even for non-security reasons: you can detect hardware problems (notoriously failing SD cards in Raspberry Pis) and mistakes, like installing a custom program to /usr instead of /opt and accidentally overwriting system files.
That only works for files altered in place, not extra .so files, cronjobs, lines injected into global bashrc/profile, that kind of thing.
(Granted, those are unlikely to survive for many years without breaking or otherwise getting caught)
(Granted, those are unlikely to survive for many years without breaking or otherwise getting caught)
You can scan for extra files too.
Yeah, backdooring configuration/bashrc is a problem, unfortunately, you will probably copy the configuration after the reinstall, thus copying the backdoor too.
Yeah, backdooring configuration/bashrc is a problem, unfortunately, you will probably copy the configuration after the reinstall, thus copying the backdoor too.
That kind of reminds me of this story from 2019:
https://changelog.complete.org/archives/9969-goodbye-to-a-15...
https://changelog.complete.org/archives/9969-goodbye-to-a-15...
The latest update bricked many laptops at work. Like no boot, no sad Mac, get a new laptop situation. We are at the point where people joke they are flipping a coin on whether the next update from Apple will brick their laptop or not.
For me, the macOS ecosystem is no longer reliable enough as a daily driver.
For me, the macOS ecosystem is no longer reliable enough as a daily driver.
I remember helping a friend a few years ago who thought he had truly bricked his MacBook. There is a restore process that reinstalls the OS when an update goes wrong. I don’t recall the process now as I’ve never needed it since but it is somewhere on Apples site. I seriously doubt these laptops are truly bricked. Obviously something cause the installer to fail but there are recovery options built in that are not part of the OS.
this is probably a good place to start https://support.apple.com/guide/mac-help/macos-recovery-a-ma...
this is probably a good place to start https://support.apple.com/guide/mac-help/macos-recovery-a-ma...
(this recovery process is also available for Apple T2 x86 Macs)
Unfortunately they won't even turn on so this won't work.
The recovery process is bootROM (non-erasable) based, it works even if they cannot be turned on.
For T2: https://support.apple.com/guide/apple-configurator-2/revive-...
For M1: https://support.apple.com/en-gb/guide/apple-configurator-2/a...
For T2: https://support.apple.com/guide/apple-configurator-2/revive-...
For M1: https://support.apple.com/en-gb/guide/apple-configurator-2/a...
Because of unstable security crap your company's IT installs on them? You can't seriously blame Apple for problems that only happen on your work laptops.
How do you know, do you work there? What in the parent post indicated your assertion?
I think it's a reasonable inference, given that this is not a widespread problem outside of this person's office. Since that's the case but it is frequent enough in that office for it to be notable, it'd indicate that some software that the company is installing is the culprit.
To what do you attribute your company's unusual experience?
Good question. I can only guess at maybe usb-c devices being connected? That would be external monitors via a USB-C dock, and so on. Otherwise I have no idea why.
That makes sense. USB-C docks are in a weird place, to the point where the few with a good reputation can command what to me are preventably high premiums. And even then there are gremlins.
My MBP2017 came with a few issues and a every update was a flip the coin, it could have go either way good or bad. Bluetooth didn’t work well with my mouse, keyboard has some issues, speaker blowed off, etc. When Apple did the butterfly keyboard recall, they replaced the chasis and that pretty much everything aside from the bottom cover and the monitor. Since then, my computer has been amazing, no issues, better battery, better keyboard, connectivity, Bluetooth and more importantly every update has gone flawless. I’m wondering if it was a board problem, but whatever it was it definitely made MacOS way more reliable too.
I used to update Mac OS versions day one. Now I put at least a month buffer before updating. Mac OS never used to nag so much about updates.
Why is it that MacOS feels more and more like Windows did 10 years ago? Slower, bloatier, buggier. In 2015, I used to go months between reboots on my MacBook Pro. In 2021, I seem to have to reboot my M1 mini at least once a week.
Curious, the only time I reboot my M1 Mac mini is for updates. Otherwise it had been rock solid for me.
Same here. MacOS on my M1 Macbook Pro has been really great so far.
hmmm not like that here. MacBook Air M1: it's the "living room computer", the one to surf from the couch and I do really dig it but once in a while everything locks up. I don't know why. Sometimes it does unstucks itself while at other times I force it off (and when it's all blocked and I hold the button to turn it off, even that is kinda not very responsive).
I doesn't happen often, once every few days. But it's not anywhere near "Debian Linux" stable (where six months of uptime for a desktop are a regular thing).
I doesn't happen often, once every few days. But it's not anywhere near "Debian Linux" stable (where six months of uptime for a desktop are a regular thing).
Had my M1 MBA since last Nov, use every day for hours. Only rebooted when system updates came out. I would get Apple on it. Might be hardware.
That's the same as saying 'buy a new one :)'. The bets of Apple fixing anything and not just telling you to replace your 13 month old laptop are slim at best.
Apple has always been great to me with fixing things as long as I took it in to an apple store. The few times they didn’t do it for free they did the repairs at what I would consider a reasonable price. If someone it having issues with their apple hardware that is the first place to start, assuming you have an apple store that you can get to.
Third, I push mine super hard and it doesn't break a sweat with anything. Never reboot.
>Why is it that MacOS feels more and more like Windows did 10 years ago? Slower, bloatier, buggier. In 2015, I used to go months between reboots on my MacBook Pro. In 2021, I seem to have to reboot my M1 mini at least once a week.
Some bizarro software, perhaps some that had you bypass SIP?
Otherwise, I never had to reboot my M1 since I bought it last year (except for minor updates and Monterey).
Some bizarro software, perhaps some that had you bypass SIP?
Otherwise, I never had to reboot my M1 since I bought it last year (except for minor updates and Monterey).
Likely ongoing teething issues with M1? It's a big lift to move an OS to an entirely new architecture, and haven't seen or heard of the same on Intel.
I don’t feel this way at all, and haven’t since 10.11 (El Capitan). Not that I never need a reboot, just… it hasn’t varied at all for me between major versions since. My observation is that macOS since then has been considered mature by Apple and generally updated to suit other initiatives. Which is fine and should be welcomed here!
I agree. I also see real improvements in Windows nowadays; macOS offers only cosmetics.
> I also see real improvements in Windows nowadays
How is Windows 11's horribly dumbed-down taskbar and start menu a "real improvement"?
They got rid of the old Windows 7 screen-clipping tool but the "new" version from Windows 10 still lacks ultra-basic things like text-annotations and arrow shapes... (but it's got a full-suite of pen-inking tools, which I'm sure everyone uses all the time).
How is Windows 11's horribly dumbed-down taskbar and start menu a "real improvement"?
They got rid of the old Windows 7 screen-clipping tool but the "new" version from Windows 10 still lacks ultra-basic things like text-annotations and arrow shapes... (but it's got a full-suite of pen-inking tools, which I'm sure everyone uses all the time).
Windows 11's start bar makes accessing settings and files easy, and gets out of the damn way of my work rather than pushing information poor animated tiles, shovelware and ads at my face while hogging my entire screen.
Finally, it's just like Windows 7.
I don't use a Surface tablet, but I'm told pen input is a major use case. Maybe pen tools should be made modal rather than uniform even across devices without pen input?
Finally, it's just like Windows 7.
I don't use a Surface tablet, but I'm told pen input is a major use case. Maybe pen tools should be made modal rather than uniform even across devices without pen input?
Nah, the 11 Start Menu is super lacking. I miss being able to make and name app groups in Windows 10.
Plus, it's just lacking in basic and obvious "features." I wish I could default to seeing all apps. I wish that the current default view's bottom third wasn't blocked by a suggestion that can't be hidden.
Ditto with the Taskbar changes. I'd prefer to have only the Windows button left, but app icons centered. Seems obvious, why isn't it there? Additionally, why remote the ability to have small icons or place the taskbar elsewhere but the button?
IMO they regressed and simplified too far and need to walk it back a bit.
The new Windows 11 coat of paint is okay.
Plus, it's just lacking in basic and obvious "features." I wish I could default to seeing all apps. I wish that the current default view's bottom third wasn't blocked by a suggestion that can't be hidden.
Ditto with the Taskbar changes. I'd prefer to have only the Windows button left, but app icons centered. Seems obvious, why isn't it there? Additionally, why remote the ability to have small icons or place the taskbar elsewhere but the button?
IMO they regressed and simplified too far and need to walk it back a bit.
The new Windows 11 coat of paint is okay.
The reason why is kinda silly: so a couple of years ago the Windows org made yet another locked-down, "mobile-first" SKU of desktop Windows designed for larger phablets and ARM devices (which never materialized - though imagine if the Microsoft Surface Duo[1] was expanded to a much wider range of Microsoft and partner-branded devices) - and this included a somewhat simplified shell user-experience - and it ended up as "Windows 10X" and was promoed at the start of this year (look familiar? https://www.windowscentral.com/windows-10x ).
Then something happened in the late-spring 2021 when the shell team all suddenly disappeared - around the same time as Bill Gates' divorce announcement (coincidence? I think not!) and the Windows org's leadership decided to make the bold move of copying-and-pasting Windows 10X#'s cut-down shell, intended for mobile devices, into the full-fat enterprise and desktop SKUs of Windows 11 and call it a day.
My sources and former work-colleague friends at MS tell me that the current shell team (they should call it a fossil team at this point considering it seems there's nothing left of it) is very, very aware of the huge backlash over the removal of essential features like repositioning the taskbar and having individual taskbar buttons, but don't expect a quick-fix - I get the feeling some hotshot PMs will try to use this occasion to pitch their own unique new (and unproven...) concepts on how the shell should work, instead of doing the big fat `git reset HEAD` back to a late-2019 commit that they should be doing... le sigh...
[1] (which runs Android... which is further evidence something went really wrong with the wave-function collapse around 2016)
Then something happened in the late-spring 2021 when the shell team all suddenly disappeared - around the same time as Bill Gates' divorce announcement (coincidence? I think not!) and the Windows org's leadership decided to make the bold move of copying-and-pasting Windows 10X#'s cut-down shell, intended for mobile devices, into the full-fat enterprise and desktop SKUs of Windows 11 and call it a day.
My sources and former work-colleague friends at MS tell me that the current shell team (they should call it a fossil team at this point considering it seems there's nothing left of it) is very, very aware of the huge backlash over the removal of essential features like repositioning the taskbar and having individual taskbar buttons, but don't expect a quick-fix - I get the feeling some hotshot PMs will try to use this occasion to pitch their own unique new (and unproven...) concepts on how the shell should work, instead of doing the big fat `git reset HEAD` back to a late-2019 commit that they should be doing... le sigh...
[1] (which runs Android... which is further evidence something went really wrong with the wave-function collapse around 2016)
Whatever is happening there, is quite clear that the COM / C++ folks are driving it all again.
They are so deep into it, that any complaints from .NET devs ends up being that "it isn't so hard to write a bit of C++ with the clunky C++/WinRT, or [ComImport]", naturally the advice people like to get.
Ah and the fact that they push Win32 with bare bones C++, where each developer has to create their own MFC like frameworks, is yet another example how things went wrong.
They are so deep into it, that any complaints from .NET devs ends up being that "it isn't so hard to write a bit of C++ with the clunky C++/WinRT, or [ComImport]", naturally the advice people like to get.
Ah and the fact that they push Win32 with bare bones C++, where each developer has to create their own MFC like frameworks, is yet another example how things went wrong.
> Microsoft Surface Duo
That's codenamed Andromeda. [1]
And yes, was planned to be a Windows SKU before mobile Windows utterly exploded.
[1] https://www.windowscentral.com/surface-duo-andromeda-windows...
That's codenamed Andromeda. [1]
And yes, was planned to be a Windows SKU before mobile Windows utterly exploded.
[1] https://www.windowscentral.com/surface-duo-andromeda-windows...
> Windows 11's start bar makes accessing settings and files easy
No, it does not. At least, not for me, it doesn't.
Remember that programs are "files" too - and my Windows 10 desktop has a nicely personalized Start Menu with probably about 30 app tiles added to it (roughly 50% are the small size, the rest Large. I don't have any Live Tiles: these are all normal shell shortcuts that exist as basic tiles. I've also employed some tweaks to allow me to have tiles for non-program-shortcuts and document files to my start menu. I have the Start Menu double-wide as well, as I have a large (43-inch) main desktop display. I also have the All Programs menu always visible because I do actually use it a lot.
I know I can simply pin more programs to my taskbar, and I can move the icons back to the left, but I simply cannot use collapsed taskbar buttons because their hit-target is tiiiiny (Fitt's Law is important, which is why it's insane that the Start button isn't in the bottom-left corner, crazy). I also run programs that generate a LOT of open windows - with ungrouped buttons (and thanks to my huge desktop monitor) I'm able to have instant 1-click access to every window - if I was using Windows 11 I'd have to click twice to switch between windows in a taskbar that is somehow both cramped (due to needing to pin more icons for non-open programs) and wasting space (as buttons won't expand to fill empty areas).
At least I'm not one of the unfortunate souls that needs to have their taskbar on the side or top of their monitor (this includes people with disabilities who prefer to not have to glance down so-much) - there's a lot of pain amongst those users right now.
Your uncritical praise just seems so-off when juxtaposed to all of the sincere negative feedback about Windows 11. Yes, people will always complain about change, but the fact people are complaining about the capability-reduced taskbar and start-menu and not the enforced rounded-corners on every window[1] is saying something.
[1] I'm actually offended by the rounded-corners thing, I'll admit: because I thought that there was solid agreement and understanding between the OS and programs that the OS would not impose itself onto the client-area of a window: programs get a perfect rectangle and users should get to see all of that rectangle - with rounded corners (and without thick non-client window-borders to absorb the curves) it means users are being short-changed on their pixels. Serious question: what if a program displays critical status information in the corner pixels of a window? It just makes me feel uncomfortable.
No, it does not. At least, not for me, it doesn't.
Remember that programs are "files" too - and my Windows 10 desktop has a nicely personalized Start Menu with probably about 30 app tiles added to it (roughly 50% are the small size, the rest Large. I don't have any Live Tiles: these are all normal shell shortcuts that exist as basic tiles. I've also employed some tweaks to allow me to have tiles for non-program-shortcuts and document files to my start menu. I have the Start Menu double-wide as well, as I have a large (43-inch) main desktop display. I also have the All Programs menu always visible because I do actually use it a lot.
I know I can simply pin more programs to my taskbar, and I can move the icons back to the left, but I simply cannot use collapsed taskbar buttons because their hit-target is tiiiiny (Fitt's Law is important, which is why it's insane that the Start button isn't in the bottom-left corner, crazy). I also run programs that generate a LOT of open windows - with ungrouped buttons (and thanks to my huge desktop monitor) I'm able to have instant 1-click access to every window - if I was using Windows 11 I'd have to click twice to switch between windows in a taskbar that is somehow both cramped (due to needing to pin more icons for non-open programs) and wasting space (as buttons won't expand to fill empty areas).
At least I'm not one of the unfortunate souls that needs to have their taskbar on the side or top of their monitor (this includes people with disabilities who prefer to not have to glance down so-much) - there's a lot of pain amongst those users right now.
Your uncritical praise just seems so-off when juxtaposed to all of the sincere negative feedback about Windows 11. Yes, people will always complain about change, but the fact people are complaining about the capability-reduced taskbar and start-menu and not the enforced rounded-corners on every window[1] is saying something.
[1] I'm actually offended by the rounded-corners thing, I'll admit: because I thought that there was solid agreement and understanding between the OS and programs that the OS would not impose itself onto the client-area of a window: programs get a perfect rectangle and users should get to see all of that rectangle - with rounded corners (and without thick non-client window-borders to absorb the curves) it means users are being short-changed on their pixels. Serious question: what if a program displays critical status information in the corner pixels of a window? It just makes me feel uncomfortable.
Spend some time watching WWDC sessions regarding network stack, security, userspace drivers, Metal tooling.
One of my beefs with apple is a random WWDC video (that can only be viewed in Safari?) is the only "documentation" of something.
With their policies about only being able to develop for apple on Apple hardware, their walled gardens, extremely locked down APIs, horrible/missing documentation, Apple is very developer hostile.
With their policies about only being able to develop for apple on Apple hardware, their walled gardens, extremely locked down APIs, horrible/missing documentation, Apple is very developer hostile.
Apple is quite good for developers targeting their platforms, do not be confused with developer === UNIX/FOSS.
I don't expect developers targeting Windows, mainframes, consoles, to do it from other platforms either.
I don't expect developers targeting Windows, mainframes, consoles, to do it from other platforms either.
> Apple is quite good for developers targeting their platforms
https://www.caseyliss.com/2020/11/10/on-apples-pisspoor-docu...
https://news.ycombinator.com/item?id=24410652
https://www.theverge.com/2021/4/21/22385859/apple-app-store-...
https://v4.chriskrycho.com/2019/apple-your-developer-documen...
> I don't expect developers targeting [. . .] consoles, to do it from other platforms either.
Consoles are poor example since I don't know a single console that lets you compile your game on it. All console manufacturers provide a development environment that runs on Windows, Linux, macOS, or a combination of those.
https://www.caseyliss.com/2020/11/10/on-apples-pisspoor-docu...
https://news.ycombinator.com/item?id=24410652
https://www.theverge.com/2021/4/21/22385859/apple-app-store-...
https://v4.chriskrycho.com/2019/apple-your-developer-documen...
> I don't expect developers targeting [. . .] consoles, to do it from other platforms either.
Consoles are poor example since I don't know a single console that lets you compile your game on it. All console manufacturers provide a development environment that runs on Windows, Linux, macOS, or a combination of those.
Most developer are quite alright with Apple Store, they were quite worse with 80% being paid to mobile operators, but now some vocal minority wants more.
I was expecting that answer for consoles, and yes all their SDKs are Windows only, with VS plugins.
I was expecting that answer for consoles, and yes all their SDKs are Windows only, with VS plugins.
You're legally permitted to run a Windows VM on Apple hardware, but not vice versa.
The idea of a CI/server for Apple software is a Mac mini... Not exactly production grade. Apples hardware/software lock in is disgusting.
Apple has no concerns for backward compatiblility.
Apple is developer hostile.
The idea of a CI/server for Apple software is a Mac mini... Not exactly production grade. Apples hardware/software lock in is disgusting.
Apple has no concerns for backward compatiblility.
Apple is developer hostile.
> The idea of a CI/server for Apple software is a Mac mini... Not exactly production grade. Apples hardware/software lock in is disgusting.
while obviously not applicable to all circumstances, and no idea what state it's in, but they are addressing this with Xcode Cloud...
while obviously not applicable to all circumstances, and no idea what state it's in, but they are addressing this with Xcode Cloud...
All of then irrelevant for developers targeting Apple ecosystem, and if one really does CI/CD there is Xcode cloud.
MacOS major updates are far from only cosmetics. Apple does a bad job in sharing it with the broad public but every year they bring new features. Sometimes they are slower, an API addition one year, a deprecation in the next one and so on.
Hasn't Windows Update had issues that deleted user files for the last three years running?
>Early during installation, the Data volume is unmounted, ensuring that its contents are protected from any ill-effects of failed installation. The System volume is mounted for writing and SIP disabled
This sounds like a needed mitigation that Windows could stand to copy.
>Early during installation, the Data volume is unmounted, ensuring that its contents are protected from any ill-effects of failed installation. The System volume is mounted for writing and SIP disabled
This sounds like a needed mitigation that Windows could stand to copy.
[deleted]
I think popular applications should be included with OS reliability because in your day to day these are the tools you use.
I've been using a MBP (2020 Intel) for work (work issued laptop) for about a week full time and if I leave Chrome open for more than a day every tab will crash even if I only have a few tabs open. Opening a new tab results in the "Aw, Snap!" crashed tab page with the unhappy face until I fully close Chrome then it works like normal. The only extensions I use are uBlock Origin and LastPass.
It happens frequently. The system isn't stressed in the slightest too in terms of CPU or memory usage. Does this happen for anyone else? It's running the latest Big Sur.
This hasn't happened to me ever on Windows or Linux after years of hardcore usage.
I've been using a MBP (2020 Intel) for work (work issued laptop) for about a week full time and if I leave Chrome open for more than a day every tab will crash even if I only have a few tabs open. Opening a new tab results in the "Aw, Snap!" crashed tab page with the unhappy face until I fully close Chrome then it works like normal. The only extensions I use are uBlock Origin and LastPass.
It happens frequently. The system isn't stressed in the slightest too in terms of CPU or memory usage. Does this happen for anyone else? It's running the latest Big Sur.
This hasn't happened to me ever on Windows or Linux after years of hardcore usage.
> I think popular applications should be included with OS reliability because in your day to day these are the tools you use.
Mac ships with Safari if you want that. Blaming Mac for the quality of third party software is a bit odd.
Mac ships with Safari if you want that. Blaming Mac for the quality of third party software is a bit odd.
> I think popular applications should be included with OS reliability because in your day to day these are the tools you use.
I think you're understating it. The point of the OS is to run applications; if running applications doesn't work, the system is probably insufficient.
I think you're understating it. The point of the OS is to run applications; if running applications doesn't work, the system is probably insufficient.
Nope, I have the last 16" Intel MBP and Chrome chugs along just fine for days and weeks on end. I pretty much only close it for Chrome prompted app updates or macOS prompted system updates.
edit: It might be worth purging your Chrome files out of the various ~/Library locations.
edit: It might be worth purging your Chrome files out of the various ~/Library locations.
I have a 2016 mbp with lots chrome tabs and other extensions, it works fine for week or two and then everything hangs and the Mac restarts. I am still on Catalina
[deleted]
Adding this website to the user-scalable=0 sin bin. No way I can read that tiny text in those images
Firefox on Android has a nice feature among the accessibility options: every site is user-scalable, in the zoom-in direction.
(I do sometimes wish, however, that zooming out was also always possible: some site authors seem to love children-book-grade font sizes, which fit about three words on a line and ten lines on the screen.)
(I do sometimes wish, however, that zooming out was also always possible: some site authors seem to love children-book-grade font sizes, which fit about three words on a line and ten lines on the screen.)
How often are the SHA-256 hashes on the System volume snapshot checked? Could something that can write to the drive root, and understood APFS, silently change the file without updating its recorded metadata (including hash)? Or is the hash checked every time a file is opened?
Checked all the time, it's a Merkle tree structure.
You can modify the seal when the Sealed System Volume feature is off. (which requires Secure Boot to be set to Permissive Security, and FileVault to be off at the time of disabling)
You can modify the seal when the Sealed System Volume feature is off. (which requires Secure Boot to be set to Permissive Security, and FileVault to be off at the time of disabling)
Why is it possible to turn Sealed System Volume off? Is there a way that malware might be able to turn it off?
Reading https://support.apple.com/en-us/HT208198, the official way to do it requires booting from Mac OS recovery and entering an administrator password.
⇒ there may of course be bugs, but Apple’s intent is there isn’t any way for malware to do that
⇒ there may of course be bugs, but Apple’s intent is there isn’t any way for malware to do that
The update to Monterey broke all my ntfs tools. While I know that Apple officially doesn't support ntfs, it doesn't make it less painful that I can't write to my external mass storage.
> The update to Monterey broke all my ntfs tools.
If your tools are scripts that run in the background, check to make sure the binary running those (e.g. /usr/bin/perl) has the proper permissions.
Each time I've upgraded to Catalina, Big Sur, and now Monterey, I keep forgetting to add the binary to System Preferences… > Security & Privacy > Privacy > Full Disk Access.
Good luck.
If your tools are scripts that run in the background, check to make sure the binary running those (e.g. /usr/bin/perl) has the proper permissions.
Each time I've upgraded to Catalina, Big Sur, and now Monterey, I keep forgetting to add the binary to System Preferences… > Security & Privacy > Privacy > Full Disk Access.
Good luck.
I see the opposite... For example, since a couple of months/updates ago Finder doesn't show me new files in a directory unless I force the search with spotlight. It is remarkable that a bug like this can happen in such a basic feature like the file browser.
I wonder if this “more sealed boot loader” will make it more difficult to dual boot Linux and MacOS? Curious if the Ashai Linux devs have a plan for this.
Nope. You can disable secure boot. https://support.apple.com/en-us/HT208198
Their plan has always required disabling the secure boot stuff.
What's the best way to get this sort of secure book on linux/bsd?
This should carry a (2009) in it's headline.
After Snow Leopard it went downhill with reliability and stability, but got new exciting features: iOS compatibility, yeah. No more x32 support, yeah! No more OpenGL support, yeah! New filesystem without identifier normalization, yeah! No more /use/local/bin/. No more kernel drivers. Mail and mDNSResponder constantly crashing, and every new release the list keeps growing. The new Windows.
After Snow Leopard it went downhill with reliability and stability, but got new exciting features: iOS compatibility, yeah. No more x32 support, yeah! No more OpenGL support, yeah! New filesystem without identifier normalization, yeah! No more /use/local/bin/. No more kernel drivers. Mail and mDNSResponder constantly crashing, and every new release the list keeps growing. The new Windows.
I'm guessing you are not an actual user of the system you are criticizing since you are wrong on so many points. Not my experience at all. Many of your criticisms are simply false. usr/local/bin is fine. OpenGL is an antiquated system that is a poor match to modern GPUs and it too was deprecated for a long time. mDNSResponder did have some issues but we have been past that for many, many years. Never had issues with Mail that a reindex command wouldn't clean up. APFS has been nothing but an improvement in my experience. 32 bit support was deprecated for over a decade. Sometimes it is time to move on.
As far as kernel drivers, yes there are still some 3rd party kernel drivers, but the (ongoing) transition to system extensions running in user space is absolutely an improvement.
As far as kernel drivers, yes there are still some 3rd party kernel drivers, but the (ongoing) transition to system extensions running in user space is absolutely an improvement.
Indeed, only absolute losers would run old games and apps that use OpenGL, when there are new shiny ones.
Homebrew moved out of /usr/local on apple silicon and I've seen people assume that this was because of macOS changing things so that /usr/local was no longer usable. It wasn't; Homebrew just wanted to stop using /usr/local and they saw this as a good time to do the migration.
> Snow Leopard it went downhill with reliability and stability … Mail and mDNSResponder constantly crashing
If this isn’t just hyperbole, try a clean reinstall after a hardware diagnostic. This isn’t normal.
(/usr/local/bin is fine, are you perhaps referring to Homebrew changing its preferred location?)
You can argue about 32-bit support but given that the platform first went 64-bit in 2003 it’s kind of hard to say you didn’t have advanced warning. Similarly, the writing has been the wall for OpenGL since Microsoft stopped favoring it on the most popular platforms in the 1990s. The model doesn’t fit how modern hardware works and it’s not surprising that they don’t want to keep supporting a standard which the industry increasingly doesn’t use.
If this isn’t just hyperbole, try a clean reinstall after a hardware diagnostic. This isn’t normal.
(/usr/local/bin is fine, are you perhaps referring to Homebrew changing its preferred location?)
You can argue about 32-bit support but given that the platform first went 64-bit in 2003 it’s kind of hard to say you didn’t have advanced warning. Similarly, the writing has been the wall for OpenGL since Microsoft stopped favoring it on the most popular platforms in the 1990s. The model doesn’t fit how modern hardware works and it’s not surprising that they don’t want to keep supporting a standard which the industry increasingly doesn’t use.
I thought the whole point of using windows is an insanely long backwards compatibility and future support window? Hence the name windowS? :)