Skip to main content

Home/ Future of the Web/ Group items tagged manageability engine

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

XML Production Workflows? Start with the Web and XHTML - 0 views

quod.lib.umich.edu/...n-workflows-start-with-the-web

OpenWeb XML XHTML-CSS HTML5-CSS3-JavaScript IDML

shared by Gary Edwards on 07 Nov 13 - No Cached
  • Challenges: Some Ugly Truths The challenges of building—and living with—an XML workflow are clear enough. The return on investment is a long-term proposition. Regardless of the benefits XML may provide, the starting reality is that it represents a very different way of doing things than the one we are familiar with. The Word Processing and Desktop Publishing paradigm, based on the promise of onscreen, WYSIWYG layout, is so dominant as to be practically inescapable. It has proven really hard to get from here to there, no matter how attractive XML might be on paper. A considerable amount of organizational effort and labour must be expended up front in order to realize the benefits. This is why XML is often referred to as an “investment”: you sink a bunch of time and money up front, and realize the benefits—greater flexibility, multiple output options, searching and indexing, and general futureproofing—later, over the long haul. It is not a short-term return proposition. And, of course, the returns you are able to realize from your XML investment are commensurate with what you put in up front: fine-grained, semantically rich tagging is going to give you more potential for searchability and recombination than a looser, more general-purpose approach, but it sure costs more. For instance, the Text Encoding Initiative (TEI) is the grand example of pouring enormous amounts of energy into the up-front tagging, with a very open-ended set of possibilities down the line. TEI helpfully defines a level to which most of us do not have to aspire.[5] But understanding this on a theoretical level is only part of the challenge. There are many practical issues that must be addressed. Software and labour are two of the most critical. How do you get the content into XML in the first place? Unfortunately, despite two decades of people doing SGML and XML, this remains an ugly question.
  • Practical Challenges In 2009, there is still no truly likeable—let alone standard—editing and authoring software for XML. For many (myself included), the high-water mark here was Adobe’s FrameMaker, substantially developed by the late 1990s. With no substantial market for it, it is relegated today mostly to the tech writing industry, unavailable for the Mac, and just far enough afield from the kinds of tools we use today that its adoption represents a significant hurdle. And FrameMaker was the best of the breed; most of the other software in decent circulation are programmers’ tools—the sort of things that, as Michael Tamblyn pointed out, encourage editors to drink at their desks. The labour question represents a stumbling block as well. The skill-sets and mind-sets that effective XML editors need have limited overlap with those needed by literary and more traditional production editors. The need to think of documents as machine-readable databases is not something that comes naturally to folks steeped in literary culture. In combination with the sheer time and effort that rich tagging requires, many publishers simply outsource the tagging to India, drawing a division of labour that spans oceans, to put it mildly. Once you have XML content, then what do you do with it? How do you produce books from it? Presumably, you need to be able to produce print output as well as digital formats. But while the latter are new enough to be generally XML-friendly (e-book formats being largely XML based, for instance), there aren’t any straightforward, standard ways of moving XML content into the kind of print production environments we are used to seeing. This isn’t to say that there aren’t ways of getting print—even very high-quality print—output from XML, just that most of them involve replacing your prepress staff with Java programmers.
  • Why does this have to be so hard? It’s not that XML is new, or immature, or untested. Remember that the basics have been around, and in production, since the early 1980s at least. But we have to take account of a substantial and long-running cultural disconnect between traditional editorial and production processes (the ones most of us know intimately) and the ways computing people have approached things. Interestingly, this cultural divide looked rather different in the 1970s, when publishers were looking at how to move to digital typesetting. Back then, printers and software developers could speak the same language. But that was before the ascendancy of the Desktop Publishing paradigm, which computerized the publishing industry while at the same time isolating it culturally. Those of us who learned how to do things the Quark way or the Adobe way had little in common with people who programmed databases or document-management systems. Desktop publishing technology isolated us in a smooth, self-contained universe of toolbars, grid lines, and laser proofs. So, now that the reasons to get with this program, XML, loom large, how can we bridge this long-standing divide?
  • ...44 more annotations...
  • Using the Web as a Production Platform The answer, I think, is right in front of you. The bridge is the Web, a technology and platform that is fundamentally based on XML, and which many publishers are by now comfortably familiar with. Perhaps not entirely comfortably, but at least most publishers are already working with the Web; they already either know or have on staff people who understand it and can work with it. The foundation of our argument is this: rather than looking at jumping to XML in its full, industrial complexity, which seems to be what the O'Reilly-backed StartWithXML initiative[6] is suggesting, publishers instead leverage existing tools and technologies—starting with the Web—as a means of getting XML workflows in place. This means making small investments and working with known tools rather than spending tens of thousands of dollars on XML software and rarefied consultants. It means re-thinking how the existing pieces of the production toolchain fit together; re-thinking the existing roles of software components already in use. It means, fundamentally, taking the Web seriously as a content platform, rather than thinking of it as something you need to get content out to, somehow. If nothing else, the Web represents an opportunity to think about editorial and production from outside the shrink-wrapped Desktop Publishing paradigm.
  • Is the Web made of Real XML? At this point some predictable objections can be heard: wait a moment, the Web isn’t really made out of XML; the HTML that makes up most of the Web is at best the bastard child of SGML, and it is far too flaky/unstructured/underpowered to be taken seriously. We counter by arguing that although HTML on the Web exists in a staggering array of different incarnations, and that the majority of it is indeed an unstructured mess, this does not undermine the general principle that basic, ubiquitous Web technologies can make a solid platform for content management, editorial process, and production workflow.
  • With the advent of a published XML standard in the late 1990s came the W3C’s adoption of XHTML: the realization of the Web’s native content markup as a proper XML document type. Today, its acceptance is almost ubiquitous, even while the majority of actual content out there may not be strictly conforming. The more important point is that most contemporary Web software, from browsers to authoring tools to content management systems (from blogs to enterprise systems), are capable of working with clean, valid XHTML. Or, to put the argument the other way around, clean, valid XHTML content plays absolutely seamlessly with everything else on the Web.[7]
  • The objection which follows, then, will be that even if we grant that XHTML is a real XML document type, that it is underpowered for “serious” content because it is almost entirely presentation (formatting) oriented; it lacks any semantic depth. In XHTML, a paragraph is a paragraph is a paragraph, as opposed to a section or an epigraph or a summary.
  • n contrast, more “serious” XML document types like DocBook[8] or DITA-derived schemas[9] are capable of making semantic distinctions about content chunks at a fine level of granularity and with a high degree of specificity.
  • So there is an argument for recalling the 80:20 rule here. If XHTML can provide 80% of the value with just 20% of the investment, then what exactly is the business case for spending the other 80% to achieve that last 20% of value? We suspect the ratio is actually quite a bit steeper than 80:20 for most publishers.
  • Furthermore, just to get technical for a moment, XHTML is extensible in a fairly straightforward way, through the common “class” attribute on each element. Web developers have long leveraged this kind of extensibility in the elaboration of “microformats” for semantic-web applications.[10] There is no reason why publishers shouldn’t think to use XHTML’s simple extensibility in a similar way for their own ends.
  • XHTML, on the other hand, is supported by a vast array of quotidian software, starting with the ubiquitous Web browser. For this very reason, XHTML is in fact employed as a component part of several more specialized document types (ONIX and ePub among them).
  • Why re-invent a general-purpose prose representation when XHTML already does the job?
  • It is worth pausing for a moment to consider the role of XHTML in the ePub standard for ebook content. An ePub file is, anatomically, a simply disguised zip archive. Inside the zip archive are a few standard component parts: there are specialized files that declare metadata about the book, and about the format of the book. And then there is the book’s content, represented in XHTML. An ePub book is a Web page in a wrapper.
  • To sum up the general argument: the Web as it already exists presents incredible value to publishers, as a platform for doing XML content management with existing (and often free) tools, and without having to go blindly into the unknown. At this point, we can offer a few design guidelines: prefer existing and/or ubiquitous tools over specialized ones wherever possible; prefer free software over proprietary systems where possible; prefer simple tools controlled and coordinated by human beings over fully automated (and therefore complex) systems; play to our strengths: use Web software for storing and managing content, use layout software for layout, and keep editors and production people in charge of their own domains.
  • Putting the Pieces Together: A Prototype
  • At the SFU Master of Publishing Program, we have been chipping away at this general line of thinking for a few years. Over that time, Web content management systems have been getting more and more sophisticated, all the while getting more streamlined and easier to use. (NB: if you have a blog, you have a Web content management system.) The Web is beginning to be recognized as a writing and editing environment used by millions of people. And the ways in which content is represented, stored, and exchanged online have become increasingly robust and standardized.
  • The missing piece of the puzzle has been print production: how can we move content from its malleable, fluid form on line into the kind of high-quality print production environments we’ve come to expect after two decades of Desktop Publishing?
  • Anyone who has tried to print Web content knows that the existing methods leave much to be desired (hyphenation and justification, for starters). In the absence of decent tools for this, most publishers quite naturally think of producing the print content first, and then think about how to get material onto the Web for various purposes. So we tend to export from Word, or from Adobe, as something of an afterthought.
  • While this sort of works, it isn’t elegant, and it completely ignores the considerable advantages of Web-based content management.
  • Content managed online is stored in one central location, accessible simultaneously to everyone in your firm, available anywhere you have an Internet connection, and usually exists in a much more fluid format than Word files. If only we could manage the editorial flow online, and then go to print formats at the end, instead of the other way around. At SFU, we made several attempts to make this work by way of the supposed “XML import” capabilities of various Desktop Publishing tools, without much success.[12]
  • In the winter of 2009, Adobe solved this part of the problem for us with the introduction of its Creative Suite 4. What CS4 offers is the option of a complete XML representation of an InDesign document: what Adobe calls IDML (InDesign Markup Language).
  • The IDML file format is—like ePub—a simply disguised zip archive that, when unpacked, reveals a cluster of XML files that represent all the different facets of an InDesign document: layout spreads, master pages, defined styles, colours, and of course, the content.
  • IDML is a well thought-out XML standard that achieves two very different goals simultaneously: it preserves all of the information that InDesign needs to do what it does; and it is broken up in a way that makes it possible for mere mortals (or at least our Master of Publishing students) to work with it.
  • What this represented to us in concrete terms was the ability to take Web-based content and move it into InDesign in a straightforward way, thus bridging Web and print production environments using existing tools and skillsets, with a little added help from free software.
  • We would take clean XHTML content, transform it to IDML-marked content, and merge that with nicely designed templates in InDesign.
  • The result is an almost push-button publication workflow, which results in a nice, familiar InDesign document that fits straight into the way publishers actually do production.
  • Tracing the steps To begin with, we worked backwards, moving the book content back to clean XHTML.
  • The simplest method for this conversion—and if you want to create Web content, this is an excellent route—was to use Adobe’s “Export to Digital Editions” option, which creates an ePub file.
  • Recall that ePub is just XHTML in a wrapper, so within the ePub file was a relatively clean XHTML document. It was somewhat cleaner (that is, the XHTML tagging was simpler and less cluttered) than InDesign’s other Web-oriented exports, possibly because Digital Editions is a well understood target, compared with somebody’s website.
  • In order to achieve our target of clean XHTML, we needed to do some editing; the XHTML produced by InDesign’s “Digital Editions” export was presentation-oriented. For instance, bulleted list items were tagged as paragraphs, with a class attribute identifying them as list items. Using the search-and-replace function, we converted such structures to proper XHTML list and list-item elements. Our guiding principle was to make the XHTML as straightforward as possible, not dependent on any particular software to interpret it.
  • We broke the book’s content into individual chapter files; each chapter could then carry its own basic metadata, and the pages conveniently fit our Web content management system (which is actually just a wiki). We assembled a dynamically generated table of contents for the 12 chapters, and created a cover page. Essentially, the book was entirely Web-based at this point.
  • When the book chapters are viewed online, they are formatted via a CSS2 stylesheet that defines a main column for content as well as dedicating screen real estate for navigational elements. We then created a second template to render the content for exporting; this was essentially a bare-bones version of the book with no navigation and minimal styling. Pages (or even the entire book) can be exported (via the “Save As...” function in a Web browser) for use in either print production or ebook conversion. At this point, we required no skills beyond those of any decent Web designer.
  • Integrating with CS4 for Print Adobe’s IDML language defines elements specific to InDesign; there is nothing in the language that looks remotely like XHTML. So a mechanical transformation step is needed to convert the XHTML content into something InDesign can use. This is not as hard as it might seem.
  • Both XHTML and IDML are composed of straightforward, well-documented structures, and so transformation from one to the other is, as they say, “trivial.” We chose to use XSLT (Extensible Stylesheet Language Transforms) to do the work. XSLT is part of the overall XML specification, and thus is very well supported in a wide variety of tools. Our prototype used a scripting engine called xsltproc, a nearly ubiquitous piece of software that we found already installed as part of Mac OS X (contemporary Linux distributions also have this as a standard tool), though any XSLT processor would work.
  • In other words, we don’t need to buy InCopy, because we just replaced it with the Web. Our wiki is now plugged directly into our InDesign layout. It even automatically updates the InDesign document when the content changes. Credit is due at this point to Adobe: this integration is possible because of the open file format in the Creative Suite 4.
  • We wrote an XSLT transformation script[18] that converted the XHTML content from the Web into an InCopy ICML file. The script itself is less than 500 lines long, and was written and debugged over a period of about a week by amateurs (again, the people named at the start of this article). The script runs in a couple of seconds, and the resulting .icml file can then be “placed” directly into an InDesign template. The ICML file references an InDesign stylesheet, so the template file can be set up with a house-styled layout, master pages, and stylesheet definitions for paragraphs and character ranges.
  • The result is very simple and easy to use. Our demonstration requires that a production editor run the XSLT transformation script manually, but there is no reason why this couldn’t be built directly into the Web content management system so that exporting the content to print ran the transformation automatically. The resulting file would then be “placed” in InDesign and proofed.
  • It should be noted that the Book Publishing 1 proof-of-concept was artificially complex; we began with a book laid out in InDesign and ended up with a look-alike book laid out in InDesign. But next time—for instance, when we publish Book Publishing 2—we can begin the process with the content on the Web, and keep it there throughout the editorial process. The book’s content could potentially be written and edited entirely online, as Web content, and then automatically poured into an InDesign template at proof time. “Just in time,” as they say. This represents an entirely new way of thinking of book production. With a Web-first orientation, it makes little sense to think of the book as “in print” or “out of print”—the book is simply available, in the first place online; in the second place in derivative digital formats; and third, but really not much more difficult, in print-ready format, via the usual InDesign CS print production system publishers are already familiar with.
  • Creating Ebook Files Creating electronic versions from XHTML source is vastly simpler than trying to generate these out of the existing print process. The ePub version is extremely easy to generate; so is online marketing copy or excerpts for the Web, since the content begins life Web-native.
  • Since an ePub file is essentially XHTML content in a special wrapper, all that is required is that we properly “wrap” our XHTML content. Ideally, the content in an ePub file is broken into chapters (as ours was) and a table of contents file is generated in order to allow easy navigation within an ebook reader. We used Julian Smart’s free tool eCub[19] to simply and automatically generate the ePub wrapper and the table of contents. The only custom development we did was to create a CSS stylesheet for the ebook so that headings and paragraph indents looked the way we wanted. Starting with XHTML content, creating ePub is almost too easy.
  • Such a workflow—beginning with the Web and exporting to print—is surely more in line with the way we will do business in the 21st century, where the Web is the default platform for reaching audiences, developing content, and putting the pieces together. It is time, we suggest, for publishers to re-orient their operations and start with the Web.
  • Our project demonstrates that Web technologies are indeed good enough to use in an XML-oriented workflow; more specialized and expensive options are not necessarily required. For massive-scale enterprise publishing, this approach may not offer enough flexibility, and the challenge of adding and extracting extra semantic richness may prove more trouble than it's worth.
  • But for smaller firms who are looking at the straightforward benefits of XML-based processes—single source publishing, online content and workflow management, open and accessible archive formats, greater online discoverability—here is a way forward.
  • Rather than a public-facing website, our system relies on the Web as a content management platform—of course a public face could easily be added.
  • The final piece of our puzzle, the ability to integrate print production, was made possible by Adobe's release of InDesign with an open XML file format. Since the Web's XHTML is also XML, is can be easily and confidently transformed to the InDesign format.
  • today, we are able to put the process together using nothing but standard, relatively ubiquitous Web tools: the Web itself as an editing and content management environment, standard Web scripting tools for the conversion process, and the well-documented IDML file format to integrate the layout tool.
  • Using the Web as a Production Platform
  • Gary Edwards on 07 Nov 13
     
    I was looking for an answer to a problem Marbux had presented, and found this interesting article.  The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format. My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML.  From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS. Researching the problems one might encounter with this approach, I found this article.  Fascinating stuff. My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML.  Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. The important point though is that XHTML is a browser specific version of XML, and compatible with the Web Kit layout engine Miro wants to move NCP to. The concept of encoding an existing application-specific format in XML has been around since 1998, when XML was first introduced as a W3C standard, a "structured" subset of SGML. (HTML is also a subset of SGML). The multiplatform StarOffice productivity suite became "OpenOffice" when Sun purchased the company in 1998, and open sourced the code base. The OpenOffice developer team came out with a XML encoding of their existing document formats in 2000. The application specific encoding became an OASIS document format standard proposal in 2002 - also known as ODF. Microsoft followed OpenOffice with a XML encoding of their application-specific binary document formats, known as OOXML. Encoding the existing NCP format in XML, specifically targeting XHTML as a "universal pivot point", would put the NCP Outliner in the Web editor category, without breaking backwards compatibility. The trick is in the XSLT conversion process. But I think that is something much easier to handle then trying to
  • Gary Edwards on 07 Nov 13
     
    I was looking for an answer to a problem Marbux had presented, and found this interesting article.  The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format. My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML.  From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS. Researching the problems one might encounter with this approach, I found this article.  Fascinating stuff. My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML.  Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. The important point though is that XHTML is a browser specific version of XML, and compatible with the Web Kit layout engine Miro wants to move NCP to. The concept of encoding an existing application-specific format in XML has been around since 1998, when XML was first introduced as a W3C standard, a "structured" subset of SGML. (HTML is also a subset of SGML). The multiplatform StarOffice productivity suite became "OpenOffice" when Sun purchased the company in 1998, and open sourced the code base. The OpenOffice developer team came out with a XML encoding of their existing document formats in 2000. The application specific encoding became an OASIS document format standard proposal in 2002 - also known as ODF. Microsoft followed OpenOffice with a XML encoding of their application-specific binary document formats, known as OOXML. Encoding the existing NCP format in XML, specifically targeting XHTML as a "universal pivot point", would put the NCP Outliner in the Web editor category, without breaking backwards compatibility. The trick is in the XSLT conversion process. But I think that is something much easier to handle then trying to
