DEV Community: Juan Miguel Medina Prieto

Writing a custom overlay with React

Juan Miguel Medina Prieto — Tue, 23 Feb 2021 11:38:50 +0000

Whenever I have ideas for personal projects and I don't trash them completely because either they're impossible for me to carry out reasonably well, or they have already been done by everyone and their mother, they tend to be oriented towards content creation or videogame competitions, usually as a result of me finding out a chore that may be automated is being performed manually.

Obviously, I don't blame anyone for not commissioning a programmer to code a tool or a bot to help them with those, mostly because it's normally on the low end where I find these sorts of hiccups, and considering the little money (if any) that will move around those environments, it's unlikely investing into a fancier workflow will be a wise decision to their eyes. However, even if I know my projects will probably go unnoticed by those people, it's still a good chance for me to try out a somewhat original idea and generate some code that doesn't consist of doing the same thing you've already seen a million times on the web for anyone to take a look at.

The idea

That said, I'd like to tell you how I came up with this overlay idea. I was watching one of the streamers I tend to watch on Twitch on a somewhat regular basis, except that day, they were broadcasting a little tournament under a charity event. A link was provided to pledge some money for the cause, and between rounds and matches, the streamer would get to the campaign's website and copy new donations to a textbox in one of their scenes manually.

That brought up a question to my mind: "isn't there a bot for that?". As I imagined, no one was aware of such a thing in the stream. The service used as the basis for the campaign was Tiltify, and the first thing I tried upon figuring out the name of the website was searching tiltify api, and sure enough, there's an HTTP API for it.

Having those docs handy, it's clear I can create a relatively simple overlay using the React library and the default template it provides with the Node script create-react-app as a starting point. The purpose of that is to try it out some and practice working with RxJS. I already have some experience with it as a result of having been working with Angular's HTTP client in the development of an application made with Angular.

Unlike what I first thought, I decided to end up using Redux as well to carry the configuration to the components that need it and not have to either pass the parameters manually or transform them inside the component. Its Angular equivalent is NgRx, although that one works quite a bit differently from Redux, which only makes sense because NgRx is made to suit the way Angular works best. Redux by itself (and a helper package) seems to be better suited to React.

The layout

Being a simple overlay that consumes an API, the application has only two views: the Overlay itself, which will be loaded by the App if the necessary configuration in the query parameters is present, and a LinkGenerator that should make it easier for streamers to paste the required information and do further configuration if they want, then get a link copied to the clipboard that will get the display view loaded into their scene.

The Overlay component's job is to get the data from Tiltify's API and render each item of the list as a Donation instance, showing its name and amount. They may be displayed in the order the API yields them (sorted from latest to oldest donation) or sorted descendingly by price, showing the greatest amounts donated on top.

The amount is further delegated into the AmountDisplay, which makes sure to layout the donated amount according to the configured position for it and desired currency. For example, a price in euros has the euro sign placed to the right (eg. 100€), while a price in dollars is written the opposite way (eg $100). Only adjusting the specific parameters is needed so that the display isn't dependant on CSS styles. This should allow the same styles to be used with different currencies.

The limitations

As you might imagine, most of the limitations came from the Tiltify API itself, simply because it is quite bare at the moment and the documentation is also lacking. The most significant issue for my purposes was the fact that there's no WebSocket option. In short, WebSocket keeps a communication channel open for longer than a regular HTTP request, thus allowing the sender and receiver to keep sending messages to each other. That way, for example, the application would get updates from the API without having to send another request. Since that wasn't an option, the next better possibility was setting up an observable which calls the code responsible for fetching all the donations every minute.

Also related to the API itself, as of the moment of writing this article, no options to sort the donations seem to be provided, and since that has to be done manually, I think it's best to fetch them all regardless of whether they will be displayed as they are fetched or sorted by amount descendingly. Besides, the tokens I generated to test the overlay with real data were constantly banned in a matter of hours for some reason; I do suspect it's because I accessed multiple campaigns from other people with them. After all, when I try just one campaign with one token, it keeps working all the time.

As I didn't want to create a sample campaign without a proper way to add test donations that didn't involve spending real money, and because there's no easy way of finding a campaign that is getting a lot of new donations regularly, I decided to add a test mode that should allow anyone else making custom styles to test how everything should look without continuously fetching data from Tiltify. It can be triggered in dev mode if you add &test=1, or basically a test query parameter with any value that is truthy to any URL the LinkGenerator makes.

My desire to add unit tests to all the code I wrote caused some unexpected changes as well. Particularly in the overlay, which is actually exposed by itself in a module and connected to the store in another. That's because I couldn't fake the timers needed to test the observable created as a result of the mapping from the state to the component. Besides, even if I pulled it off, all the mocking necessary to make the test suite work correctly would have made it excessively complicated. Thus, I tested the overlay without any connection, separated the code responsible for bringing the current list of donations to its own service, thus testing it by itself, too, and left the connection to the store untested due to the timers' problem I described before.

The result

The finished overlay application is available to try out here. The source code and documentation about its usage and customization can be found in the repo below.

jmmedina00 / tiltify-donors-overlay

An overlay that shows the latest (or highest) donations for a Tiltify's campaign

Tiltify Overlay

Overlay made with React that shows a Tiltify campaign's donations, sorted by newest to oldest or by amount given descendingly. An article about the making of this application is provided here.

Usage instructions (as-is)

Get your campaign's id from the campaign's dashboard. This article describes exactly where it is.
Go to the account settings, then go to Your applications, create an application, enter its settings and get its access token from the section at the bottom.
Enter here.
Fill in the form with the campaign and the token, and select some options as you wish. When it's done, click Generate link.
Go to OBS and add a browser source, paste the link that was copied to your clipboard and set up the dimensions as you prefer. Make sure to remove the default custom CSS and not mark Shutdown source when not visible or Refresh browser when scene becomes…

View on GitHub

Feel free to ask me any questions about anything in the code or regarding my design decisions and I'll try to give the best reply I can provide.

How OAuth works in a nutshell

Juan Miguel Medina Prieto — Mon, 18 Jan 2021 14:59:24 +0000

If you have been using social media or similar apps for any amount of time, you probably have noticed buttons in a lot of those like these by now:

Maybe you have used any sort of website that does analytics or posts things for you on those social media, either automatically or in some sort of special condition. You might also have seen that strange video with the exact amount of views in both the title and the view counter every single time you watch it. And all those things have something in common: they all use OAuth.

