728x90

New to Linux and in need of a good painting tool? Check out Krita! It’s completely free, open source and has dozens of features to satisfy artists of all types.

Krita is part of the KDE project and has support for pretty much every Linux distribution out there. To install Krita, open up a terminal and follow the instructions that correspond to your Linux distribution.

Ubuntu

Krita is in the official software repositories on Ubuntu, and users can quickly install it with the following command in a terminal.

sudo apt install krita

The version of Krita in the Ubuntu software sources is relatively recent, but it’s not the absolute latest. If you’re looking for a more recent version, you’ll need to update it with the official Krita PPA. To do this, use the following command.

sudo add-apt-repository ppa:kritalime/ppa

After adding the new Krita software PPA, run the update command.

sudo apt update

Running the update command will see the new Krita PPA and detect that a newer version of the software is available. To switch over to the latest version of the software on Ubuntu, run the upgrade command.

sudo apt upgrade -y

Debian

Debian has the Krita graphic design tool ready for installation on nearly every version. To install it, open up a terminal and use the Apt-get package management tool to get it working.

sudo apt-get install krita

Installing the Krita tool on Debian will get you out of a pinch. However, due to the nature of how Debian works, you’ll likely be using an older version of the software. To get around this, consider following this tutorial to enable Debian Backports. Using Backports will let you get a newer version of Krita on your Debian setup.

Don’t want to go through the trouble of enabling Debian Backports? Consider continuing through the tutorial and following either the Flatpak or AppImage instructions to get a more recent version of Krita.

Arch Linux

Arch Linux users can easily install Krita, though before doing so you’ll need to enable the “Extra” software repository. To enable it, launch a terminal and open up your Pacman configuration file in the Nano text editor.

sudo nano /etc/pacman.conf

In the Pacman editor, scroll through the file until you see “[Extra],” and remove all “#” symbols in front of it.

After enabling the Extra software repository, re-sync Pacman, and install any updates.

sudo pacman -Syyu

With Extra set up, install Krita to your Arch Linux PC.

sudo pacman -S krita

Fedora

Using a reasonably new version of Krita on Fedora Linux requires no extra setup. To install it, open up a terminal and use the DNF package tool.

sudo dnf install krita -y

OpenSUSE

Like Fedora, OpenSUSE users looking to install the Krita painting/sketch program don’t need to follow any steps to enable third-party software repos. Open up a terminal and use the Zypper packaging tool to get the app working.

sudo zypper install krita

Flatpak

The Krita application is available on Flathub, which means that users who don’t have access to the program through traditional means still can install it.

Getting Krita working with Flatpak is quite straightforward. First, learn how to set up Flatpak on your Linux PC. When that’s taken care of, open up a terminal and use the command-line to install Krita.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

flatpak install flathub org.kde.krita

Generic Linux Instructions Via AppImage

Many Linux distributions offer support for Flatpak and Snap packages to make up for lack of software in their official software sources. However, not all distros have support for these packaging formats.

If your Linux distribution doesn’t have support for Flatpak, you’ll have to go the AppImage route instead.

To install Krita via AppImage, open up a terminal window and use the wget tool to download it.

mkdir -p ~/AppImages

cd ~/AppImages
wget https://download.kde.org/stable/krita/4.1.1/krita-4.1.1-x86_64.appimage

Now that the Krita AppImage is done downloading, it’s time to update its system permissions. Changing the permissions will allow the AppImage to run as a program on your Linux PC.

sudo chmod +x krita-4.1.1-x86_64.appimage

Run Krita from the terminal with:

./krita-4.1.1-x86_64.appimage

Updating Krita AppImage

The Krita AppImage doesn’t update automatically. Instead, if you want to upgrade to a newer version of Krita, follow the steps below.

Step 1: Open up a terminal and delete the Krita app image on your Linux PC.

cd ~/AppImages

rm krita-4.1.1-x86_64.appimage

Step 2: Go to the official website, click on “AppImage” and download the new release.

Step 3: Move the terminal into the ~/Downloads folder with CD.

cd ~/Downloads

Step 4: Change the new file’s permissions, move it into the ~/AppImages folder and launch it.

sudo chmod +x krita-*-x86_64.appimage

mv krita-*-x86_64.appimage ~/AppImages

./krita-*-x86_64.appimage


728x90

if do not google chrome, next command is possible: 

#google-chrome --no-sandbox


But It is also causes errors.

Objective

The objective is to install Google Chrome web browser on Kali Linux. See an appendix for a possible issue troubleshooting.

Requirements

Privileged access to your Kali Linux installation or Live system is required.

Difficulty

EASY

Conventions

  • # - requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command
  • $ - requires given linux commands to be executed as a regular non-privileged user

Instructions

Download Google Chrome

To start, use wget command to download a latest Google Chrome debian package:

# wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

Install Google Chrome

The easiest way to install google chrome on you Kali Linux is to by use of gdebi which will automatically download all depended packages.

# gdebi google-chrome-stable_current_amd64.deb

Start Google Chrome

To start Google Chrome, open up a terminal and run google-chrome command:

$ google-chrome


Appendix

Illegal Instruction

The Illegal Instruction error message appears when running the google-chrome command as privileged root user. Since by default Kali Linux's default user is root, we need to create a dummy non-privileged user eg. linuxconfig, and use this user to start Google Chrome browser:

# useradd -m -d /home/linuxconfig linuxconfig
# su linuxconfig -c google-chrome

Package libappindicator1 is not installed

