posted by Bryon Moyer
I recently stumbled upon a limited series on Netflix called Black Mirror. I’m not accustomed to doing reviews, so this is a bit unusual – yet I found this series particularly compelling and worth some comment.
While it’s not a show about technology per se, it’s a show about humans and what they might do with technology. And it felt like the writers had access to some pretty tech-savvy consultants when putting it together.
Needless to say, the scenes depicted bear little resemblance to the promises that marketing brochures make about our future tech-driven paradise (you know, the one that takes all the grunt work away and gives us all that leisure time?). Given that there’s no lack of happy prognostics, this focuses on the flip side – a darker look. It doesn’t blame technology; it’s clear that whatever scenarios they concoct are a result of humans. But technology is the clear enabler in the background.
It also doesn’t shout solutions; many of the episodes end unresolved. It’s as if they’re leaving us to decide how it ends.
This series is unique in that each episode is completely self-contained. It’s like a collection of short stories. No two episodes occur in the same time or place. (Although there is a featured song that shows up in two episodes…) The actors are completely different. A few familiar faces; mostly not (at least for US folk – it appears to be a British production). Given that they needed new sets and costumes for each one, that’s probably why each “season” has only three episodes at most. The first season was actually 2011, then 2013 and 2014. So I’m a bit late to the game.
To be clear, this is an edgy production, not for kids. Some episodes can be harder to watch. There’s some sex; not a ton of violence. If you don’t like any of that, then you won’t enjoy it. But if you don’t mind being challenged, then I found it an interesting non-tech take on the technology we take for granted every day.
You can find more info at http://www.imdb.com/title/tt2085059/.
posted by Larra Morris
3D printed fashion is not new at this point. Printed accessories, jewelery, and even dresses have been showing up at Maker Faires, 3D Printing shows, and other technology/fashion showcases for several years now. Last year, I wrote about some of the 3D printed fashion at the 3D Printing Conference and Expo in New York City and the exciting intersection between art and technology being represented at that show.
This weekend, I feel like I witnessed a sign of a big step forward for 3D printed fashion within culture. I went to the Museum at FIT (at the Fashion Insitute of Technology in New York City) to check out their new Fairy Tale Fashion Exhibition. The show examines how fairy tales inspire high fashion, from red cloaks to glass slippers to gowns fit for a swan princess. It's an exhibit in keeping with many of the other fashion art museum displays put on by the Museum at FIT, or the Costume Institute at the Metropolitan Museum of art, or other museums/galleries of that nature. The focus is not on technology or high tech.
One display featured garments inspired by the story of Cinderella, including, predictably, several fancy shoes inspired by glass slippers. Among them, I was excited to find a glass slipper by Noritaka Tatehana: a clear acrylic, heel-less high heel, faceted to reflect light. The explantory placard in front of it casually mentioned that it was a 3D printed shoe. I read the card and said to my companion, "whelp, it looks like 3D printed fashion has arrived."
The inclusion of a 3D printed item in this exhibit seems to signal a step forward because this is a fashion art show. Not a special “3D Printed Fashion” show or a “Technology in Fashion” display or a “BEHOLD… FASHION OF THE FUTURE!” -type event. The topic is not meant to highlight 3D printing technology at all. The placard doesn't scream: "Look at this crazy 3D printed shoe! What a wild new technique!" It simply explains that 3D printing was the technique the designer used to achieve the effect he wanted. This matter-of-fact presentation of 3D printing, placed right alongside all the other techniques in an art show, is a signal that 3D printed fashion is taking a step from the sideshow onto the mainstage.
Cinderella Slipper and photograph © Noritaka Tatehana, 2014
posted by Bryon Moyer
We would be nowhere without clocks. So much of what we do involves timing, much of which we’re completely unaware of – in particular, electronically. Many of our systems depend on some kind of a master clock so that logging and timestamping can be done reliably. And with the advent of even more “asynchronous” systems that report events with a timestamp, soon even more systems will need access to a reliable time source.
That’s hard enough within one box, but in many cases, it must be done between two boxes on the same network or even between two boxes on two different networks. That means that an internal clock source won’t work: it will be different from the internal clock sources in the other boxes, and these will gradually drift apart.
If you’re trying to create a record of what came before what, everyone has to agree on the time base. One example given by Microsemi was that of a very short (less than a minute) cell phone call whose beginning and ending timestamps came from different servers whose clocks had drifted apart. The start ended up being timestamped as happening after the end of the call, which caused the billing software to record a 23-hour and 59 minute (or thereabouts) call length.
As quick background for those of us not in the midst of this, the timing is handled by a time server. When a server on the network needs to timestamp an event, it sends a request to the time server for a timestamp via NTP, or network time protocol. In this manner, all the servers on the same network have a consistent source of time.
Granted, the requests get serialized, so if two events happened “simultaneously”, one timestamp would get issued before the other. So it’s important that the response time be fast enough that multiple serialized timestamps can be served within a single “tick” so as to be reported as simultaneous for a given level of precision.
But if you need timestamps that you can compare with each other from two different networks, then you no longer have the a single time server handling both – you have two different time servers, one for each network, and they have to be in synch too. How does that happen?
GPS (or GNSS more generally) is how that happens; exquisite timing is necessary for these navigation systems to work, so the time server is connected to an antenna that detects GPS and uses it to set the time. This lets multiple servers maintain a consistent, correlatable time base. In the event that GPS fails, these servers actually have mini atomic clocks that can hold each server over with minimal drift so that any GPS gaps can be covered.
But there’s one problem and vulnerability: most time servers process the time requests using a CPU. The CPU takes longer to process a time request than the network takes to deliver the request, so the system essentially relies on breaks between requests to allow the CPU to keep up. That makes the system vulnerable to a distributed denial of service (DDoS) attack – essentially, flooding the server with timestamp requests and potentially crashing the server (which then messes up all the systems relying on the time server).
So Microsemi has issued a new time server, the SyncServer S600/650, with a significant twist: NTP requests aren’t sent to the CPU; they’re sent to FPGAs for a faster hardware response. So fast that it can respond at line rate to the gigabit Ethernet incoming pipe. In other words, it can keep up with as many requests as you can place into the pipe. If you try to flood it even harder, you can’t because the pipe is already full. At the same time, if the server thinks someone is trying to flood it, it can issue an alarm so that IT folks can intervene.
Image courtesy Microsemi
The FPGA provides another benefit: flexibility. Time servers can provide a number of direct signals – clocks, sine waves, timestamp series, etc. – via plug-in modules. But typical modules can provide only one of these types of signal, making server configuration inflexible. By using FPGAs, those modules can be programmed – statically or in real time – to provide different outputs as needed, making the provisioning of the server much more efficient.
You can find more info in their announcement.