TouchHLE: High-level Emulator for iPhone OS Apps

touchHLE: high-level emulator for iPhone OS apps

touchHLE is a high-level emulator (HLE) for iPhone OS apps. It runs on modern desktop operating systems, and is written in Rust.

As an HLE, touchHLE is radically different from a low-level emulator (LLE) like QEMU. The only code the emulated CPU executes is the app binary and a handful of libraries; touchHLE takes the place of iPhone OS and provides its own implementations of the system frameworks (Foundation, UIKit, OpenGL ES, OpenAL, etc).

The goal of this project is to run games from the early days of iOS. Only iPhone/iPod touch apps for iPhone OS 2.x have been tested so far. Modern/64-bit iOS app support is explicitly a non-goal, and support for apps that aren't games is unlikely to be prioritized due to the complexity. On the other hand, it's likely that we'll attempt to support apps for some newer 32-bit versions (especially 3.x and 4.x) and the iPad in future. iPhone OS 1.x support might be attempted also.

Visit our homepage! https://touchhle.org/

If you're curious about the history and motivation behind the project, you might want to read the original announcement.

Important disclaimer

This project is not affiliated with or endorsed by Apple Inc in any way. iPhone, iPhone OS, iOS, iPod, iPod touch and iPad may be trademarks of Apple Inc in the United States or other countries.

Only use touchHLE to emulate software you legally own.

Platform support

touchHLE has been tested and is to be considered supported on x64 Windows and x64 macOS. It may be possible to build it on Linux and on some AArch64 systems (at least one person has succeeded), but we make no guarantees right now. If you're an Apple Silicon Mac user: don't worry, the x64 macOS build reportedly works under Rosetta.

Architectures other than x64 and AArch64 are completely unsupported, and this is unlikely to change.

It would be desirable to eventually support Android. That is probably not too much work.

Input methods:

For simulated touch input, there are two options:
- Mouse/trackpad input (tap/hold/drag by pressing the left mouse button)
- Virtual cursor using the right analog stick on a game controller (tap/hold/drag by pressing the stick or the right shoulder button)
For simulated accelerometer input (tilt controls), a game controller with a left analog stick is currently required. Real accelerometer support will come soon, but it's not in the first release.

Development status

Real development started in December 2022, and this is so far a single person's full-time passion project. There's only a single release so far and no promises can be made about the future. Please be patient.

Currently, the supported functionality is not much more than what the single supported app uses. The code tries to be reasonably complete where it can, though.

App support

For pretty screenshots and video, check out the home page!

Super Monkey Ball (2008, App Store launch title), tested versions 1.0, 1.02, 1.3 (1.3 is the most heavily tested)
- Fully playable, everything works. Among other things:
  - Sound effects and music
  - Logo, title, menu, ranking, settings and credits screens
  - Main Game, Instant Game (Shuffle Play) and Practice game modes
  - Save game persistence (settings, unlocks, records)
  - Continuing a previous game after closing and reopening the app
  - The tutorial (in the versions that have it)
- Consistent full fps (30fps) in release builds even on a fairly underpowered laptop (2017 Retina MacBook, passively cooled!)
- Special enhancement: can be run with increased internal resolution via the --scale-hack= option. Resolutions up to circa 4K have been tested. No noticeable performance impact at small scales (2×, 3×).
- Recommended game controller settings: --y-tilt-offset=24
- Known issue: memory leak of approximately 0.2MB/second on macOS. All obvious issues in the emulator itself have been ruled out, so it might be a problem in macOS itself, SDL2, or some other dependency. Thankfully this is slow enough that it shouldn't be a problem for most play sessions.

No other apps are known to work right now. This will surely improve in future. :)

Usage

First obtain touchHLE, either a binary release or by building it yourself (see the next section).

You'll then need an app that you can run. See the “App support” section above. Note that the app binary must be decrypted to be usable.

There's no graphical user interface right now, so you'll usually need to use the command line to run touchHLE. For first-time users on Windows:

Move the .ipa file or .app bundle to the same folder as touchHLE.exe.
Hold the Shift key and Right-click on the empty space in the folder window.
Click “Open with PowerShell”.
You can then type .\touchHLE.exe "YourAppNameHere.ipa" (or .app as appropriate) and press enter.
You may want to type .\touchHLE.exe to see the available options for things like game controllers.

Currently language detection doesn't work on Windows. To change the language preference reported to the app, you can type SET LANG= followed by an ISO 639-1 language code, then press Enter, before running the app. Some common language codes are: en (English), de (Deutsch), es (español), fr (français), it (italiano) and ja (日本語). Bear in mind that it's the app itself that determines which languages are supported, not the emulator.

Any data saved by the app (e.g. saved games) are stored in the touchHLE_sandbox folder.

If the emulator crashes almost immediately while running a game listed as supported, please check whether you have any overlays turned on like the Steam overlay, Discord overlay, RivaTuner Statistics Server, etc. Sadly, as useful as these tools are, they work by injecting themselves into other apps or games and don't always clean up after themselves, so they can break touchHLE… it's not our fault. 😢 Currently only RivaTuner Statistics Server is known to be a problem. If you find another overlay that doesn't work, please tell us about it.

Building and contributing

Please see the BUILDING.md and CONTRIBUTING.md files in the git repo.

License

The source code of touchHLE itself (not its dependencies) is licensed under the Mozilla Public License, version 2.0.

Due to license compatibility concerns, binaries are under the GNU General Public License version 3 or later.

For a best effort listing of all licenses of dependencies, build touchHLE and pass the --copyright flag when running it.

Please note that different licensing terms apply to the bundled dynamic libraries (in touchHLE_dylibs/) and fonts (in touchHLE_fonts/). Please consult the respective directories for more information.

Thanks

We stand on the shoulders of giants. Thank you to:

The authors of and contributors to the many libraries used by this project: dynarmic, rust-macho, SDL, rust-sdl2, stb_image, openal-soft, hound, caf, RustType, the Liberation fonts, the Noto CJK fonts, rust-plist, gl-rs, cargo-license, cc-rs, cmake-rs, and the Rust standard library.
The Rust project generally.
The various people out there who've documented the iPhone OS platform, officially or otherwise. Much of this documentation is linked to within this codebase!
The iOS hacking/jailbreaking community.
The Free Software Foundation, for making libgcc and libstdc++ copyleft and therefore saving this project from ABI hell.
The National Security Agency of the United States of America, for Ghidra.
Many friends who took an interest in the project and gave suggestions and encouragement.
Developers of early iPhone OS apps. What treasures you created!
Apple, and NeXT before them, for creating such fantastic platforms.

Download Details:

Author: Hikari-no-yume
Source Code: https://github.com/hikari-no-yume/touchHLE
License: MPL-2.0 license

#rust #iphone #os #emulation

TouchHLE: High-level Emulator for iPhone OS Apps

Nigel Uys

1673855700

Docker-OSX: Run macOS VM in a Docker!

Docker-OSX ·

Run Mac OS X in Docker with near-native performance! X11 Forwarding! iMessage security research! iPhone USB working! macOS in a Docker container!

Conduct Security Research on macOS using both Linux & Windows!

Docker-OSX now has a Discord server & Telegram!

The Discord is active on docker-osx and anyone is welcome to come and ask questions, ideas, etc.

Quick Start Docker-OSX

Video setup tutorial is also available here: https://www.youtube.com/watch?v=wLezYl77Ll8

Windows users: click here to see the notes below!

First time here? try initial setup, otherwise try the instructions below to use either Catalina or Big Sur.

Any questions, ideas, or just want to hang out?

https://discord.gg/sickchat

Catalina

docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    sickcodes/docker-osx:latest

# docker build -t docker-osx .

Big Sur

docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    sickcodes/docker-osx:big-sur

# docker build -t docker-osx --build-arg SHORTNAME=big-sur .

Monterey


docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e GENERATE_UNIQUE=true \
    -e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist' \
    sickcodes/docker-osx:monterey

# docker build -t docker-osx --build-arg SHORTNAME=monterey .

Ventura


docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e GENERATE_UNIQUE=true \
    -e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist' \
    sickcodes/docker-osx:ventura

# docker build -t docker-osx --build-arg SHORTNAME=ventura .

Run Catalina Pre-Installed

# 40GB disk space required: 20GB original image 20GB your container.
docker pull sickcodes/docker-osx:auto

# boot directly into a real OS X shell with a visual display [NOT HEADLESS]
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e GENERATE_UNIQUE=true \
    sickcodes/docker-osx:auto

# username is user
# passsword is alpine

Older Systems

High Sierra


docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    sickcodes/docker-osx:high-sierra

# docker build -t docker-osx --build-arg SHORTNAME=high-sierra .

Mojave


docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    sickcodes/docker-osx:mojave

# docker build -t docker-osx --build-arg SHORTNAME=mojave .

Download the image manually and use it in Docker

This is a particularly good way for downloading the container, in case Docker's CDN (or your connection) happens to be slow.

wget https://images2.sick.codes/mac_hdd_ng_auto.img

docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v "${PWD}/mac_hdd_ng_auto.img:/image" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e GENERATE_UNIQUE=true \
    -e MASTER_PLIST_URL=https://raw.githubusercontent.com/sickcodes/Docker-OSX/master/custom/config-nopicker-custom.plist \
    sickcodes/docker-osx:naked

Use your own image and manually and automatically log into a shell

Enable SSH in network sharing inside the guest first. Change -e "USERNAME=user" and -e "PASSWORD=password" to your credentials. The container will add itself to ~/.ssh/authorized_keys

Since you can't see the screen, use the PLIST with nopicker, for example:

# Catalina
# wget https://images2.sick.codes/mac_hdd_ng_auto.img
# Monterey
wget https://images.sick.codes/mac_hdd_ng_auto_monterey.img

docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v "${PWD}/mac_hdd_ng_auto_monterey.img:/image" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e "USERNAME=user" \
    -e "PASSWORD=alpine" \
    -e GENERATE_UNIQUE=true \
    -e MASTER_PLIST_URL=https://raw.githubusercontent.com/sickcodes/Docker-OSX/master/custom/config-nopicker-custom.plist \
    sickcodes/docker-osx:naked-auto

Share directories, sharing files, shared folder, mount folder

The easiest and most secure way is sshfs

# on Linux/Windows
mkdir ~/mnt/osx
sshfs user@localhost:/ -p 50922 ~/mnt/osx
# wait a few seconds, and ~/mnt/osx will have full rootfs mounted over ssh, and in userspace
# automated: sshpass -p <password> sshfs user@localhost:/ -p 50922 ~/mnt/osx

(VFIO) iPhone USB passthrough (VFIO)

If you have a laptop see the next usbfluxd section.

If you have a desktop PC, you can use @Silfalion's instructions : https://github.com/Silfalion/Iphone_docker_osx_passthrough

(USBFLUXD) iPhone USB -> Network style passthrough OSX-KVM Docker-OSX

Video setup tutorial for usbfluxd is also available here: https://www.youtube.com/watch?v=kTk5fGjK_PM

This method WORKS on laptop, PC, anything!

Thank you @nikias for usbfluxd via https://github.com/corellium!

This is done inside Linux.

Open 3 terminals on Linux

Connecting your device over USB on Linux allows you to expose usbmuxd on port 5000 using https://github.com/corellium/usbfluxd to another system on the same network.

Ensure usbmuxd, socat and usbfluxd are installed.

sudo pacman -S libusbmuxd usbmuxd avahi socat

Available on the AUR: https://aur.archlinux.org/packages/usbfluxd/

yay usbfluxd

Plug in your iPhone or iPad.

Terminal 1

sudo systemctl start usbmuxd
sudo avahi-daemon

Terminal 2:

# on host
sudo systemctl restart usbmuxd
sudo socat tcp-listen:5000,fork unix-connect:/var/run/usbmuxd

Terminal 3:

sudo usbfluxd -f -n

Connect to a host running usbfluxd

This is done inside macOS.

Install homebrew.

172.17.0.1 is usually the Docker bridge IP, which is your PC, but you can use any IP from ip addr...

macOS Terminal:

# on the guest
brew install make automake autoconf libtool pkg-config gcc libimobiledevice usbmuxd

git clone https://github.com/corellium/usbfluxd.git
cd usbfluxd

./autogen.sh
make
sudo make install

Accept the USB over TCP connection, and appear as local:

(you may need to change 172.17.0.1 to the IP address of the host. e.g. check ip addr)

# on the guest
sudo launchctl start usbmuxd
export PATH=/usr/local/sbin:${PATH}
sudo usbfluxd -f -r 172.17.0.1:5000

Close apps such as Xcode and reopen them and your device should appear!

If you need to start again on Linux, wipe the current usbfluxd, usbmuxd, and socat:

sudo killall usbfluxd
sudo systemctl restart usbmuxd
sudo killall socat

Make container FASTER using https://github.com/sickcodes/osx-optimizer

SEE commands in https://github.com/sickcodes/osx-optimizer!

Skip the GUI login screen (at your own risk!)
Disable spotlight indexing on macOS to heavily speed up Virtual Instances.
Disable heavy login screen wallpaper
Disable updates (at your own risk!)

Increase disk space by moving /var/lib/docker to external drive, block storage, NFS, or any other location conceivable.

Move /var/lib/docker, following the tutorial below

Cheap large physical disk storage instead using your server's disk, or SSD.
Block Storage, NFS, etc.

