Skip to content

ubuntu-vmware-developer-environment.md

Latest commit

 

History

History
358 lines (253 loc) · 15.9 KB

ubuntu-vmware-developer-environment.md

File metadata and controls

358 lines (253 loc) · 15.9 KB
Raw

Ubuntu VMware Developer Environment

Learning Context

  • Subject: Operating Systems and Development Environments
  • Input mode: Full Personal Explanation
  • Environment: Windows host with an Ubuntu guest in VMware
  • Learning status: Practiced, based on personal reporting
  • Validation status: Partially tested; the setup, installations, and troubleshooting results were not independently reproduced while writing this entry

My Original Understanding

I built an Ubuntu virtual machine as a development environment and organized what I learned into twelve phases. The work covered virtualization, installing Ubuntu, Linux commands, package management, development tools, Git and GitHub, SSH, GNOME customization, troubleshooting, recovery, storage, and Docker architecture.

I also made two deliberate decisions:

  • I did not resize the virtual disk because the existing free space was sufficient.
  • I postponed Docker until I begin backend work involving tools such as Spring Boot and PostgreSQL.

The most important practical problem I encountered was that applications disappeared and GNOME search stopped working. I identified a conflict between Ubuntu Dock and Dash to Dock, disabled Ubuntu Dock, and kept Dash to Dock. This was my first reported Linux desktop debugging experience.

Understanding Assessment

My overall understanding is mostly correct.

The strongest parts are the separation between host and guest operating systems, the purpose of guest integration tools, basic Linux and package-management concepts, layered recovery options, and the broad differences between Docker on Linux, macOS, and Windows.

The following points need precision:

  • A VMware snapshot is a short-term recovery point, not a replacement for an independent backup. It depends on the virtual machine's files remaining healthy and available.
  • Timeshift is designed primarily for system restoration. It should not be treated as the main backup for personal files.
  • Git and GitHub preserve project history only after work has been committed and, for remote recovery, pushed. They do not back up the whole computer or virtual machine.
  • Keeping one repository per project and keeping learning repositories private are reasonable personal strategies, not mandatory Git rules.
  • SSH is a common secure authentication method for Git hosting, but HTTPS authentication is also valid.
  • Installing many tools creates a strong workstation foundation, but readiness for a specific workload still depends on configuration and project-level testing.
  • VMware guest integration features can depend on the installed tools package, VMware product settings, display session, and guest configuration.
  • rm deletes files and directories and normally does not move them to a desktop trash folder. It must be used carefully.

Phase 1 — Virtualization Fundamentals

I learned that a virtual machine is a software-defined computer running inside another computer.

  • Host operating system: Windows, which controls the physical hardware and runs VMware.
  • Guest operating system: Ubuntu, which runs inside the virtual machine.
  • VMware: The virtualization layer that assigns virtual CPU, memory, storage, networking, and other devices to Ubuntu.

A Linux VM gives a developer an isolated environment for learning Linux and testing software without replacing the host operating system. Snapshots can provide convenient recovery points before risky changes, but they are not complete backups.

Phase 2 — Installing Ubuntu

I practiced:

  • Installing Ubuntu inside VMware.
  • Allocating virtual CPU, RAM, and storage.
  • Configuring virtual hardware.
  • Installing or enabling VMware guest tools.

VMware's Linux guest tools can support features such as:

  • Automatic display resizing.
  • Host-and-guest clipboard integration.
  • Drag and drop.
  • Shared folders.
  • Mouse and desktop integration.
  • Improved guest management.

Feature availability can vary by configuration. On supported Linux distributions, open-vm-tools is generally preferred, and desktop integration commonly requires the desktop package.

Phase 3 — Linux Basics

I became familiar with:

  • Ubuntu Desktop.
  • The GNOME desktop environment.
  • Applications and the terminal.
  • The home directory.
  • The root filesystem.

I was introduced to these commands:

