We spent a lot of time spotting old hardware in it. An Atari VCS is a major part of the plot, but we also saw a ColecoVision, though both were simulated. There were a number of old arcade cabinets, notably a Pinball 2000 Revenge From Mars. In the Macintosh world, a possibly anachronistic Macintosh LC series machine (we couldn't determine the model) turns up along with an unknown early PC which sort of resembles a Tandy 1000 of some kind. However, the real oddball was what I'm pretty sure was a Commodore 1570 disk drive. These are rather unusual and it wouldn't make sense for one to be in the United States around that time period. Watch for it in Halliday's bedroom with the unknown LC near the end of the film.
Friday, March 30, 2018
Stuff spotted in Ready Player One
Saturday, March 24, 2018
TenFourFox FPR7b1 and TenFourFoxBox 1.1 available
In this version, the hidden basic adblock feature introduced in FPR6 is now exposed in the TenFourFox preference pane:
It does not default to on, and won't ever do so, but it will reflect the state of what you set it to if you played around with it in FPR6. Logging, however, is not exposed in the UI. If you want that off (though it now defaults to off), you will still need to go into about:config and change tenfourfox.adblock.logging.enabled to false. The blocklist includes several more cryptominers, adblockerblockers and tracking scripts, and there are a couple more I am currently investigating which will either make FPR7 final or FPR8.
The other big change is some retuning to garbage and cycle collection intervals which should reduce the browser's choppiness and make GC pauses less frequent, more productive and more deterministic. I did a number of stress tests to make sure this would not bloat the browser or make it run out of memory, and I am fairly confident the parameters I settled on strike a good balance between performance and parsimoniousness. Along with these updates are some additional DOM and CSS features under the hood, additional HTTPS cipher support (fixing Amtrak in particular, among others) and some sundry performance boosts and microoptimizations. The user agent strings are also updated for Firefox 60 and current versions of iOS and Android.
To go along with this is an update to TenFourFoxBox which allows basic adblock to be enabled for foxboxes and updates the cloaked user agent string to Firefox 60. There is a new demo foxbox for 2048, just for fun, and updated Gmail and user guide foxboxes. TenFourFoxBox 1.1 will go live simultaneously with FPR7 final on or about May 9.
Meanwhile, the POWER9-based Talos II showed up in public; here's a nice picture of it at the OpenPOWER Summit running Unreal Engine with engineer Tim Pearson. I'm not in love with the case, but that's easily corrected. :) Word on the street is April for general availability. You'll hear about it here first.
Thursday, March 15, 2018
TenFourFox FPR6 SPR1 coming
The bug in question would require a TenFourFox-specific exploit to be useful, but is definitely exploitable, and fortunately was easily repaired. The G5 will chug overnight and have builds tomorrow and heat the rear of the house all at the same time.
Saturday, March 10, 2018
TenFourFox FPR6 available
The backend for the main download page at Floodgap has been altered such that the Downloader is now only offered to browsers that do not support TLS 1.2 (this is detected by checking for a particular JavaScript math function Math.hypot, the presence of which I discovered roughly correlates with TLS 1.2 support in Google Chrome, Microsoft Edge, Safari and Firefox/TenFourFox). This is to save bandwidth on our main server since those browsers are perfectly capable of downloading directly from SourceForge and don't need the Downloader to help them. This is also true of Leopard WebKit, assuming the Security framework update is also installed.
For FPR7, I have already exposed basic adblock in the TenFourFox preferences pane, and am looking at some efficiency updates as well as updates to the supported TLS ciphers and hopefully date pickers if there is still time. Also, the limited profiling tools I have at my disposal suggest that some of the browser's occasional choppiness is at least partially associated with improperly scheduled garbage collection slices. I'm experimenting with retuning the runtime environment to see if we can stave off some types of collection to preserve CPU cycles and not bloat peak memory usage too much. So far, 24 hours into testing with some guesswork numbers, it doesn't seem to be exploding. More on that later.
Saturday, March 3, 2018
And now for something completely different: Make that Power Mac into a radio station (plus: the radioSHARK tank and AltiVec + LAME = awesome)
Also, the TenFourFox Downloader is now live. After only a few days up with no other promotion, it's pulling down about 200 downloads a day. I note that some small number are current TenFourFox users, which isn't really what this is intended for: the Downloader is unavoidably -- and in this case, also unnecessarily -- less secure, and just consumes bandwidth on Floodgap downloading a tool to download something the browser can just download directly. If you're using TenFourFox already (at least 38 or later), please just download upgrades with the browser itself. In addition, some are Intel Mac users on 10.6 and earlier, which the Downloader intentionally won't grab for because we don't support them. Nevertheless, the Downloader is clearly accomplishing its goal, which is important given that many websites won't be accessible to Power Mac users anymore without it, so it will be a permanent addition to the site.
Anyway, let's talk about Power Macs and radios. I'm always fond of giving my beloved old Macs new things to do, so here's something you can think about for that little G4 Mac mini you tossed in the closet. Our 2,400 square foot house has a rather curious floor plan: it's a typical California single-floor ranch but configured as a highly elongated L-shape along the bottom and right legs of the property's quadrilateral. If I set something playing somewhere in the back of the house you probably won't hear it very well even just a couple rooms away. The usual solution is to buy something like a Sonos, which are convenient and easy to operate, but streaming devices like that can have synchronization issues and they are definitely not cheap.
But there's another solution: set up a house FM transmitter. With a little spare time and the cost of the transmitter (mine cost $125), you can devise a scheme that turns any FM radio inside your house into a remote speaker with decent audio quality. Larger and better engineered than those cheapo little FM transmitters you might use in a car, the additional power allows the signal to travel through walls and with careful calibration can cover even a relatively large property. Best of all, adding additional drops is just the cost of another radio (instead of an expensive dedicated receiver), and because it's broadcast everything is in perfect sync. If your phone has an FM radio you can even listen to your home transmitter on that!
There are some downsides to this approach, of course. One minor downside is because it's broadcast, your neighbours could tune in (don't play your potentially embarrassing, uh, "home movie" audio soundtracks this way). Another minor downside is that the audio quality is decent but not perfect. The transmitter is in your house, so interference is likely to be less, but things as simple as intermittently energized electrical circuits, bad antenna positioning, etc., can all make reception sometimes maddeningly unpredictable. If you're an uncompromising audiophile, or you need more than two-channel audio, you're just going to have to get a dedicated streaming system.
The big one, though, is that you are now transmitting on a legally regulated audio band without a license. The US Federal Communications Commission has provisions under Part 15 for unlicensed AM/FM transmission which limit your signal to an effective distance of just 200 feet. There are more specific regulations about radiated signal strength, but the rule of thumb I use is that if you can detect a usable signal at your property line you are probably already in violation (and you can bet I took a lot of samples when I was setting this up). The FCC doesn't generally drive around residential neighbourhoods with a radio detector van and no one's going to track down a signal no one but you can hear, but if your signal leaks off your property it only takes one neighbourhood busybody with a scanner and nothing better to do to complain and initiate an investigation. Worse, if you transmit on the same frequency as an actually licensed local station and meaningfully interfere with their signal, and they detect it (and if it's meaningful interference, I guarantee you they will sooner or later), you're in serious trouble. The higher the rated wattage for your transmitter, the greater the risk you run of getting busted, especially if you are in a densely populated area. If you ever get a notice of violation, take it seriously, take your transmitter completely offline immediately, and make sure you tell the FCC in writing you turned it off. Don't turn it back on again until you're sure you're in compliance or you may be looking at a fine of up to $75,000. If you're not in the United States, you'd better know what the law is there too.
So let's assume you're confident you're in (or can be in) compliance with your new transmitter, which you can be easily with some reasonable precautions I'll discuss in a moment. You could just plug the transmitter into a dedicated playback device, and some people do just that, but by connecting the transmitter to a handy computer you can do so many other useful things. So I plugged it into my Sawtooth G4 file server, which lives approximately in the middle of the house in the dedicated home server room:
There it is, the slim black box with the whip antenna coming off the top sandwiched between the FireWire hub (a very, very useful device and much more reliable than multiple FireWire controllers) and the plastic strut the power strip is mounted on. This is the Whole House FM Transmitter 3.0 "WHFT3" which can be powered off USB or batteries (portable!), has mic and line-level inputs (though in this application only line input is connected), includes both rubber duck and whip antennas (a note about this presently) and retails for about $125. Amazon carries it too (I don't get a piece of any sales, I'm just a satisfied customer). It can crank up to around 300 milliwatts, which may not seem like much to the uninitiated, but easily covers the 100 foot range of my house and is less likely to be picked up by nosy listeners than some of the multi-watt Chinese import RF blowtorches they sell on eBay (for a point of comparison, a typical ham mobile radio emits around 5 watts). It also has relatively little leakage, meaning it is unlikely to be a source of detectable RF interference when properly tuned.
By doing it this way, the G4, which is ordinarily just acting as an FTP and AFP server, now plays music from playlists and the audio is broadcast over the FM transmitter. How you decide to do this is where the little bit of work comes in, but I can well imagine just having MacAmp Lite X or Audion running on it and you can change what's playing over Screen Sharing or VNC. In my case, I wrote up a daemon to manage playlists and a command-line client to manipulate it. 10.5+ offers a built-in tool called afplay to play audio files from the command line, or you can use this command line playback tool for 10.2 through 10.4. The radio daemon uses this tool (the G4 server runs Tiger) to play each file in the selected folder in order. I'll leave writing such a thing to the reader since my radio daemon has some dependencies on the way my network is configured, but it's not very complex to devise in general.
Either way works fine, but you also need to make sure that the device has appropriate signal strength and input levels. The WHFT3 allows you to independently adjust how much strength it transmits with a simple control on the side; you can also adjust the relative levels for the mic and line input if you are using both. (There is a sorta secret high-level transmission mode you can enable which I strongly recommend you do not: you will almost certainly be out of FCC compliance if you do. Mine didn't need this.) You should set this only as high as necessary to get good reception where you need it, which brings us to making sure the input level is also correct, as the WHFT3 is somewhat more prone to a phenomenon called over-modulation than some other devices. This occurs when the input level is too high and manifests as distortion or clipping but only when audio is actually playing.
To calibrate my system, I first started with a silent signal. Since the frequency I chose had no receivable FM station in my region of greater Los Angeles (and believe me, finding a clear spot on the FM dial is tough in the Los Angeles area), I knew that I would only hear static on that frequency. I turned on the transmitter with no input using the "default" rubber duck antenna and went around the house with an FM radio with its antenna fully retracted. When I heard static instead of nothing, I knew I was exceeding the transmission range, which gave me an approximate "worst case" distance for inside the house. I then walked around the property line with the FM radio and its antenna fully extended this time for a "within compliance" test. I only picked up static outside the house, but inside I couldn't get enough range in the kitchen even with the transmitter cranked up all the way, so I ended up switching the rubber duck antenna for the included whip antenna. The whip is not the FCC-approved configuration (you are warned), but got me the additional extra range, and I was able to back down the transmitter strength and still be "neighbour proof" at the property line. This is also important for audio quality since if you have the transmitter power all the way up the WHFT3 tends to introduce additional distortion no matter what your input level is.
Next was to figure out the appropriate input level. I blasted Bucko and Champs Australian Christmas music and backed down the system volume on the G4 until there was no distortion for the entire album (insert your own choice of high volume audio here such as Spice Girls or Anthrax), and checked the new level a few times with a couple other albums until I was satisfied that distortion and overmodulation was at a minimum. Interestingly, while you can AppleScript setting the volume in future, what you get from osascript -e 'set ovol to output volume of (get volume settings)' is in different units than what you feed to osascript -e 'set volume X': the first returns a number from 0-100 with 14 unit steps, but the second expects a number from 1-10 in 0.1 unit steps. The volume on my G4 is reported by AppleScript as "56" but I set that on startup in a launchd startup item with a volume value of 4.0 (i.e., 4 times 14 equals 56). Don't ask me why Apple did it this way.
There were two things left to do. First was to build up a sufficient library of music to play from the file server, which (you may find this hard to believe) really is just a file server and handles things like backups and staging folders, not a media server. There are many tools like the most excellent X Lossless Decoder utility -- still Tiger and PowerPC compatible! -- which will rip your CDs into any format you like. I decided on MP3 since the audio didn't need to be lossless and they were smaller, but most of the discs I cared about were already ripped in lossless format on the G5, so it was more a matter of transcoding them quickly. The author of XLD makes the AltiVec-accelerated LAME encoder he uses available separately, but this didn't work right on 10.4, so I took his patches against LAME 3.100, tweaked them further, restored G3 and 10.4 compatibility, and generated a three-headed binary that selects for G3, G4 and a special optimized version for G5. You can download LAMEVMX here, or get the source code from Github.
On the G5 LAMEVMX just tears through music at around 25x to as much as 30x playback speed, over three times as fast as the non-SIMD version. I stuck the MP3 files on a USB drive and plugged that in the Sawtooth so I didn't have to take up space on its main RAID, and the radio daemon iterates off that.
The second was figuring out some way to use my radios as, well, radios. Yes, you could just tune them to another station and then tune them back, but I was lazy, and when you get an analogue tuner set at that perfect point you really don't want to have to do it again over and over. Moreover, I usually listen to AM radio, not FM. One option is to see if they stream over the Internet, which may even be better quality, though receiving them over the radio eliminates having to have a compatible client and any irregularities with your network. With a little help from an unusual USB device, you can do that too:
This is the Griffin radioSHARK, which is nothing less than a terrestrial radio receiver bolted onto a USB HID. It receives AM and FM and transmits back to the Mac over USB audio or analogue line-level out. How do we hook this up to our Mac radio station? One option is to just connect its audio output directly, but you should have already guessed I'd rather use the digital output over USB. While you can use Griffin's software to tune the radio and play it through (which is even AppleScript-able, at least version 2), it's PowerPC-only and won't run on 10.7+ if you're using an old Intel Mac for this purpose, and I always prefer to do this kind of thing programmatically anyhow.
For the tuner side, enterprising people on the Linux side eventually figured out how to talk to the HID directly and thus tune the radio manually (there are two different protocols for the two versions of the radioSHARK; more on this in a moment). I combined both protocols together and merged it with an earlier but more limited OS X utility, and the result is radioSH, a commandline radio tuner. (You can also set the radioSHARK's fun blue and red LEDs with this tool and use it as a cheapo annunciator device. Read the radioSH page for more on that.) I compiled it for PowerPC and 32-bit Intel, and the binary runs on anything from 10.4 to 10.13 until Apple cuts off 32-bit binary compatibility. The source code is available too.
For USB audio playthru, any USB audio utility will suffice, such as LineIn (free, PowerPC compatible) or SoundSource (not free, not PowerPC compatible), or even QuickTime Player with a New Audio Recording and the radioSHARK's USB audio output as source. Again, I prefer to do this under automatic control, so I wrote a utility using the MTCoreAudio framework to do the playback in the background. (Use this source file and tweak appropriately for your radioSHARK's USB audio endpoint UID.) At this point, getting the G4 radio station to play the radio was as simple as adding code to the radio daemon to tune the radio with radioSH and play the USB audio stream through the main audio output using that background tool when a playlist wasn't active (and to turn off the background streamer when a playlist was running). Fortunately, USB playthru uses very little CPU even on this 450MHz machine.
I mentioned there are two versions of the radioSHARK, white (v1) and black (v2), which have nearly completely different hardware (belied by their completely different HID protocols). The black radioSHARK is very uncommon. I've seen some reports that there are v1 white units with v2 black internals, but of the three white radioSHARKs I own, all of them are detected as v1 devices. This makes a difference because while neither unit tunes AM stations particularly well, the v1 seems to have poorer AM reception and more distortion, and the v2 is less prone to carrier hum. To get the AM stations I listen to more reliably with better quality, I managed to track down a black radioSHARK and stuck it in the attic:
To improve AM reception really all you can do is rotate or reposition the receiver and the attic seemed to get these stations best. A 12-foot USB extension cable routes back to the G4 radio station. The radioSHARK is USB-powered, so that's the only connection I had to run.
To receive the radio on the Quad G5 while I'm working, I connected one of the white radioSHARKs (since it's receiving FM, there wasn't much advantage to trying to find another black unit). I tune it on startup with radioSH to the G4 and listen with LineIn. Note that because it's receiving the radio signal over USB there is a tiny delay and the audio is just a hair out of sync with the "live" analogue radios in the house. If you're mostly an Intel Mac house, you can of course do the same thing with the same device in the same way (on my MacBook Air, I use radioSH to tune and play the audio in QuickTime Player).
For a little silliness I added a "call sign" cron job that uses /usr/bin/say to speak a "station ID" every hour on the hour. The system just mixes it over the radio daemon's audio output, so no other code changes were necessary. There you go, your very own automatic G4 radio station in your very own house. Another great use for your trusty old Power Mac!
Oh, one more followup, this time on Because I Got High Sierra. My mother's Mac mini, originally running Mavericks, somehow got upgraded to High Sierra without her realizing it. The immediate effect was to make Microsoft Word 2011 crash on startup (I migrated her to LibreOffice), but the delayed effect was, on the next reboot (for the point update to 10.13.2), this alarming screen:
The system wouldn't boot! On every startup it would complain that "macOS could not be installed on your computer" and "The path /System/Installation/Packages/OSInstall.mpkg appears to be missing or damaged." Clicking Restart just caused the same message to appear.
After some cussing and checking that the drive was okay in the Recovery partition, the solution was to start in Safe Mode, go to the App Store and force another system update. After about 40 minutes of chugging away, the system grudgingly came up after everything was (apparently) refreshed. Although some people with this error message reported that they could copy the OSInstall.mpkg file from some other partition on their drive, I couldn't find such a file even in the Recovery partition or anywhere else. I suspect the difference is that these people encountered this error immediately after "upgrading" to Because I Got High Sierra, while my mother's computer encountered this after a subsequent update. This problem does not appear to be rare. It doesn't seem to have been due to insufficient disk space or a hardware failure and I can't find anything that she did wrong (other than allowing High Sierra to install in the first place). What would she have done if I hadn't been visiting that weekend, I wonder? On top of all the other stupid stuff in High Sierra, why do I continue to waste my time with this idiocy?
Does Apple even give a damn anymore?