In WWDC talks, Apple devs have mentioned that they want to move away from dlopen with the introduction of dyld3. What's the status of dlopen, at present and for the future? Does it have limitations with dyld3?
Related
Does anyone know how the Apple TV Developer kit differs from the commercial one?
For instance, The App Store doesn't seem to be available on the Dev Kit
The 13T396 "GM" tvOS build has been available since October 21st.
However, on October 29th the "release version" of tvOS was added to the Apple website. Annoyingly, this is also marked as build 13T396.
The tvOS App Store showed up on my Dev Kit after downloading and restoring the release build. I had tried restoring the "GM" several times, after the App Store went live, with no success.
Make sure to download the new bits released on 10/29, and use that build (13T396) rather than the GM (13T396).
Once the Release build has been installed, your dev kit will be at "absolute parity" with retail Apple TVs.
Yes - there will be an update that brings the dev kit OS to absolute parity with shipping units.
https://forums.developer.apple.com/thread/18615
According to this post on the developer forums, the App Store is not available yet. Sometime in the future (Unknown at the moment) the dev kit will be able to update "to absolute parity with shipping units."
https://forums.developer.apple.com/thread/18615
I was wondering if adobe air would come out for the apple watch or is there any way to develop with adobe air for iWatch? Thanks!
WatchOS 2 apps require submission to Apple using LLVM BitCode. Apple can than compile to native code (currently S1/arm7v) as they update the watch framework and/or hardware and the developer does not have to resubmit their apps to handle those changes.
Adobe has not publicly mentioned adding any additional platforms to Air and it would require a major investment to place a AS3/Air front-end on the LLVM compiler. I, personally, highly doubt this feature will ever be seen.
Learning X-code (or license and learn Xamarin/C#) is the only way to go right now (unless someone knows of other third-party development env. that support WatchOS2/WatchKit).
Add your Vote of support to additional Air platforms:
Open Adobe bug/tracker for Windows Phone 8/10 (open since 10/2013): https://bugbase.adobe.com/index.cfm?event=selectBug&CFGRIDKEY=3648920
Open Adobe bug/tracker for WatchKit & Android Wear:
https://bugbase.adobe.com/index.cfm?event=bug&id=4069595
What has been the experience of folks who have already been using OpenDJ and OpenAM? Older versions seem free to use but the new releases don't seem to be free for use. How do they compare to the existing commercial offerings? They look like a better option than using OpenLDAP with CAS but don't look free.
Below you can find answers depending on when this question was asked just for the sake of history.
ANSWER AFTER April 3rd, 2017
With the recent changes made to the business model here you can find the key details you will need to know:
The latest versions of the main products have been firstly renamed, but secondly has been re-versioned to match ForgeRock's Identity Platform views:
OpenAM 14.0.0 -> Access Manager 5.0.0
OpenDJ 4.0.0 -> Directory Services 5.0.0
OpenIDM 5.0.0 -> Identity Management 5.0.0
OpenIG 5.0.0 -> Identity Gateway 5.0.0
The products listed above were all released under a commercial licence, meaning:
The ForgeRock contributed source code (i.e. ForgeRock's intellectual property) is not licensed under an open source licence.
All source code that does not solely belong to ForgeRock (e.g. original source code that belonged to Sun, or source that had open source contributor's work associated with them) will be still available under the CDDL licence and can be obtained as detailed under forgerock.org.
All ForgeRock IP is licensed under a non open source licence.
The products released under the commercial licence can be evaluated for 60 days only.
At the same time of the official release of the new products, community editions have been released for the Open* products:
The community editions are essentially the latest maintenance releases of the last EOL'd versions of the products.
Since these are maintenance releases, they are meant to be firstly more stable, but secondly slightly more secure (only slightly since these versions have not been updated to include the security fixes that have been issued since these versions' original release date).
The community editions can be found under forgerock.github.io
With these new releases every community member will have to make a decision themselves: do they want to go for the latest, but EOL'd stable version of the product, or do they want to try their luck with the latest public, but likely to be less mature software versions (like OpenAM 13.0.0 that was released before the business model change).
Whether community versions will be released/updated by ForgeRock in the upcoming years is currently unknown, no such information has been publicly provided.
Short of an official announcement from ForgeRock, please have a look at this topic in the ForgeRock forum for more details.
To summarize:
The Open* products are still open source and freely available, however they are no longer being publicly developed by ForgeRock. Whether new community versions will be made available is yet unknown, but given the current example, each year the community would get access to an EOL'd version of the product..
ANSWER BEFORE April 3rd, 2017
Here are some facts about the projects and the licensing in general:
Only major releases are made publicly available, which means the source code is available in the format of an SVN tag, whilst the binary that can be downloaded from BackStage will have the binary license on it.
The binary license allows people to test out the product, but it prevents them from using those binaries in production environments without support subscription.
Maintenance versions are not available publicly neither in source nor in binary format.
Each project's trunk (or master) is publicly available, which means that in one shape or form every single bugfix is available, so with some luck it should be possible to cherry-pick important fixes from trunk onto your own special maintenance version.
Each product is relatively simple to build (except maybe the web agents), and as such it shouldn't pose much of a risk to your deployment (ForgeRock does have customers who are building their own artifacts for their deployments, so it is really not a rocket science).
Downloading the artifacts from BackStage only requires some skills on working with agent protected applications, here is an example curl command:
$ curl -O -H "Cookie: fr_sso_sess_prod=AQIC5w..." https://backstage.forgerock.com/downloads/enterprise/openam/openam12/12.0.0/OpenAM-12.0.0.war
Unfortunately it is common that the major releases have some annoying bugs, for those, backporting is relatively simple, since the difference between trunk and the latest major release shouldn't be too big, so you should be able to handle those by manually backporting the fixes. Since major releases happen every ~year or so, you don't have to live with these local changes for too long fortunately.
The projects have active community, and getting help with any kind of issues shouldn't be too difficult (let it be a deployment issue or how to build the projects locally)
Probably I should mention that I'm a ForgeRock employee, so take my comments as you please.
Just to clarify: when you build trunk on your own, you do not have to buy subscription. Only ForgeRock enterprise builds should include the binary license. When building your own stuff, it is you who creates the binaries, hence you can simply decide to leave the binary license out of it.
I'll answer your question in two parts:
First as it compares to existing commercial it's actually a very good solution, as it scales, and it's very feature rich. You can go to the site and read all about the features.
The second part of newer version requiring subscription is somewhat wrong. Mainly because there are subscription downloads from forgerock.com. I assume this are for support service contract reasons that one must purchace. If you want to run the latest version just download the nightly builds forgerock.org, and you will be running the latest version. Lastly I will echo Ludovic's comments about the confusion of free.
[Community] - https://forgerock.org/
[Commercial Support] - https://forgerock.com/
PS. I'm in no way associated with forgerock.
I think you are confusing free as in Free beer and the freedom of open source.
This said OpenAM and OpenDJ are enterprise ready products, mature and used in a large number of mission critical environments including governments, telecom operators, financial institutions, insurances...
Do you know any open-source project in EDA (Electronic Design Automation) looking for C++ programmers?
You might be able to get into gEDA if you hang out on their mailing list. Details: http://www.gpleda.org/developer.html
I dig up this old topic, but we from the KiCad EDA project still searching for new developers and testers. KiCad is a GPL'ed suite for drawing schematics, printed circuit boards and viewing gerbers. Its written in C++ with the wxWidgets toolkit and is able to work native on Windows, Linux/BSD and Mac OSX.
Read more about the project at:
http://www.kicad-eda.org
And the project is now hosted at launchpad.
You might want to talk to the owners of Icarus Verilog or Verilator. There are a host of other tools on freshmeat too which are into EDA and open source.
We extensively used Electric during our VLSI and Microelectronics classes. The project is sponsored by Sun and may soon get orphaned in the post Oracle days. It will be worthwhile contacting them and offering assistance. It is a great tool worth supporting.
I don't know of any that are actively looking for C++ software developers.
However, if you implement or improve a feature, or fix a bug, you can make a pull request from their open-source repository. E.g., take a conference paper from DAC/ICCAD, implement it and integrate it into the open-source repository.
Some examples below are stuff to experiment with and learn from.
Xyce (best open-source circuit simulator): https://xyce.sandia.gov/index.html
The EPFL Logic Synthesis Libraries: https://github.com/lsils/lstools-showcase
EDA projects that are part of the OpenROAD program/initiative: https://theopenroadproject.org/
If you check out research papers from DAC, ICCAD, and DATE (the top research conferences in EDA), you can find some software developments releasing their work as open source on Github or elsewhere.
What are best practices in recording build/test machine(s) setup during the life time of a project? If you need to provide a patch for previous version of your product, you likely need to reload the same compiler and support tools to re-issue the patched release. What and how do you record? The obvious things are:the OS version and patch level, compiler/IDE version and patch level 3rd party tools/libraries.
My first thought is to keep a log file of all the requirements. This log file would go into your VCS.
VMWare Virtualization(or other similar products) are ideal for this type of thing. Build an entire development/build/ or test environment, and leave it setup just for that purpose. You can take the image off-line, back it up to a DVD and simply turn it back on when you need it.
I'm using maven for java with the enforcerer plugin so all of these things are stored in my project object model, even the version of maven itself which is required. As long as I manage to get the proper version from version control I'm home free.
3rd party tools and libraries go in version control along with everything else; we have a libs tree that goes under our VCS trunk right next to our app tree, so it gets included with any branches or tags that we create. The one wrinkle I haven't yet solved is Windows tools and libraries that require their own installers instead of running out of whatever directory VCS gives them.
For OS and compiler, I'd recommend creating a VM for each release if you can't install multiple compiler versions in parallel. Then your project wiki can document which VM and which compiler version to use for a given build. This isn't automatic like your log file would be, but it provides a ready-to-go environment (instead of potentially having to reinstall a machine to match your log file). Some projects check their entire compiler into version control, but this seems overkill to me (and doesn't play well with IDEs and compilers that need their own installers).
We don't track patch levels for the OS and compiler. I realize that it's possible that a patch would break or change something, but the chance seems so low that the cost-benefit ratio just isn't there.