Showing posts with label Intel. Show all posts
Showing posts with label Intel. Show all posts

Thursday, May 23, 2013

Tizen Shell, la versione desktop di Tizen OS 3 basata su GNOME Shell


Notizie dal mondo Tizen OS, il sistema operativo mobile per smartphone sponsorizzato da Intel e Samsung e basato su Linux.

A quanto pare Tizen OS è pronto a scendere in campo nel settore UltraBook o più in generale nel mondo desktop.

In un video da poche ore pubblicato su Tizen Experts è possibile vedere in azione una versione di Tizen OS basata su GNOME 3 su di un UltraBook Intel.
La nuova modalità desktop è ottenuta mediante la "fusione" di Tizen OS 3 e Gnome Shell. L'interfaccia desktop è stata ribattezzata dagli sviluppatori con il nome di Tizen Shell.

Nel video è possibile vedere le classiche applicazioni a cui siamo abituati noi pinguini come Rhytmbox, Google Chrome, Steam, Shotwell, Files, LibreOffice, Empathy, etc affiancate da alcuni widgets (scritti in javascript utilizzando le API di GNOME 3) per gestire Facebook, Twitter, il Meteo e tutto quello che può rientrare nella sfera mobile.

Il network manager utilizzato è Connman e per la gestione dell'audio viene utilizzato Pulse Audio.
Insomma, hanno in pratica preso Tizen e gli hanno abbinato GNOME 3 cambiandone il tema e ritoccandolo qua e la.
Voi cosa ne pensate?

Any source

Saturday, October 15, 2011

How Can We Change the Future? The Tomorrow Project

It turns out that Intel, the giant chip maker, employs a full time futurist. His name is Brian David Johnson, and he actually gets paid to go around asking people what the future might be like. Intel says they're the "Sponsors of Tomorrow", so I guess they want to have a clue about what they're sponsoring. When I worked at Intel in the early 80's, we could have sponsored a thousand futurist studies, and not one of them would have predicted that Intel would someday employ a "Chief Futurist" leading a "Tomorrow Project".

None of those futurists would have predicted that over a hundred thousand people would show up at New York Comic-Con, either. But it's happening. The show is completely sold out. Jacob Javits Convention Center is packed to the gills with zombies, otaku, wood nymphs, transformers and girls with blue, purple or red hair- i don't know the word for them.

Many of them packed a very serious session hosted by Johnson featuring Cory Doctorow, the science fiction writer, blogger, and activist. The session was entitled "Sci-Fi Prototyping: Designing the Future Panel". No on in the audience was disappointed not to hear about the future of the panel, and we also did without Doug Rushkoff, whose appearance was scheduled to make the panel a panel, but who failed to predict his future schedule well enough to participate.

Doctorow, Johnson, Rushkoff, and will.i.am, who was accurately predicted to not be present, have contributed to The Tomorrow Project Anthology which had its launch today. Nostalgically enough, this is a book. Less nostalgic, but perhaps just as dated, it's a 1.8MB PDF file. Made available for free, by Intel. Doctorow's contribution is a novella by Doctorow called The Knights of the Rainbow Table which so far (I'm on p.17), is a fun read. It's about the nano-apocalypse that will occur in the near future when it's easy for a group of grad student low-lifes to crack everybody's website password security.

Johnson framed the session as a discussion about the ways in which science fiction can provide a narrative to steer the future. I'm a bit skeptical. I don't think that the "narrative" of Star Trek communicators caused Motorola engineers to create the flip-phone, even if they were fans of the show while growing up. Doctorow had a really interesting analogy, though. He said a science fiction story was like a Petri dish that lets an microscopic idea grow into a huge colony of micro-organisms visible to the naked eye. That strikes me as a really useful way to think of how fiction influences the world.

The problem with ascribing power to narrative is evident if you look at the world around us. Narratives compete with other narratives, and their relative power derives not from their truth or their skill, but rather from their fit. Narratives warning about the death of privacy, for example, have scant power compared to the offer of a free movie, or even a free PDF download. No one pays attention to a narrative unless it fits with what they want to do today.

Before the panel, Doctorow expressed to me his strong commitment to making his works available with Creative Commons licenses; He'll certainly release The Knights of the Rainbow Table that way. But let's work on Intel to change the future a bit. Why can't they release The Tomorrow Project Anthology with a similar license? (the current license is all rights reserved, you can download it, but you can't redistribute it) You CAN help change the future- file a request to post the whole ebook using this form.
 