pwd
ls
cd
mkdir
rm
cp
mv
cat
sudo
apt

These commands cover navigation, file and directory operations, displaying file content, administrative execution, and package management. Commands using sudo or destructive operations such as rm require extra care.

Phase 4 — Package Management

I learned that Ubuntu uses APT to work with software packages and configured repositories.

sudo apt update
sudo apt upgrade
sudo apt install <package>
sudo apt remove <package>
  • A repository is a configured source of package metadata and software.
  • A package is a distributable unit of software.
  • A dependency is another package required by a package.
  • apt update refreshes local package information.
  • apt upgrade installs available upgrades under APT's upgrade rules.
  • apt install installs a named package and required dependencies.
  • apt remove removes a named package, although some configuration or unused dependency data may remain.

The angle-bracketed <package> is a placeholder and must be replaced with an actual package name.

Phase 5 — Development Environment

I reported installing:

  • Git.
  • GitHub CLI.
  • Visual Studio Code.
  • IntelliJ IDEA.
  • PyCharm.
  • Java 21 LTS.
  • Python.
  • uv.
  • Google Chrome.
  • Zsh.
  • Starship Prompt.

This provides a broad foundation for Java, Python, command-line, and Git-based development. The installations and versions were not independently checked for this entry, so they remain user-reported rather than repository-verified.

Phase 6 — Git and GitHub Foundations

I learned:

  • Git is a distributed version-control system.
  • GitHub is a hosting and collaboration platform for Git repositories.
  • A repository stores a project's tracked files and history.
  • A commit records a selected change in the local history.
  • A push transfers local commits to a configured remote.
  • A branch is a movable line of development.
  • GitHub repositories can be public or private, subject to platform permissions and settings.

My current personal strategy is:

  • Prefer one repository per independent project.
  • Keep learning projects private until I decide they are ready to publish.

These are organizational choices, not universal requirements. A monorepo or an early public repository can also be appropriate in other situations.

Phase 7 — SSH Authentication

I reported configuring:

  • An SSH key pair.
  • GitHub SSH authentication.
  • Git operations that no longer prompt for an account password on every use.

SSH keys are a common secure authentication workflow. The private key must remain secret and must never be committed to a repository. Passwordless Git operations do not mean authentication is absent; the SSH key performs the authentication.

Phase 8 — Linux Customization

I reported installing or configuring:

  • WhiteSur Theme.
  • GNOME Tweaks.
  • Dash to Dock.
  • A macOS-inspired desktop appearance.

I learned about GTK themes, shell themes, icon themes, and GNOME Extensions. These layers affect different parts of the desktop and can interact with the Ubuntu-provided GNOME configuration.

Phase 9 — Troubleshooting GNOME

Reported problem

  • Applications disappeared.
  • Search stopped working.

Reported diagnosis

A conflict existed between Ubuntu Dock and Dash to Dock.

Reported solution

I disabled Ubuntu Dock and kept Dash to Dock.

Result and evidence status

I reported that this resolved the issue. The result was not independently reproduced or supported with logs in this entry, so it is recorded as a personal troubleshooting result rather than a universally proven cause for similar symptoms.

This experience demonstrated a useful debugging pattern:

  1. Identify what changed.
  2. Look for overlapping extensions or services.
  3. Disable one conflicting component.
  4. Test whether normal behavior returns.
  5. Record the cause, action, and result.

Phase 10 — System Recovery

I learned that recovery tools protect different layers:

Tool Main purpose Important limitation
VMware snapshot Return a virtual machine to a captured state Not an independent backup of the VM
Timeshift Restore Linux system state using supported snapshot modes Not the primary backup for personal files
Git Restore committed project versions Protects tracked project history, not the operating system
GitHub or another remote Store pushed Git history away from the local repository Uncommitted and unpushed work is not included

For stronger protection, important personal files and the virtual machine itself still need an independent backup strategy.

Phase 11 — Storage Management

