Are there any major differences between a modern Linux and QNX Neutrino that would make porting an existing client/server difficult? The source is normally built using Qt's qmake, but has no other Qt dependencies.
I need to provide an estimate for how long this process will take, but I've never used QNX.
If it matters, this will run on an ARM CPU, but we already build for ARM on Linux as well.
It's really going to be hard to estimate until you try because there are a lot of similarities, but where there are differences can be more problematic. If I were estimating, I would start by downloading an eval copy of the QNX and try building to see what problems you are facing.
The biggest issue may have is if you are using a GUI. QNX uses it's own GUI technology which is not X. (Although Qt 4.7 has been ported to QNX 6.5, so if you were to use Qt, it would probably work.)
Related
I'm going to produce VoLTE packet stream on OMNET++. Which OS is recommended for installing OMNET++, Linux or Win?
My laptop system is win10. If Linux is better, is there any problem if I use linux on VBox?
Thanx for your kind recommendations.
Linux [1] is definitely the recommended OS for using OMNeT++.
In particular, you will have the best experience with Ubuntu 18.04.1 - if you're using the latest OMNeT++ release that is. Older versions might work better on earlier Ubuntu releases.
Running it in a virtual machine should not cause any issues.
The only case that might be problematic is using the 3D integration (OSG and osgEarth). Rendering performance might be worse (or it might not work at all), but this depends on your setup. There are a few GPU/driver/config/etc. combinations where even this works quite well.
EDIT:
The reason is that even though Windows is fully supported as well, it simply performs significantly worse - especially during building either OMNeT++, or any model libraries or projects. We suspect that it is caused mostly by how NTFS works, among a variety other things.
On top of that, certain "more exotic" features in some model libraries might only be available on Linux.
[1]: Well, technically it's GNU/Linux, or more appropriately, GNU+Linux. :D
I suggestion Linux (Example : Debian, Fedora) or Unix, Because Linux or Unix have most stable using develop OMNeT++ to working great.
I've heard that Smalltalk is also an OS.
How can I install Smalltalk on my X86 instead of Linux or windows?
What are the steps to do that?
Any tutorials on installing Smalltalk on a bare-metal machine ?
I don't know if there is a standalone smalltalk environment, but you can try squeak, which runs above your os (linux, windows or mac). Not just an os but a complete working environment.
There was a project called SqueakNOS. That was the only post-PARC experiment to use Smalltalk directly loaded over the hardware, with no other operating system. It had even a version to work on an OLPC.
I don't know if currently someone follows that development, but it's very interesting and an excellent place to learn about hardware, in human-readable (but executable) terms. You can see and debug how a device driver works, for instance.
Smalltalk Virtual Machine is handling memory allocation, access to file systems, network connections, process (green thread)...
So viewed from Smalltalk world, it is very similar to an OS.
But how to implement the virtual machine without an underlying OS?
There is a project SqueakNOS and a fork PharoNOS meaning No Operating System, whose goal is to completely bypass the OS, and have Squeak/Pharo running on bare hardware.
So yes, it's possible.
But what you'll get with this is still a Smalltalk world, maybe not what you expect from a linux or windows distribution...
I am an ASP.NET developer, but now I want to build a software that can be installed on my PC. Software built in .NET platform only works when the .NET Framework is installed, and software written in Java only works if the JDK is installed. When I install programs like Firefox, uTorrent, etc., I don't need to have any frameworks (.NET, JDK, etc.) installed. How do I write software that doesn't depend on a framework?
You will have to use a language that isn't dependent on a framework or otherwise only target clients that are already have your framework installed.
If you chose C or C++ for example, you would distribute binaries to your client that contained machine code. This code would not be dependent on a runtime environment (like C# or Java) or an interpreter (like Python or Ruby). This is the way that applications like Firefox and uTorrent are written.
"When I install programs like Firefox, uTorrent, etc., I don't need to have any frameworks."
Actually, you do. They just tend to use the C++ frameworks, such as MFC, some of which are already installed. Even then, there are installers for these frameworks that are included with other application installers (usually called Microsoft Visual C++ 2008 SP1 Redistributable Package or something like that. See Also: Visual C++ Deployment).
Now, having said that, they don't require a virtual machine (like a JVM for Java or a CLR for .NET), because C++ compiles down to x86 / x86-64 machine language to be executed directly by the operating system.
Fundamentally you always have a "platform", which is the operating system. Traditionally if you want to write code that will run on multiple operating systems you would use a fairly portable language such as C++ that produces native executables for a target operating system. Still, there are differences between how different operating systems work. There will therefore be parts of the C++ (or other portable language) code that are specific to that OS. You try to isolate those parts as much as possible to minimize the effort to port between OSes. Still, that effort is typically very substantial. You are also limited to the least common denominator of features available on all target operating systems (unless you create a custom version for a given OS that exposes its special features).
This is complex, time consuming and expensive. That's the reason technologies such as Java and .NET were created.
If You want to build really platform independent software You will finally end up with solution like Java Runtime or .NET. What You could do, You could thing about writing application in such way that You are able to compile/run it on most known platform, and of course then You need middleware to translate Your application's objects into platform objects (functions, whatever...).
I have seen solutions made in Pascal for DOS in such layer of abstraction that with little effort it was moved directly to Delphi for Windows without touching application logic.
Does anyone know of a good software development framework or similar that has the following properties?
Cross platform: it should be runnable on XP, Vista, OSX and common versions of Linux (such as Ubuntu and Kubuntu).
No installation: Be able to run the software from a USB stick without having to copy anything to the host machine.
Have good GUI support (this is why this question doesn't give a suitable answer, as far as I can tell).
Permissive licensing such as LGPL or BSD or such.
Among the softer requirements are having a set of abstractions for the most common backend functionality, such as sockets, file IO, and so on (There is usually some platform specific adaptations necessary), and supporting a good language such as Python or C++, though it is usually fun to learn a new one (i.e. not perl).
I think possible candidates are Qt 4.5 or above (but IFAIK Qt software will not run on Vista without any installation(?)), some wxWidgets or maybe wxPython solution, perhaps gtkmm. The examples I have found have failed on one or another of the requirements. This does not mean that no such examples exist, it just means that I have not found any. So I was wondering if anyone out there know of any existing solutions to this?
Some clarifications;
By "framework" I mean something like Qt or gtkmm or python with a widget package.
This is about being able to run the finished product on multiple platforms, from a stick, without installation, it is not about having a portable development environment.
It is not a boot stick.
It is ok to have to build the software specifically for the different targets, if necessary.
The use case I am seeing is that you have some software that you rely on (such as project planning, administration of information, analysis tools or similar) that:
does not rely on having an internet connection being available.
is run on different host machines where it is not really ok to install anything.
is moved by a user via a physical medium (such as a USB stick).
is run on different operating systems, such as Windows, Vista, Ubuntu, OSX.
works on the same data on these different hosts (the data can be stored on the host or on the stick).
is not really restricted in how big the bundled framework is (unless it is several gigabytes, which is not really realistic).
It is also ok to have parallel installations on the stick as long as the software behaves the same and can work on the same data when run on the different targets.
A different view on the use case would be that I have five newly installed machines with Vista, XP, OSX, Ubuntu and Kubuntu respectively in front of me. I would like to, without having to install anything new on the machines, be able to run the same software from a single USB stick (meeting the above GUI requirements and so on) on each of these five machines (though, if necessary from different bundles on the stick).
Is this possible?
Edit:
I have experimented a little with a Qt app that uses some widgets and a sqlite database. It was easy to get it to work on an ubuntu dist and on osx. For windows xp and vista I had to copy QtCored4.dll, QtGuid4.dll, QtSqld4.dll and mingwm10.dll to distribution directory (this was debug code) and I copied the qsqlited4.dll to a folder named "sqldrivers" in the distribution directory.
You mention wxWidgets but dismiss it as failing at least one of the requirements.
I don't know what your requirements are and in what way wxWidgets wouldn't work for you, but IMO it does fulfill them:
Cross platform: it should be runnable on XP, Vista, OSX and common versions of Linux.
It does run on those platforms, but "common versions of Linux" isn't good enough, as you can never be sure that the necessary GUI libraries for wxGTK (which should not be linked to statically) will be installed. This is however a problem for other solutions as well, unless you plan to put everything onto the stick.
No installation: Be able to run the software from a USB stick without having to copy anything to the host machine.
See the previous point, you would need to specify which libraries are needed on Linux. Also you could specify at build time not to use some of the system-provided libraries (for example for graphics, compression, regexes) but to use the wxWidgets-internal libraries instead.
Have good GUI support
Check.
Permissive licensing such as LGPL or BSD or such.
Check. You can statically link wxWidgets into your application too.
supporting a good language such as Python or C++
Supports both, and there are bindings to other languages as well.
having a set of abstractions for the most common backend functionality, such as sockets, file IO, and so on
It does have some abstractions like that, but you can link to other cross-platform libraries as well.
We use wxWidgets for FlameRobin, a graphical administration program for the Firebird SQL server. It has active ports to Windows, Linux and Mac OS X, and has been compiled for at least some BSD variant and Solaris as well. It definitely runs from a stick on Windows, I haven't tried with Linux or Mac OS X, but I don't see why it shouldn't there too.
Java.
It has GUI support.
It provides your network/file/etc. abstractions.
It is cross-platform. Most platforms you can think of have a JRE available.
No need to install a JRE. Most users probably already have one, and if not, you can run the appropriate JRE right off the stick.
You can provide several startup scripts for various platforms to run the app under the appropriate JRE.
Something else to consider is HTML+Javascript. :D
You can look at Mono it cross platform, has GUI (GTK+, or Winforms 2.0) and I can execute code without installing.
This might not be crossplatform, but is maybe even better, it dont even use the platform : linux on a stick :-)
The subtitle is
Take your Java workspaces wherever you go on a USB key
Here with java and eclipse, but nothing stops you there of course.
http://knol.google.com/k/inderjeet-singh/installing-a-ubuntu-hardy-heron-java/1j9pj7d01g86i/2#
Well, it depends on what you mean by 'package'. Kylix came close to being such a thing. It was QT based, and it allowed you to write once and compile for Windows + Linux. However, it was not an open source solution.
I asked a similar question in this link
http://www.24hsoftware.com/DevelopersForum/CrossPlatform-C-Library.html
and the best asnswer seems to be QT.
I have started using QT, but it is not as easy as I expected mainly due to deployment problems due to the DLL hell, Winsxs hell and manifest hell.
Tclkit is a single-file, self-contained Tcl/Tk system. The mac version I have is about 3.8 megs. You can get a version for just about any modern OS. I carry around a thumb drive that has mac, windows and linux binaries so I can run my scripts on any platform. No install is required, just copy one file wherever you want.
The most recent versions of tcklit use native, themed widgets (though, on *nix there really isn't a single "native" set of widgets...)
How compatible is code written under Solaris with Open Solaris ? I would be interested specifically in some kernel modules .
I think it is hard to quantify software compatibility, but I'd say code written for Solaris is quite forward compatible with OpenSolaris kernel. OpenSolaris source code evolves into what will be Solaris 11, and Sun's commitment to backwards compatibility is quite a fact.
Kernel modules written for Solaris should function in OpenSolaris following a simple recompile providing you are using the exposed kernel APIs that are compatible between the releases that you are using in Solaris and OpenSolaris.
There is a huge amount of work in Sun to ensure that programs written using publicly exposed interfaces are compatible. There is a listed 'Exposure/Stability' entry at the bottom of manual pages for most APIs that state in defined terms how someone can use it.
Kernel modules in particular will be very compatible between Solaris and OpenSolaris. OpenSolaris (via Project Indiana) is evolving the user-space components more heavily, including the installer and packages.
This is with regard to core OS daemons only and not kernel modules, but I've had success compiling OpenSolaris components from source and using the resulting binaries on commercial Solaris just fine. It's obviously easier with a Makefile but I did one manually.
I tried this with a small handful of binaries that I needed to add debugging output to and compiled them directly on the commercial Solaris system using gcc without issue. As mentioned earlier YMMV based on what app/module it is.