About the “Mir hate-fest”

If you’ve been following the news, you’ll probably know about Ubuntu dropping Unity. I would say this is probably a surprise to many of us, due to the many years of efforts they have invested in Unity 8, and it being so close to completion.

It was speculated that, since Unity 8 is now dropped, Mir would also be dropped. However, it looks like it will still be developed, but not necessarily for desktop usage.

But speaking of that post, I found it quite unfortunate how Mark talked about “Mir-hating”, simplifying it to seem like it was irrational hatred with very little rational grounds:

“It became a political topic as irrational as climate change or gun control, where being on one side or the other was a sign of tribal allegiance”

“[…] now I think many members of the free software community are just deeply anti-social types who love to hate on whatever is mainstream”

“The very same muppets would write about how terrible it was that IOS/Android had no competition and then how terrible it was that Canonical was investing in (free software!) compositing and convergence”

Now, in all fairness, I haven’t been involved enough in the community to know much about the so-called “Mir hate-fest”. It is very possible that I haven’t seen the irrational tribal-like hatred he was talking about. However, the “hatred” I have seen would be spread into 2 categories (mainly):

1. People (like me) who were worried about Mir splitting up the linux desktop, basically forcing any linux user who cares about graphical performance to be under Canonical’s control.
2. People worrying about architectural problems in the codebase (or other code-related issues).

Both of these, IMO, are quite valid concerns, and should be allowed to be voiced, without being disregarded as “irrational hate”.

I’ll admit, my original post on this topic was pretty strong (and admittedly not very well articulated either). However, I believe that it’s important, especially in a free software community, to be able to voice our opinions about projects and decisions. In software circles that tend to stifle open discussion (I’ve seen this especially in various proprietary software communities), it is honestly a terrible atmosphere (at least IMO), and the community tends to suffer as a whole (due to companies feeling that they have power over their users, and feel that they can do anything they want, in hopes of gaining more profit).

In Mark’s defense, I agree that it is very important to stay respectful and constructive, and I apologize for the tone in my first post. I haven’t seen many other rude comments towards Mir, but as I said, I could be wrong. Having a lot of rude comments towards your software is very difficult for those behind the project to handle, and usually doesn’t amount to anywhere constructive anyways.

But I think that saying something along the lines of “anyone who disagrees that Mir is a good project is an idiot” (“I agree, it’s a very fast, clean and powerful graphics composition engine, and smart people love it for that.”, alongside the quotes I mentioned above) is very counterproductive to maintaining a good free software ecosystem.

My bottom line for this post is: I believe it’s vital to allow healthy discussion for projects within the free software community, but in a respectful and constructive manner, and I believe this point is especially important for large projects used by many people (such as ubuntu, the linux kernel, etc.).

Why Openlux instead of Redshift?

First, I want to clarify that this is not a post trying to show that one is better than the other unequivocally. This is, instead, a post trying to show my reasons for writing openlux, and the differences between both softwares. I’m sure that many people will prefer the way that redshift works, over the way that openlux works, and that’s awesome!! The purpose of this post is, mainly, to show the differences, and hopefully help you decide which is better for your circumstance :)

My initial reason for writing openlux was because f.lux didn’t work for me, for various reasons (as I outlined in the first post about it) … I was actually unaware of redshift. There were a few people who linked me to it, and I immediately felt slightly disappointed that I hadn’t done my research before (would have saved me quite a bit of work!). Looking into it though, it’s not what I was looking for, and it has some of the issues that made me switch away from f.lux.

Redshift’s mode of operation is different than openlux’s. It primarily functions as a daemon, changing the color temperature automagically, depending on your timezone. This is a really handy feature, however, you don’t have much ability to configure the times. If you don’t have insomnia, and have a regular sleeping schedule, this is probably perfect. You tell it where you live, and it will change the screen color temperature throughout the day, in order to match the light you would receive if you were outside at that time (except at night, of course =P). But in my case, I can stay up until 4-5am, unable to sleep at all. Having the screen automatically change to a higher color temperature when I’m trying to go to sleep is most definitely not what I need. Now I could change the timezone every so often, but I’d rather have something in which I control when the screen color changes, instead of having to work against the program. I am aware that redshift has an option for manually changing the color temperature, but you don’t have much control over other options (such as animating to it, or individual control over RGB channels).

