I am interested in writing a Vala program that will determine the present operating system and act accordingly (exactly how it will act I have not decided yet, but is not relevant to this question). So what I would like to know is how I might determine the present operating system (including the specific distribution in the case of Linux) in a Vala program at runtime.
Unless you are writing system level code (like package manager or OS configuration code), you shouldn't. A much better alternative is to use a library that already abstracts the distribution specifics for you.
If you absolutely have to there are two main ways to do it:
At build time
Here your build system should be responsible to detect the OS / distribution and either pass a define to the compiler (like -DDISTRO_UBUNTU) or write a config.vala file (possibly from a template config.vala.in with replacements, e.g. autotools has the AC_CONFIG_FILES facility to do this).
At runtime
Here your tool does the detection itself when it's running.
Which fits your application better is a design choice.
As to how to do it there are several things you can check:
uname -a (or other parameters, see man uname) will give you the kernel that is currently running.
lsb_release -a (not available on every distro, sometimes an optional package which you might have a package dependency to) will give you information on what distro and what distro version you are running on.
On Debian/Ubuntu derivates there is a file called /etc/debian_version which gives an indication of what release is currently installed. That information is not totally accurate though.
Some people are trying to read /etc/issue, but that is dangerous, since that file could be modified by the admin / the user.
You could ask the user which OS she is running.
There are also some os info libraries that you could use.
You might use the uname(2) syscall (how to do that in Vala is left as an exercise to the user), or read /proc/version (see proc(5)), or read /etc/issues or follow Linux Standard Base conventions (e.g.popen the output of lsb_release -a).
But as Jens Mühlenhoff answered, you should not do that, and avoid writing code depending on some particular distribution.
And some users might want to fake or hide that information (think of someone having some "Linux From Scratch" system).
Related
Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?
I'm thinking something like passing a -target to the swift command and passing another parameter to let it statically link all dependencies, but I'm not sure what the exact commands are.
The exact value for -target seems to be rather elusive.
Do I need to know the exact target distribution to be able to pass the correct string to the -target parameter?
From reading the sources on github
target would be Linux
machine would be x86_64
This gets called by the primary build script
This how ever answers a part of the question
The exact value for -target seems to be rather elusive.
Install a GCC toolchain for Mac OSX that can retarget Linux, one repo that I can see is OSXCross, for example.
Supply the values to the environment variables to GCC prior to running the script, that references that toolchain.
Unfortunately, that does not guarantee it will work, but give it a try and see what happens.
Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?
The short answer? Of course it is! Anything is possible when you put your heart to it!
Is it efficient? Inherently, no.
While I'm sure everyone here is familiar with what a compiler does, for the sake of this question and its newest of users, a compiler is an application that converts human readable code and maps it to a binary format that a computer can understand. However it should be worth mentioning that not all computers are the same. Each computer operating system has a different binary mapping than the other so a simple operation like copying values could be expressed as 1010 on one machine, and 0101 on another. As stated before in many questions prior, and for example this one, many programming languages are buildable across a variety of machines, but very few of them are portable across them because each computer has a different binary mapping.
~~~~~~~
So how do we fix this?
~~~~~~~
Well there are a number of solutions to fix this. The most obvious
method is to simply make your environment the target environment and
build your program to your hearts content. You obviously already did
this through a virtual machine and this typically what many
developers will do. This is by far the easiest solution but it
defeats the purpose of the question where you want to simply build
from your OSX machine.
Earlier you said you heard people talking about compiling windows programs on linux machines. Cygwin is a a development platform aimed at obtaining the windows framework that is not normally present on linux machines and allows many programs to be built with the windows framework in mind. However all its doing is adding binaries so that the compiler has some proper places to map to when windows only commands are found within a configuration. All its doing is introducing the binary configurations necessary for a program to successfully be ported over. This ties into the second option.
Secondly comes a compiler that supports cross platform compilation.
While I am currently uninformed and/or unfamiliar with such
compilers, this is technically a valid solution but would I call it
reliable? Probably not. If anything you're just adding more work to
your compiler as not only does it have to correctly map the syntax of
one computer program for one computer, it has to waste time linking
it to the new binaries. Additionally you would need to have the
compiler remember these linking's which could entail more wasted
memory space for having this one compiler.
Even then, systems like these are few and far between and whether its guaranteed to work depends upon how well the compilers maintainer knows their stuff, how frequently they update it etc. etc. And the chances that they even performed to correct mappings of binaries in the first place is not something I'd stake my life on.
The third and perhaps most ideal solution is to look into container technologies such as docker. Their containers are essentially ways for you to build your app and port it to new machines without having to change or modify anything about how you build and compile it. Simply build one, store it in a container, port it to your machine of choice and integrate it into your current project. Come to think of it, container systems like docker were built to prevent the very thing that you are currently experiencing, where you have a source code working on your one machine but no place else. Something like docker will be able to run your code on any machine without having to recompile it for each new machine.
Docker provides an interesting framework for container to container communication, application examples and has a fairly straightforward documentation that it would be worthwhile to look at to see if your project could have some of its parts ported to docker.
This being said, there are multiple ways to fix the issue you are currently facing, so as you being a software engineer, its up to you in what would be the most ideal way of handling your project.
// EDIT //
Will edit this to be a better response once im not drop-dead tired.
I have been programming in java for 3 years but I have no experience with other languages. I want to know what I need to study in order to be able to make an operating system. Am most likely going to make my operating system based on Linux kernel. What programming languages should I be familiar with and what aspects of the pc hardware should I study. if you know any online tutorials or good books please mention them.
The answer depends on how far you want to go and how much you want to write yourself vs using existing code.
The most straightforward way is to have a look at Arch Linux or Gentoo and build your own, custom Linux setup. Approximate time needed to create a minimal working system: ~2 hours
You could, otherwise, compile the Linux kernel, build some software packages and put it all together yourself and create your own Linux distro - i.e your own operating system in a sense. Linux From Scratch will be an invaluable resource if this is what you decide to do. Approximate time needed to create a minimal working system: ~2-5 days
Say that's too easy for you but you're not ready to delve into the nitty-gritty of kernel development. You can write your own applications that run on top of the Linux kernel. Typically, you'd need to know C/C++ but any language that supports running on Linux/compiling to a Linux executable will work. Heck, you could chuck a (or write your own) Java runtime on and write your whole 'operating system'/user-space in Java. Approximate time needed to create a minimal working system: ~6-12 months
What about if you want to get down to programming your own kernel from scratch? Heck, Linux is overrated and you want to write your own kernel and it's going to be the next best thing! You would want to learn a bit about the platform you're developing on. At the very least, you'll need to know the assembly instructions of some special operations for your platform that can't be done natively in C like switching CPU modes. You'll definitely need to read up on the OS dev wiki for this and you should have a fair decent computer science background.
At this point, you shouldn't need too much other than a good tutorial, C, a little assembly, reference manuals for the hardware you're hoping to support and 3+ years of computer science background to get you started. Your boot loader that's booting your kernel should handle most of the hardware initialisation. Bootloaders like GRUB (I'm assuming you're developing on a x86 system) does so much for you that it can probably just jump to your kernel main function straight away without you having to do too much. Again, if you wanted, you could port or write your own Java runtime in C and write the rest of your kernel in Java! Approximate time needed to create a minimal working system: ~3-5 years
But, let's just say you're screaming for more pain and you want to write an operating system really from scratch and you don't want no bootloader doing a lot of the legwork. What do you need? Firstly, you'll need a lot more reference manuals. And you'll need to read up on a lot more assembly. Especially for Intel processors, there's a lot of work involved bringing the system up from 16bit mode to 32/64bit protected mode with paging (which is what I assume you want). You'll also want to know about every tiny quirk and weirdness of your platform that will affect your OS (these are often not documented; hooray!). Plus, all of the above. In short, you will need to study everything. Approximate time needed to create a minimal working system: 5+ years
Of course, this post is just scraping the surface of what is needed to even bring up a basic operating system capable of say, opening a web browser. The approximates roughly assumes a minimal working system is something capable of running a graphical web browser and will vary depending on how much you want to write.
I don't mean to be condescending but this is the kind of reality you'll be facing if you decide to write your own operating system. Nevertheless, it is a valuable learning experience if you can break the initial barrier or even just trying to set up your own Linux system.
First, I would say that you install any Linux OS on your system and get accustomed with it.
Second, for OS development you have to know C language. As for the Assembly language, it depends from where you start the OS development. If you will be using available bootloaders, then I don't think that you will be requiring to learn assembly language.
This is a website on OS development: http://wiki.osdev.org/Main_Page
There you will find all the stuff you need to know for the OS development. And also how to develop OS step-by-step.
Now-a-days, a "Eudyptula Challenge" is going on. It is a series of programming exercise for the linux kernel. You can find more info here: http://eudyptula-challenge.org/
Does anyone know of a scripting language that's included with most platforms (say Mac/Windows/Linux)? I haven't been able to find one. So far javascript in web browsers or compiled java are about it. Jython comes close.
My goal is to be able to download a file from the web or portable storage and just run it, without having to install something first, or have special user permissions, or edit it, or rename it, or give it executable privilages. It would give you access to generally accepted metaphors in computing: input, output, persistent storage, time, spawning tasks, sockets, fixed and floating point math, unicode, etc. Ideally it would abstract away minutia like line endings, endianness, and yielding for other processes.
I don't want to get into why having a universal language/virtual machine is important, or at the very least, useful. I feel that we are missing a middleware above the operating system level, something like POSIX but less esoteric, and without it, we all are forced to spend a disproportionate amount of time reinventing the wheel or writing special cases. For me, availability and a complete feature set are more important than speed (which could come later).
Thanks in advance for any insights you can provide,
Zack Morris
You will be able to run carefully written sh scripts on almost all unix systems.
If you want to add Microsoft systems, then it is more difficult, but still possible to provide a single script file, that will "autodetect" the interpreter it's running on and select between a sh part and a command.com or whatever they have on Microsoft systems.
Once you can run a script on a known system you can further download or unpack and install automatically whatever software you need.
Is it possible to write system level source code in Vala.
like for a small Micro kernel OS?
or for use it in the Linux kernel for modules or device drivers?
Technically, yes, but in reality it's probably not very practical.
People have written kernel modules in Vala before, but AFAIK nothing really serious. Actually, someone wrote a Multiboot kernel using Vala a few years ago.
You can get around the dependency on GLib by using the posix profile (pass --profile posix), but it tends to be a bit buggy and lots of features aren't supported, including a lot of the stuff that makes programming in Vala a pleasant experience.
I don't think so. Vala is tied to the GObject and Glib gtype type system (inside GTK) - including its reference count based memory management. The Linux kernel uses a different (even if conceptually similar) memory management. And inside your microkernel OS, you need to provide one.
Some update to the answers above: the posix profile has been deleted from vala codebase in version 0.17.4, because it was unmaintained. Here is the announcement.
we start to write plug in for eclipse to work with some java frame work like hadoop (we want to edit hadoop eclipse plug in and merge it with other. our plug in must work in Linux operating system. Generally writing plug in for eclipse depend on operating system or not? if depend what benefits to write it for Linux?
Well, the previous answer is correct... in most cases. You should specifically check all the interfaces with the operating system.
SWT is a Java wrapper over native OS widgets. It behaves almost the same on all OSs, but not exactly. There are subtleties. For example, events that might be fired a bit differently, drawing of widgets, etc. My experience shows that you have to check on all OSs to be sure that it works as it should, especially if you are doing more complex UI rendering. In many cases I had to do some fine tuning to get it right. It is not a great deal of effort, but it should be considered.
Another issue is working with the file system. For example, make sure you are composing files paths correctly. It is always a good idea to test that part as well.
Eclipse plugins are platform independent (you are writing them in Java), unless your plugin requires some low-level calls to the operating system (i.e. JNI) or to invoke some tool found only in the Linux OS.
The only part of Eclipse tied - in part - to the OS is the SWT toolkit, since it's optimized for the graphic environment you are running it, but if Eclipse can run in the OS you are interested in, you should not be bothered by this.