Forem: Alireza Shabani

Why GNOME’s Translation Platform Is Called "Damned Lies"

Alireza Shabani — Wed, 11 Jun 2025 13:39:01 +0000

Damned Lies is the name of GNOME’s web application for managing localization (l10n) across its projects. But why is it named like this?

Damned Lies about GNOME

On the About page of GNOME’s localization site, the only explanation given for the name Damned Lies is a link to a Wikipedia article called "Lies, damned lies, and statistics".

"Damned Lies" comes from the saying "Lies, damned lies, and statistics" which is a 19th-century phrase used to describe the persuasive power of statistics to bolster weak arguments, As described on Wikipedia. One of its earliest known uses appeared in an 1891 letter to the National Observer, which categorized lies into three types:

"Sir, —It has been wittily remarked that there are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third and most aggravated is statistics. It is on statistics and on the absence of statistics that the advocate of national pensions relies ..."

To find out more, I asked in GNOME’s i18n Matrix room, and Alexandre Franke helped a lot, he said:

Stats are indeed lies, in many ways.

Like if GNOME 48 gets 100% translated in your language on Damned Lies, it doesn’t mean the version of GNOME 48 you have installed on your system is 100% translated, because the former is a real time stat for the branch and the latter is a snapshot (tarball) at a specific time.

So 48.1 gets released while the translation is at 99%, and then the translators complete the work, but you won’t get the missing translations until 48.2 gets released.

Works the other way around: the translation is at 100% at the time of the release, but then there’s a freeze exception and the stats go 99% while the released version is at 100%.

Or you are looking at an old version of GNOME for which there won’t be any new release, which wasn’t fully translated by the time of the latest release, but then a translator decided that they wanted to see 100% because the incomplete translation was not looking as nice as they’d like, and you end up with Damned Lies telling you that version of GNOME was fully translated when it never was and never will be.

All that to say that translators need to learn to work smart, at the right time, on the right modules, and not focus on the stats.

So there you have it: Damned Lies is a name that reminds us that numbers and statistics can be misleading even on GNOME's I10n Web application.

Journey to GNOME Circle: Community, App Ideas, and Getting Started

Alireza Shabani — Sun, 13 Apr 2025 17:58:14 +0000

Hello, chat! I'm Revisto, and I want to share my journey to GNOME Circle and how I became a GNOME Foundation member. I'll discuss my experiences and the development path of Drum Machine. This is the first part of the "Journey to GNOME Circle" series.

I love Free and Open Source communities, especially GNOME and GNOME Circle. I find contributing to open source communities far more rewarding than contributing to projects maintained by a single individual. If you find the right community, there are many experienced, generous, and humble people you can learn from. You can explore various projects maintained by the community, experience consistent quality, be surrounded by an amazing community, and even enjoy some perks!

I found the GNOME community to be one of the best in the FOSS industry. Why?

There are lots of apps and projects you can contribute to, from GTK to Terminal to GNOME Shell itself.
It has a welcoming community full of experienced people.
GNOME looks fantastic, thanks to Jakub Steiner. The GNOME design is stunning. It has great documentation and handbooks for beginners, making it super beginner-friendly.
Different ways to contribute, you can help with documentation, programming, design, translation, create new apps, and more.
Membership perks.

GNOME Foundation Membership?!

The GNOME Foundation offers membership to its active contributors. Whether you're an active translator, help with documentation, enhance GNOME's appearance, or generally MAKE GNOME BETTER, you can apply for membership. Additionally, if your app gets into GNOME Circle, you qualify for membership.

What are the perks?

Here are some of the perks in summary. You can find complete information here.

Email Alias (nickname@gnome.org): gnome.org email addresses are provided for all Foundation members. This address is an alias which can be used as a relay for sending and receiving emails.
Your own blog at blogs.gnome.org: Foundation members are eligible to host their blog on blogs.gnome.org.
Listing on Planet GNOME: Foundation members who have blogs can have them included on planet.gnome.org.
Travel sponsorship for events: Foundation members are eligible for travel sponsorship to GNOME conferences and events.
Nextcloud (cloud.gnome.org): GNOME hosts a Nextcloud instance at cloud.gnome.org. This provides a range of services, including file hosting, calendaring, and contact management.

