Evaluating TOON in a Real-World Scenario

Token-Oriented Notation (abbreviated as TOON) is the concept of rewriting JSON in such a way that fewer characters, and thus fewer tokens, are generated. The concept is explained in more detail at https://toonformat.dev/, and a simple example is shown below. When querying the systemd-mcp server for all inactive services on a system, the output without TOON is as follows:

{
  "users": [
    { "id": 1, "name": "Alice", "role": "admin" },
    { "id": 2, "name": "Bob", "role": "user" }
  ]
}

This representation, which uses 119 characters, is reduced to 53 characters when using TOON:

users[2]{id,name,role}:
  1,Alice,admin
  2,Bob,user

See also the systemd example at the end of this post.

Because token savings are a direct way to reduce AI inference costs, improve response times (by decreasing latency), and allow better utilization of the context window, this approach seems like an easy win. Still, changing the fundamental response format of the MCP server may also have downsides. Therefore, I decided to perform some real-world experiments to determine if there are any downsides, the most severe of which would be incorrect responses from the LLM or an increased number of tool calls that nullify the token savings.

MCP Server and Implementation

As I was working on the systemd-mcp server (https://github.com/openSUSE/systemd-mcp), I decided to use this project as a base.

Since the standard Go implementation of MCP (https://github.com/modelcontextprotocol/go-sdk) does not support TOON yet, I used toon-context-mcp (https://github.com/aj-geddes/toon-context-mcp). The integration is relatively straightforward: the primary payload of an MCP tool response is a text field containing the internal structure marshaled as JSON. Thus, this text field is now marshaled using TOON, while the outer JSON structure used for communication between the MCP server and client remains intact.

Testbed

Creating the testbed was slightly more involved and required some refinement. First, the MCP server requires a real, live-running systemd process to connect to. A reproducible and secure solution is to run it inside a virtual machine (VM). The OpenTofu (open-source Terraform) configuration, available at https://github.com/mslacken/EvalToon/blob/main/tofu/leap-cloud.tf, provisions an openSUSE Tumbleweed cloud image that is configured via cloud-init.

A notable side quest was deploying the systemd-mcp binary to the VM. Compiling it on the VM itself would consume excessive CPU cycles and time, and using the RPM package was not viable because the TOON changes had not been pushed upstream yet. The canonical way to copy a binary to a VM would simply be to copy the file using scp. However, I chose not to use this approach because the SSH server was disabled, and I wanted to assign fixing the SSH service as a task for the LLM itself. This left several possibilities (among others):

• Using a 9p or similar shared filesystem
• Using a read-only filesystem containing only the binary

Since the 9p solution requires absolute paths in the cloud-init configuration, I chose to create a second virtual disk containing the pre-compiled binary. Upon booting the VM, the setup script uses dd to dump the binary into the root filesystem.

The setup script also stopped the SSH service, creating the broken configuration that serves as our “FIX” task testbed.

Agent

To connect the MCP server to the LLM, which was hosted on a remote Ollama instance, I used the Google Agent Development Kit (ADK) (https://adk.dev) to manage the agent execution loops.

Although ADK supports external logging, it can also log events to a local SQLite database. This database is critical for our analysis, allowing us to extract the relevant metrics: the number of prompt (input) tokens presented to the LLM, candidate (output) tokens generated by the LLM, the number of tool calls, and the total number of Ollama API calls.

LLM

The external Ollama instance ran a gemma4 model with 31.3B parameters and Q4_K_M quantization, with a temperature of 1.0 and a context window of 131,072 tokens.

Experiments

The following three queries were presented to the LLM:

• “Check if sshd is running” (labeled as CHECK)
• “List me running services on the system and which services can be started” (labeled as LIST)
• “I can’t login, fix this!” (labeled as FIX)

The first two tasks are relatively simple, primarily establishing baseline performance and token usage. In contrast, the final query (FIX) requires a multi-step troubleshooting approach with several tool calls, testing how TOON performs in a complex, real-world agentic scenario.

For each query, I conducted 30 independent runs with and without TOON enabled.

Results

The results are summarized in the table below:

As can be seen from the table, using TOON reduces both the prompt tokens presented to the LLM and the candidate tokens generated by it. It is somewhat surprising that using TOON consistently leads to fewer generated tokens, suggesting a trend where the length of the LLM’s output correlates with the volume of the input context.

For the simple query (CHECK), where the LLM is only tasked with checking if SSH is running, using TOON does not yield a significant difference. This is because the vast majority of the tokens are consumed by the system prompt and the schemas/descriptions of the available tools.

For the service listing query (LIST), which outputs a large volume of systemd units, TOON performed slightly worse. This was due to a minor increase in the mean number of tool calls during TOON runs, which subsequently increased both prompt and generated tokens.

Figure 1a: Number of tool and Ollama calls of the FIX task (with outliers)

Figure 1b: Number of tool and Ollama calls of the FIX_TOON task (without outliers)

Figure 2a: Number of generated tokens for FIX (outliers visible)

Figure 2b: Number of generated tokens for FIX_TOON (more compact distribution)

For the most complex task (FIX), which requires the LLM to identify the stopped SSH service and start it, the compact representations provided by TOON have the most significant impact. This is reflected not only in the reduced token counts presented to the LLM, but also in more efficient tool utilization, preventing the agent from going off-course as it often did when using raw JSON.

Not using pure JSON does not hinder the LLM; instead, the more efficient utilization of the context window appears to be highly superior.

Summary

Although using TOON for simple tasks does not seem to make a significant difference—as most tokens are spent on the system prompt and MCP server descriptions—it performs superiorly when applied to complex tasks, keeping the LLM more focused. This is likely because the increased information density reduces distracting overhead, enhancing reasoning performance on complex, multi-step operations.

Links

• EvalToon Repository
• systemd-mcp Repository

systemd example

state: inactive

{
state:

"inactive"

units:[
0: "systemd-battery-check.service"
1: "emergency.service"
2: "initrd.target"
3: "dm-event.service"
4: "check-battery.service"
5: "apt-daily.service"
6: "plymouth-start.service"
7: "rc-local.service"
8: "boot.automount"
9: "ip6tables.service"
10: "boot.mount"
11: "blockdev@dev-disk-by\x2duuid-41b87736\x2d08cc\x2d6bd0\x2d85de\x2dd844cd161676.target"
12: "systemd-soft-reboot.service"
13: "firewalld.service"
14: "plymouth-quit.service"
15: "blockdev@dev-vda2.target"
16: "remote-cryptsetup.target"
17: "dracut-pre-pivot.service"
18: "modprobe@fuse.service"
19: "modprobe@efi_pstore.service"
20: "dracut-cmdline.service"
21: "lvm2-lvmpolld.service"
22: "dracut-pre-mount.service"
23: "initrd-root-device.target"
24: "YaST2-Second-Stage.service"
25: "systemd-repart.service"
26: "cryptsetup-pre.target"
27: "emergency.target"
28: "umount.target"
29: "systemd-hostnamed.service"
30: "nss-lookup.target"
31: "dracut-initqueue.service"
32: "initrd-parse-etc.service"
33: "shutdown.target"
34: "soft-reboot.target"
35: "initrd-switch-root.service"
36: "issue-generator.service"
37: "iptables.service"
38: "veritysetup-pre.target"
39: "backup-sysconfig.service"
40: "dev-ttyAMA0.device"
41: "initrd-usr-fs.target"
42: "systemd-modules-load.service"
43: "initrd-root-fs.target"
44: "systemd-tpm2-setup-early.service"
45: "final.target"
46: "systemd-hibernate-resume.service"
47: "audit-rules.service"
48: "xdm.service"
49: "nss-user-lookup.target"
50: "initrd-switch-root.target"
51: "home.mount"
52: "poweroff.target"
53: "systemd-firstboot.service"
54: "blockdev@dev-disk-by\x2duuid-BE2D\x2dB7C2.target"
55: "remote-fs-pre.target"
56: "ntpd.service"
57: "systemd-rfkill.service"
58: "logrotate.service"
59: "systemd-udev-settle.service"
60: "ebtables.service"
61: "systemd-tmpfiles-clean.service"
62: "serial-getty@ttyS2.service"
63: "getty-pre.target"
64: "remote-veritysetup.target"
65: "apache2.target"
66: "apparmor.service"
67: "proc-sys-fs-binfmt_misc.mount"
68: "sysroot.mount"
69: "modprobe@configfs.service"
70: "ca-certificates.service"
71: "systemd-poweroff.service"
72: "rescue.target"
73: "systemd-journald-audit.socket"
74: "nftables.service"
75: "rescue.service"
76: "fstrim.service"
77: "systemd-ask-password-console.service"
78: "systemd-hibernate-clear.service"
79: "dracut-mount.service"
80: "systemd-timesyncd.service"
81: "modprobe@drm.service"
82: "wicked.service"
83: "systemd-pstore.service"
84: "systemd-binfmt.service"
85: "initrd-cleanup.service"
86: "sshd.service"
87: "syslog.service"
88: "display-manager.service"
89: "systemd-quotacheck-root.service"
90: "initrd-udevadm-cleanup-db.service"
91: "boot-sysctl.service"
92: "systemd-networkd-wait-online.service"
93: "hv_kvp_daemon.service"
94: "initrd-fs.target"
95: "serial-getty@ttyS1.service"
96: "ipset.service"
97: "dracut-pre-udev.service"
98: "backup-rpmdb.service"
99: "dracut-pre-trigger.service"
100: "dracut-shutdown-onfailure.service"
101: "serial-getty@ttyAMA0.service"
102: "wtmpdb-rotate.service"
103: "syslog.socket"
104: "plymouth-quit-wait.service"
105: "sshd-keygen.service"
106: "wtmpdbd.service"
]
}

units[107]: systemd-repart.service,ntpd.service,boot-sysctl.service,systemd-journald-audit.socket,initrd-fs.target,systemd-tpm2-setup-early.service,apparmor.service,systemd-pstore.service,backup-sysconfig.service,iptables.service,systemd-modules-load.service,modprobe@drm.service,dev-ttyAMA0.device,modprobe@efi_pstore.service,issue-generator.service,nss-lookup.target,syslog.service,getty-pre.target,final.target,initrd-usr-fs.target,systemd-hibernate-resume.service,systemd-ask-password-console.service,syslog.socket,sshd.service,modprobe@configfs.service,poweroff.target,ebtables.service,rescue.target,emergency.target,sysroot.mount,ip6tables.service,rc-local.service,blockdev@dev-vda2.target,systemd-rfkill.service,apt-daily.service,dracut-initqueue.service,serial-getty@ttyAMA0.service,check-battery.service,systemd-timesyncd.service,soft-reboot.target,apache2.target,home.mount,systemd-poweroff.service,nftables.service,lvm2-lvmpolld.service,dracut-shutdown-onfailure.service,plymouth-quit-wait.service,systemd-udev-settle.service,serial-getty@ttyS2.service,systemd-hibernate-clear.service,boot.automount,YaST2-Second-Stage.service,plymouth-start.service,initrd-udevadm-cleanup-db.service,dracut-pre-mount.service,nss-user-lookup.target,serial-getty@ttyS1.service,wicked.service,systemd-battery-check.service,initrd-parse-etc.service,emergency.service,hv_kvp_daemon.service,ca-certificates.service,systemd-soft-reboot.service,backup-rpmdb.service,modprobe@fuse.service,dracut-pre-trigger.service,dm-event.service,plymouth-quit.service,"blockdev@dev-disk-by\\x2duuid-BE2D\\x2dB7C2.target",audit-rules.service,rescue.service,initrd-root-device.target,systemd-firstboot.service,"blockdev@dev-disk-by\\x2duuid-41b87736\\x2d08cc\\x2d6bd0\\x2d85de\\x2dd844cd161676.target",shutdown.target,remote-veritysetup.target,initrd-root-fs.target,initrd.target,display-manager.service,wtmpdb-rotate.service,systemd-hostnamed.service,remote-cryptsetup.target,dracut-pre-udev.service,systemd-quotacheck-root.service,initrd-switch-root.target,dracut-pre-pivot.service,proc-sys-fs-binfmt_misc.mount,systemd-binfmt.service,ipset.service,remote-fs-pre.target,umount.target,boot.mount,veritysetup-pre.target,dracut-mount.service,dracut-cmdline.service,sshd-keygen.service,initrd-switch-root.service,fstrim.service,wtmpdbd.service,cryptsetup-pre.target,logrotate.service,initrd-cleanup.service,systemd-tmpfiles-clean.service,firewalld.service,systemd-networkd-wait-online.service,xdm.service"

Raw data

CHECK

# query prom_tokens cand_tokens tot_tokens tool_calls ollama_calls
"Check if sshd is running" 11936 289 12225 2 3
"Check if sshd is running" 7732 143 7875 1 2
"Check if sshd is running" 11788 257 12045 2 3
"Check if sshd is running" 11785 250 12035 2 3
"Check if sshd is running" 12056 379 12435 2 3
"Check if sshd is running" 11875 310 12185 2 3
"Check if sshd is running" 11802 238 12040 2 3
"Check if sshd is running" 11819 277 12096 2 3
"Check if sshd is running" 11825 285 12110 2 3
"Check if sshd is running" 11807 266 12073 2 3
"Check if sshd is running" 11909 325 12234 2 3
"Check if sshd is running" 11788 248 12036 2 3
"Check if sshd is running" 11786 275 12061 2 3
"Check if sshd is running" 11754 211 11965 2 3
"Check if sshd is running" 7786 195 7981 1 2
"Check if sshd is running" 7736 215 7951 1 2
"Check if sshd is running" 12026 597 12623 2 3
"Check if sshd is running" 11778 263 12041 2 3
"Check if sshd is running" 7827 225 8052 1 2
"Check if sshd is running" 7733 138 7871 1 2
"Check if sshd is running" 11843 284 12127 2 3
"Check if sshd is running" 11798 248 12046 2 3
"Check if sshd is running" 7719 132 7851 1 2
"Check if sshd is running" 7856 255 8111 1 2
"Check if sshd is running" 11901 309 12210 2 3
"Check if sshd is running" 11823 262 12085 2 3
"Check if sshd is running" 11836 284 12120 2 3
"Check if sshd is running" 7733 151 7884 1 2
"Check if sshd is running" 11861 301 12162 2 3
"Check if sshd is running" 7735 143 7878 1 2

CHECK_TOON

 query prom_tokens cand_tokens tot_tokens tool_calls ollama_calls
"Check if sshd is running" 11843 283 12126 2 3
"Check if sshd is running" 7831 241 8072 1 2
"Check if sshd is running" 11842 305 12147 2 3
"Check if sshd is running" 7801 213 8014 1 2
"Check if sshd is running" 11753 237 11990 2 3
"Check if sshd is running" 11742 216 11958 2 3
"Check if sshd is running" 11825 282 12107 2 3
"Check if sshd is running" 7809 221 8030 1 2
"Check if sshd is running" 7774 187 7961 1 2
"Check if sshd is running" 11824 264 12088 2 3
"Check if sshd is running" 7736 148 7884 1 2
"Check if sshd is running" 11789 248 12037 2 3
"Check if sshd is running" 11980 351 12331 2 3
"Check if sshd is running" 11778 247 12025 2 3
"Check if sshd is running" 11766 208 11974 2 3
"Check if sshd is running" 7842 248 8090 1 2
"Check if sshd is running" 11770 234 12004 2 3
"Check if sshd is running" 7755 163 7918 1 2
"Check if sshd is running" 11730 210 11940 2 3
"Check if sshd is running" 11809 257 12066 2 3
"Check if sshd is running" 11835 279 12114 2 3
"Check if sshd is running" 7843 240 8083 1 2
"Check if sshd is running" 11850 288 12138 2 3
"Check if sshd is running" 11820 264 12084 2 3
"Check if sshd is running" 7786 199 7985 1 2
"Check if sshd is running" 7757 165 7922 1 2
"Check if sshd is running" 7820 217 8037 1 2
"Check if sshd is running" 11758 236 11994 2 3
"Check if sshd is running" 11897 306 12203 2 3
"Check if sshd is running" 11750 226 11976 2 3

LIST

# query prom_tokens cand_tokens tot_tokens tool_calls ollama_calls
"List me running services on the system and which services can be started" 12347 725 13072 2 2
"List me running services on the system and which services can be started" 12437 864 13301 2 2
"List me running services on the system and which services can be started" 12421 2120 14541 2 2
"List me running services on the system and which services can be started" 12429 2683 15112 2 2
"List me running services on the system and which services can be started" 12398 2366 14764 2 2
"List me running services on the system and which services can be started" 8976 2675 11651 2 2
"List me running services on the system and which services can be started" 12400 2119 14519 2 2
"List me running services on the system and which services can be started" 12449 1946 14395 2 2
"List me running services on the system and which services can be started" 8947 2458 11405 2 2
"List me running services on the system and which services can be started" 8902 2481 11383 2 2
"List me running services on the system and which services can be started" 8884 1303 10187 2 2
"List me running services on the system and which services can be started" 8898 1386 10284 2 2
"List me running services on the system and which services can be started" 8953 2538 11491 2 2
"List me running services on the system and which services can be started" 12418 829 13247 2 2
"List me running services on the system and which services can be started" 9046 1268 10314 2 2
"List me running services on the system and which services can be started" 9343 984 10327 3 2
"List me running services on the system and which services can be started" 12532 2220 14752 2 2
"List me running services on the system and which services can be started" 8934 1609 10543 2 2
"List me running services on the system and which services can be started" 12364 869 13233 2 2
"List me running services on the system and which services can be started" 8990 1816 10806 2 2
"List me running services on the system and which services can be started" 12399 2011 14410 2 2
"List me running services on the system and which services can be started" 8883 924 9807 2 2
"List me running services on the system and which services can be started" 8968 2432 11400 2 2
"List me running services on the system and which services can be started" 12343 2084 14427 2 2
"List me running services on the system and which services can be started" 12405 1481 13886 2 2
"List me running services on the system and which services can be started" 12342 1761 14103 2 2
"List me running services on the system and which services can be started" 12450 727 13177 2 2
"List me running services on the system and which services can be started" 12324 582 12906 2 2
"List me running services on the system and which services can be started" 9472 2749 12221 3 2
"List me running services on the system and which services can be started" 9184 2423 11607 3 2

LIST_TOON

# query prom_tokens cand_tokens tot_tokens tool_calls ollama_calls
"List me running services on the system and which services can be started" 12341 2520 14861 2 2
"List me running services on the system and which services can be started" 12362 621 12983 2 2
"List me running services on the system and which services can be started" 12384 1374 13758 2 2
"List me running services on the system and which services can be started" 12326 1977 14303 2 2
"List me running services on the system and which services can be started" 8987 2383 11370 3 2
"List me running services on the system and which services can be started" 8914 2509 11423 2 2
"List me running services on the system and which services can be started" 12389 2127 14516 2 2
"List me running services on the system and which services can be started" 12568 789 13357 2 2
"List me running services on the system and which services can be started" 12376 1963 14339 2 2
"List me running services on the system and which services can be started" 8885 1814 10699 2 2
"List me running services on the system and which services can be started" 12481 1995 14476 2 2
"List me running services on the system and which services can be started" 12366 2294 14660 2 2
"List me running services on the system and which services can be started" 8875 1692 10567 2 2
"List me running services on the system and which services can be started" 9034 2344 11378 2 2
"List me running services on the system and which services can be started" 12531 2390 14921 2 2
"List me running services on the system and which services can be started" 12335 1998 14333 2 2
"List me running services on the system and which services can be started" 12444 684 13128 2 2
"List me running services on the system and which services can be started" 12445 1775 14220 2 2
"List me running services on the system and which services can be started" 29548 857 30405 3 4
"List me running services on the system and which services can be started" 12331 1720 14051 2 2
"List me running services on the system and which services can be started" 8982 2211 11193 2 2
"List me running services on the system and which services can be started" 12477 2182 14659 2 2
"List me running services on the system and which services can be started" 12400 1448 13848 2 2
"List me running services on the system and which services can be started" 9244 1857 11101 2 2
"List me running services on the system and which services can be started" 8882 825 9707 2 2
"List me running services on the system and which services can be started" 9078 2073 11151 2 2
"List me running services on the system and which services can be started" 12549 936 13485 2 2
"List me running services on the system and which services can be started" 12466 1201 13667 2 2
"List me running services on the system and which services can be started" 9021 1732 10753 2 2
"List me running services on the system and which services can be started" 12377 2267 14644 2 2

FIX

"I can't login, fix this!" 41367 964 42331 8 9
"I can't login, fix this!" 25606 619 26225 5 6
"I can't login, fix this!" 22251 816 23067 6 5
"I can't login, fix this!" 22130 613 22743 4 5
"I can't login, fix this!" 26780 748 27528 5 6
"I can't login, fix this!" 112901 943 113844 9 10
"I can't login, fix this!" 54626 753 55379 7 8
"I can't login, fix this!" 25405 547 25952 5 6
"I can't login, fix this!" 16866 615 17481 4 4
"I can't login, fix this!" 59437 958 60395 7 8
"I can't login, fix this!" 33176 929 34105 6 7
"I can't login, fix this!" 16453 489 16942 3 4
"I can't login, fix this!" 26306 611 26917 5 6
"I can't login, fix this!" 22935 913 23848 5 5
"I can't login, fix this!" 84688 2655 87343 13 8
"I can't login, fix this!" 25757 641 26398 5 6
"I can't login, fix this!" 31397 853 32250 6 7
"I can't login, fix this!" 26691 695 27386 5 6
"I can't login, fix this!" 27273 794 28067 5 6
"I can't login, fix this!" 94618 2614 97232 15 16
"I can't login, fix this!" 31886 777 32663 6 7
"I can't login, fix this!" 25962 551 26513 5 6
"I can't login, fix this!" 26899 745 27644 5 6
"I can't login, fix this!" 25976 662 26638 5 6
"I can't login, fix this!" 25531 537 26068 5 6
"I can't login, fix this!" 54975 793 55768 7 8
"I can't login, fix this!" 26921 748 27669 5 6
"I can't login, fix this!" 26531 778 27309 5 6
"I can't login, fix this!" 36614 712 37326 6 5
"I can't login, fix this!" 24196 1074 25270 6 5

FIX_TOON

# query prom_tokens cand_tokens tot_tokens tool_calls ollama_calls
"I can't login, fix this!" 26317 581 26898 5 6
"I can't login, fix this!" 20708 494 21202 4 5
"I can't login, fix this!" 18571 1030 19601 7 4
"I can't login, fix this!" 30497 782 31279 6 7
"I can't login, fix this!" 22412 689 23101 5 5
"I can't login, fix this!" 22012 647 22659 6 5
"I can't login, fix this!" 37325 1379 38704 10 7
"I can't login, fix this!" 26394 651 27045 5 6
"I can't login, fix this!" 55580 956 56536 7 8
"I can't login, fix this!" 31431 680 32111 6 7
"I can't login, fix this!" 28580 820 29400 5 6
"I can't login, fix this!" 36118 839 36957 7 8
"I can't login, fix this!" 22785 770 23555 5 5
"I can't login, fix this!" 20158 346 20504 4 5
"I can't login, fix this!" 26159 567 26726 5 6
"I can't login, fix this!" 63605 875 64480 8 9
"I can't login, fix this!" 47181 935 48116 7 5
"I can't login, fix this!" 41776 856 42632 8 9
"I can't login, fix this!" 21752 585 22337 6 5
"I can't login, fix this!" 53449 707 54156 7 8
"I can't login, fix this!" 26152 730 26882 5 6
"I can't login, fix this!" 22470 704 23174 4 5
"I can't login, fix this!" 74308 1094 75402 9 10
"I can't login, fix this!" 27106 769 27875 5 6
"I can't login, fix this!" 26527 688 27215 5 6
"I can't login, fix this!" 26470 682 27152 5 6
"I can't login, fix this!" 27317 818 28135 5 6
"I can't login, fix this!" 37025 960 37985 7 8
"I can't login, fix this!" 27619 765 28384 6 6
"I can't login, fix this!" 26177 598 26775 5 6

openSUSE Leap Micro was the last to the party to receive the extended openSUSE signing key following its recent expiration. We’re deeply sorry for the inconvenience. The underlying issue has now been resolved everywhere.

If your system still encounters repository signature errors, you can refresh the repository metadata and fetch the updated signing key manually.

The zypper ref -f command forces a refresh of the repository metadata, including the new GPG signing key. Normally this should happen automatically, but the current version of libzypp may not always retrieve the updated key correctly. Forcing a refresh resolves the problem. Just to note that the zypper ref -f will force new key on any openSUSE distribution.

Run the following commands:

transactional-update shell
zypper ref -f
zypper dup
exit # from tu shell

After rebooting into the new snapshot, your system should be using the updated signing key and repository refreshes should work normally again.

Have a lot of fun!

In my previous post I covered the template refactor for the obs-status-service SVG generation. That work was reviewed and merged into main (PR #364). Building on top of that, I’ve opened a follow-up PR (#402) that focuses on two things: making the SVG badges visually consistent with Gitea’s UI and making them responsive for large projects.

Native Gitea Colors

The old SVGs used hardcoded colors that looked out of place next to Gitea’s UI. I extracted the real CSS variables from Gitea’s dark and light themes and embedded them directly into the SVG templates. Now the badges blend in naturally with the rest of the page, and they automatically switch between light and dark mode using the ?theme= parameter.

Responsive Compact Mode

The project matrix view works great when there are a few repositories, but some projects like openSUSE:Tools have dozens of repo/arch combinations. The full matrix becomes too wide for any screen.

To solve this I added a ?compact=true|false|auto parameter. In compact mode:

• Column headers are rotated 90° to take up less horizontal space.
• Badge text is hidden, leaving only colored squares.
• Column width shrinks from 155px to 32px.

The auto mode (the default) activates compact mode automatically when the matrix would exceed 800px wide or when there are more than 4 repositories. This is calculated server-side before generating the SVG, since CSS @media queries cannot resize an SVG’s viewBox when it’s embedded as an <img>.

Dynamic Layout

Long package names like 000product:openSUSE-Addon-NonOss-ftp-ftp-x86_64 used to overflow and overlap with the status cells. Now both the label column width and the header height are calculated dynamically based on the longest text string, so nothing gets cut off regardless of the data.

Side-by-side Comparisons

To verify the improvements, I wrote a Go test that fetches live build data from the OBS public API and generates SVGs with both the old production code (downloaded via HTTP from br.opensuse.org) and the new template-based renderer. Here are some examples using the projects my mentor dgarcia suggested:

Project Summary: devel:languages:python:Factory

obs-status-service (old):

obs-status-service (new):

Package: devel:languages:python:Factory / python313

Before:

After:

Badge: openSUSE:Factory / python313:base / standard / x86_64

Before:

After:

Matrix View: devel:languages:python:Factory

gitexplorer (interactive):

obs-status-service (new):

What’s Next

The template refactor PR #364 has been merged into main. The Gitea color integration and compact mode are in review in PR #402.

The next step is exploring JavaScript inside SVGs so that badges can update themselves in real time without reloading the page.

Infrastructure runs on Linux, and Linux hardware is only as good as the software that builds, packages, signs and distributes its drivers and libraries, work that has to happen across dozens of distributions and several CPU architectures, every single day.

That work has a home. The openSUSE Project has spent years assembling a development structure that hardware vendors and enterprises now lean on:

• Open Build Service compiles a single source tree into signed packages for nearly any distribution or architecture;
• openQA boots and tests the results the way a real user would;
• The rolling release Tumbleweed and stable Leap distributions serve as both upstream and supporting structure for Enterprise as a proving ground and downstream anchor;
• Uyuni Project, the upstream of SUSE Multi-Linux Manager pioneers the space that keeps deployed fleets patched and accounted for long after the packages ship.

Together, these answer the question every hardware maker eventually faces; build once, validate everywhere and deliver with confidence.

Companies whose revenue depends on silicon “just working” in Linux data centers may evaluate funding this layer as an investment, not as charity. It is one of the highest-leverage, lowest-cost investments available. But communities like openSUSE depend on sponsors so that the contributing community can grow, support and thrive.

SUSE is the primary sponsor of openSUSE, and the project has other companies that sponsor the project. The project welcomes additional backers. Sponsorship takes three practical forms; money, hardware, or services. Sponsorship has historically been organized into tiers: Platinum, Gold, and Silver. The sponsors gain visibility and developer reach. Hardware sponsors sign an Equipment Donation Agreement. Services provided to contributing developers make development more efficient. And the Geeko Foundation, a not-for-profit, acts as fiscal steward, receiving and administering funds on the project’s behalf to support contributors, travel and events.

The return on a sponsorship

1. The whole ecosystem, not just one distro

OBS builds on the order of 140,000 packages for more than a dozen base distributions across many architectures. A vendor that donates silicon and sponsors build capacity gets its drivers and libraries built and validated across that entire matrix; Fedora, Debian, Ubuntu, the SUSE family and more.

This is not a static archive. In a typical week, Tumbleweed absorbs on the order of 500 accepted change requests, moving Mesa, the Linux kernel, QEMU, GCC, LLVM, Rust, GNOME and KDE forward in lockstep. Paying engineers to chase each target distribution independently is expensive; the same result comes far more cost-effectively from developers already working inside the openSUSE ecosystem. Hardware that works on Linux ships and sells faster.

2. Silicon QA at scale

Packaging is only half the problem; the other half is testing. That is where openQA comes in; openSUSE’s automated OS-testing service, which boots real images and drives real installs.

Pair it with sponsored hardware and a vendor’s drivers get exercised continuously: every snapshot, every architecture, in front of tens of thousands of real users doing unpredictable things. The value shows in the ordinary weekly record; compiler transitions caught in dedicated staging projects before they reach users, individual test failures tracked down to a specific step in a specific run, unresolvable dependencies counted and driven back down. Regressions surface on actual silicon earlier, and far more cheaply, than any internal lab could manage.

3. Growing the architecture your chips are trying to sell

openSUSE does not treat arm as an afterthought. Tumbleweed on arm rolls continuously alongside x86, with its own openQA coverage, and a dedicated ARMv9 project rebuilds the core of the distribution to take advantage of the newer baseline. s390x is maintained in parallel. A chipmaker sponsoring arm build capacity is directly cultivating the soil its own products grow in. And would be doing it where the architecture is already a first-class citizen rather than a port.

4. Faster driver delivery, fewer support tickets

The model already exists: openSUSE’s NVIDIA driver packages are maintained by SUSE engineers, with spec files living in OBS and coordinated with NVIDIA. A factory first policy, where development happens upstream, deepens that relationship. Dedicated hardware, closer coordination and sponsored maintainer time all shorten the lag between a driver release and users actually being able to install it. Every week shaved off that cycle is support load a vendor never has to absorb.

5. Strategic influence on neutral ground, without lock-in

OBS, openQA and Uyuni are deliberately vendor-neutral. None is tied to a single vendor’s product line; all three build, test and manage systems well beyond the SUSE family. For a chipmaker, neutrality is the point; sponsorship keeps the packaging pipeline healthy and open, so no single competitor ends up controlling how silicon reaches Linux.

Uyuni is upstream of SUSE Multi-Linux Manager, and that relationship cuts the way a sponsor should want: the upstream project sets direction and the commercial product follows, not the reverse. It’s the same arrangement that governs most of the Linux stack a vendor already ships on. A sponsor influences the open project and gets the benefit downstream, without buying into any vendor’s roadmap.

6. Developer mindshare, ISV reach, and recruiting

Sponsorship has always carried visibility in front of the developers and independent software vendors who decide what runs where. In a labor market where kernel, driver and systems talent is scarce, presence in the openSUSE community is a recruiting channel and a credibility signal to the wider open-source world.

The bottom line

Put these together and you get a flywheel of mutual benefit. The technology gets built by the community at a fraction of what in-house enablement would cost, and it gets built continuously, in public, with the failures visible and tracked rather than discovered by a customer. The community gets what it needs to keep going: travel to the conferences where the work gets shared, hardware to test on, and infrastructure that grows as fast as the ideas do.

For a business valued in the hundreds of billions, an equipment donation or a sponsored service is a rounding error. It is also one of the cleanest ways a company can fund the building of the technology it sells build on open-source. Donations acknowledging community efforts are also encouraged.

If you are interested in sponsoring openSUSE, we are open to options or suggestions.

Providing space for hosting an openSUSE event or sponsoring the openSUSE Conference provides a unique opportunity to connect with open source users, system administrators, developers, designers, and community leaders. Sponsoring the conference also provides an opportunity to showcase your brand to the open-source knowledge.

For more information, email ddemaio@opensuse.org.

Dear Tumbleweed users and hackers,

This week was quite busy and successful, with 5 snapshots (0709, 0710, 0712, 0714, and 0715) published to our users.

Last week, we promised to put selinux-policy back into the queue after having temporarily reverted it to bypass the openQA failures, and we did just that. It turned out our theory was spot-on! In snapshot 0714, the SELinux Toolchain 3.11 landed, and confirmed our dependency fix for rpm-plugin-selinux was correct

Another noteworthy change is the reversion of the gvim GTK4 build back to GTK3. While we strive to ship the latest technology, the current state of the GTK4 port simply does not live up to the quality promises we give to our users, resulting in clipboard deadlocks. Thus, we chose stability over the shiny new build.

These five snapshots delivered the following updates:

• SELinux Toolchain 3.11 (together with selinux-policy)
• KDE Frameworks 6.28.0
• QEMU 11.0.2
• GStreamer 1.28.5
• Vim 9.2.0780
• PipeWire 1.6.8
• freetype 2.14.3
• poppler 26.07.0
• curl 8.21.0
• git 2.55.0
• BusyBox 1.38.0
• php 8.5.8
• postfix 3.11.5
• timezone 2026c
• kernel-firmware 20260710
• Rust 1.97

Let’s take a look at what we can expect in the coming days and weeks.

• KDE Plasma 6.7.3
• systemd 261.1
• Perl 5.44.0
• linux-glibc-devel 7.1: Last holdup at this time is llvm (15 – 21)
• Podman 6.0.0: Undergoing integration and sync testing with buildah and skopeo. Staging seems to pass, but for this stack we also get some manual testing
• GCC 16 as the default system compiler. If my eyes don’t deceive me, qemu seems to be the last package failing to build

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The community blog feed aggregator lists the featured highlights below from July 10 to 16.

Blogs this week cover the third Plasma 6.7 bugfix release, a SUSE security advisory on SELinux userspace utilities, a call for host proposals for the openSUSE.Asia Summit 2027, syslog-ng packages for Ubuntu 26.04, a keynote recap on open source trust and the Cyber Resilience Act, audio recording arriving in Spectacle, a Meteoclimatic desktop plasmoid, a Krita June development report, Slimbook’s local AI workstation and more.

Here is a summary and links for each post:

Display the Meteoclimatic data on your desktop with this Plasmoid for Plasma 6 from KDE

Victorhck shares information about Plasma 6 plasmoid that visualizes Meteoclimatic weather station data directly on the desktop. Building on an earlier text-mode plasmoid and terminal scripts, this version presents the data with emoji icons for a more elegant and visually appealing display. Victorhck invites users to share screenshots of their configurations on Mastodon.

Nexus AI Workstation, the proposal to have local AI free on Slimbook

The KDE Blog presents Slimbook’s Nexus AI Workstation, a server family designed for running local AI workloads without relying on cloud token subscriptions. The goal is to offer a platform prepared for executing and developing AI workloads locally, combining high performance with the flexibility professionals, companies, researchers and developers demand.

Krita Report June 2026

The KDE Blog covers the June 2026 Krita development report, highlighting releases 5.3.2.1 and 6.0.2.1 that fix severe regressions related to layer selection and crashes when working with wait frames. Krita Plus for Android replaces old contributor badges with downloadable resource packs and a Google Play subscription, along with improved interface scaling, transform tool fixes with multiple layers, and crash fixes when undoing text operations.

Third Bugfix Update for Plasma 6.7

The KDE Blog announces the third bugfix release for Plasma 6.7, delivering stability improvements, better translations, and error resolution across the desktop environment. The post also recaps the major new features of Plasma 6.7, including per-monitor virtual desktops, a microphone volume test tool, quick theme switching, a Vietnamese lunar calendar, and a new print queue manager.

SELinux Userspace Utilities: Local Denial-of-Service Attack Vectors in seunshare

The SUSE Security Team discloses two local denial-of-service vulnerabilities in the seunshare program from SELinux userspace utilities version 3.10. A symlink race condition in rm_rf() allows deletion of root-owned files, while the killall() function can be exploited to kill root-owned processes running in the unconfined SELinux domain. Both issues were independently fixed upstream in version 3.11.

openSUSE.Asia Summit 2027: Call for Host

openSUSE News invites local openSUSE communities across Asia to submit proposals to host the openSUSE.Asia Summit 2027. The proposal deadline is August 10 with the host announcement scheduled for October 31 following presentations at the 2026 summit in Yogyakarta, Indonesia. Proposals should cover venue, transportation, budget, catering, and the local organizing team’s experience.

Syslog-ng 4.12.0 Available for Ubuntu 26.04 (Resolute)

Peter Czanik’s Blog confirms that syslog-ng now supports Ubuntu 26.04 with ready-to-use packages alongside the 4.12.0 release. The post fills a gap in his usual coverage, which tends to focus on FreeBSD, Fedora and openSUSE.

Bare Weather – Weather Information on Your Desktop with Plasmoids for Plasma 6 (35)

The KDE Blog presents Bare Weather, the 35th entry in its Plasma 6 plasmoid series, which delivers interactive weather data directly on the desktop. The widget by corral76 offers two layouts: a card design with animated icons and color-coded headers, and a graph design with scrollable temperature and precipitation curves.

Bash and Fish Scripts to Display Meteoclimatic Weather Station Data

Victorhck shares Bash and Fish terminal scripts that display real-time weather data from Meteoclimatic amateur stations. The scripts use curl and awk with emoji icons to present the information, and the first run prompts for a station ID which is saved to a config file.

This Month in KDE Linux: June 2026

The KDE Blog translates Nate Graham’s monthly progress report on KDE Linux, the community’s upcoming operating system. The project has reached 78 percent completion toward its beta milestone. Updates include Audex replacing the old CD ripping tool, a built-in log collection utility, and UEFI-only boot support.

When the Code Remains Clean but Trust Collapses: The New Era of Open Source

Efstathios summarizes the openSUSE Conference 2026 keynote by Hans de Raad on the intersection of open source security, the Cyber Resilience Act, and AI tooling risks. The post examines the GSD framework incident where clean code masked a collapsed trust chain, drawing parallels to the xz-utils backdoor.

Audio Recording in Spectacle – This Week in Plasma

The KDE Blog translates Nate Graham’s weekly Plasma development update, which highlights audio recording arriving in Spectacle for screen captures in Plasma 6.8. The update also covers VRAM usage display in System Monitor, the Ethiopian calendar addition, improved combobox theming, tablet stylus support for Overview overlays, and numerous bugfix releases across Plasma 6.6.6, 6.7.3, and Frameworks 6.29.

Linux Saloon 209 | Fedora 44

Nathan’s Blog covers the latest Linux and technology news, including the Warthunder Sim Rig hardware build, font management in Linux, and the retirement of the “Father of the Internet.” The episode also discusses Firefox updates, the Steam Machine launch, and Fedora governance changes alongside the Fedora 44 release.

KDE Frameworks 6.28.0 Update

The KDE Blog announces KDE Frameworks 6.28 and continues its series describing each library in the framework collection. This month focuses on KCodecs, a Tier 1 library responsible for character set detection, XML entity translation, and email address validation across KDE applications.

Colors, Graphics, and Performance in Plasma 6.7

The KDE Blog covers the under-the-hood improvements in Plasma 6.7 related to color management, graphics rendering, and energy efficiency. Users can now use ICC color profiles and HDR content simultaneously. There is a new toggle to control reddish tinting at low brightness on AMD laptops. The team also achieved performance gains and reduced power consumption for CPU-rendered applications and Intel integrated GPUs.

openSUSE Tumbleweed Review of Week 28 of 2026

Victorhck and Dominique Leuenberger provide a Spanish and English language review of four Tumbleweed snapshots (0702, 0703, 0707, and 0708) published during the week. Highlights include the removal of Python 3.11 modules while keeping the interpreter and pip, KDE Gear 26.04.3, Plasma 6.7.2, Linux kernel 7.1.2 and 7.1.3, Mesa 26.1.4, and systemd 260.3. Upcoming packages include GStreamer 1.28.5, SELinux toolchain 3.11, and GCC 16 as the default compiler.

View more blogs or learn to publish your own on planet.opensuse.org.

Table of Contents

• 1) Introduction
• 2) Design Overview
• 3) Security Issues
  • 3.1) Local File Deletion Attack Vector in rm_rf() (CVE-2026-59676)
  • 3.2) Process Kill Attack Vector in killall() (CVE-2026-59677)