Redshift also uses color tables in order to compute the RGB values from kelvin temperatures. This allows for maximum accuracy within the range it provides (1000-25100K), however, it doesn’t allow anything outside of the range. On the other hand, openlux, works using Tanner Helland‘s algorithm, which allows for a theoretically infinite (practically 0-2³², because it’s stored in a 32-bit integer), but less accurate result. Personally, I prefer using an algorithm, but there are definitely things to say about using a color table instead. The algorithm is pretty accurate (I think it’s a maximum of ~3-5% off of the original value), but if you’re within the range that redshift provides, it’s always nice to have 100% accuracy!

The main philosophical difference (that influences how the programs evolve) between redshift and openlux is the goal: redshift is more oriented towards being a standalone, fully-featured program, while openlux is oriented towards being a program that only does one task (change the screen color temperature), and focuses on that one task. It leaves tasks such as changing the color temperature in accordance with the timezone to other programs specialized for this (such as cron), or manually. Redshift tends to go more on the side of “run it, and forget about it”, while openlux leans more on giving the user maximum control and flexibility.

There’s definitely something to be said about both philosophies, and different users will appreciate different philosophies. I personally prefer the one of having full control at all times, but there are many users who would prefer to just have the program manage it for them automagically.

If you’re not sure which to use, try both! See which one works best for you. After all, GNU/Linux is all about choice :)

If I’ve made any mistake in this article, please let me know. This post is most definitely not about saying that one software is better than the other. While I, of course, prefer openlux, I want this to be a fair comparison of both softwares, so that users can better decide which software they want to use for themselves.

Openlux 0.2 beta – Animations, iOS port

I wrote openlux around 2 and a half weeks ago, as a simple, libre alternative to f.lux that addresses a few issues I’ve encountered with it. I’ve since used it everyday, and I’ve actually noticed an improvement in my sleep!

However, my iPad still uses f.lux (or, until today, at least). No, in this case, I’m not worried about the fact that f.lux is proprietary (it’s an iPad), but earlier, when my sleep was really messed up (and by messed up, I mean, I was going to sleep at 7-8am), f.lux would automatically switch to 3400K (instead of 2300K), which definitely didn’t have a positive impact on my sleep. Also, it only goes down to 2300K, doesn’t allow much customizability, and doesn’t always work how I want it to work, etc.

So after spending quite a long time (basically ever since I released the first version of openlux) working on the port, it finally works!!! It doesn’t work as well as I wanted it to (multiple colors output the same value, compressing the color range … I tried lerping values, but it ended up giving garbage), but at least it works!

Animations literally took about the last hour of developing this version (in other words, barely any time at all, compared to the time needed to develop the iOS port), since, luckily, I only encountered one bug while making it. The point of animations is not for visual bling, but rather to make it easier on the eyes if it’s run automatically (e.g. via cron).

Other than those, there are a few minor features, such as optional relative adjustment of colors (“-b 10” will set the blue channel to 10, “-b +10” will add 10 to the blue channel, and “-b -10” will remove 10), and saving/resetting gamma values (mainly just a by-product of working on the iOS port).

If anyone would be interested in testing this on their iDevices, I would really appreciate it ^^ Though it works fine on my 1st generation iPad, I don’t know if it will work on other devices too. I wrote instructions on how to compile and run it here: https://github.com/AnonymousMeerkat/openlux/wiki/Compiling-for-iOS :) I’m not aware of this being able to cause any permanent damage to your device (my device works fine now, even after the display being severely messed up multiple times), but if you’re scared, stick with f.lux for now. Quick note: it doesn’t work on iOS <4, since it needs to retrieve the gamma table (which iOS versions <4 don’t support).

To wrap up, here’s a few examples of the new features that come with openlux 0.2:

openlux -k 1000 -a 10000         # Animates to 1000K in 10 seconds (10000 milliseconds)
openlux -k 1000 -a 100000 -d 100 # Animates to 1000K in 100 seconds, with a delay of 100 milliseconds per "frame" (less CPU usage)
openlux -k 1000 -g +10           # Sets the color temperature to 1000K, but adds 10 to the green channel
openlux -R                       # Resets to the last saved gamma table (openlux automatically saves the gamma table the first time it's run per boot)
openlux -s                       # Saves the gamma table

How to set up WineASIO

Step 1: Install WineASIO

