With later start times there is always the temptation to stay up later and I’ve found myself getting a bit lazy around the house so I’m going to get things back in order by heading off to sleep earlier and waking up earlier but before all that I’m going to get my washing all sorted out so that all the lose ends are sorted out before heading off to bed. The washing is hung out in the spare room and got the de-hundifier which is a whole lot cheaper than having a dryer. I’ve got my alarm set to 9:30am but eventually I want to roll my wake up time to 9:00am so basically my free time flips to being before work rather than after work which should also help with ensuring that I don’t snack later on at night – in bed by 11am with a good night sleep.
I’ve been following the improvements in Webkit and I’m looking forward to seeing all the improvements that have been making their way into the Safari product being shipped to consumers. The other part that will be interesting is what the whole ‘run 32bit without compromises’ actually means which has been noted in their 32bit to 64bit transition guide for developers – what do they mean by compromises? I’m leaning towards the removal of carbon based API’s thus leaving the 32bit modern frameworks and then eventually the removal of the 32bit code being more of a long term project but then again I could be wrong and Apple simply goes ‘balls to the wall’ and customers are told “if you want 32bit compatibility then run it in a virtual machine otherwise it is all 64bit with none of the legacy frameworks left over”. One thing to keep in mind is that the move to 64bit benefits Apple given it allowed them to deal with the fragile runtime and base class so in the move to 64bit it allowed them to break compatibility and deal with limitations of the old design and harmonise iOS and macOS operating system at the most fundamental level. To quote to posts I saw on a forum regarding the matter:
Backwards-compatibility is an interesting story on the mac. The Objective-C ABI on 32-bit macOS is what is called the “fragile” runtime because it has the fragile base class problem. Originally Objective-C had the same design flaw as C++: the ivars of every class had to be in the header for all to see so the compiler could rely on the binary layout. A subclass’ ivars would be offset by the compiler by examining the layout of every superclass, then baked into the binary.
In the modern (all iOS and 64-bit macOS) runtime the ivar offsets are patched up at runtime so the layout of classes (including base classes) can change without breaking compatibility. Working around the limitations of the 32-bit Objective-C runtime imposes significant costs, it is far from a simple recompile with a different pointer size. It also adds a lot to the size of the installed OS.
There are also a whole bunch of APIs left out of 64-bit macOS, including almost all of Carbon that dealt with UIs (HIToolbox, ATSUI, QuickDraw, Nav Services, Dialog/Menu/Font Manager, etc). None of these APIs have received anything more than bare maintenance in the last 10 years, and evolving the system while keeping them operational has not been easy.
In a way, this is the true last step of the Mac OS X transition that started in 2001–the removal of the transitional APIs that made it possible.