Why does an Apple watch need a passcode to operate and unlock, when you can not type an alphanumeric passcode on the device itself?

For anyone who has their iphone tied to Enterprise Management, you lose control of the watch, and if you ever see that dreaded "Enter passcode" to proceed dialog, then you have to factory reset the device.

I like the Apple Watch (series 5) - it has a "weight" to it that makes it feel like a valued possession. But, shame on the battery life and zero applications to install on it.

Been looking at these devices. Long ago, I purchased an Intel NUC (cant even remember the model number). The device from way-back was a "better raspberry pi" than a raspberry pi - small & cute. I had to give up on it after a bit, because the firmware was rotten and it kept resetting itself. This is the problem of being a first-mover.

Fast forward a number of years, and the new Intel NUC 10's look very attractive - up to 8 cores/16 threads, and with SSD support via SATA or NVMe - I could put lots of TB of storage into one device.

But the devices are expensive - you are paying for the (nice) case and embedded CPU. (You can purchase your own DRAM and SSD from wherever you prefer).

https://simplynuc.co.uk/ is but one place to search and configure devices. The devices are confusing because the ideal machine is the full height machine which has room for an extra SATA device. And the model numbers are equally confusing.

Now that AMD has entered the scene with the wonderful Ryzen CPU family, and the newest Renoir Ryzen 7 4800U device Asus PN50 Mini PC with 8 cores and 16 threads, we are finally able to see how much price gouging Intel has done, over the years.

Intel have drip fed the market with CPUs and minor upgrades, and kept a constant max of 4 cores / 8 threads, for the laptop and low powered devices. AMD have made them rethink their strategy, so this competition can truly help.

Havent written a post in a while, and time to resurface.

Havent done a blog in a long time, and it seems that as time has moved on, and Viruses have moved from the computer to the humans in the world....lets just move on.

During the lockdown, I have been meaning to catch up and get some things done. This includes some CRiSP bug fixes and updates.

I have an early Raspberry Pi (model 1) used to serve up web content. It has been good for a few years now - but underpowered, and severely lacking in RAM and Disk. I purchased a Raspberry Pi 3 about 18 months ago, and it just sat in the drawer, waiting a rainy day project.

Ok, so locked up at home, its a rainy day. (Actually it is sunny today, but who knows what it will be like tomorrow).

I had purchased various Amazon Echo device over the last few years. In general, they have been a game changer to merge audio and visual, with cheap/affordable devices. The never ending array of releases is mind-boggling, and now I am being left with piles of devices with nowhere else to plug them in. I can't say I like Alexa - whilst it is a novelty, the too many times it responds to nothing in particular, and its lack of "AI" is annoying. And I miss being able to watch YouTube videos on the "Show" devices.

I had bought two Echo 3rd gen devices, with a view to using them in stereo mode. The sound is good enough, but the lack of ability to play proper stereo over bluetooth has been annoying. So much so, that I stopped using them and purchased an Ultimate Ears device - which is portable and battery powered. (UE Megaboom 3). Great device.

But the two unused Amazon Echo's sit there, and leer at me, as if to say "get off your back side!".

So, lets use the RPI has a hifi device - certainly a zillion web sites and utilities. So I set it up. (Had to take a detour to buy an assortment of audio cables and splitters). Setting up the RPI is really, really simple.

Deciding on audio player was much, much harder. With so many tools out there. Whilst the world had moved on since I last looked, we now have the wonderful "mpd" music-player daemon. So, the act of playing is separated out from the tools and UI's which you can interface with. So many attractive looking players, and many are web based. (My RPI is headless, so web is best). I had to resort to ssh and CLI for a few days til I got everything set up.

I tried "mopidy" - it looks really attractive, and I banged my head against this tool, and, alas, simply couldnt get it to work. I almost got it to work, but it has expectations to run as UID "mopidy" and after doing far too much system fiddling to get the library in the right place, I gave up. It managed to crash the RPI when doing a scan of my audio library.

I started looking at other alternatives - many come as images to be put on an sd-card. I am frowning at the way the world has gone from an installable tarball to docker images or total OS replacements. I see no advantage to this, unless I wanted to dedicate a Pi to a specific piece of software. So, I started looking around.

ympd - http://www.ympd.org