If you use ubuntu, run this in a terminal:

sudo apt-get install software-properties-common wget
sudo add-apt-repository ppa:kxstudio-debian/kxstudio
sudo apt-get update
sudo apt-get install kxstudio-repos
sudo apt-get update
sudo apt-get install wineasio

If you use Arch Linux:

Add the Arch Audio repository, then run in a terminal:

sudo pacman -Sy wineasio

Step 2: Register WineASIO

If you have a 32-bit WINE prefix, or you have a 64-bit one, and you want to run a 32-bit ASIO application (e.g. a DAW), run this:

regsvr32 wineasio

If you have a 64-bit WINE prefix, and you want to run a 64-bit ASIO application:

wine64 regsvr32 wineasio

If everything went smoothly, you should see a message similar to:

Successfully registered DLL wineasio.dll

However, you may receive:

Failed to load DLL wineasio.dll

In my case, the reason why this message occurred, is that wineasio.dll was installed to the wrong location. I had 2 problems, actually. It was first installed to /usr/lib/wine, not /usr/local/lib/wine (I have a custom-built version of WINE), and second, even if it had been installed to /usr/local/lib/wine, it wouldn’t have worked, because, in my case, WINE loaded 64-bit libraries only from /usr/local/lib64/wine, and 32-bit libraries only from /usr/local/lib/wine. The package had installed the 32-bit version of wineasio to /usr/lib32/wine, and the 64-bit version to /usr/lib/wine.

Try moving the wineasio .so’s to these places:

• 64-bit wineasio .so: /usr/lib64/wine
• 32-bit wineasio .so: /usr/lib/wine

Then try again. If you still have problems, leave a comment below, and I’ll try my best to help =)

Step 3: Setup JACK

WineASIO uses JACK as the backend for the audio, so, not surprisingly, JACK has to be setup correctly for WineASIO to function correctly. I wrote an article a while back about how to do this.

Step 4: Profit!

It’s that simple! Now all you have to do is to load up the application you want, and set the ASIO driver to WineASIO =)

Creating an orchestral track under Ubuntu – Part 1: Setting up JACK

In my previous post, I was talking about (okay, fine, advertising) a track I made under linux, using LMMS, and I said I would write a tutorial on setting up an audio studio, and creating a track with it, so here it is! I’ll dividing this tutorial into multiple parts, so stay tuned (one way to do this is to subscribe … hint, hint ;) )!

This part, as the title says, is to setup JACK. This is probably the most frustrating step in setting up your studio, but it’s very important! Most people will try to make it work with a program named QjackCtl. If that works for you, awesome! But it never worked for me. So instead, I’ll show you how I made it working, well, without it (mostly).

Here is the command I run on my computer to start JACK. It’s probably not optimal, but it works for me:

killall jackd;killall pulseaudio;jackd -R -t 1000 -d alsa -P hw:0,0 -r 48000 -n2 -D

This will probably not work on your computer, but we’ll test it, using alsaplayer (install it if you don’t have it yet, and make sure that the volume levels are at 100%, and nothing is muted):

alsaplayer -o jack PATH/TO/AUDIO/FILE.mp3