• 4) Remaining Concerns
• 5) CVE Assignments
• 6) Timeline
• 7) References
• 8) Change History

1) Introduction

The seunshare program is part of the SELinux “sandbox” feature, which is used to confine untrusted programs using Linux mount namespaces and restrictive SELinux policies. The program is designed to be installed with setuid-root privileges, accessible to all users in the system.

We have been asked to review the program’s security with the intention of assigning the setuid bit to it on SUSE distributions in the future. Fedora Linux already ships this program with setuid-root enabled; other SELinux-enabled Linux distributions may do so as well.

During our review of the utility’s code in version 3.10 of the SELinux userspace utilities we identified two local Denial-of-Service attack vectors, which will be described in detail in the following sections. Upstream independently fixed these issues in version 3.11, without clearly marking them as security issues, however.

The rest of this report is based on version 3.10 of the codebase of seunshare.

2) Design Overview

The seunshare program is relatively small, consisting of about 1,000 lines of C code. The elevated root privileges are primarily needed to setup a custom mount namespace for the sandbox environment.

The program accepts a range of command line arguments which, among others, allow to request dedicated directories to be used for the following paths inside the sandbox:

• the user’s home directory.
• the /tmp directory.
• the /run/user/<uid> directory.

For the /run and /tmp directories, the source paths specified by the user are copied into a random temporary directory in the initial mount namespace under /tmp/.sandbox-<label>-XXXXXX using the rsync program. These directories are then bind-mounted into the sandbox’s mount namespace to appear at the expected locations.

