WPILib Suite Setup for Limited Disk Space on Linux


Just wanted to see if anybody can see any problems/issues/concerns doing what I am about to discuss concerning the installation of the WPILib tools for C++/Java on Linux.

Our team was given some small laptops with even smaller disks (~16GB) due to they are early model SSDs. We put a small version of Linux on them, as we did not want to pay for Windows licenses. We were initially going to use them for teaching programming for outreach, but later we figured we could use them for robot code development as well.

In the WPILib documentation (section 1.5, “WPILib Installation”, Linux subsection), each user is to download the suite from GitHub, and extract to their home directory (~, or /home/user). The suite extracted is approximately 2.1GB. As each additional user would need an additional 2.1GB, a small drive would fill up very fast after 2-3 users.


In order to save installation space, we extracted the wpilib directory to /opt, i.e. /opt/wpilib.

Then, for each user, symbolic links are made in the user’s home directory (~), linking to the installed directories at /opt.

In other words :
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/documentation
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/frccode
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/installUtils
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/jdk
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/maven
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/roborio
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/Robotbuilder
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/tools
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/utility
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/vendordeps
/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/vsCodeExtensions

Thus, each additional user links to the shared suite. We have tried this, and it works, as far as we can tell. We don’t plan on simulataneous users, so there should be no locking/contention issues.

Do any files of the suite need write access? I know a logs directory is created, and that is made in each users /home/user/wpilib/2020 directory.

Any thoughts why this should be a problem?

I’m more comfortable with Linux, but I think there is a way to do something similar in Windows.

Thanks for any input!

Sorry, the links should read:

/home/user/wpilib/2020/documentation -> /opt/wpilib/2020/documentation
/home/user/wpilib/2020/frccode -> /opt/wpilib/2020/frccode
/home/user/wpilib/2020/installUtils -> /opt/wpilib/2020/installUtils
/home/user/wpilib/2020/jdk -> /opt/wpilib/2020/jdk
/home/user/wpilib/2020/maven -> /opt/wpilib/2020/maven
/home/user/wpilib/2020/roborio -> /opt/wpilib/2020/roborio
/home/user/wpilib/2020/Robotbuilder -> /opt/wpilib/2020/Robotbuilder
/home/user/wpilib/2020/tools -> /opt/wpilib/2020/tools
/home/user/wpilib/2020/utility -> /opt/wpilib/2020/utility
/home/user/wpilib/2020/vendordeps -> /opt/wpilib/2020/vendordeps
/home/user/wpilib/2020/vsCodeExtensions -> /opt/wpilib/2020/vsCodeExtensions

Hmmmm. I don’t know enough about the inside of WPILib to really say whether the solution will work or not. Maven and VendorDeps will definitely need write access. Apparently not, I was mistaken.

However, A few questions about stuff you didn’t ask for an opinion on:

  1. Why have multiple user accounts? Could you create a single shared account that anyone who uses the computer logs into? Unless you’re storing personal information, I guess I’m not sure why multiple user accounts are required.

  2. FWIW windows license keys can be gotten for about $5 on ebay. Not necessarily recommending this per say, just making public knowledge a bit more public. If payment is your primary concern, well… one risky and questionable option.

  3. Small SSD’s can also be quite cheap. Have you considered upgrading the storage space to help prevent the above (and other) issues?

Although his year is a bit different… most years my advice would be: Any time spent debugging a customized sw dev setup during build season is wasted time. NI & WPI provide the blessed, “tried & true” method, and do a lot of work to get it right. Diverging from their answer is very very risky IMO.

Unless you’re 100% confident your solution will work prior to build season, for the whole build season, and never ever break… you’re putting yourself at a disadvantage relative to other teams, since you now have all their same problems for software development, plus a few of your own. Very oversimplified view I know… but this is at least how I usually model these sorts of problems/questions.

That being said, you may have some budget or organizational reasons why it’s ok to add those extra problems in. You also might not have those constraints. Just depends.

Assuming you are in the boat of “gotta go custom” for whatever reason: Do you really need RobotBuilder or Documentation on each PC? If you have internet connectivity I believe you could play some tricks with Maven to not require as much local storage. You could also pursue going Gradle/VIM only to reduce the need to have vsCode or its extensions installed. A lot of the utilities related to simulation could also be removed if you don’t plan to simulate your code.