What's OAuth?

OAuth is usually referred to as an open standard for access delegation. That short definition could be described as a protocol, if you will, that allows a piece of software (such as an application or a console script) to access and/or modify a user's information or resources, thus acting on their behalf if needed, via an external API, usually from a social network, without requiring the user to input their password anywhere other than its official app or website. Besides, that website will usually make sure the user agrees with letting that accessing application use whatever it needs.

As described above, it's frequently used as an authentication method in websites that are external to those social media, so that the user doesn't have to fill in yet another form when applying for a job or getting started in a platform, as it simply asks the software that provides OAuth access to some user data to automate that process. Some of them, such as Medium, will go as far as to only provide that option for a user to either login or create an account, omitting the traditional login form completely.

However, that's only the tip of the iceberg, since OAuth is simply providing access to an API in the name of a user who explicitly allowed the app that consumes it to do so, and as long as it has the permission, it may not only access data but modify it at will. That may be used by an app to import files from your Drive, schedule posts externally, automatically create them from other sources, or even provide automatic services via a Facebook page or a Twitter account, much like bots in Telegram or Discord do, among other things.

How it works

If you're familiar with HTTP APIs, you'll be aware of the fact that as soon as you have the authorization, using any endpoints needed to do what you want is relatively easy: just prepare an HTTP request with the correct method and endpoint, making sure to place the access token where necessary (usually in the Authorization header), then execute it and analyze the response you get from it.

But, unlike traditional services, where you simply request an access token by providing a username or email along with a password, how do you get authorization to use an API via OAuth? Well, being a standard, any OAuth provider will make your app go through a specific flow to get the token, which can be resumed in:

Your app generates a unique link (at least, it should be) to the OAuth provider's login page
The user goes through it and they login in if they haven't already, then they're usually presented with the list of permissions your app needs.
If the user grants access (or has done it in the past, thus skipping the prompt), the provider redirects the user back to the app.
The app gets a single-use access code via that redirection if everything went well, which will be used by the app to ask the API for a proper access token, allowing it to act on the behalf of the user on that service.

The process in detail

The steps above describe how the flow works at a high level, but doesn't cover everything that's required to properly consume an OAuth provider. What's described here obviously applies to most OAuth providers you're going to find and the changes from one provider to the next will usually be very minor, often boiling down to certain parameters' length or whether some parameters are actually required or are just recommended.

The setup on the provider's side

Before you're able to use any part of an OAuth-authenticated API, you'll need to get a client ID and a secret from the provider. This usually means registering your application in the developer console or settings for your account, and once you generate those strings, the credentials section will look something like this:

You may consider those as a username and password of sorts for applications that wish to act on the behalf of users. The client ID will always be used twice: to generate the URL and to request the access token once the temporary code is available reaches your application. The secret, as you may imagine, is used in that last step as a password or key to make sure that the token request is legitimate, and while the client ID may be leaked without much issue, the secret should be reset as soon as you're aware of its unauthorized use. That's the whole reason some developer consoles will force you to create a new one if you lose the previous one, although most of the time, you simply need to click a button if you want to see it again.

The way you do the registration process varies from one service to the next. Make sure to check out the documentation to learn how to properly do it.

Generating the link

Once you obtain the client ID and secret, you'll be able to generate a proper link to the authorization endpoint. It will carry the data it needs through the query parameters on the URL, and those parameters are:

