Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 2 dagen 19 uur geleden

The Servo Blog: This Week In Servo 106

ma, 05/03/2018 - 01:30

Windows nightlies no longer crash on startup! Sorry about the long delay in reverting the change that originally triggered the crash.

In the last week, we merged 70 PRs in the Servo organization’s repositories.

Planning and Status

Our roadmap is available online, including the overall plans for 2018.

This week’s status updates are here.

Notable Additions
  • nox removed more ToCss implementations by deriving them.
  • paul added a URL prompt to allow navigating pages in nightly builds.
  • manish fixed a panic that appeared on Wikipedia due to the use of rowspan and colspan.
  • ajeffrey avoided a deadlock caused by IPC channels on certain pages.
  • gw adjusted the behaviour of clipped blend operations.
  • emilio improved the behaviour of iterating over CSS longhand properties in the style system.
  • manish implemented rowspan support for tables.
  • alexfjw improved the performance of some operations that check computed display values.
  • emilio made the style system respect conditionally-enabled CSS properties better.
New Contributors

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!

Categorieën: Mozilla-nl planet

Cameron Kaiser: And now for something completely different: Make that Power Mac into a radio station (plus: the radioSHARK tank and AltiVec + LAME = awesome)

zo, 04/03/2018 - 03:17
As I watch Law and Order reruns on my business trip, first, a couple followups. The big note is that it looks like Intel and some ARM cores aren't the only ones vulnerable to Meltdown; Raptor Computer Systems confirms that Meltdown affects at least POWER7 through POWER9 as well, and the Talos II has already been patched. It's not clear if this is true for POWER4 (which would include the G5) through POWER6 as these processor generations have substantial microarchitectural differences. However, it doesn't change anything for the G3 and 7400, since because they appear to be immune to Spectre-type attacks means they must also be immune to Meltdown. As a practical matter, though, unless you're running an iffy program locally there is no known JavaScript vector that successfully works to exploit Spectre (let alone Meltdown) on Power Macs, even on the 7450 and G5 which are known to be vulnerable to Spectre.

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?

Categorieën: Mozilla-nl planet

Chris AtLee: Taskcluster migration update, the sequel

za, 03/03/2018 - 13:26
Firefox, now 100% buildbot-free!

First, the good news - Developer Edition 60.0b1 will be the first release in nearly 10 years done without using buildbot. This is an amazing milestone, and I'm incredibly proud of everybody who has contributed to make this possible!

Long time, no update

How did we get here? It's been, uh, almost 6 months since I last posted an update about our migration to Taskcluster.

In my last update, I described our plans for the end of 2017...

We're on track to ship builds produced in Taskcluster as part of the 56.0 release scheduled for late September. After that the only Firefox builds being produced by buildbot will be for ESR52. Meanwhile, we've started tackling the remaining parts of release automation. We prioritized getting nightly and CI builds migrated to Taskcluster, however, there are still parts of the release process still implemented in Buildbot. We're aiming to have release automation completely migrated off of buildbot by the end of the year. We've already seen many benefits from migrating CI to Taskcluster, and migrating the release process will realize many of those same benefits. How'd we do?

We're past the end of 2017, so how are we doing?

Well, we successfully shipped 56.0 with builds produced in Taskcluster. Our big Firefox Quantum release (57.0), was also shipped with builds produced by Taskcluster.