I was sort of impressed by this solitary tool to offer a web browser and player in one. Alas, its a bit lacking in utility, but a great start. It showed me what could be done. Its interface seemed a bit laggy, and it didnt seem to offer proper playlists.

volumio - http://volumio.org

This looked a lot more to my taste, but a 300 MB Zip/Image file meant it was not going to be easy to try it out, so I rapidly abandoned that.

RompR - https://fatg3erman.github.io/RompR/

I saw this one - the screen shots looked beautiful. And was concerned whether to try this or not. I even toyed with writing my own music client and web interface - my needs are not much. But I perservered.

Look - this software just "works". The documentation is flawless to setting up. I had severe reservations about it leveraging PHP, but the install instructions lead you through the packages you need and the config files. Super.

So lets run it. Wham! Wow! This is more than brilliant. It has so much functionality - far more than I need; it has skinnable themes. And it talks to the internet. My poorly arranged/indexed mp3 library was suddenly awash with artist details and links for more info. So much to play with. And the UI is available on every mobile/browser in the house - it caters to the mobile or desktop format.

I cant reiterate how much "wow" this software is and the thought process having gone into it.

Maybe I will put up some screen shots.

Not sure whether to laugh or cry. Ubuntu 16.04 is now the latest release. I grabbed a server ISO and decided to install - so I could do some dtrace fixes for the Linux 4.4 kernel.

I go through a routine of a base install, get my .profile/.bashrc, bin/ and various other things to make the VM my "home".

First thing is to create my login id as part of the install. Alas, over the years, my UID has been set out of bounds during an install. To make life easier, I ensure I have the same UID across all systems - despite it not really being relevant. But it helps.

First thing: sudo to root, vi /etc/passwd and change my UID to the preferred one. Then "chown -R fox ." on my home dir, logout, and login again. All is ready.

Alas, sudo has a naughty bug in it. Since I have my UID==GID, I also need to edit /etc/group.

Guess what I forgot to do? Yes. Forgot to edit /etc/group.

So now what? Well, "sudo" nicely core dumps on you when your group doesnt match. WTF?! Its 2016 !

Oh dear, am locked out of becoming root with out a reinstall.......

Ok, so lets boot to single user mode, vi /etc/group, and carry on.

Whew! All is resolved.

Been adding a native python interface to CRiSP, and needed to run valgrind on my code. Alas, Python itself seems to be polluted with many undefined memory read scenarios (this is python2.7). A simple python script, when run under valgrind gives rise to errors like:

==17795== Invalid read of size 4
==17795==    at 0x4A30B1: ??? (in /usr/bin/python2.7)
==17795==    by 0x4E05A5: ??? (in /usr/bin/python2.7)
==17795==    by 0x4C5BB1: ??? (in /usr/bin/python2.7)
==17795==    by 0x4B422E: ??? (in /usr/bin/python2.7)
==17795==    by 0x4B3DFA: ??? (in /usr/bin/python2.7)
==17795==    by 0x4B3642: ??? (in /usr/bin/python2.7)
==17795==    by 0x4B6755: ??? (in /usr/bin/python2.7)
==17795==    by 0x4D437A: PyEval_CallObjectWithKeywords (in /usr/bin/python2.7)
==17795==    by 0x4CF3B0: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==17795==    by 0x4CB6B0: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==17795==    by 0x4CAF55: PyEval_EvalCode (in /usr/bin/python2.7)
==17795==    by 0x4C97BB: PyImport_ExecCodeModuleEx (in /usr/bin/python2.7)     ==17795==  Address 0x6046020 is 34,480 bytes inside a block of size 36,521 free'd
==17795==    at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17795==    by 0x4C6033: PyMarshal_ReadLastObjectFromFile (in /usr/bin/python2.7)
==17795==    by 0x4C5F6D: ??? (in /usr/bin/python2.7)
==17795==    by 0x4C5B4B: ??? (in /usr/bin/python2.7)
==17795==    by 0x4B422E: ??? (in /usr/bin/python2.7)
==17795==    by 0x4B3DFA: ??? (in /usr/bin/python2.7)
==17795==    by 0x4B3642: ??? (in /usr/bin/python2.7)
==17795==    by 0x4B6755: ??? (in /usr/bin/python2.7)
==17795==    by 0x4D437A: PyEval_CallObjectWithKeywords (in /usr/bin/python2.7)
==17795==    by 0x4CF3B0: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==17795==    by 0x4CB6B0: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==17795==    by 0x4CAF55: PyEval_EvalCode (in /usr/bin/python2.7)