Tutorial here: https://sick.codes/how-to-run-docker-from-block-storage/

Only follow the above tutorial if you are happy with wiping all your current Docker images/layers.

Safe mode: Disable docker temporarily so you can move the Docker folder temporarily.

Do NOT do this until you have moved your image out already https://github.com/dulatello08/Docker-OSX/#quick-start-your-own-image-naked-container-image

killall dockerd
systemctl disable --now docker
systemctl disable --now docker.socket
systemctl stop docker
systemctl stop docker.socket

Now, that Docker daemon is off, move /var/lib/docker somewhere

Then, symbolicly link /var/lib/docker somewhere:

mv /var/lib/docker /run/media/user/some_drive/docker
ln -s /run/media/user/some_drive/docker /var/lib/docker

# now check if /var/lib/docker is working still
ls /var/lib/docker

If you see folders, then it worked. You can restart Docker, or just reboot if you want to be sure.

Important notices:

2021-11-14 - Added High Sierra, Mojave

Pick one of these while building, irrelevant when using docker pull:

--build-arg SHORTNAME=high-sierra 
--build-arg SHORTNAME=mojave
--build-arg SHORTNAME=catalina
--build-arg SHORTNAME=big-sur
--build-arg SHORTNAME=monterey
--build-arg SHORTNAME=ventura

Technical details

There currently multiple images, each with different use cases (explained below):

High Sierra
Mojave
Catalina
Big Sur
Monterey
Ventura
Auto (pre-made Catalina)
Naked (use your own .img)
Naked-Auto (user your own .img and SSH in)

High Sierra:

Mojave:

Catalina:

Big-Sur:

Monterey make your own image:

Pre-made Catalina system by Sick.Codes: username: user, password: alpine

Naked: Bring-your-own-image setup (use any of the above first):

Naked Auto: same as above but with -e USERNAME & -e PASSWORD and -e OSX_COMMANDS="put your commands here"

Capabilities

use iPhone OSX KVM on Linux using usbfluxd!
macOS Monterey VM on Linux!
Folder sharing-
USB passthrough (hotplug too)
SSH enabled (localhost:50922)
VNC enabled (localhost:8888) if using ./vnc version
iMessage security research via serial number generator!
X11 forwarding is enabled
runs on top of QEMU + KVM
supports Big Sur, custom images, Xvfb headless mode
you can clone your container with docker commit

Requirements

