This question is for experienced Unix/Linux developers.
If you have found that you like Mac OS X better than *nix as a development platform, why is that?
I know that hardware configuration is more convenient and graphics are generally more polished, but I'm not referring to those things. I'm asking specifically about functionality related to software development.
Also, do the benefits still apply if you are mainly targeting Windows or Unix/Linux?
For most purposes, OS X is Unix. Aside from Xcode (which I personally don't care for), there isn't really anything there to make it better or worse than any other Unix-like system for development.
Most of the typical tools, libraries, languages, and interfaces are there, you'll even be using GCC for C/C++ work. As long as you're not developing against Apple/OS X-specific interfaces like Cocoa, you are developing on Unix.
I use OS X because it just works, thus not interfering with my development, not because it has magical fairy dust that makes it better than any other Unix for development.
I love Apple as a dev platform because I get all the power of the *nix commandline as well as Apple's developers tools (XCode).
The additional software/hardware polish, and quality of third party software make it all that much more enjoyable.
Mac OS X is not better than a Unix environment, it is a Unix environment: http://www.opengroup.org/openbrand/certificates/1190p.pdf
I'd go as far as saying it's probably the most used Unix, considering it's also in all iPod Touch and iPhones.
(As far as I'm aware, Linux isn't a certified Unix, but I may be wrong, perhaps a distribution/vendor went through that process.)
Sometimes, for professional reasons, you just have to have tools that are compatible with what your boss or customers use. This often includes proprietary tools like MS Office, whether you want it or not (OpenOffice can't always deal perfectly with Word documents). OSX provides this intermediate ground, where the developers can also be users or closer to their user base.
Related
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 have to port the application which is using the Qt3 library to a new embedded OS.
If the OS is not yet selected but it is known that it is not Linux/Windows, what is the general way of porting procedure? I mean what files should be changed and what are independed and can be left as is?
If it's not Linux or Windows you could be pretty stuck out the door. Qt is highly dependent on libraries being available for it to be able to build. This is not a no however, it has been ported to Symbian which is obviously not Linux or Windows. The big thing on that though is that it was ported by Nokia, who had amount of time and amount of developers, where those X's are reasonably big numbers.
Start by getting the Qt everywhere source code, work out what bits you're going to need and which bits you won't. If the platform has gcc/g++/another reasonably well understood C++ compiler you're in luck and you should be able to build the bits as needed. Qt does depend on standard libraries throughout so make sure they're also available in some form for the platform, and it does use some non-standard ones for some components so you'll need to know which aspects of Qt you're working on. You should be able to get some sort of toolchain from there.
I'd stick to platforms that Qt supports though, if you go off the beaten track you're looking into increasing your dev times and having very little useful support.
Well, I need your advice.
I'm working on a huge engineering project, everything is ready now (resources and formulas etc) and it's time to start coding. I don't have any problem with what language to code with (i know a lot).
but they're the users who are pulling me off.
I use Windows as a primary OS but there are a lot of Mac and Linux users too. And these days tablets have taken a lot of developing space ( Android and stuff).
So what option do you advice :
1)Write the program from the scratch on each OS, I mean writing the program on Windows using Visual Studio, on Mac use Xcode.
but this costs a lot ... I own Windows PC, buying Mac or Mac OS for my desktop, will ruin my budget.
2)Use cross-platform compilers ...
It is nice. but how about the commercial use? I have read that I need to buy a commercial license in order to publish my apps worldwide.
please if this is wrong tell me about it.
so really I don't know ... shall I just deploy it for Windows?
Also if you know a great option for cross-compiling would help a lot .
Your Advice Is Appreciated
Best Regards
What kind of app is it?
If it's just a number crunching app with a very simple front end then can you write a commandline version and wrap it with a web script?
If it needs very responive rich user interface and you can program in C++ then Qt is a very good solution even if you don't need cross platform.
The LGPL license is perfectly suitable for commercial apps.
I want to study and compare executable file structure of elf, SPARC and PA-RISC.
To perform the studies I want to install OpenSolaris on an Intel machine (Core2Duo).
But I got a basic doubt will it work at all ?
I know SPARC has its own assembly - grew in suspicion if it will work or is valid thought at all.
I was aiming to write some programs disassemble them and with some help of tools study the file structures.
I don't have any clue how to perform all this for HP-UX (PA-RISC); dont know any free OS for PA-RISC.
You won't be able to run Sparc or PA-RISC executables on an intel processor. However, if all you want to do is to analyse the structure of these executables, all you need is suitable development tools.
I haven't checked, but I suspect OpenSolaris comes with development tools capable of analysing Solaris/sparc executables out of the box. But even other toolchains can do that. For example, GNU binutils (specifically the BFD library they use) support many architectures, including Sparc and PA-RISC. (If you use GNU binutils, make sure you get a full version, perhaps labeled as “for cross-compilation”, e.g. binutils-multiarch on Debian or Ubuntu)
SPARC:
I have never installed OpenSolaris on anything. You might consider trying NetBSD: it runs SPARC machines at least as well as Solaris did, and it uses ELF format executables. The source code is freely available for study, too.
You will need to understand the ELF file format. I don't recall any particular document standing out back in the days when I wanted to understand ELF, and it looks like Google can offer a large number of web sites that will explain ELF. My advice on ELF is to write a program to read the ELF headers, and then dump them out in a readable text format, even though many such programs already exist.
You will also need a SPARC disassembler that understands ELF. I wrote one a long time ago, it will probably work reasonably well today. http://www.stratigery.com/elf_dis.tar.Z
You can download PDFs about SPARC here: http://www.sparc.com/specificationsDocuments.html I recommend the SPARC V8 and V9 architecture manuals.
PA-RISC:
This is a very odd architecture, with very little in the way of documentation. I believe that PA-RISC was Apollo Computer's (R.I.P) RISC architecture, then HP bought Apollo in 1990 or 1991. The stack grows down and the heap grows up, where just about everything else has it the other way around. It also has a segment register, but one that works differently than x86 segmentation.
HP is really the only place to find anything about PA-RISC.
There are ports for PA-RISC architectures of Linux, NetBSD and OpenBSD.
You cannot run code compiled for Sparc or PA-RISC on an x86 system, unless you use a full-fledge emulator. Qemu can emulate a Sparc-based machine, with enough accuracy for running a Linux operating system on it (but it will not be fast: Qemu must interpret all Sparc opcodes one by one, and this has a heavy overhead, so a fast PC from 2011 may perhaps yield the performance of a Sparc workstation from 1996). There is an ongoing project for adding PA-RISC support to Qemu but it does not seem to have reach any non-trivial level of usability yet.
I'm in the research phase of my next computer build. I have the idea in my head of running a hypervisor as the base of the system, but i would want to be able to take a shot at programming opencl with one of the OS's installed on the hypervisor...and maybe some gaming. Would i have enough access to the GPU to be able to achieve this effectively, or am i better off installing an OS that i will do development(and gaming) from and then just virtualize any systems on top of that?
what are your recommendations for a hypervisor, vmware, microsoft or other?
sidenote: Recently graduated with a BS in CS, the massive parallel processing seems like a good idea of something to learn, won't be doing any 'real'/major development work. also, i'm aware that CUDA is more mature in it's development, but i'm sticking with opencl for a few reasons, so please don't try to persuade me.
thanks for your input!
dave k.
whats your focus? Virtualisation or OpenCL?
Hak5 did a nice walkthrough of debian based virtualisation environment ProxMox, but I don't know whether it allows virtual hosts hardware access or OpenCL virtualisation.