Gary Edwards

Duke Engines' incredibly compact, lightweight valveless axial engine - 0 views

www.gizmag.com/...33631

Duke-Axial-engine energy

shared by Gary Edwards on 03 Sep 14 - No Cached
  • The Duke engine is an axial design, meaning that its five cylinders encircle the drive shaft and run parallel with it. The pistons drive a star-shaped reciprocator, which nutates around the drive shaft, kind of like a spinning coin coming to rest on a table.
  • The reciprocator's center point is used to drive the central drive shaft, which rotates in the opposite direction to the reciprocator. "That counter-rotation keeps it in tidy balance," says Duke co-founder John Garvey. "If you lay your hand on it while it's running, you can barely detect any motion at all, it's quite remarkable." That's borne out by the video below, where the engine revving doesn't even cause enough vibrations to tip a coin off its side.
  • Instead of cam- or pneumatically-operated intake and outlet valves, the cylinders rotate past intake and outlet ports in a stationary head ring. The spark plugs are also mounted in this stationary ring – the cylinders simply slide past each port or plug at the stage of the cycle it's needed for and move on. In this way, Duke eliminates all the complexity of valve operation and manages to run a five-cylinder engine with just three spark plugs and three fuel injectors. The Duke engine ends up delivering as many power strokes per revolution as a six cylinder engine, but with huge weight savings and a vast reduction in the number of engine parts.
  • ...1 more annotation...
  • The engine has shown excellent resistance to pre-ignition (or detonation) – potentially because its cylinders tend to run cooler than comparable engines. Duke has run compression ratios as high as 14:1 with regular 91-octane gasoline. This suggests that further developments will pull even more power out of a given amount of fuel, increasing the overall efficiency of the unit.
  • Gary Edwards on 03 Sep 14
     
    Watch the second video! This is extraordinary. "New Zealand's Duke Engines has been busy developing and demonstrating excellent results with a bizarre axial engine prototype that completely does away with valves, while delivering excellent power and torque from an engine much smaller, lighter and simpler than the existing technology. We spoke with Duke co-founder John Garvey to find out how the Duke Axial Engine project is going."