A lot of code in seunshare is concerned with securely maintaining these temporary directories. To allow the sandbox environment to modify the directory contents, seunshare assigns group write permissions for the real group ID of the calling user, as shown in this example:

drwxrwx--T. 2 root user 80 Jul  8 16:11 /tmp/.sandbox-user-OaxmUp/

To safely access user-provided paths, the program flips its filesystem UID to the real UID of the calling user and back to root, as needed.

3) Security Issues

Since seunshare is supposed to run on SELinux-enabled systems, it is important to understand what kind of privilege escalation can be achieved when vulnerabilities are exploited in a setuid-root binary like this. Many SELinux-enabled systems, such as Fedora and openSUSE, ship with the “targeted” SELinux policy by default. This policy is focused on confining well-known system services, but assigns an unconfined SELinux context to interactive users by default to achieve a balance between security and usability.

There is currently no domain transition from the unconfined domain to the more restricted seunshare_t defined in the SELinux policy for seunshare. This means the execution of seunshare continues in the unconfined domain. Thus in the context of attacks carried out by interactive users, the impact of the vulnerabilities below will be a root-like privilege escalation despite the system running in SELinux enforced mode.

3.1) Local File Deletion Attack Vector in rm_rf() (CVE-2026-59676)

The function rm_rf() is called at the end of the utility’s execution to recursively remove temporary directory trees. While a comment in the function suggests that no symbolic links would be followed by this routine, the reality is that the openat() system call is lacking the O_NOFOLLOW flag. This creates a race condition during the recursion of the rm_rf() function:

