Open-source library of componetns being built

Just thought I'd chime in with a project I am working on when time allows. I am sure there are others out there, but I am doing this for a couple reasons. First, I find as I work on some components I'd like to see, I am learning how to use Swing more. There are times when I copy/paste some code from tutorial examples, then modify it to my liking. Second, I am working on a pluggable Swing based UI framework application that I am hoping to release into alpha in a few months, built around my plugin engine that is similar to the eclipse engine in how it works. I am seeing more and more Eclipse RCP applications using SWT being built or being talked about, and I believe the majority of GUI developers for Java are still using Swing, and in my opinion should continue to do so. As such, I hope to provide a very capable, robust GUI application framework that can run out of the box as an empty shell ready to take on plugins. Developers will use not only the plugin capability to quickly add dynamic features to an application, but plugins will make full use of "core" plugins (help facility, preferences panel, file chooser dialog, email/ftp services, web services, ejb services, jmx connectors, etc), as well as make use of the many widgets I plan to add (along with some others) with this library.
I am working on several components initially. Some of them I am not sure yet that I can use, as I have taken source from examples and will need to get author permission to modify them and make them available. The library should be LGPL or BSD licensed. I have not yet got a library put together of the components. I thus far have a tree check box, list check box, rounded panels with gradient shadowing and outlining, drag and drop library that you can set the source and target components (or several), provide various types of data to be draggable between them, and the use of compositing the drag image to give it a ghost like appearance, wizard component, taskview (outlook style slidable bars), status bar, a dynamic toolbar that functions like the Mac OS X main bar, where when you mouse over them they can magnify in an animated manner. I am also working on a JFileChooser replacement, one with much more configurable capabilities. For example, when choosing directories, why does JFileChooser not allow you to hide the filename and Files of type fields? You can't make use of them because you are not displaying filenames in the chooser box.
Anyway, the project is at www.sourceforge.net/projects/genpluginengine for the plugin engine, and /projects/theseuswidgets for the component library. Please feel free to join up on the forums/mail lists there, respond here, and help contribute!!
Thanks.

 
Have you looked at HighCharts
or
QuickGraph
UML, then code