client_id: the app's client ID obtained from the developer console
redirect_uri: the app's URL the provider should redirect the user back to once the authentication and prompt, if any, are done. It will receive the single-use code necessary for obtaining the access token in most cases.
response_type: if it's required, it should always be set to code, since that's the flow that's been discussed above and the token flow, while apparently faster, is much more insecure, to the point it's going to be removed in OAuth 2.1.
state: a string of your choice, normally used to mitigate CSRF attacks or, in other words, making it harder for attackers to tamper with your application via a user's interaction with another website. It'll be sent along with the temporary code back to the app, where it'll be verified. It's usually recommended, but some providers require a state to be present.
scope: the list of scopes or permissions your app needs from the user to function, separated however the provider specifies it (some require spaces between scopes, others require colons). Make sure to only specify the scopes you need (for example, don't ask to modify repos if you only need to read user private information), not only because a user should distrust an app that asks a lot of permissions for basic stuff, but if an attacker gets the access token, they'll be able to cause much more damage than with a token with very limited write permissions.

These are the generic parameters you are guaranteed to need when going through an OAuth flow. There are others specific to a particular provider, so check their documentation if you intend to use them.

Requesting the token

Once the user has authorized the application back at the OAuth provider, they will be redirected to it on the specified redirect_uri. It will include the access code and the previously specified state if any. Once the state is verified, the next step is to ask for the access token.

This is done by sending a POST request to the API's endpoint responsible for this. Both the client ID and the secret are required to validate the request, usually as the body parameters client_id and client_secret, respectively, except for Reddit, which fetches the ID and secret as a username and password in the Authorization: Basic style, the same as the Apache server's password protection works.

The code is always passed as a body parameter and in most cases, two more parameters are required, which are grant_type (which is always set to "authorization_code") and redirect_uri, which should probably be set to the same value the authorization link had in its query.

The response to this request will contain the access_token among other information, which might be useful or not depending on the use case. Some providers also allow getting a refresh_token, either by setting a specific parameter or automatically, which may be used later to get a new access token, usually by doing the same process, only providing the refresh token rather than a temporary code.

Some sample code

Even though there are quite a lot of libraries that make this whole process easier, particularly when generating the links, I think it's a good practice to try to understand how things work at a lower level, then switch to higher-level libraries, much in the same way as learning a programming language, then learning a framework is recommended.

I decided to code a quick sample app in PHP and JavaScript, without using any frameworks, that showcases the most basic case use for OAuth with several providers: getting basic user data to identify them quickly. While it's not proper signup or login, it will hopefully make sense to anyone who takes a look at it.

jmmedina00 / sample-oauth-app

A demo app that can be logged into via other services. The purpose is to show the flow of OAuth in different web services.

Sample OAuth App

Web application developed by Juan Miguel Medina Prieto as a proof of concept of using OAuth for authentication purposes. Accesses the APIs of Google, GitHub, GitLab and Dropbox in order to get information from the user that grants permission to their respective OAuth app. Reddit is also showcased, though it can't really be used in the app's flow as it doesn't provide the user's email.

Running the application

Make sure you have Docker and Docker Compose installed.
Go to each service's development console and create an application or project (make sure to choose web app for Reddit and OAuth App for GitHub). Follow the required steps in order to get an OAuth client ID and secret, and only toggle the required scopes for each service:
- Google: https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/userinfo.profile
- GitHub: user:read and user:email
- GitLab: read_user
- Dropbox: account_info.read
- Reddit: identity
Clone this repository, either with git clone or…

View on GitHub

Feel free to ask any questions or suggestions, I'll try my best to give a meaningful reply.

Mapping, reducing and filtering in PHP

Juan Miguel Medina Prieto — Fri, 03 Jan 2020 19:40:12 +0000

There's this thing called "functional programming" that you might have heard about, particularly if you have been learning about JavaScript and let's not mention if you have used languages like Scala or Haskell. It's obviously not as popular as object-oriented programming and using it will likely have its pros and cons, just as any programming paradigm or any programming language. Unfortunately, I can't say I'm experienced enough to compare both of those without ending up essentially copying and pasting someone else's post, and even then it will highly depend on your chosen technology or what you need to achieve.

What I can say, though, is that, apart from some useful tips you can choose to apply or not depending on what's needed, there are usually some pretty useful functions for handling arrays and avoiding unnecessary uses of foreach blocks, thus making the code a lot easier to read. Some of those functions are map, reduce and filter, which are available in PHP as "array_map", "array_reduce" and "array_filter".

array_map

Given an array, this function will transform its values by using them as a parameter in a given callback function, returning, as a result, a new array with those transformed values just in the same order, and even preserving their keys.

This function will take two parameters as a minimum:

A callback function (or its name, if it's declared somewhere else) that will take as many parameters as many arrays will be used.
An array, whose values will be run through as the first parameter of the callback function.
More arrays, preferably of the same size as the first one, if the callback function accepts more than one parameter.

Let's see an example. The following snippet takes these numbers and sums their squares to their triple value:

function squareAndTripleValue($number) {
    return pow($number, 2) + (3 * $number);
}

$numbers = [2, 4, 7, 9, 11, 22];
$tranformedNumbers = array_map("squareAndTripleValue", $numbers);

If we didn't use array_map, the code would come out like this:

function squareAndTripleValue($number) {
    return pow($number, 2) + (3 * $number);
}

$numbers = [2, 4, 7, 9, 11, 22];
$tranformedNumbers = [];

foreach ($numbers as $number) {
    $tranformedNumbers[] = squareAndTripleValue($number);
}

This one isn't terribly longer than the first one, but imagine you have to do operations like these over and over again. Moreover, running an array through a function by using foreach might be confusing if the array declaration was removed, as it's not really necessary, but it's considered a best practice because it prevents potential issues, especially if the variable is overwritten. Overall, using array_map when possible makes the code look a little bit cleaner and easier to understand.

Here's a repl.it for you to further try it out:

You can check the PHP documentation on array_map here.

array_reduce

This function takes the elements of an array and iterates them through a callback as one of the parameters, where it will be applied to the result of previous elements being applied to an initial value.

It will take two parameters as a minimum:

An array, whose values will be passed as a callback's parameter one at a time.
A non-void callback function with two parameters:
1. The carry for the initial value or the result from the previous iteration. It should be returned once the second parameter is applied to it.
2. The current iterated item inside the array
An initial value, which will be the "carry" value in the first iteration. It's sort of optional since the function will run without it, but you usually shouldn't omit it, as that initial value will be NULL in that case, likely causing problems.

In this example, we'll get the sum of the numbers on an array.

function doSum($carry, $item) {
    return $carry + $item;
}

$numbers = [2, 4, 7, 9, 11, 22];
$sum = array_reduce($numbers, "doSum", 0);

And here's the snippet without using array_reduce, but following its style.

function doSum($carry, $item) {
    return $carry + $item;
}

$numbers = [2, 4, 7, 9, 11, 22];
$sum = 0;

foreach ($numbers as $number) {
    $sum = doSum($sum, $number);
}

Again, the second one isn't terribly longer than the first one, but it's a little bit cleaner and easier to use, provided that you remember what array_reduce does. Regardless, this an example that would work even if the third parameter was omitted and, in fact, would also work in the foreach version if the $sum declaration was omitted. PHP would complain in that case, though. However, as I said earlier, it's not a great idea to do that on a regular basis: just as an example, doing the product of those numbers would require setting the initial value to 1.

You can experiment with array_reduce in this repl.it:

You can check the PHP documentation on array_reduce here.

array_filter

Given an array, this function will return an array with only the values that (or the values whose keys) return TRUE when running through the desired callback if any. Otherwise, a single value won't be part of the resulting array if its key or itself is FALSE when converted to a boolean.

It will take one parameter as a minimum, up to three:

The array to be filtered by the callback function if any.
A callback function that will take one parameter or two.
A special flag that will change this function's behavior. By default, the array's values will be tested against the callback, but if you set the ARRAY_FILTER_USE_KEY constant as the third parameter, it will test the keys, instead. Using the ARRAY_FILTER_USE_BOTH constant will cause the function to send the key as a second parameter along with the value.

Let's do three examples, each one for showing what each constant actually does. In the first one, we'll get just the even numbers (divisible by 2) from the original array:

function testNumber($number) {
    return $number % 2 == 0;
}

$numbers = [2, 3, 7, 8, 10, 21, 42, 45];
$evenNumbers = array_filter($numbers, "testNumber");

Here's the same snippet without using array_filter:

function testNumber($number) {
    return $number % 2 == 0;
}

$numbers = [2, 3, 7, 8, 10, 21, 42, 45];

foreach ($numbers as $number) {
    if (testNumber($number)) {
        $evenNumbers[] = $number;
    }
}

Just with this example, you can notice that, when using foreach, doing the same as array_filter would do requires the use of an if statement, increasing the number of indentations and making the code clearly harder to read than the array_filter version. Furthermore, keep in mind that the behavior of these two snippets is a bit different, as array_filter always keeps the original key, while foreach would require to declare its usage and assigning it directly inside the block.

In the next snippet, we'll get the numbers with an even key (or index, as PHP assigns incrementing numbers as keys by default to new values). Since the keys start by 0, we're actually obtaining the numbers in an odd position:

function testNumber($number) {
    return $number % 2 == 0;
}

$numbers = [2, 3, 7, 8, 10, 21, 42, 45];
$evenNumbers = array_filter($numbers, "testNumber", ARRAY_FILTER_USE_KEY);

And here's the same code without using array_filter:

function testNumber($number) {
    return $number % 2 == 0;
}

$numbers = [2, 3, 7, 8, 10, 21, 42, 45];

foreach ($numbers as $key => $number) {
    if (testNumber($key)) {
        $evenNumbers[$key] = $number;
    }
}

And finally, in this snippet, we're going to get only the numbers that are even and have an even key:

function testNumber($number, $key) {
    return $number % 2 == 0 && $key % 2 == 0;
}

$numbers = [2, 3, 7, 8, 10, 21, 42, 45];

foreach ($numbers as $key => $number) {
    if (testNumber($number, $key)) {
        $evenNumbers[$key] = $number;
    }
}

Here's a repl.it you can experiment with:

You can check the PHP documentation on array_filter here.

A quick little tip

Before ending, have a look at this snippet:

$template = "Let's suppose you got this %verb% template from a file, a query or whatever";
$verbs = ["nice", "beautiful", "boring", "stupid"];

$fullTexts = array_map(function ($verb) {
    return str_replace("%verb%", $verb, $template);
}, $verbs); /*Yes, you can directly define the function as an argument
instead of referencing its name somewhere else*/

If you have been working on PHP for any amount of time, you'll notice the mapping function wouldn't be able to see the $template, thus making the $fullTexts totally empty. That's because all the variables in a function are treated in the function's scope, and the global values outside cannot be seen. We could consider this issue as the biggest downside of using the functions described above instead of foreach.

To solve it, you just have to declare the variable with the global keyword before giving it any use:

$fullTexts = array_map(function ($verb) {
    global $template;
    return str_replace("%verb%", $verb, $template);
}, $verbs);

You can check more info about the variable scope here.

Conclusion

These three little functions can be quite useful when working on arrays, as they can help make your code a lot easier to read than if using a foreach block for several small tasks like those. However, it would best to overwrite the array you're working on with each step, as chaining those operations would come out like this:

$numbers = [1, 2, 3, 4, 5];

$squaresFromEvenNumbers = array_map(function ($number) {
    return pow($number, 2);
}, array_filter($numbers, function ($number) {
    return $number % 2 == 0;
}));

That's called callback hell, and it will make the code just as hard to read as if you were just using foreach for these tasks. Even though in JavaScript it's somehow difficult to solve, due to its asynchronous nature, this issue only crops up when functions like these are introduced and are easy to solve: just do each step separately, as I said earlier.

Finally, when should you use each of these functions? Well, as a rule of thumb:

Use array_map when you want an array with the same length as the input array and the resulting elements are the result of a transformation of the input elements.
Use array_filter when you want the same array as the input one, excluding elements that don't fulfill a given condition.
array_reduce should be used when you want to transform an array into a totally different structure or a single value that couldn't be achieved with any other function.
Use foreach only when you need to do something else and the operations on each element don't return a result.

If you want to learn more, don't forget to check out PHP's official documentation on array functions, including array_map, array_reduce, and array_filter.

Moving away from Ubuntu: peeking at FreeBSD (Part 3)

Juan Miguel Medina Prieto — Mon, 30 Dec 2019 16:24:13 +0000

So, in the previous two parts of this post (if they can be considered so instead of two posts), I was playing around with FreeBSD in a virtual machine in order to determine how different it is from using Ubuntu or some other Debian-based Linux distributions. For the moment, I've been using that as a server (more or less), accessing it via SSH and installing a FAMP, or Apache along with PHP and MySQL under FreeBSD. But I'm not done yet, as I also want to check how hard it will be to install a desktop environment and test it like that.

Installing GNOME

So, first of all, I should try using pkg in order to try to find some packages related. I'll try searching popular Linux desktops, such as GNOME, KDE, etc.

I don't know whether I should be surprised by having found actual results related to GNOME, but it's pretty good news, regardless, as this tells us FreeBSD may have really similar desktop experiences to what Linux users have. Now, I'm not sure which is the correct package to install GNOME 3. It seems like "gnome3-3.28_2" is the good one, but I still want to search what's available for KDE.

And it looks like Plasma is here, too! After looking around in the results, I see that "kde5-5.16.5.19.08.1" looks like the most likely package to install KDE Plasma as a whole. Regardless, I'm going to proceed with GNOME, and maybe I'll try Plasma next, just to see whether the default configuration can handle two desktops installed at the same time or additional steps are required.

And this, ladies and gentlemen, is the fattest part of any desktop Linux installation: the desktop itself. Oh well, I'll go ahead and check the VM's screen while the installation goes on, just to see whether something funny happens.

Around 10-15 minutes later, the scrolling stops and I get what follows. Well, this is just the end of it, as there's a bunch of messages from the other packages that have been installed along with GNOME. I'll just restart the machine and see if any magic happens, hoping that the installation has taken care of everything.

Unlucky me, I guess it doesn't start it right away by default, not even after I log in as any of the users. I guess I'll have to check GNOME's page on FreeBSD's website. Apparently, the final step that was required for GNOME to load after rebooting is right here, which is just another line in /etc/rc.conf:

After doing that, I reboot the machine yet again and... Nothing, I'm still getting just the text mode. I check the manual page again... And I see the "startx" command, which I'm apparently missing since there's no manual page for that, and the command isn't recognized, either. I prefer to check "X11" in pkg, as I think that's the environment related to that command.

Interesting, there are some packages for virtual machines. I guess I'll have to try some of those.

Well, it doesn't seem to be what I need, so I'll just cancel that and try that test program instead, just to see whether things change in there.

Nothing, it looks like whatever that I thought I'm missing is already installed, and I can't find something related to X11 in the manual, either, so I try listing the statuses for the services the manual page lists for starting GNOME without requiring a system restart, and this is what I get:

So "gdm" is not running and "dbus" needs to be added to the rc.conf file. I'm pretty sure that's the piece of the puzzle I'm missing, so I'll add that and try again. One reboot later... Nothing, still out of luck, so I'll try checking GNOME's service itself.

It looks like GDM is still not running. I try starting it manually, and the only response I get is "Starting gdm". However, while trying to log in to see whether something changes, I see there's "service -e", which will list all services that will start on boot, I try it and...

Sure enough, there's no GNOME to be seen anywhere. I guess I should look for "gnome" in /usr/local/etc/, just to see if there's something that I'm missing.

There is, indeed, something, but probably not what I need to start GNOME up. Just as a final attempt, I'll try to install X.Org, since I think that's the server lots of desktops use as their basis.

It seems that the package was missing, so I'll go ahead and install it. As long as I don't have to deal with the older desktop environments...

Well, that's done, even though that package doesn't seem too happy about having been installed. Oh well, I'll just reboot and see if, this time, the magic does happen.

And it does! Finally, I can use a more graphical environment to use this UNIX computer. Luckily, I can log in to my user just as if I were using a Linux machine.

The first thing I try is playing around with the volume control, and sure enough, I can hear some sound, so probably the web browser can load regular pages as well.

Well, I can enter YouTube and sort of watch videos, even though the pre-installed web browser (which isn't Firefox, by the way) isn't capable of handling it properly. I also notice that the environment itself, just upon opening a few windows, gets very laggy, most likely due to the little amount of VRAM that VirtualBox assigns to a FreeBSD's machine by default. So I increase it to the maximum to see whether that gets better or not and that works... even though the web browser still glitches a lot while trying to play the video, so I guess it's just not working properly.

Also worthy of mention is the fact that logging in with GNOME won't automatically create the folder system Linux desktops are known for, such as Documents, Images, Desktop, etc. And of course, there's no app store to be found, so this is far from ideal for the average person to use who isn't willing to learn how to use pkg to search and install any software. Oh, and did I mention there's no option to add icons or files to the desktop? That's likely due to the fact the "Desktop" folder is missing, but that's probably annoying as well.

Installing KDE

So now that GNOME is more or less usable, I'll try installing KDE directly from the desktop's terminal, just so that you can see how it looks by default.

Yeah, it's not pretty, but I do guess it could be worse than that. It's pretty much just the same GNOME terminal you'd find in your default Ubuntu installation, even though the color scheme is a lot uglier and simpler. In fact, csh behaves just as badly with that terminal as the one I'm using, ~~which is MATE's default terminal, by the way. It's good enough for me.~~

So this one obviously takes longer to install, around 20-25 minutes, but it's already done, so I'll try rebooting in order to see whether something is different or, even better, KDE is also listed when logging in.

Well, it looks like this one is going to be a lot simpler than installing GNOME, probably because I already did the hardest work before. So I try entering my password while having selected "Plasma" and...

This looks pretty similar to what I would have found after installing Kubuntu or any KDE-based distro. Oddly enough, it seems like Plasma has created the Desktop folder in order to place icons and whatnot inside. Also, there's also Discover, KDE's app store, but it doesn't seem to work at all. Again, not ideal for someone who isn't very experienced with computers.

Since I don't hear any sound when playing around with the volume control, I navigate through KDE's configuration and manage to find an audio test, which does seem to work, even though it sounds a bit choppy at times.

Once again, I test the pre-installed web browser by making it play a YouTube video and...

Well, it seems to work a lot better than GNOME's browser, but this one can't really play the video at full speed, probably because of the fact that either it doesn't have proper drivers to handle the VM's graphics card, or the VM itself can't really do a lot in terms of performance as KDE isn't likely that well optimized for FreeBSD.

Overall, by just taking a quick look at both KDE and GNOME, I'd say KDE would manage to give a better experience to the user without having to touch a lot of things, especially when it comes to the configuration panel since KDE itself looks a bit more polished and less bare than GNOME by default. Maybe I'm a bit biased, as I prefer KDE over GNOME, but both are usable while not ideal when compared to Linux desktop distributions or even desktops by themselves.

My thoughts on FreeBSD

Well, after spending almost three posts doing some basic things with FreeBSD, I think I can point out some thoughts about actually using it, both from the terminal and from a desktop. I'm aware of the fact I might be wrong since, just in case someone didn't notice, I'm a lot closer to having a first impression about it than having actual experience with it and being able to speak with authority on the subject.

On the surface, FreeBSD and Linux are very similar to each other when it comes to the user experience, which makes sense, as FreeBSD comes from a derived version of Unix and Linux is just a Unix clone. If you access a service such as a website or an (S)FTP server, it would be really difficult to notice something different while being hosted under any of them unless developer information was visible (such as a phpinfo() call in PHP under Apache) to the user or some hidden files could be noticed.
Even though this is likely due to something I haven't configured properly (or maybe my hard drive isn't all that capable of handling it), I've been noticing some delay between pressing Return after typing a command and seeing the shell react when working on Linux machines, particularly on Ubuntu Server. On FreeBSD, however, those delays are a lot less likely to happen, at least when it's a fresh installation. I don't think Ubuntu has worse performance than FreeBSD if a fair benchmark was made, but the fact that the Unix clone has a lot less enabled services by default, thus making it faster to run.
When it comes to the directory structure and naming conventions (like the one for the HDDs), and especially commands for performing more specific tasks, such as formatting partitions or handling them, things change quite a bit, so get ready for having to search how to do stuff upon seeing a command isn't found or produces a very different output from what you'd expect on Ubuntu or where the files you need are located (if you're looking for files installed by a package, I found that "pkg info -l <packageyouneed>" will do the trick).
The service enabling procedure is particularly irritating, as you usually have to add lines manually to a text file in order for a service to start on boot. Sometimes it goes even further than that, requiring you to add those lines so that the service can run at all. Still, unless FreeBSD is using SystemV or some clone/fork/relative, I might have found out why people are still using "service" on Ubuntu: so that everyone can quickly understand one service is being managed upon seeing a "service" command.
Even though it doesn't always look too polished on the output, "pkg" is probably just as pleasing to use as "apt", but I will say the lookup commands for packages might be quite confusing, as some are just for installed packages. Regardless, the messages some packages spit out to the console upon finishing the installation are quite useful when we're talking about a server or some package that isn't likely to work on the first try.
The documentation provided by the manual is just as useful as what you'd find in any Linux distribution, although I couldn't help looking FreeBSD's online manual, which I'd dare say is a bit better and more comprehensive. Anyway, I should point out that a good chunk of the manual pages, probably a lot more what you'd find on Ubuntu, for example, is aimed at developers, which is probably quite handy for them, but it may scare some users away. Plus, it's a bit irritating to find some C header info when searching how to format a partition.
Speaking of documentation, when you enter a terminal, you are greeted by a default message, then a random tip about moving around the system or performing some task. That's quite useful, to be honest, and has in fact helped me in some of the situations.
When talking about using FreeBSD in a desktop computer, I'd say it doesn't work quite as well as when using Linux distributions. GNOME is a good example of that, even though I can't really say for sure since I was just playing around with the two more demanding Linux desktops in a virtual machine. Regardless, I can say the experience wouldn't be quite ideal for the average computer user since there's no option to install software other than using "pkg" in the terminal and it got a bit glitchy upon opening a few windows.
And obviously, even though I can't really test it, the compatibility isn't probably all that great for regular computers. The fact that some packages have messages about compatibility issues tells me that using FreeBSD on real hardware, compared to even not that popular Linux distributions can be a bit worse, especially when using less generic hardware. It might be really similar to running Linux on a server, but I can't say for sure. Oh, and the binaries: I doubt Linux binaries will work all that well in FreeBSD, so you should try to compile from source if you can't find the software you need through pkg.

In conclusion, FreeBSD is a quite interesting operating system, even though I wouldn't recommend it in general except for a few rare scenarios. One would be on a desktop, where you could try some of the lighter environments such as MATE or Xfce, in order to check whether they run any better than in Ubuntu or Debian, provided that you're lucky enough to have support for your hardware. I could advise to give it try a lot more confidently on an older server since it is a bit lighter by default than most Linux distributions. Obviously, I wouldn't recommend it by any means to anyone that doesn't have a lot of experience moving around the terminal or even with computers, as things are harder to achieve in FreeBSD than in Linux.

Moving away from Ubuntu: peeking at FreeBSD (Part 2)

Juan Miguel Medina Prieto — Fri, 27 Dec 2019 15:11:32 +0000

Previously, I had installed FreeBSD in a VirtualBox VM and had started tinkering with it: I simply created another user and set it up so that I could log in as root from it via SSH. Besides, I attempted to set bash as root's shell, even though I failed. While doing so, I had started using pkg, FreeBSD's software management tool, and this time, I'm going to use it even further, as I'll be installing a LAMP stack (that is, Apache or a web server, PHP and MySQL) and then I'll be trying to set a desktop environment up.

The disk structure

Before that, though, I want to try something: attaching another virtual HDD to the VM, to check the way FreeBSD lays it out. Let's recall the following image:

This was the result the final partitioning screen showed during the installation, display only one disk with two partitions: the main one, and the swap partition. It's quite a bit different and more complex than what's usual in Linux (the disk itself would have been called "sda" and their partitions, "sda1" and "sda2", respectively). And out of curiosity, I want to explore this naming convention a bit further by experimenting a little bit.

As such, I add two more disks in the storage section while the VM is turned off, and the setup comes out like this.

Next, I turn it on and log in via SSH. Then I try to run the command "lsblk", but it's not found, so I check the manual page for "fdisk". It says it's obsolete and advises to use "gpart" instead.

That's probably the command I need. I try it and... It seems like it just lists the main disk, probably because the others are blank. And this is when I check the VM's configuration and notice the changes I had made before were missing. I'll have to do them again. Unfortunately, after adding the disks, the command's output was still the same.

Still, when checking the contents of /dev, two new devices appear just after the ones representing the main HDD and its partitions. Even if I can't get them to appear on any tools that come to my mind, I still want to try to initialize, so I'll log in as root and try "fdisk /dev/ada1", as it's the only console-based tool I really have experience with.

Seems like I'm out of luck here, too, as this behaves in a different way to Debian's "fdisk". So I check the manual, and I eventually try "gpart create -s mbr /dev/ada1", wanting to initialize the second disk's partition table.

It does seem to have liked that, even though I can't really see any difference when running "gpart list". Still, it does appear if I add the "-a" option, so I think I'm in the right direction. Now, I'll try creating two partitions.

It seems to work, but will it have processed the partition sizes as I wanted? I was trying to make the first take 10 gigabytes, and then the rest for the second one.

Yes, it does! Now I guess I can initialize the third disk without any problems. That one will have a single "linux-data" partition. Now I'm not sure of whether "gpart" just makes the layout or does the full formatting process. Once I'm done, I'll commit the changes for both disks, since this tool seems to work in a similar way to version-control and transaction-based systems... Or maybe I don't need to do so, as I didn't specify any flags at all, and those were just meant to do exactly what I was talking about before. Just to be sure, I reboot the machine, and sure enough, there they are. Whoops!

Anyway, before moving on, I want to check whether the partitions are formatted or not. ~~I just noticed the naming style is a bit different in the main disk compared to the other, probably because of the swap thing~~. So I'll try to mount... "ada1s1", for example.

It doesn't seem to work, so I'll try to format that partition, then try again. Unluckily, there's no "mkfs" command, so I'll have to look around. This online manual page shows the command "newfs", but it doesn't suit what I need here, since that partition is meant to have a FAT32 filesystem. This one, however, shows the "newfs_msdos" command, which is the precise one I need.

Still, I don't get any different results than before. I search online how to mount a FAT32 device, land here, and it turns out I wasn't specifying the device type correctly.

Now it makes a lot more sense to me. And... I have finally determined what "gpart" does: it just makes the partitions, it doesn't format then. Oh well, I'll move on.

Installing a web server

After messing with the disk partitioning and formatting tools, I think it's time to try to do one of the main attractions: the LAMP stack. Just as a reminder, the LAMP stack consists of:

Apache, a web server
PHP, a programming language which is mainly used alongside Apache
MySQL, a database management system

Obviously, these three components would normally be running on a Linux machine, but I'm going to try to make them run together under FreeBSD in order to get some experience with pkg and recall how these had to be configured.

I'll start by Apache. The first thing I should obviously try is searching for it in the repositories. It should be done with "pkg search apache".

It does seem to return a lot of results, but I quickly find the one that I need: "apache24-2.4.41". I won't be picky about the version number since I just want to see it running.

After waiting for a while, the installation ends and I get this message:

Once I do the "rc.conf" modification, ~~which is a weird way to add a service to start after booting, especially coming from Ubuntu,~~ I try the VM's IP address in my browser and... it doesn't work. Probably I need to start it manually. Luckily, the "service" command does drive me somewhere.

Now I suspect FreeBSD is running services by using System V or something similar... Oh well, at least listing the scripts shows "apache24", so I start it by typing "service apache24 start", it complains a bit and, once I try it in my web browser...

Yeah, that's what I was going to say... Nevermind, I should create a quick PHP script so that the module can be tested as soon as it's installed. But it seems like I have to find where the main folder is, since it's not /var/www/html. I think Apache is the best guy to ask. However, /etc doesn't contain any "apache" folders. After having a little fight with "find", since this command is a lot pickier than in Linux (or than I recalled), I manage to get Apache's folders.

Checking the server's folder, /usr/local/etc/apache24, I notice its file structure is very different from what I expected, so I'll probably have to look further in the files in order to find where that HTML file lives. I'll start by the main one, httpd.conf, and right there I find it.

That's the DocumentRoot, the directive you're looking for when you want to find to figure out where the server's files are located. Since there are no virtual hosts, apparently, there's no room for error, I'll check that one directory.

Bingo! Now I'll write a quick script to test PHP. It will be useful once we start messing with it.

Oddly enough, when I try it without having installed PHP, it shows me the PHP code instead of directly offering it as a download. No one wants either of those scenarios, not even me, so let's tackle that. First, I'll search in the repository:

The result of running "pkg search php" scrolled on my face for a few seconds, so I should try to reduce the results a little bit. "apache php" and vice-versa don't return any results at all, and it doesn't even understand it if I don't quote it. Oh well, I guess "grep" will come to my rescue once again.

I don't really like the results I'm seeing, but at least I know PHP 7 is available. Searching "php7" or even "php7." should be helpful, right? Well, just barely, and I still can't see the main package, which is what I probably need, so I'll just run "pkg install php"... which doesn't work. However, specifying a version (7.3) without dots seems to do the trick.

The installation worked. Now, will it directly link to Apache? Well, nope, it still displays the same result when I try running the script I had made before. It doesn't surprise me at all, even though now I have to figure out how to make it work. No hints from the manual, nor the configuration files, nor the packages info, so I'll have to search online. Not wanting to "cheat", as there are several tutorials on how to make a FAMP (which is the same I'm trying to achieve), I find FreeBSD's manual page on the server, and after finding "mod_php" while explaining the modules, I have an idea: searching that in the repositories.

And there it is, I think. I haven't figured out a way of looking at a package's info without installing it, so running "pkg install mod_php73-7.3.12" is going to be a shot in the dark. It doesn't need anything else before installing itself, and sure enough, look at this message:

After adding those lines to Apache's configuration file, right after the root directory's directives, I restart Apache's service with "service apache24 restart". It seems to complain about the same about not having a domain, and...

Tada! PHP scripts are now working under Apache. MySQL is the only thing that remains to prepare. I'm not sure about installing it, but linking it with PHP should be pretty easy. Anyway, I'll do another search in the repository:

Okay, we're good for the moment. I'll just pick "mysql57-server-5.7.27" and "php73-pdo_mysql-7.3.12". The last one isn't PHP's traditional MySQL API, but a newer one called PDO, aimed at trying to provide an almost universal interface when dealing with SQL databases. Regardless, this is a good time to test whether I can select several packages to install.

Looks like I can, so I'll perform the installation.

Interesting, an automatically generated password. Normally, when working on Ubuntu, MySQL had a root user without a password who could just access it locally. That will be interesting to implement in the MySQL script. Right now, I have to start the service manually, so upon listing the available services, I run "service mysql-server start". Then I have to change something up in the rc.conf, and then I run the command again. And the secret password file appears. I won't be showing it, but I can tell copying and pasting the password works even in the terminal.

Yeah, it makes sense. Let's see if I remember how the "ALTER USER" statement worked.

I got it right first try. I quickly exit and try to enter again to check it changed correctly, and sure enough, it worked perfectly. In order to make things a little bit easier for me, I create another user for remote access with all privileges. Before trying it out in a graphical program, I test it in a local terminal.

I guess that would have been way too easy. No problem, I think I have to touch some configuration in order for the MySQL to be exposed externally. I'll try checking the main configuration file.

It must be that directive. If I change the IP address to the one assigned by my DHCP, I should be able to connect, right? Granted, I'd have to restart the service in the first place.

That's a lot better, now I can open my GUI client and insert some data. I'll just make a quick table so that the script isn't all that difficult.

And here goes the script, ~~which doesn't use HTML5 nor AJAX since this is just a test~~:

And here's the result. It seems to work perfectly.

Well, this is getting long enough, so I'll split this further into another part, where I'll finally try to install a desktop and make some conclusions about how easy FreeBSD is to deal with.

Moving away from Ubuntu: peeking at FreeBSD (Part 1)

Juan Miguel Medina Prieto — Sun, 22 Dec 2019 18:50:05 +0000

I've been aware of the existence of OSes besides Windows since I was given my small green laptop by my school, as a result of some politicians in my region attempting to get a nice picture taken, and it showed: the computer was a low-end one, even for the day's standards (we're talking about 2010 or so), so there wasn't a lot that you could do on it comfortably. For example, after a few years, I wasn't able to properly browse any web sites, and let's not talk about the fact I couldn't run an IDE on it when I had to bring it to classes in order to code on it: it crashed spectacularly or simply refused to run at all.

Even though, I'm glad of having had it: it made me deal with some form of Ubuntu for the first time, as my parents wouldn't let me use their better, but still sorta low-end, Windows machine, ~~they didn't want me to download things on it and eventually make it unable to boot~~, so I had to spend time learning how things worked on there. Not that much of a problem for me, but it was a deal-breaker for most of my classmates.

Regardless, nowadays, I have some culture about how Linux came to be and their relatives and, as I don't really need Windows, ~~since the games I want to play are available on Linux or are playable in Wine or even a VM~~, and I'm pretty much aware of how painful it can be when it's cracked, I just prefer to use Ubuntu in my main computer. Besides, it's very likely I'll end up working with a Linux machine, and that way it won't be that big of a deal for me, especially when it comes to running commands.

However, to be honest, I have never used any distro other than Debian-based ones (with different desktops) for a reasonable amount of time, and I've always been curious about how different it is to work on other distributions. Sure, a lot of things will be very similar, but I still want to see how different it really is by myself.

So, I'm going to start by shooting at the dark with the first one: FreeBSD

What's FreeBSD?

FreeBSD isn't really a Linux distribution, but an OS derived from one of its relatives, BSD. This operating system was created by the University of California, Berkeley from Unix's source code and, soon before its original development ceased, became the basis of several open-source OSes under the BSD license, including FreeBSD, which allowed the code to be used in proprietary projects such as Apple's OSes and PS3 and PS4's OSes.

Obviously, by itself, it's much less popular and, according to some posts out there, harder to use than Linux, especially in desktop, even though it's somewhat better when it comes to running servers. There's no way I can reliably measure its performance in a server, but I should be able to tell if it's a lot more of a pain to use than Ubuntu Server.

My goals

In order to give FreeBSD a first try, I'm going to attempt to do the following tasks after installing it:

Figuring out the folder structure (if it's any different from FHS)
Installing an SSH server in order to use it from a terminal
Trying to install a web server (Apache is preferred), make it work with PHP and run a script to read some data from a local database.
Attempting to install a desktop environment

The setup

In order to keep it simple, I'm going to create a VM using VirtualBox with 2GB of RAM and a 30GB virtual HDD. I'm choosing the defaults for FreeBSD, so the storage layout comes out like this:

For the network, I simply change the default network adapter to be attached to a bridged adapter, which will make the VM fully visible for my local network:

Installation

I boot up the virtual machine after selecting the FreeBSD installation image for the virtual disc drive. I'm greeted by this screen upon waiting for a countdown to run out.

I select the Install option and arrive at the keymap screen. Since I don't have a standard US keyboard, I first try the "Test default keymap"

Nope, it's just a prompt to check you had the right keymap, which is not my case, so I cancel it and select my language's keymap. Apparently, it doesn't want to show some special characters (such as ñ or letters with accents), but the rest of the keys print the correct characters for my keyboard, so I'll move on.

After the keymap, I'm asked for a hostname (I respond with bsdchamber), and I'm asked about what to install. Since I'm not sure, I just prefer to leave as is and select OK.

Next, I get to the partitioning. Thankfully, I don't really need to do any specific stuff, so I just select the default option and tell it to use the entire disk and create an MBR partition scheme.

And this is how the final partitioning setup looks like (the device names are quite interesting, by the way):

Once it's finished, it begins copying all the data to the hard-drive:

Suddenly, I'm prompted to enter a root password:

And then it asks me to select a network interface and asks me whether I want to configure IPv4, DHCP, and IPv6. I only accept the first two. Then, I'm prompted to the DNS selection.

This is quite surprising to find nowadays, but I still fill them in with the Google Public DNS addresses.

After that, the timezone selector pops out, and I select my timezone without any problem at all. I also get to this system configuration:

Good, SSH is already included, but I still want the NTP daemon (for syncing up the time), so I select them with the space bar and move on.

This screen is quite interesting, and probably a reason why they say FreeBSD has somewhat better security than Linux. Oh well, I'll just select what feels more natural to me, including secure_console. Once I click OK, it asks me whether I'd like to add new users. I probably should, but since this is just a lab, there's no need to do so, so I pass, and I land on the final screen.

Well, at least you can change something up if you change your mind, but I'll just exit and finish the installation. It also asks about manual configuration, but I prefer not to do so. After that, I reboot to the new installation, even though I have to remove the virtual disc manually.

First boot

Since I selected secure_console, I do have to put credentials to enter into a shell, just like I'm used to in Debian-based distributions, and it works pretty much the same. In fact, the command line format seems to be exactly the same, even if it looks quite ugly.

I try the "ifconfig" command to check the network, and, sure enough, it is identical as in Linux. Next, I try to login via SSH.

Strangely, it refuses to accept my password, but I suspect it's probably due to the fact that I'm trying to login to the root user. I guess I'm creating another user, after all, al least just to get started.

It looks like the "adduser" command I used works a bit differently than I expected, but I still managed to create a user for me. I'll try entering with that one instead.

And it looks like we have a winner! I shouldn't be surprised, anyway, as root login via SSH isn't allowed when security measures are applied to Linux machines. Luckily, I should be able to enter as root with this brand-new user.

Or maybe not. I'll have to check the manual. "man su" should do it.

Well, this is interesting. It looks like I have to add my own user to the group "wheel" if I want to be able to log in as root. But, first of all, I should figure out how to add a user to a group. I used to do it with "adduser", but it probably won't work here, especially knowing what happened before. The manual itself says that "adduser" is just for creating new users.

Sadly, after trying to check some manual pages and listing the commands in /usr/bin, I can't find anything at all, so I guess I'll have to edit the /etc/group file manually.

Oh, great, I don't have nano installed. That's... the only text editor I can really use, so I'll have to install it. Luckily, I saw that you could install stuff in the login message by typing "pkg install", so hopefully "pkg install nano" will work?

Phew! It needed to do some more stuff, as it was the first thing I was installing via pkg, but it worked, so now I should be able to edit the file easily.

Okay, now that thing's done, will it allow me to...?

It does, luckily. And I notice right away that my user's home path is slightly different than usual. I'll have a look at the root directory.

There are a few folders that I don't recognize, but otherwise, it is very similar to what I'm used to seeing when working on Debian. I should also see what shell I'm using, just in case.

So root is using "csh"... I really thought I was using bash, since it was so similar, but I guess that being able to see hidden files was a dead giveaway of the fact something was off. In fact, I can't recognize any of the files that are present in root's home. Still, what I feel the most comfortable on is bash, so I'm going to try to install it.

Nice! It's included! Once I get it installed, I grab its location by using "which", and change it up in the /etc/passwd file.

I save the file and exit the connection, just to enter again and log in as root. After seeing the shell looks exactly the same, I decide to see all processes running (at least, from my user's perspective).

As I imagined, the changes didn't apply, and since I'm not looking at the proper command to do it, I just prefer to reboot the machine so that the changes take effect. A simple "reboot" will do it.

Unfortunately, that doesn't work, and I'm still stuck with csh. However, I notice there's another file, master.passwd, so I try to modify that one.

This one seems to have the root password, but it looks exactly the same as the other file otherwise. I save and reconnect to the host, but it doesn't work, either, so I search on the Internet, and I land on this page, which shows the command "chsh" in order to do what I wanted. I try "chsh root", but it takes me to a vi editor. Luckily, I happen to find another manual entry, where it says I can change it by setting the EDITOR variable, which is done with "setenv EDITOR nano", in my case.

But it fails. It simply refuses to accept that shell as valid.

Out of curiosity, I tried changing my non-root user's shell. And surprisingly, it did work!

I had seen before that the manual pages advised against changing the default shell, but I didn't expect that it wouldn't let me do so. Oh well, I'll have to deal with it.

This is it for the moment. In the next part, I'll be trying to install the LAMP stack on FreeBSD and then a desktop environment.