• first an fstatat() is performed for directory contents obtained from readdir() to safely determine whether an entry refers to a sub-directory.
• when a directory is encountered the unsafe openat() happens, allowing the unprivileged user to replace the directory entry by a symbolic link in the meantime. While the O_DIRECTORY flag is passed to openat(), symbolic links in the target are still followed, as long as they point to a directory.

When the user calling seunshare is running in the unconfined SELinux domain, arbitrary root-owned files can be deleted this way. The vulnerability does not allow to delete arbitrary files of other users, however, because seunshare drops all capabilities before calling rm_rf(). This leaves the process in a somewhat strange state of privilege: it can no longer override discretionary access control (DAC) but it is still allowed to operate on files owned by the filesystem-uid of the privileged process, which is 0 during the invocation of rm_rf().

We developed a reproducer for this issue, which succeeds in executing the exploit quickly after some fine tuning of the timing for the target system. We verified that the reproducer works on current openSUSE Tumbleweed with policycoreutils 3.10 and the setuid-root bit enabled on seunshare. It does not work on current Fedora 44, as it seems Fedora backported a patch to fix this issue (it passes O_NOFOLLOW to the openat() call in question).

Upstream fixed this issue in commit 38f0a4d9a which is part of of the 3.11 upstream release.

3.2) Process Kill Attack Vector in killall() (CVE-2026-59677)