And, of course, replace PATH/TO/AUDIO/FILE.mp3 to the path to an audio file (that you know works, and for your convenience, I’ve uploaded a working test audio file here: http://www.uploadmb.com/dw.php?id=1375942423). The test is simple: Click on the play button. Do you hear audio? If yes, then JACK works! If no, then, well, do I need to clarify this? :P

Anyways, if it doesn’t work, what you’ll have to do is to try EVERY. SINGLE. AUDIO DEVICE. (and subdevices). Sounds like a lot of repetitive work, right? It is! So to get the audio device list, open up QjackCtl (I said that we’d get it working mostly without it, not completely!), select “Setup”, and click on the arrow beside “Interfaces”:

Now, if you look carefully, you might find a red circle around a certain area. That area contains the hardware ID (for lack of a better term) which we will be giving to JACK. So re-run this command, changing the part in bold with the ID you saw:

killall jackd;killall pulseaudio;jackd -R -t 1000 -d alsa -P hw:0,0 -r 48000 -n2 -D

And then re-test JACK (using the alsaplayer test I mentioned earlier). If it doesn’t work, keep on repeating the JACK step, changing the hardware ID each time, and, of course, test it. Once it works, package it up in a script, like this:

#!/bin/bash
killall jackd;killall pulseaudio;jackd -R -t 1000 -d alsa -P HARDWARE_ID_HERE -r 48000 -n2 -D & # The ampersand at the end is intentional, as it runs it in the background

Save it, and chmod +x it (set it as executable), then run it when you need JACK.

---

Bonus: Routing Pulseaudio to JACK

Don’t worry, this part is simple :D . Make sure JACK and pulseaudio are running (you can run pulseaudio by running this: pulseaudio &), then run this:

pactl load-module module-jack-sink channels=2; pactl load-module module-jack-source channels=2;pacmd set-default-sink jack_out

You might have to re-run it, and restart applications using pulseaudio.

---

This is the full script I use to start JACK, and route pulseaudio to it:

#!/bin/bash

killall -KILL jackd
killall -KILL pulseaudio
jackd -R -t 1000 -d alsa -P hw:0,0 -r 48000 -n2 -D & # REMEMBER TO CHANGE hw:0,0
sleep 3
pulseaudio &
sleep 3
pactl load-module module-jack-sink channels=2; pactl load-module module-jack-source channels=2;pacmd set-default-sink jack_out
pactl load-module module-jack-sink channels=2; pactl load-module module-jack-source channels=2;pacmd set-default-sink jack_out

My thoughts on Mir

EDIT 27/08/15: I apologize for the harshness of this post. I was quite upset about this move when I wrote this.

If you aren’t aware, Canonical is planning on writing a new display server, competing to both X11 and Wayland, named Mir.

I’ll state my opinion right now: I really do NOT like this move. The rest of the post is the “why” of my opinion. I have not written all of the “why”, because some of the reasons I thought of lacked enough proof to back what I said (such as Canonical becoming another Microsoft or Apple, trying to take over the linux world ;)).

First, the segregation. Let’s assume that Mir is, as was planned “A … that is extremely well-defined, well-tested and portable.” (this is very hard to do, in fact, there are only a very few amount of software and libraries that are this good). Now this would cause a horrible issue of segregation, because now application developers that write applications for Mir will exclude people who do not have Mir (kind of an obvious issue though). Most application developers will use a toolkit, such as Qt or GTK+, which provides an abstraction layer that will allow the applications to run on any display server (though, of course, this requires patching them to support the display servers, but canonical, IIRC, has promised to do this, at least for Qt), so this is less of an issue. The bigger issue would be with the 3rd party graphics drivers. Both major GPU manufacturers (Nvidia and ATI) are already having issues with giving X11 support to their drivers (though Nvidia has considerably less issues than ATI). Now comes along Wayland, an alternative to X11. Back in 2010, Nvidia clearly stated that they do not have any plans to support wayland (they seemed to have changed their mind though, or at least, considered it), and ATI does not plan on supporting wayland anytime soon. This is reasonable for the companies and for linux. As long as X11 will still be supported until both companies officially support wayland, everything should be somewhat okay. But then comes along Mir, a company-lead alternative to both Wayland and X11, for their operating system. 3 different display servers for linux, and both major GPU manufacturers are already having issues with one. This is just ridiculous. And anyways, just think of the users and distros, trying to find which one they should use.

As I said before, I was assuming Mir was exactly what it was planned (i.e. perfect-world scenario). I already stated that it was extremely hard to actually meet the requirements they wanted, let alone that Canonical is not exactly known for their amazing abilities at efficient coding. Just look at unity. Even GNOME 3 and KDE are faster than that! And GNOME 3 uses Javascript extensively (a language that I think we can all agree on its slowness). Unity is written in C, C++, and Vala, 3 languages that are quite fast (though using many languages together can slow down an application). Please tell me: Why is it that Unity is so much slower that GNOME or KDE, which have at least the same complexity, if not much more? (EDIT: Some people have said part of the cause of the slowness is because of Compiz and Nux. Nux, IIRC, is developed by Canonical too) Now look at the Ubuntu software center, and at Ubiquity, two other applications written by canonical. The USC took ~10 seconds to load, compared to most other applications loading nearly instantly. Of course, they are written in python, which, after programming in it for a rather long time (and having a lot of experience with other languages), I think I can say that it is not only a slow language, but also a rather badly designed one. Canonical did not, of course, make python, but I just used that to show you an example of their poor decisions. Enough hitting on Canonical, let’s assume that they are great coders now. How long do you think it would take to write a complete display server that is “extremely well-defined, well-tested, and portable”? Canonical is a rather small company, how do you think they will write an application (or library) that is “well-tested”? Or maybe we should ask, what defines “extremely well-defined” and “well-tested” (and “portable”)?

