I want to run multiple versions of MATLAB (with standalone licenses) on a Windows XP home computer. One is MATLAB R2007b and the other is MATLAB R2009a. I found some docs online (link and link), but nothing related to the latest versions. Has anyone tried this?
You can do that, just install the new and the old versions in different directories.
FWIW if you have the chance to run MATLAB R2009b rather than R2009a, you might want to. I haven't looked in detail at the release notes yet, but I noticed already that the language in Simscape has been improved in R2009b + now I have to reinstall it yet again to get the upgrade...
I've been running MATLAB both on my desktop and in a virtual machine successfully for a while now. I happen to be running the same version in both right now, but there's no reason why you couldn't run different versions in and out of the VM. This setup allows me to keep a stable working version of my application available that I can rely upon to satisfy the need to rapidly analyze data while simultaneously having a separate development version that may or may not be fully functioning at any particular time.
You could use Octave which is an open source 'alternative', should sort the issue out nicely
Related
We’ve been trying to get SikuliX 2.0.5 to run on a RHEL 8 system, and not having much luck.
We went through the instructions on this webpage:
https://sikulix-2014.readthedocs.io/en/latest/newslinux.html#newslinux
We started on RHEL 7, but the OpenCV shared library required a newer version of GLIBC than is standard on RHEL 7 (version ‘GLIBC_2.27’ not found (required by ~/.Sikulix/SikuliLibs/libopencv_java430.so)), so we moved up to RHEL 8. We had to build OpenCV (v4.3.0) from source because we could not find a java companion package for RHEL 8, which required quite a few other dependencies, but in the end we got it built with most options enabled, and installed as root on the system. We also got Tesseract installed via a package, as well as xdotool and wmctrl.
We are setting LD_LIBRARY_PATH to ensure that the OpenCV libs are picked up, and when we run with the “-v -c” options to the IDE, there are no obvious problems reported. It seems to believe it is moving the mouse, though we can see that it is not, and when we try to capture a screenshot, the “canvas” from which to capture is either uninitialized/garbage frame buffer memory, or a totally black screen. On rare occasions we have seen the actual desktop, but most times we do not.
Originally the system had 2 monitors, but was subsequently reconfigured to a single display system. We were originally running remotely over NoMachine, but have also tried running locally and observed no difference in behavior.
Any pointers or suggestions would be most welcome. Given that no error messages are being reported, we are out of ideas for how to proceed in debugging the problem. It appears that more native support is provided for Debian-based systems, but we’re attempting to validate a product which only advertises support for RHEL systems, so we’d prefer to get it working in this environment if at all possible.
I have installed Motioneyeos on a Pi Zero and on a Pi2, and it works like a charm in both of them. The control of the 2 systems can be unified on the web server of any one of them. The web interface is clear and allows to customize hundreds aspects of the program. Anything perfect so far.
Trying to understand a little bit how does it work, I have logged to one of the 2 Pis through ssh and I have checked that the OS is kept to a bare minimum. uname -r returns 4.19.65.
On the web interface of the app it is possible to check if the last version of the program is the one running. I have checked, and yes, I have the last version.
My question is: does it make sense to upgrade the OS components used by the program (apt update, apt dist-upgrade) even if the last version of the program is the one running in my Pis? Apt is not even installed, so the first thing would be to bring it there and install it, but I am afraid that if I update the OS, the program may stop to work...
I answer myself thanks to the feedback received in another forum. Motioneyeos is an embedded software based on Buildroot and as such it is not possible to install any package on it. To be able to install a package on Motioneyeos, Motioneyeos has to be installed on an full OS as Raspbian following the instructions in Motioneyeos web ==>>
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.
Put succinctly I need a base for my system, since it was built on macOS Darwin seems like the logical choice as it will require the least porting effort. I know you can download up to Darwin 8.0.1 from Apple, and the full source tree is available for up to 10.0, however v8 is too old and lacks many standard modern features (i.e. a password system that doesn't restrict the root user to 10 characters, or support for the case-sensitive version of HFS+). I've tried building Darwin 9/10/11/12 from source using darwinbuild, but it always fails for various server-side reasons.
There has to be some way to create the equivalent of a vanilla Darwin 16 image. Perhaps taking an existing copy of macOS and stripping away all the closed-source stuff? Building the source that Apple provides at Apple Open Source Repository and substituting the rest of the packages required for the OS to function with source from another BSD distro? Taking an existing copy of FreeBSD and substituting the kernel with XNU? There has to be some way. Any ideas or thoughts on the ideas I suggested are welcome. Thanks.
The last xnu build instructions are for El Capitan (Darwin 15) but you might be able to follow them for Sierra (Darwin 16). The latest source available at time of writing is for 10.12.4, which isn't overly out of date.
This gets you most of the kernel of shipping macOS. It doesn't get you the driver stack - especially the SATA/AHCI stack is not open source, which could be a problem. (One of these days I'll get around to publishing our full virtio driver stack including virtio-blk and virtio-scsi drivers, with which you should be able to run without SATA in Qemu/KVM at least.)
I have no idea about getting a useful userland going - macOS/OSX uses launchd as its "init" process, and the last published source code for that is some years old. I don't know if it will need some tweaking to get it working on newer kernels.
I have a program which I try to run on two computers. On one computer, it works fine. However, on the other computer, it hangs while attempting to create a USB channel. I do not have the ability to look inside the program. What is the best way to determine the differences between the two machines?
dxdiag will give you information about the specific minor versions of XP you're using. From there, I'd build two virtual machines, upgraded to the specific versions of windows.
From there, begin installing software one-by-one on the failing machine until you can reproduce the error. If this doesn't work, you might have a hardware issue, and then you're really SOL.