(side note: 57 had the most complex update scenarios we've ever had to support for Firefox...a subject for another post!)

Release scheduling

Post-56.0, our release process was using Taskcluster exclusively for producing the initial builds, and all the release process scheduling. We were still using Buildbot for many of the post-build tasks, like l10n repacks, publishing updates, pushing files to S3, etc. Once again we relied on the buildbot bridge to allow us to integrate existing buildbot components with the newer taskcluster pipeline. I learned from Kim Moir that this is a great example of the strangler pattern.

In the fall of 2017, we decided to begin migrating all of the scheduling logic for release automation into taskcluster using the in-tree taskgraph scheduling system. We did this for a few reasons...

  1. Having the release scheduling logic ride the trains is much more maintainable. Previous to this we had an externally defined release pipeline in our releasetasks repo. It was hard to keep this repository in sync with changes required for beta/release and ESR branches.

  2. More importantly, having the release scheduling logic in-tree meant that we could then rely on chain-of-trust to verify artifacts produced by the release pipeline.

  3. We felt that having the complete release pipeline defined in taskcluster would make it easier for us to tackle the remaining buildbot bridge tasks in parallel.

We hit this milestone in the 58 cycle. Starting with 58.0b3, Firefox and Fennec releases were completely scheduled using the in-tree taskgraph generation. We also migrated over the l10n repacks at the same time, removing a longstanding source of problems where repacks would fail when we first got to beta due to environmental differences between taskcluster and buildbot.

No-BBB Releases

Still, as of 58, much of release automation still ran on buildbot, even if Taskcluster was doing all the scheduling.

Since December, we've been working on removing these last few pieces of buildbot from the release process. Progress was initially a bit slow, given Austin and Christmas, but we've been hard at work in the new year.

That brings us to today.

We've moved uptake monitoring, update verify (and made it 2x faster too!), update submission, final verify, bouncer submission, version bumping and tagging, balrog submission all to run in Taskcluster via various kinds of scriptworkers.

As I mentioned above, DevEdition 60.0b1 will be the first release in nearly 10 years done without using buildbot. The rest of the 60 release cycle will follow suit, and once 60 hits the release channel, only ESR52 will remain on buildbot!

Categorieën: Mozilla-nl planet

K Lars Lohn: Things Gateway - Part 5

vr, 02/03/2018 - 18:00
In Part 4 of this series, I showed how to link the Things Gateway with a quartet of Philips Hue bulbs via the Hue Bridge.  There are advantages and disadvantages to using the Hue Bridge.  On the plus side, the Hue Bridge enables the mobile device app, a mature controller for Hue lights with plenty of bells and whistles.  On the downside, the Hue Bridge is an Internet capable device, and I'm just not sure I can trust that.

My experience shows that if you purchase a Hue bulb packaged without a Hue Bridge, you can pair the light directly with a Zigbee adapter.  This means that the light works like any Zigbee compatible bulb.

Purchasing Hue bulbs in a Starter Kit can be a less expensive way to purchase Hue bulbs.  Starter Kits include three or four bulbs along with a Hue Bridge.  However, the bulbs are effectively locked to the Hue Bridge that came in the package.  To use the bulb without the Hue Bridge, the bulbs need liberation. Fortunately, it is not as complicated and perilous as jail breaking a cell phone.  Ironically, Philips sells the tool to do the unlocking disguised as their own remote Hue Dimmer Switch.

Caveat emptor:  If you really want to avoid the Hue Bridge, compare the costs of buying single bulbs versus Starter Kits, factoring in the cost of the Hue Dimmer Switch.  The only way that Starter Kits saved money was when I found them on sale.  At their full price, they are a dubious bargain.

Goal: Get the Things Gateway to control Hue light bulbs without the use of a Hue bridge. Maintain total local control with no component communicating outside to the Internet.
To reproduce everything that I'm doing here today, you'll need these things:

Requirements & Parts List:
ItemWhat's it for?Where I got itThe Raspberry Pi and associated hardware from Part 2 of this series.This is the base platform that we'll be adding ontoFrom Part 2 of this seriesDIGI XStickThis allows the Raspberry Pi to talk the ZigBee protocol - there are several models, make sure you get the XU-Z11 model.The only place that I could find this was Mouser ElectronicsPhilips Hue White & Color Ambiance bulbTo demonstrate use of a Hue bulb without any extra parts or incantationsHome DepotPhilips Hue White & Color Ambiance Starter KitTo demonstrate unlocking Hue bulbs from their associated Hue BridgeAmazonPhilips Hue Dimmer SwitchThe magic key that can unlock Hue bulbsAmazon
Step 1: I'm assuming that we're starting with the Things Gateway configured for the Zigbee adapter.  See Part 2 of this series for instructions.  Remember to update the Zigbee add-on as specified in the instructions.

Step 2: First we're going to just show that we can, with no fuss, use a Philips Hue bulb that was not packaged with a Hue Bridge.
From the Things pane, press the "+" button.
Plug in your Hue light, you should see the bulb detected.  Press "Save" and "Done".
You now have full control of a Hue bulb in the Things Gateway.  You can repeat this step with any Hue bulbs that were purchased without a Hue Bridge.

Step 3:  From this point on, we're only going to deal with liberating Hue bulbs that were purchased in a Starter Kit that included a Hue Bridge.   If you've already set up your Hue lights and Bridge, these instructions will effectively undo that setup.
The first thing that we need to do is unlock the bulbs.  For that, we're going to use the Hue Dimmer Switch.  You'll notice that the instructions for the dimmer switch want you to pair it with the bridge.  Since our goal is to not use the bridge, we're going to ignore the instructions.  Pull the battery tab to get power to the dimmer.  There will be a tiny light in one corner of the ON switch that blinks orange.  This means that it is looking to pair with a Hue Bridge.  You may ignore the blinking light.

We're going to apply power to one of our Hue bulbs.  It should light up warm white in color.  Hold the Hue Dimmer in both hands with thumbs set to press both the ON and OFF buttons at the same time.  Move the dimmer to within four inches of the bulb to be unlocked.  Press and hold the ON and OFF buttons.  After ten seconds, continue holding when the bulb blinks a harsh bluish white light several times and then re-illuminates to a warm white.  Release the buttons.
Repeat this step for each bulb that you want to unlock.  In my case, since my bulbs are so close to each other, I had to ensure that only one bulb was powered at a time.

The Hue Dimmer can factory reset other Zigbee compatible bulbs, like the CREE bulbs and Ikea TRÅDFRI bulbs.  I'll have more on that in a future Ikea focused installment.

Step 4:  To add your newly unlocked Hue bulbs to the Things Gateway, repeat Step 2 for each bulb.  When completed, I had five Hue bulbs ready to color at will.  Now will somebody remind me why I would want lights of all these different colors?
In the next installment, I'm going to integrate TP-Link devices into this circus.
Categorieën: Mozilla-nl planet