Gary Edwards

The Grand Convergence: Web + RIA + Widgets + Client/Server - 0 views

ajax.sys-con.com/516151

ria webkit air silverlight widgets

shared by Gary Edwards on 06 Nov 08 - Cached
  • he architecture of the Widget engine divides the client technology into two parts, the engine and the widgets. The widget engine is usually a pretty large download.
  • The widget engine is really a wonderful architecture that gives you the power of the desktop (via the widget engine) and the management of the Web (via widget downloads).  Widget engines can out-perform RIA solutions and they can store larger data sets. 
  • Fit Client applications can be centrally managed, yet remain resident on the desktop. They can offer access to standard web content (e.g. HTML) without the need of a browser. Fit Clients can leverage the processing power and disc space of the client machine, but they can also offer more restrictive and secure environments than client/server platforms.
  • Gary Edwards on 06 Nov 08
     
    Excellent overview of where applications are going. Richard Monson-Haefel, (whom i met at the 2008 Web 2.0 Conference) explains the convergence of four emerging application models: Web Clients (Browsers), RiA Clients, Client/Server, and Widget Engines. He comes up with a convergence point called "Fit Client", offering Adobe Air as the leading example. Richard walks through each application model, discussing limitations and advantages. Good stuff, especially this comment: "The widget engine is really a wonderful architecture that gives you the power of the desktop (via the widget engine) and the management of the Web (via widget downloads).  Widget engines can out-perform RIA solutions and they can store larger data sets.    The limitation of Widget engines is not in their architecture, it is that they have been designed for applications with fairly weak capabilities compared to client/server. Widgets tend to be single-purpose applications with limited access to the native operating system. That said, the widget architecture itself - the separation of the platform from the applications - is important. It makes it possible to create applications (widgets) that are portable across operating systems and are packaged for easy download and installation. "