These are useful and beneficial for your reputation and branding. I use my email alias for GNOME-related work at AlirezaSh@gnome.org, have my blog at alirezash.gnome.org, and sync my Obsidian notes with Nextcloud on GNOME infrastructure. Unfortunately, I couldn't get my travel sponsorship as a speaker at events because I'm from Iran, and due to OFAC regulations which is so unfair.

What's GNOME Circle?

I've always had the idea of creating beautiful, useful apps for Linux. There were many apps I needed but couldn't find a good version for Linux, and some apps I wished had better GUIs.

GNOME Circle is a collection of applications and libraries that extend the GNOME ecosystem.

"GNOME Circle champions the great software that is available for the GNOME platform. Not only do we showcase the best apps and libraries for GNOME, but we also support independent developers who are using GNOME technologies."

— GNOME Circle

In GNOME, we have core apps like Terminal, GNOME Shell, Text Editor, etc., and we have GNOME Circle apps. These are apps that independent developers have created using GNOME technologies (GTK and Libadwaita), following the GNOME Human Interface Guidelines, and meeting the app criteria. Once accepted, these apps become part of GNOME Circle.

GNOME Circle has lots of really cool apps that you should check out. It includes Curtail, an application to compress your images; Ear Tag, an audio file tags editor; Chess Clock, which provides time control for over-the-board chess games.

GNOME Circle is really cool, full of beautiful apps and creative developers.

App Idea?