In yesterday's tomorrow, androids dream of electric sheep, cars fly around LA, and in Blade Runner, people read newspapers on paper. What will today's tomorrow look like tomorrow? I wonder how much of today's best writing about the future will be available to people ten years from now. Unfortunately, the answer depends on licensing details that most creators don't think much about. Doctorow is an exception.
Enhanced by Zemanta

Article any source

Monday, June 7, 2010

Are Public Libraries in a Death Spiral?

The year and a half that I worked for Intel was marked by a sharp recession in the semiconductor industry. Most of the industry was plagued with a boom and bust cycle; during the busts, most companies laid off staff. Intel had at that point managed to avoid layoffs, and Andy Grove, Intel's hard-charging President, wanted to protect that record. He came up with a program called the "125% solution". As an alternative to layoffs, Grove asked Intel employees to work 50 hours a week instead of 40, without a pay increase.  We were told that we would work our way through the recession by developing new products.

The management of the Technology Development division, where I worked, had a hard time with this plan. At the meeting where they explained the program to us, they anticipated the obvious question. "No, this doesn't mean you should cut back your hours to 50 from the 50-80 hours some of you have been working." Even so, most of us were relieved that there would be no layoffs, and the line workers felt the same way.

I apologize in advance if this article comes off a bit Grove-ish, but I've become increasingly worried about the future of public libraries. It's not just the large library budget cuts that seem to be pandemic across the country (see the list below if you need any confirmation) but it's the way that budget cuts are preventing preventing libraries from addressing the fundamental changes that are occuring in the ways that people interact with books.

A favorite budget-cutting tactic of public library directors seems to be curtailment of opening hours (with branch-closing a close second). To me, this seems like the worst possible thing for a public library to do. It's as if Andy Grove had told us that we needed to get rid of 25% of our customers. Public library funding comes from the public, and the best way to convince the public that their library deserves more funding is to get the public inside the library doors.

Public Broadcasting is a good example for public libraries (and a competitor for donor support). Does public radio turn off their transmitter when they need money? No, they put on specially good programming and have pledge drives. My local library puts donor names on bricks; I'd like to see libraries put donor names on opening hours.

Tough economic times are exactly when public libraries are needed the most. The assistance that libraries offer to people looking for work, training for new occupations, learning to read, or finding social networks makes public libraries valuable parts of their communities, but that doesn't happen when the doors are locked. I can imagine a future where public library services are online and always open, but that's not today's reality.

One argument for cutting hours might be that the visibility of these cuts makes it easier to restore funding when the economic cycle turns. This may have been true in the past, but I think that the funding that goes away this year will never come back. The way most people access information has changed profoundly since the last economic downturn. A library that reduces its hours is just training its public to meet information needs elsewhere, and that public isn't going to rush back. The library's funding will get cut again and again, and eventually it will have to close its doors.

The public library of the future has to stop being about collections and start being about helping people and communities. Google can't be a physical place where people offer access, assistance and education for the internet and the information it accesses; local public libraries CAN be.   It's these "new" directions that will attract renewed public support and funding into the future. But library directors struggling to deal with budget cuts will find it hard to also reposition their services to meet the needs of an increasingly internet-based society.

Although I don't like cutting hours, it's not like there are lots of alternatives. Libraries with slashed budgets have painful cuts to make. Difficult choices will be made on acquisitions, staff, buildings, user fees, organizational mergers and consolidations. If you're involved with a library that's going through this, don't give up.

Intel survived that recession, and gave us beer mugs to celebrate the end of the "125% Solution". But it didn't escape the endless spiral of economic expansion and contraction. The next contraction cycle combined with competition from Japan to force Intel to lay off many workers and re-examine its businesses. Intel left the DRAM business to focus on microprocessors. You can read the rest of the story...in the library. (Or at Amazon)

Funding cuts in libraries (thanks to Gary Price at ResourceShelf, the Library Journal Funding Page, and LISNews for many of the links):
Reblog this post [with Zemanta]

Article any source

Friday, May 21, 2010

Bit.ly Preview Add-on Leaks User Activity; Referer Header Considered Harmful

Inside Intel: Andy Grove and the Rise of the World's Most Powerful Chip CompanyI've been reading a book called "Inside Intel" by Tim Jackson that reports the history of the chip giant up to 1997. At the end of the book, Intel is dealing with the famous flaw in the Pentium's division circuitry. Jackson observes that Intel's big mistake in dealing with the bug was to deal with it as a minor technical issue rather than as the major marketing issue it really was. If Intel's management had promptly addressed consumer concerns by offering to replace chips for any customer that wanted it rather than dismissing the problem as the inconsequential bug it actually was, it could have avoided 90% of the expense it actually incurred. The public doesn't want to deal with arcane technology bugs; they want to know who to trust.

