Forem: segfault

XMPP Client In C.

segfault — Fri, 16 Jan 2026 15:27:17 +0000

What's xmpp??

XMPP originally named Jabber is an open communication protocol designed for instant messaging.
Based on XML(Extensible Markup Language), It enables the near real time exchange of structured data between two or more network entities alice and bob. It was designed to be extensible, the protocol offers a many applications beyond traditional IM in the broader realm of message oriented middleware including signaling for VoIP,video,file transfer,gaming and other use cases.

I assume you have knowledge of fundamentals of C.

Remember C is the language of cave men now let's proceed onto the next stage.

First grab libxml2 for parsing xml because xmpp loves wasting cycles.

sudo apt-get install gcc libxml2 -dev
We start by importing various libraries

#include <stdio.h>
#include <string.h>
#include <stdlib.h> 
#include <time.h>
#include <sys/types.h>
#include <conio.h>  
#include <winsock.h>
#include <poll.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <arpa/inet.>

// Just use libstrophe. Seriously.
#include <strophe.h>
// (But you won’t, because you hate yourself.)

#define Unix 0 // set to 0 for Unix, 1 for Windows
#define CLIENT_NAME "Cvck"
#define CLIENT_VERSION "not used at this time"
#define REMOTEPORT 5222
#define PROXY "proxy.eu.jabber.org"
#define STDIN 0  // file descriptor for standard input
#define ENCODING "UTF-8"
#define START_DEBUGMODE 0

/// Connect to the xmpp server (pray theres no TLS bug)//
/* Socket Variables */
int sock;
struct sockaddr_in client_addr;
struct sockaddr_in server_addr;
struct hostent *hostname;
int sin_size;
int si_sock;
struct sockaddr_in si_client_addr;
struct sockaddr_in si_server_addr;
struct hostent *si_hostname;

/* send/recv prototypes */
char proxy[128];
char *host,int size);
void connectsock(void);
void getin(void);
void fd_getin(void);
/* send/recv variables */
int buflen;
fd_set onrecv_set;
struct timeval tv;
unsigned short sequence_number_client;
char message_out[3000];

/* Here is how to send login stanza*/
void send_xmpp_auth(int sockfd, const char *user, const char *pass) {
    char buffer[1024];
    snprintf(buffer, sizeof(buffer),
        "<stream:stream to='%s' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>",
        "example.com");
    send(sockfd, buffer, strlen(buffer), 0);

    // Wait for server response (you’ll need to parse it)//
    // Pro tip: Use libxml2 or suffer regex nightmares.
}

/* vars */
char client[32];
char user[127];
char userjid[384];
void userlogin(void);

int main(int argc, char *argv[])
{
  printf("\n" " %s, a Xmpp cli \n"" version: %s\n" " xmppid: terzibajian@draugr.de , website: http://x64x2.neocities.com\n" "\n",CLIENT_NAME,__FILE__);

   if (argc > 0 && ((argv[1]== NULL) || (argv[2]== NULL)))
    {
    printf("   Usage: %s <xmppid>[/ressource] <pass> [server] [port]\n\n", argv[0]);
    exit(0);
  }

  strcpy(client,argv[0]);
  strcpy(user,argv[1]);
     if (strstr(user,"@") != NULL){
    strcpy(nick,user);
    if (strstr(user,"/") != NULL)
        sscanf(nick,"%[^@]@%[^/]/%s",user,domain,ressource);
    else
        {sscanf(nick,"%[^@]@%s",user,domain);
        strcpy(ressource,CLIENT_NAME);}
    }
  strcpy(pass,argv[2]);

   if (argv[3] != NULL)
    strcpy(remotehost,argv[3]);
   else
    strcpy(remotehost,domain);
    if (domain==NULL)
    strcpy(domain,remotehost);

   //if (argv[4] != NULL)
  if ((argv[4] != NULL) && (argv[3] != NULL))
    strcpy(remoteport,argv[4]);
else
    strcpy(remoteport,"5222");

  //printf("\n\tCONNECTED as %s@%s on %s:%s!\n\n",user,domain,remotehost,remoteport);
    connectsock();
    userlogin();
        flapon(); 
        printf("get stream...\n");
        toc_signon(); 
        printf("server signon...\n");
        toc_init_done();
} 
/* Functions*/
void commands_interpreter(void)
{
    if (strstr(message_out,"quit:") != NULL)
        {
        strcpy(option,"");
        sscanf(message_out,"quit: %[^\n]",option);
        sprintf(message_out,"<presence type='unavailable'><status>%s</status></presence>",option);
        sendout(message_out);
        sprintf(message_out,"</stream:stream>");
        printf("%s\n",message_out);
        exitclient();
        }
    if (strcmp(message_out,"debug") == 0)
        {
        debugmode=debugmode^1;
        if (debugmode==1)
            printf("debug mode is now ON\n");
        else
            printf("debug mode is now OFF\n");          
        }
    if (strcmp(message_out,"notif") == 0)
        {
        notifmode=notifmode^1;
        if (notifmode==1)
            printf("presence notification is now ON\n");
        else
            printf("presence notification is now OFF\n");           
        }
    if (strcmp(message_out,"antiflood") == 0)
        {
        antifloodmode=antifloodmode^1;
        if (antifloodmode==1)
            printf("presence antiflood is now ON\n");
        else
            printf("presence antiflood is now OFF\n");          
        }
    if (strcmp(message_out,"autoresult") == 0)
        {
        autoresult=autoresult^1;
        if (autoresult==1)
            printf("autoresult mode is now ON\n");
        else
            printf("autoresult mode is now OFF\n");         
        }
    if (strstr(message_out,"prior:") != NULL)
        {
        sscanf(message_out,"prior: %s",prior);
        sprintf(message_out,"<presence><priority>%s</priority></presence>",prior);
        }
    if (strstr(message_out,"status:") != NULL)
        {
        sscanf(message_out,"status: %[^\n]",option);
        sprintf(message_out,
            "<presence><status>%s</status><priority>%s</priority></presence>"
            "<presence to='%s'><status>%s</status><priority>%s</priority></presence>"
            ,option,prior,roomname,option,prior);
        }
}        