If GNOME Circle sounds interesting to you, or you like GNOME Foundation membership perks, or you appreciate the open-source community, or you want to create an app that fulfills your own needs, you should have an idea. What app do you want to develop? I believe we all have ideas. Personally, I really want a good VPN client for Linux (because of censorship in Iran, it's vital), or a good-looking, user-friendly download manager, among other apps.

I highly recommend you check out other applications on GNOME Circle. There are lots of creative projects there that can inspire you. Some of my favorites:

Wike: Search and read Wikipedia articles.
Komikku: Discover and read manga & comics.
Fretboard: Look up guitar chords.
Ear Tag: Edit audio file tags.

I think it's a good idea to check if your idea has already been implemented. You can check the apps in GNOME Circle and also check the apps that are being reviewed by the GNOME Circle Committee to become part of the circle soon: GNOME Circle Issues.

Although you can submit a new app with a similar idea to an existing app, I believe it would be better to bring new ideas to the circle or even contribute to existing circle apps that align with your idea.

On a side note, I really enjoy reading other people's app requests and discussions here. I've been reading them to familiarize myself with the application acceptance process and understand the possible reasons an app might get rejected.

Since I'm a music producer (listen to my work here), I really like the idea of making music production in Linux easier. I had music-related ideas for my first app in the Circle: synthesizers, drum machines, and eventually a DAW (Digital Audio Workstation). I started simple and went with Drum Machine. I looked at different online drum machines such as drumbit.app and onemotion.com/drum-machine, then I started thinking about how I wanted my own drum machine to look like and I drew this (I know it doesn't look good; I'm bad at drawing >-<).

Now I had motivation, an idea, and wanted to actually start making.
I'll detail the development process and evolution of Drum Machine in the next post, so stay tuned!

You can find me here:

Mastodon: @revisto@mastodon.social
Blog: blogs.gnome.org/AlirezaSh
GitHub: github.com/revisto
LinkedIn: linkedin.com/in/revisto
Youtube: youtube.com/@theRevisto
Telegram (Personal): t.me/revisto
Telegram (Tech Channel in Farsi): t.me/revistoTech

Thanks for reading!

SOLID Design Principles: Learn the Dependency Inversion Principle

Alireza Shabani — Mon, 04 Dec 2023 09:31:49 +0000

👋 Hey there, fellow software enthusiasts!

I'm Revisto, a passionate software engineer 👨‍💻, and I want to dive into the exciting world of SOLID principles.

SOLID is a set of rules and principles that help us create maintainable, reusable, and flexible software designs. These principles guide us in building software that can adapt and grow as our projects evolve. Today, we will focus on the third principle of SOLID.

The Dependency Inversion Principle (DIP):

✨ Now, let's shine a light on the Dependency Inversion Principle (DIP). This principle focuses on managing dependencies between classes, aiming to create software systems that are flexible, maintainable, and extensible.

💡 The core idea of the DIP can be summarized as "depend on abstractions, not on concretions." In other words, classes should rely on interfaces or abstract classes rather than concrete implementations. By doing so, we invert the traditional dependency flow.

Robert C. Martin, one of the proponents of SOLID principles, defines the Dependency Inversion Principle in two parts:

High-level modules should not depend on low-level modules. Both should depend on abstractions. This means that the modules at a higher level of abstraction should not rely on the lower-level details. Instead, they should depend on abstract interfaces or classes.
Abstractions should not depend on details. Details should depend on abstractions. This emphasizes that the abstract interface or class should not be influenced by the specific implementation details. It should provide a contract that the concrete implementations adhere to.

📔 Common Example:

Understanding the Scenario:
Imagine we have a Logger class that is responsible for writing log messages to a file. We also have a Calculator class that performs arithmetic operations and uses the Logger class to log information about those operations.

class Logger:
    def log(self, message):
        with open('log.txt', 'a') as f:
            f.write(message + '\n')

class Calculator:

    def __init__(self):
        self.logger = Logger()

    def add(self, x, y):
        result = x + y
        self.logger.log(f"Added {x} and {y}, result = {result}")
        return result

❌ In the original implementation, the Calculator class directly creates an instance of the Logger class within its constructor. This creates a strong dependency between the two classes, making it difficult to modify or replace the Logger implementation in the future.

from abc import ABC, abstractmethod

class LoggerInterface(ABC):
    @abstractmethod
    def log(self, message):
        pass

class Logger(LoggerInterface):
    def log(self, message):
        with open('log.txt', 'a') as f:
            f.write(message + '\n')

class Calculator:
    def __init__(self, logger: LoggerInterface):
        self.logger = logger

    def add(self, x, y):
        result = x + y
        self.logger.log(f"Added {x} and {y}, result = {result}")
        return result

To adhere to the Dependency Inversion Principle, we can introduce an interface, LoggerInterface, which defines the log method. The Logger class then implements this interface, ensuring it adheres to the contract defined by the interface.

By adhering to the Dependency Inversion Principle, we achieve loose coupling between classes, making our software more flexible and easier to maintain. It also enhances code reusability and allows for more straightforward testing and future modifications.

🚀 Stay tuned for more articles where we'll explore other exciting programming topics and delve into the exciting world of software engineering.

Thanks for reading. Feel free to comment your thoughts😊. Hope this post was helpful. You can hit me up on Linked In and Github.

Happy coding!

SOLID Design Principles: Learn the Interface-Segregation Principle

Alireza Shabani — Mon, 27 Nov 2023 15:16:09 +0000

👋 Hey there, fellow software enthusiasts!

I'm Revisto, a passionate software engineer 👨‍💻, and I want to dive into the exciting world of SOLID principles.

S: Single Responsibility Principle
O: Open-Closed Principle
L: Liskov Substitution Principle
I: Interface Segregation Principle
D: Dependency Inversion Principle

Understanding the Interface Segregation Principle:

✨ In object-oriented programming, an interface represents a set of behaviors that an object can perform. It serves as a contract that defines the methods an object must have. The purpose of interfaces is to enable clients to interact with objects through a common interface, without needing to know the intricate details of how those methods are implemented.

The core idea behind the Interface Segregation Principle can be summarized as follows:

Clients should not be forced to depend upon methods that they do not use. Interfaces belong to clients, not to hierarchies🤩.

In Python, abstract classes are commonly used as interfaces, aligning with the philosophy of duck typing. The duck typing principle states that:

If it walks like a duck and quacks like a duck, it must be a duck🦆.

📔 Common Example:

from abc import ABC, abstractmethod

class Printer(ABC):
    @abstractmethod
    def print(self, document):
        pass

    @abstractmethod
    def fax(self, document):
        pass

    @abstractmethod
    def scan(self, document):
        pass

class OldPrinter(Printer):
    def print(self, document):
        print(f"Printing {document} in black and white...")

    def fax(self, document):
        raise NotImplementedError("Fax functionality not supported")

    def scan(self, document):
        raise NotImplementedError("Scan functionality not supported")

The ISP suggests that interfaces should be designed in a way that clients are not forced to depend on methods they don't need.

❌ The OldPrinter class implements the print method to print documents in black and white. However, it raises NotImplementedError for the fax and scan methods, indicating that these functionalities are not supported by this particular printer.

from abc import ABC, abstractmethod

class Printer(ABC):
    @abstractmethod
    def print(self, document):
        pass

class Fax(ABC):
    @abstractmethod
    def fax(self, document):
        pass

class Scanner(ABC):
    @abstractmethod
    def scan(self, document):
        pass

class OldPrinter(Printer):
    def print(self, document):
        print(f"Printing {document} in black and white...")

class NewPrinter(Printer, Fax, Scanner):
    def print(self, document):
        print(f"Printing {document} in color...")

    def fax(self, document):
        print(f"Faxing {document}...")

    def scan(self, document):
        print(f"Scanning {document}...")

More examples at my GitHub

By adhering to the Interface Segregation Principle, we can craft interfaces that are meaningful and concise, tailored specifically to the needs of clients. This principle empowers us to create software systems that are adaptable, maintainable, and efficient. Remember, SOLID principles serve as valuable guidelines for building software that stands the test of time.

🚀 Stay tuned for more articles where we'll explore the other SOLID principles and delve into the exciting world of software engineering.

Thanks for reading. Feel free to comment your thoughts😊. Hope this post was helpful. You can hit me up on Linked In and Github.

Happy coding!

SOLID Design Principles: Learn the Liskov-Substitution Principle

Alireza Shabani — Sat, 25 Nov 2023 11:01:54 +0000

👋 Hey there, fellow software enthusiasts!

I'm Revisto, a passionate software engineer 👨‍💻, and I want to dive into the exciting world of SOLID principles.

S: Single Responsibility Principle
O: Open-Closed Principle
L: Liskov Substitution Principle
I: Interface Segregation Principle
D: Dependency Inversion Principle

✨ The Liskov Substitution Principle is named after the brilliant Barbara Liskov. Simply put, it states that a child class should be able to replace its parent class seamlessly. This means that objects of the child class should be able to substitute objects of the parent class without causing any issues or breaking the application's integrity.

In other words, any piece of code that interacts with objects of a specific type should continue to function correctly even when those objects are replaced with instances of a subtype.

Subtypes must be substitutable for their base types.

(A subtype can be either a class extending another class or a class implementing an interface.)

Let's consider an example to better grasp the concept. Imagine we have a Teleportation class in our codebase. According to the Liskov Substitution Principle, we should be able to substitute the Teleportation class with any of its subclasses, such as Car, Bike or Cycle, without causing any issues or breaking the existing code🤩.

📔 Example

from abc import ABC, abstractmethod

class TransporationDevice(ABC):
        @abstractmethod
        def start_engine(self):
            pass

class Car(TransporationDevice):
        def start_engine(self):
           print("Starting Engine...")

class Bike(TransporationDevice):
        def start_engine(self):
           print("Starting Engine...")

class Cycle(TransporationDevice):
        def start_engine(self):
          # Bicyles don't have engines
          raise NotImplementedError()

❌ The TransporationDevice class doesn't adhere to the Liskov Substitution Principle. When we think about scaling, there is a problem because not all the devices have engines and then there would be a problem.
When that happens, the TransporationDevice class needs to change to support all devices and use other classes for all teleportation kinds. Thus, the current design violates OCP.

from abc import ABC, abstractmethod

class TransporationDevice(ABC):
    @abstractmethod
    def start(self):
        """Steps to start the vehicle"""

class TransporationDeviceWithoutEngine(ABC):
    pass

class TransporationDeviceWithEngine(ABC):        
    @abstractmethod
    def start_engine(self):
        """Process to start the engine"""

class Car(TransporationDeviceWithEngine):

        def start(self):
            # First start engine
            self.start_engine()
            # Do other steps here

        def start_engine(self):
           print("Starting Engine...")

class Bike(TransporationDeviceWithEngine):
        def start(self):
            # First start the engine
            self.start_engine()
            # Do other steps here

        def start_engine(self):
           print("Starting Engine...")


class Cycle(TransporationDeviceWithoutEngine):
        def start(self):
            print("Hit pedals....")

More examples at my GitHub

Benefits of Applying LSP:

By adhering to the Liskov Substitution Principle, we can ensure that our code remains flexible and robust. It reduces the chances of introducing bugs or errors when extending our codebase.

🚀 Stay tuned for more articles where we'll explore the other SOLID principles and delve into the exciting world of software engineering.

Thanks for reading. Feel free to comment your thoughts😊. Hope this post was helpful. You can hit me up on Linked In and Github.

Happy coding!

SOLID Design Principles: Learn the Open-Closed Principle

Alireza Shabani — Sun, 19 Nov 2023 14:13:25 +0000

👋 Hey there, fellow software enthusiasts!
I'm Revisto, a passionate software engineer, and I want to dive into the exciting world of SOLID principles.

SOLID is a set of rules and principles that can help us create maintainable, reusable, and flexible software designs. Essentially, it provides guidelines for building software that can help our projects grow easily.

So, what does SOLID stand for? Let's break it down:

S: Single Responsibility Principle
O: Open-Closed Principle
L: Liskov Substitution Principle
I: Interface Segregation Principle
D: Dependency Inversion Principle

✨ One of the fundamental principles of SOLID is the Open-Closed Principle (OCP). It states that a class, method, or function should be open for extension but closed for modification. In other words, w*e should be able to easily extend the functionality of a software component without having to modify its existing code.*

So, what does it mean for a component to be open for extension? It means that we can add new features or behaviors to the component without modification. This can be achieved through techniques like inheritance, where we can create new classes or functions that build upon the existing ones.

By adhering to the Open-Closed Principle, we create software components that are flexible and adaptable🤩. When new requirements or features arise, we can simply extend the existing codebase rather than modify it. This reduces the risk of introducing bugs and makes our software more maintainable in the long run.

Let's take a look at a couple of examples to illustrate the Open-Closed Principle in action:

👨‍💻 Example: Inheritance

def calculate(income, deduction, country):
    # tax_amount variable is defined
    # in each calculation
    tax_amount = int()
    taxable_income = income - deduction
    if country == "India":
        # calculation here
        pass
    elif country == "US":
        # calculation here
        pass
    elif country == "UK":
        # calculation here
        pass
    return tax_amount

❌ The calculate function doesn't adhere to the Open-Closed Principle. When we think about scaling and users from several countries start using the app, then there would be a problem.
When that happens, the TaxCalculator class needs to change to support the new countries and their rules. Thus, the current design violates OCP.

from abc import ABC, abstractmethod

class CountryTaxCalculator(ABC):
    @abstractmethod
    def calculate_tax_amount(self):
        pass

class TaxCalculatorForUS(CountryTaxCalculator):
    def __init__(self, total_income, total_deduction):
        self.total_income = total_income
        self.total_deduction = total_deduction

    def calculate_tax_amount(self):
        taxable_income = self.total_income - self.total_deduction
        # calculation here 
        return taxable_income 


class TaxCalculatorForUK(CountryTaxCalculator):
    def __init__(self, total_income, total_deduction):
        self.total_income = total_income
        self.total_deduction = total_deduction

    def calculate_tax_amount(self):
        taxable_income = self.total_income - self.total_deduction
        # calculation here 
        return taxable_income

More examples at my GitHub

Adhering to the single responsibility principle is crucial. Make sure that each class or module has a clear and distinct responsibility. If a class becomes responsible for multiple tasks, it's a sign that it should be broken down into smaller, more focused units.

Open-Closed Principle VS Single-Responsibility Principle

Here I quote from this post from sanderarts:

The Single Responsibility Principle deals with the fact that if a class has multiple responsibilities, these responsibilities will be tightly coupled if they're in a single class. So if an interface or algorithm changes for one responsibility it will likely also affect the other responsibility, an undesired effect.
In the Open/Closed Principle a class should be able to extend its behavior without the need to modify the class itself. The only need to modify the class should be because it has a bug/error in it, not because you would like to change or add functionality.

By embracing the Open-Closed Principle, we create software that is more flexible, maintainable, and extensible. We can easily add new features without modifying existing code, promoting code reuse and reducing the risk of introducing bugs. So, let's strive to keep our software open for extension but closed for modification!

🚀 Stay tuned for more articles where we'll explore the other SOLID principles and delve into the exciting world of software engineering.

Thanks for reading. Feel free to comment your thoughts😊. Hope this post was helpful. You can hit me up on Linked In and Github.

Happy coding!

SOLID Design Principles: Learn the Single-Responsibility Principle

Alireza Shabani — Sun, 19 Nov 2023 11:06:07 +0000

👋 Hey there, fellow software enthusiasts!
I'm Revisto, a passionate software engineer, and I want to dive into the exciting world of SOLID principles.

So, what does SOLID stand for? Let's break it down:

S: Single Responsibility Principle
O: Open-Closed Principle
L: Liskov Substitution Principle
I: Interface Segregation Principle
D: Dependency Inversion Principle

In this article, we'll take a closer look at each of these principles, starting with the first one: the Single Responsibility Principle.

The Single Responsibility Principle (SRP) states that every entity in your software should have one and only one responsibility. In simpler terms, it means that a class or function should have a single job to do.

Robert C. Martin states:

A class should have only one reason to change.

Think about it this way: if you have a class that's responsible for multiple tasks or purposes, you'll find yourself needing to modify the entire class whenever any of those tasks change. This can quickly become a nightmare, as it increases the risk of breaking other parts of the class or function unintentionally.

To adhere to the Single Responsibility Principle, it's important to identify the distinct responsibilities within your software and separate them into different classes or functions. By doing so, you ensure that each entity has a clear purpose and is focused on a specific task.

👨‍💻 Example:

Now, let's take a look at some Python examples to illustrate the Single Responsibility Principle in action:

class Customer:
    def __init__(self, name, email):
        self.name = name
        self.email = email

    def send_email(self, message):
        # sending an email to the customer
        pass

    def place_order(self, order):
        # placing an order
        pass

    def generate_invoice(self, invoice):
        # generating an invoice
        pass

    def add_feedback(self, feedback):
        # add feedback
        pass

Here is a Customer class, it's responsible for sending emails to the customer, placing an order, generating invoices, and adding feedback.
Are all these functions related to the Customer class?
❌ The short answer is NO.
The customer class must be responsible for tasks and jobs only related to the customer. send_email is another task related to the Notification system. place_order should be handled by another class related to orders etc.

class Customer:
    def __init__(self, name, email):
        self.name = name
        self.email = email

class EmailService:
    def send_email(self, customer, message):
        # Sending an email to the customer
        pass

class OrderService:
    def place_order(self, customer, order):
        # Placing an order
        pass

class InvoiceService:
    def generate_invoice(self, customer, invoice):
        # Generating an invoice
        pass

class FeedbackService:
    def add_feedback(self, customer, feedback):
        # add customer feedback
        pass

More examples at
my GitHub

What happens if we adhere to the single responsibility principle?

By adhering to the Single Responsibility Principle, we can achieve code that is easier to understand, maintain, and test. Changes in one responsibility won't affect other unrelated parts of the codebase, reducing the risk of introducing bugs and improving overall code quality.

In the next articles, we'll explore the other SOLID principles, so stay tuned for more exciting insights into building better software.

Thanks for reading. Feel free to comment your thoughts😊. Hope this post was helpful. You can hit me up on Linked In and Github.

Happy coding!

Generate All Possible Images!

Alireza Shabani — Sun, 12 Jul 2020 00:19:02 +0000

Let's discuss a HUGE project but so useful one!
The main idea is to generate all possible pictures with a specific resolution such as 1080×1920.

Why:

Your first question might be, why the hell should this happen?

Cause it is literally EVERYTHING!!! Everything has happened, Everything that will happen, it can be a huge resource of inspiration, it can be leaked photos, it can be any media that will be released tomorrow, it can be exactly the future. This is "Why".

If we want to generate all 1080p pictures, it will be around

< 1080*1920*255*255*255 = 3.47892351×10¹³ >

, it is noticeable we are facing two different issues:

Time
Size

Therefore i though as the first step , i should use a lower resolution to generate , so i did some research:

○ 352 x 240 (240p)
○ 480 x 360 (360p)
○ 858 x 480 (480p)
○ 1280 x 720 (720p)
○ 1920 x 1080 (1080p)
○ 3860 x 2160 (2160p)

The best choice is 240p. it will be something like:

Alright, Let's check a number of possibilities:

240×352×256×256×256 = 1.417339208×10¹²

it is still a lot but with a huge difference in size.
so I had another idea, limiting the range of red/green/blue:

2 Different Ways

Option 1

instead of having (256³)=16777216 options for each pixel , have ((256/8)³)=32768 => we saved 16777216/32768=512 , in other words (240×352×32*32*32)=2768240640 possibilities

How About analysing size and time:

Size:

Each .Jpg format 240p : 51KB (maximum)
Each .Png format 240p : 254KB (maximum)
It is clear we have to use .jpg format.
All possible pictures size will be :

(240×352×32*32*32)*51KB = 141180272640KB or 137871360MB or 134640GB or 131TB

Time:

Each pixel (in a loop not random) takes 0.000000166

Each 240p picture generate takes

(0.000000166*(352*240))+0.08 = 0.09402368

Then for all Possible pictures, it takes

0.01*2768240640= 27682406.4 sec or 461373.4 min or 7689.5 hour or 320.3 days

Option 2

instead of having (256³)=16777216 options for each pixel , have ((256/32)³)=512 => we saved 16777216/512=32768 , in other words (240×352×8*8*8)=43253760 possibilities

How About analysing size and time:

Size:

Each .Jpg format 240p : 51KB (maximum)
Each .Png format 240p : 254KB (maximum)
It is clear we have to use .jpg format.
All possible pictures size will be :

(240×352×8*8*8)*51KB = 2205941760KB or 2154240MB or 2103.7GB or 2.05TB

Time:

Each pixel (in a loop not random) takes 0.000000166

Each 240p picture generate takes

(0.000000166*(352*240))+0.08 = 0.09402368

Then for all Possible pictures, it takes

0.01*43253760= 432537.6 sec or 7208.9 min or 120.1 hour or 5 days

Thanks for your attention, hope you like the idea and I really love to see your ideas to optimize!

Revisto

Customize Your Ubuntu a bit !

Alireza Shabani — Thu, 09 Jul 2020 20:34:14 +0000

I have installed Ubuntu and I had been trying a lot and testing everything to make my system as beautiful as possible.
so let's Customize (▀̿Ĺ̯▀̿ ̿)

Tweaks :

The first step is to make sure that we have the universe repository enabled on our Ubuntu system:

sudo add-apt-repository universe

Now install Tweak Tool on your Ubuntu system:

sudo apt install gnome-tweak-tool

SHELL Config

shell is locked by default in Ubuntu, Here is how to unlock it.

sudo apt install gnome-shell-extensions

Restart your system
then,

Open GNOME Extensions app

Turn On 'User Themes'

After These :

Then you need to log out and back into your session OR manually restart GNOME Shell (Alt + F2, type r, hit enter)

Turn On 'User Themes'

Select ‘Appearance’ in the sidebar
Locate the Shell section
Select THE SHELL THEME that you want from the menu

My Recommendation can make your system, A GodDamn Awesome Ubuntu:

▷ Applications: Orchis
▷ Cursor: Yaru
▷ Icons: Numix-Circle
▷ Shell: Orchis-Dark

How To Install Them?

Orchis and Orchis-Dark:

git clone https://github.com/vinceliuice/Orchis-theme
cd Orchis-theme
./install.sh

Numix-Circle :

sudo add-apt-repository ppa:numix/ppa
sudo apt update
sudo apt install numix-icon-theme-circle

WallPaper (^̮^):

I highly recommend you to find your Wallpaper from Unsplash
Why:

Perfect Pictures
High-Quality Pictures
Over 1.5 million photos

Thanks for your attention, hope you make the most beautiful Ubuntu and eNJOY!

Revisto