I'm setting up reproducible build environments for our product using Vagrant and VirtualBox. We are targeting RHEL7, Oracle7 and Ubuntu 14. I have read a few RPM build guides but one thing is not clear to me. Using RHEL6 as an example, say I build an rpm on RHEL 6.4 but want to ensure compatibility with 6.0 and up. Will the generated RPM be compatible with the whole RHEL 6 series or do I need to build on 6.0 to ensure that?
Basically I'm trying to decide if I should have Vagrant update the systems to the latest minor release and packages in my rpm build environments.
Generally yes, as long as you're only dependent on public interfaces. Determining what a public interface is, isn't all that easy though.
From Red Hat Enterprise Linux: Application Compatibility GUIDE
During the life cycle of a major release, Red Hat makes commercially
reasonable efforts to maintain binary compatibility for the core
runtime environment across all minor releases and errata advisories.
That's the best guarantee you'll get it seems. Edit: See also Red Hat Enterprise Linux Application Compatibility Policies
During RHEL 5.x and 6.x, we've built many projects whose binaries were run on older minor releases,
I've not seen any problems. (Although the binary interface for these applications is minimal, limited to libc/libstdc++ and 3-4 other libraries - and a few python programs)
(As a side note if you're building kernel modules, the kernel provides no ABI guarantee and may change between minor releases.)
I'd always operated under the assumption that the compatibility guarantee was from anywhere in the series to anywhere in the series but I've seen at least one instance where that was broken (I don't know if that was accidental or not though).
So, for safety, I would probably suggest using the oldest revision of the series that you officially want to support.
Related
Given the availability of a new workstation (Intell Xeon X5690, Windows 7 Professional, 64-bit) for numerical analysis of fluid dynamics models, I find it a shame not engage in parallel computing. So far, I have had no or little experience in this field.
What's the difference between MS-MPI and the latest release of MPICH suitable for Windows? I installed MPICH 1.4.1, but I cannot get a test program to work on Ifort. How am I supposed to compile the program? Do I have to change Ifort configurations somehow to add the libraries of MPICH? Isn't there any good manual available online that could meet my needs?
There's lots of questions in this one question, but it all boils down to one basic question: How do I install MPI on Windows?
MPICH has long since worked on Windows. The last version that supported it was 1.4.1p1 as you've found, but it doesn't have any support anymore from the MPICH developers so if you have trouble, you probably won't find much help. I haven't seen anyone on here step up to help with those questions so far.
MS-MPI is a good option if you want to use Windows. It's free to use and still has support directly from Microsoft. You'll have to read their documentation about how to set everything up correctly, but it's probably the right place to start if you want to use MPI on Windows.
Intel MPI also works on Windows, but it isn't free so you might not want to look at that right now.
I have developped an application on Windows (which works well). I have to now execute this application on Ubuntu. How can I deploy my application ? Is it possible to cross compiled (and if yes how). I haven't seen any tutorial (only Linux to Windows).
Thak you for your help
You cannot cross-compile to "Linux", because that's not an OS.
Certain system-level libraries and interfaces differ from distribution to distribution, making it nearly impossible to get a one-binary-covers-all.
Setting up a cross-compiler is generally a pain in the... nuts, and for Linux->Windows, there is no free alternative (a Windows license isn't free). For Windows->Linux, you can install the distribution you are targetting and compile it natively (perhaps in a virtual machine). This guarantees compatibility with the OS you're targetting and is much more reliable than cross-compiling.
I am starting to create a QT application with sqlite for a hand held device. My Project Manager asks me to select an operating system (embedded linux) for the device (we are not considering android).
As in Desktop, are there many embedded-Linux distributions for devices?
If so, Which embedded linux I should consider?
You have multiple choices, but I will suggest the easier and - in my opinion - better two.
Buildroot - is a set of makefiles that lets you create your custom embedded distribution. Can take care of building the Linux
kernel, the toolchain and a barebox or U-Boot bootloader, too. Easily expandable and
with a practically zero learning curve. You have a fully working
system in a matter of hours.
Yocto - a fully fledged (and complicated) build system. Suggested over Buildroot when you need a LOT of packages/components
and may need flexibility in expanding the system directly on
premises. What you can do substantially depends on the "layers" (sets of rules for building things) available: you combine layers together to obtain your system. Has a steep learning curve but is used and directly
supported by multiple vendors (e.g.: Atmel, TI).
Anyway, unless you have more than good reasons, I strongly suggest the former.
There are several Linux distros to be used with ARM. Maybe you should consider Fedora ARM https://fedoraproject.org/wiki/Architectures/ARM
This is a difficult question to answer not knowing more about the project requirements (not just software requirements, but also non-functional ones as well) and capabilities of the platform.
Angstrom (based on OpenEmbedded) is another possibility for Linux.
I would challenge the assumption that the operating system must be Linux. Why? If time-to-market or having commercial support are important, you might be better off with commercial embedded or RT operations systems such as VxWorks or QNX.
There are also professionally supported Linux distros such as Montavista
Whilst free linux distros are, well, free, you are generally on your own and your team's time isn't free.
You can use Qt for embedded device , it’s fast and compatible with many hardwares and if your hardware is not supported, porting it to a new hardware is not so hard
plus it has special rendering system
I haven't read very much about MPI's implementation yet, but I was asked to setup a third party software statically linked against version 1.4.1pl of MPICH2 with an environment that runs the MPICH2 runtime with version 1.2.1.
Should I expect problems?
It will probably work, but it's not ideal. There are certainly bugs in 1.2.1 that have long been fixed. And since we don't usually test mixed version installations, bugs are more likely to occur in mixed version installations.
If you have odd configurations of the 1.2.1 environment (non-default process managers or PMI libraries), then the odds of a problem increase substantially.
I have recently gained access to a Mac. I am wondering if anyone has any tips/advice for setting up Mono on a mac for development and execution of ASP.NET? Most resources point to Linux implementations which tend to differ a lot from the way Mac's do things. Any tips or advice would be helpful
To launch the development ASP.NET server, just open a terminal window and run the "xsp2" command from the Mono installation.
The only thing that is missing from the Mono distribution on the Mac compared to Linux is the Apache module, that one you will have to compile yourself if you want to deploy your application in production on OSX.
Since I first worked with mono osx, they've added Cocoa# and ObjC#, but the ASP.NET core was pretty solid (about 3 years ago). You can in fact write web applications according to the Onion book, and port 'em to IIS with little or no difficulty.
Honestly if you want to run ASP.NET you probably don't want to struggle with getting it to run via mono on MacOS. Intel-based Macintoshes can boot Windows, and Apple provides Windows drivers for their various devices as part of Boot Camp.
Alternately you can buy Parallels or VMWare Fusion for less than $100. I use VMWare Fusion. There is also a Mac version of VirtualBox from Sun which is free, though I have never used it.
For MacOS development (not .Net) you really should try Apple's XCode. It is free. It primarily focuses on Objective C though Python, Ruby, and other languages can be used to develop native Mac applications.
Edit 9/22: I'm sorry neither you nor Kev found this a useful answer. Let me try to expand a bit: the Macintosh has a long history of software being ported in from Windows, applying a theme to make the GUI elements look Mac-like but otherwise being content with a minimum cost port. Such software never behaves like a real Mac application: it doesn't respond to AppleEvents, it won't be scriptable, it handles only the cross-platform clipboard formats, etc.
You're free to do whatever you want, including running ASP.NET using mono. If its for your personal use, knock yourself out. However if you're considering it as a way to offer your web-enabled product in a Mac version, I urge you to reconsider. The Mac market has for the most part rejected such products. You'll get some sales, but nothing like you would get for an app which behaves like a native Mac application.
Now, let the down-voting continue.
You can also run ASP.NET via NGINX - easy to install using:
sudo brew install nginx
See installation tutorial: http://www.robertmulley.com/tutorial/nginx-install-and-setup-mac-os-x-mavericks/
See configuration steps for your app: http://www.mono-project.com/docs/web/fastcgi/nginx/
(Note: see my pull request as the fastcgi-mono-server4 should now be used - https://github.com/mono/website/pull/82/files)
Why use Mono on a Mac? Run Parallels, VMWare, or Boot Camp.