void getin(void)
{
char sockbuf[12000];
/* memset sockbuf*/
        if((buflen=recv(sock,sockbuf, sizeof(sockbuf),0)) == -1)    /* Lire nouvelle co */
         {
            printf(" brk  recv in - buflen = %i\n",buflen);     /* Si erreur lecture */
            perror("recv");
            exit(1);}
           printf("recv in - buflen = %i (%i)\n",buflen, strlen(sockbuf));  /* Result buffer */
          if ((debugmode==1) || (strstr(ressource,"debug") != NULL))
            /*printf("[%i bytes]\n",buflen);*\
          /*printbuf(sockbuf,buflen);*\
}

void connectsock(void)
{
    /*create socket*/
    if ( (sock = socket(AF_INET, SOCK_STREAM, 0)) < 0)
    {   perror("opening steam socket in");
        exit(1);
    }
    /*printf("create socket %i\n", sock);*/
    /*name socket using wildcards*/
    hostname=gethostbyname(remotehost);
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = inet_addr( inet_ntoa(*((struct in_addr *)hostname->h_addr)) );
    server_addr.sin_port = htons((unsigned short int) atoi(remoteport));  /* Use specified port */
    memset(server_addr.sin_zero, 0, 8);

    /*resolve DNS and connecting socket*/
    printf("connecting to: %s port %s\n", inet_ntoa(server_addr.sin_addr),remoteport);
    sin_size=sizeof(struct sockaddr_in);
    if(connect(sock,(struct sockaddr*)&server_addr, sin_size) == -1) {
        perror("connect");
        exit(1);}
}

void userlogin(void)
{
    printf("Login with %s ...\n",user);
    strcpy(prior,"0");
    strcpy(proxy,PROXY);
    autoresult=1;
    sprintf(userjid,"%s@%s/%s",user,domain,ressource);
}

void exitclient(void)
{
    closesocket(sock);
    shutdown(sock,SHUT_RDWR);
exit(0);
}

Langton's Ant

segfault — Mon, 04 Mar 2024 19:22:39 +0000

Langton's ant (also virtual ant or vant) is a simple zero player game and cellular automaton simulating the behavior of an ant that behaves according to extremely simple rules but nevertheless builds a very complex structure. It is similar to game of life. Langton's ant is Turing complete (it can be used to perform any computation that any other computer can).

Rules: in the basic version the ant is placed in a square grid where each square can be either white or black. Initially all squares are white. The ant can face north, west, south or east and operates in steps. In each step it does the following: if the square the ant is on is white (black), it turns the square to black (white), turns 90 degrees to the right (left) and moves one square forward.

These simple rules produce a quite complex structure, seen below. The interesting thing is that initially the ant behaves chaotically but after about 10000 steps it suddenly ends up behaving in an ordered manner by building a "highway" that's a non-chaotic, repeating pattern. From then on it continues building the highway until the end of time.

...........................................................................
.............................................................##............
............................................................##......##.....
...........................................................#.##.#..#..#....
...........................................................#..#.###..###...
.....##.....................................................#.##..####.#...
....##........................................................##...........
...#.##.#.....................................................##.##.##.....
...#..#.##................................................#.##.#..####.....
....#.A.#.#................................##....##....##.###.##.#####.....
....#...#.##..............................##..####....##..#.##.#.#..#......
...###..#.#.#............................#.##..####....####.###.####.......
...#####.#..##......................##...#.......##..##....#...#.###.......
....#..###..#.#....................#..#..#......#..##..##...##.####........
.....###...#..##..................#..#...#.......##.##...#..#..##.#........
......#..###..#.#.................#..#....#.########.#.#.##..####.#........
.......###...#..##..........##..##.#.#.#....##.##.#.#.##..#..##..##........
........#..###..#.#........#####.#..##...##.#...#....#.#..#..#..#.#........
.........###...#..##......#.##...##...#..#...####..#...##.####.##..........
..........#..###..#.#.....#....#...####.#..#####.##...##########...##......
...........###...#..##....#.....#.##.#####.##..#.#...#..#..##.#..#..#......
............#..###..#.#...#.....#####.#.#####.....#.#..##.#....##...#......
.............###...#..##...#..#.######.##.#.##.#.#....###.###...##...#.....
..............#..###..#.#...##..#.##...##.##.###.###...#..#.##..####.#.....
...............###...#..##......#.####..##..#########..#..##....#..##......
................#..###..#.#..#...##..###########.#..####..#....#....#......
.................###...#..##.###..##.#...##.......####.####...#......#.....
..................#..###..#.#.#..#.###.#.#.##......##...#.#.#....#...#.....
...................###...#.....#.##.#.##..##..#####.####..####.##...#......
....................#..###..#.##....#..#.###..#......###.##.#..#..##.......
.....................###...#...#.#..#.#.####.##..#.##.###..#.....#.........
......................#..###..##...##.##...###..#....#..##.####...#........
.......................###...#.#.##.###..#..##.....#...###.##..##.#........
........................#..#.........##.##...#..##.....##.#.....##.........
...........................#.#...#.##.###...#...#.#..####....#.##..........
.......................#.###.#.##.#.#.##.##.##.#...#####.###.##............
.......................###.##...#.####..##.##.######.#.###.#...#...........
........................#.....#...#####.#.#..####..#...###.#.#.#...........
..........................#.###.##..#.##..###.#.#.....###...###............
..........................#.#..###..##.####.##...#.#..#.##..##.............
.........................###.#..#...#.....#.....##.##..###.................
............................##..##.#.#.........###.......#.................
................................#.#..#.........#..#....#...................
................................###...##............##.#...................
.................................#..####..........#..##....................
..................................##..############..##.....................
...........................................................................

Langton's ant after 11100 steps, A signifies the ant's position, note the chaotic region from which the highway emerges left and up.

The Langton's ant game can be extended/modified, e.g. in following ways:

multiple colors: Squares can have more colors than just black/white that are cycled by the ant. Here we also need to specify which way the ant turns for each color it steps on, for example for 4 colors we may specify the rules as LRLL (turn left on 1st color, right on 2nd color etc.).
multiple ants: called colonies
different grid: e.g. hexagonal or 3D
multiple ant states: Besides having a direction the ant can have a more complex state. Such ants are called turmites (Turing termite).

The ant was invented/discovered by Christopher Langton in his 1986 paper called Studying Artificial Life With Cellular Automata where he calls the ants vants (virtual ants).

Implementation

The following is a simple C implementation of Langton's ant including the extension to multiple colors (modify COLORS and RULES).

#include <stdio.h>
#include <unistd.h>

#define FIELD_SIZE 48
#define STEPS 5000
#define COLORS 2      // number of colors
#define RULES 0x01    // bit map of the rules, this one is RL

unsigned char field[FIELD_SIZE * FIELD_SIZE];

struct
{
  int x;
  int y;
  char direction; // 0: up, 1: right, 2: down, 3: left
} ant;

int wrap(int x, int max)
{
  return (x < 0) ? (max - 1) : ((x >= max) ? 0 : x);
}