seunshare offers --kill and -Z switches as documented in its man page:

-k --kill
       Kill all processes with matching MCS level

-Z context
       Use alternate SELinux context while running the executable

Both switches combined cause the killall() function to kill all processes running with the user-provided SELinux context. This does not fully work for arbitrary target processes due to SELinux access control; however, if the calling user is running in unconfined context (as explained previously) it allows to kill e.g. root-owned processes running also in unconfined context. Once the algorithm reaches its own PID (if the context matches), it kills itself, thus it is possible that only a certain range of PIDs can be killed this way depending on the PID selection order of the algorithm in killall().

We have been able to reproduce the issue both on openSUSE and on Fedora 44 using a command line like this:

seunshare --kill -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -t ~/some-dir/ -- /usr/bin/true

Upstream fixed this issue by dropping the --kill switch and the killall() function in commit 572db2fa.

4) Remaining Concerns

The code of seunshare has seen major changes between version 3.10 and 3.11 of the SELinux userspace utilities. The new version of the program improves on various aspects of the code; generally the code shows awareness of various filesystem-related security concerns that are relevant for setuid-root binaries. Still a number of concerns remain:

• Data which is modified in temporary directories within the sandbox is transparently copied back into the calling user’s source directory via rsync. Since the program is untrusted it can potentially create all kinds of dangerous files, which will now reside e.g. in the user’s regular home directory and could lead to security issues at a later time when accessed without care.
• The code flips the filesystem UID a lot to temporarily drop root privileges for file operations. This logic is hard to follow in parts and leaves the process in an unusual state of privilege, as the effective UID is still 0; during the first stages of the program it also still has all capabilities. Due to the filesystem UID being set to the real user’s UID, file operations are carried out using the calling user’s lower privileges, however. From a design point of view it would be preferable to let the process operate in an unprivileged state by default (effective UID and GID set to the real UID and GID). Privileges could then be raised for the few operations that actually need root privileges.
• The code currently lacks some common security precautions for setuid-root programs:
  • while a new environment variable block is set up to execute the untrusted target program, the privileged parent process keeps the untrusted environment variables of the calling user in place. These are also inherited to tools like rsync that are invoked for the purposes of setting up the sandbox. While this is not an issue at the moment, it could turn into a security issue at a later time when the code changes.
  • the umask() of the process is also kept unchanged, inheriting whatever the unprivileged parent process configured. This can cause files to receive world-readable or world-writable bits leading to unexpected attack vectors.