Similar Messages

  • Do I need to pay anything to Adobe if I inject java script using some open source library?

    Hello,
    I want to restrict PDF reader to achieve Digital Rights Management (DRM).
    Do I need to pay anything to Adobe if I inject java script to achieve so using some open source library?
    Basically I want my PDF documents to be restricted such that I can: 
    Limit printing
    Prevent screenshots
    Restrict access by license expiry date
    Restrict distribution of downloaded PDF (i.e. the document should run on specific machine only)
    Restrict copy and paste within PDF document
    I came across below links from which I suspect Adobe expects one to pay if he/she attempts to restrict reader functionality in some way?
    http://www.adobe.com/devnet/reader/topic_drm.html
    http://www.adobe.com/devnet/acrobat/overview.html
    Am I correct in my assumption?

    I think it is a vain hope to imagine you could implement DRM via JavaScript. Remember it can be turned off.
    Printing is either enabled or disabled according to document security.
    Working with PDFs does not require permission from Adobe but
    * adding functionality to Adobe Reader definitely does; a DRM development license is a major investment.
    * if the file is Reader-enabled, all third party tools will disable that.

  • EngLab - Open source mathematical/engineering platform

    Hello all,
    I'm new to Archlinux and quite exited with it. Anyway, some colleagues of mine from the University and me have created an engineering platform for the Linux platform, although Windows builds are also available. If you like check it out, but be aware that it's still on an early development stage.
    (I hope this is the right board to post this )
    Website: http://englab.sourceforge.net/
    Now that I am into Arch I'm going to make some research and create a build system for it to run on Arch and with your help maybe enter the AUR.
    Here is our press presentation for the first big release (now we're on 0.2.1alpha):
    We are pleased to inform you that the 0.2alpha release of the open-source program EngLab has been published.
    Our site is located to englab.sourceforge.net . You can download it from https://sourceforge.net/project/showfil … _id=206384
    EngLab is a cross-compile mathematical platform with a C like syntax, intended to be used both by engineers and users with little programming knowledge. The initiative has been taken from a group of students a year ago.
    Our goal is to develop an easy-to-use computaion and simulation platform with a C++ like syntax. We have adopted Matlab's structure philoshophy and C++ 's structured language syntax. There are various toolboxes (packages of functions relative to a certain scientific field), which depend on open-source libraries.
    The EngLab distribution is available in two ways: there are two basic Englab releases, EngLab Console and EngLab GUI. EngLab Console allows EngLab's execution through the console(Linux or Windows). EngLab GUI gives the opportunity of using EngLab through a graphical user interface. EngLab GUI is implemented with the use of  the open-source library wxWidgets 2.8, providing additional usability compared to EngLab Console edition. EngLab GUI is independent, so there is no need for EngLab Console to be installed, in order to properly install and execute EngLab GUI.
    Toolboxes are distributed as seperate packages. Their installation is possible either through EngLab Console or EngLab GUI. The reason is that those toolboxes depend on open-source libraries that have to be previously installed. So as the user not to be forced to install those libraries directly, user can install packages and toolboxes at his/her own will.
    For the time being, EngLab Console edition is available for Windows and Linux and Englab GUI is available for Linux only.
    Until now EngLab has the following features :
    - 16 types of variable declaration (int, float, ...)
    - Variable declaration with unlimited number of dimensions.
    - Loop structures (for, while, ...)
    - Arithmetic, logical and binary operations
    - Constant number declaration (pi, phi, ...)
    - Graphical manipulation of variable values of any dimension (Englab GUI)
    - Adjustable graphical environment (Englab GUI)
    - Editor for writing *.eng functions (Englab GUI)
    - Command history for the last 5 sessions
    - Immediate access to variables, constants and functions (EngLab GUI)
    - Recent files opened through EngLab (EngLab GUI)
    Toolboxes that have been fully or partially implemented:
    - a package containing fundamental functions of C (trigonemetric, hyperbolic trigonometrical, ...)
    - a package containing some statistic functions
    - a package containing functions that allow convertions of the variable type
    All these toolboxes accompany the basic two EngLab editions, since they do not depend on another open-source library. Moreover, some other toolboxes have been partially implemented:
    - a package that contains functions for the manipulation of 2-D matrices (determinant, inverse array, ...). This package depends on the open-source library NewMat10.
    - a package that contains functions for image processing. This package depends on the open-source library CImg.
    - a package that contains functions for image processing. This package depends on the open-source library OpenCV.
    Also, we develop
    - a toolbox for visual data representation(plots etc)
    - a toolbox that contains functins for manipulating polyonymials, root detection, computation of integrals and derivatives, special functions and more.
    Those two toolboxes will be available in the next releases.
    The disadvantage is the number of EngLab developers, which does not allow EngLab's quick development. Thus, helping us would be welcomed.
    You can help us with the following two ways:
    - By reporting bugs, which you have observed during EngLab execution. You can report bugs in https://sourceforge.net/tracker/?group_ … tid=997443 . Moreover, you can suggest new features that would improve EngLab's usability and performance. New features can be suggested in https://sourceforge.net/tracker/?group_ … tid=997446 .
    - If you would like to get more into EngLab, you can become EngLab developers and help us. That requires C++ knowledge.
    If you have read till here, that's a good sign. Wink
    You could ask questions in the mailing list [email protected] or in the forum .
    EngLab development team :
    Bugfest development team :
    Serenis Charalampos - PhD student of the Department of Electrical and Computer Engineering of Aristotle University of Thessaloniki(Greece).
    Tsardoulias Emmanouil - PhD student of the Department of Electrical and Computer  Engineering of Aristotle University of Thessaloniki(Greece).
    Gavves Efstratios - Dipl. Engineer of the Department of Electrical and Computer  Engineering of Aristotle University of Thessaloniki(Greece).
    Parastatidis Nikolas - Postgraduate student of the Department of Electrical  and Computer Engineering of Aristotle University of Thessaloniki(Greece).
    Also contributed:
    Gkekas Christos - Dipl. Engineer of the Department of Electrical and Computer  Engineering of Aristotle University of Thessaloniki(Greece).
    Vogianou Thanassis - PhD student of the Department of Electrical and Computer  Engineering of Aristotle University of Thessaloniki(Greece).

    We are glad to announce that version 0.3 of Englab has been released. The new version contains several bug fixes and improvements in the kernel, a new and advanced GUI based on the Qt toolkit and toolboxes with several functions. Amongst the featured toolboxes are:
    - cimgbox, image processing and manipulation toolbox
    - plotbox, toolbox for plotting graphs and figures
    - dspbox, toolbox for Digital Signal Processing and audio processing
    as dynamic (external) toolboxes and:
    - analogfilters, toolbox for analog filter design
    - unit conversions toolboxes, complex numbers toolbox, polynomials toolbox, stats toolbox etc.
    as static (internal) toolboxes.
    Englab is available for GNU/Linux, Unix (not tested) and Windows32 platforms.
    For GNU/Linux
         - Platform-independent
         The source tarballs are available at:
         http://sourceforge.net/project/showfile … _id=206384
         - Debian/Ubuntu (and other Debian-based distributions)
         Precompiled deb packages are available for download here:     
         http://sourceforge.net/project/showfile … _id=292500
         or to use our Debian repository, simply add it to your package sources by appending the following lines to /etc/apt/sources.list
         deb http://englab.bugfest.net/debian unstable main
         deb-src http://englab.bugfest.net/debian unstable main
         (Please note that you need to have root permission in order to edit the sources.list file)
         - Archlinux
         PKGBUILD scripts are available in AUR:
         http://aur.archlinux.org/packages.php?O … _Search=Go
         or in sourceforge:     
         http://sourceforge.net/project/showfile … _id=292585
         and also precompiled Arch packages exist in our Archlinux repository. In your /etc/pacman.conf add the following lines for the i686 architecture:
         [englab]
         Server = http://englab.bugfest.net/arch/i686
         and for the x86_64 architecture:
         [englab]
         Server = http://englab.bugfest.net/arch/x86_64
         then execute:
         # pacman -Syu
         to allow pacman to synchronize with the repository and:
         # pacman -Ss englab
         to see all the available packages.
         - Fedora
         RPM packages can be downloaded from sourceforge:
         http://sourceforge.net/project/showfile … _id=324683
    For Windows
         Download the zip from sourceforge:
         http://sourceforge.net/project/showfile … _id=324502
         and unzip it to the directory of your choice.
    For possible bugs, feature requests and any comments you may have please send us an e-mail at:
    [email protected]
    Thank you!

  • Open Source Developer

    Hi everyone,
    First post here as I'm not a Java developer, but I'm looking for help in your community. Sorry in advance if it is not the right place to post that, maybe you can redirect me if it is the case.
    I'm a flash actionscript developer and I've started an open source project some months ago.
    The project is an AS3 flash framework that is meant to be generated, this framewok is an MVC framework and manage the body of a flash site. The idea is generate the body of a flash site through settings.
    I'm working with another flash developer who is also a Java beginner. We have started to build a software with SWT. The first version is far from what I'd like to do but will be a very good start as a demo to show the potential. This first version is at the moment half done but unfortunately the other developer doesn't have a lot of time anymore.
    I can write myself a bit of java but I clearly don't have time to work on both side, Java and actionscript. I'm using already and successfully the flash framework in real projects and I still have a lot of work on the actionscript part, it makes unable to go further with the software at the moment.
    I don't know how things are working in the Java community but in the Flash one there are tons of free open source library/framework/project released. All these people are working freely on their project (probably at night as I'm doing :) ) because the're happy to face challenge, help the community and help developers to go further.
    I'm looking for one Java developer (and probably more later, as well as flash developer) interested in the project and willing to help me to finish this first version.
    The flash part is working already but not released to the public, you can contact me to join me or just to ask me more information (and see the framework and the application) or help me find someone.
    You can contact me on my blog:
    www.soundstep.com
    Thanks for your time.
    Romu

    Sorry Romu, but this against the CoC and [Terms of use|http://www.sun.com/termsofuse.jsp#g2_1] here.

  • ADF Faces open sourced

    Hi everybody,
    There are a lot a news on the Internet related to the Oracle donation of ADF Faces to Apache/My Faces. I was wondering if someone there could give us some precisions such as the ADF Faces (Cherokee?) availability (as an open source library) since it is a great news :)
    Thanks,
    Fabrice.

    Fabrice,
    basically the donated HTML components are work in progress and available in the Apache incubator website from where they will be made available later to MyFaces.
    See: http://www.jsfcentral.com/listings/A10470;jsessionid=1A6E290B6D7575D7391F83AC8AF41BC9?link
    and stay tuned
    Frank

  • OT: Yahoo open sources Javascript library

    Scott had a interesting link on his blog recently.
    http://developer.yahoo.net/yui/index.html
    http://yuiblog.com/
    http://developer.yahoo.net/ypatterns/
    Interesting development. Wonder what their business rationale for doing this is.
    It is kinda sad to see whole new Javascript toolkits being built from scratch over and over again. There are so many awesome toolkits out there today (Dojo, Prototype, script.aculo.us, the list goes on), wonder why the communities don't just collaborate and concentrate on 1 or 2 toolkits. I guess that is the open source model at work :-(

    Hallo,
    ... and ApEx is doing their own also. How about integration of e.g. http://www.dojotoolkit.org/ and collaborate with that framework?
    dojo has a real good basic structure and stable foundation of their libraries to write high level browser independent JavaScript Code (including an Aspect Oriented Event System in JavaScript, that is very powerful).
    What about wrapping the libaries
    htmldb_html_elements.js over dojo.html.* and
    htmldb_get.js over dojo.hostenv / dojo.rpc
    For further info on dojo see:
    http://www.ajaxian.com/articles/dojo-in-practice/DojoToolkitInPractice.pdf
    http://www.javapassion.com/j2ee/DojoToolkit_speakernoted.pdf
    For comparison of different toolkits see:
    http://forums.theajaxworkshop.com/viewtopic.php?t=237&sid=0a6781a1deec72ba3f7e851e3d4746ed
    Thx, Willi

  • IPhoto won't open due to the not being updated but when I check to upgrade to iPhoto 11 it tells me it is installed. The photos in the library were modified using 9.1.5 and the iPhoto is said to be 7.1.5 (iPhoto 8). Any ideas?

    iPhoto won't open due to the not being updated but when I check to upgrade to iPhoto 11 it tells me it is installed. The photos in the library were modified using 9.1.5 and the iPhoto is said to be 7.1.5 (iPhoto 8). Any ideas?

    How do you know the library was modified with iPhoto 9 (11)?  If you've never had iPhoto 9 on your Mac it could'nt have.  It sounds like a damaged library. Make a temporary, backup copy (if you don't already have a backup copy) of the library and apply the two fixes below in order as needed:
    Fix #1
    Launch iPhoto with the Command+Option keys held down and rebuild the library.
    Select the options identified in the screenshot. 
    Fix #2
    Using iPhoto Library Manager  to Rebuild Your iPhoto Library
    Download iPhoto Library Manager and launch.
    Click on the Add Library button, navigate to your Home/Pictures folder and select your iPhoto Library folder.
    Now that the library is listed in the left hand pane of iPLM, click on your library and go to the File ➙ Rebuild Library menu option
    In the next  window name the new library and select the location you want it to be placed.
    Click on the Create button.
    Note: This creates a new library based on the LIbraryData.xml file in the library and will recover Events, Albums, keywords, titles and comments but not books, calendars or slideshows. The original library will be left untouched for further attempts at fixing the problem or in case the rebuilt library is not satisfactory.
    OT

  • HT5037 IPhoto I am being advised that I need To open your library with this version of iPhoto, it first needs to be prepared.

    To open your library with this version of iPhoto, it first needs to be prepared.
    I am receiving this message: To open your library with this version of iPhoto, it first needs to be prepared.
    But when I try to prepare as by instructions, I am told that my existing version doesn't require to be prepared?
    Any help please!

    Given that you present nothing except a problem with no contexno one can possbly anser
    What version of iPhoto do you have? You state that you have OS X 10.8.5 in your profile - is that correct? What are the instructions that you are following that do not work?
    LN

  • Open Source releasing best practices?

    Hello,
    When creating open source software, I don't really know what the best way to release it (what kind of makefile, versioning system, etc...) is. It's also hard to find this info online, is there any good online info or book about this?
    Here are some of my questions...
    -How many operating systems should your makefile support? Should I make special cases for every single Linux distro and other OS in the makefile, or can I just  put a generic "g++ *.cpp" in the makefile, and let each OS and distro's own package managers take care of tailoring it to their OS?
    -For makefile complexity, I guess there is a scale ranging from a hack like just typing "g++ *.cpp" in it, through having nice sections, groups of files and definitions like "CFLAGS", all the way up to projects which have 20 different makefiles in them like "Makefile.in", "Makefile.pandora", etc.... Where on that scale should you ideally be?
    -Makefiles of many projects look incredibly complex, why?
    -What versioning system to use? When to make a 1.0.0? When to append "rc" at the end?
    -When to tag stable versions? And when you change something in head, do you need to change version number every single time?
    -When creating a dynamic library, and you tagged a stable version, and you then change something in head. Should in the makefile the version number of the library name be changed to something? If so, should it be changed to a next minor version, or to something with "-rc" at the end?
    -What names should be used for tags of versions?
    -Does there need to be both a zipped version of the source code and one under VCS, and if so why is that zipped version needed?
    -Are there any naming conventions for output binaries and libraries?
    -Are you supposed to let your makefile clean up .o files after compilation or not?
    -Are there any conventions for makefiles for names of sections and variables in it? E.g. is it a good idea to have a "clean:" in your makefile to remove everything?
    -When depending on another library which is hosted somewhere else, how to handle that? What when statically depending on it?
    -Any other things I should know?
    Thanks!
    Last edited by aardwolf (2013-05-07 12:32:57)

    aardwolf wrote:Hello,
    Many of your questions have no single correct response. I'll reply with my own opinions and experiences, based on my release of two open source projects (GPT fdisk and rEFInd).
    -How many operating systems should your makefile support? Should I make special cases for every single Linux distro and other OS in the makefile, or can I just  put a generic "g++ *.cpp" in the makefile, and let each OS and distro's own package managers take care of tailoring it to their OS?
    Ideally, a Makefile should build a package under every OS on the planet. In practice, this isn't always practical. Many developers use programs like Autotools to create Makefiles that are suited to a particular build environment. Other developers (myself included) create a handful of Makefiles for different environments -- for instance, my GPT fdisk has Makefiles for Linux, FreeBSD, OS X, and Windows. My rEFInd officially supports building only under Linux, although it supports two EFI toolkits (GNU-EFI and TianoCore EDK II) via a cascading set of Makefiles. Any of these Makefiles can require changes depending on the distribution and development environment in use, but that's not really my concern.
    If a distribution requires changes, that type of change is generally best left to a build system like Autotools or to the person who builds or packages the program. IMHO, it's unreasonable to ask a developer to make minor tweaks to a static Makefile to support every minor Linux variant on the planet.
    -For makefile complexity, I guess there is a scale ranging from a hack like just typing "g++ *.cpp" in it, through having nice sections, groups of files and definitions like "CFLAGS", all the way up to projects which have 20 different makefiles in them like "Makefile.in", "Makefile.pandora", etc.... Where on that scale should you ideally be?
    This is very much a matter of personal preference and project complexity. Autotools or something similar will make it easy for users and distribution maintainers, but can be tricky to use for the developer. If your program is a simple single-file C program, you might forego a Makefile completely; but for something on the scale of the Linux kernel, a Makefile (or something equivalent) is absolutely required.
    -Makefiles of many projects look incredibly complex, why?
    Some projects are very complex, as in the Linux kernel itself. Other times, the Makefiles generated by automated systems like Autotools can be more complex than they might be if they were hand-crafted. In still other cases the developers like complexity or are barely competent at creating Makefiles and so create something that's more complex than it needs to be.
    -What versioning system to use? When to make a 1.0.0? When to append "rc" at the end?
    AFAIK, there are no standards on this. A 1.0 release denotes that something has moved beyond "beta test" status -- in other words, you think it's stable and usable for the masses. Open source software authors tend to be conservative in making that judgment, so pre-1.0 releases in the open source world are often as good as post-1.0 releases of commercial software. The bottom line, though, is that it is a judgment call -- what I consider "1.0" software you might consider well beyond that point and something else might consider pre-beta.
    As to release candidate (RC), not all projects use that designation at all. It seems to me to be more common among large projects as they approach major release milestones, to denote something that is close to being finalized, but not quite -- essentially a sort of very late beta stage, even if the initial 1.0 release was made some time before.
    -When to tag stable versions? And when you change something in head, do you need to change version number every single time?
    If the code changes, you should definitely change the version number. Most developers accumulate several changes before making a new official release, though. Personally, I make full releases with three-digit numbers (like 0.8.6 or 0.6.10), and I upload minor changes to my project's git repository with four-digit numbers (like 0.8.6.1 or 0.6.10.2), but don't do full releases with tarballs and RPMs and whatnot for these, except in a limited way if I want specific people to test a recent change because they filed a bug report. Others have other systems.
    -When creating a dynamic library, and you tagged a stable version, and you then change something in head. Should in the makefile the version number of the library name be changed to something? If so, should it be changed to a next minor version, or to something with "-rc" at the end?
    The key difference with dynamic libraries is that the interfaces should not change with minor changes. IIRC, the second digit (like "2" in 1.2.3) is the cutoff point. In other words, a program that uses library version 1.2.3 should continue to work without changes or recompilation with library 1.2.4 or 1.2.2 (assuming no bugs). This enables users to upgrade the library (from 1.2.3 to 1.2.4 or the like) without upgrading every binary that relies on it. With version 1.3.0, though, the interface to the library might change in a way that would require recompilation of the program or even changes to the source code. Thus, changing the library from 1.2.4 to 1.3.0 will require the user to upgrade all the programs that use that dynamic library (or keep the old version around along with the new one). Note that I've never created a publicly-released library, and it's been a while since I've read up on this, so I might be a little off on these details.
    -What names should be used for tags of versions?
    I'm not sure what you mean by this.
    -Does there need to be both a zipped version of the source code and one under VCS, and if so why is that zipped version needed?
    You can do it any way you want; but as a general rule, you should provide source code in a tarball or .zip file because that's easier to download. Some package systems, such as RPM, require that a source package filename be specified, and so not providing source in such a package just complicates matters for packagers and therefore makes it less likely that they'll bother packaging your program at all. This in turn makes it harder for your users to use the program.
    Note that most Linux programs' source code is provided as tarballs rather than as .zip files. Some cross-platform programs can be exceptions to this rule. For instance, I used .zip for rEFInd (a boot loader) because .zip is a little more common in Windows -- although I'm sure either would have worked fine, in practice.
    You should probably provide binary builds of your software -- although in some cases this can be tricky because a binary built for Distribution A may not work on Distribution B because of library differences. The OpenSUSE Build Service (OBS) can help with this, although it's a bit of a pain to use.
    -Are there any naming conventions for output binaries and libraries?
    Not AFAIK, except of course for filename extensions like .so and .a.
    -Are you supposed to let your makefile clean up .o files after compilation or not?
    No, except for the "clean" target and anything else that's supposed to do this.
    -Are there any conventions for makefiles for names of sections and variables in it? E.g. is it a good idea to have a "clean:" in your makefile to remove everything?
    The "all" target builds everything, "clean" cleans up, "install" installs everything, and "uninstall" uninstalls everything. There's no law that says you have to have all of these, but they're common, particularly with big projects.
    -When depending on another library which is hosted somewhere else, how to handle that? What when statically depending on it?
    This type of thing is generally handled by packaging programs (pacman, rpm, dpkg, etc.), not by developers' Makefiles. That said, Makefile builders like Autotools should check for the relevant development libraries and stop if they aren't present. That will handle the static linking issue, as well as other problems. On another level, when using RPM, a source RPM will include dependencies on the relevant development libraries, and Debian source files have a similar feature. Putting these files together is the responsibility of distribution maintainers, not of program authors.
    -Any other things I should know?
    There's a huge range of acceptable practices on these issues. As a general rule, though, the smaller the package the more likely you are to find a simple Makefile that builds the whole project. Bigger projects are more likely to rely on multiple Makefiles, Autotools, or other complex pre-build software. More standardization emerges at the distribution level, in the form of source and binary RPMs, Debian packages, etc. You shouldn't need to worry too much about that. So long as your package builds with few or no changes on a variety of distributions, the distribution packagers can handle the rest. Build systems always support patches so that minor changes to Makefiles or whatnot can be incorporated. This frees you up to worry about other things rather than trying to support every minor variant distribution in existence.

  • Huge Hole in Open Source Software Found, Leaves Millions Vulnerable

    Huge Hole in Open Source Software Found, Leaves Millions Vulnerable
    Debian, the Linux variant used largely by security professionals, and Ubuntu, the variant most commonly used by home users are both affected. Furthermore, Windows servers may be compromised as well if they are using keys generated on Linux systems.
    Ironically the bug originated from an automated tool known as Valgrind which is supposed to reduce programming bugs which lead to security vulnerabilities. It found that a block memory was not being properly initialized, meaning that it would contain random information. The automated tool politely inserted code to clean up the block of memory making it all zeros. The only problem was that the system was intentionally using the block's unknown to get randomness to generate the keys. The library also gets randomness from mouse movements, keystroke timings, network packet arrival timings, and even microvariations in hard drive speed.
    The Valgrind code caused errors, so the programmers simply commented out all the code, including the other methods of generating randomness on accident. Only the code which utilized the process ID, an integer ranging from 0 to 32,767, remained to provide randomness. It turns out the "fix" turned grievous error was not the work of the OpenSSL programmers themselves, but of the Debian team, known for their security expertise.
    OpenSSL developer Ben Laurie raged, "Never fix a bug you don't understand! Had Debian [sent the bug to us] in this case, we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was. But no, it seems that every vendor wants to 'add value' by getting in between the user of the software and its author."

    firewalker - this was discussed here and on our mailing lists at the time the vulnerability was discovered, approximately two weeks ago. It's always a good idea to search the forum before posting.
    http://bbs.archlinux.org/viewtopic.php?id=48660
    Thread closed.

  • Open source /  Commercial version, it's up to you! Why not for ESB products

    Please comment this forum and help us to get Sun's support for Open ESB as we can get it for open-Solaris or Glassfish.
    Thanks
    Paul
    Extract from
    http://www.pymma.com/eng/People/Blog-Paul-Perez-Chief-Architect
    Jonathan Schwartz new policy
    Few years ago, Jonathan Schwartz replaced Scott McNealy as SUN Microsystems CEO. Swartz's first decision was to convert Sun into an Open-Source company. Consequently, Solaris OS, Application Servers and even the Java language were opened and their sources published. At present, Sun is viewed as a major Open Source actor.
    Sun�s new sales philosophy proposes, on one hand, its best products in an open-source format and on the other hand, commercial support and hardware. The best examples of this new philosophy are Open-Solaris and Glassfish. You can download these products, use them and test them. After you have built applications with these tools and wish to move into a production environment, you can buy support from Sun.
    Open source or Commercial version, it's up to you!
    Alternatively, you can as well buy commercial versions at the first place. Even if open sources and commercial versions are slightly different than the open-source ones, more than 95% of their code is originated from the same development branch. Example : SUN proposes its queue messaging system with two similar versions, respectively named �SUN QM� and "Open-MQ". The only difference is the amount you pay for the technical support.
    Everyone can find advantages in this sales policy on Sun products: companies and developers try and develop for free and can rely on Sun support in production. As a matter of fact, Sun uses these �free� products as Trojan horses to conquer new market shares, penetrate new companies and sell Sun hardware.
    Why not for ESB Products ?
    Unfortunately, there is a small issue in this picture: Sun's ESB platform is the exception in this sales policy. In Fact, Sun proposes two different tools for ESB developments. The first product. "JCAPS", is a commercial product inherited from Seebeyond. The second product, "Open-ESB" is based on JBI specifications (JSR 208) and was developed from scratch about 2 years ago.
    Alas, JCAPs and Open-ESB are definitely two different products.
    JCAPS ignores JBI specifications
    JCAPS connectors are based on JCA specifications and not on JBI.
    Open-ESB development process is based on Web services specifications, JCAPS not.
    JCAPS and Open-ESB developments are not compatible.
    Hundreds other differences can be found between the two products.
    We can understand that for a while, for technical, marketing or business reasons, a company supports more than one product lines with the same functionalities. IBM does it and Oracle buying BEA will do it also.
    However, there are several things that Pymma would like to understand:
    Why the download of JCAPS is only available for authorized JCAPS Partner ?
    Why SUN does not provide support for open-ESB as it does for Glassfish, Open Solaris or Open MQ ?
    Why JBI or Open-ESB are never mentioned at most ESB seminars organized by Sun Centres in the UK ?
    Why Sun marketing, Gurus or consultants are prolix about JBI in the public lectures and technical forums, and at the same ignore Open-ESB when they advice companies ?
    Is the policy of Jonathan Swartz policy only applicable for Java Legacy applications (Application Server, Message queuing�)? not for ESB tools ?
    Of course, we already asked these questions to SUN but we never got clear answers.
    Thanks for clarifying Sun's position
    Many companies believe in JBI and their developers spend time and energy working on Open-ESB . These companies would certainly be interested to hear Sun's explanations on the above questions. They probably want to be sure that Open-ESB will not be just a prototype for the new JCAP version (only reserved for SUN JCAPS Partners). They certainly want to be credible by proposing SUN's professional support on Open-ESB as they do for Glassfish and Open-Solaris. After, they only need from SUN to clarify its position and give a clear prospective for the future of JBI and Open-ESB. We hope that through this blog Sun will hear us and we will give us clear answers.

    Hi Leonie,
    My iPhoto is iPhoto 11, version 9.4.2.  I believe my Aperture is the latest version but I don't know how to verify that when I can't open it.  I regularly accept any updates.
    How I restored my Aperture Library: I opened Aperture, clicked on Time Machine, and navigated to the Aperture Library that had been backed-up earlier in the day.  It took a while to restore. 
    When done, I opened Aperture (yes, at that point I could still open it).  It opened up on the still-empty Library, and I had to manually change it to the restored library, every time I opened aperture after that.  This was annoying, so, I then went to FINDER and deleted the empty Library.  I probably shouldn't have done this; I noticed it had the words "current default" in its filename. 
    From that point on, FINDER shows the restored aperture library (actually two restored aperture libraries, since I accessed Time Machine a second time to restore an even older backed-up version) but of course, not the empty Library that had had "default" in its filename.  And... I can no longer open Aperture.
    Hope you can help me, thanks so much,
    Glensdaughter

  • Open source image, audio, video hosting - MediaCrush

    Hey guys! I've been building MediaCrush over the past few months, with my friend (and fellow Arch user) Jose Diez, and several other open-source contributors. It hosts video, audio, images, vectors - over 500 different file formats are supported. You can upload almost anything (like a mp3, flac, mp4, webm, avi, bmp, svg, cr3...) and it'll be converted (losslessly where possible) to browser-friendly formats. You get a link to share, like this: https://mediacru.sh/Fx73lJhU0_Id
    The site is completely open source. You can run your own clone of MediaCrush locally with the help of the detailed instructions in the README. Pull requests are welcome, too, so you can help make it better if you please. It's written in Python and it's built on the shoulders of giants like ImageMagick and ffmpeg. Our whole shop is Arch - our dev machines are Arch, and all of the production servers (web servers, processing servers, and storage servers) are running Arch.
    ✓ Share images, audio, video, vectors
    ✓ Super fast hosting
    ✓ Hotlinking/embedding
    ✓ Create albums of media
    ✓ Keep track of files you've uploaded (optional)
    ✓ Privacy-first data policies (link)
    ✓ Excellent public API (link)
    ✓ Entirely open source
    ✓ HTTPS only
    ✓ Ad-free
    You can upload files right away at https://mediacru.sh, or set up your own instance to host files on. Feel free to hop into the IRC channel for a chat, too: #mediacrush on irc.freenode.net. There are a couple of other cool things that you might like. For example, MediaCrush-cli lets you upload files from the comfort of your favorite shell.
    $ mediacrush --album *.jpg # example usage
    You can find it in the AUR as mediacrush-cli. There are also browser extensions that make it easy to rehost images around the web: Firefox, Chromium (both are open source, of course 1, 2). I also have a little script that uploads screenshots via scrot straight to MediaCrush.
    Here are some example URLs to play with: Video, or audio, or a GIF (we convert those to video, makes them load faster), or how about an album?
    Let me know what you think! I hope you like it.
    Last edited by SirCmpwn (2014-02-04 01:26:43)

    SirCmpwn wrote:
    likytau wrote:
    a GIF (we convert those to video, makes them load faster)
    practice, but of course it totally breaks on pixel art.
    You're absolutely right. The reason we decided to convert GIF to video is because the majority of GIFs are sourced from video, and GIF is a poor choice for that kind of media. However, GIF is well suited to pixel art. The original GIF doesn't go away when you upload - if you want to host GIFs on MediaCrush like that, I suggest hotlinking straight to it: https://mediacru.sh/1hBjPzWZGy6m.gif. That being said, we strive to make the conversion as close as possible to the original, and I feel that in both cases, the final result is close enough to give the general idea, and then you get the original GIF when you click "Download", so it's suitable for sharing.
    Yes, I agree that it is quite good quality, the problem only arises when the output must be 100% accurate as with pixel art.
    It's good to know that the original does not go away.. Especially for formats like GPL, this is quite helpful.
    Files are run through detect, which determines what kind of file they are, collects some metadata, and selects a processor. Processing is distributed, which is accomplished through Celery (with Redis as a broker).
    I see, excellent summary. With the help of that, I have written a GPL detector (which maybe doesn't work fully, I had no idea whether simply open()ing the file would be okay with your architecture):
    def detect_gpl(path):
    # XXX don't know how to access path. Is standard open() ok?
    with open(path, 'r') as f:
    lines = [f.readline().rstrip() for v in range(3)]
    if (lines[0] != 'GIMP Palette' or
    (not lines[1].startswith('Name: ')) or
    (not lines[2].startswith('Columns: '))):
    return None
    return {
    'type': 'application/x-gimp-palette',
    'extra': None,
    'flags': None,
    Haven't written rendering code yet, but I think imagemagick can do the job; it would probably be possible to generate an XPM directly in Python code, that ImageMagick could then convert.
    Regarding the other formats you mentioned, could you offer some test files, and a general idea of what they are and how we might go about detecting them and supporting them?
    Yeah, I'll provide some shortly. You may not want to support them all, but here's a summary of what they are:
    * GPL : Gimp Palette. Used by GIMP (duh), Inkscape, Mypaint, Scribus ... most OSS graphics apps. Identified as above (well, my routine above is actually fairly paranoid -- just checking that the first line content equals 'GIMP Palette' is normally enough to detect it). Sample files here.
    * ora: OpenRaster. 'Generic layered image format', hopefully will become a standard for layered raster graphics interchange. MyPaint's native format, supported by GIMP and Krita. Convertable to PNG using calligraconverter[1].
    * kra: Krita's native format. Convertable to PNG using calligraconverter[1].
    * xcf, xcf.gz, xcf.bz: GIMP's native format. Convertable to PNG using xcf2png (from 'xcftools' package)
    * ase : probably don't bother -- this is Aseprite's native format, which is not particularly common in the wild. I don't know of a tool that converts it. I just tried it for testing's sake.
    * webp: Google's WebP format. Already handled, but you seem to currently convert it to a video even if the image is static.
    [1] Available in the package 'calligra-extras'
    You're welcome to submit pull requests; you should join the IRC channel to participate in dev chatter. Thanks for the feedback!
    Thanks, I'll look at doing that once I'm familiar with the system.
    Last edited by likytau (2014-02-05 05:45:51)

  • Open-source anyone??

    I recently decided to start an open-source project JAquarist, which Im sure not too many of you would find great interest in, despite some rather interesting ideas and techniques Ill be employing in the application. Several months ago I attempted an application framework, a small project that I brushed to the side until
    more important things were taken care of, JAVA certification being just one of them.... I decided to complete this project, the Framework that is, in the hopes it would make my real task at hand JAquarist project a bit easier to develop, maintain, extend, etc. The development of this framework has gone quite well to this point, some areas admittedly quick fix hacks, my inexperience probably showing through its design, but its almost completed to the requirements for my JAquarist project.The point is that this framework could be a useful tool, or a quality framework if more time, though and effort was given to its overall design and implementation, especially by those more experienced than myself. I hate to admit there is huge room for improvement in many areas, I still have much to learn!!
    I will finish this framework within two weeks and then let it loose. Anyone interested in further developing this framework please contact me at [email protected]

    My project is hosted at sourceforge, that is JAquarist which will be built using the framework Im currently working on, which should be a project of its own. Its an application-framework which attempts to many things. Key features, are dynamic pluggable behavior through a component interface. This interface defines such things as the components available guis, top level menu, menu-items, dependencies(for inter component communication/re-usability), as well as a few other odds and ends. Classes implementing the component interface can be added/removed via xml configuration, without recompile. Menus are dynamically created and linked to a "components" defined guis, some of which wil be reusable in other components. Logging, although very much a quick hack at tis point, is also provided, an application context for an application to easily access key directories/files under an install directory, lastly jdbc support, which is coming along well I think. You can turn jdbc on/off and specify connection parameters in xml config, and much of the work such as data binding is handled automatically. In addtion component depenency checking, jdbc dependency checking as well. To provide one example, there is a JdbcComponent interface. initialization wil compare its required tables to tables existing in an rdbms, if not found initialization will call upon the components getCreateScript() returning sql create statement, which will then be used to create the table.

  • With the GL demise... are people moving towards open source?

    Not a GL expert by any means but I have built several sites that I'm relatively happy with using GL6, this being one of them:
    http://tinyurl.com/ybn8pw
    Yes, it's table based so I realize I'm a dinosaur :)
    With the demise of a staple such as GL and the desire not to jump in again so readily on a commercial product... I wonder how many, if any, have moved to something in the open source CMS arena?
    I ask because I've been tempted to move to something like WordPress using a magazine based theme as the basis of my site and wonder if others have made this move as well?
    As I said, I'm no GL expert... but with a few basic plug-ins and some rudimentary CSS... I've got my site to do a few nice things.
    Not looking to stir the pot, just asking with an eye towards the future.
    Thanks

    I'm using Wordpress, but not as an alternative. I've set up a few blogs and I'm getting into mucking with the php and css to customise designs - it's fun, but unless you stick to canned templates, you need to know some fairly detailed css and get to grips with yet another coding language in php - you don't need to learn all about it, but enough to get comfortable.
    So, another learning curve but it does open up new possibilities. As far as Golive goes, I'll keep using Golive CS2 for the forseeable future, although I'll end up keeping an elderly Mac to run it in the end, along with other older software I don't choose to abandon.

  • OpenCL for Labview is now Open Source

    Howdy,
    I wrote OpenCLV (OpenCL for Labview) about a year ago and have decided to make it an Opensource project availible on GitHub.  It contains all my C code to compile DLLs, all the Labview code, some pre-compiled x64 DLL code and a pre-built .vip project if you just want to download and install it.
    https://github.com/amcelroy/OpenCLV.git
    My email is in the GPL license header in the C code if you find any bugs or have any comments.  
    Austin

    tst wrote:
    While I don't have use for something like this myself, the willingness to share open source code is appreciated.
    One problem I would have with this, though, is the license. I'm far from an expert on licensing, but my understanding is that the GPL license is infectious - if you use a component which uses it directly in your code, you have to make your own code GPL as well to adhere with the license and the only way around that is to separate the GPL component into a separate, dynamically linked, component which would allow the end user to replace it if they want. See their FAQ here - http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
    My understanding is that this is the reason that OpenG switched from GPL to BSD some years ago - BSD is more permissive and basically just requires you to place the copyright notice somewhere where the user can see it.
    The strict interpretation of GPL prohibits integrating a GPL component into a non GPL software even dynamically. That is why there is a LGPL. And that was indeed why OpenG changed from LGPL (not GPL!) to BSD several years ago. Many of the most influencing OpenG supporters felt that it was rather cumbersome to use it in non (L)GPL software. The most prominent product of this nowadays is VIPM.
    The only exception to that change are the shared library components of the libraries that I wrote. I didn't feel that there was any bad influence from integrating them as LGPL into any sort of LabVIEW application, as they are fully dynamic anyways and by the nature of LGPL have no viral effect on the application that uses them.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

Maybe you are looking for