I have not used RedHawk but am considering using it. Reading the documentation it appears that RedHawk only supports development on varieties of Linux, but it is not clear whether this limitation also applies to target execution environment. Can RedHawk support applications to run on non-Linux target hardware (cross-compile, CoreFramework, remote debug, ...)?
Redhawk is not limited to running applications on Linux platforms, per the SCA standard. An ExecutableDevice (see http://redhawksdr.github.io/Documentation/main.html, Section 6.4 'Executable Device') enables software to be copied to and run on a particular host, which does not have to be Linux-based. However, Redhawk does not provide any implementations, base class/helper libraries, development tools, etc. for other platforms, which makes this less practical.
The only exception to this is the SCA explorer, used to browse/interact with Redhawk domains (for Windows, available on SourceForge). Interacting with a running Redhawk domain from a different platform is fairly straight-forward using CORBA and the interfaces included with the Core Framework.
Related
I am trying to learn IBM's basic assembly language and I was wondering if there was a way of assembling BAL code on a Linux guest running on a mainframe?
I have nasm and as installed, but I think these are normally used for Intel processors rather than Z.
There is a tool chain in Linux so that you can write assembler. as as an assembler then link edit and go. However, assembler is just a “language” which depends on a broader eco-system of APIs.
For instance, on z/OS there are a number of manuals that document the interfaces to operating system services, authorization of assembler and other “operating system services” that are going to vary depending on the OS you are developing in.
If you want to code 390x assembler on Linux you can but you are using OS services in Linux which are very different than other OS’ like z/OS.
If you are interested in a compare and contrast of the architectural differences between z/OS and zLinux you will find this presentation enlightening.
Here are a few other possibilities, in no particular order:
IBM offers a commercially licensed HLASM for Linux on Z/LinuxONE. The standalone IBM Program Number for IBM HLASM is 5696-234, but it can also be licensed via other IBM operating systems for Z, such as z/OS. IBM distributes HLASM for Linux as a .rpm file, and it'll be something like asma90-1.6.0-47.rpm (where 47 is a revision level, the most current I see at the moment but subject to change).
Dignus offers a commercially licensed product known as Systems/ASM (or DASM for short).
z390 may be of interest: http://www.z390.org
Please note that z390 apparently hasn't been updated since 2012, so it likely won't include support for recent machine models' instructions.
When I first heard that Microsoft was working to run docker containers it didn't make sense.
For a while it seemed that Docker was Linux-centric, with its dependency on Linux Containers.
Now it seems Docker has switched from LXC to an implementation of the Open Containers Format (OCF) spec in runc.
My question is: Does the OCF spec mean that Docker is no longer Linux centric? (ie is that how this will work? Does that mean there exists the theoretical capability to do this on OSX as well?)
There are a few points of interest here.
Containers can only be supported natively on platforms that have support for OS virtualization. OSX (so far) does not have such a capability. So it cannot support containers natively. You have to use a VM.
A standardized container format does not mean that the same container will be able to run on different platforms. The container and the host necessarily have to run on the same kernel. So a particular container can only run on a compatible platform.
What the standardized container format specification does is to enable richer container ecosystem technology from varied sources, all able to interwork because of the standard container format. This technology still has to be implemented for each different host platform.
Docker's adoption of OCF does not necessarily mean that it will automatically start targeting platforms other than Linux. It just means that the container format it will use on Linux will be the OCF instead of it's own proprietary format.
+1 to Ziffusion. You might want to reword Item 1), but basically you are correct on all four points.
To answer the OP's question: I do not believe OCF "deprecates" Linux. On the contrary, I believe it better supports Linux AND, AT THE SAME TIME, opens Docker functionality to better support other OS's, too.
Specifically:
https://www.opencontainers.org/faq
In the past two years, there has been rapid growth in both interest in
and usage of container-based solutions. Almost all major IT vendors
and cloud providers have announced container-based solutions, and
there has been a proliferation of start-ups founded in this area as
well. While the proliferation of ideas in this space is welcome, the
promise of containers as a source of application portability requires
the establishment of certain standards around format and runtime.
While the rapid growth of the Docker project has served to make the
Docker image format a de facto standard for many purposes, there is
widespread interest in a single, open container specification, which
is:
a) not bound to higher level constructs such as a particular client or
orchestration stack,
b) not tightly associated with any particular commercial vendor or
project, and
c) portable across a wide variety of operating systems, hardware, CPU
architectures, public clouds, etc.
The FAQ further states:
What are the values guiding the specification?
Composable. All tools for downloading, installing, and running containers should be well integrated, but independent and composable.
Container formats and runtime should not be bound to clients, to
higher level frameworks, etc.
Portable: The runtime standard should be usable across different hardware, operating systems, and cloud environments.
Open. The format and runtime should be well-specified and developed by a community. We want independent implementations of tools to be
able to run the same container consistently. ...
The Open Container Initiative is a working towards making a container format and a runtime that can run on many platforms, although a lot of the concepts and requirements will be based on the linux foundation they have been built from. An OCF container still specifies a platform so don't expect to be able to execute a Windows container on a Linux host. But expect to be able to manage Linux and Windows and "Y" containers in the same manner and ecosystem.
Docker moved away from LXC a while ago, to using libcontainer which is still linux centric. runC is the next runtime that is already able to run current docker containers on Linux, but aims to support the Open Container Format spec on many platforms.
The goal of runC is to make standard containers available everywhere
Linux, obviously, has been building up the OS features to support containers over the last 10 years. Microsoft has included a lot of the OS components in Windows 10 to run containers natively and has thrown support behind docker. So expect runC to be running on Windows soon.
BSD does support a lot of the functionality via it's Jails setup but never matured as much as the Linux space so I believe additional OS support will be required for it, or OSX to be able to run an OCF container natively. Although recent FreeBSD 11 does allow you to run Docker via it's 64bit Linux compatibility layer so I'm guessing runC would be close to doing the same, at some possible performance cost.
I am looking for design suggestions/documents etc. which contains specifics of system applications management in Linux (Ubuntu, Debian etc.)
Can you please point to a source of information or suggest a design?
I'm not sure to understand what you mean by system applications management (certainly it can mean several different things).
In practice, Linux distributions have some package management system to deal with that issue. init or systemd (etc....) is in charge of starting/stopping/managing daemons and servers. Its configuration is related to packaging.
Read also Ubuntu Packaging Guide and How To Package For Debian and Debian new Maintainer guide etc...
If you are coding some service application, read Advanced Linux Programming and about daemon(3) & syslog(3)
Also, study the source code of relevant system applications (similar to the one you are dreaming of), since Linux is generally (mostly) free software.
Im am building an unified messaging platform on Ubuntu, including VOIP and other features. However I need to modify the existing codebase, so that it works on top of IMS (IP Multimedia Subsystem). I am aware of one IMS implementation for Linux (Open IMS Core), but it is mostly designed for testbed and not for production systems. Can you point me to some other IMS implementations, possibly free, for Linux?
Regards,
Angel Kafazov
There is a HSS system written in erlang....
there are also some other components written on top of kamillio SIP i think it might be called openHSS...
mobicents has some tutorials about linking with an openIMS
an IMS implementation consists of many components so you wont likely find an entire system freely open sourced
your closet bets are the mobicents and opencloud Slee platforms
but Beware JSLEE dev is a complex beast
I'm looking for an explanation of the different functionality in versions of a application called VMAC (Verix blah blah blah), also called "comm server", which is used on Verifone payment terminals. I've got terminals with versions 1.7 and 3.3 of VMAC, and I'm unaware of the differences.
If someone is a Verifone expert, it would be helpful to know how much of the communication with the processing host vs the merchant services provider's application.
VMAC stands for Verix Multi App Conductor. VMAC provides a platform for multiple terminal applications to run on a single device. Comm server software is used for communication purpose. Versions mentioned by you are bit older version . Latest version of VMAC available is 3.20.0. Differences between different VMAC versions are like newer versions supports more (and/or Enhanced) features of devices and/or are more robust than previous versions.