This week FaceBook and MySpace had to deal with the consequences of obscure bugs that leaked personal subscriber information to advertisers. The Wall Street Journal reported that because Facebook and MySpace put user handles in URLs on their sites, these user handles, which can very often be traced back to a user identity, leaked to advertisers via the referer headers sent by browser software.

Reaction on one technology blog reminded me of Intel's missteps. Marshall Kirkpatrick, on ReadWriteWeb, called the the Journal's article "a jaw dropping move of bizarreness", going on to explain that passing referrer information was "just how the Internet works" and accusing the Journal of "anti-technology fear-mongering".

When a web browser requests a file from a website, it sends a bunch of extra information via http headers. One header gives the address of the file, which might be a web page, an image, or a script file. Other headers give the name of the software being used, the language and character sets supported by the browser. The Referer header (yes, that's how it's spelled, blame the RFC for getting the spelling wrong) reports the address of the page that requested or linked to the file. If the request is made to an advertiser's site, the Referer URL identifies the page that the user is looking at. When that page has an address that include private information, the private stuff can leak.

The controversy spurred me to take a look at some library websites to see what sort of data they might leak using referer headers. I used the very handy Firefox add-on called "Live HTTP Headers". I was astounded to see that a well known book database website seemed to be reporting the books I was browsing to Bit.ly, the URL shortening service! In another header, Bit.ly was also getting an identifying cookie. I went to another website, and found the exact same thing. This set off some alarm bells.

I soon realized that a report of EVERY web page I visit is being sent to Bit.ly. The culprit turned out to be Bit.ly's Bit.ly Preview add-on for Firefox. It turns out that for every web page I visit, this line of javascript is executed:
this.loadCss("http://s.bit.ly/preview.s3.v2.css?v=4.2");
This request for a CSS stylesheet has the side effect of causing Firefox to transmit to Bit.ly the address for each and every web page I visit in a referer header.

It's ironic. My last post described how URL shortening services can be abused for evil, but my point was that these abuses were a burden for the services, not that the services were abusive themselves. In fact, Bit.ly has probably done more than any shortening service to combat abuse and the Preview add-on is part of that anti-abuse effort. With Preview installed, users can safely check what's behind any of the short URLs they encounter by hovering over the link in question.

The privacy leak in bit.ly Preview is almost certainly an unintentional product of sloppy coding and deficient testing rather than an effort to spy on the 100,000 users who have installed the add-on. Nonetheless, it's a horrific privacy leak. There are other add-ons that intentionally leak private information, but typically they disclose their activity as a natural part of the add-on's functionality. One example would be GetGlue, which I've written about, and even Bit.ly preview cannot help but leak some info when it's doing what it's supposed to do (expand and preview shortened URLs).

I'm sure that Bit.ly will fix this bug quickly; their support was amazingly fast when I reported another issue. But a larger question remains. How do we make sure that the services we use everyday aren't leaking our info all over the place? The most widely deployed services- Google, Amazon, Facebook, etc. all deserve a  higher level of scrutiny because of the quantity of data at their fingertips. All the privacy policies in the world aren't worth a dime if web sites can't be held accountable for the effects of sloppy coding. It's high time for popular sites to submit to strict third-party privacy auditing, and for web users to demand it. It doesn't matter whether any advertisers actually used the personal information that Facebook sent them; what matters is whether users can trust Facebook.

It's also time for the internet technology community to recognize that referer headers are as dangerous to privacy as they are to spelling. They should be abolished. Browser software should stop sending them. The referer header was originally devised to help dispersed server admins fix and control broken links. Today, the referer header is used for "analytics", which is a polite word for "spying". The collection of referer headers helps web sites to "improve their service", but you could say the same of informants and totalitarian governments.

The pipe is rusty- that's why it leaks. We need to fix it.
Article any source

Monday, March 22, 2010

Second Sourcing, Application Interfaces, and a 16 Bit Static Ram

While returning my Mac Plus to the attic, I decided to bring out some electronics relics I have from an even earlier era. The photo shows an undiced 1.25" wafer of integrated circuits and two packaged chips from around 1969. (The acorn hat is for scale) There are about 200 transistors on each chip. I think it's a 16 bit static RAM chip- with a magnifying glass, I can see and count the 16 cells. For context, when the Mac 128K Mac came out, it shipped with 64Kb DRAM chips. (about 1000x more dense). Today 4Gb chips are in production, a factor of a billion denser than my relic, and the silicon wafers are 30 cm in diameter.