I learned these concepts:

  • A virtual disk is storage presented by VMware to the guest as a disk device.
  • A partition is a defined region of a disk.
  • sda2 is a possible Linux device name for the second partition on the first SCSI/SATA-style disk, but actual names vary by system.
  • Unallocated space is disk capacity not currently assigned to a partition.

I also learned that GParted is a graphical partition editor that can create, delete, shrink, or extend supported partitions.

Partition changes carry a risk of data loss. I chose not to resize the disk because enough free space remained. This was a sound decision: storage should not be changed only because resizing is technically possible.

Phase 12 — Docker Architecture

I learned why the experience of running Linux containers differs by operating system:

Linux

Docker Engine can run directly on a supported Linux host and use Linux kernel features for containers. This generally avoids the extra Linux virtual-machine layer required by non-Linux hosts.

macOS

Docker Desktop runs Linux containers through a managed Linux virtual machine because macOS does not provide a Linux kernel.

Windows

Docker Desktop can use a WSL 2 or Hyper-V-based backend depending on the selected configuration and container mode. This introduces additional virtualization and integration layers.

Because Ubuntu is already running inside VMware, using another VM-dependent Docker Desktop layer could require nested virtualization. When Docker becomes necessary, installing Docker Engine directly in the Ubuntu guest may be the simpler learning path, provided the Ubuntu version and VM configuration meet Docker's requirements.

I intentionally postponed Docker until backend development gives it a concrete purpose, such as running PostgreSQL alongside a Spring Boot application.

Current Developer Environment

Based on my report, the Ubuntu VM is prepared as a foundation for:

  • Java development.
  • Python development.
  • Linux practice.
  • Git and GitHub workflows.
  • Computer science coursework.
  • Future backend, database, container, and AI or machine-learning work.

This means the environment is no longer the main immediate bottleneck. Readiness for each area should still be demonstrated through small projects and reproducible checks.

Skills Gained

  • Virtualization fundamentals.
  • Ubuntu installation and virtual-machine management.
  • Linux command-line basics.
  • Package management with APT.
  • Development-tool installation.
  • Git and GitHub foundations.
  • SSH authentication.
  • GNOME customization.
  • Linux desktop troubleshooting.
  • Layered recovery concepts.
  • Disk and partition concepts.
  • Docker architecture fundamentals.

Planned Learning Path

  1. Practice Git and GitHub alongside every project.
  2. Learn Java fundamentals.
  3. Deepen Linux knowledge for development.
  4. Study data structures and algorithms.
  5. Learn SQL and PostgreSQL.
  6. Learn Docker through a real development need.
  7. Build backend applications with Spring Boot.
  8. Expand Python skills.
  9. Study artificial intelligence and machine learning.
  10. Learn deployment and cloud-development fundamentals.

Validation Record

Confirmed from authoritative documentation

  • Ubuntu's APT workflow and the meanings of update, upgrade, install, repositories, packages, and dependencies.
  • The purpose and feature set of VMware open-vm-tools, including desktop resizing, shared folders, clipboard operations, and drag and drop.
  • Timeshift's focus on system restoration rather than general personal-file backup.
  • Docker Engine support on Ubuntu and Docker Desktop's use of virtualization layers on macOS and Windows.

Checked but not executed

  • The listed Linux commands are valid commands.
  • The APT examples are syntactically valid when <package> is replaced.
  • The conceptual distinctions between a VMware snapshot, Timeshift, Git, and a remote repository are technically consistent.

User-reported and not independently verified

  • The exact VMware virtual-hardware allocation.
  • Installation and versions of the listed development tools.
  • Successful SSH authentication with GitHub.
  • The GNOME failure, its diagnosed cause, and its resolution.
  • Available disk space and the identity of the relevant partition.
  • Overall readiness of the environment for each future workload.

Sources

Operating system, virtualization, and desktop

Development tools

Recovery and storage

Containers and planned backend tools