dpkg: dependency problems prevent configuration of google-chrome-stable:
 google-chrome-stable depends on libappindicator1; however:
  Package libappindicator1 is not installed.

To resolve Google Chrome's dependencies problems use gdebi to install Google Chrome's debian package. See above. 

Start google chrome as regular user on Kali Linux




728x90

Returns up to nanoseconds, rounded to the resolution of the implementation.

Looks like an ANSI ripoff from POSIX' clock_gettime.

Example: a printf is done every 100ms on Ubuntu 15.10:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

static long get_nanos(void) {
    struct timespec ts;
    timespec_get(&ts, TIME_UTC);
    return (long)ts.tv_sec * 1000000000L + ts.tv_nsec;
}

int main(void) {
    long nanos;
    long last_nanos;
    long start;
    nanos = get_nanos();
    last_nanos = nanos;
    start = nanos;
    while (1) {
        nanos = get_nanos();
        if (nanos - last_nanos > 100000000L) {
            printf("current nanos: %ld\n", nanos - start);
            last_nanos = nanos;
        }
    }
    return EXIT_SUCCESS;
}

The C11 N1570 standard draft 7.27.2.5 "The timespec_get function says":

If base is TIME_UTC, the tv_sec member is set to the number of seconds since an implementation defined epoch, truncated to a whole value and the tv_nsec member is set to the integral number of nanoseconds, rounded to the resolution of the system clock. (321)

321) Although a struct timespec object describes times with nanosecond resolution, the available resolution is system dependent and may even be greater than 1 second.

C++11 also got std::chrono::high_resolution_clockC++ Cross-Platform High-Resolution Timer

timespec_get 함수에 해당하는 TIME_UTC 에 대한 상수는 다음과 같이 정의되어 있다. (사실 별 쓸모는 없지만 왠지 궁금해서 적어놓는다.)


glibc 2.21 implementation

Can be found under sysdeps/posix/timespec_get.c as:

int
timespec_get (struct timespec *ts, int base)
{
  switch (base)
    {
    case TIME_UTC:
      if (__clock_gettime (CLOCK_REALTIME, ts) < 0)
        return 0;
      break;

    default:
      return 0;
    }

  return base;
}

so clearly:

  • only TIME_UTC is currently supported

  • it forwards to __clock_gettime (CLOCK_REALTIME, ts), which is a POSIX API: http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html

    Linux x86-64 has a clock_gettime system call.

    Note that this is not a fail-proof micro-benchmarking method because:

    • man clock_gettime says that this measure may have discontinuities if you change some system time setting while your program runs. This should be a rare event of course, and you might be able to ignore it.

    • this measures wall time, so if the scheduler decides to forget about your task, it will appear to run for longer.

    For those reasons getrusage() might be a better better POSIX benchmarking tool, despite it's lower microsecond maximum precision.

    More information at: Measure time in Linux - time vs clock vs getrusage vs clock_gettime vs gettimeofday vs timespec_get?


728x90

Recently, I had to do latency testing of message passing between kernel-land and user-land, so I first looked after time structures and functions available in both the kernel and the libc, and then I looked after possible tuning of the kernel.

Obviously gettimeofday is not precise enough because it returns a timeval structure (defined in time.h), which only has a microsecond resolution:

1
2
3
4
struct timeval {
  time_t      tv_sec;       /* seconds */
  suseconds_t tv_usec; /* microseconds */
};


Instead, the timespec structure (also defined in time.h) seems perfect with a nanosecond resolution:

1
2
3
4
struct timespec {
  time_t   tv_sec;  /* seconds */
  long     tv_nsec;   /* nanoseconds */
};


So, I stumbled upon kernel POSIX timers which can be accessed from user-land with the following functions (triggering syscalls):

1
2
#include <time.h>
int clock_gettime(clockid_t clk_id, struct timespec *tp);

According to the manual, a system-wide realtime clock is provided (CLOCK_REALTIME), perfect here.

When you look at the libc and kernel source kernel/posix-timers.c, it is interesting how these clocks are implemented... and definitely not trivial!

Now how to use it? Consider the following code which measures the latency between two gettime calls, for each type of clock.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <stdio.h>
#include <time.h>
 
int main(int argc, char **argv, char **arge) {
  struct timespec tps, tpe;
  if ((clock_gettime(CLOCK_REALTIME, &tps) != 0)
  || (clock_gettime(CLOCK_REALTIME, &tpe) != 0)) {
    perror("clock_gettime");
    return -1;
  }
  printf("%lu s, %lu ns\n", tpe.tv_sec-tps.tv_sec,
    tpe.tv_nsec-tps.tv_nsec);
  return 0;
}

Compile and link with librt (for clock_gettime).

결과적으로 Library 에서 librt 는 반드시 컴파일 라이브러리 헤더에 포함시켜줘야 한다. (Real Time 관련 헤더라 빠지면 에러난다)

1
$ gcc -Wall -lrt -o time time.c

Now here is what I get on a Core i7 950, Linux 2.6.33, libc 2.10.2-6, Debian sid.

이와같이, 컴퓨터 사양에 의해서도 nano second 는 엄청난 차이를 보여준다.

1
2
$ ./time
0 s, 113 ns

Pretty good!

Interesting thing, if in another shell if I run a do-nothing loop (« while(1); »), I have better timings:

1
2
$ ./time
0 s, 58 ns


Apparently, it comes from a feature of modern CPU: the ability to shutdown ("relax") when idle. And it takes some time for the CPU to wake-up. You can modify this behaviour by using the idle=poll kernel command line. This way, the CPU never relaxes and is always ready (polling) to work.

+ Recent posts