Finally, assuming you have one high-storage PC: have you considred using VS Live Code share? You can set up the toolchain and software on one computer, and have students use just-vsCode on their laptops to “remote in” to the main computers session to simultaneously edit the software. This comes with its own share of assumptions and limitations, but might be another answer with fewer pitfalls than manipulating the WPILIB install structure.

Edit: Clarifications and things I had wrong.

1 Like

I assume then, you are also unable to upgrade the SSDs in these machines to something that would bypass this issue. As, with 16GB, the issue isn’t even getting Windows Licenses, since you wouldn’t have the space to even install Windows 10 on that size drive. If the SSDs are not upgradable, I know your pain, as I’ve had to help deal with two of these recent “HP Stream 14” laptops that have only 32GB of storage which is barely enough to install Windows 10, but then not enough for it to later download updates leading to all kinds of ridiculous nonsense… My solution was indeed to install Linux as the eMMC storage is soldered to the Motherboard on those laptops…

A simpler solution however, that doesn’t bring up many potential headaches would be to just use a single shared user account on each of the machines. This is what 3468 does with our 6 shared programming laptops. If you really still want to stick to having separate user accounts, and heal with the headaches therein, then keep reading.

So, to start, I’m not sure why you are symlinking each individual sub-directory.
You should just need one symlink.

/home/user/wpilib -> /opt/wpilib

and in theory you’re covered for multiple years in one go (assuming the directory structure doesn’t get changed yet again).

As for if it will work. Based on what I know of how the WPILIB is setup (for which I am making several assumptions, so hopefully someone more familiar does chime-in) I’m pretty sure it will provided you setup the permissions correctly. Also note, I think a lot about security, so some of that will have shaped my answers/explanations below.

You’ll need to make sure every other user will have the proper minimum permissions. Clearly this will involve Read permissions and probably Execute Permissions. If we can get away without Write permissions that would be good since it would keep one student from nuking the whole WPILIB install for the system. Looking at my own WPILIB install from this year, I see no file changes after the initial install except for updating the tools and changes in the maven dir from adding the SparkMAX VendorLib. With these considerations in mind, know that these ares may be pain points down the line if the students don’t have write permissions.

There are a few ways we can setup the permissions. The first and simplest is to just give everyone access to the /opt/wpilib/ directory and its sub-directories/files. chmod -R 755 /opt/wpilib/ for example.

A more fancy method would be to create a group, say wpilib, frc, programmer, ect. have the /opt/wpilib/ directory structure’s group set to it, as well as give the group as a secondary group to the student’s accounts.

groupadd wpilib
chown -R root:wpilib /opt/wpilib
chmod -R 750 /opt/wpilib
usermod -aG wpilib user

IF Write permissions are needed, or you want to give them, then I HIGHLY recommend going with the group setup rather than give everyone write access to the directory.

Also, there are options on linux meant to maintain shared directories. These tools are the umask, sticky bit and setuid/setgid.

The umask allows us to set what the permissions should be on any newly created files in a directory/directory structure. So we could make sure the right permissions are set on any files a student may have to create if they have write perms. You can even specify Sticky and SUID/SGID perms.

The Sticky Bit sets a directory such that only the owner of the file/directory can rename/move and delete files/directories in that structure where the sticky bit is set. So someone else can’t come in and nuke the directory unless they have root (or whatever other user you set to own /opt/wpilib) can remove things.

The SUID/SGID (User ID/Group ID) on the other hand set directories/files such that the user has a sort of elevated permissions to allow them to read/write/execute as if they were that user or group. So if SetGID was set for the wpilib group, all files created in the /opt/wpilib directory would have the group wpilib making sure everyone would still have access to them, and not just the user that created the new file.

One thing of note, I’m not certain how SUID and Sticky Bit would interact together. I’ve used each before, but never together. With SUID set to root, all new files created in the structure would be created owned by root as well, and so Sticky Bit would keep anyone but root from deleting the files, but SUID also means that the user is acting as root, so the SUID may kinda cancel out the Sticky Bit. I’d have to do more testing to validate that. From what I’m reading on the wikipedia page (which isn’t the proper documentation so I could be wrong) the Sticky Bit takes priority, so it may work out perfectly that they could create files and they’d be owned by root, but then they wouldn’t be able to delete them.