int main(void)
{
  ant.x = FIELD_SIZE / 2;
  ant.y = FIELD_SIZE / 2;
  ant.direction = 0;

  for (unsigned int step = 0; step < STEPS; ++step)
  {   
    unsigned int fieldIndex = ant.y * FIELD_SIZE + ant.x;
    unsigned char color = field[fieldIndex];

    ant.direction = wrap(ant.direction + (((RULES >> color) & 0x01) ? 1 : -1),4);

    field[fieldIndex] = (color + 1) % COLORS; // change color

    // move forward:

    switch (ant.direction)
    {
      case 0: ant.y++; break; // up
      case 1: ant.x++; break; // right
      case 2: ant.y--; break; // down
      case 3: ant.x--; break; // left
      default: break;
    }

    ant.x = wrap(ant.x,FIELD_SIZE);
    ant.y = wrap(ant.y,FIELD_SIZE);

    // draw:

    for (int i = 0; i < 10; ++i)
      putchar('\n');

    for (int y = 0; y < FIELD_SIZE; ++y)
    {
      for (int x = 0; x < FIELD_SIZE; ++x)
        if (x == ant.x && y == ant.y)
          putchar('A');
        else
        {
          unsigned char val = field[y * FIELD_SIZE + x];
          putchar(val ? ('A' + val - 1) : '.');
        }

      putchar('\n');
    }

    usleep(10000);
  }

  return 0;
}

Object-Oriented Programming

segfault — Sat, 16 Dec 2023 01:47:09 +0000

"I invented the term 'object oriented' and C++ was not what I had in mind" -- Alan Kay, inventor of OOP

Object-oriented programming (OOP, also object-obsessed programming) is a programming paradigm that tries to model reality as a collection of abstract objects that communicate with each other and obey some specific rules. While the idea itself isn't bad and can be useful in certain cases, OOP has become extremely overused, extremely badly implemented and downright forced in programming languages which apply this abstraction to every single program and concept, creating anti-patterns, unnecessary issues and of course bloat. Some therefore see OOP as a cancer of software development.