I havent looked at the python internals to see what and how dangerous this is.

Alas, my Intel NUC decided to die. Our electric meter needed replacing and after a power on - it wouldnt boot. It was suffering amnesia again and refused to find the boot record on the HD. Shame, because I really liked the machine, but wasnt going to play around to see if the boot record had been corrupt or fiddle around with yet another BIOS update. Shame on Intel for releasing the Celeron NUC and letting it be a poor player.

So, lets look for another machine. Intel-on-a-stick. Thats more like it. But the price is excessive, and Intel lost my trust.

Off to a Raspberry Pi2. Having played with the first RaspberryPi and being let down by the very bad power supply sensitive issues, I thought I would try again. I must say, so far, am enjoying it. The NOOB SD card just works - so much better than any other Linux - it installed flawlessly (despite the confusing initial boot/install screen), and TCP worked on the ethernet.

So, the rss feed (http://www.crispeditor.co.uk:3000) is back up and I just need to copy the crisp website and releases over (as soon as the 128GB USB drive arrives), and should be back in business.

The Pi2 is impressive - 4 core 1GHz ARM processor, but a nuisance as I need to recompile a few binaries over to ARM. At least I can create a new CRiSP release for Pi, and revalidate the ARM dtrace port.

Stay tuned for the crispeditor web site to resurface.

For now the RSS feed supply is a bit dry and empty, but should be a full page of news within 12-24h.

Pushed out a new dtrace release; this includes domain name changes and one cosmetic compiler fix for some systems. It wont fix/enhance most peoples issues, but gives me a decent baseline to compare against.

The new website www.crispeditor.co.uk is live, and its interesting to watch who is accessing it. Right now, there are two main attempts at cracking it - one is a WordPress vulnerability and the other, is a PHP one. I guess the bots are hungry for food.

Also, it is interesting how quickly both Google and Bing start their bot machines. That is encouraging. Very soon, I will be the most popular website in the solar system - just keep clicking and we might make it into the Interweb Hall of Fame.

The domain transfer and contents transfer is complete - the links on the website can now be used to download copies of CRiSP, DTrace and other tools. I will need to tidy up some of the very old contents.

Please mail me at crispeditor at gmail.com if you see any issues.

The new replacement and home for the very old Demon website, where you can download copies of CRiSP is nearly ready. You can visit the website at

http://www.crispeditor.co.uk

and you will find content and download links, but the links will be a bit stale as I copy things around. Hope to have this at parity in the next day or so.

You may not be able to actually download anything, but thats high on the list to fix.

I joined Demon Internet back in 1992 - the first service provider in the UK, and home for CRiSP (www.crisp.demon.co.uk) for the last 23y.

Despite various ownership changes of the company, it seems that the FTP service is no longer functioning and I will finally retire my Demon account this year.

For those of you looking to find CRiSP, you will find that eventually that website will vanish, and I will replace with another site - once I have decided on the best options.

My gmail accounts will continue to work, but my demon email address will stop working at some point.

This is just a heads up.

I hope I am wrong and the FTP service recovers, but it seems like Demon are transferring the hosting services to another provider, and nobody at Demon understands the product they own, so it appears.

Everything was looking promising to release a new dtrace sometime last week. It was working on the 3.16 kernel, 3.8, 3.4 and then onto RH5.6 (2.6.18). I ran into a lot of issues on 2.6.18 - not surprising, given the code mutations. Much of the last 2 weeks was on the execve() system call. It would panic the kernel. Despite a lot of experiments and reading of the assembler and kernel code, I kept doing silly things. It really doesnt help that the 2.6.18 kernel will hard panic on a stray GPF - made it very difficult to figure out what was going on.

Eventually I got every line of assembler and issues with registers in C code to work.

Along the way I had an issue with the "old_rsp" symbol. This is not exposed in /proc/kallsyms, and not even in the /boot/System.map code. I had to write a tool to extract this from inside the kernel. But this ran into complications because /proc/kcore is broken on the RH/Centos kernels. I had to create a new device driver, which has to be loaded into the kernel prior to the build of dtrace ("/proc/dtrace_kmem"). Its a very simple driver only designed to handle the scenario of building dtrace.

Having got this work, then the next roadblock was the rt_sigreturn() syscall which paniced the kernel. Careful investigation showed a missing line of assembler (for the 2.6.18 kernel). Now that works.

Now everything is looking good on RH5/Centos5 but before going on the trawl of later kernels and proving I didnt break anything, I have an issue with x_call.c. Either I use the native smp_call_function() interface - which works great, until we panic the kernel, or I use my implementation, which doesnt seem to be broadcasting to the cpus - this means certain probes get "lost".

So, hopefully this week or next weekend - depending on the xcall issues.

Still delaying the dtrace release. Having gotten 3.16 kernels to work, I started working backwards on random 3.x kernels, to validate it still worked there. I fixed a number of issues there, and then headed into RedHat 5.6 / Centos 5.6 land (2.6.18+ kernel).

I spent some time trying to get execve() syscall tracing to work - and am still working on that.

Along my journey, I noticed a few things. Firstly dtrace4linux is too complicated - trying to support 32+64b kernels, along the entire path back to 2.6.18 or earlier, is painful. I cannot easily automate regression testing (not without a lot more hard-disk space, and not worthwhile whilst I am aware of obvious bugs to fix). I could simplify testing by picking any release, and just rebooting with different kernels - rather than full ISO images of RedHat/Centos/Ubuntu/Arch and so on.

I also noticed that the mechanism dtrace4linux uses to find addresses in the kernel is slightly overkill. It hooks into the kernel to find symbols which cannot be resolved at link time. The mechanism I have is pretty interesting - relying on a Perl script to locate the things it needs. I found a case where one of the items I need is not visible at all in user space - its solely in the kernel - part of the syscall interrupt code (the per-cpu area). Despite what latest kernels do, some older kernels *dont*. And catering for them is important. In one case I have had to go searching the interrupt code to find this value. I ended up writing a C program to run in user space, prior to the build, and really, it would have been better to generalise this so that everything we need is simply defined in a table compiled in to the code, rather than the /dev/fbt code to read from the input stream. This would ensure that a build compiles and works. Today, sometimes I debug issues with old kernels because a required symbol is missing and we end up dereferencing a null pointer (not a nice thing to do in the kernel).

One problem I had with the above, was that gdb on the older distro releases cannot be used to read kernel memory due to a bug in the kernel precluding reading from /proc/kcore. Fortunately, I include a script in the release which emits a vmlinux.o, complete with symbol table, from the distribution vmlinuz file.

I havent reverified the ARM port of dtrace, but thats something for a different rainy or snowy day.

The next release of dtrace is hopefully this weekend. Having resolved the issues I had previously, have been doing more testing - so far only really on the 3.16 kernel, and found that some of the syscalls were behaving badly due to reimplementation in the kernel. Hopefully when I have fixed the last two or three, then I can finish my merges and push out the latest release. I will do a cursory check on some of the older kernels - it is likely I have made a mistake somewhere and broken older kernels, but will be easier to fix having made some internal changes.

Note that no new functionality is in here - the issues with libdwarf remain - I may try again to solve that issue, and "dtrace -p" is still a long way off from being functional.

Given that 3.20 is now the current kernel, I may need to see if that works and pray that 3.17-3.20 didnt affect how dtrace works, or, if it does, the work to make it compile should be much less than the issues that 3.16 raised.

When gcc 0.x came out - it was so refreshing. A free C compiler. GCC evolved over the years, got slower and used more memory. I used to use gcc on a 4MB RAM system (no typo), and wished I had 5MB RAM. Today, memory is cheap, and a few GB to compile code is acceptable. (The worst I have seen is 30+GB to compile a C++ piece of code - not mine!)

One of the powerful features of gcc was that "gcc -g" and "gcc -O" were not exclusive. And gdb came about as a free debugger, complimenting gcc.

Over recent years, gdb has become closer to useless. It is a powerful and complex and featureful debugger. But I am fed up single stepping my code, and watching the line of execution bounce back and forth because the compiler emits strange debug info where we move back and forth over lines of code and declarations.

Today, in debugging fcterm - my attempt to place a breakpoint on a line of code, puts the breakpoint *miles* away from the place I am trying to intercept. This renders "gcc -g" close to useless, unless I turn off all optimisations, and pray the compiler isnt inlining code.

Shame on gcc. Maybe I should switch to clang/llvm.