Well, that question already been asked, however my environment is slightly different. I've robot that moves mouse inside x11vnc session. I'd like that cursor motion to be properly displayed with vncviewer (tigervnc-1.4.2-r2). Seems nothing works.
What I've tried:
x11vnc -nocursor && vncviewer LocalCursor=0 DotWhenNoCursor=1
x11vnc -cursor arrow && vncviewer LocalCursor=0 DotWhenNoCursor=0
x11vnc -cursor X && vncviewer LocalCursor=0 DotWhenNoCursor=0
x11vnc -cursor some && vncviewer LocalCursor=0 DotWhenNoCursor=0
x11vnc -cursor most && vncviewer LocalCursor=0 DotWhenNoCursor=0
Also plaid some with LocalCursor=1 (although think since I need to see remote cursor that's wrong idea).
Is that possible (not sure I properly understand vnc approach for cursor display).
Found solution. Just enabled -multiptr option for x11vnc.
Got that option working out of the box on x11vnc-0.9.14-r2 Gentoo Linux version of x11vnc. However, it could be necessary to install additional x11vnc-multiptr module.
on ubuntu:
git clone git#github.com:LibVNC/x11vnc.git
cd x11vnc
sudo apt-get install libvncserver-dev
./autogen.sh
./configure
make
sudo make install
xset r rate 200 30
x11vnc -repeat -multiptr
Related
I have a Ubuntu 20.04 running within WSL 2 on a Windows 10 computer.
Every time I login to Ubuntu, I had to manually execute these four line by pasting it one by one in the Windows 10 Terminal.
sudo apt-get update && sudo apt-get install -yqq daemonize dbus-user-session fontconfig
sudo daemonize /usr/bin/unshare --fork --pid --mount-proc /lib/systemd/systemd --system-unit=basic.target
exec sudo nsenter -t $(pidof systemd) -a su - $LOGNAME
sudo /etc/init.d/xrdp start
May I know if there is a way to skip this manual process?
You can use .bashrc file to execute commands whenever you open the terminal. It should be located at $HOME directory.
cd $HOME
nano .bashrc
place your commands at the end of the file, press ctl+x then y to save.
In Dockerfiles I'm seeing most people using this syntax
RUN apt-get -y update \
&& apt-get install -y libicu-dev
over this one
RUN apt-get -y update
RUN apt-get install -y libicu-dev
For me the first one gets only one line (layer) cached while the second caches both (am I wrong ?) and stops as soon as a command is not successful.
Besides I don't find the first one more readable.
So why would we use the first syntax ?
It is optimisation for docker image layer. I also recommend to read Best practices for writing Dockerfiles
There is also interesting presentation from DockerCon EU 2017.
Lesser the layers, better the image.
Hence, combining commands using && will create a single layer.
Having two RUN will create two layers.
According to the images and layers documentation
Each layer is only a set of differences from the layer before it
So for example 2 layers creating different files would not use more disk space. Especially since Docker 17.05 allows multi-stage builds. However, it still could use more space if the second one is entirely modifying files from the first one.
Following Khapov Igor's comment I found out the real answer to the original question in the best practice doc:
Using apt-get update alone in a RUN statement causes caching issues and subsequent apt-get install instructions fail.
It's actually more about layer dependencies with previous commands for which results can evolve over time like apt-get update.
That's why they are telling:
Always combine RUN apt-get update with apt-get install in the same RUN statement
Each command in a Dockerfile creates another image layer.
Combining commands is a way to end up with less layers overall.
See https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/#images-and-layers
This line:
RUN apt-get -y update \
&& apt-get install -y libicu-dev
will create one single docker layer and these lines:
RUN apt-get -y update
RUN apt-get install -y libicu-dev
will create two different layers.
This is the main reason why when you need to install something in your docker machine (ex: via APT) you tend to keep everything in one single line (aka layer)
As the other answers already said, every command generates a layer and it's usually desirable to have the minimum amount of layers per image.
Each layer is only a set of differences from the layer before it. The layers are stacked on top of each other. When you create a new container, you add a new writable layer on top of the underlying layers.
This means that unless you're going to "squash" your image (which translates in using the --squash option during the build), you end up having an image consuming space for nothing.
Example
# Dockerfile
FROM ubuntu
RUN apt-get update
RUN apt-get install -y --no-install-recommends dnsutils
RUN echo $( dig somewhere.nowhere )
RUN apt-get remove --purge dnsutils
RUN rm -rf /var/lib/apt/lists/*
COPY magicalScript.sh /
CMD /magicalScript.sh
In this case you'll have layers containing only overhead:
1 with cache coming from apt-get update
1 with dnsutils installed,
1 containing the removal of the dnsutils
1 containing the removal of the cache
The problem is that all those layers remain there and consume space for no reason at all.
Why squash is not always a good solution? Because the layers represents a cache as well. And it's extremely useful when you need to perform a lot of builds and you need them to be as fast as possible.
Usually it's good practice to group together operation related the installation of new packages on the OS:
# Dockerfile
FROM ubuntu
RUN useradd docker \
&& mkdir /home/docker \
&& chown docker:docker /home/docker \
&& addgroup docker staff
RUN apt-get update \
&& apt-get install -y --no-install-recommends ed less locales vim-tiny wget ca-certificates fonts-texgyre \
&& rm -rf /var/lib/apt/lists/*
RUN echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen \
&& locale-gen en_US.utf8 \
&& /usr/sbin/update-locale LANG=en_US.UTF-8
CMD ["mySpecialCommand"]
I have been working through some i2c examples. Plugging it all together and I find that I need to install the i2c-tools package, then use raspi-config to enable the I2C system.
The wiringPi gpio command has a shortcut to the i2cdetect command and running it gives
Before 3 weeks everything working properly, detected 68. I didn't understand what is the problem !!! Can anyone one help me to solve this issue.
The I2C bus allows multiple devices to be connected to your Raspberry Pi, each with a unique address, that can often be set by changing jumper settings on the module. It is very useful to be able to see which devices are connected to your Pi as a way of making sure everything is working.
To do this, it is worth running the following commands in the Terminal to install the i2c-tools utility.
sudo apt-get install -y python-smbus
sudo apt-get install -y i2c-tools
If you're not using a modern Raspbian or you want to do it by hand, you can! Open LXTerminal or console or ssh and enter the following command:
sudo nano /etc/modules
and add these two lines to the end of the file:
i2c-bcm2708
i2c-dev
Then save the file with Control-X Y
Depending on your distribution, you may also have a file called /etc/modprobe.d/raspi-blacklist.conf
If you do not have this file then there is nothing to do, however, if you do have this file, you need to edit it and comment out the lines below:
blacklist spi-bcm2708
blacklist i2c-bcm2708
.. by putting a # in front of them.
Open an editor on the file by typing:
sudo nano /etc/modprobe.d/raspi-blacklist.conf
If you are running a recent Raspberry Pi (3.18 kernel or higher) you will also need to update the /boot/config.txt file. Edit it with sudo nano /boot/config.txt and add the text
dtparam=i2c1=on
dtparam=i2c_arm=on
at the bottom. note that the "1" in "i2c1" is a one not an L!
Once this is all done, reboot!
Now when you log in you can type the following command to see all the connected devices
sudo i2cdetect -y 1
Note that if you are using one of the very first Raspberry Pis (a 256MB Raspberry Pi Model B) then you will need to change the command to:
sudo i2cdetect -y 0
Try sudo i2cdetect -y 1 or sudo i2cdetect -y 0 (if you using old Raspberry Pi) and run it on root. Open terminal and run command sudo su, then run sudo i2cdetect -y 1
I'm trying to record video from a firefox run by xvfb-run but it always output nothing in the video file except black screen.
Here's what I did:
start a firefox, open google.com:
$ xvfb-run firefox https://google.com
Then it will use the default display server number 99. I can see the display information by command xdpyinfo -display :99.
A screenshot works very well by command:
$ xwd -root -silent -display :99.0 | xwdtopnm |pnmtojpeg > screen.jpg
Start using ffmpeg to record a video:
$ ffmpeg -f x11grab -i :99.0 out.mpg
When I play the video file out.mpg, there's black screen all the time.
Is there any parameter I missed?
I don't know if you have fixed this bug but if you haven't let me help out because I ran into same issue. Here's a solution (I'm running on Fedora 30):
Your need to Configuring Xorg as the default GNOME session. On your terminal open your custom.conf by typing the this command sudo nano /etc/gdm/custom.conf and uncomment WaylandEnable=false if it's commented but must be set to false
Then, on the [daemon] section just under WaylandEnable=false add this line DefaultSession=gnome-xorg.desktop and save the file. Then try running your Screen Recorder program again.
Congratulations.
However, if nano command is not working please try installing it by running the command
sudo dnf install nano or sudo apt-get install nano which ever works for you.
I am writing a bash script (for apt-get based OS's) that automates the installations process of various programs. In this process I run "apt-get -fy update" and "apt-get -fy upgrade" sometimes. In the process of upgrading, occasionally, a restart is required.
My question: is there a way of testing if the system is asking for a restart after running "apt-get -fy upgrade"? I am trying to write the script for it to run from beginning to end without human any intervention.
Thank you.
Use the file /var/run/reboot-required which does exactly what you want. So we will have this:
apt-get update && apt-get -fy upgrade && [ -f /var/run/reboot-required ] && shutdown -r now
I don't recall whether apt-get actually gives you a predictably formatted message informing you whether a restart is necessary, but if it does you could just check the output, e.g. something like apt-get -fy update | grep -q 'fill in restart message pattern' && reboot.
Another probably less reliable alternative is to use checkrestart from the debian-goodies package.
If you do a
apt-get -fy update && shutdown -r now
it will respect the order and will update until finish and finally restart your server.