Ugly examples of OOP gone bad include Java and C++ (which at least doesn't force it). Other languages such as Python and Javascript include OOP but have lightened it up a bit and at least allow you to avoid using it.

You should learn OOP but only to see why it's bad (and to actually understand 99% of code written nowadays).

Principles

Bear in mind that OOP doesn't have a single, crystal clear definition. It takes many forms and mutations depending on language and it is practically always combined with other paradigms such as the imperative paradigm, so things may be fuzzy.

Generally OOP programs solve problems by having object that communicate with each other. Every object is specialized to do some thing, e.g. one handles drawing text, another one handles caching, another one handles rendering of pictures etc. Every object has its data (e.g. a human object has weight, race etc.) and methods (object's own functions e.g. human may provide methods getHeight, drinkBeer or petCat). Objects may send messages to each other: e.g. a human object sends a message to another human object to get his name (in practice this means the first object calls a method of the other object just like we call functions, e.g.: `human2.getName().

Now many OO languages use so called class OOP. In these we define object classes, similarly to defining data types. A class is a "template" for an object, it defines methods and types of data to hold. Any object we then create is then created based on some class (e.g. we create the object alice and bob of class Human, just as normally we create a variable x of type int). We say an object is an instance of a class, i.e. object is a real manifestation of what a class describes, with specific data etc.

The more "lightweight" type of OOP is called classless OOP which is usually based on having so called prototype objects instead of classes. In these languages we can simply create objects without classes and then assign them properties and methods dynamically at runtime. Here instead of creating a Human class we rather create a prototype object that serves as a template for other objects. To create specific humans we clone the prototype human and modify the clone.

OOP furthermore comes with some basic principles such as:

encapsulation: Object should NOT be able to access other object's data directly -- they may only use their methods. For example an object shouldn't be able to access the height attribute of a Human object, it should be able to access it only via methods of that object such as getHeight. (This leads to the setter/getter antipattern).
polymorphism: Different objects (e.g. of different classes) may have methods with the same name which behave differently for either object and we may just call that method without caring what kind of object that is (the correct implementation gets chosen at runtime). E.g. objects of both Human and Bomb classes may have a method setOnFire, which with the former will kill the human and with the latter will cause an explosion killing many humans. This is good e.g. in a case when we have an array of GUI components and want to perform e.g. resize on every one of them: we simply iterate over the whole array and call the method resize on each object without caring whether the object is a button, checkbox or a window.
inheritance: In class OOP classes form a hierarchy in which parent classes can have child classes, e.g. a class LivingBeing will have Human and Animal sub classes. Sub classes inherit stuff from the parent class and may add some more. However this leads to other anti patterns such as the diamond_problem. Inheritance is nowadays regarded as bad even by normies and is being replaced by composition.

Why It's Shit

OOP is just a bad abstraction for many problems that by their nature aren't object-oriented. OOP is not a silver bullet, yet it tries to behave as one. The greatest issue of OOP is that it's trying to solve everything. For example it forces the idea that data and algorithms should always come together, but that's simply a stupid statement in general, there is no justification for it, some data is simply data and some algorithms are simply algorithms. You may ask what else to use instead of OOP then -- see the section below.
For simple programs (which most programs should be) such as many Unix utilities OOP is simply completely unnecessary.
OOP languages make you battle artificial restrictions rather than focus on solving the problem at hand.
Great number of the supposed "features" and design patterns (setters/getters, singletons, inheritance, ...) turned out to actually be antipatterns and burdens -- this isn't a controversial statement, even OOP proponents usually agree with this.
OOP as any higher abstraction very often comes with overhead, memory footprint and performance loss bloat as well as more complex compilers, language specifications, more dependencies etc.
The relatively elegant idea of pure OOP didn't catch on and the practically used OOP languages are abomination hybrids of imperative and OOP paradigms that just take more head space, create friction and unnecessary issues to solve. Sane languages now allow the choice to use OOP fully, partially or avoid it completely, which leads to a two-in-one overcomplication.
The naive idea of OOP that the real world is composed of nicely defined objects such as Humans and Trees also showed to be completely off, we instead see shit like AbstractIntVisitorShitFactory etc.
The idea that OOP would lead to code reusability also completely failed, it's simply not the case at all, implementation code of specific classes is typically burdened with internal and external dependencies just like any other bloated code. OOPer believed that their paradigm would create a world full of reusable blackboxes, but that wasn't the case, OOP is neither necessary for blackboxing, nor has the practice shown it would contribute to it -- quite on the contrary, e.g. simple imperative header-only C libraries are much more reusable than those we find in the OOP world.
Good programmers don't need OOP because they know how to program -- OOP doesn't invent anything, it is merely a way of trying to force good programming mostly on incompetent programmers hired in companies, to prevent them from doing damage. However this of course doesn't work, a shit programmer will always program shit, he will find his way to fuck up despite any obstacles and if you invent obstacles good enough for stopping him from fucking up, you'll also stop him from being able to program something that works well as you tie his hands. Yes, good programmers write shit buggy code too, but that's more of a symptom of bad, overcomplicated bloated capitalist design of technology that's just asking for bugs and errors -- here OOP is trying to cure symptoms of an inherently wrong direction, it is not addressing the root cause.
OOP just mostly repeats what other things like modules already do.
If you want to program in object-oriented way and have a good justification for it, you don't need an OOP language anyway, you can emulate all aspects of OOP in simple languages like C. So instead of building the idea into the language itself and dragging it along forever and everywhere, it would be better to have optional OOP libraries.
It generalizes and simplifies programming into a few rules of thumb such as encapsulation, again for the sake of inexperienced noobs. However there are no simple rules for how to program well, good programming requires a huge amount of experience and as in any art, good programmer knows when breaking the general rules is good. OOP doesn't let good programmers do this, it preaches things like "global variables bad" which is just too oversimplified and hurts good programming.

So Which Paradigm To Use Instead Of OOP?

After many people realized OOP is kind of shit, there has been a boom of "OOP alternatives" such as functional, traits, agent oriented programming, all kinds of "lightweight" OOP etc etc. Which one to use?

In short: NONE, by default use the imperative paradigm (also called "procedural"). Remember this isn't to say you shouldn't ever apply a different paradigm, but imperative should be the default, most prevalent and suitable one to use in solving most problems. There is nothing new to invent or "beat" OOP.

But why imperative? Why can't we simply improve OOP or come up with something ultra genius to replace it with? Why do we say OOP is bad because it's forced and now we are forcing imperative paradigm? The answer is that the imperative paradigm is special because it is how computers actually work, it is not made up but rather it's the natural low level paradigm with minimum abstraction that reflects the underlying nature of computers. You may say this is just bullshit arbitrary rationalization but no, these properties makes procedural paradigm special among all other paradigms because:

Its implementation is simple and suckless because it maps nicely and naturally to the underlying hardware -- basically commands in a language simply translate to one or more instructions. This makes construction of compilers easy.
It's predictable and efficient, i.e. a programmer writing imperative code can see quite clearly how what he's writing will translate to the assembly instructions. This makes it possible to write highly efficient code, unlike high level paradigms that perform huge amounts of magic for translating foreign concepts to machine instructions -- and of course this magic may differ between compilers, i.e. what's efficient code in one compiler may be inefficient in another similar situation arose e.g. in the world of OpenGL where driver implementation started to play a huge role and which led to the creation of a more low level API Vulkan.
It doesn't force high amounts of unnecessary high level abstraction. This means we MAY use any abstraction, even OOP, if we currently need it, e.g. via a library, but we aren't FORCED to use a weird high level concepts on problems that can't be described easily in terms of those concepts. That is if you're solving a non-OOP problem with OOP, you waste effort on translating that problem to OOP and the compiler then wastes another effort on un-OOPing this to translate this to instructions. With imperative paradigm this can't happen because you're basically writing instructions which has to happen either way.
It is generally true that the higher the abstraction, the smaller its scope of application should be, so the default abstraction (paradigm) should be low level. This works e.g. in science: psychology is a high level abstraction but can only be applied to study human behavior, while quantum physics is a low level abstraction which applies to the whole universe.

Once computers start fundamentally working on a different paradigm, e.g. functional -- which BTW might happen with new types of computers such as quantum ones -- we may switch to that paradigm as the default, but until then imperative is the way to go.

Markov Chain

segfault — Wed, 25 Oct 2023 00:53:01 +0000

Markov chain is a relatively simple stochastic (working with probability) mathematical model for predicting or generating sequences of symbols. It can be used to describe some processes happening in the real world such as behavior of some animals, Brownian motion or structure of a language. In the world of programming Markov chains are pretty often used for generation of texts that looks like some template text whose structure is learned by the Markov chain (Markov chains are one possible model used in machine learning. Chatbots are just one example).

There are different types of Markov chains. Here we will be focusing on discrete time Markov chains with finite state space as these are the ones practically always used in programming. They are also the simplest ones.

Such a Markov chain consists of a finite number of states S0, S1, ..., Sn. Each state Si has a certain probability of transitioning to another state (including transitioning back to itself), i.e. P(Si,S0), P(Si,S1), ..., P(Si,Sn); these probabilities have to, of course, add up to 1, and some of them may be 0. These probabilities can conveniently be written as a n x n matrix.

Basically Markov chain is like a finite state automaton which instead of input symbols on its transition arrows has probabilities.

Example

Let's say we want to create a simple AI for an NPC in a video game. At any time this NPC is in one of these states:

Taking cover (state A):
- 50% chance to stay in cover
- 50% chance to start looking for a target
Searching for a target (state B):
- 50% chance to remain searching for a target
- 25% chance to start shooting at what it's looking at
- 25% chance to throw a grenade at what it's looking at
Shooting a bullet at the target (state C):
- 70% chance to remain shooting
- 10% chance to throw a grenade
- 10% chance to start looking for another target
- 10% chance to take cover
Throwing a grenade at the target (state D):
- 50% chance to shoot a bullet
- 25% chance to start looking for another target
- 25% chance to take cover

Now it's pretty clear this description gets a bit tedious, it's better, especially with even more states, to write the probabilities as a matrix (rows represent the current state, columns the next state):

	A	B	C	D
A	0.5	0.5	0	0
B	0	0.5	0.25	0.25
C	0.1	0.1	0.7	0.1
D	0.25	0.25	0.5	0

We can see a few things: the NPC can't immediately attack from cover, it has to search for a target first. It also can't throw two grenades in succession etc. Let's note that this model will now be yielding random sequences of actions such as [cover, search, shoot, shoot, cover] or [cover, search, search, grenade, shoot] but some of them may be less likely (for example shooting 3 bullets in a row has a probability of 0.1%) and some downright impossible (e.g. two grenades in a row). Notice a similarity to for example natural language: some words are more likely to be followed by some words than others (e.g. the word "number" is more likely to be followed by "one" than for example "cat").

Explaining Recursion

segfault — Sun, 17 Sep 2023 12:19:01 +0000

In general recursion is a situation in which a definition refers to itself; for example the definition of a human's ancestor as "the human's parents and the ancestors of his parents" fractals are also very nice example of what a simple recursive definition can achieve. In programming recursion takes on a meaning of a function that calls itself; this is the meaning we'll suppose in this article, unless noted otherwise.

We divide recursion to a direct and indirect one. In direct recursion the function calls itself directly, in indirect function A calls a function B which ends up (even possibly by calling some more functions) calling A again. Indirect recursion is tricky because it may appear by mistake and cause a bug (which is nevertheless easily noticed as the program will mostly run out of memory and crash).

When a function calls itself, it starts "diving" deeper and deeper and in most situations we want this to stop at some point, so in most cases a recursion has to contain a terminating condition. Without this condition the recursion will keep recurring and end up in an equivalent of an infinite loop (which in case of recursion will however crash the program with a stack overflow exception). Let's see this on perhaps the most typical example of using recursion, a factorial function:

unsigned int factorial(unsigned int x)
{
  if (x > 1)
    return x * factorial(x - 1); // recursive call
  else
    return 1; // terminating condition
}

See that as long as x > 1, recursive calls are being made; with each the x is decremented so that inevitably x will at one point come to equal 1. Then the else branch of the condition will be taken -- the terminating condition has been met -- and in this branch no further recursive call is made, i.e. the recursion is stopped here and the code starts to descend from the recursion.

Note that even in computing we can use an infinite recursion sometimes. For example in Haskell. it is possible to define infinite data structures with a recursive definition; however this kind of recursion is intentionally allowed, it is treated as a mathematical definition and with correct use it won't crash the program.

Every recursion can be replaced by iteration and vice versa (iteration meaning a loop such as while). In fact some language (e.g. functional do not have loops and handle repetition solely by recursion. This means that you, a programmer, always have a choice between recursion and iteration, and here you should know that recursion is typically slower than iteration. This is because recursion has a lot of overhead: remember that every level of recursion is a function call that involves things such as pushing and popping values on stack, handling return addresses etc. The usual advice is therefore to prefer iteration, even though recursion can sometimes be more elegant/simple and if you don't mind the overhead, it's not necessarily wrong to go for it. Typically this is the case when you have multiple branches to dive into, e.g. in case of quick sort. In the above example of factorial we only have one recurring branch, so it's much better to implement the function with iteration:

unsigned int factorial(unsigned int x)
{
  unsigned int result = 1;

  while (x > 1)
  {
    result *= x;
    x--;
  }

  return result;
}

How do the computers practically make recursion happen? Basically they use a stack to remember states on each level of the recursion. In programming languages that support recursive function calls this is hidden behind the scenes in the form of call stack. This is why an infinite recursion causes stack overflow.

Another important type of recursion is tail recursion which happens when the recursive call in a function is the very last command. It is utilized in functional languages that use recursion instead of loops. This kind of recursion can be optimized by the compiler into basically the same code a loop would produce, so that e.g. stack won't grow tremendously.

All you need to know about Sorting

segfault — Fri, 02 Jun 2023 01:18:43 +0000

Sorting means rearranging a sequence, such as a list of numbers, so that the elements are put in a specific order (e.g. ascending or descending). In computer science sorting is quite a wide topic, there are dozens of sorting algorithms, each with pros and cons and different attributes are being studied, e.g. the algorithm's time complexity, its stability etc. Sorting algorithms are a favorite subject of programming classes as they provide a good exercise for programming and analysis of algorithms and can be nicely put on tests :)

Some famous sorting algorithms include bubble sort (a simple KISS algorithm), quick and merge sort (some of the fastest algorithms) and stupid sort (just tries different permutations until it hits the jackpot).

In practice however we oftentimes end up using some of the simplest sorting algorithms (such as bubble sort anyway, unless we're programming a database or otherwise dealing with enormous amounts of data. If we need to sort just a few hundred of items and/or the sorting doesn't occur very often, a simple algorithm does the job well, sometimes even faster due to a potential initial overhead of a very complex algorithm. So always consider the KISS approach first.

Attributes of sorting algorithms we're generally interested in are the following:

time and space complexity: Time and space complexity hints on how fast the algorithm will run and how much memory it will need, specifically we're interested in the best, worst and average case depending on the length of the input sequence. Indeed we ideally want the fastest algorithm, but it has to be known that a better time complexity doesn't have to imply a faster run time in practice, especially with shorter sequences. An algorithm that's extremely fast in best case scenario may be extremely slow in non-ideal cases. With memory, we are often interested whether the algorithm works in place; such an algorithm only needs a constant amount of memory in addition to the memory that the sorted sequence takes, i.e. the sequence is sorted in the memory where it resides.
implementation complexity: A simple algorithm is better if it's good enough. It may lead to e.g. smaller code size which may be a factor e.g. in embedded - stability: A stable sorting algorithm preserves the order of the elements that are considered equal. With pure numbers this of course doesn't matter, but if we're sorting more complex data structures (e.g. sorting records about people by their names), this attribute may become important.
comparative vs non-comparative: A comparative sort only requires a single operation that compares any two elements and says which one has a higher value -- such an algorithm is general and can be used for sorting any data, but its time complexity of the average case can't be better than O(n * log(n)). Non-comparison sorts can be faster as they may take advantage of other possible integer operations.
recursion and parallelism: Some algorithms are recursive in nature, some are not. Some algorithms can be parallelised e.g. with a GPU which will greatly increase their speed.
other: There may be other specific, e.g. some algorithms are are slow if sorting an already sorted sequence (which is addressed by adaptive sorting), so we may have to also consider the nature of data we'll be sorting. Other times we may be interested e.g. in what machine instructions the algorithm will compile to etc.

In practice not only the algorithm but also its implementation matters. For example if we have a sequence of very large data structures to sort, we may want to avoid physically rearranging these structures in memory, this could be slow. In such case we may want to use indirect sorting: we create an additional list whose elements are indices to the main sequence, and we only sort this list of indices.

All you need to know about Assembly language

segfault — Thu, 01 Jun 2023 03:12:17 +0000

GUYS I AM NOT SO GREAT AT ASSEMBLY,so feel free to correct my errors

Let's start with the basics

Assembly is, for any given hardware platform ISA , the unstructured, lowest levels programming language -- it maps (mostly) 1:1 to machine code (the actual binary CPU instructions) and basically only differs from the actual machine code by utilizing a more human readable form. Assembly is compiled by assembler into the the machine code. Assembly is not a single language, it differs for every architecture, and is therefore not portable!

Typical Assembly Language

The language is unstructured, i.e. there are no control structures such as if or for statements: these have to be manually implemented using labels and jump instructions. The typical look of an assembly program is therefore a single column of instructions with arguments, one per line.

The working of the language reflects the actual hardware architecture -- usually there is a small number of registers (e.g. 16) which may be called something like R0 to R15. These registers are the fastest available memory (faster than the main RAM memory) and are used to perform calculations. Some registers are general purpose and some are special: typically there will be e.g. the FLAGS register which holds various 1bit results of performed operations (e.g. overflow, zero result etc.). Values can be moved between registers and the main memory.

Instructions are typically written as three-letter abbreviations and follow some unwritten naming conventions so that different assembly languages at least look similar. Common instructions found in most assembly languages are for example:

MOV (move): move a number between registers and/or memory.
JMP (jump): unconditional jump to far away instruction.
BEQ (branch if equal): jump if result of previous comparison was equality.
ADD (add): add two numbers.
NOP (no operation): do nothing (used e.g. for delays).
CMP (compare): compare two numbers and set relevant flags (typically for a subsequent conditional jump).

Assembly languages may offer simple helpers such as macros.

A Quick Guide To Vim

segfault — Thu, 25 May 2023 00:46:34 +0000

{ This is WIP, I use Vim but am not such guru really so there may appear some errors, I know this topic is pretty religious so don't eat me. }

Vim (Vi Improved) is a legendary [free as in freedom], fairly (though not hardcore) minimalist and suckless terminal-only (no GUI) text editor for skilled programmers and hackers, and one of the best editors you can choose for text editing and programming. It is a successor of a much simpler editor vi that was made in 1976 and which has become a standard text editor installed on every Unix system. Vim added features like tabs, syntax highlight, scriptability, sessions and plugins and as such has become not just a simple text editor but an editor that can comfortably be used for programming instead of any bloated IDE. Observing a skilled Vim user edit text is really like watching a magician or a literal movie hacker -- the editing is extremely fast, without any use of mouse, it transcends mere text editing and for some becomes something akin a way of life.

Vim is generally known to be "difficult to learn" -- it is not because it is inherently difficult but rather for being very different from other editors -- it has no GUI (even though it's still a screen-oriented interactive TUI, it is keyboard-only and is operated via text commands rather than with a mouse, it's also preferable to not even use arrow keys but rather hjkl keys. There is even a meme that says Vim is so difficult that just exiting it is a non-trivial task. People not acquainted with Vim aren't able to do it and if they accidentally open Vim they have to either Google how to close it or force kill the terminal xD Of course it's not so difficult to do, it's a little bit different than in other software -- you have to press escape, then type :q and press enter (although depending on the situation this may not work, e.g. if you have multiple documents open and want to exit without saving you have to type :wqa etc.). The (sad) fact is that most coding monkeys and "professional programmers" nowadays choose some ugly bloated IDE as their most important tool rather than investing two days into learning Vim, probably the best editor.

Why use Vim?

Well, simply because it is (relatively) suckless, universal and extremely good for editing any text and for any kind of programming, for many it settles the search for an editor -- once you learn it you'll find it is flexible, powerful, comfortable, modifiable, lightweight... it has everything you need. Anyone who has ever invested the time to learn Vim will almost certainly tell you it was one of the best decisions he made and that guy probably only uses Vim for everything now. Many people even get used to it so much they download mods that e.g. add Vim commands and shortcuts to programs like web browsers. A great advantage is that vi is installed on every Unix as it is a standard utility, so if you know Vim, you can just comfortably use any Unix-like system just from the command line: when you ssh into a server you can simply edit files without setting up any remote GUI or whatever. Therefore Vim is automatically a must learn skill for any sysadmin. A huge number of people also use Vim for "productivity" -- even though we don't fancy the productivity cult and the bottleneck of programming speed usually isn't the speed of typing, it is true that Vim makes you edit text extremely fast (you don't move your hands between mouse and keyboard, you don't even need to touch the arrow keys, the commands and shortcuts make editing very efficient). Some nubs think you "need" a huge IDE to make big programs, that's just plain wrong, you can do anything in Vim that you can do in any other IDE, it's as good for editing tiny files as for managing a huge codebase.

Vim's biggest rival is Emac, a similar editor which is however more complex and bloated (it is joked that Emacs is really an operating system -- Vim is more suckless, yet not less powerful, and so it is naturally the choice of the suckless community and also ours. Vim and Emacs are a subject of a holy war for the the best editor yet developed; the Emacs side calls itself the Church of Emacs, led by Richard Stallman (who created Emacs) while the Vi supporters are called members of the Cult of Vim (vi vi vi = 666).

It has to be noted that Vim as a program is still kind of bloated, large part of the suckless community acknowledges this (cat-v) lists Vim as harmful, recommends Acme, Sam or ed instead). Nonetheless the important thing is that Vim is a good de facto standard -- the Vim's interface and philosophy is what matters the most, there are alternatives you can comfortably switch to. The situation is similar to for example "Unix as a concept", i.e. its interface, philosophy and culture, which together create a certain standardization that allows for different implementations that can be switched without much trouble. In the suckless community Vim has a similar status to C, Linux or X11 -- it is not ideal, by the strict standards it is a little bit bloated, however it is one of the best existing solutions and makes up for its shortcomings by being a stable, well established de-facto standard.

How To

These are some Vim basics for getting started. There are two important editing modes in Vim:

insert mode: For writing text, you just type text as normal. Pressing ESC enters command mode. Here CTRL + n can be used for text completion.
command mode: For executing commands. Pressing i enters insert mode.

Some important commands in command mode are:

arrow keys: Can be used for moving cursor, even though many prefer to use the hjkl keys. With SHIFT held down the cursor moves horizontally by words and by screens vertically.
h,j,k,l: Cursor movement.
$: Move cursor to end of the line.
0: Move cursor to start of the line.
CTRL + w + w: Move between windows (created with :split or :vspit).
CTRL + PAGEUP, CTRL + PAGEDOWN: Move between tabs.
u: Undo.
CTRL + SHIFT + r: Redo.
:: Allows entering longer commands. TAB can be used for completion and up/down keys for listing command history. Some of the commands are:
- q: Quit, or close the current extra window/tab. Use qa for closing all windows/tabs and quit. q! (or qa!) quits without saving changes, wq quits with saving changes, wqa quits all saving all changes etc.
- w: Save changes (can be followed by filename).
- noh: Cancel highlighted text (e.g. after search).
- !: Run command in terminal, you can e.g. compile your program this way. For running Vim commands before the terminal commands use vimcommands |! terminalcommands, e.g. :wa |! make && ./program.
- tabedit filename: Opens given file in a new tab (tabs are closed with :q).
- tabmove number: Move current tab to given position (+ and - can be used for relative movement of tabs).
- vsplit: Creates a new window by splitting the current one vertically.
- split: Creates a new window by splitting the current on horizontally.
- >: Indent to the right, well combined with text selection (v, V).
- .: Repeat previous command.
- %s/find/replace/g: Search and replace regex, sed style.
- help command: Show help about given command.
- set variable value: Set a variable, used e.g. in configs.
/pattern: Search for a regex patter entered after /. Found matches will be highlighted (:noh cancels the highlight), you can move to the next one with n and to the previous one with N.
NUMBER G: Go to line with given number (0 means last line).
v, V: Select/highlight text (by characters and by lines).
d: Delete, this is followed by a command saying what to delete, e.g. dw deletes to the end of the word, dd deletes the whole line. WARNING: delete actually copies the deleted text into clipboard (it behaves like cut)!
o: Insert new line.
p: Paste.
y: Copy (yank), followed by a command saying what to copy (e.g. yw copies a word), yy copies the whole line.

Vim can be configured with a file named .vimrc in home directory. In it there is a set of commands that will automatically be run on start. Example of a simple config file follows:

set number " set line numbering
set et     " expand tabs
set sw=2
set hlsearch
set nowrap          " no line wrap
set colorcolumn=80  " highlight 80th column
set list
set listchars=tab:>.
set backspace=indent,eol,start
syntax on

What's An Algorithm

segfault — Tue, 23 May 2023 00:57:00 +0000

Algorithm is an exact description of how to solve a problem. Algorithms are basically what programming is all about: we tell computers, in very exact ways with programming languages, how to solve problems -- we write algorithms. But algorithms don't have to be just computer programs, they are simply instruction for solving problems.

Cooking recipes are sometimes given as an example of a non-computer algorithm (though they rarely contain branching and loops, very typical features of algorithms). The so called wall-follower is a simple algorithm to get out of any maze: you just pick either a left-hand or right-hand wall and then keep following it. You may write a crazy algorithm for how to survive in a jungle, but it has to be exact; if there is any ambiguity, it is not considered an algorithm.

Interesting fact: contrary to intuition there are problems that are mathematically proven to be unsolvable by any algorithm, but for most practically encountered problems we can write an algorithm (though for some problems even our best algorithms can be unusably slow).

Algorithms are mostly (possibly declarative, depending on definitions) written as a series of steps (or instructions); these steps may be specific actions (such as adding two numbers or drawing a pixel to the screen) or conditional jumps to other steps ("if condition X holds then jump to step N, otherwise continue"). These jumps can be used to create branches (in programming known as if-then-else) and loops. Branches and loops are together known as control structures -- they don't express a direct action but control where we move in the algorithm itself. All in all, any algorithm can be written with only these three constructs:

sequence: A series of steps, one after another.
selection (branches, if-then-else): Two branches (sequences of steps) preceded by a condition; the first branch is executed only if the condition holds, the second ("else") branch is executed only if the condition doesn't hold (e.g. "If user password is correct, log the user in, otherwise print out an error.").
iteration (loops, repetition): Sequence of steps that's repeated as long as certain condition holds (e.g. "As long as end of file is not reached, read and print out next character from the file.").

Note: in a wider sense algorithms may be expressed in other ways than sequences of steps non-imperative ways, even mathematical equations are often called algorithms because they imply the steps towards solving a problem. But we'll stick to the common meaning of algorithm given above.

Additional constructs can be introduced to make programming more comfortable, e.g. subroutines/functions (kind of small subprograms that the main program uses for solving the problem) or switch statements (selection but with more than two branches). Loops are also commonly divided into several types: counted loops, loops with condition and the beginning and loops with condition at the end (for, while and do while in C, respectively). Similarly to mathematical equations, algorithms make use of variables, i.e. values which can change that have a specific name (such as x or myVariable).

Practical programming is based on expressing algorithm via text, but visual programming is also possible: flowcharts are a way of visually expressing algorithms, you have probably seen some. Decision trees are special cases of algorithms that have no loops, you have probably seen some too. Even though some languages (mostly educational such as Snap are visual and similar to flow charts, it is not practical to create big algorithms in this way -- serious programs are written as a text in programming language.

Example

Let's write a simple algorithm that counts the number of divisors of given number x and checks if the number is prime along the way. (Note that we'll do it in a naive, educational way -- it can be done better). Let's start by writing the steps in plain English:

Read the number x from the input.
Set the divisor counter to 0.
Set currently checked number to 1.
While currently checked number is lower or equal than x:
- a: If currently checked number divides x, increase divisor counter by 1.
- b: Increase currently checked number.
Write out the divisor counter.
If divisor counter is equal to 2, write out the number is a prime.

Notice that x, divisor counter and currently checked number are variables. Step 4 is a loop (iteration) and steps a and 6 are branches (selection). The flowchart of this algorithm is:

               START
                 |
                 V
               read x
                 |
                 V
       set divisor count to 0
                 |
                 V
       set checked number to 1
                 |
    ------------>|
    |            |
    |            V                no
    |    checked number <= x ? -------
    |            |                   |
    |            | yes               |
    |            V                   |
    |     checked number    no       |
    |       divides x ? --------     |
    |            |             |     |
    |            | yes         |     |
    |            V             |     |
    |     increase divisor     |     |
    |       count by 1         |     |
    |            |             |     |
    |            |             |     |
    |            |<-------------     |
    |            |                   |
    |            V                   |
    |     increase checked           V
    |       number by 1     print divisor count
    |            |                   |
    --------------                   |
                                     V             no
                             divisor count = 2 ? ------
                                     |                |
                                     | yes            |
                                     V                |
                           print "number is prime"    |
                                     |                |
                                     |<----------------
                                     V
                                    END

This algorithm would be written in Python as:

x = int(input("enter a number: "))

divisors = 0

for i in range(1,x + 1):
  if x % i == 0: # i divides x?
    divisors = divisors + 1

print("divisors: " + str(divisors))

if divisors == 2:
  print("It is a prime!")

and in C as:

#include <stdio.h>                                                              

int main(void)
{
  int x, divisors = 0;

  scanf("%d",&x); // read a number

  for (int i = 1; i <= x; ++i)
    if (x % i == 0) // i divides x?
      divisors = divisors + 1;

  printf("number of divisors: %d\n",divisors);

  if (divisors == 2)
    puts("It is a prime!");

  return 0;
}

Study of Algorithms

As algorithms are at the heart of [computer science, there's a lot of rich theory and knowledge about them.

Turing machine, a kind of mathematical bare-minimum computer, created by Alan Turing, is the traditional formal tool for studying algorithms, though many other models of computation exist. From theoretical computer science we know not all problems are computable, i.e. there are problems unsolvable by any algorithm (e.g. the [halting problem. Computational complexity is a theoretical study of resource consumption by algorithms, i.e. how fast and memory efficient algorithms are (see e.g. P vs NP. Mathematical programming is concerned, besides others, with optimizing algorithms so that their time and/or space complexity is as low as possible which gives rise to algorithm design methods such as dynamic programming (optimization is a less theoretical approach to making more efficient algorithms). Formal verification is a field that tries to mathematically (and sometimes automatically) prove correctness of algorithms (this is needed for critical software, e.g. in planes or medicine). Genetic programming and some other methods of artificial intelligence try to automatically create algorithms (algorithms that create algorithms). Quantum computingis concerned with creating new kind of algorithms algorithms for quantum computers (a new type of still-in-research computers). [Programming language design is an art of finding best ways of expressing algorithms.

Specific Algorithms

Following are some common algorithms classified into groups.

graphics

DDA : line drawing algorithm
Bresenham's algorithm : another line drawing algorithm
Midpoint algorithm : circle drawing algorithm
flood fill : algorithm for coloring continuous areas
Hough transform : finds shapes in pictures
painter's algorithm
path tracing
ray tracing
Boot'h algorithm : algorithm for multiplication
Dijkstra's algorithm
Euclidean algorithm: computes greatest common divisor
numerical algorithm : approximate mathematical functions
sieve of Eratosthenes : computes prime numbers
bubble sort : simple, kind of slow but still usable sorting algorithm
quick sort : one of the fastest sorting algorithms
- searching
binary search
linear search
- other
A* : path searching algorithm, used by AI in many games
fizzbuzz : problem/simple algorithm given in job interviews to filter out complete noobs
FFT: quickly converts signal (audio, image, ...) to its representation in frequencies, one of the most famous and important algorithms
Huffman coding : compression algorithm
k-means : clustering algorithm
MD5: hash function
minimax plus alpha-beta pruning : used by many AI that play turn based games
proof of work algorithms: used by some cryptocurrencies
Shor's algorithm: factorization algorithm
YouTube algorithm: secret algorithm YouTube uses to suggest videos to viewers, a lot of people hate it :)

A Short Introduction To AI

segfault — Wed, 17 May 2023 01:33:12 +0000

Artificial Intelligence

Artificial intelligence (AI) is an area of computer science whose effort lies in making computers simulate thinking of humans and possibly other biologically living beings.

This may include making computers play games such as chess , compose music, paint pictures, understand and processing audio, images and text on high level of abstraction (e.g. translation between natural languages), making predictions about complex systems such as stock market or weather or even exhibit a general human-like behavior.

Even though today's focus in AI is on machine learning and especially neural networks, there are many other usable approaches and models such as "hand crafted" state tree searching algorithms that can simulate and even outperform the behavior of humans in certain specialized areas.

There's a concern that's still a matter of discussion about the dangers of developing a powerful AI, as that could possibly lead to a technological singularity in which a super intelligent AI might take control over the whole world without humans being able to seize the control back. Even though it's still likely a far future and many people say the danger is not real, the question seems to be about when rather than if.

By about 2020, "AI" has become a capitalist. They try to put machine learning into everything just for that AI label -- and of course, for a bloat monopoly

By 2023 neural network AI has become extremely advanced in processing visual, textual and audio information and is rapidly marching on.

Networks such as stable diffusion are now able to generate images (or modify existing ones) with results mostly indistinguishable from real photos just from a short plain language textual description.

Text to video AI is emerging and already giving nice results. AI is able to write computer programs from plain language text description.

Chatbots, especially the proprietary chatGPT, are scarily human-like and can already carry on conversation mostly indistinguishable from real human conversation while showing extraordinary knowledge and intelligence -- the chatbot can for example correctly reason about advanced mathematical concepts on a level much higher above average human.

AI has become mainstream and is everywhere, normies are downloading "AI apps" on their phones that do funny stuff with their images while spying on them. In games such as chess or even strategy video games neural AI has already been for years far surpassing the best of humans by miles.

CLI VS GUI

segfault — Thu, 24 Nov 2022 11:05:58 +0000

There are a few reasons for this:

The command line and graphical user interface (GUI) are two different ways of interacting with a computer. The command line, also known as the command-line interface (CLI), is a text-based interface that allows users to enter commands using a keyboard. The GUI, on the other hand, is a visual interface that allows users to interact with the computer using a mouse, touchpad, or other pointing device.

The command line has been around since the earliest days of computing, and it is still used by many programmers and other technical professionals. The command line allows users to enter commands directly, which can be very powerful and efficient, especially for tasks that require precise control or require the use of multiple commands.

However, the command line can be challenging for some users, as it requires a certain level of knowledge and familiarity with the system, as well as the ability to remember and enter commands correctly. In contrast, the GUI is designed to be more user-friendly, and it allows users to interact with the computer using visual cues and familiar metaphors, such as windows, icons, and menus.

Despite the advantages of the GUI, the command line remains popular among many users, particularly among those who are comfortable with using the keyboard and who prefer the efficiency and flexibility of the command line. For example, the command line is often used by programmers and other technical professionals who need to perform complex tasks or manage large amounts of data.

In conclusion, the command line and GUI are two different ways of interacting with a computer, and each has its own advantages and disadvantages.

The main advantage of the command line is that it is very powerful and efficient, especially for tasks that require precise control or the use of multiple commands. The command line also allows users to automate tasks using scripts and other tools, and it is often used by programmers and other technical professionals.

However, the command line has some disadvantages as well. One of the main disadvantages is that it can be difficult for some users to learn and use, as it requires a certain level of knowledge and familiarity with the system, as well as the ability to remember and enter commands correctly. Additionally, the command line can be less user-friendly and less intuitive than the GUI, which can make it less accessible to some users.

The main advantage of the GUI is that it is designed to be more user-friendly and intuitive, and it allows users to interact with the computer using visual cues and familiar metaphors, such as windows, icons, and menus. This makes the GUI more accessible to a wider range of users, including those who may not have experience with computers.

However, the GUI also has some disadvantages. One of the main disadvantages is that it can be less efficient than the

The command line interface is much faster than the graphical user interface.

The command line interface is much more flexible.

You can do things with the command line interface that you can't do with the graphical user interface
For example, you can use the command line to view hidden files and folders, change file permissions, and access system settings that are not typically exposed in a graphical user interface.

The command line interface is faster and more efficient than the graphical user interface.

The command line interface allows you to automate tasks more easily.

The command line interface gives you more control over your system.

The command line interface is more faster and efficient

The CLI is more powerful and flexible.

The CLI is more accurate than a GUI.

Introduction To Filesystem

segfault — Sat, 12 Nov 2022 02:06:48 +0000

For all the zoomers out there that don't know what a file is?

A file is a collection of data or information that is related each other for example it is a collection of related documents or papers that are arranged so that they can be consulted easily

Computer file:it is a digital data that contains stored information and stored in a computer readable form.it is a digital information stored in a computer format(electronic format) which is available to a computer programmer and is based on some kind of durable storage.

Field: it is also called "attributes" is an area reserved for each piece of individual data(each data) such as student's number,address and number.

Record: is a group of related file pertaining to one person's place or thing

Data item: is a single member of a data element.it's a unit stored data to a field.

Types of data item

Numeric data
Alphabetic data
Graphical data
Alphanumeric data
Audio data