Gonzalo San Gil, PhD.

GM45 chipsets: remove the ME (manageability engine) - 0 views

libreboot.org/...gm45_remove_me.html

remove ME manageability engine GM45 chipset open tech

shared by Gonzalo San Gil, PhD. on 04 Mar 16 - No Cached
  • Gonzalo San Gil, PhD. on 04 Mar 16
     
    "This sections relates to disabling and removing the ME (Intel Management Engine) on GM45. This was originally done on the ThinkPad X200, and later adapted for the ThinkPad R400/T400/T500. It can in principle be done on any GM45 or GS45 system. The ME is a blob that typically must be left inside the flash chip (in the ME region, as outlined by the default descriptor). On GM45, it is possible to remove it without any ill effects. All other parts of coreboot on GM45 systems (provided GMA MHD4500 / Intel graphics) can be blob-free, so removing the ME was the last obstacle to make GM45 a feasible target in libreboot (the systems can also work without the microcode blobs). "
  • Gonzalo San Gil, PhD. on 04 Mar 16
     
    "This sections relates to disabling and removing the ME (Intel Management Engine) on GM45. This was originally done on the ThinkPad X200, and later adapted for the ThinkPad R400/T400/T500. It can in principle be done on any GM45 or GS45 system. The ME is a blob that typically must be left inside the flash chip (in the ME region, as outlined by the default descriptor). On GM45, it is possible to remove it without any ill effects. All other parts of coreboot on GM45 systems (provided GMA MHD4500 / Intel graphics) can be blob-free, so removing the ME was the last obstacle to make GM45 a feasible target in libreboot (the systems can also work without the microcode blobs). "
