However, after running the playbook and restarting, the terminal did not look quite right:
You see the OS logo before the “>” is not displayed, and other icon fonts (I’m using exa/eza instead of “ls”) are missing, too (e.g., the one for YAML and Markdown files). In Arch, I knew how to solve icon problems for exa. Here in Ubuntu, I never experimented in that respect.
However, the p10k GitHub repository provides many hints in that respect. Unfortunately, Ubuntu does not provide packages for Nerd fonts. However, the p10k GitHub repository provides some Meslo fonts that can be directly downloaded.
The commands to solve the problem (provided you already have “fontconfig” and “wget” installed, otherwise, do install them) are:
Now, reboot (this seems to be required), and the next time you open the terminal, everything looks fine (note the OS icon and the icons for YAML and Markdown files):
Of course, you could also download another Nerd font from the corresponding GitHub repository, but this procedure seems to work like a charm, and you use the p10k recommended font (Meslo).
By the way, the Gnome Text Editor automatically uses the new icon fonts. Other programs like Kate (which I use in Gnome as well) have to be configured to use the Meslo font.
I am writing this report about my (nice) experience upgrading the SSD (1 TB) to my Dell OptiPlex 5040 MiniTower. That’s an old computer (I bought it in 2016), but it’s still working great. However, its default SSD of 256 GB was becoming too small for Windows and my Linux distributions. This computer also came with a secondary mechanical hard disk (1 TB).
DISCLAIMER: This is NOT meant to be a tutorial; it’s just a report. You will do that at your own risk if you perform these operations! Ensure you did not void the warranty by opening your laptop.
I wrote this blog post as a reminder for myself in case I have to open this desktop again in the future!
To be honest, my plan was to add the new SSD as an additional SSD, but, as described later, I found out that the mechanical hard disk was a 2.5 one, so I replaced the old SSD with the new one (after cloning it). I’ve used a “FIDECO YPZ220C” to perform the offline cloning, which worked great!
This is the BIOS status BEFORE the upgrade:
I seem to remember that “RAID” is required to have Linux installed on such a machine.
This is the new SSD (a Samsung 870 EVO, 1 TB, SATA 2.5”):
The cool thing about this desktop PC, similar to other Dell computers I had in the past, is that you don’t need a screwdriver: you disassemble it just with your hands. However, I suggest you have a look at a disassembling video like the one I’ve used: https://www.youtube.com/watch?v=gXePa1N_8iI. I know the video is about a Dell Optiplex 7040 MT, while mine is a Dell Optiplex 5040 MT, but their shapes and internals look the same. On the contrary, the Dell Optiplex 5040 SmallFactor videos are not useful because there’s a huge difference between my MiniTower and a SmallFactor 5040.
These are a few photos of the disassembling, showing the handles to use to open the computer, disconnect a few parts, and access the part holding the 2.5 drives.
This is the part holding the two 2.5 drives (as I said, at this point, I realized that also the mechanical hard disk is occupying one such place):
The SSD (I will replace) is the first one on top.
It’s easy to remove that: just use the handles to pull it off:
There are no screws to remove: you just enlarge the container to remove the SSD and insert the new one.
As I said above, I inserted the new one after performing the offline cloning.
Once I closed the desktop, the BIOS confirmed that the new SSD was recognized! 🙂
Now, some bad news (which is easy to fix, though): if you use a partition manager, e.g., in Linux, the SSD is seen as 1 TB, but the partitions are based on the original source SSD, so you end up with lots of free space that you cannot use!
For example, here’s the output of fdisk, which understands there’s something wrong with the partition table:
1
2
3
4
5
6
7
8
9
10
11
❯ sudo fdisk /dev/sda
Welcome to fdisk (util-linux 2.39.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
GPT PMBR size mismatch (500118191 != 1953525167) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.
It also suggests that it’s not a good idea to try to fix it when one of the partitions is mounted.
Using a live ISO, e.g., the one from EndeavourOS, is just a matter of fixing the partition table as follows.
1
2
3
4
5
6
7
8
9
10
$ parted -l
Warning: Not all of the space available to /dev/sda appears to be used, you can
fix the GPT to use all of the space (an extra 10485760 blocks) or continue with
the current setting?
Fix/Ignore?
Answer: fix
GPT PMBR Size Mismatch Error Fix
That’s it. Problem fixed you can reboot VM.
Now, you have access to the whole space in the disk.
Up to now, I have shown how to get started with Hyprland with the initial configurations.
Now, I’ll show how to install the mainstream status bar in Hyprland: Waybar. Again, I’m going to do that for Arch Linux. As in the previous posts, I will NOT focus on the look and feel configuration.
Before continuing, the Waybar module for keyboard status (Caps lock and Num lock) requires the user to be part of the “input” group. Ensure your user is part of that group by running “groups”. If not, then add it with
1
sudo usermod-aG input$USER
Then, you must log out and log in.
First of all, the official package waybar already supports Hyprland (in the past, you had to install an AUR package). So, let’s install the main packages (as usual, you might want to make sure your packages are up-to-date before going on):
1
sudo pacman-Swaybar
Let’s open a terminal and start Waybar
1
waybar&
The result is not that good-looking
Waybar heavily relies on Nerd fonts for icons, and, currently, we don’t have any installed (unless you have already installed a few yourself).
The terminal will also be filled with a few warnings about a few missing things (related to Sway) and errors about failures to connect to MPD.
Let’s quit Waybar (close the terminal from where you launched it), and let’s fix the font problem by installing a few font packages:
Let’s start Waybar again, and this time it looks better:
Try to click on the modules and see what happens. For some of them, the information shown will change (e.g., the time will turn into the date).
Let’s quit Waybar again, and let’s start configuring it. We must create the configuration files for Waybar (by default, they are searched for in “~/.config/waybar”). We can do that by using the default ones:
1
2
mkdir-p~/.config/waybar
cp/etc/xdg/waybar/*~/.config/waybar/
The above command will copy “config” (with the configuration of Waybar modules, i.e., the “boxes” shown in the bar; The configuration uses the JSON file format) and style.css (for the style).
Let’s edit “config”. At the time of writing, this is the initial part of the configuration file:
1
2
3
4
5
6
7
8
9
10
11
12
{
// "layer": "top", // Waybar at top layer
// "position": "bottom", // Waybar position (top|bottom|left|right)
"height":30,// Waybar height (to be removed for auto height)
The initial parts specify the position and other main configurations. This part must be enabled:
1
"layer":"top",
Otherwise, Waybar popups render behind the windows
Let’s edit the modules that must be shown on the bar’s left, center, and right. Of course, this is subjective; here, I show a few examples. The modules starting with “sway” are for the Sway Window Manager, while we’re using Hyprland, and we must use the corresponding ones:
Each module, together with its configuration, is documented in the Waybar Wiki.
Let’s focus on the left and center modules. I’ve opened three workspaces, and here’s the result (note the workspace indicator on the left, and on the center, we see the currently focused window’s title, in this case, Firefox):
By editing the “style.css” file, we can change the workspace indicator so that we better highlight the current workspace:
1
2
3
4
#workspaces button.active {
background-color:green;
box-shadow:inset0-3px#ffffff;
}
Restart Waybar, and now the current workspace is well distinguished:
The “tray” module is useful to show applications running in the background, like “skype”, “dropbox,” or the “network-manager-applet”.
Let’s now define a custom module, for example, one for showing a menu for locking the screen, logging out, rebooting, etc. To do that, first, we need to install the AUR package “wlogout”:
1
yay-Swlogout
Let’s say we want to add it as the last module on the right. We edit the Waybar config file like this:
1
"modules-right":...asbefore...,"custom/power"],
Then, in the same file, before closing the last JSON element, we define such a module (remember to add a comma after the previously existing last module):
1
2
3
4
5
6
7
8
...
},
"custom/power":{
"format":" ⏻ ",
"tooltip":false,
"on-click":"wlogout --protocol layer-shell"
}
}
Note that I’ve used a character using the installed Nerd font. Of course, you can choose anything you like. The “wlogout” menu will appear when you click on that module. Let’s restart Waybar and verify that:
By editing the “style.css”, you can customize the style of this custom module, e.g.,
1
2
3
#custom-power {
background-color:#ffa000;
}
When we’re happy with the configuration, we modify the Hyprland configuration file to start Waybar automatically when we enter Hyprland:
1
exec-once=waybar
Restart Hyprland and Waybar will now appear automatically.
Finally, you can have several Waybar bars, i.e., instances, in different parts of the screen, each one with a different configuration.
For example, let’s create another Waybar configuration for showing a Taskbar to show all the running applications from all workspaces. This can be useful to quickly look at all the running applications and quickly switch to any of them, especially in the presence of many workspaces.
I create another configuration file in the “~/.config/waybar” directory, e.g., “config-taskbar”, with these contents (you could also configure several Waybar instances in the same configuration file, but I prefer to have one configuration file for each instance):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"layer":"top",// Waybar at top layer
"position":"bottom",// Waybar position (top|bottom|left|right)
"height":30,// Waybar height (to be removed for auto height)
// "width": 1280, // Waybar width
"spacing":4,// Gaps between modules (4px)
// Choose the order of the modules
"modules-center":["wlr/taskbar"],
// Modules configuration
"wlr/taskbar":{
"format":"{icon}",
"icon-size":16,
//"icon-theme": "Numix-Circle",
"tooltip-format":"{title}",
"on-click":"activate",
"on-click-middle":"close"
}
}
We can call it from the command line as follows:
1
waybar--config~/.config/waybar/config-taskbar
Here’s the second instance of Waybar on the bottom, showing all the running applications (from all the workspaces):
Unfortunately, in my experience, not all icons for all running applications are correctly shown: for example, for “nemo”, you get an empty icon in the taskbar. You can click it, but visually, you don’t see that… maybe it has something to do with the icon set. I still have to investigate.
You can run both instances when Hyprland starts by putting these two lines in the “hyprland.conf” file:
In this blog post, I will describe a few scenarios where you want to update versions in a multi-module Maven project consistently. In these examples, you have both a parent POM, which is meant to contain common properties and configurations to be inherited throughout the other projects, and aggregator POMs, which are meant to be used only to build the multi-module project. Thus, the parent itself is NOT meant to be used to build the multi-module project.
I’m not saying that such a POM configuration and structure is ideal. I mean that it can be seen as a good practice to separate the concept of parent and aggregator POMs (though, typically, they are implemented in the same POM). However, in complex multi-module projects, you might want to separate them. In particular, as in this example, we can have different separate aggregator POMs because we want to be able to build different sets of children’s projects. The aggregators inherit from the parent to make things a bit more complex and interesting. Again, this is not strictly required, but it allows the aggregators to inherit the shared configurations and properties from the parent. However, this adds a few more (interesting?) problems, which we’ll examine in this article.
Description:
Sets the current project’s version and based on that change propagates that change onto any child modules as necessary.
This is the aggregator1 POM (note that it inherits from the parent and also mentions the parent as a child because we want to build the parent during the reactor, e.g., to deploy it):
[ERROR]Failed toexecute goal org.codehaus.mojo:versions-maven-plugin:2.14.2:set(default-cli)on project example.aggregator1:Project version isinherited from parent.->[Help1]
[ERROR]Non-resolvable parentPOM forcom.examples:example.aggregator1:0.0.1-SNAPSHOT:Could notfind artifact com.examples:example.parent1:pom:0.0.1-SNAPSHOT and'parent.relativePath'points at wrong local POM@line4,column10->[Help2]
[ERROR]
Before going on, let’s revert the change of version in parent1.
Let’s add references to aggregators in parent1
XHTML
1
2
3
4
<modules>
<module>../example.aggregator1</module>
<module>../example.aggregator2</module>
</modules>
Let’s run the Maven command on parent1:
1
[ERROR]Childmodule example.parent1/pom.xml of example.aggregator1/pom.xml forms aggregation cycle example.parent1/pom.xml->example.aggregator1/pom.xml->example.parent1/pom.xml@
That makes sense: the aggregator has the parent as a child, and the parent has the aggregator as a child.
But what if we help Maven a little to detect all the children without a cycle?
It looks like it is enough to “hide” the references to children inside a profile that is NOT activated:
XHTML
1
2
3
4
5
6
7
8
9
10
11
<profiles>
<profile>
<!-- DON'T activate it, it's only to let Maven
detect the the children -->
<id>update-versions-only</id>
<modules>
<module>../example.aggregator1</module>
<module>../example.aggregator2</module>
</modules>
</profile>
</profiles>
And the update works. All the versions are consistently updated in all the Maven modules:
The important thing is that aggregator2 does not have parent1 as a module (just parent2), or the Maven command will not terminate.
We can also consistently update the version of a single artifact; if the artifact is a parent POM, the references to that parent will also be updated in children. For example, let’s update only the version of parent2 by running this command from the parent1 project and verify that the versions are updated consistently:
Unfortunately, this is not the correct result: the version of parent2 has not been updated. Only the references to parent2 in the children have been updated to a new version that will not be found.
For this strategy to work, parent2 must have its version, not the one inherited from parent1.
Let’s verify that: let’s manually change the version of parent2 to the one we have just set in its children:
XHTML
1
2
3
4
5
6
7
8
9
10
<parent>
<groupId>com.examples</groupId>
<artifactId>example.parent1</artifactId>
<version>0.0.2-SNAPSHOT</version>
<relativePath>../example.parent1</relativePath>
</parent>
<artifactId>example.parent2</artifactId>
<packaging>pom</packaging>
<version>0.0.3-SNAPSHOT</version>
And let’s try to update to a new version the parent2:
Let’s try and be more specific by specifying the old version (after all, we’re running this command from parent1 asking to change the version of a specific child):
This time it worked! It updated the version in parent2 and all the children of parent2.
Let’s reset all the versions to the initial state.
Let’s remove the “hack” of child modules from parent1 and create a brand new aggregator that does not inherit from any parent (in fact, it configures the versions plugin itself) but serves purely as an aggregator:
But what if we apply the same trick of the modules inside a profile in this new aggregator project, which is meant to be used only to update versions consistently?
This time, the version update works even when the same module is present in both our aggregator1 and aggregator2! Moreover, versions are updated only once in the module mentioned in both our aggregators:
Maybe, this time, this is not to be considered a hack because we use this aggregator only as a means to keep track of version updates consistently in all the children of our parent POMs.
As I said, these might be seen as complex configurations; however, I think it’s good to experiment with “toy” examples before applying version changes to real-life Maven projects, which might share such complexity.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.