1 Like

Oh yeah, I totally forgot about things like VS Code Share, or even VS Code Server if you have another machine you could setup “hosting” on instead of local installs on each laptop.

1 Like

I can’t actually think of anything inherently wrong with this. You’re correct about the logs folder needing to be writable for all users, and its probably a good idea to have that different per user like you are doing. As for all the other folders, none of them are written to. The tools folder will need execute permission, but thats really about it. Clever idea, and I can’t think of anything right now that would have issues with that. In 2021 we’re probably going to include VS Code in the installer, which will slightly change things, but even that won’t be too bad, and I’ll keep this idea in mind when writing other features.

1 Like

Those windows licenses aren’t legal. They’re keys from bulk purchases by organizations or from OEMs, and selling them is a violation of the license terms (and odds are that they are being resold by a rogue employee who is essentially stealing from their company).

Mod Edit: removed discussion of piracy.

1 Like

Did some more research… probably correct, and edited to help reflect that. I’d historically been under the impression they were discarded OEM keys which were more “kosher”, but apparently even that violates the license agreements.

Seems like they’re Chromebooks from the description. Most of the ones I’ve seen have a chip soldered onto the board for storage over an actual SSD. If it shows up as /dev/mmcblk* on OP’s computers, it’s probably that.

Oh I am well aware of small/cheap computers soldering the flash chips to the motherboard.

1 Like


Thanks for the info on VS Live Code share! I haven’t heard of that before, and will definitely look at that in the future.

As far as your questions:

We are using GitHub for our code repository, and I felt it would be a big mess to have a single user account, shared among potential coders, and trying to modify the .gitconfig file for each actual user.

I think someone stated those were not quite kosher… and besides, my experience is that given the same hardware, Linux will run circles around Windows, performance wise…

These computers were donated to us, and we want to use money for things toward the robot. If need be, we can remove some other things to free up some space.

Absolutely agree with you here, IF we were using these computers for final development. However, right before the start of the 2020 season, our team purchased a modern PC with Windows 10 that we use for compiling, deployment, and driver station. That newer PC is what we will use for “production” software development/deployment. These computers with the limited memory would only be for teaching sessions (programming outreach, and internal training), or if somebody wants to contribute to the programming, and doesn’t have a computer of their own that they could use.

RobotBuilder is only 8KB. However the documentation is 174MB, so if we have Internet (which we would if using GitHub). we could just visit the C++ API docs.

I’m not that familiar with Gradle or Maven, so that would take some time.

MS VS Code from what I can tell takes ~270MB, and yes, we have some scripts that allow us to compile from the command line interface. But I’m not sure if I want to teach new programmers VI (or for that matter, re-teach myself what little I knew of VI). Besides, we put EMACS on there, so why would they need anything else? (Hopefully I didn’t start a holy war here ;-).

And again, removing simulation is a great idea, I just don’t know enough about it to do anything…

Finally. thanks for the tip on Live Code. I will definitely look at that.

1 Like


Thanks for the feedback and the great ideas about umask, sticky bit, and setuid/setgid. I’m familiar with umask, but only heard of sticky bit and setuid/setgid. I’m going to read up on those in the near future.

I’m also glad to have someone bring up the use of groups, which I was thinking about, but just didn’t have the time to implement. Hopefully I should not have to be worried with security too much, but I may revisit that later.

As for why I am symbolic linking each directory, each user must have write access to the ~/wpilib/2020/logs directory, from what I could see. If I symlink the base directory wpilib, I believe each user will overwrite each others log files.

Finally, thanks for giving such a detailed procedure for setting up the groups.

Appreciate the help!


I appreciate somebody from the WPILib team providing some feedback on this (I was hoping for that), and confirming that I wasn’t out in left field.

Also thanks for confirming the write access needed for the logs directory, and that the other directories do not need write access.

Thanks again for the confirmation. Appreciate it!

If you have a more powerful machine that has SSH installed on it, I highly recommend checking out vscode’s Remote Development extensions.

In particular, you can run vscode locally, connected to a remote machine over SSH. If the local network is fast enough, you won’t notice a difference – it’s really quite seamless, when you open terminal you’re executing commands remotely.

I actually use this for development at my day job: I run vscode on my mac, connect over SSH to my Linux development station. Most of the time I never notice that it’s remote.