5) CVE Assignments

We approached the upstream SELinux userspace utilities developers and suggested to assign CVEs for the two issues discussed above. Upstream informed us that they don’t take care of CVE assignment themselves, however. Since Red Hat developers are also involved with upstream development, we were waiting for an agreement on who will assign CVEs to avoid duplicates. On 2026-07-17, after the initial publication of this report, we received a response that there is no intention by RedHat developers to assign CVEs. As a result we assigned CVEs on our end as documented in the updated blog post.

6) Timeline

7) References

• SElinux userspace utilities bugfix release 3.11
• SELinux userspace utilities Github project
• vulnerable seunshare code in upstream release 3.10
• Reproducer for the file delete issue

8) Change History

openSUSE.Asia Summit 2027: Call for Host

The openSUSE.Asia Summit is an annual conference that brings together openSUSE contributors, users, and Free and Open Source Software (FOSS) enthusiasts from across Asia. It provides a unique opportunity for the community to meet in person, exchange ideas, share technical knowledge, and strengthen collaboration.

As the openSUSE.Asia Summit 2026 will be held in Yogyakarta, Indonesia, the openSUSE.Asia Organization Committee is now inviting local openSUSE communities to submit proposals to host the 2027 summit.

Hosting the summit is a rewarding opportunity to showcase your local community, promote open source technologies, and connect with contributors from across Asia. The organizing committee will work closely with the selected team, providing guidance and sharing experiences from previous events throughout the planning process.