Lastly, let’s say that they were able to accomplish their goal. Why do they need a new display server in the first place? Why can’t they just use Wayland? There is a section on the wiki about this, which I tried to read, but it was quite vague. All that I could understand is that they wanted support for 3D input devices. So why don’t they just talk to the Wayland developers about this and maybe help them implement it if progress is not going fast enough? Or if they don’t want to have it in wayland, just fork it, don’t start writing your own. “In summary, we have not chosen Wayland/Weston as our basis for delivering a next-generation user experience as it does not fulfill our requirements completely”. Oh, come on. Wayland is open-source, you can change it if you need to, you know. Or if they don’t want the changes, you can just fork it. I know I’m repeating my last sentence, but this is just ridiculous.

So to summarize, I’m not that crazy about Mir :P

I know I said things rather bluntly, and I’m expecting that most of the reactions to this will be rather harsh, but I feel that it was important to write this. It’s not because I hate ubuntu that I write this, I really like the initiative, just not the execution (which is why I write these kinds of posts… maybe if enough people show their disapproval towards their methods, they might change their minds ^_^). Also, if you think that any of the claims I made were false, let me know, I’m not that closed-minded about it ;)

Why I migrated to Arch Linux

First, yes, I am well aware that this is an ubuntu-related blog, monitored on planet ubuntu, etc… This is not a “XYZ is better than ubuntu” post, but rather a “Consider XYZ too” post.

I have been a loyal ubuntu user for around 5 years, and I have also tried my best to help the community for around 3 years (and still am). I never plan on leaving the community, as I find ubuntu is sort of like a gateway for windows/mac users to the open source world, and all of us need to make sure that each user can have the best experience in that gateway so that they can explore deeper and, in their turn, help out too.

Anyways, going to the topic of this post, I have had a very pleasant experience with ubuntu until 11.10. Ubuntu then tried to attract the public to it by, well, over-blinging it (I’m referring to Unity). I have to say they did an excellent job on keeping it beautiful and minimalistic, but it needs a mid/high-range computer to use it. On my computer (which I consider it to be rather mid-range), it was really slow (2-5 minutes to login, let alone using it). Another thing that I didn’t like was how ubuntu over-patched everything. From the linux kernel to GNOME 3, it’s no wonder that everything was really slow. I’m sure that there are good reasons for doing so, but still, I personally like doing my own patching as I want it, not as someone else wants it. Also, I am not a huge fan of the debian package managment system, as even doing “nothing” takes around a second or two… not interested in that. The API is seriously messy, horribly documented, and even from a “users” perspective (a more tech-savvy one, of course), it’s hard to understand the output (for example, do you have any idea what’s happening when you run “sudo apt-get update”?)

You are probably thinking of a thousand counter-arguments against what I said, and they are probably all right. The thing is, I’m talking from a hacker/developer’s perspective where I want everything my way, nobody decides for me (which I feel that ubuntu is sort of doing). I know that the average user is probably very happy from the decisions ubuntu took, maybe even for the exact reasons that I don’t like it.

So now that I’ve written a bit why I don’t like ubuntu, I’ll write a few things that I like about arch. First of all, the installer is awesome! Yep, no installer, you do it by hand. This initially repulsed me from arch, until I discovered how the install process worked, and then I really loved it. It doesn’t come preinstalled with loads of apps that you might never use, it just has the bare minimum of a good linux desktop (which, IMHO, is great). I also loved the package manager ever since I started using it. So simple, so fast (even the downloads are faster because of LZMA compression, and by the way, the uncompressing is lightning fast), and yet so powerful! It uses standard getopt-type arguments instead of commands, so it’s way easier to use. The other thing that I like is how arch is so community-based. It isn’t a project where there is a team behind it, and community can help as 3rd party devs. It works by the community donating PKGBUILDs (shell scripts that build packages) and scripts or whatever else is needed and then “trusted members” (people who have been donating to arch linux a lot) will then review it for safety before including it. Another thing that I like is how it is a rolling release. This means that there are never new releases of arch, you update it, you have the latest arch system.