My father was one of the founders of Solid State Scientific, Inc., (SSSI) a company that made CMOS integrated circuits. SSSI, located in Montgomeryville PA, started out as a second-source supplier for RCA's line of low-power CMOS logic chips. In the electronics industry, it has been a common practice for component manufacturers to license their circuit designs or specifications to other manufacturers so that their customers would be assured of an adequate supply. The second source company could compete on price or performance. For example, engineers could design systems with the 4060 14-bit ripple counter chip with internal oscillator, and know that they could buy a replacement chip from either RCA or SSSI. If RCA's fab was fully booked, SSSI would be able to fill the gap. There was no vendor lock-in.

Second source relationships could be tricky- AMD and Intel famously ended up litigating AMD's second-source status for the 8086 series of microrocessors. Logic family chips were commodities, and profit margins were thin. The second-source gambit was a judgment that a company could make more money by driving prices down and volume up. Companies like SSSI were always chasing after higher profit margins in new applications such as custom circuits for digital watches. The large volume parts would pay for their fabs, and the proprietary circuits would earn the profits, or at least that was the idea. Vendor lock-in, while while it might discourage adoption and reduce volume, is good for profitability.

As chips become more and more complicated, the chip manufacturing industry realligned. Today, apart from giants like Intel, most chips are manufactured by foundry companies that don't do chip design at all. Chip design companies try to maintain high margins with exclusive intellectual property; the foundry companies aggregate volume and drive down cost by manufacturing chips from many different design companies.

I've been thinking about the way that the advance of technology moves application interfaces. In the days of the CMOS logic chips, the application interface was a spec sheet and a logic diagram. That was everything an circuit designer needed to include the component in a design. Today that interface has migrated onto the chip and into software;  chip foundries provide software models for components ranging from transistors to processor blocks for designers to include in their products.

When software engineers talk about application interfaces, they're usually thinking about function calls and data structures that one block of software can use to interact with other blocks of software. These interfaces, once published and relied on, tend to be much more stable over time than the code hidden behind them. To some extent, software application interfaces can hide hardware implementations as easily as they can hide code. One result of this is that new chips may come with software interfaces that persist through different versions of the chip. In something of a paradox, the software interface is fixed while the hardware interface moves around.

Software has become more and more part of our daily work, and interfaces have become important to non-engineers. File formats are a good example of application interfaces that are important to all of us. The files I produced on my Mac Plus 25 years ago are still with me and usable; because of that, but you can read the Ph. D. dissertation I wrote using it. OpenOffice serves as a second-source for Word, and I can use either program with some assurance that I will continue to be able to do so into the future.

There's some backstory there. The "interchange format" for the original Word was "RTF". RTF is a reasonably good format, informed by Donald Knuth's TeX, but it was always a second citizen compared to the native "DOC" format. Microsoft published a spec, but they didn't follow it too closely and they changed it with every new release of Word. One result was that it was difficult to use Word as part of a larger publishing system (which I tried to do back in my days as an e-Journal developer). The last thing Microsoft wanted was for competition to Word develop before it grew to dominate the marketplace.

Cloud based software (software as a service) depends in a interesting way on application interfaces. Consider Google docs. You can send it a ".DOC" file created in Microsoft Word, do something with it, then export it. In a sense, Word is a "second source" for Google Docs, and consumers can use Docs without fear of lock-in. Docs adds its own web API so that developers can use it as a component of a larger web-based system. This is the "platform" strategy.

These new interfaces offer a user lock-in trade-off. While the customer gains the freedom to use a website's functionality with services from other companies, the control of the interface leaves the other companies at the mercy of the  company controlling the API. Developers coding to the interface are in the same situation as a second source chip supplier- always exposed to competition, while the platform provider becomes more and more locked in with every new component that plugs into it.

We now see a very interesting competition in platform strategies emerging. Apple's iPad/iPhone/iTouch software platform tries to lock-in consumers by opening an attractive set of API's for app development. It goes further, though, by attempting to control a marketplace (the app store) and imposing restrictive terms on app vendors. Google's Android platform tries to do the same thing in a much more open environment. Apple seems to have learned an important lesson, though. The biggest difficulty facing a company trying to plug into a platform is profitability, and the iPhone software marketplace appears to be offering viable business models for developers. It remains to be seen whether that condition will last, but it's clear that technology shifts are pushing services (such as phone service) that used to be stand-alone products into large, more complex ecosystems.
Enhanced by Zemanta

Article any source