Just a note on setting up Felix for use in an "enterprise".
There is lots of stuff to do. However the core problem is to
distribute and build upgrades to the core system.
Felix install consists of two directories at least:
(1) share
(2) target = host
The share directory consists of two subdirectories:
(1) src
(2) lib
The src is a copy of the whole source code, including all the webpages.
It is all human readable platform independent text (except for a couple
of images used by the webserver).
The lib directory is just a copy of src/lib, the Felix library, which is all
Felix code.
There can be any number of target directories, but there must be one
which is named "host". Targets contain:
(1) config
(2) lib/rtl and lib/plat
(3) bin
All these files are platform dependent. config contains the *.fpc database used
to configure building and using Felix on that platform. The lib/plat is a Felix
source with platform details available to Felix. It is used to condition the
shared
library to make it adapt to the current target platform.
The lib/rtl and bin contain machine level binary code such as object files,
executables, shared libraries, as well as C++ header files used to adapt
the C++ sources of the RTL (and user C++) for the current platform.
SO: the network administrator will first get Felix from github, and build and
install it. This is repeated for upgrades. The admin needs write access
to the share directory to do this, as well as the host.
The admin will also create directories or links for each target platform.
The platform manager for that platform needs write access. Their job is to
build Felix for that platform.
The users of the platform need read and execute permission, but not write
access.
Each user must have their own cache in $HOME/.felix which they have full access
to.
DIFFICULTY.
==========
With this model, the felix install directory contains shared source everyone
uses and platform specific target directories. However since those targets
are platform specific, but they live on the same server as the shared sources,
we have a bit of an admin problem. Unix can probably solve this with various
mounting arrangements, or symbolic links from the platforms TO the shared
directory.
However it is platform dependent how to set this up.
A better way in principle is that every platform has a target directory and a
LINK
to the shared sources that Felix understands.
For me personally, it is an issue: the current method means I cannot just
install
the shared sources using 'sudo' and then build for my box without it in
my personally accessible space (I normally cannot write to /usr/local without
using sudo).
So I am probably going to change the layout. Comments welcome!
I will probably change it so "target" is wherever you want, and you have
to put a link to the shared sources. by "link" I do NOT mean a Unix link,
I mean a piece of text in the config that says "sources are in the
directory xyz/share".
The OTHER way to do this is to create the coupling required on the
command line:
flx --share=/usr/local/lib/felix/felix-latest/share --target=mytarget
the obvious default location for the "host" target is i
--target=$HOME/felix/host
however that cannot be shared between accounts on the same machine.
So there are three options:
(A) leave it as it is: target directories siblings to the shared one
(B) change to put the link to the shared sources in the target config
(C) change to require the shared platform independent and platform
dependent be coupled on the command line
Clearly (A) is the most robust and easiest to work with IF it is good enough.
I did this first for that reason.
(B) is flexible, but it means you cannot install a built target just by copying
it unless it was built off the installed shared sources. If it was built
of a local source (what I do all the time) then the copy of the installed
code will point at the wrong place.
Apple Frameworks work this way. All shared libraries built and then installed
in the Felix system have the wrong dependencies (because they're
not built and installed one at a time so the next one depends on the
installed ones, but all built together, then installed, so they all depend
on the build location instead of the install location). DYLD_LIBRARY_PATH
fixes this (but Apple's frameworks are meant to get rid of the need for that).
(C) is the most flexible but very error prone unless the HOME directory
is the default, which means every account has to have their own
private configuration.
I don't think (C) is viable in an enterprise where some people are
"just using" Felix programs rather than writing these programs.
I have a plan for an extension of (B): instead of Felix sources going
on a server shared on a LAN, it will go on felix-lang.org.
So the sources will be shared *universally*. Felix will use
TCP/IP/HTTP to cache the sources and update the caches.
Once this "automatic update" is running, you will never need to
rebuild Felix manually. Everything will rebuild automatically
and transparently.
This is similar to say Firefox or some Windows program doing
an automatic update EXCEPT that we're downloading SOURCE CODE
in plain text not binaries. In other words, we have Open Source.
We'd use security/crypto etc to ensure the right stuff is downloaded,
and the public archive is then available for bug inspection.
Then we allow intervention, for example "Don't update without asking"
to gain more security for those with the expertise to actually manage
updating/verification/rebuilding etc.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