Important Dates

• 10 August 2026 — Proposal submission deadline
• 4 October 2026 — Host proposal presentation during openSUSE.Asia Summit 2026 in Yogyakarta, Indonesia
• 31 October 2026 — Announcement of the openSUSE.Asia Summit 2027 host

Applicants are encouraged to join our regular online meetings before the summit. This is a great opportunity to learn about the event organization process, ask questions, and interact with organizers from previous years.

How to Submit

Please send your proposal to both:

• summit@lists.opensuse.org
• opensuseasia-summit@googlegroups.com

Since summit@lists.opensuse.org does not accept email attachments, please upload your proposal to a file-sharing service (such as Nextcloud, Google Drive, or Dropbox) and include the download link in your email.

Proposal Guidelines

Your proposal should include at least the following information:

• Host city and venue
• Transportation
  • International access to your city
  • Local transportation to the venue
• Estimated budget
  • Venue
  • Catering (coffee break, lunch, dinner)
  • Conference dinner
  • Conference tour (optional)
  • T-shirts and event materials
  • Other operational expenses
• Local organizing team
  • Introduction to your local openSUSE community
  • Experience organizing conferences or community events
  • Expected volunteers and organizing structure
• Tentative event schedule
• Potential local sponsors or partners (optional but recommended)

Before preparing your proposal, please read the openSUSE.Asia Summit Tips for Organizers:

• https://en.opensuse.org/openSUSE:Asia_Summit_Tips_for_Organizers

We look forward to receiving your proposal and welcoming a new host community for openSUSE.Asia Summit 2027. We hope to see your community become the next destination for the openSUSE community in Asia!