Department of Chemistry

...California State University Stanislaus

  • Increase font size
  • Default font size
  • Decrease font size
Home News Feeds Planet Ubuntu
Newsfeeds
Planet Ubuntu
Planet Ubuntu - http://planet.ubuntu.com/

  • Stephen Kelly: Grantlee 0.5.0 (codename Auf 2 Hochzeiten tanzen) now available

    The Grantlee community is pleased to announce the release of Grantlee version 0.3 (Mirror). Source and binary compatibility are maintained as with all previous releases. Django is an implementation of the Django template system in Qt.

    This release builds with both Qt 5 and Qt 4. The Qt 5 build is only for transitional purposes so that a downstream can get their own code built and working with Qt 5 without being first blocked by Grantlee backward incompatible changes. The Qt 5 based version of Grantlee 0.5.0 should not be relied upon as a stable interface. It is only there to assist porting. There won’t be any more Qt 4 based releases, except to fix build issues if needed.

    The next release of Grantlee will happen next week and will be exclusively Qt 5 based. It will have a small number of backward incompatible changes, such as adding missing const and dropping some deprecated stuff.

    The minimum CMake required has also been increased to version 2.8.11. This release contains most of the API for usage requirements and so allows cleaning up a lot of older CMake code.

    Also in this release is a small number of new bug fixes and memory leak plugs etc.




  • Daniel Pocock: reSIProcate migration from SVN to Git completed

    This week, the reSIProcate project completed the move from SVN to Git.

    With many people using the SIP stack in both open source and commercial projects, the migration was carefully planned and tested over an extended period of time. Hopefully some of the experience from this migration can help other projects too.

    Previous SVN committers were tracked down using my script for matching emails to Github accounts. This also allowed us to see their recent commits on other projects and see how they want their name and email address represented when their previous commits in SVN were mapped to Git commits.

    For about a year, the sync2git script had been run hourly from cron to maintain an official mirror of the project in Github. This allowed people to test it and it also allowed us to start using some Github features like travis-CI.org before officially moving to Git.

    At the cut-over, the SVN directories were made read-only, sync2git was run one last time and then people were advised they could commit in Git.

    Documentation has also been created to help people get started quickly sharing patches as Github pull requests if they haven't used this facility before.



  • Ronnie Tucker: Curl Exploits Closed in All Supported Ubuntu OSes

    Canonical has announced that a couple of curl vulnerabilities have been found and fixed in its Ubuntu 14.04 LTS, Ubuntu 12.04 LTS, and Ubuntu 10.04 LTS operating systems.

    The developers have released a new update for the curl package and it looks like a number of security issues have been corrected.

    “Tim Ruehsen discovered that curl incorrectly handled partial literal IP addresses. This could lead to the disclosure of cookies to the wrong site, and malicious sites being able to set cookies for others,” reads the security notice.

    Source:

    http://news.softpedia.com/news/Curl-Exploits-Close-in-All-Supported-Ubuntu-OSes-458899.shtml

    Submitted by: Silviu Stahie



  • Stuart Langridge: Fundamentally connected

    Aaron Gustafson recently wrote a very interesting monograph bemoaning a recent trend to view JavaScript as “a virtual machine in the browser”. I’ll quote fairly extensively, because Aaron makes some really strong points here, and I have a lot of sympathy with them. But at bottom I think he’s wrong, or at the very least he’s looking at this question from the wrong direction, like trying to divine the purpose of the Taj Mahal by looking at it from underneath.

    The one problem I’ve seen,” says Aaron, “is the fundamental disconnect many of these developers [who began taking JavaScript seriously after Ajax became popular] seem to have with the way deploying code on the Web works. In traditional software development, we have some say in the execution environment. On the Web, we don’t.” He goes on to explain: “If we’re writing server-side software in Python or Rails or even PHP, … we control the server environment [or] we have knowledge of it and can author… accordingly”, and “in the more traditional installed software world, we can similarly control the environment by placing certain restrictions on what operating systems our code can run on”.

    I believe that this criticism, while essentially valid, misapprehends the real case here. It underestimates the universality of JavaScript implementations, it overestimates the stability of old-fashioned software development, and most importantly it starts from the presumption that building things for one particular computer is actually a good idea. Which it isn’t.

    Now, nobody is arguing that the web environment is occasionally challengingly different across browsers and devices. But a lot of it isn’t. No browser ships with a JavaScript implementation in which 1 and 1 add to make 3, or in which Arrays don’t have a length property, or in which the for keyword doesn’t exist. If we ignore some of the Mozilla-specific stuff which is becoming ES6 (things such as array comprehensions, which nobody is actually using in actual live code out there in the universe), JavaScript is pretty stable and pretty unchanging across all its implementations. Of course, what we’re really talking about here is the DOM model, not JavaScript-the-language, and to claim that “JavaScript can be the virtual machine” and then say “aha I didn’t mean the DOM” is sophistry on a par with a child asking “can I not not not not not have an ice-cream?”. But the DOM model is pretty stable too, let’s be honest. In things I build, certainly I find myself in murky depths occasionally with JavaScript across different browsers and devices, but those depths are as the sparkling waters of Lake Treviso by comparison with CSS across different browsers. In fact, when CSS proves problematic across browsers, JavaScript is the bandage used to fix it and provide a consistent experience — your keyframed CSS animation might be unreliable, but jQuery plugins work everywhere. JavaScript is the glue that binds the other bits together.

    Equally, I am not at all sold that “we have knowledge of [the server environment] and can author your program accordingly so it will execute as anticipated” when doing server development. Or, at least, that’s possible, but nobody does. If you doubt this, I invite you to go file a bug on any server-side app you like and say “this thing doesn’t work right for me” and then add at the bottom “oh, and I’m running FreeBSD, not Ubuntu”. The response will occasionally be “oh really? we had better get that fixed then!” but is much more likely to be “we don’t support that. Use Ubuntu and this git repository.” Now, that’s a valid approach — we only support this specific known configuration! — but importantly, on the web Aaron sees requiring a specific browser/OS combination as an impractical impossibility and the wrong thing to do, whereas doing this on the server is positively virtuous. I believe that this is no virtue. Dismissing claims of failure with “well, you should be using the environment I demand” is just as large a sin on the server or the desktop as it is in the browser. You, the web developer, can’t require that I use your choice of browser, but equally you, the server developer, shouldn’t require that I use your particular exact combination of server packages either. Why do client users deserve more respect than server users? If a developer using your server software should be compelled to go and get a different server, how’s that different from asking someone to install a different web browser? Sure, I’m not expecting someone who built a server app running on Linux to necessarily also make it run on Windows (although wise developers will do so), but then I’m not really expecting someone who’s built a 3d game with WebGL to make the experience meaningful for someone browsing with Lynx, either.

    Perhaps though you differ there, gentle reader. That the web is the web, and one should have a meaningful experience (although importantly not necessarily the same meaningful experience) which ever class of browser and device and capability one uses to get at the web. That is a very good point, one with which I have a reasonable amount of sympathy, and it leads me on to the final part of the argument.

    It is this. Web developers are actually better than non-web developers. And Aaron explains precisely why. It is because to build a great web app is precisely to build a thing which can be meaningfully experienced by people on any class of browser and device and capability. The absolute tip-top very best “native” app can only be enjoyed by those to whom it is native. “Native apps” are poetry: undeniably beautiful when done well, but useless if you don’t speak the language. A great web app, on the other hand, is a painting: beautiful to experience and available to everybody. The Web has trained its developers to attempt to build something that is fundamentally egalitarian, fundamentally available to everyone. That’s why the Web’s good. The old software model, of something which only works in one place, isn’t the baseline against which the Web should be judged; it’s something that’s been surpassed. Software development is easiest if it only has to work on your own machine, but that doesn’t mean that that’s all we should aim for. We’re all still collaboratively working out exactly how to build apps this way. Do we always succeed? No. But by any measure the Web is the largest, most widely deployed, most popular and most ubiquitous computing platform the world has ever known. And its programming language is JavaScript.



  • Paul Tagliamonte: Docker PostgreSQL Foreign Data Wrapper

    For the tl;dr: Docker FDW is a thing. Star it, hack it, try it out. File bugs, be happy. If you want to see what it's like to read, there's some example SQL down below.

    The question is first, what the heck is a PostgreSQL Foreign Data Wrapper? PostgreSQL Foreign Data Wrappers are plugins that allow C libraries to provide an adaptor for PostgreSQL to talk to an external database.

    Some folks have used this to wrap stuff like MongoDB, which I always found to be hilarous (and an epic hack).

    Enter Multicorn

    During my time at PyGotham, I saw a talk from Wes Chow about something called Multicorn. He was showing off some really neat plugins, such as the git revision history of CPython, and parsed logfiles from some stuff over at Chartbeat. This basically blew my mind.

    All throughout the talk I was coming up with all sorts of things that I wanted to do -- this whole library is basically exactly what I've been dreaming about for years. I've always wanted to provide a SQL-like interface into querying API data, joining data cross-API using common crosswalks, such as using Capitol Words to query for Legislators, and use the bioguide ids to JOIN against the congress api to get their Twitter account names.

    My first shot was to Multicorn the new Open Civic Data API I was working on, chuckled and put it aside as a really awesome hack.

    Enter Docker

    It wasn't until tianon connected the dots for me and suggested a Docker FDW did I get really excited. Cue a few hours of hacking, and I'm proud to say -- here's Docker FDW.

    Currently it only implements reading from the API, but extending this to allow for SQL DELETE operations isn't out of the question, and likely to be implemented soon. This lets us ask all sorts of really interesting questions out of the API, and might even help folks writing webapps avoid adding too much Docker-aware logic.

    Setting it up

    I'm going to assume you have a working Multicorn, PostgreSQL and Docker setup (including adding the postgres user to the docker group)

    So, now let's pop open a psql session. Create a database (I called mine dockerfdw, but it can be anything), and let's create some tables.

    Before we create the tables, we need to let PostgreSQL know where our objects are. This takes a name for the server, and the Python importable path to our FDW.

    CREATE SERVER docker_containers FOREIGN DATA WRAPPER multicorn options (
        wrapper 'dockerfdw.wrappers.containers.ContainerFdw');
    
    CREATE SERVER docker_image FOREIGN DATA WRAPPER multicorn options (
        wrapper 'dockerfdw.wrappers.images.ImageFdw');
    

    Now that we have the server in place, we can tell PostgreSQL to create a table backed by the FDW by creating a foreign table. I won't go too much into the syntax here, but you might also note that we pass in some options - these are passed to the constructor of the FDW, letting us set stuff like the Docker host.

    CREATE foreign table docker_containers (
        "id"          TEXT,
        "image"       TEXT,
        "name"        TEXT,
        "names"       TEXT[],
        "privileged"  BOOLEAN,
        "ip"          TEXT,
        "bridge"      TEXT,
        "running"     BOOLEAN,
        "pid"         INT,
        "exit_code"   INT,
        "command"     TEXT[]
    ) server docker_containers options (
        host 'unix:///run/docker.sock'
    );
    
    
    CREATE foreign table docker_images (
        "id"              TEXT,
        "architecture"    TEXT,
        "author"          TEXT,
        "comment"         TEXT,
        "parent"          TEXT,
        "tags"            TEXT[]
    ) server docker_image options (
        host 'unix:///run/docker.sock'
    );
    

    And, now that we have tables in place, we can try to learn something about the Docker containers. Let's start with something fun - a join from containers to images, showing all image tag names, the container names and the ip of the container (if it has one!).

    SELECT docker_containers.ip, docker_containers.names, docker_images.tags
      FROM docker_containers
      RIGHT JOIN docker_images
      ON docker_containers.image=docker_images.id;
    
         ip      |            names            |                  tags                   
    -------------+-----------------------------+-----------------------------------------
                 |                             | {ruby:latest}
                 |                             | {paultag/vcs-mirror:latest}
                 | {/de-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
                 | {/ny-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
                 | {/ar-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
     172.17.0.47 | {/ms-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
     172.17.0.46 | {/nc-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
                 | {/ia-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
                 | {/az-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
                 | {/oh-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
                 | {/va-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
     172.17.0.41 | {/wa-openstates-to-ocd}     | {sunlightlabs/scrapers-us-state:latest}
                 | {/jovial_poincare}          | {<none>:<none>}
                 | {/jolly_goldstine}          | {<none>:<none>}
                 | {/cranky_torvalds}          | {<none>:<none>}
                 | {/backstabbing_wilson}      | {<none>:<none>}
                 | {/desperate_hoover}         | {<none>:<none>}
                 | {/backstabbing_ardinghelli} | {<none>:<none>}
                 | {/cocky_feynman}            | {<none>:<none>}
                 |                             | {paultag/postgres:latest}
                 |                             | {debian:testing}
                 |                             | {paultag/crank:latest}
                 |                             | {<none>:<none>}
                 |                             | {<none>:<none>}
                 | {/stupefied_fermat}         | {hackerschool/doorbot:latest}
                 | {/focused_euclid}           | {debian:unstable}
                 | {/focused_babbage}          | {debian:unstable}
                 | {/clever_torvalds}          | {debian:unstable}
                 | {/stoic_tesla}              | {debian:unstable}
                 | {/evil_torvalds}            | {debian:unstable}
                 | {/foo}                      | {debian:unstable}
    (31 rows)
    

    Success! This is just a taste of what's to come, so please feel free to hack on Docker FDW, tweet me @paultag, file bugs / feature requests. It's currently a bit of a hack, and it's something that I think has long-term potential after some work goes into making sure that this is a rock solid interface to the Docker API.