I have mixed feelings about my new daily driver. For one, I've been a Mac user for over 11 years now and I have come to love features like Find My and Apple Maps as well as Keynote and Numbers as well as Graphics, Cheatsheet, Timetable (both available on iOS and iPadOS too, which means I can view on any device). I also love the other things like Preview, LanScan, Music, Apple TV, Quicktime and of course, control over my Home (this isn't a huge problem as I use Home Assistant anyway). I weighed up the advantages and disadvantages and the only major advantage the switch brings to me is that the parts in the computer are replaceable.
Let's be clear though, my new laptop isn't designed to solely replace my MacBook Pro, it's purpose is to get rid of the desktop computer that I have and make the whole work and play more streamlined. That means the chances are my MacBook will still remain a major part of my daily life whilst my new laptop will remain as my work machine and gaming machine (through the eGPU). I do not want a repeat of the disaster that was my Razer Blade Stealth where it basically sat and did nothing for three years despite me dropping £1500 on it. I am, for the foreseeable future, intending to keep my desktop PC as I wish to look at using it as a storage server (as it has a whopping 9 drive bays in it). Plus, the desktop was only upgraded last in July of 2019 with a £150 PSU (which is another amazing Corsair 850W PSU).
I finally decided to jump away from big towering desktop computers to a more reasonable laptop-based eGPU setup.
In the next few months, I will begin dismantling my desktop setup which I have had since January 2019. The desktop I currently have has parts that have survived 5 generations of desktop PCs, and some parts in it are as old as 2007. The PSU in it replaced my 10-year-old Corsair HX850 which lasted exactly ten years from when I built my first PC in 2009. It marked the point when I was considering ditching the desktop PC altogether and going down the USB-C-based laptop route which I tried with my Razer Blade Stealth until the screen started to fail.
I have been torn between two laptops that both comply with my environmental concerns and my Right-To-Repair belief. They are the Framework laptop and the HP EliteBook 845 G9. I have mixed feelings about both, but I am more swayed towards the Ryzen processor than an Intel that offers little performance improvements over my brother's Skylake-based computer.
Over the last few days, my work has been focused on finishing off the BalfVote website.
For those who haven't been keeping an eye on my blog, BalfVote is now available to use freely at balf.vote. The new system allows you to create simple polls that users can access from their devices. It's part of my WISP project and the actual interface that was developed as part of my website has no actual styling. This is why I use this in my presentations - it fits with the theme.
It's still in very early beta stages but the whole interface from the graphs and the questions works 100% - it's just the creator that still needs work.
In the November 2022 release of ZPE, sockets will be available through the new Socket object! This has been a long-requested feature that was first proposed but scrapped when ZPE became object-oriented. Further to that ZPE 1.10.11 is bringing back the UI object due to issues within the plugin version.
ZPE 1.10.10 already brings the new MQTT object which will soon feature subscription as well as publishing (probably in December). The new MQTT object is actually really awesome and it allows me to automate my house even further than before with ZPE. As always, the core principle behind ZPE is to make features like MQTT more accessible and easier to use, and the socket is no different. Instead of requiring 20 lines of code, ZPE's socket implementation requires just two lines of code.
ZPE 1.10.10 is considerably larger at 1.2MB instead of 960KB as it would have been if not for MQTT. It's still reasonably small, but expect ZPE to get bigger as new features like MQTT get added.
ZPE 1.10.10 will be released today at some point, and the headline feature is MQTT support.
In case you didn't know, MQTT is built upon the TCP/IP stack and is intended for direct communication in the form of a publish and subscribe system. ZPE now has the ability to publish (not subscribe yet) messages to an endpoint and is fairly straightforward to use (unlike the underlying implementation).
To use MQTT in ZPE, one uses the MQTT object which encapsulates several built-in functions (connect and publish). More will be published after the release today on using MQTT.
You could write the following code (assuming you have cached values already setup):
$topic = "comms" $message = "Hello world!" $mqtt = new MQTT() $mqtt->connect("192.168.1.2", 1883, read_cache_value("MQTT_USER"), read_cache_value("MQTT_PASS")) $mqtt->publish($topic, $message)
Tonight I managed to recover my home server after it encountered a fsck issue. I'm going to say, when I had this issue I shouted the word it resembles. However, it was easy to recover from, since I DD my machine every day onto a separate location. The problem is, that downloading the image, for backup purposes, took forever. This is because the image is 40GB.
My network is a mix of gigabit and 2.5 gigabit Ethernet and with my new gaming PC will be even more 2.5 gigabit. This causes slow downs for example when transferring from the home server to my MacBook (the server is only gigabit).
However, over the next few months, I will begin the transition to 10 gigabit Ethernet across the house for certain things like my PCs. I will be documenting this as I go along with it so follow my blog to find out more!
ZPE's codenames have been a continuing tradition, and since I announced version 1.10.x codenames I have been following a once a month release cycle, the same will happen with ZPE 1.11.x.
However, there will be a change. Instead of just being given a codename, each version will ditch the version number from the name and will instead use the codenames as the version. The version numbers will still increment, but will not be as prominent as the names. The names are yet to be decided but the first version, aka ZPE 1.11.x will be called ZPE Omega. ZPE will also keep codenames between versions in the future, so ZPE 1.11.1 may share a codename with ZPE 1.11.2 and so on.
The headline feature of ZPE 1.10.10, known as Lusty Lion, will be MQTT support. As an MQTT user myself, having MQTT support in ZPE will be a welcome addition. ZPE 1.10.10 will also reintroduce the MySQL features to ZPE.
ZPE 1.10.10 will also introduce minor performance improvements and will be the second version that will be available in native images as well as a JAR.
I really wanted to simply outline what I thought of the latest Nintendo Direct, which blew my mind.
There were three staple elements that made this Nintendo Direct so amazing. Those three announcements were:
- The Nintendo 64 games - I was over the moon to see a good old classic, Pokemon Stadium, is coming to the Nintendo Switch, and I was just as over the moon with the announcement of Pokemon Stadium 2, but I was even more over the moon with the announcement that Goldeneye was coming to the Switch also.
- Pikmin 4 - I've enjoyed Pikmin since 2002 when the first version came out - heck that feels a long time ago as I was still in primary school! Pikmin 3 was one of my favourite games of all time - it was just an awesome culmination of a strategy game that works so well with a controller.
- Legend of Zelda - I've always loved Zelda since OoT was one of the first games I owned. I cannot wait for another Zelda game. Enough said.
Let's be clear from the start, it was obvious that the native build of ZPE was going to have better performance, but I wasn't entirely sure of how much better the performance was going to be until I compiled the latest version and tested it.
The native version is considerable faster when it processed loops. Here is an example of a 100,000 iteration loop running on the Java version first, then the native version. Both are running on an M1 Mac with the native version compiled for aarch64.
And with the ZPE Standard Library the comparison is made even clearer:
Whilst ZPE native is faster than the JRE ZPE, it's important to know that its feature set is not complete. I am working on improving this and the native binaries may become the future of ZPE, but at present, they have bugs (for example the sound features do not work).
Performance is now gaining on that of PHP with loops in particular.