So as I said in the beginning, this is not “Arch is better than Ubuntu”, but rather “Arch works better for me than Ubuntu did”. I have nothing against the idea of ubuntu, I love it actually. But I don’t want to use it anymore, that’s all :). That being said (and I repeat again), I do not plan on ever leaving the community, I will always try to help out the best I can :)

Thanks for reading! Feel free to comment below on your own opinions of this matter (and please, keep it nice, I don’t want to deal with a flame war).

Relinux 0.4a1 is released!

After about a year of writing, rewriting, and rebasing, relinux 0.4a1 has finally been released! Here are a few of the new features in relinux 0.4:

• Qt user interface
• Thread-based, so multiple operations can run at the same time
• Logging, so if there are any problems while relinux runs, you can easily diagnose it
• ISO level support, so that your compressed filesystem can exceed 4GB (if needed, of course)
• Module API, so that you can automate common tasks in making your distro

Continue reading »

How to root an Android device under Ubuntu

I have found a lot of tutorials on this subject, but none really supported Android x86 devices, so I decided to write my own here which will support both ARM and x86. If you have an android phone or tablet, you have an ARM CPU, and if you have a virtual android device (or have android installed on your computer), you have an x86 CPU. Notice that you are on your own with rooting. I can try to help, but I cannot guarantee that it will work 100% (it might even break your device). Good luck!

Prerequisites:

• Superuser (download the appropriate version, either ARM or x86): http://androidsu.com/superuser/
• Psneuter:
  • x86 version: http://ompldr.org/iaGRpOA or http://www.2shared.com/file/la-SBMiM/psneuter.html
  • ARM version: http://ompldr.org/iaGRpOQ or http://www.2shared.com/file/nslmVzaB/psneuter.html
  • Both: http://thepiratebay.sx/torrent/8817388/psneuter_-_ARM_and_x86 (I am seriously tired of upload websites constantly going down)
• An android device (obviously)

First, open up your android device and navigate to Settings -> Applications -> Development, and make sure USB Debugging is on. Next, connect your android device to your computer (if it isn’t already), but make sure you do NOT mount it. If it’s a virtual device, you don’t have to worry about it. Connect your android device with ADB, and type these commands in the terminal (of your computer, not the android device, replacing “path/to/directory/X/is/located” with the actual directory where X is located):

cd path/to/directory/psneuter/is/located
adb push ./psneuter /data/local/tmp/
cd path/to/directory/superuser/is/located
mkdir superuser
cd superuser
unzip ../Superuser-*.zip
adb push ./system/app/Superuser.apk /data/local/tmp/Superuser.apk
adb push ./system/bin/su /data/local/tmp/su

We just uploaded everything we need to the android device (under a temporary directory). Now it’s time to root it! If you are using Android x86, press ALT+F1 and type the commands there instead of on the host machine. If you are not using it, first type this in the host machine’s terminal (it will simply engage a shell with your phone/tablet):
adb shell
Enter these commands:
cd /data/local/tmp
chmod 755 psneuter
./psneuter
On the host machine (yes, this is both for x86 and non-x86), connect to the android device using ADB, and type these commands:
adb shell
busybox ash
mount -o remount,rw /dev/block/mtdblock0 /system
cp /data/local/tmp/su /system/bin/su
chmod 6755 /system/bin/su
cp /data/local/tmp/Superuser.apk /system/app/Superuser.apk
chmod 777 /system/app/Superuser.apk
reboot
Your android device should now be rooted!

Virtualbox shows “Kernel driver not installed”

This error happens when you upgraded to a newer kernel and virtualbox-dkms hasn’t been built for it.

Instead of writing a huge post about the how and when etc…, I’ll just write the solution below (I don’t see a need to add a lot more information anyways):

sudo dpkg-reconfigure virtualbox-dkms
sudo modprobe vboxdrv
sudo modprobe vboxnetadp
sudo modprobe vboxnetflt
sudo modprobe vboxpci

All this does is that it recompiles virtualbox-dkms so that it works on your kernel, and then it loads the VirtualBox kernel modules. After running this code, you should be able to use virtualbox :)

Notice that you don’t need to run the modprobe commands if you’re going to reboot right after (or rather, reboot before you want to use virtualbox).