20GB+++ disk space for bare minimum installation (50GB if using Xcode)
virtualization should be enabled in your BIOS settings
a x86_64 kvm-capable host
at least 50 GBs for :auto (half for the base image, half for your runtime image

TODO

documentation for security researchers
gpu acceleration
support for virt-manager

Docker

Images built on top of the contents of this repository are also available on Docker Hub for convenience: https://hub.docker.com/r/sickcodes/docker-osx

A comprehensive list of the available Docker images and their intended purpose can be found in the Instructions.

Kubernetes

Docker-OSX supports Kubernetes.

Kubernetes Helm Chart & Documentation can be found under the helm directory.

Thanks cephasara for contributing this major contribution.

Support

Small questions & issues

Feel free to open an issue, should you come across minor issues with running Docker-OSX or have any questions.

Resolved issues

Before you open an issue, however, please check the closed issues and confirm that you're using the latest version of this repository — your issues may have already been resolved! You might also see your answer in our questions and answers section below.

Feature requests and updates

Follow @sickcodes!

Professional support

For more sophisticated endeavours, we offer the following support services:

Enterprise support, business support, or casual support.
Custom images, custom scripts, consulting (per hour available!)
One-on-one conversations with you or your development team.

In case you're interested, contact @sickcodes on Twitter or click here.

License/Contributing

Docker-OSX is licensed under the GPL v3+. Contributions are welcomed and immensely appreciated. You are in-fact permitted to use Docker-OSX as a tool to create proprietary software.

Other cool Docker/QEMU based projects

Disclaimer

If you are serious about Apple Security, and possibly finding 6-figure bug bounties within the Apple Bug Bounty Program, then you're in the right place! Further notes: Is Hackintosh, OSX-KVM, or Docker-OSX legal?

Product names, logos, brands and other trademarks referred to within this project are the property of their respective trademark holders. These trademark holders are not affiliated with our repository in any capacity. They do not sponsor or endorse this project in any way.

Instructions

Container images

Already set up or just looking to make a container quickly? Check out our quick start or see a bunch more use cases under our container creation examples section.

There are several different Docker-OSX images available which are suitable for different purposes.

sickcodes/docker-osx:latest - I just want to try it out.
sickcodes/docker-osx:latest - I want to use Docker-OSX to develop/secure apps in Xcode (sign into Xcode, Transporter)
sickcodes/docker-osx:naked - I want to use Docker-OSX for CI/CD-related purposes (sign into Xcode, Transporter)

Create your personal image using :latest or big-sur. Then, pull the image out the image. Afterwards, you will be able to duplicate that image and import it to the :naked container, in order to revert the container to a previous state repeatedly.

sickcodes/docker-osx:auto - I'm only interested in using the command line (useful for compiling software or using Homebrew headlessly).

sickcodes/docker-osx:naked - I need iMessage/iCloud for security research.

sickcodes/docker-osx:big-sur - I want to run Big Sur.

sickcodes/docker-osx:monterey - I want to run Monterey.

sickcodes/docker-osx:ventura - I want to run Ventura.

sickcodes/docker-osx:high-sierra - I want to run High Sierra.

sickcodes/docker-osx:mojave - I want to run Mojave.

Initial setup

Before you do anything else, you will need to turn on hardware virtualization in your BIOS. Precisely how will depend on your particular machine (and BIOS), but it should be straightforward.

Then, you'll need QEMU and some other dependencies on your host:

# ARCH
sudo pacman -S qemu libvirt dnsmasq virt-manager bridge-utils flex bison iptables-nft edk2-ovmf

# UBUNTU DEBIAN
sudo apt install qemu qemu-kvm libvirt-clients libvirt-daemon-system bridge-utils virt-manager libguestfs-tools

# CENTOS RHEL FEDORA
sudo yum install libvirt qemu-kvm

Then, enable libvirt and load the KVM kernel module:

sudo systemctl enable --now libvirtd
sudo systemctl enable --now virtlogd

echo 1 | sudo tee /sys/module/kvm/parameters/ignore_msrs

sudo modprobe kvm

I'd like to run Docker-OSX on Windows

Running Docker-OSX on Windows is possible using WSL2 (Windows 11 + Windows Subsystem for Linux).

You must have Windows 11 installed with build 22000+ (21H2 or higher).

First, install WSL on your computer by running this command in an administrator powershell. For more info, look here.

This will install Ubuntu by default.

wsl --install

You can confirm WSL2 is enabled using wsl -l -v in PowerShell. To see other distributions that are available, use wsl -l -o.

If you have previously installed WSL1, upgrade to WSL 2. Check this link to upgrade from WSL1 to WSL2.

After WSL installation, go to C:/Users/<Your_Name>/.wslconfig and add nestedVirtualization=true to the end of the file (If the file doesn't exist, create it). For more information about the .wslconfig file check this link. Verify that you have selected "Show Hidden Files" and "Show File Extensions" in File Explorer options. The result should be like this:

[wsl2]
nestedVirtualization=true

Go into your WSL distro (Run wsl in powershell) and check if KVM is enabled by using the kvm-ok command. The output should look like this:

INFO: /dev/kvm exists
KVM acceleration can be used

Now download and install Docker for Windows if it is not already installed.

After installation, go into Settings and check these 2 boxes:

General -> "Use the WSL2 based engine";
Resources -> WSL Integration -> "Enable integration with my default WSL distro",

Ensure x11-apps is installed. Use the command sudo apt install x11-apps -y to install it if it isn't.

Finally, there are 3 ways to get video output:

WSLg: This is the simplest and easiest option to use. There may be some issues such as the keyboard not being fully passed through or seeing a second mouse on the desktop - Issue on WSLg - but this option is recommended.

To use WSLg's built-in X-11 server, change these two lines in the docker run command to point Docker-OSX to WSLg.

-e "DISPLAY=${DISPLAY:-:0.0}" \
-v /mnt/wslg/.X11-unix:/tmp/.X11-unix \

Or try:

-e "DISPLAY=${DISPLAY:-:0}" \
-v /mnt/wslg/.X11-unix:/tmp/.X11-unix \

For Ubuntu 20.x on Windows, see https://github.com/sickcodes/Docker-OSX/discussions/458

VNC: See the VNC section for more information. You could also add -vnc argument to qemu. Connect to your mac VM via a VNC Client. Here is a how to
Desktop Environment: This will give you a full desktop linux experience but it will use a bit more of the computer's resources. Here is an example guide, but there are other guides that help set up a desktop environment. DE Example

Additional boot instructions for when you are creating your container

Boot the macOS Base System (Press Enter)

Click Disk Utility

Erase the BIGGEST disk (around 200gb default), DO NOT MODIFY THE SMALLER DISKS.

-- if you can't click erase, you may need to reduce the disk size by 1kb

(optional) Create a partition using the unused space to house the OS and your files if you want to limit the capacity. (For Xcode 12 partition at least 60gb.)

Click Reinstall macOS

The system may require multiple reboots during installation

Troubleshooting

Routine checks

This is a great place to start if you are having trouble getting going, especially if you're not that familiar with Docker just yet.

Just looking to make a container quickly? Check out our container creation examples section.

More specific/advanced troubleshooting questions and answers may be found in More Questions and Answers. You should also check out the closed issues. Someone else might have gotten a question like yours answered already even if you can't find it in this document!

Confirm that your CPU supports virtualization

See initial setup.

Docker Unknown Server OS error

docker: unknown server OS: .
See 'docker run --help'.

This means your docker daemon is not running.

pgrep dockerd should return nothing

Therefore, you have a few choices.

sudo dockerd for foreground Docker usage. I use this.

sudo systemctl --start dockerd to start dockerd this now.

sudo systemctl --enable --now dockerd for start dockerd on every reboot, and now.

Use more CPU Cores/SMP

Examples:

-e EXTRA='-smp 6,sockets=3,cores=2'

-e EXTRA='-smp 8,sockets=4,cores=2'

-e EXTRA='-smp 16,sockets=8,cores=2'

Note, unlike memory, CPU usage is shared. so you can allocate all of your CPU's to the container.

Confirm your user is part of the the Docker group, KVM group, libvirt group

Add yourself to the Docker group

If you use sudo dockerd or dockerd is controlled by systemd/systemctl, then you must be in the Docker group. If you are not in the Docker group:

sudo usermod -aG docker "${USER}"

and also add yourself to the kvm and libvirt groups if needed:

sudo usermod -aG libvirt "${USER}"
sudo usermod -aG kvm "${USER}"

Is the docker daemon enabled?

# run ad hoc
sudo dockerd

# or daemonize it
sudo nohup dockerd &

# enable it in systemd (it will persist across reboots this way)
sudo systemctl enable --now docker

# or just start it as your user with systemd instead of enabling it
systemctl start docker

Share folder with Docker-OSX QEMU macOS

Sharing a folder with guest is quite simple.

Your folder, will go to /mnt/hostshare inside the Arch container which is then passed over QEMU.

Then mount using sudo -S mount_9p hostshare from inside the mac.

For example,

FOLDER=~/somefolder

    -v "${FOLDER}:/mnt/hostshare" \
    -e EXTRA="-virtfs local,path=/mnt/hostshare,mount_tag=hostshare,security_model=passthrough,id=hostshare" \

Full example:

# stat mac_hdd_ng.img
SHARE=~/somefolder

docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -v "${PWD}/mac_hdd_ng.img:/home/arch/OSX-KVM/mac_hdd_ng.img" \
    -v "${SHARE}:/mnt/hostshare" \
    -e EXTRA="-virtfs local,path=/mnt/hostshare,mount_tag=hostshare,security_model=passthrough,id=hostshare" \
    sickcodes/docker-osx:latest

# !!! Open Terminal inside macOS and run the following command to mount the virtual file system
# sudo -S mount_9p hostshare

Share Linux NFS Drive into macOS

To share a folder using NFS, setup a folder for on the host machine, for example, /srv/nfs/share and then append to /etc/exports:

/srv/nfs/share      127.0.0.1/0(insecure,rw,all_squash,anonuid=1000,anongid=985,no_subtree_check)

You may need to reload exports now, which will begin sharing that directory.

# reload shared folders
sudo exportfs -arv

Source & Explanation

Give permissions on the shared folder for the anonuid and anongid, where anonuid and anongid matches that of your linux user; id -u

id -u ; id -g will print userid:groupid

chown 1000:985 /srv/nfs/share
chmod u+rwx /srv/nfs/share

Start the Docker-OSX container with the additional flag --network host

Create and mount the nfs folder from the mac terminal:

mkdir -p ~/mnt
sudo mount_nfs -o locallocks 10.0.2.2:/srv/nfs/share ~/mnt

Share USB Drive into macOS over QEMU

Mount USB Drive (Hotplug/Hot Plug USB)

Start your container.

Pick a port, for example, 7700.

lsusb to get vid:pid

On Linux: sudo usbredirserver -p 7700 1e3d:2096

Now, in the Docker window hit Enter to see the (qemu) console.

You can add/remove the disk using commands like this, even once the machine is started:

chardev-add socket,id=usbredirchardev1,port=7700,host=172.17.0.1

device_add usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4

Mount USB Drive inside macOS at boot Docker OSX

PORT=7700
IP_ADDRESS=172.17.0.1

-e EXTRA="-chardev socket,id=usbredirchardev1,port=${PORT},host=${IP_ADDRESS} -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4" \`

Fedora: enable internet connectivity with a bridged network

Fedora's default firewall settings may prevent Docker's network interface from reaching the internet. In order to reoslve this, you will need to whitelist the interface in your firewall:

# Set the docker0 bridge to the trusted zone
sudo firewall-cmd --permanent --zone=trusted --add-interface=docker0
sudo firewall-cmd --reload

Nested Hardware Virtualization

Check if your machine has hardware virtualization enabled:

sudo tee /sys/module/kvm/parameters/ignore_msrs <<< 1

egrep -c '(svm|vmx)' /proc/cpuinfo

Virtual network adapters

Fast internet connectivity

-e NETWORKING=vmxnet3

Slow internet connectivity

-e NETWORKING=e1000-82545em

CI/CD Related Improvements

Tips for reducing the size of the image

Start the container as usual, and remove unnecessary files. A useful way to do this is to use du -sh * starting from the / directory, and find large directories where files can be removed. E.g. unnecessary cached files, Xcode platforms, etc.
Once you are satisfied with the amount of free space, enable trim with sudo trimforce enable, and reboot.
Zero out the empty space on the disk with dd if=/dev/zero of=./empty && rm -f empty
Shut down the VM and copy out the qcow image with docker cp stoppedcontainer:/home/arch/OSX-KVM/mac_hdd_ng.img .
Run qemu-img check -r all mac_hdd_ng.img to fix any errors.
Run qemu-img convert -O qcow2 mac_hdd_ng.img deduped.img and check for errors again
OPTIONAL: Run qemu-img convert -c -O qcow2 deduped.img compressed.img to further compress the image. This may reduce the runtime speed though, but it should reduce the size by roughly 25%.
Check for errors again, and build a fresh docker image. E.g. with this Dockerfile

FROM sickcodes/docker-osx
USER arch
COPY --chown=arch ./deduped.img /home/arch/OSX-KVM/mac_hdd_ng.img

Run Docker-OSX headlessly with Telnet

First make sure autoboot is enabled

Next, you will want to set up SSH to be automatically started.

sudo systemsetup -setremotelogin on

Make sure to commit the new docker image and save it, or rebuild as described in the section on reducing disk space.

Then run it with these arguments.

# Run with the -nographic flag, and enable a telnet interface
  docker run \
    --device /dev/kvm \
    -p 50922:10022 \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e EXTRA="-monitor telnet::45454,server,nowait -nographic -serial null" \
    mycustomimage

What mirrors are appropriate to use to build Docker-OSX locally?

If you are building Docker-OSX locally, you'll probably want to use Arch Linux's mirrors.

Mirror locations can be found here (uses two-letter country codes): https://archlinux.org/mirrorlist/all/

docker build -t docker-osx:latest \
    --build-arg RANKMIRRORS=true \
    --build-arg MIRROR_COUNTRY=US \
    --build-arg MIRROR_COUNT=10 \
    --build-arg SHORTNAME=catalina \
    --build-arg SIZE=200G .

Custom QEMU Arguments (passthrough devices)

Pass any devices/directories to the Docker container & the QEMU arguments using the handy runtime argument provider option -e EXTRA=.

# example customizations
docker run \
    -e RAM=4 \
    -e SMP=4 \
    -e CORES=4 \
    -e EXTRA='-usb -device usb-host,hostbus=1,hostaddr=8' \
    -e INTERNAL_SSH_PORT=23 \
    -e MAC_ADDRESS="$(xxd -c1 -p -l 6 /dev/urandom | tr '\n' ':' | cut -c1-17)" \
    -e AUDIO_DRIVER=alsa \
    -e IMAGE_PATH=/image \
    -e SCREEN_SHARE_PORT=5900 \
    -e DISPLAY=:0 \
    -e NETWORKING=vmxnet3 \
    --device /dev/kvm \
    --device /dev/snd \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    docker-osx:latest

Generating serial numbers

Generate serial numbers in ./custom OR make docker generate them at runtime (see below).

At any time, verify your serial number before logging into iCloud, etc.

# this is a quick way to check your serial number via cli inside OSX
ioreg -l | grep IOPlatformSerialNumber

# test some commands
sshpass -p 'alpine' ssh user@localhost -p 50922 'ping google.com'

# check your serial number
sshpass -p 'alpine' ssh user@localhost -p 50922 'ioreg -l | grep IOPlatformSerialNumber'

Getting started with serial numbers

# ARCH
pacman -S libguestfs

# UBUNTU DEBIAN
apt install libguestfs -y

# RHEL FEDORA CENTOS
yum install libguestfs -y

Inside the ./custom folder you will find 4 scripts.

config-nopicker-custom.plist
opencore-image-ng.sh

These two files are from OSX-KVM.

You don't need to touch these two files.

The config.plist has 5 values replaced with placeholders. Click here to see those values for no reason.

generate-unique-machine-values.sh This script will generate serial numbers, with Mac Addresses, plus output to CSV/TSV, plus make a bootdisk image.

You can create hundreds, ./custom/generate-unique-machine-values.sh --help

./custom/generate-unique-machine-values.sh \
    --count 1 \
    --tsv ./serial.tsv \
    --bootdisks \
    --output-bootdisk OpenCore.qcow2 \
    --output-env source.env.sh

Or if you have some specific serial numbers...

generate-specific-bootdisk.sh

This example generates a random set of serial numbers at runtime, headlessly

# proof of concept only, generates random serial numbers, headlessly, and quits right after.
docker run --rm -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -e NOPICKER=true \
    -e GENERATE_UNIQUE=true \
    -e DEVICE_MODEL="iMacPro1,1" \
    sickcodes/docker-osx:auto

# -e OSX_COMMANDS='ioreg -l | grep IOPlatformSerialNumber' \

This example generates a specific set of serial numbers at runtime

# run the same as above 17gb auto image, with SSH, with nopicker, and save the bootdisk for later.
# you don't need to save the bootdisk IF you supply specific serial numbers!

docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -e NOPICKER=true \
    -e GENERATE_SPECIFIC=true \
    -e DEVICE_MODEL="iMacPro1,1" \
    -e SERIAL="C02TW0WAHX87" \
    -e BOARD_SERIAL="C027251024NJG36UE" \
    -e UUID="5CCB366D-9118-4C61-A00A-E5BAF3BED451" \
    -e MAC_ADDRESS="A8:5C:2C:9A:46:2F" \
    -e OSX_COMMANDS='ioreg -l | grep IOPlatformSerialNumber' \
    sickcodes/docker-osx:auto

This example generates a specific set of serial numbers at runtime, with your existing image, at 1000x1000 display resolution

# run an existing image in current directory, with a screen, with SSH, with nopicker.

stat mac_hdd_ng.img # make sure you have an image if you're using :naked

docker run -it \
    -v "${PWD}/mac_hdd_ng.img:/image" \
    --device /dev/kvm \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -p 50922:10022 \
    -e NOPICKER=true \
    -e GENERATE_SPECIFIC=true \
    -e DEVICE_MODEL="iMacPro1,1" \
    -e SERIAL="C02TW0WAHX87" \
    -e BOARD_SERIAL="C027251024NJG36UE" \
    -e UUID="5CCB366D-9118-4C61-A00A-E5BAF3BED451" \
    -e MAC_ADDRESS="A8:5C:2C:9A:46:2F" \
    -e WIDTH=1000 \
    -e HEIGHT=1000 \
    sickcodes/docker-osx:naked

If you want to generate serial numbers, either make them at runtime using -e GENERATE_UNIQUE=true \

Or you can generate them inside the ./custom folder. And then use:

    -e GENERATE_SPECIFIC=true \
    -e SERIAL="" \
    -e BOARD_SERIAL="" \
    -e UUID="" \
    -e MAC_ADDRESS="" \

Making serial numbers persist across reboots


stat mac_hdd_ng_testing.img
touch ./output.env

# generate fresh random serial numbers, with a screen, using your own image, and save env file with your new serial numbers for later.

docker run -it \
    --device /dev/kvm \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -p 50922:10022 \
    -e NOPICKER=true \
    -e GENERATE_UNIQUE=true \
    -e GENERATE_SPECIFIC=true \
    -e DEVICE_MODEL="iMacPro1,1" \
    -v "${PWD}/output.env:/env" \
    -v "${PWD}/mac_hdd_ng_testing.img:/image" \
    sickcodes/docker-osx:naked

To use iMessage or iCloud you need to change 5 values.

SERIAL
BOARD_SERIAL
UUID
MAC_ADDRESS

ROM is just the lowercased mac address, without : between each word.

You can tell the container to generate them for you using -e GENERATE_UNIQUE=true

Or tell the container to use specific ones using -e GENERATE_SPECIFIC=true

    -e GENERATE_SPECIFIC=true \
    -e DEVICE_MODEL="iMacPro1,1" \
    -e SERIAL="C02TW0WAHX87" \
    -e BOARD_SERIAL="C027251024NJG36UE" \
    -e UUID="5CCB366D-9118-4C61-A00A-E5BAF3BED451" \
    -e MAC_ADDRESS="A8:5C:2C:9A:46:2F" \

Changing display resolution

The display resolution is controlled by this line:

https://github.com/sickcodes/Docker-OSX/blob/master/custom/config-nopicker-custom.plist#L819

Instead of mounting that disk, Docker-OSX will generate a new OpenCore.qcow2 by using this one cool trick:

-e GENERATE_UNIQUE=true \
-e WIDTH=800 \
-e HEIGHT=600 \

To use WIDTH/HEIGHT, you must use with either -e GENERATE_UNIQUE=true or -e GENERATE_SPECIFIC=true.

It will take around 30 seconds longer to boot because it needs to make a new boot partition using libguestfs.

-e GENERATE_SPECIFIC=true \
-e WIDTH=1920 \
-e HEIGHT=1080 \
-e SERIAL="" \
-e BOARD_SERIAL="" \
-e UUID="" \
-e MAC_ADDRESS="" \

Change Docker-OSX Resolution Examples

# using an image in your current directory
stat mac_hdd_ng.img

docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v "${PWD}/mac_hdd_ng.img:/image" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e GENERATE_SPECIFIC=true \
    -e DEVICE_MODEL="iMacPro1,1" \
    -e SERIAL="C02TW0WAHX87" \
    -e BOARD_SERIAL="C027251024NJG36UE" \
    -e UUID="5CCB366D-9118-4C61-A00A-E5BAF3BED451" \
    -e MAC_ADDRESS="A8:5C:2C:9A:46:2F" \
    -e MASTER_PLIST_URL=https://raw.githubusercontent.com/sickcodes/Docker-OSX/master/custom/config-nopicker-custom.plist \
    -e WIDTH=1600 \
    -e HEIGHT=900 \
    sickcodes/docker-osx:naked

# generating random serial numbers, using the DIY installer, along with the screen resolution changes.
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e GENERATE_UNIQUE=true \
    -e WIDTH=800 \
    -e HEIGHT=600 \
    sickcodes/docker-osx:latest

Here's a few other resolutions! If you resolution is invalid, it will default to 800x600.

    -e WIDTH=800 \
    -e HEIGHT=600 \

    -e WIDTH=1280 \
    -e HEIGHT=768 \

    -e WIDTH=1600 \
    -e HEIGHT=900 \

    -e WIDTH=1920 \
    -e HEIGHT=1080 \

    -e WIDTH=2560 \
    -e HEIGHT=1600 \

This example shows how to change resolution after the container is created.

First step is to stop the docker daemon

sudo systemctl stop docker

The second step is to change container config in

/var/lib/docker/containers/[container-id]/config.v2.json

(Suppose your original WIDTH is 1024 and HEIGHT is 768, you can search 1024 and replace it with the new value. Same for 768.)

The last step is to restart the docker daemon

sudo systemctl restart docker

Mounting physical disks in Mac OSX

Pass the disk into the container as a volume and then pass the disk again into QEMU command line extras with.

Use the config-custom.plist because you probably want to see the boot menu, otherwise omit the first line:

DISK_TWO="${PWD}/mount_me.img"

-e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist' \
-v "${DISK_TWO}:/disktwo" \
-e EXTRA='-device ide-hd,bus=sata.5,drive=DISK-TWO -drive id=DISK-TWO,if=none,file=/disktwo,format=qcow2' \

Physical disk mounting example

OSX_IMAGE="${PWD}/mac_hdd_ng_xcode_bigsur.img"
DISK_TWO="${PWD}/mount_me.img"

docker run -it \
    --device /dev/kvm \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist' \
    -v "${OSX_IMAGE}":/image \
    -v "${DISK_TWO}":/disktwo \
    -e EXTRA='-device ide-hd,bus=sata.5,drive=DISK-TWO -drive id=DISK-TWO,if=none,file=/disktwo,format=qcow2' \
    sickcodes/docker-osx:naked

Extracting the APFS disk on Linux

In Docker-OSX, we are using qcow2 images.

This means the image grows as you use it, but the guest OS thinks you have 200GB available.

READ ONLY

# mount the qemu image like a real disk
sudo modprobe nbd max_part=8
sudo qemu-nbd --connect=/dev/nbd0 ./image.img
sudo fdisk /dev/nbd0 -l

mkdir -p ./mnt
sudo mount /dev/nbd0p1 ./mnt

# inspect partitions (2 partitions)
sudo fdisk /dev/nbd0 -l

# mount using apfs-linux-rw OR apfs-fuse
mkdir -p ./part

sudo mount /dev/nbd0p2 ./part
sudo apfs-fuse -o allow_other /dev/nbd0p2 ./part

When you are finishing looking at your disk, you can unmount the partition, the disk, and remove the loopback device:

sudo umount ./part
sudo umount ./mnt
sudo qemu-nbd --disconnect /dev/nbd0
sudo rmmod nbd

USB Passthrough

Firstly, QEMU must be started as root.

It is also potentially possible to accomplish USB passthrough by changing the permissions of the device in the container. See here.

For example, create a new Dockerfile with the following

FROM sickcodes/docker-osx
USER arch
RUN sed -i -e s/exec\ qemu/exec\ sudo\ qemu/ ./Launch.sh
COPY --chown=arch ./new_image.img /home/arch/OSX-KVM/mac_hdd_ng.img

Where new_image.img is the qcow2 image you extracted. Then rebuild with docker build .

Next we need to find out the bus and port numbers of the USB device we want to pass through to the VM:

lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 2: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 5, If 1, Class=Chip/SmartCard, Driver=, 12M
    |__ Port 3: Dev 2, If 0, Class=Wireless, Driver=, 12M
    |__ Port 3: Dev 2, If 1, Class=Wireless, Driver=, 12M
    |__ Port 5: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 5: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M

In this example, we want to pass through a smartcard device. The device we want is on bus 1 and port 2.

There may also be differences if your device is usb 2.0 (ehci) vs usb 3.0 (xhci). See here for more details.

# hostbus and hostport correspond to the numbers from lsusb
# runs in privileged mode to enable access to the usb devices.
docker run \
  --privileged \
  --device /dev/kvm \
  -e RAM=4 \
  -p 50922:10022 \
  -e "DISPLAY=${DISPLAY:-:0.0}" \
  -e EXTRA="-device virtio-serial-pci -device usb-host,hostbus=1,hostport=2" \
  mycustomimage

You should see the device show up when you do system_profiler SPUSBDataType in the MacOS shell.

Important Note: this will cause the host system to lose access to the USB device while the VM is running!

Container creation examples

Quick Start your own image (naked container image)

This is my favourite container. You can supply an existing disk image as a Docker command line argument.

Pull images out using sudo find /var/lib/docker -size +10G | grep mac_hdd_ng.img

Supply your own local image with the command argument -v "${PWD}/mac_hdd_ng.img:/image" and use sickcodes/docker-osx:naked when instructing Docker to create your container.

Naked image is for booting any existing .img file, e.g in the current working directory ($PWD)

By default, this image has a variable called NOPICKER which is "true". This skips the disk selection menu. Use -e NOPICKER=false or any other string than the word true to enter the boot menu.

This lets you use other disks instead of skipping the boot menu, e.g. recovery disk or disk utility.

docker pull sickcodes/docker-osx:naked

# run your own image + SSH
# change mac_hdd_ng.img
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v "${PWD}/mac_hdd_ng.img:/image" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    sickcodes/docker-osx:naked

# run local copy of the auto image + SSH + Boot menu
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v "${PWD}/mac_hdd_ng_auto.img:/image" \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e "NOPICKER=false" \
    sickcodes/docker-osx:naked

Building an OSX container with video output

The Quick Start command should work out of the box, provided that you keep the following lines. Works in auto & naked machines:

    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \

Prebuilt image with arbitrary command line arguments

-e OSX_COMMANDS lets you run any commands inside the container

docker pull sickcodes/docker-osx:auto

# boot to OS X shell + display + specify commands to run inside OS X!
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e "OSX_COMMANDS=/bin/bash -c \"put your commands here\"" \
    sickcodes/docker-osx:auto

# Boots in a minute or two!

OR if you have an image already and just want to log in and execute arbitrary commands:

docker pull sickcodes/docker-osx:naked-auto

# boot to OS X shell + display + specify commands to run inside OS X!
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e USERNAME=yourusername \
    -e PASSWORD=yourpassword \
    -e "OSX_COMMANDS=/bin/bash -c \"put your commands here\"" \
    sickcodes/docker-osx:naked-auto

# Boots in a minute or two!

Further examples

There's a myriad of other potential use cases that can work perfectly with Docker-OSX, some of which you'll see below!

Building a headless OSX container

For a headless container, remove the following two lines from your docker run command:

    # -v /tmp/.X11-unix:/tmp/.X11-unix \
    # -e "DISPLAY=${DISPLAY:-:0.0}" \

Building a headless container from a custom image

This is particularly helpful for CI/CD pipelines.

# run your own image headless + SSH
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v "${PWD}/mac_hdd_ng.img:/image" \
    sickcodes/docker-osx:naked

Building a headless container which allows insecure VNC on localhost (!for local use only!)

Must change -it to -i to be able to interact with the QEMU console

To exit a container using -i you must docker kill <containerid>. For example, to kill everything, docker ps | xargs docker kill.

Native QEMU VNC example

docker run -i \
    --device /dev/kvm \
    -p 50922:10022 \
    -p 5999:5999 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e EXTRA="-display none -vnc 0.0.0.0:99,password=on" \
    sickcodes/docker-osx:big-sur

# type `change vnc password myvncusername` into the docker terminal and set a password
# connect to localhost:5999 using VNC
# qemu 6 seems to require a username for vnc now

NOT TLS/HTTPS Encrypted at all!

Or ssh -N root@1.1.1.1 -L 5999:127.0.0.1:5999, where 1.1.1.1 is your remote server IP.

(Note: if you close port 5999 and use the SSH tunnel, this becomes secure.)

Building a headless container to run remotely with secure VNC

Add the following line:

-e EXTRA="-display none -vnc 0.0.0.0:99,password=on"

In the Docker terminal, press enter until you see (qemu).

Type change vnc password someusername

Enter a password for your new vnc username^.

You also need the container IP: docker inspect <containerid> | jq -r '.[0].NetworkSettings.IPAddress'

Or ip n will usually show the container IP first.

Now VNC connect using the Docker container IP, for example 172.17.0.2:5999

Remote VNC over SSH: ssh -N root@1.1.1.1 -L 5999:172.17.0.2:5999, where 1.1.1.1 is your remote server IP and 172.17.0.2 is your LAN container IP.

Now you can direct connect VNC to any container built with this command!

I'd like to use SPICE instead of VNC

Optionally, you can enable the SPICE protocol, which allows use of remote-viewer to access your OSX container rather than VNC.

Note: -disable-ticketing will allow unauthenticated access to the VM. See the spice manual for help setting up authenticated access ("Ticketing").

  docker run \
    --device /dev/kvm \
    -p 3001:3001 \
    -p 50922:10022 \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    -e EXTRA="-monitor telnet::45454,server,nowait -nographic -serial null -spice disable-ticketing,port=3001" \
    mycustomimage

Then simply do remote-viewer spice://localhost:3001 and add --spice-debug for debugging.

Creating images based on an already configured and set up container

# You can create an image of an already configured and setup container.
# This allows you to effectively duplicate a system.
# To do this, run the following commands

# make note of your container id
docker ps --all
docker commit containerid newImageName

# To run this image do the following
docker run \
    --device /dev/kvm \
    --device /dev/snd \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    newImageName

docker pull sickcodes/docker-osx:auto

# boot directly into a real OS X shell with no display (Xvfb) [HEADLESS]
docker run -it \
    --device /dev/kvm \
    -p 50922:10022 \
    sickcodes/docker-osx:auto

# username is user
# passsword is alpine
# Wait 2-3 minutes until you drop into the shell.

Run the original version of Docker-OSX


docker pull sickcodes/docker-osx:latest

docker run -it \
    --device /dev/kvm \
    --device /dev/snd \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    sickcodes/docker-osx:latest

# press CTRL + G if your mouse gets stuck
# scroll down to troubleshooting if you have problems
# need more RAM and SSH on localhost -p 50922?

Run but enable SSH in OS X (Original Version)!

docker run -it \
    --device /dev/kvm \
    --device /dev/snd \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    sickcodes/docker-osx:latest

# turn on SSH after you've installed OS X in the "Sharing" settings.
ssh user@localhost -p 50922

Autoboot into OS X after you've installed everything

Add the extra option -e NOPICKER=true.

Old machines:

# find your containerID
docker ps

# move the no picker script on top of the Launch script
# NEW CONTAINERS
docker exec containerID mv ./Launch-nopicker.sh ./Launch.sh

# VNC-VERSION-CONTAINER
docker exec containerID mv ./Launch-nopicker.sh ./Launch_custom.sh

# LEGACY CONTAINERS
docker exec containerID bash -c "grep -v InstallMedia ./Launch.sh > ./Launch-nopicker.sh
chmod +x ./Launch-nopicker.sh
sed -i -e s/OpenCore\.qcow2/OpenCore\-nopicker\.qcow2/ ./Launch-nopicker.sh
"

The big-sur image starts slowly after installation. Is this expected?

Automatic updates are still on in the container's settings. You may wish to turn them off. We have future plans for development around this.

What is `${DISPLAY:-:0.0}`?

$DISPLAY is the shell variable that refers to your X11 display server.

${DISPLAY} is the same, but allows you to join variables like this:

e.g. ${DISPLAY}_${DISPLAY} would print :0.0_:0.0
e.g. $DISPLAY_$DISPLAY would print :0.0

...because $DISPLAY_ is not $DISPLAY

${variable:-fallback} allows you to set a "fallback" variable to be substituted if $variable is not set.

You can also use ${variable:=fallback} to set that variable (in your current terminal).

In Docker-OSX, we assume, :0.0 is your default $DISPLAY variable.

You can see what yours is

echo $DISPLAY

That way, ${DISPLAY:-:0.0} will use whatever variable your X11 server has set for you, else :0.0

What is `-v /tmp/.X11-unix:/tmp/.X11-unix`?

-v is a Docker command-line option that lets you pass a volume to the container.

The directory that we are letting the Docker container use is a X server display socket.

/tmp/.X11-unix

If we let the Docker container use the same display socket as our own environment, then any applications you run inside the Docker container will show up on your screen too! https://www.x.org/archive/X11R6.8.0/doc/RELNOTES5.html

ALSA errors on startup or container creation

You may when initialising or booting into a container see errors from the (qemu) console of the following form: ALSA lib blahblahblah: (function name) returned error: no such file or directory. These are more or less expected. As long as you are able to boot into the container and everything is working, no reason to worry about these.

Click to join the Discord server https://discord.gg/sickchat

Click to join the Telegram server https://t.me/sickcodeschat

Or reach out via Linkedin if it's private: https://www.linkedin.com/in/sickcodes

Or via https://sick.codes/contact/

Download Details:

Author: Sickcodes
Source Code: https://github.com/sickcodes/Docker-OSX
License: GPL-3.0 license

#docker #macos #container #os

Bongani Ngema

1673632260

Install Roblox on Pop!_OS

Roblox is one of the popular games with a great gaming community. It has cross-platform support, which you can use on macOS, Windows, and Android. Yes, Roblox is not available in Linux, and it takes a lot of effort to install since the game has yet to be ported to Linux.

However, you can use Wine because it offers the Windows environment in Linux. Hence, you can use Roblox in Linux using Wine. So, in this tutorial, we will explain the brief details on how to install Roblox on Pop!_OS because it is a Ubuntu-based distro.

How To Install Roblox on Pop!_OS

You can run any Windows program on Linux using the Wine utility. The latest version of Wine is required to run Roblox on Pop!_OS. Before installing Roblox, install Wine using the following procedure:

First, add the GPG key to install the latest version of Wine HQ.

wget -O – https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add –

Get the Wine repository using the following command:

sudo apt-add-repository https://dl.winehq.org/wine-builds/ubuntu/

Install Wine with the help of the following command:

sudo apt install --install-recommends winehq-stable

The whole process above installs Wine. Now, you can start the download process of Roblox.

Roblox is only available in UWP or AppxBundle app format, and you can install it on Windows 8 or 10 using the Microsoft Store. So, even after installing Wine HQ, you still need help downloading the Roblox setup on Pop!_OS directly from the official website.

You can download it from any third-party website, such as Filehorse, which automatically updates to the latest version once installed. Here, we will download the executable file of Roblox from the Filehorse website.

After downloading the previous file, open it in “Wine Windows Program Loader” by right-clicking it.

Before installing Roblox on Pop!_OS, Wine instructs you to install the Mono and Gecko installers for the system. After completing the process, the system will launch the “Roblox installation wizard” and automatically update its oldest version to the latest available version.

You will see the Roblox icon on your Pop!_OS desktop; right-click to execute it, and select “Allow Launch”. Finally, you can start Roblox in your Pop!_OS from its shortcut icon.

Now, you can log in to it and use Roblox on Linux, and if you are a new user, you can also create a new account.

Conclusion

Roblox is not just a game but an entire collection of games created by the community. In this tutorial, we have explained how to install Roblox on Pop!_OS. You can run Roblox Studio or Roblox Player on Linux with Wine’s compatibility layer for the Windows startup program. Here, we look at installing Roblox on Pop!_OS using the Wine repository.

Original article source at: https://linuxhint.com/

#linux #roblox #os

Nat Grady

1658935860

Titlebar: Emulate OS X Window Title Bar

titlebar

Emulate OS X window title bar. Extracted from mafintosh/playback. See the live demo.

npm install titlebar

Usage

Used with browserify or in a similar enviroment.

var titlebar = require('titlebar');

var t = titlebar();
t.appendTo(document.body);

t.on('close', function(e) {
    console.log('close');
});

// t.element exposes the root dom element
t.element.appendChild(document.createElement('div'));

// Clean up after usage
t.destroy();

The returned instance emits four events: close, minimize, fullscreen (each corresponding to one of the stoplight buttons) and maximize when double clicking on the title bar area, or holding down alt key and clicking fullscreen.

The initializer function accepts an options object.

style (default true): Disable default styling.
draggable (default true): Disable the -webkit-app-region CSS property on the root element. Allows a frameless windows to be dragged in an electron application.

Author: Kapetan
Source Code: https://github.com/kapetan/titlebar
License:

#electron #os #windows

Awesome Rust

1658020980

Advisory DB - Security Advisory Database for Rust Crates

RustSec Advisory Database

The RustSec Advisory Database is a repository of security advisories filed against Rust crates published via https://crates.io. A human-readable version of the advisory database can be found at https://rustsec.org/advisories/.

We also export advisory data to the OSV format, see the osv branch.

The following tools consume this advisory database and can be used for auditing and reporting (send PRs to add yours):

cargo-audit: Audit Cargo.lock files for crates with security vulnerabilities
cargo-deny: Audit Cargo.lock files for crates with security vulnerabilities, limit the usage of particular dependencies, their licenses, sources to download from, detect multiple versions of same packages in the dependency tree and more.

Reporting Vulnerabilities

To report a new vulnerability, open a pull request using the template below. See CONTRIBUTING.md for more information.

Advisory Format

See EXAMPLE_ADVISORY.md for a template.

Advisories are formatted in Markdown with TOML "front matter". Below is the schema of the "front matter" section of an advisory:

# Before you submit a PR using this template, **please delete the comments**
# explaining each field, as well as any unused fields.

[advisory]
# Identifier for the advisory (mandatory). Will be assigned a "RUSTSEC-YYYY-NNNN"
# identifier e.g. RUSTSEC-2018-0001. Please use "RUSTSEC-0000-0000" in PRs.
id = "RUSTSEC-0000-0000"

# Name of the affected crate (mandatory)
package = "mycrate"

# Disclosure date of the advisory as an RFC 3339 date (mandatory)
date = "2021-01-31"

# URL to a long-form description of this issue, e.g. a GitHub issue/PR,
# a change log entry, or a blogpost announcing the release (optional)
url = "https://github.com/mystuff/mycrate/issues/123"

# Optional: Categories this advisory falls under. Valid categories are:
# "code-execution", "crypto-failure", "denial-of-service", "file-disclosure"
# "format-injection", "memory-corruption", "memory-exposure", "privilege-escalation"
categories = ["crypto-failure"]

# Optional: a Common Vulnerability Scoring System score. More information
# can be found on the CVSS website, https://www.first.org/cvss/.
#cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"

# Freeform keywords which describe this vulnerability, similar to Cargo (optional)
keywords = ["ssl", "mitm"]

# Vulnerability aliases, e.g. CVE IDs (optional but recommended)
# Request a CVE for your RustSec vulns: https://iwantacve.org/
#aliases = ["CVE-2018-XXXX"]

# Related vulnerabilities (optional)
# e.g. CVE for a C library wrapped by a -sys crate)
#related = ["CVE-2018-YYYY", "CVE-2018-ZZZZ"]

# Optional: metadata which narrows the scope of what this advisory affects
[affected]
# CPU architectures impacted by this vulnerability (optional).
# Only use this if the vulnerability is specific to a particular CPU architecture,
# e.g. the vulnerability is in x86 assembly.
# For a list of CPU architecture strings, see the "platforms" crate:
# <https://docs.rs/platforms/latest/platforms/target/enum.Arch.html>
#arch = ["x86", "x86_64"]

# Operating systems impacted by this vulnerability (optional)
# Only use this if the vulnerable is specific to a particular OS, e.g. it was
# located in a binding to a Windows-specific API.
# For a list of OS strings, see the "platforms" crate:
# <https://docs.rs/platforms/latest/platforms/target/enum.OS.html>
#os = ["windows"]

# Table of canonical paths to vulnerable functions (optional)
# mapping to which versions impacted by this advisory used that particular
# name (e.g. if the function was renamed between versions). 
# The path syntax is `cratename::path::to::function`, without any
# parameters or additional information, followed by a list of version reqs.
functions = { "mycrate::MyType::vulnerable_function" = ["< 1.2.0, >= 1.1.0"] }

# Versions which include fixes for this vulnerability (mandatory)
[versions]
patched = [">= 1.2.0"]

# Versions which were never vulnerable (optional)
#unaffected = ["< 1.1.0"]

Download Details:
Author: RustSec
Source Code: https://github.com/RustSec/advisory-db/
License: View license

#rust #rustlang #staticanalysis

Advisory DB - Security Advisory Database for Rust Crates

Nat Grady

1658020620

Etcher: Flash OS Images to SD Cards & USB Drives, Safely and Easily

Etcher

Flash OS images to SD cards & USB drives, safely and easily.

Etcher is a powerful OS image flasher built with web technologies to ensure flashing an SDCard or USB drive is a pleasant and safe experience. It protects you from accidentally writing to your hard-drives, ensures every byte of data was written correctly, and much more. It can also directly flash Raspberry Pi devices that support USB device boot mode.

Packages

Package repository hosting is graciously provided by Cloudsmith. Cloudsmith is the only fully hosted, cloud-native, universal package management solution, that enables your organization to create, store and share packages in any format, to any place, with total confidence.

Debian and Ubuntu based Package Repository (GNU/Linux x86/x64)

Detailed or alternative steps in the instructions by Cloudsmith

Add Etcher Debian repository:

curl -1sLf \
   'https://dl.cloudsmith.io/public/balena/etcher/setup.deb.sh' \
   | sudo -E bash

Update and install:

sudo apt-get update
sudo apt-get install balena-etcher-electron

Uninstall

sudo apt-get remove balena-etcher-electron
rm /etc/apt/sources.list.d/balena-etcher.list
apt-get clean
rm -rf /var/lib/apt/lists/*
apt-get update

Redhat (RHEL) and Fedora-based Package Repository (GNU/Linux x86/x64)

Detailed or alternative steps in the instructions by Cloudsmith

DNF

Add Etcher rpm repository:

curl -1sLf \
   'https://dl.cloudsmith.io/public/balena/etcher/setup.rpm.sh' \
   | sudo -E bash

Update and install:

sudo dnf install -y balena-etcher-electron

Uninstall

rm /etc/yum.repos.d/balena-etcher.repo
rm /etc/yum.repos.d/balena-etcher-source.repo

Yum

Add Etcher rpm repository:

curl -1sLf \
   'https://dl.cloudsmith.io/public/balena/etcher/setup.rpm.sh' \
   | sudo -E bash

Update and install:

sudo yum install -y balena-etcher-electron

Uninstall

sudo yum remove -y balena-etcher-electron
rm /etc/yum.repos.d/balena-etcher.repo
rm /etc/yum.repos.d/balena-etcher-source.repo

OpenSUSE LEAP & Tumbleweed install (zypper)

Add the repo

curl -1sLf \
'https://dl.cloudsmith.io/public/balena/etcher/setup.rpm.sh' \
| sudo -E bash

Update and install

sudo zypper up
sudo zypper install balena-etcher-electron

Uninstall

sudo zypper rm balena-etcher-electron
# remove the repo
sudo zypper rr balena-etcher
sudo zypper rr balena-etcher-source

Solus (GNU/Linux x64)

sudo eopkg it etcher

Uninstall

sudo eopkg rm etcher

Arch/Manjaro Linux (GNU/Linux x64)

Etcher is offered through the Arch User Repository and can be installed on both Manjaro and Arch systems. You can compile it from the source code in this repository using balena-etcher. The following example uses a common AUR helper to install the latest release:

yay -S balena-etcher

Uninstall

yay -R balena-etcher

Brew (macOS)

Note: Etcher has to be updated manually to point to new versions, so it might not refer to the latest version immediately after an Etcher release.

brew install balenaetcher

Uninstall

brew uninstall balenaetcher

Chocolatey (Windows)

This package is maintained by @majkinetor, and is kept up to date automatically.

choco install etcher

Uninstall

choco uninstall etcher

Support

If you're having any problem, please raise an issue on GitHub, and the balena.io team will be happy to help.

Supported Operating Systems

Linux (most distros)
macOS 10.10 (Yosemite) and later
Microsoft Windows 7 and later

Note: Etcher will run on any platform officially supported by Electron. Read more in their documentation.

Installers

Refer to the downloads page for the latest pre-made installers for all supported operating systems.

Author: Balena-io
Source Code: https://github.com/balena-io/etcher
License: Apache-2.0 license

#electron #crossplatform #usb #os

Etcher: Flash OS Images to SD Cards & USB Drives, Safely and Easily

Nat Grady

1657740120

OS-usage: A Nodejs Module for Mac OSX to Watch System Usage

os-usage

A node module to watch system usage

Installation

npm install https://github.com/ningt/os-usage.git

Example Usage

var usage = require('os-usage');

// create an instance of CpuMonitor
var cpuMonitor = new usage.CpuMonitor();

// watch cpu usage overview
cpuMonitor.on('cpuUsage', function(data) {
    console.log(data);
    
    // { user: '9.33', sys: '56.0', idle: '34.66' }
});

// watch processes that use most cpu percentage
cpuMonitor.on('topCpuProcs', function(data) {
    console.log(data);
    
    // [ { pid: '21749', cpu: '0.0', command: 'top' },
    //  { pid: '21748', cpu: '0.0', command: 'node' },
    //  { pid: '21747', cpu: '0.0', command: 'node' },
    //  { pid: '21710', cpu: '0.0', command: 'com.apple.iCloud' },
    //  { pid: '21670', cpu: '0.0', command: 'LookupViewServic' } ]
});

// exit monitor
cpuMonitor.emit('exit');


// create a new instance of MemMonitor
var memMonitor = new usage.MemMonitor();

// watch memory usage overview
memMonitor.on('memUsage', function(data) {
    console.log(data);
    
    // { used: '9377M', wired: '2442M', unused: '7005M' }
});

// watch processes that use most memory
memMonitor.on('topMemProcs', function(data) {
    console.log(data);
    
       // [ { pid: '0', mem: '1521M', command: 'kernel_task' },
      // { pid: '13718', mem: '319M', command: 'Safari' },
    // { pid: '332', mem: '173M', command: 'Google Drive' },
      // { pid: '264', mem: '127M', command: 'Finder' },
      // { pid: '21654', mem: '123M', command: 'MacDown' } ]
});

// exit monitor
memMonitor.emit('exit');

Parameters

You can pass the following parameter when you initialize a monitor.

Parameter	Description
`limit`	number of processes to watch, default is `5`
`delay`	time interval in seconds to refesh stats, default is `1`
`exclude`	array of process names that will be ignore from results

Example:

var opts = { limit: 10, delay: 2, exclude: ['top', 'kernel_task', ...] };
var monitor = new usage.CpuMonitor(opts);

Author: Ningt
Source Code: https://github.com/ningt/os-usage
License:

#node #javascript #os #mac

OS-usage: A Nodejs Module for Mac OSX to Watch System Usage

Gonzalo Almanza Segundo

1655215500

Manjaro Vs. Arch: Elegir Su Sistema Operativo Post-Ubuntu

Los principiantes de Linux a menudo comienzan con Ubuntu. Es una de las distribuciones más populares y ampliamente utilizadas y es bastante amigable para principiantes. Está dirigido principalmente a usuarios (posiblemente inexpertos) que no quieren preocuparse por cómo configurar su sistema.

Sin embargo, llega un momento en que uno puede querer más flexibilidad y poder. Arch y Manjaro son dos grandes jugadores en esa área, ya que apuntan a usuarios con una actitud de hágalo usted mismo.

En esta publicación, los compararemos, pero primero, veremos cómo está aumentando su popularidad.

¿Se está eliminando Ubuntu?

Históricamente, uno de los primeros indicadores del abandono de un sistema operativo ha sido una disminución en su adopción por parte de los jugadores.

boilingstream.com proporciona un muy buen análisis de la popularidad de Ubuntu, junto con otras distribuciones de Linux, dentro de la comunidad de jugadores. Según ellos, a principios de 2019, más del 40 por ciento de los jugadores de Linux usarían Ubuntu como sistema operativo (SO) preferido. En ese momento, tanto Manjaro como Arch tenían alrededor de un 10 por ciento de adopción, siendo el primero un poco más popular que el segundo.

En tres años la situación ha cambiado radicalmente. La adopción de Ubuntu es ahora del 18,8 por ciento, casi la misma que la de Manjaro (18,5 por ciento) e inferior a la de Arch (20 por ciento). La tendencia es clara: los últimos dos sistemas operativos han ido ganando popularidad y ahora han superado a Ubuntu.

Por lo tanto, surge una pregunta: ¿Cómo elegiríamos entre Arch y Manjaro? Esta publicación se trata de explorar las diferencias entre ellos para tomar una decisión informada para nuestro sistema operativo posterior a Ubuntu.

arco linux

Arch Linux es una de las distribuciones de Linux más vanguardistas, cuyo enfoque está en el minimalismo y la personalización. Una de las principales diferencias con respecto a otras distribuciones es el proceso de instalación. En lugar de estar basado en GUI (interfaz gráfica de usuario) o TUI (interfaz de usuario de texto), Arch debe instalarse mediante la línea de comandos. Esto hace que todo el proceso sea más complejo y definitivamente no apto para principiantes.

Los usuarios de Arch pueden contar con el soporte de ArchWiki, documentación completa que resulta útil en el momento de la instalación y configuración.

Arch es una distribución de lanzamiento continuo, lo que significa que las actualizaciones de las aplicaciones instaladas se entregan con frecuencia. Este es diferente del modelo adoptado, por ejemplo, por Ubuntu o Fedora, donde cada pocos meses o años se lanza una nueva versión.

En Arch, una vez que instalamos el sistema operativo, podemos mantenerlo actualizado y sus aplicaciones utilizando Pacman , el administrador de paquetes. Los repositorios oficiales contienen toneladas de paquetes que sus mantenedores actualizan constantemente. Tener siempre las últimas versiones también puede ser un arma de doble filo, ya que también podemos incurrir en los últimos errores.

Cuando un paquete no está disponible en los repositorios oficiales, puede estar en AUR (Arch User Repository). Esta es una de las características más apreciadas de Arch, ya que podemos acceder a contenido producido por los usuarios. Aún así, necesitaremos compilar el software obtenido de AUR nosotros mismos.

Mánjaro

Manjaro está basado en Arch Linux. El gestor de repositorios es el mismo que Arch, Pacman , aunque Manjaro simplifica la gestión de paquetes dándonos también una aplicación gráfica. Incluso si los repositorios de Manjaro son diferentes a los de Arch, podemos acceder a AUR y beneficiarnos del software proporcionado por el usuario.

En términos generales, Manjaro es más fácil de usar que Arch. Se puede descargar en diferentes sabores, según el entorno de escritorio. Por ejemplo, los tres lanzamientos oficiales usan XFCE, KDE o GNOME. Sin embargo, hay una serie de lanzamientos "no oficiales" para otros entornos.

La comparación

Esta sección contiene una comparación entre Arch y Manjaro.

Modelo de liberación rodante

Como vimos anteriormente, tanto Manjaro como Arch se basan en un modelo de actualización de lanzamiento continuo: como usuarios, podemos instalar el sistema operativo solo una vez y luego nos beneficiaremos de las actualizaciones frecuentes. Ambas distribuciones mantienen sus imágenes de instalación actualizadas para que los sistemas recién instalados no tengan que instalar todas las actualizaciones de aplicaciones y sistemas nuevos. Esta práctica se denomina actualización de ISO.

Aún así, Manjaro mantiene sus propios repositorios independientes y no depende de los de Arch (con la única excepción del administrado por la comunidad, que es AUR). Dichos repositorios independientes también contienen paquetes que no están disponibles para los usuarios de Arch.

En términos generales, pero no necesariamente, los paquetes de Majaro son más estables que sus contrapartes de Arch. Esto se debe a que las actualizaciones que provienen de los repositorios de Arch primero se prueban y posiblemente se parchean antes de que se lancen a los usuarios de Manjaro. El proceso suele tardar un par de semanas.

La consecuencia inmediata de la mencionada diferencia es que Manjaro nunca será tan “moderno” como Arch. Por otro lado, debería ser menos propenso a errores graves que podrían dañar o romper el sistema.

Gestión de paquetes

Tanto Arch como Manjaro confían en una herramienta de línea de comandos, codificada en C, conocida como Pacman para administrar las actualizaciones de software. Por lo tanto, los mismos comandos funcionarán igual en ambos sistemas.

No obstante, Manjaro también viene con una herramienta gráfica para gestionar los paquetes instalados: Pamac . Este último también se puede agregar a Arch, pero no es una parte incorporada del sistema.

Conductores

Manjaro facilita la instalación de controladores, especialmente los de GPU. Por ejemplo, durante el procedimiento de instalación, los usuarios pueden optar por dejar que Manjaro detecte la tarjeta gráfica e instale los controladores más apropiados para ella.

Además, Manjaro viene con una herramienta gráfica, conocida como Herramienta de detección de hardware de Manjaro (MHWD), que ayuda a administrar los controladores del hardware.

En Arch, por otro lado, los usuarios tienen que encontrar e instalar los controladores apropiados a mano.

Procedimiento de instalación

Como vimos arriba, la instalación de Arch es más complicada que la de Manjaro. Sin embargo, para facilitar la instalación, podemos usar archinstall. Es una herramienta de línea de comandos que viene con diferentes instaladores preconfigurados, simulando un instalador "guiado" para Arch. La herramienta aún es experimental y utiliza valores predeterminados diferentes a los del proceso de instalación normal.

Además, Arch viene básicamente sin aplicaciones preinstaladas. Los usuarios son libres de instalar solo los paquetes que deseen personalmente. Por tanto, no tiene un entorno de escritorio preconfigurado, aunque los usuarios pueden optar por instalarlo desde los repositorios oficiales.

Manjaro, en cambio, ofrece un procedimiento de instalación basado en GUI. Como vimos anteriormente, viene con algunas aplicaciones preinstaladas, como Pamac, MHWD, reproductores de audio/video, un cliente de correo electrónico y una suite ofimática. Además, Manjaro ofrece diferentes imágenes de instalación con entornos de escritorio predefinidos.

Seguridad

Como Arch es una distribución de bricolaje, su seguridad depende de cómo la configuren los usuarios. Los mantenedores ponen mucho esfuerzo en no exponer el sistema a amenazas obvias y conocidas. Por ejemplo, una lista de las principales vulnerabilidades está disponible en https://security.archlinux.org/ . Además, ArchWiki tiene una página muy detallada que explica cómo endurecer el sistema.

Manjaro, por otro lado, ha minimizado la importancia de las prácticas de seguridad en el pasado. Por ejemplo, en 2015, los mantenedores dejaron que caducara su certificado SSL e indicaron a los usuarios que retrocedieran sus relojes para solucionar el problema temporalmente. Además, los usuarios de Manjaro todavía tienen que configurar el sistema por sí mismos, ya que el sistema operativo no viene con una configuración a prueba de balas predefinida.

Conclusión

En esta publicación, nos sumergimos en una comparación entre Arch Linux y Manjaro. Sin embargo, hay muchas otras distribuciones populares basadas en Arch, como EndeavourOS y Garuda Linux. En última instancia, la elección es solo una cuestión de preferencia personal.

Cuando se trata de los sistemas operativos comparados en este artículo, ambos tienen ventajas y desventajas. Sobre el papel, Arch es más adecuado para usuarios avanzados que saben exactamente lo que quieren en sus sistemas. Manjaro, por otro lado, adopta un enfoque más pragmático y hace algunas suposiciones sobre lo que quieren sus usuarios (por ejemplo, al instalar algunas aplicaciones predefinidas).

Aún así, los usuarios avanzados pueden querer optar por Manjaro solo porque no necesitan toda la flexibilidad proporcionada por Arch. Los usuarios menos experimentados, en cambio, pueden querer probar Arch solo por aprender.

En términos generales, la elección correcta también depende de lo que vamos a hacer con nuestro sistema operativo.

Por ejemplo, los jugadores se beneficiarán de Manjaro o Arch Linux, ya que básicamente no hay diferencia entre ellos cuando se trata de juegos. Sin embargo, la instalación del controlador es más sencilla en Manjaro. Lo mismo es cierto para los desarrolladores o las personas que trabajan con la edición de medios. El modelo de actualización continua garantiza que los paquetes se actualicen con frecuencia, lo que brinda a los desarrolladores y trabajadores la posibilidad de trabajar con la última versión de sus herramientas.

En mi opinión, Manjaro, así como otras distribuciones basadas en Arch, son un muy buen punto de partida si desea tener más control sobre su sistema operativo. Viene con muchas de las ventajas de Arch mientras mantiene bajo control la complejidad de la configuración. Luego, si desea obtener más experiencia en la configuración de un sistema operativo y terminar con un sistema altamente personalizado, puede pasar a Arch.

Esta historia se publicó originalmente en https://blog.logrocket.com/manjaro-arch-choosing-post-ubuntu-os/

#manjaro #arch #ubuntu #os

Manjaro Vs. Arch: Elegir Su Sistema Operativo Post-Ubuntu

津田あすか

1655215200

Manjaro vs. Arch：Ubuntu以降のOSの選択

Linuxの初心者は、Ubuntuから始めることがよくあります。これは、最も人気があり、広く使用されているディストリビューションの1つであり、非常に初心者向けです。これは主に、システムのセットアップ方法について心配したくない（おそらく経験の浅い）ユーザーを対象としています。

しかし、もっと柔軟性とパワーが必要になる時が来ます。ArchとManjaroは、日曜大工の姿勢でユーザーを対象としているため、この分野で2人の大きなプレーヤーです。

この投稿では、それらを比較しますが、最初に、それらの人気がどのように増加しているかを見ていきます。

Ubuntuは削除されていますか？

歴史的に、オペレーティングシステムが削除されたことを示す初期の指標の1つは、ゲーマーによる採用の減少でした。

boilingstream.comは、ゲームコミュニティ内でのUbuntuと他のLinuxディストリビューションの人気に関する非常に優れた分析を提供します。彼らによると、2019年の初めには、Linuxゲーマーの40％以上がUbuntuを優先オペレーティングシステム（OS）として使用していました。当時、ManjaroとArchはどちらも約10％採用されており、前者の方が後者よりもわずかに人気がありました。

3年間で状況は根本的に変化しました。Ubuntuの採用は現在18.8％で、Manjaro（18.5％）とほぼ同じであり、Arch（20％）よりも低くなっています。傾向は明らかです。後者の2つのOSは人気を博しており、Ubuntuを上回っています。

したがって、疑問が浮かびます。ArchとManjaroのどちらを選択するのでしょうか。この投稿は、Ubuntu以降のOSについて十分な情報に基づいた選択を行うために、それらの違いを調査することを目的としています。

Arch Linux

Arch Linuxは、ミニマリズムとカスタマイズに重点を置いた最先端のLinuxディストリビューションの1つです。他のディストリビューションとの主な違いの1つは、インストールプロセスです。GUI-（グラフィカルユーザーインターフェイス）またはTUI-（テキストユーザーインターフェイス）ベースではなく、コマンドラインを使用してArchをインストールする必要があります。これにより、プロセス全体がより複雑になり、初心者には絶対にわかりません。

Archユーザーは、インストールおよび構成時に役立つ包括的なドキュメントであるArchWikiのサポートを利用できます。

Archはいわゆるローリングリリースディストリビューションであり、インストールされたアプリケーションのアップデートが頻繁に配信されることを意味します。これは、たとえば、UbuntuやFedoraで採用されているモデルとは異なります。このモデルでは、数か月または数年ごとに新しいバージョンがリリースされます。

Archでは、OSをインストールすると、パッケージマネージャーであるPacmanを使用して、OSとそのアプリケーションを最新の状態に保つことができます。公式リポジトリには、メンテナによって絶えず更新される大量のパッケージが含まれています。最新のバグが発生する可能性があるため、常に最新バージョンを使用することも両刃の剣である可能性があります。

パッケージが公式リポジトリで利用できない場合は、AUR（Arch UserRepository）にある可能性があります。これは、ユーザーが作成したコンテンツにアクセスできるため、Archの最も評価の高い機能の1つです。それでも、AURから取得したソフトウェアを自分でコンパイルする必要があります。

マンジャロ

ManjaroはArchLinuxをベースにしています。リポジトリマネージャーはArch、Pacmanと同じですが、Manjaroはグラフィカルアプリケーションも提供することでパッケージ管理を簡素化します。ManjaroのリポジトリがArchのリポジトリと異なっていても、AURにアクセスして、ユーザーが提供するソフトウェアの恩恵を受けることができます。

一般的に、ManjaroはArchよりもユーザーフレンドリーです。デスクトップ環境に基づいて、さまざまなフレーバーでダウンロードできます。たとえば、3つの公式リリースでは、XFCE、KDE、またはGNOMEのいずれかが使用されます。ただし、他の環境向けの「非公式」リリースがいくつかあります。

比較

このセクションには、ArchとManjaroの比較が含まれています。

ローリングリリースモデル

上で見たように、ManjaroとArchはどちらもローリングリリースの更新モデルに基づいています。ユーザーとして、OSを1回だけインストールすると、頻繁な更新の恩恵を受けることができます。どちらのディストリビューションもインストールイメージを最新の状態に保つため、新しくインストールされたシステムは、新しいシステムとアプリケーションの更新をすべてインストールする必要がありません。この方法はISOリフレッシュと呼ばれます。

それでも、Manjaroは独自の独立したリポジトリを維持しており、Archのリポジトリに依存していません（コミュニティが管理するリポジトリ、つまりAURを除いて）。このような独立したリポジトリには、Archユーザーが利用できないパッケージも含まれています。

一般的に言えば、必ずしもそうとは限りませんが、MajaroのパッケージはArchのパッケージよりも安定しています。これは、Archリポジトリからの更新が、Manjaroのユーザーにリリースされる前に、最初にテストされ、場合によってはパッチが適用されるためです。このプロセスには通常、数週間かかります。

前述の違いの直接の結果は、ManjaroがArchほど「モダン」になることは決してないということです。一方、システムを損傷または破壊する可能性のある重大なバグが発生する可能性は低くなります。

パッケージ管理

ArchとManjaroはどちらも、ソフトウェアの更新を管理するために、Cでコード化されたPacmanと呼ばれるコマンドラインツールに依存しています。したがって、同じコマンドが両方のシステムで同じように機能します。

それでも、Manjaroには、インストールされているパッケージを管理するためのグラフィカルツールであるPamacも付属しています。後者はArchに追加することもできますが、システムの組み込み部分ではありません。

運転手

Manjaroを使用すると、ドライバー、特にGPUドライバーのインストールが簡単になります。たとえば、インストール手順中に、ユーザーはManjaroにグラフィックカードを検出させ、それに最も適切なドライバーをインストールさせることを選択できます。

さらに、Manjaroには、ハードウェアのドライバーの管理に役立つManjaro Hardware Detection Tool（MHWD）と呼ばれるグラフィックツールが付属しています。

一方、Archでは、ユーザーは適切なドライバーを手作業で見つけてインストールする必要があります。

インストール手順

上で見たように、ArchのインストールはManjaroのインストールよりも複雑です。ただし、インストールを簡単にするために、archinstallを使用できます。これは、Archの「ガイド付き」インストーラーをシミュレートする、さまざまな事前構成済みインストーラーが付属するコマンドラインツールです。このツールはまだ実験段階であり、通常のインストールプロセスとは異なるデフォルト値を使用します。

さらに、Archには基本的にプリインストールされたアプリケーションは付属していません。ユーザーは、個人的に必要なパッケージのみを自由にインストールできます。したがって、ユーザーは公式リポジトリからインストールすることを選択できますが、事前構成されたデスクトップ環境はありません。

代わりに、ManjaroはGUIベースのインストール手順を提供します。上で見たように、Pamac、MHWD、オーディオ/ビデオプレーヤー、電子メールクライアント、オフィススイートなどのいくつかのプリインストールされたアプリケーションが付属しています。さらに、Manjaroは、事前定義されたデスクトップ環境でさまざまなインストールイメージを提供します。

安全

Archは日曜大工のディストリビューションであるため、そのセキュリティはユーザーがArchを構成する方法によって異なります。メンテナは、システムを明白で既知の脅威にさらさないように多大な努力を払いました。たとえば、主な脆弱性のリストはhttps://security.archlinux.org/で入手できます。さらに、ArchWikiには、システムを強化する方法を説明する非常に詳細なページがあります。

一方、Manjaroは、過去にセキュリティ慣行の重要性を軽視してきました。たとえば、2015年に、メンテナはSSL証明書の有効期限を切れさせ、一時的に問題を回避するために時計をロールバックするようにユーザーに指示しました。さらに、OSには事前定義された防弾構成が付属していないため、Manjaroユーザーは自分でシステムを構成する必要があります。

結論

この投稿では、ArchLinuxとManjaroの比較について詳しく説明します。ただし、EndeavourOSやGaruda Linuxなど、他にも多くの人気のあるArchベースのディストリビューションがあります。最終的に、選択は個人的な好みの問題です。

この記事で比較したOSに関しては、どちらにも長所と短所があります。紙面では、Archは、システムに何を求めているかを正確に理解している上級ユーザーに適しています。一方、Manjaroは、より実用的なアプローチを採用し、ユーザーが何を望んでいるかについていくつかの仮定を立てます（たとえば、いくつかの事前定義されたアプリケーションをインストールすることによって）。

それでも、上級ユーザーは、Archが提供するすべての柔軟性を必要としないという理由だけで、Manjaroを利用したいと思うかもしれません。代わりに、経験の浅いユーザーは、学習のためだけにArchを試してみることをお勧めします。

一般的に言って、正しい選択は、OSで何をするかにも依存します。

たとえば、ゲーマーはManjaroまたはArch Linuxのいずれかを利用できます。これは、ゲームに関しては基本的に違いがないためです。ただし、Manjaroではドライバーのインストールが簡単です。同じことが、開発者やメディア編集を扱う人々にも当てはまります。ローリング更新モデルにより、パッケージが頻繁に更新され、開発者と作業者が最新バージョンのツールを使用できるようになります。

私の意見では、Manjaroや他のArchベースのディストリビューションは、OSをより細かく制御したい場合の非常に良い出発点です。構成の複雑さを制御しながら、Archの多くの利点があります。次に、OSの構成に関する専門知識をさらに深めて、高度にカスタマイズされたシステムを作成したい場合は、Archに移行できます。

このストーリーはもともとhttps://blog.logrocket.com/manjaro-arch-choosing-post-ubuntu-os/で公開されました

#manjaro #arch #ubuntu #os

Duane Purdy

1654427520

ToaruOS: A "Complete" Operating System for X86-64 PCs

ToaruOS

ToaruOS is a "complete" operating system for x86-64 PCs and experimental support for ARMv8.

While many independent, hobby, and research OSes aim to experiment with new designs, ToaruOS is intended as an educational resource, providing a representative microcosm of functionality found in major desktop operating systems.

The OS includes a kernel, bootloader, dynamic shared object linker, C standard library, its own composited windowing system, a dynamic bytecode-compiled programming language, advanced code editor, and dozens of other utilities and example applications.

There are no external runtime dependencies and all required source code, totalling roughly 100k lines of (primarily) C, is included in this repository, save for Kuroko, which lives separately.

Screenshot Demonstration of ToaruOS's UI and some applications.

History

I have been working on ToaruOS for over a decade now, and my goals have changed over the years.
When I first started the project in December 2010, my aim was to "learn by doing" - studying Unix-like systems by making one from scratch. I had been a contributor to Compiz, one of the first widely-used compositing window managers for X11, a few years prior, and somewhat naturally ToaruOS gained a GUI built on similar concepts early on.
For its original 1.0 release in 2015, ToaruOS was not the "completely from scratch" OS it has since become. Newlib provided the libc, and the GUI was built on Cairo, libpng, and Freetype. In the middle of 2018, I started a new project to replace these third-party components, which was eventually completed and merged to become ToaruOS 1.6.
Through out the project, ToaruOS has also attracted quite a few beginner OS developers who have tried to use it as a reference. ToaruOS's kernel, however, was a source of personal embarrassment for me, and in April 2021, after a long hiatus, I began work on a new one. The result was Misaka: a new 64-bit, SMP-enabled kernel. Misaka was merged in May and started the 1.99 series of beta releases leading up to ToaruOS 2.0.

Features

Dynamically linked userspace with shared libraries and dlopen.
Composited graphical UI with software acceleration and a late-2000s design inspiration.
VM integration for absolute mouse and automatic display sizing in VirtualBox and VMware Workstation.
Unix-like terminal interface including a feature-rich terminal emulator and several familiar utilities.
Optional third-party ports including GCC 10.3, Binutils, SDL1.2, Quake, and more.

Notable Components

Misaka (kernel), kernel/, a hybrid modular kernel, and the core of the operating system.
Yutani (window compositor), apps/compositor.c, manages window buffers, layout, and input routing.
Bim (text editor), apps/bim.c, is a Vim-inspired editor with syntax highlighting.
Terminal, apps/terminal.c, xterm-esque terminal emulator with 24-bit color support.
ld.so (dynamic linker/loader), linker/linker.c, loads dynamically-linked ELF binaries.
Esh (shell), apps/sh.c, supports pipes, redirections, variables, etc.
Kuroko (interpreter), kuroko/, a dynamic bytecode-compiled programming language.

Current Goals

The following projects are currently in progress:

Rewrite the network stack for greater throughput, stability, and server support.
Improve SMP performance with better scheduling and smarter userspace synchronization functions.
Support more hardware with new device drivers for AHCI, USB, virtio devices, etc.
Bring back ports from ToaruOS "Legacy", like muPDF and Mesa.
Improve POSIX coverage especially in regards to signals, synchronization primitives, as well as by providing more common utilities.
Continue to improve the C library which remains quite incomplete compared to Newlib and is a major source of issues with bringing back old ports.
Replace third-party development tools to get the OS to a state where it is self-hosting with just the addition of a C compiler.
Implement a C compiler toolchain in toarucc.

Building / Installation

Building With Docker

General users hoping to build ToaruOS from source are recommended to use the prebuilt Docker image, which contains all the necessary tools:

git clone https://github.com/klange/toaruos
cd toaruos
git submodule update --init kuroko
docker pull toaruos/build-tools:1.99.x
docker run -v `pwd`:/root/misaka -w /root/misaka -e LANG=C.UTF-8 -t toaruos/build-tools:1.99.x util/build-in-docker.sh

After building like this, you can run the various utility targets (make run, etc.). Try make shell to run a ToaruOS shell using a serial port with QEMU.

Build Process Internals

The Makefile uses a Kuroko tool, auto-dep.krk, to generate additional Makefiles for the userspace applications and libraries, automatically resolving dependencies based on #include directives.

In an indeterminate order, the C library, kernel, userspace librares and applications are built, combined into a compressed archive for use as a ramdisk, and then packaged into an ISO9660 filesystem image.

Project Layout

apps - Userspace applications, all first-party.
base - Ramdisk root filesystem staging directory. Includes C headers in base/usr/include, as well as graphical resources for the compositor and window decorator.
boot - BIOS and EFI loader with interactive menus.
build - Auxiliary build scripts for platform ports.
kernel - The Misaka kernel.
kuroko - Submodule checkout of the Kuroko interpreter.
lib - Userspace libraries.
libc - C standard library implementation.
linker - Userspace dynamic linker/loader, implements shared library support.
modules - Loadable driver modules for the kernel.
util - Utility scripts, staging directory for the toolchain (binutils/gcc).
.make - Generated Makefiles.

Filesystem Layout

The root filesystem is set up as follows:

bin: First-party applications.
cdrom: Mount point for the CD, if available.
dev: Virtual device directory, generated by the kernel.
- net: Network interface devices.
- pex: Packet Exchange hub, lists accessible IPC services.
- pts: PTY secondaries, endpoints for TTYs.
etc: Configuration files, startup scripts.
home: User directories.
lib: First-party libraries
- kuroko: Kuroko modules.
mod: Loadable kernel modules.
proc: Virtual files that present kernel state.
- 1, etc.: Virtual files with status information for individual processes.
src: Source files, see "Project Layout" section above.
tmp: Mounted as a read/write tmpfs normally.
usr: Userspace resources
- bin: Third-party applications, normally empty until packages are installed.
- include: Header files, including potentially ones from third-party packages.
- lib: Third-party libraries. Should have libgcc_s.so by default.
- share: Various resources.
  - bim: Syntax highlighting and themes for the text editor.
  - cursor: Mouse cursor sprites.
  - fonts: TrueType font files. Live CDs ship with Deja Vu Sans.
  - games: Dumping ground for game-related resource files, like Doom wads.
  - help: Documentation files for the Help Browser application.
  - icons: PNG icons, divided into further directories by size.
  - ttk: Spritesheet resources for the window decorator and widget library.
  - wallpapers: JPEG wallpapers.
var: Runtime files, including package manager manifest cache, PID files, some lock files, etc.

Running ToaruOS

VirtualBox and VMware Workstation

The best end-user experience with ToaruOS will be had in either of these virtual machines, as ToaruOS has support for their automatic display sizing and absolute mouse positioning.

Set up a new VM for an "other" 64-bit guest, supply it with at least 1GiB of RAM, attach the CD image, remove or ignore any hard disks, and select an Intel Gigabit NIC. Two or more CPUs are recommended, as well.

VirtualBox screenshot

ToaruOS running in VirtualBox.

VMware screenshot

ToaruOS running in VMware Workstation Player.

By default, the bootloader will pass a flag to the VirtualBox device driver to disable "Seamless" support as the implementation has a performance overhead. To enable Seamless mode, use the bootloader menu to check the "VirtualBox Seamless" option before booting. The menu also has options to disable automatic guest display sizing if you experience issues with this feature.

QEMU

Most development of ToaruOS happens in QEMU, as it provides the most flexibility in hardware and the best debugging experience. A recommended QEMU command line in an Ubuntu 20.04 host is:

qemu-system-x86_64 -enable-kvm -m 1G -soundhw ac97 -cdrom image.iso -smp 2

Replace -enable-kvm with -accel hvm or -accel haxm as appropriate on host platforms without KVM, or remove it to try under QEMU's TCG software emulation.

Note that QEMU command line options are not stable and these flags may produce warnings in newer versions.

The option -M q35 will replace the PIIX chipset emulation with a newer one, which has the side effect of switching the IDE controller for a SATA one. This can result in faster boot times at the expense of ToaruOS not being able to read its own CD at runtime until I get around to finishing my AHCI driver.

Other

ToaruOS has been successfully tested on real hardware. If the native BIOS or EFI loaders fail to function, try booting with Grub. ToaruOS complies with the "Multiboot" and "Multiboot 2" specs so it may be loaded with either the multiboot or multiboot2 commands as follows:

multiboot2 /path/to/misaka-kernel root=/dev/ram0 migrate vid=auto start=live-session
module2 /path/to/ramdisk.igz
set gfxpayload=keep

Native photo ToaruOS running natively from a USB stick on a ThinkPad T410.

License

All first-party parts of ToaruOS are made available under the terms of the University of Illinois / NCSA License, which is a BSD-style permissive license. Unless otherwise specified, this is the original and only license for all files in this repository - just because a file does not have a copyright header does not mean it isn't under this license. ToaruOS is intended as an educational reference, and I encourage the use of my code, but please be sure you follow the requirements of the license. You may redistribute code under the NCSA license, as well as make modifications to the code and sublicense it under other terms (such as the GPL, or a proprietary license), but you must always include the copyright notice specified in the license as well as make the full text of the license (it's only a couple paragraphs) available to end-users.

While most of ToaruOS is written entirely by myself, be sure to include other authors where relevant, such as with Mike's audio subsystem or Dale's string functions.

Some components of ToaruOS, such as Kuroko or bim have different but compatible terms.

Community

Mirrors

ToaruOS is regularly mirrored to multiple Git hosting sites.

Gitlab: toaruos/toaruos
GitHub: klange/toaruos
Bitbucket: klange/toaruos
ToaruOS.org: klange/toaruos

IRC

#toaruos on Libera (irc.libera.chat)

FAQs

Is ToaruOS self-hosting?

Individual applications and libraries can be built by installing the build-essential metapackage from the repository, which will pull in gcc and binutils. Sources are available in the /src directory on the live CD in a similar layout to this repository, and the auto-dep.krk utility script is also available.

For building ramdisks, finalized kernels, or CD images, some components are currently unavailable. In particular, the build script for ramdisks is still written in Python and depends on its tarfile module and zlib support. Previously, with a capable compiler toolchain, ToaruOS 1.x was able to build its own kernel, userspace, libraries, and bootloader, and turn these into a working ISO CD image through a Python script that performed a similar function to the Makefile.

ToaruOS is not currently capable of building most of its ports, due to a lack of a proper POSIX shell and Make implementation. These are eventual goals of the project.

Is ToaruOS a Linux distribution?

No, not at all. There is no code from Linux anywhere in ToaruOS, nor were Linux sources used as a reference material.

ToaruOS is a completely independent project, and all code in this repository - which is the entire codebase of the operating system, including its kernel, bootloaders, libraries, and applications - is original, written by myself and a handful of contributors over the course of ten years. The complete source history, going back to when ToaruOS was nothing more than a baremetal "hello world" can be tracked through this git repository.

When you say "complete"...

ToaruOS is complete in the sense that it covers the whole range of functionality for an OS: It is not "just a kernel" or "just a userspace".

ToaruOS is not complete in the sense of being "done".

Is ToaruOS POSIX-compliant?

While I aim to support POSIX interfaces well enough for software to be ported, strict implementation of the standard is not a major goal of the OS, and full compliance may even be undesirable.

Are contributions accepted?

ToaruOS is a personal project, not a community project. Contributions in the form of code should be discussed in advance. Ports and other work outside of the repo, however, are a great way to help out.

You can also help by contributing to Kuroko - which is part of why it's kept as a separate repository.

Author: klange
Source Code: https://github.com/klange/toaruos
License: NCSA license

#c #os

ToaruOS: A "Complete" Operating System for X86-64 PCs

Chesley Labadie

1652879940

Bleep: OS Signal Handlers in Go

Bleep

Bleep is used to peform actions on OS signals. It is highly extensible and goroutine safe. It is possible to add any number of actions and all of them are guaranteed to be performed simultaneously on the OS signals that Bleep will be listening for.

Installation

go get github.com/sinhashubham95/bleep

How to Use

The Bleep package allows you to create a new instance of the handler and also has a default handler in place that can be used directly.

Creating separate Bleep instances can be useful, when you want to perform different set of actions for different set of OS signals.

Create a New OS Signal Handler

This is used to create a new handler for performing actions on OS Signals.

import (
  "os"
  "github.com/sinhashubham95/bleep"
)

func New() {
  handler := bleep.New()
  // now this handler can be used to add or remove actions and listen to the OS signals
}

Add an Action

This is used to add an action to be executed on the OS signal listening for.

import (
  "os"
  "github.com/sinhashubham95/bleep"
)

fun Add() {
  key := bleep.Add(func (s os.Signal) {
    // do something
  })
  // this key is the unique identifier for your added action
}

Remove an Action

This is used to remove an action added to Bleep.

import (
  "github.com/sinhashubham95/bleep"
)

func Remove() {
  action := bleep.Remove("some-key")  // this key should be the same as the one returned during adding the action
  // the returned action is the one that was added using this key
}

Listen

This is used to listen for the OS signals. Note that this will wait for the signal in the go routine in which this is called.

import (
  "syscall"
  "github.com/sinhashubham95/bleep"
)

func Listen() {
  bleep.Listen(syscall.SIGINT, syscall.SIGTERM)
}

Author: Sinhashubham95
Source Code: https://github.com/sinhashubham95/bleep
License: MIT license

#go #golang #os

Annie Emard

1651605480

Advisory DB: Security Advisory Database for Rust Crates

RustSec Advisory Database

We also export advisory data to the OSV format, see the osv branch.

The following tools consume this advisory database and can be used for auditing and reporting (send PRs to add yours):

cargo-audit: Audit Cargo.lock files for crates with security vulnerabilities
cargo-deny: Audit Cargo.lock files for crates with security vulnerabilities, limit the usage of particular dependencies, their licenses, sources to download from, detect multiple versions of same packages in the dependency tree and more.

Reporting Vulnerabilities

To report a new vulnerability, open a pull request using the template below. See CONTRIBUTING.md for more information.

Advisory Format

See EXAMPLE_ADVISORY.md for a template.

Advisories are formatted in Markdown with TOML "front matter". Below is the schema of the "front matter" section of an advisory:

# Before you submit a PR using this template, **please delete the comments**
# explaining each field, as well as any unused fields.

[advisory]
# Identifier for the advisory (mandatory). Will be assigned a "RUSTSEC-YYYY-NNNN"
# identifier e.g. RUSTSEC-2018-0001. Please use "RUSTSEC-0000-0000" in PRs.
id = "RUSTSEC-0000-0000"

# Name of the affected crate (mandatory)
package = "mycrate"

# Disclosure date of the advisory as an RFC 3339 date (mandatory)
date = "2021-01-31"

# URL to a long-form description of this issue, e.g. a GitHub issue/PR,
# a change log entry, or a blogpost announcing the release (optional)
url = "https://github.com/mystuff/mycrate/issues/123"

# Optional: Categories this advisory falls under. Valid categories are:
# "code-execution", "crypto-failure", "denial-of-service", "file-disclosure"
# "format-injection", "memory-corruption", "memory-exposure", "privilege-escalation"
categories = ["crypto-failure"]

# Optional: a Common Vulnerability Scoring System score. More information
# can be found on the CVSS website, https://www.first.org/cvss/.
#cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"

# Freeform keywords which describe this vulnerability, similar to Cargo (optional)
keywords = ["ssl", "mitm"]

# Vulnerability aliases, e.g. CVE IDs (optional but recommended)
# Request a CVE for your RustSec vulns: https://iwantacve.org/
#aliases = ["CVE-2018-XXXX"]

# Related vulnerabilities (optional)
# e.g. CVE for a C library wrapped by a -sys crate)
#related = ["CVE-2018-YYYY", "CVE-2018-ZZZZ"]

# Optional: metadata which narrows the scope of what this advisory affects
[affected]
# CPU architectures impacted by this vulnerability (optional).
# Only use this if the vulnerability is specific to a particular CPU architecture,
# e.g. the vulnerability is in x86 assembly.
# For a list of CPU architecture strings, see the "platforms" crate:
# <https://docs.rs/platforms/latest/platforms/target/enum.Arch.html>
#arch = ["x86", "x86_64"]

# Operating systems impacted by this vulnerability (optional)
# Only use this if the vulnerable is specific to a particular OS, e.g. it was
# located in a binding to a Windows-specific API.
# For a list of OS strings, see the "platforms" crate:
# <https://docs.rs/platforms/latest/platforms/target/enum.OS.html>
#os = ["windows"]

# Table of canonical paths to vulnerable functions (optional)
# mapping to which versions impacted by this advisory used that particular
# name (e.g. if the function was renamed between versions). 
# The path syntax is `cratename::path::to::function`, without any
# parameters or additional information, followed by a list of version reqs.
functions = { "mycrate::MyType::vulnerable_function" = ["< 1.2.0, >= 1.1.0"] }

# Versions which include fixes for this vulnerability (mandatory)
[versions]
patched = [">= 1.2.0"]

# Versions which were never vulnerable (optional)
#unaffected = ["< 1.1.0"]

License

All content in this repository is placed in the public domain.

Author: RustSec
Source Code: https://github.com/RustSec/advisory-db/
License: View license

#rust

曾俊

1648532820

Chrome OS Flex 系统最新安装教程

谷歌出品！Chrome OS Flex 系统最新安装教程，让你的老旧电脑充满活力！完全免费，适合PC / Mac等设备

1.Chrome OS Flex 官网：【点击进入】

2.Chromebook 恢复工具：【点击下载】

#chrome #os

津田直子

1648035420

【毎日Python】Pythonでディレクトリパスとファイル名に分割｜os.path.split

import os

current_dir = os.getcwd()
path = os.path.join(current_dir, "sample")
file_path = os.path.join(path, "A.csv")

file_path

Pythonでディレクトリ名とファイル名に分割する方法です。
Pythonのosモジュールのpath.splitを使います。
今回は、このファイルパスを分割します。

import os
dir_name,file_name = os.path.split(file_path)

必須の引数はファイルパスです。
返り値は2つです。
最初の返り値がディレクトリ名で、次の返り値がファイル名です。
dir_nameと、file_nameという変数に代入しましょう。
実行します。
代入されているか確認してみましょう。

dir_name

uage-python">file_name

▼書き起こしブログ
https://kino-code.com/python_os_path_split/

#python #os.path.split

【毎日Python】Pythonでディレクトリパスとファイル名に分割｜os.path.split

津田直子

1648024560

【毎日Python】Pythonでファイルを削除する

import os
os.remove('test.txt')

pythonでファイルを削除する方法です。
使用する関数は、Pythonのosモジュールのremoveメソッドです。
必須の引数は、削除したいファイルパスです。
実行します。
ファイルが削除できました。
なお、removeメソッドでは、ディレクトリ、つまり、フォルダは削除できません。
ディレクトリを削除する方法には、rmdirやremovedirs、rmtreeを使います。
空のフォルダを削除したい場合は、rmdirやremovedirsを使います。
空ではないフォルダを削除するにはshutilのrmtreeを使います。

import glob
file_names = glob.glob('./sample03/*.csv')

for file_name in file_names:
    os.remove(file_name)

このremoveとglobを使うと、特定の拡張子のみ削除することができます。
sample03のフォルダにはcsvファイルとtxtファイルの2つが混在しています。
csvファイルのみ削除してみましょう。
まず、globでcsvファイル飲み取得します。
それをfor文で回してremoveで削除します。
実行します。
削除されました。

▼書き起こしブログ
https://kino-code.com/python_os_remove/

#python #os.remove

touchHLE: high-level emulator for iPhone OS apps

Important disclaimer

Platform support

Development status

App support

Download Details:

Docker-OSX ·

Quick Start Docker-OSX

Any questions, ideas, or just want to hang out?

Catalina

Big Sur

Monterey

Ventura

Run Catalina Pre-Installed

Older Systems

High Sierra

Mojave

Download the image manually and use it in Docker

Use your own image and manually and automatically log into a shell

Connect to a host running usbfluxd

Make container FASTER using https://github.com/sickcodes/osx-optimizer

Increase disk space by moving /var/lib/docker to external drive, block storage, NFS, or any other location conceivable.

Important notices:

Technical details

Capabilities

Requirements

TODO

Docker

Kubernetes

Support

Small questions & issues

Resolved issues

Feature requests and updates

Professional support

License/Contributing

Other cool Docker/QEMU based projects

Disclaimer

Container images

Already set up or just looking to make a container quickly? Check out our quick start or see a bunch more use cases under our container creation examples section.

Initial setup

I'd like to run Docker-OSX on Windows

Additional boot instructions for when you are creating your container

Troubleshooting

Routine checks

Confirm that your CPU supports virtualization

Docker Unknown Server OS error

Use more CPU Cores/SMP

Confirm your user is part of the the Docker group, KVM group, libvirt group

Add yourself to the Docker group

Is the docker daemon enabled?

More Questions and Answers

Start the same container later (persistent disk)

I have used Docker-OSX before and want to restart a container that starts automatically

LibGTK errors "connection refused"

Permissions denied error

RAM over-allocation

PulseAudio

Use PulseAudio for sound

PulseAudio debugging

PulseAudio with WSLg

Forward additional ports (nginx hosting example)

Bridged networking

Enable IPv4 forwarding for bridged network connections for remote installations

Share folder with Docker-OSX QEMU macOS

Share Linux NFS Drive into macOS

Share USB Drive into macOS over QEMU

Mount USB Drive (Hotplug/Hot Plug USB)

Mount USB Drive inside macOS at boot Docker OSX

Fedora: enable internet connectivity with a bridged network

Nested Hardware Virtualization

Virtual network adapters

Fast internet connectivity

Slow internet connectivity

CI/CD Related Improvements

Tips for reducing the size of the image

Run Docker-OSX headlessly with Telnet

What mirrors are appropriate to use to build Docker-OSX locally?

Custom QEMU Arguments (passthrough devices)

Generating serial numbers

Getting started with serial numbers

What is `${DISPLAY:-:0.0}`?

What is `-v /tmp/.X11-unix:/tmp/.X11-unix`?