Gonzalo San Gil, PhD.

Midori in Launchpad - 0 views

launchpad.net/midori

join midori suggestiontester beta beta-testers browser code freenode

shared by Gonzalo San Gil, PhD. on 28 Feb 15 - No Cached
  • Gonzalo San Gil, PhD. on 28 Feb 15
     
    [ # Join #midori on irc.freenode.net for discussions about bugs and development. Project statistics: https://www.ohloh.net/p/midori # Midori is a fast and lightweight web browser that uses the WebKit rendering engine and the GTK+ interface. Midori is a fast little WebKit browser with support for HTML5. It can manage many open tabs and windows. The URL bar completes history, bookmarks, search engines and open tabs out of the box. Web developers can use the powerful web inspector that is a part of WebKit. Individual pages can easily be turned into web apps and new profiles can be created on demand. A number of extensions are included by default: * Adblock with support for ABP filter lists and custom rules is built-in. * You can download files with Aria2 or SteadyFlow. * User scripts and styles support a la Greasemonkey. * Managing cookies and scripts via NoJS and Cookie Security Manager. * Switching open tabs in a vertical panel or a popup window.]
Gary Edwards

Under the Covers: Alfresco's SharePoint Services (WSS) Killer - 0 views

www.cmswire.com/...services-wss-killer-004004.php

sharepoint alfresco wiki-Word collaboration MOSS

shared by Gary Edwards on 26 Feb 09 - Cached
Rechal Morin liked it
  • Gary Edwards on 26 Feb 09
     
    Reverse engineering the MS Office SharePoint Protocol: CMSwire has a good review of Alfresco's latest feature, the repurposing of MSOffice as an editing and collaboration front end for the Alfresco Open Web Content Management System.
    Microsoft ha sof course been very busy re-purposing MSOffice as a front end editor - shared collaboration space for their own MOSS WebStack - CMS. Thanks to the EU, Microsoft was forced to publicly disclose integration and interop methods used to wire together MOSS. Alfresco seized the disclosure to create their own re-purposing.
    IMHO, this is exactly how the Microsoft monopoly needs to be cracked. Instead of replacing MSOffice at great cost and disruption to business users, tap into the same re-purposing methods Microsoft uses as they try to shift that monopoly center from the desktop to a proprietary MS Web.
    "... The Office SharePoint Protocol is one of the big achievements that Alfresco has come out with to sell Alfresco Share as a true viable alternative to SharePoint in the enterprise....
    "... Microsoft Office is still the most widely used productivity suite in organizations today. That's a huge reason why SharePoint has been so successful - Microsoft created a protocol to enable Office to interact directly with SharePoint. This means you don't have to leave the discomfort of our Office application to create, edit and manage documents and calendar events in SharePoint." For Alfresco, the break came when Microsoft released a number of technical specifications to the public (including the spec for SharePoint 2007) in the name of interoperability. Alfresco used this information to implement the Office and SharePoint protocols as a compatible server - thus the same functionality users get working between Office and SharePoint, they can now also get natively with Office and Alfresco.
Gary Edwards

Official Google Webmaster Central Blog: Introducing Rich Snippets - 0 views

googlewebmastercentral.blogspot.com/...introducing-rich-snippets.html

rdfa rich-snippets google html5 odf ooxml w3c

shared by Gary Edwards on 17 May 09 - Cached
  • Gary Edwards on 17 May 09
     
    Google "Rich Snippets" is a new presentation of HTML snippets that applies Google's algorithms to highlight structured data embedded in web pages. Rich Snippets give end-users convenient summary information about their search results at a glance. Google is currently supporting a very limited subset of data about reviews and people. When searching for a product or service, users can easily see reviews and ratings, and when searching for a person, they'll get help distinguishing between people with the same name. It's a simple change to the display of search results, yet our experiments have shown that users find the new data valuable. For this to work though, both Web-masters and Web-workers have to annotate thier pages with structured data in a standard format. Google snippets supports microformats and RDFa. Existing Web data can be wrapped with some additional tags to accomplish this. Notice that Google avoids mention of RDF and the W3C's vision of a "Semantic Web" where Web objects are fully described in machine readable semantics. Over at the WHATWG group, where work on HTML5 continues, Google's Ian Hickson has been fighting RDFa and the Semantic Web in what looks to be an effort to protect the infamous Google algorithms. RDFa provides a means for Web-workers, knowledge-workers, line-of-business managers and document generating end-users to enrich their HTML+ with machine semantics. The idea being that the document experts creating Web content can best describe to search engine and content management machines the objects-of-information used. The google algorithms provide a proprietary semantics of this same content. The best solution to the tsunami of conten the Web has wrought would be to combine end-user semantic expertise with Google algorithms. Let's hope Google stays the RDFa course and comes around to recognize the full potential of organizing the world's information with the input of content providers. One thing the world desperatel
Gonzalo San Gil, PhD.

Mozilla restarts work on multi-process Firefox | InfoWorld - 0 views

www.infoworld.com/...-on-multi-process-firefox.html

e10s Electrolysis mozilla firefox multi-process

shared by Gonzalo San Gil, PhD. on 17 Jun 15 - No Cached
  • Gonzalo San Gil, PhD. on 17 Jun 15
     
    "After years of spinning its wheels, Mozilla recently stepped up work on separating page rendering from content in Firefox to make the browser more secure and more stable. Dubbed Electrolysis, or "e10s" for short, Mozilla's attempt to bring multiple processes to Firefox got a shot in the arm last month when Chris Peterson, an engineering program manager with the open-source developer, announced that the team working on the project had been expanded."
Paul Merrell

Internet Archive: Scanning Services - 1 views

archive.org/v2

Web Internet-Archives digtizing-print-services

shared by Paul Merrell on 01 Feb 15 - No Cached
  • Digitizing Print Collections with the Internet Archive Open and free online access, permanent storage, unlimited downloads and lifetime file management. We can help digitize your collections in 4 simple steps:
  • In addition to permanent hosting on archive.org, your books will be integrated with Open Library, openlibrary.org, a page on the web for every book.
  • Non-destructive color scanning using our Scribe system at one of our scanning centers across the globe. Complete MARC records, Dublin Core & XML, just 10c USD per image and a small set up charge per item.
  • ...4 more annotations...
  • Create and upload high-quality JP2000 images; persistent identifiers, lifetime hosting of files, lifetime management of file system and file access.
  • Create high quality PDF A files; run OCR across texts to allow "search inside" all books. Add to Internet Archive search engine; display via our open source Book Reader
  • 2,000,000 books online 600 million pages scanned 1,500 book scanned each day 15 million downloads each month 33 scanning centers in 7 countries 3.5 petabytes of storage 8 Gb per second bandwidth
  • Library of Congress Harvard University The New York Public Library Smithsonian Institution The Getty Research Institute University of California University of Toronto Biodiversity Heritage Library Boston Library Consortium C.A.R.L.I. Johns Hopkins University Allen County Public Library Lyrasis Massachusetts Institute of technology State Library of Massachusetts . . . and over 1,000 other Open Content Alliance partners
  • Paul Merrell on 01 Feb 15
     
    I've been looking for a permanent online home for a couple of historical works I co-authored. My guidiing criterion has been the best chance of the works' long-term survival in a publicly-accessible form after my death. I think I may have just found my solution. 
Paul Merrell

We finally gave Congress email addresses - Sunlight Foundation Blog - 0 views

sunlightfoundation.com/...-gave-congress-email-addresses

U.S. Congress email

shared by Paul Merrell on 18 Jun 14 - No Cached
  • On OpenCongress, you can now email your representatives and senators just as easily as you would a friend or colleague. We've added a new feature to OpenCongress. It's not flashy. It doesn't use D3 or integrate with social media. But we still think it's pretty cool. You might've already heard of it. Email. This may not sound like a big deal, but it's been a long time coming. A lot of people are surprised to learn that Congress doesn't have publicly available email addresses. It's the number one feature request that we hear from users of our APIs. Until recently, we didn't have a good response. That's because members of Congress typically put their feedback mechanisms behind captchas and zip code requirements. Sometimes these forms break; sometimes their requirements improperly lock out actual constituents. And they always make it harder to email your congressional delegation than it should be.
  • This is a real problem. According to the Congressional Management Foundation, 88% of Capitol Hill staffers agree that electronic messages from constituents influence their bosses' decisions. We think that it's inappropriate to erect technical barriers around such an essential democratic mechanism. Congress itself is addressing the problem. That effort has just entered its second decade, and people are feeling optimistic that a launch to a closed set of partners might be coming soon. But we weren't content to wait. So when the Electronic Frontier Foundation (EFF) approached us about this problem, we were excited to really make some progress. Building on groundwork first done by the Participatory Politics Foundation and more recent work within Sunlight, a network of 150 volunteers collected the data we needed from congressional websites in just two days. That information is now on Github, available to all who want to build the next generation of constituent communication tools. The EFF is already working on some exciting things to that end.
  • But we just wanted to be able to email our representatives like normal people. So now, if you visit a legislator's page on OpenCongress, you'll see an email address in the right-hand sidebar that looks like Sen.Reid@opencongress.org or Rep.Boehner@opencongress.org. You can also email myreps@opencongress.org to email both of your senators and your House representatives at once. The first time we get an email from you, we'll send one back asking for some additional details. This is necessary because our code submits your message by navigating those aforementioned congressional webforms, and we don't want to enter incorrect information. But for emails after the first one, all you'll have to do is click a link that says, "Yes, I meant to send that email."
  • ...1 more annotation...
  • One more thing: For now, our system will only let you email your own representatives. A lot of people dislike this. We do, too. In an age of increasing polarization, party discipline means that congressional leaders must be accountable to citizens outside their districts. But the unfortunate truth is that Congress typically won't bother reading messages from non-constituents — that's why those zip code requirements exist in the first place. Until that changes, we don't want our users to waste their time. So that's it. If it seems simple, it's because it is. But we think that unbreaking how Congress connects to the Internet is important. You should be able to send a call to action in a tweet, easily forward a listserv message to your representative and interact with your government using the tools you use to interact with everyone else.
Paul Merrell

Utah lawmaker questions city water going to NSA - 0 views

www.rgj.com/...19438569

surveillance state NSA Bluffdale water data privacy

shared by Paul Merrell on 24 Nov 14 - No Cached
  • SALT LAKE CITY – A Utah lawmaker concerned about government spying on its citizens is questioning whether city water service should be cut off to a massive National Security Agency data storage facility outside Salt Lake City.Republican Rep. Marc Roberts, of Santaquin, said there are serious questions about privacy and surveillance surrounding the center, and several Utah residents who spoke at a legislative committee hearing Wednesday agreed.During the last legislative session, lawmakers opted to hold off on Roberts' bill to shut off the facility's water and decided to study it during the interim."This is not a bill just about a data center. This is a bill about civil rights," web developer Joe Levi said. "This is a bill that needs to be taken up and needs to be taken seriously."Pete Ashdown, founder of Salt Lake City-based Internet provider XMission, called the center a stain upon the state and its technology industry. "I do encourage you to stand up and do something about it," he said.Lawmakers said they aren't considering shutting down $1.7 billion facility, but the committee chair acknowledged the concerns and said there might be another way to get the point across. "We may look at some type of a strong message to give our representatives to take back to Congress," said Republican Sen. David Hinkins, of Orangeville.
  • The NSA's largest data storage center in the U.S. was built in Utah over 37 other locations because of open land and cheap electricity. The center sits on a National Guard base about 25 miles south of Salt Lake City in the town of Bluffdale.NSA officials said the center is key to protecting national security networks and allowing U.S. authorities to watch for cyber threats. Beyond that, the agency has offered few details.The center attracted much discussion and concern after revelations last year that the NSA has been collecting millions of U.S. phone records and digital communications stored by major Internet providers.
  • Cybersecurity experts say the nondescript Utah facility is a giant storehouse for phone calls, emails and online records that have been secretly collected.Outside the computer storehouses are large coolers that keep the machines from overheating. The coolers use large amounts of water, which the nearby city of Bluffdale sells to the center at a discounted rate.City records released earlier this year showed monthly water use was much less than the 1 million gallons a day that the U.S. Army Corps of Engineers predicted the center would need, causing some to wonder if the center was fully operational.NSA officials have refused to say if the center is up and running after its scheduled opening in October 2013 was stalled by electrical problems.City utility records showed the NSA has been making monthly minimum payments of about $30,000 to Bluffdale. The city manager said that pays for more water than the center used.The state of Nevada shut off water to the site of the proposed Yucca Mountain nuclear waste dump 90 miles northwest of Las Vegas in 2002, after months of threats.The project didn't run dry because the Energy Department built a 1-million-gallon tank and a small well for the site. Department officials said the stored water, plus 400,000 gallons stored in other tanks at the Nevada Test Site, provided time for scientists to continue experiments and design work at the site.
  • ...1 more annotation...
  • SALT LAKE CITY – A Utah lawmaker concerned about government spying on its citizens is questioning whether city water service should be cut off to a massive National Security Agency data storage facility outside Salt Lake City.Rep
  • Paul Merrell on 24 Nov 14
     
    Hey, go for their electricity too! But what do we do with the Bluffdale facility after we abolish the NSA? Turn it over to Internet Archives, with a $1 billion endowment for maintenance? Free and permanent web sites for everyone?  
Paul Merrell

U.S. military closer to making cyborgs a reality - CNNPolitics.com - 0 views

edition.cnn.com/...index.html

surveillance state cyborgs

shared by Paul Merrell on 10 Mar 16 - No Cached
  • The U.S. military is spending millions on an advanced implant that would allow a human brain to communicate directly with computers.If it succeeds, cyborgs will be a reality.The Pentagon's research arm, the Defense Advanced Research Projects Agency (DARPA), hopes the implant will allow humans to directly interface with computers, which could benefit people with aural and visual disabilities, such as veterans injured in combat.The goal of the proposed implant is to "open the channel between the human brain and modern electronics" according to DARPA's program manager, Phillip Alvelda.
  • DARPA sees the implant as providing a foundation for new therapies that could help people with deficits in sight or hearing by "feeding digital auditory or visual information into the brain."A spokesman for DARPA told CNN that the program is not intended for military applications.
  • But some experts see such an implant as having the potential for numerous applications, including military ones, in the field of wearable robotics -- which aims to augment and restore human performance.Conor Walsh, a professor of mechanical and biomedical engineering at Harvard University, told CNN that the implant would "change the game," adding that "in the future, wearable robotic devices will be controlled by implants."Walsh sees the potential for wearable robotic devices or exoskeletons in everything from helping a medical patient recover from a stroke to enhancing soldiers' capabilities in combat.The U.S. military is currently developing a battery-powered exoskeleton, the Tactical Assault Light Operator Suit, to provide superior protection from enemy fire and in-helmet technologies that boost the user's communications ability and vision.The suits' development is being overseen by U.S. Special Operations Command.In theory, the proposed neural implant would allow the military member operating the suit to more effectively control the armored exoskeleton while deployed in combat.
  • ...1 more annotation...
  • In its announcement, DARPA acknowledged that an implant is still a long ways away, with breakthroughs in neuroscience, synthetic biology, low-power electronics, photonics and medical-device manufacturing needed before the device could be used.DARPA plans to recruit a diverse set of experts in an attempt to accelerate the project's development, according to its statement announcing the project.
  • Paul Merrell on 10 Mar 16
     
    Let's assume for the moment that DARPA's goal is realizable and brain implants for commuication with computers become common. How long will it take for FBI, NSA, et ilk to get legislation or a court order allowing them to conduct mass surveillance of people's brains? Not long, I suspect. 
1 - 12 of 12
Showing 20▼ items per page