Similar as to how RetroPie works, can I use a Linux app as my desktop environment? I don't actually need things like an actual desktop and installing apps. I just need to have a clean simple way to run my application and MongoDB on a RaspberryPi.
Quick answer: "YES, but..."
X VS Desktop Environments
You will need a graphical server, but you can avoid using a Desktop Environment!
In Linux, your graphical programs relies (at least) on an X server to work properly. This means you'll never find (if not specifically crafted as a programming exercise) totally independent applications with custom internal libraries and a bult-in environment.
That exactly why X were invented!
But X is NOT your Desktop Environment... in fact, DE runs over X.
Yet, you can go very minimal with some applications using X without any DE.
Let's going minimalistic:
I assume you maybe want a fully functional web browser.
Let's take a common example, Firefox:
Firefox requires X server.
You'll need to manually install X server first, then Firefox.
Either way, if you can rely on a package manager, it should install the bare minimum of the packages, including the X server.
Then, you just need to run the X server without the desktop environnment. Basically something like:
$ X
Then you just start Firefox in this X server:
$ DISPLAY=:0 firefox
You can switch from the X server and the framebuffer by using CTRL+ALT+F1 and CTRL+ALT+F7.
So, in some way, you could also use all seven framebuffers (from F1 to F7) to handle up to 7 graphical programs in 7 different X server processes.
Please notice that this is not the way many applications are intended to run... you'll have to dig down and investigate your application as it may not work as intended sometimes without a proper DE below it
Related
Is there any software working like this?
Runs as a standalone program. No install is needed. Thus, can be used as an Ansible module.
After running the program in a remote Linux machine, I can open up a web browser, then open a web page provided by the program. The program provides features similar to file explorer, IDE-level code editor, debugger, etc. In terms of debugger, there is already similar one; gdbgui.
There is another way such as Gnome, KDE or X11. However, these requires much packages to be installed. I don't want they be installed, because my Linux machines are kept to be small and secure.
You might consider having some terminal emulator running inside a browser. Such things exist, e.g. libonion has oterm as an example application. Then you can do all the things that a command line interface thru a unix shell provides (of course, you won't be able to run GUI applications, e.g. X11 clients such as GTK or Qt applications).
You could also consider some webmin like stuff.
Notice that you don't need to have a desktop environment on a remote Linux machine. Most of them (e.g. internet servers) have only command line interface.
Learn more about X11: you could have an X11 server on your laptop (e.g. under Windows if so needed) and run remotely X11 clients (that is GUI applications) with ssh -X on your remote Linux system.
However, these requires much packages to be installed. I don't want they be installed, because my Linux machines are kept to be small and secure.
I don't understand that requirement. On my VPS, running in some OVH datacenter, I do have X11 client applications (notably emacs). I don't believe that lowers the security of my system, and the disk space consumption for X11 applications and libraries is small enough these days. And of course I use standard commands (like cp(1), mv(1), rm(1), grep(1), find(1), less(1), file(1), sed(1) ....) to manage files. Any graphical file manager is useless (and I never use them, while using Unix since 1986)
You really should learn how to use the command line on Linux. It is incredibly powerful.
Running an Apple USB keyboard (the large one with a numpad)
I'm unable to use the ALT-key, so I can't access fairly vital symbols like: [] and {}.
Swedish characters doesn't work either, even though it's less of an issue.
I've followed the instructions here:
https://wiki.debian.org/Keyboard
But regardless what I set, I can't notice any differences (even after reboot).
The server is setup on a VPS so I'm using VNC to access the console. I'm using the built in Screen sharing client of OS X Mavericks.
Any help would be very much appreciated
/J
Wasn't a keyboard problem at all.
Seems the problem is with the built in VNC client in OS X Mavericks.
If I use a Java client the keyboard works great.
I'm using /bin/sh to execute some commands, but some of those commands require me to have a "graphical terminal" which I don't really know what that means, those commands give wrong output on my software, but correct output on the normal Gnome/KDE Terminal.
I was wondering if there is away to tell the underlying X Window Session that my software is a "graphical terminal"?
As #ugoren said, the DISPLAY variable is what is used to find the X Window System from applications. If X is not running in the background, the variable will be unset.
You can start a new X server using xinit from your script if you cannot talk to the old one; ideally, this would be something like Xvnc (which does not need hardware access).
If I understand correctly you are trying to run application on a remote machine or at least one that doesn't run any X Server. If that is the case you might try to use Xvfb which creates a virtual server which allows applications to connect to it and "draw" windows.
Normally, software that uses X windows relies on the DISPLAY environment variable.
It's value should be something like 10.0.0.1:0.0, where 10.0.0.1 is your IP address (I'm not sure what 0.0 is, but 0.0 normally works).
You also need some X server software to run on your PC, which would show the window.
I am using a very stripped down version of Linux, I want to create a self contained GTK application on a system that has no X window environment installed.
I want to use GTK GUI classes and widgets and not create a server version where GUI is disabled.
The only thing you can expect is a working glibc.
From what I understand it would involve the following:
Statically link GTK lib with X libraries.Statically link my application with the above mentioned library.
Is there anything to watch out for, Can a (somewhat) newbie get it done. I used google, but (some usable) information flew over my head.
GTK and X are independent programs. You would typically need to install both for the program to work. Alternatively, you can use the Linux framebuffer by switching out GTK for GTKfb. You will need to compile GTKfb and its dependencies statically if you don't want to distribute the libraries. Carefully read the LGPL if you do this. Red Hat has a paper on building small applications with GTKfb: http://www.redhat.com/f/pdf/gtkfb.pdf.
X libraries are X11 client libraries that are used to connect to X11 server. Your device does not run such server, and X11 client libraries won't be of any help. On embedded devices, the good option is probably to use direct access to framebuffer (e.g., gtk-directfb, gtk-fb)
You should be able to do this; however most of the X / Gtk libraries are normally compiled dynamically, and while they should compile statically you may encounter some bit-rot.
Have you considered simply bundling all the required shared libraries with your application? You could launch your application via a shell script wrapper which sets up the library search path to point to the directory with your shared libraries in.
This is similar to the method that firefox uses on Linux for it's plugin path.
You could use X Virtual Framebuffer. On Debian, it's the xvfb package. The following is from the package description:
Xvfb provides an X server that can
run on machines with no display
hardware and no physical input
devices. It emulates a dumb
framebuffer using virtual memory. The
primary use of this server was
intended to be server testing, but
other novel uses for it have been
found, including testing clients
against unusual depths and screen
configurations, doing batch processing
with Xvfb as a background rendering
engine, load testing, as an aid to
porting the X server to a new
platform, and providing an unobtrusive
way to run applications that don't
really need an X server but insist on
having one anyway.
This package also contains a
convenience script called xvfb-run
which simplifies the automated
execution of X clients in a virtual
server environment. This convenience
script requires the use of the xauth
program.
More information about X.Org can be
found at:
http://www.X.org
http://xorg.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
This package is built from the X.org
xserver module.
I recently started using Linux (where I work is a Microsoft shop, so I only code in C#, work with MS products etc).
I'm trying to understand at a high level how some basic things in Linux hang together.
I've been reading www.linfo.org
Anyway I've never quite got what X is.
From reading this article it seems to me that X is layer that sits on top of the operating system (one X server sitting on top of the OS??) and X client applications make requests to the X server.
I think KDE, Xfce and Gnome are display managers, are they X server clients then?
I'm quite confused where everything sits.
Any explanation would be really appreciated!
It's all very modular and flexible; however this leads to complexity.
The "X Server" drives the display device. It provides graphics services to clients, and those services are pretty simple - such as:
"Give me a window frame to draw in"
"Put this bitmap here"
"Draw a horizontal black line 100px wide"
"Render the text 'hello' at (100,100)"
"Tell me if any mouse clicks or key presses have been aimed at my window frame"
There is a library called Xlib, provided by X, that has a standard interface for all these simple services. Any program that wants to use the X server's display eventually uses this client library and is called an X Client. Xlib knows how to connect to an arbitrary X server - on the local machine, or via TCP/IP across the LAN, or across the world - to call these services.
The Window Manager, which is just another X client program, is in charge of the "look and feel" of the desktop - how you move and arrange windows, etc. Because the window manager draws all the window decorations, it can make the desktop look like WindowsXP, or a Mac, or NeXTSTEP.
Part of the philosophy of X was to define "mechanism and not policy" - meaning, they give you tools to do it, but don't tell you how to use those tools. One such tool is the window manager, which can be replaced at will.
Many modern X applications are written to use a desktop enviroment such as Gnome or KDE. This offers these programs a consistent set of buttons and controls to draw, and a consistent interface for some things not traditionally included in X, but often considered part of a desktop - such as how to respond to drag-and-drop or how to present a standard file chooser dialog box.
The desktop environment usually provides an object model or programmatic interface that takes care of making all the simple X client requests and lets the program handle more important things. Removing these low-level calls yields another important benefit - platform independence.
Many desktop environments include a window manager, so that the look and feel of window controls and buttons is consistent and works with the desktop metaphor provided by the environment. However, it can usually still be switched out.
The separation of the X Server (running the display) and the X Client (wanting to use the display) has a few implications:
The graphics system is separate from the GUI programs, and they are separated about as completely as a web browser and web server are.
So the GUI program might not be displaying on the local machine - just like a web browser doesn't have to point at a web server on the local machine.
A machine can run JUST the client, with the X server elsewhere.
The machine with the display doesn't have to run the client - it can run JUST the X server, and all the clients can run on a dedicated machine. This is the original thin client: big programs running on big central server - with graphical user interaction handled by dedicated hardware on the desk in front of the user.
You need to know what your X server's network address is so you can tell GUI programs where to display their GUI. (this is usually done by setting the DISPLAY environment variable)
You can display many programs, from many different machines, all on the same desktop at the same time. It is all handled seamlessly, including cut-and-paste.
X11 is a network protocol, currently at release 7 (hence X11R7). It encapsulates graphics and input information, and connects an X client (application or window manager) running on a local or remote machine to the X server currently driving the local screen and input devices.
Gnome, KDE, XFCE, and LXDE are desktop environments; they contain pieces that talk to/with the X server (metacity, kwin, etc.), but also consist of specifications that applications must follow and libraries that are available in order for an application to "belong" to the DE.
In addition, it's worth remembering that the X server is just another program that gets run under linux. There's nothing special about it, it just happens to know how to grab onto the graphics card and take over the monitor using video drivers.
You can (theoretically) run linux very happily without ever running an X server - although of course, you would be limited to the command line programs.
That's how linux organises itself - kernel at the base, then a set of programs that provide functionality to higher level programs, which themselves provide functionality to higher level programs, all building up into a complete stack of software oriented to whatever the job of the machine is (say, general desktop, software development, web server, etc).
Beyond the kernel and it's modules, nothing is 'special'.
Wikipedia has some info about it.