robot_lab 0.0.1 → 0.0.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/.github/workflows/deploy-github-pages.yml +9 -9
- data/.irbrc +6 -0
- data/CHANGELOG.md +140 -0
- data/README.md +263 -48
- data/Rakefile +71 -1
- data/docs/api/core/index.md +53 -46
- data/docs/api/core/memory.md +200 -154
- data/docs/api/core/network.md +13 -3
- data/docs/api/core/robot.md +490 -130
- data/docs/api/core/state.md +55 -73
- data/docs/api/core/tool.md +205 -209
- data/docs/api/index.md +7 -28
- data/docs/api/mcp/client.md +119 -48
- data/docs/api/mcp/index.md +75 -60
- data/docs/api/mcp/server.md +120 -136
- data/docs/api/mcp/transports.md +172 -184
- data/docs/api/messages/index.md +35 -20
- data/docs/api/messages/text-message.md +67 -21
- data/docs/api/messages/tool-call-message.md +80 -41
- data/docs/api/messages/tool-result-message.md +119 -50
- data/docs/api/messages/user-message.md +48 -24
- data/docs/api/streaming/context.md +157 -74
- data/docs/api/streaming/events.md +114 -166
- data/docs/api/streaming/index.md +74 -72
- data/docs/architecture/core-concepts.md +360 -116
- data/docs/architecture/index.md +97 -59
- data/docs/architecture/message-flow.md +138 -129
- data/docs/architecture/network-orchestration.md +197 -50
- data/docs/architecture/robot-execution.md +199 -146
- data/docs/architecture/state-management.md +255 -187
- data/docs/concepts.md +311 -49
- data/docs/examples/basic-chat.md +89 -77
- data/docs/examples/index.md +222 -47
- data/docs/examples/mcp-server.md +207 -203
- data/docs/examples/multi-robot-network.md +129 -35
- data/docs/examples/rails-application.md +159 -160
- data/docs/examples/tool-usage.md +295 -204
- data/docs/getting-started/configuration.md +347 -154
- data/docs/getting-started/index.md +1 -1
- data/docs/getting-started/installation.md +22 -13
- data/docs/getting-started/quick-start.md +166 -121
- data/docs/guides/building-robots.md +418 -212
- data/docs/guides/creating-networks.md +143 -24
- data/docs/guides/index.md +0 -5
- data/docs/guides/mcp-integration.md +152 -113
- data/docs/guides/memory.md +220 -164
- data/docs/guides/rails-integration.md +244 -162
- data/docs/guides/streaming.md +137 -187
- data/docs/guides/using-tools.md +259 -212
- data/docs/index.md +46 -41
- data/examples/01_simple_robot.rb +6 -9
- data/examples/02_tools.rb +6 -9
- data/examples/03_network.rb +19 -17
- data/examples/04_mcp.rb +5 -8
- data/examples/05_streaming.rb +5 -8
- data/examples/06_prompt_templates.rb +42 -37
- data/examples/07_network_memory.rb +13 -14
- data/examples/08_llm_config.rb +169 -0
- data/examples/09_chaining.rb +262 -0
- data/examples/10_memory.rb +331 -0
- data/examples/11_network_introspection.rb +253 -0
- data/examples/12_message_bus.rb +74 -0
- data/examples/13_spawn.rb +90 -0
- data/examples/14_rusty_circuit/comic.rb +143 -0
- data/examples/14_rusty_circuit/display.rb +203 -0
- data/examples/14_rusty_circuit/heckler.rb +63 -0
- data/examples/14_rusty_circuit/open_mic.rb +123 -0
- data/examples/14_rusty_circuit/prompts/open_mic_comic.md +20 -0
- data/examples/14_rusty_circuit/prompts/open_mic_heckler.md +23 -0
- data/examples/14_rusty_circuit/prompts/open_mic_scout.md +20 -0
- data/examples/14_rusty_circuit/scout.rb +156 -0
- data/examples/14_rusty_circuit/scout_notes.md +89 -0
- data/examples/14_rusty_circuit/show.log +234 -0
- data/examples/15_memory_network_and_bus/editor_in_chief.rb +24 -0
- data/examples/15_memory_network_and_bus/editorial_pipeline.rb +206 -0
- data/examples/15_memory_network_and_bus/linux_writer.rb +80 -0
- data/examples/15_memory_network_and_bus/os_editor.rb +46 -0
- data/examples/15_memory_network_and_bus/os_writer.rb +46 -0
- data/examples/15_memory_network_and_bus/output/combined_article.md +13 -0
- data/examples/15_memory_network_and_bus/output/final_article.md +15 -0
- data/examples/15_memory_network_and_bus/output/linux_draft.md +5 -0
- data/examples/15_memory_network_and_bus/output/mac_draft.md +7 -0
- data/examples/15_memory_network_and_bus/output/memory.json +13 -0
- data/examples/15_memory_network_and_bus/output/revision_1.md +19 -0
- data/examples/15_memory_network_and_bus/output/revision_2.md +15 -0
- data/examples/15_memory_network_and_bus/output/windows_draft.md +7 -0
- data/examples/15_memory_network_and_bus/prompts/os_advocate.md +13 -0
- data/examples/15_memory_network_and_bus/prompts/os_chief.md +13 -0
- data/examples/15_memory_network_and_bus/prompts/os_editor.md +13 -0
- data/examples/16_writers_room/display.rb +158 -0
- data/examples/16_writers_room/output/.gitignore +2 -0
- data/examples/16_writers_room/output/opus_001.md +263 -0
- data/examples/16_writers_room/output/opus_001_notes.log +470 -0
- data/examples/16_writers_room/prompts/writer.md +37 -0
- data/examples/16_writers_room/room.rb +150 -0
- data/examples/16_writers_room/tools.rb +162 -0
- data/examples/16_writers_room/writer.rb +121 -0
- data/examples/16_writers_room/writers_room.rb +162 -0
- data/examples/README.md +197 -0
- data/examples/prompts/{assistant/system.txt.erb → assistant.md} +3 -0
- data/examples/prompts/{billing/system.txt.erb → billing.md} +3 -0
- data/examples/prompts/{classifier/system.txt.erb → classifier.md} +3 -0
- data/examples/prompts/comedian.md +6 -0
- data/examples/prompts/comedy_critic.md +10 -0
- data/examples/prompts/configurable.md +9 -0
- data/examples/prompts/dispatcher.md +12 -0
- data/examples/prompts/{entity_extractor/system.txt.erb → entity_extractor.md} +3 -0
- data/examples/prompts/{escalation/system.txt.erb → escalation.md} +7 -0
- data/examples/prompts/frontmatter_mcp_test.md +9 -0
- data/examples/prompts/frontmatter_named_test.md +5 -0
- data/examples/prompts/frontmatter_tools_test.md +6 -0
- data/examples/prompts/{general/system.txt.erb → general.md} +3 -0
- data/examples/prompts/{github_assistant/system.txt.erb → github_assistant.md} +8 -0
- data/examples/prompts/{helper/system.txt.erb → helper.md} +3 -0
- data/examples/prompts/{keyword_extractor/system.txt.erb → keyword_extractor.md} +3 -0
- data/examples/prompts/llm_config_demo.md +20 -0
- data/examples/prompts/{order_support/system.txt.erb → order_support.md} +8 -0
- data/examples/prompts/os_advocate.md +13 -0
- data/examples/prompts/os_chief.md +13 -0
- data/examples/prompts/os_editor.md +13 -0
- data/examples/prompts/{product_support/system.txt.erb → product_support.md} +7 -0
- data/examples/prompts/{sentiment_analyzer/system.txt.erb → sentiment_analyzer.md} +3 -0
- data/examples/prompts/{synthesizer/system.txt.erb → synthesizer.md} +3 -0
- data/examples/prompts/{technical/system.txt.erb → technical.md} +3 -0
- data/examples/prompts/{triage/system.txt.erb → triage.md} +6 -0
- data/lib/generators/robot_lab/templates/initializer.rb.tt +0 -13
- data/lib/robot_lab/ask_user.rb +75 -0
- data/lib/robot_lab/config/defaults.yml +121 -0
- data/lib/robot_lab/config.rb +183 -0
- data/lib/robot_lab/error.rb +6 -0
- data/lib/robot_lab/mcp/client.rb +1 -1
- data/lib/robot_lab/memory.rb +10 -34
- data/lib/robot_lab/network.rb +13 -20
- data/lib/robot_lab/robot/bus_messaging.rb +239 -0
- data/lib/robot_lab/robot/mcp_management.rb +88 -0
- data/lib/robot_lab/robot/template_rendering.rb +130 -0
- data/lib/robot_lab/robot.rb +240 -330
- data/lib/robot_lab/robot_message.rb +44 -0
- data/lib/robot_lab/robot_result.rb +1 -0
- data/lib/robot_lab/run_config.rb +184 -0
- data/lib/robot_lab/state_proxy.rb +2 -12
- data/lib/robot_lab/streaming/context.rb +1 -1
- data/lib/robot_lab/task.rb +8 -1
- data/lib/robot_lab/tool.rb +108 -172
- data/lib/robot_lab/tool_config.rb +1 -1
- data/lib/robot_lab/tool_manifest.rb +2 -18
- data/lib/robot_lab/utils.rb +39 -0
- data/lib/robot_lab/version.rb +1 -1
- data/lib/robot_lab.rb +89 -57
- data/mkdocs.yml +0 -11
- metadata +121 -135
- data/docs/api/adapters/anthropic.md +0 -121
- data/docs/api/adapters/gemini.md +0 -133
- data/docs/api/adapters/index.md +0 -104
- data/docs/api/adapters/openai.md +0 -134
- data/docs/api/history/active-record-adapter.md +0 -195
- data/docs/api/history/config.md +0 -191
- data/docs/api/history/index.md +0 -132
- data/docs/api/history/thread-manager.md +0 -144
- data/docs/guides/history.md +0 -359
- data/examples/prompts/assistant/user.txt.erb +0 -1
- data/examples/prompts/billing/user.txt.erb +0 -1
- data/examples/prompts/classifier/user.txt.erb +0 -1
- data/examples/prompts/entity_extractor/user.txt.erb +0 -3
- data/examples/prompts/escalation/user.txt.erb +0 -34
- data/examples/prompts/general/user.txt.erb +0 -1
- data/examples/prompts/github_assistant/user.txt.erb +0 -1
- data/examples/prompts/helper/user.txt.erb +0 -1
- data/examples/prompts/keyword_extractor/user.txt.erb +0 -3
- data/examples/prompts/order_support/user.txt.erb +0 -22
- data/examples/prompts/product_support/user.txt.erb +0 -32
- data/examples/prompts/sentiment_analyzer/user.txt.erb +0 -3
- data/examples/prompts/synthesizer/user.txt.erb +0 -15
- data/examples/prompts/technical/user.txt.erb +0 -1
- data/examples/prompts/triage/user.txt.erb +0 -17
- data/lib/robot_lab/adapters/anthropic.rb +0 -163
- data/lib/robot_lab/adapters/base.rb +0 -85
- data/lib/robot_lab/adapters/gemini.rb +0 -193
- data/lib/robot_lab/adapters/openai.rb +0 -159
- data/lib/robot_lab/adapters/registry.rb +0 -81
- data/lib/robot_lab/configuration.rb +0 -143
- data/lib/robot_lab/errors.rb +0 -70
- data/lib/robot_lab/history/active_record_adapter.rb +0 -146
- data/lib/robot_lab/history/config.rb +0 -115
- data/lib/robot_lab/history/thread_manager.rb +0 -93
- data/lib/robot_lab/robotic_model.rb +0 -324
|
@@ -0,0 +1,206 @@
|
|
|
1
|
+
#!/usr/bin/env ruby
|
|
2
|
+
# frozen_string_literal: true
|
|
3
|
+
|
|
4
|
+
# Example 15: OS Research Editorial Pipeline — Network + Memory + Bus + Spawn
|
|
5
|
+
#
|
|
6
|
+
# Three writers advocate for different operating systems (macOS, Windows,
|
|
7
|
+
# Linux/BSD) for home AI research labs. The Linux writer spawns distro
|
|
8
|
+
# specialists. An editor synthesizes. An editor-in-chief gives final approval.
|
|
9
|
+
#
|
|
10
|
+
# This showcases all three coordination mechanisms working together:
|
|
11
|
+
#
|
|
12
|
+
# NETWORK (parallel pipeline + shared memory)
|
|
13
|
+
# ┌──────────────────────────────────────────────────────┐
|
|
14
|
+
# │ mac_writer ──┐ │
|
|
15
|
+
# │ win_writer ──┼── editor ──→ combined article │
|
|
16
|
+
# │ linux_writer ──┘ │
|
|
17
|
+
# │ └── spawns distro specialists via spawn() │
|
|
18
|
+
# │ │
|
|
19
|
+
# │ MEMORY carries drafts between stages │
|
|
20
|
+
# │ :mac_draft, :windows_draft, :linux_draft │
|
|
21
|
+
# └──────────────────────────────────────────────────────┘
|
|
22
|
+
# │
|
|
23
|
+
# BUS (review loop)
|
|
24
|
+
# │
|
|
25
|
+
# ┌─────┴──────┐
|
|
26
|
+
# │ chief │
|
|
27
|
+
# └────────────┘
|
|
28
|
+
#
|
|
29
|
+
# - NETWORK orchestrates 3 parallel writers → editor synthesis
|
|
30
|
+
# - MEMORY passes advocacy drafts between pipeline stages
|
|
31
|
+
# - BUS enables editor ↔ chief revision loop after pipeline
|
|
32
|
+
# - SPAWN creates distro specialists dynamically within pipeline
|
|
33
|
+
#
|
|
34
|
+
# Usage:
|
|
35
|
+
# bundle exec ruby examples/15_memory_network_and_bus/editorial_pipeline.rb
|
|
36
|
+
|
|
37
|
+
ENV["ROBOT_LAB_TEMPLATE_PATH"] ||= File.join(__dir__, "prompts")
|
|
38
|
+
|
|
39
|
+
require_relative "../../lib/robot_lab"
|
|
40
|
+
require "fileutils"
|
|
41
|
+
|
|
42
|
+
RubyLLM.configure { |c| c.logger = Logger.new(File::NULL) }
|
|
43
|
+
|
|
44
|
+
MAX_REVISIONS = 3
|
|
45
|
+
OUTPUT_DIR = File.join(__dir__, "output")
|
|
46
|
+
|
|
47
|
+
FileUtils.mkdir_p(OUTPUT_DIR)
|
|
48
|
+
|
|
49
|
+
# ── Load robot classes ────────────────────────────────────
|
|
50
|
+
|
|
51
|
+
require_relative "os_writer"
|
|
52
|
+
require_relative "linux_writer"
|
|
53
|
+
require_relative "os_editor"
|
|
54
|
+
require_relative "editor_in_chief"
|
|
55
|
+
|
|
56
|
+
# ── Build Everything ──────────────────────────────────────
|
|
57
|
+
|
|
58
|
+
bus = TypedBus::MessageBus.new
|
|
59
|
+
|
|
60
|
+
mac_writer = OsWriter.new(
|
|
61
|
+
name: "mac_writer",
|
|
62
|
+
template: :os_advocate,
|
|
63
|
+
local_tools: [RobotLab::AskUser],
|
|
64
|
+
context: {
|
|
65
|
+
os_name: "macOS",
|
|
66
|
+
strengths: "Apple Silicon (M-series) performance, Metal GPU framework, Unix foundation, CoreML integration, energy efficiency"
|
|
67
|
+
},
|
|
68
|
+
memory_key: :mac_draft
|
|
69
|
+
)
|
|
70
|
+
|
|
71
|
+
win_writer = OsWriter.new(
|
|
72
|
+
name: "win_writer",
|
|
73
|
+
template: :os_advocate,
|
|
74
|
+
local_tools: [RobotLab::AskUser],
|
|
75
|
+
context: {
|
|
76
|
+
os_name: "Windows",
|
|
77
|
+
strengths: "NVIDIA CUDA first-class support, WSL2 Linux compatibility, DirectML, widest hardware selection, enterprise tool integration"
|
|
78
|
+
},
|
|
79
|
+
memory_key: :windows_draft
|
|
80
|
+
)
|
|
81
|
+
|
|
82
|
+
linux_writer = LinuxWriter.new(
|
|
83
|
+
name: "linux_writer",
|
|
84
|
+
template: :os_advocate,
|
|
85
|
+
local_tools: [RobotLab::AskUser],
|
|
86
|
+
context: {
|
|
87
|
+
os_name: "Linux/BSD",
|
|
88
|
+
strengths: "Full GPU stack control, Docker-native, free and open source, server parity, massive community packages"
|
|
89
|
+
},
|
|
90
|
+
memory_key: :linux_draft,
|
|
91
|
+
bus: bus
|
|
92
|
+
)
|
|
93
|
+
|
|
94
|
+
editor = OsEditor.new(
|
|
95
|
+
name: "editor",
|
|
96
|
+
template: :os_editor,
|
|
97
|
+
bus: bus
|
|
98
|
+
)
|
|
99
|
+
|
|
100
|
+
# Editor handles revision requests from the chief via bus
|
|
101
|
+
revision_count = 0
|
|
102
|
+
editor.on_message do |message|
|
|
103
|
+
revised = editor.run(message.content).reply.strip
|
|
104
|
+
editor.instance_variable_set(:@article, revised)
|
|
105
|
+
|
|
106
|
+
revision_count += 1
|
|
107
|
+
path = File.join(OUTPUT_DIR, "revision_#{revision_count}.md")
|
|
108
|
+
File.write(path, "# Revision #{revision_count}\n\n#{revised}\n")
|
|
109
|
+
puts " Editor [revised]: #{revised[0..120]}..."
|
|
110
|
+
puts " [editor] Revision written to #{path}"
|
|
111
|
+
|
|
112
|
+
editor.send_reply(to: message.from.to_sym, content: revised, in_reply_to: message.key)
|
|
113
|
+
end
|
|
114
|
+
|
|
115
|
+
chief = EditorInChief.new(
|
|
116
|
+
name: "chief",
|
|
117
|
+
template: :os_chief,
|
|
118
|
+
bus: bus
|
|
119
|
+
)
|
|
120
|
+
|
|
121
|
+
# Network orchestrates the writing pipeline
|
|
122
|
+
network = RobotLab.create_network(name: "os_editorial") do
|
|
123
|
+
task :mac_writer, mac_writer, depends_on: :none
|
|
124
|
+
task :win_writer, win_writer, depends_on: :none
|
|
125
|
+
task :linux_writer, linux_writer, depends_on: :none
|
|
126
|
+
task :editor, editor, depends_on: [:mac_writer, :win_writer, :linux_writer]
|
|
127
|
+
end
|
|
128
|
+
|
|
129
|
+
# Give each pipeline robot a direct reference to shared memory.
|
|
130
|
+
# extract_run_context's delete() pattern mutates the shared run_params
|
|
131
|
+
# hash, so parallel steps lose network_memory after the first one runs.
|
|
132
|
+
shared_memory = network.memory
|
|
133
|
+
[mac_writer, win_writer, linux_writer, editor].each do |robot|
|
|
134
|
+
robot.shared_memory = shared_memory
|
|
135
|
+
end
|
|
136
|
+
|
|
137
|
+
# Monitor shared memory changes during the pipeline
|
|
138
|
+
network.memory.subscribe(
|
|
139
|
+
:mac_draft, :windows_draft, :linux_draft,
|
|
140
|
+
:ubuntu_specialist, :fedora_specialist, :freebsd_specialist
|
|
141
|
+
) do |change|
|
|
142
|
+
puts " [memory] :#{change.key} updated by #{change.writer}"
|
|
143
|
+
end
|
|
144
|
+
|
|
145
|
+
# ── Run ──────────────────────────────────────────────────────
|
|
146
|
+
|
|
147
|
+
puts "=" * 60
|
|
148
|
+
puts "Example 15: OS Research Editorial Pipeline"
|
|
149
|
+
puts " Network + Memory + Bus + Spawn"
|
|
150
|
+
puts "=" * 60
|
|
151
|
+
puts
|
|
152
|
+
puts network.visualize
|
|
153
|
+
puts
|
|
154
|
+
|
|
155
|
+
# ── Phase 1: Writing Pipeline (Network + Memory + Spawn) ──
|
|
156
|
+
|
|
157
|
+
puts "Phase 1: Writing Pipeline (Network + Memory + Spawn)"
|
|
158
|
+
puts "-" * 40
|
|
159
|
+
|
|
160
|
+
# Gather the research focus from the user via AskUser
|
|
161
|
+
ask = RobotLab::AskUser.new
|
|
162
|
+
focus = ask.call(
|
|
163
|
+
"question" => "What AI research focus areas for the home lab article?",
|
|
164
|
+
"default" => "LLM fine-tuning, image generation, and local inference"
|
|
165
|
+
)
|
|
166
|
+
|
|
167
|
+
topic = "Write about your operating system's advantages for building a home AI research lab focused on #{focus}."
|
|
168
|
+
|
|
169
|
+
result = network.run(message: topic)
|
|
170
|
+
article = editor.article
|
|
171
|
+
|
|
172
|
+
puts
|
|
173
|
+
puts " Article excerpt: #{article[0..200]}..." if article
|
|
174
|
+
puts
|
|
175
|
+
puts " Memory keys: #{network.memory.keys.join(', ')}"
|
|
176
|
+
puts " Specialists spawned: #{linux_writer.specialists.size}"
|
|
177
|
+
|
|
178
|
+
# ── Phase 2: Editorial Review (Bus) ──────────────────────
|
|
179
|
+
|
|
180
|
+
puts
|
|
181
|
+
puts "Phase 2: Editorial Review (Bus)"
|
|
182
|
+
puts "-" * 40
|
|
183
|
+
|
|
184
|
+
# Chief reviews the article via bus — may trigger revision loop
|
|
185
|
+
chief.send_message(to: :editor, content: article)
|
|
186
|
+
|
|
187
|
+
final_article = editor.article
|
|
188
|
+
final_path = File.join(OUTPUT_DIR, "final_article.md")
|
|
189
|
+
status = chief.accepted ? "APPROVED" : "NOT APPROVED (max revisions reached)"
|
|
190
|
+
File.write(final_path, "# Final Article — #{status}\n\n#{final_article}\n")
|
|
191
|
+
|
|
192
|
+
puts
|
|
193
|
+
puts "-" * 60
|
|
194
|
+
puts "Revisions: #{chief.rounds} | Accepted: #{chief.accepted}"
|
|
195
|
+
puts "Specialists spawned: #{linux_writer.specialists.size}"
|
|
196
|
+
puts "Output directory: #{OUTPUT_DIR}"
|
|
197
|
+
puts "=" * 60
|
|
198
|
+
|
|
199
|
+
puts
|
|
200
|
+
|
|
201
|
+
require "json"
|
|
202
|
+
|
|
203
|
+
memory_path = File.join(OUTPUT_DIR, "memory.json")
|
|
204
|
+
File.write(memory_path, JSON.pretty_generate(shared_memory.to_h))
|
|
205
|
+
puts
|
|
206
|
+
puts "Memory written to #{memory_path}"
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
# frozen_string_literal: true
|
|
2
|
+
|
|
3
|
+
# Linux writer spawns distro specialists before writing its draft.
|
|
4
|
+
# Demonstrates the spawn() pattern for dynamic robot creation.
|
|
5
|
+
class LinuxWriter < OsWriter
|
|
6
|
+
attr_reader :specialists
|
|
7
|
+
|
|
8
|
+
def initialize(**opts)
|
|
9
|
+
super(**opts)
|
|
10
|
+
@specialists = []
|
|
11
|
+
end
|
|
12
|
+
|
|
13
|
+
def call(result)
|
|
14
|
+
message = extract_message(result)
|
|
15
|
+
|
|
16
|
+
# Spawn distro specialists and collect their analyses
|
|
17
|
+
distro_analyses = spawn_distro_specialists(message)
|
|
18
|
+
|
|
19
|
+
# Build an enriched prompt with specialist input
|
|
20
|
+
enriched = <<~PROMPT
|
|
21
|
+
#{message}
|
|
22
|
+
|
|
23
|
+
Your team of distro specialists has provided the following analyses.
|
|
24
|
+
Incorporate their insights into your advocacy piece:
|
|
25
|
+
|
|
26
|
+
#{distro_analyses}
|
|
27
|
+
PROMPT
|
|
28
|
+
|
|
29
|
+
robot_result = run(enriched, network_memory: @shared_memory)
|
|
30
|
+
|
|
31
|
+
if @shared_memory
|
|
32
|
+
draft = robot_result.reply.to_s
|
|
33
|
+
@shared_memory.current_writer = @name
|
|
34
|
+
@shared_memory.set(@memory_key, draft)
|
|
35
|
+
|
|
36
|
+
path = File.join(OUTPUT_DIR, "#{@memory_key}.md")
|
|
37
|
+
File.write(path, "# #{@name} Draft\n\n#{draft}\n")
|
|
38
|
+
puts " [#{@name}] Draft written to memory[:#{@memory_key}] and #{path} (with #{@specialists.size} specialist inputs)"
|
|
39
|
+
end
|
|
40
|
+
|
|
41
|
+
result.with_context(@name.to_sym, robot_result).continue(robot_result)
|
|
42
|
+
end
|
|
43
|
+
|
|
44
|
+
private
|
|
45
|
+
|
|
46
|
+
def spawn_distro_specialists(topic)
|
|
47
|
+
distros = [
|
|
48
|
+
{ name: "ubuntu_specialist", label: "Ubuntu/Debian",
|
|
49
|
+
prompt: "You are a Ubuntu/Debian specialist for AI research. Focus on apt ecosystem, CUDA support, and wide hardware compatibility." },
|
|
50
|
+
{ name: "fedora_specialist", label: "Fedora/RHEL",
|
|
51
|
+
prompt: "You are a Fedora/RHEL specialist for AI research. Focus on cutting-edge kernels, SELinux security, and enterprise tooling." },
|
|
52
|
+
{ name: "freebsd_specialist", label: "FreeBSD",
|
|
53
|
+
prompt: "You are a FreeBSD specialist for AI research. Focus on ZFS, jails, bhyve virtualization, and stability for long-running experiments." }
|
|
54
|
+
]
|
|
55
|
+
|
|
56
|
+
analyses = []
|
|
57
|
+
|
|
58
|
+
distros.each do |distro|
|
|
59
|
+
puts " [#{@name}] Spawning #{distro[:label]} specialist..."
|
|
60
|
+
specialist = spawn(name: distro[:name], system_prompt: distro[:prompt])
|
|
61
|
+
@specialists << specialist
|
|
62
|
+
|
|
63
|
+
analysis = specialist.run(
|
|
64
|
+
"Briefly describe why #{distro[:label]} is a strong choice for a home AI research lab. 2-3 sentences."
|
|
65
|
+
).reply.strip
|
|
66
|
+
|
|
67
|
+
puts " [#{distro[:name]}] #{analysis[0..80]}..."
|
|
68
|
+
analyses << "### #{distro[:label]}\n#{analysis}"
|
|
69
|
+
|
|
70
|
+
# Write each specialist's analysis to shared memory
|
|
71
|
+
if @shared_memory
|
|
72
|
+
memory_key = distro[:name].to_sym
|
|
73
|
+
@shared_memory.current_writer = distro[:name]
|
|
74
|
+
@shared_memory.set(memory_key, analysis)
|
|
75
|
+
end
|
|
76
|
+
end
|
|
77
|
+
|
|
78
|
+
analyses.join("\n\n")
|
|
79
|
+
end
|
|
80
|
+
end
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# frozen_string_literal: true
|
|
2
|
+
|
|
3
|
+
# Reads all three drafts from memory, synthesizes a combined article.
|
|
4
|
+
# Also handles revision requests from the chief via bus.
|
|
5
|
+
#
|
|
6
|
+
# Like OsWriter, uses a direct shared_memory reference to avoid the
|
|
7
|
+
# extract_run_context mutation issue with parallel pipeline steps.
|
|
8
|
+
class OsEditor < RobotLab::Robot
|
|
9
|
+
attr_accessor :shared_memory
|
|
10
|
+
attr_reader :article
|
|
11
|
+
|
|
12
|
+
def initialize(**opts)
|
|
13
|
+
super(**opts)
|
|
14
|
+
@article = nil
|
|
15
|
+
end
|
|
16
|
+
|
|
17
|
+
def call(result)
|
|
18
|
+
# Read all three drafts from shared memory
|
|
19
|
+
mac_draft = @shared_memory&.get(:mac_draft) || "No draft available."
|
|
20
|
+
windows_draft = @shared_memory&.get(:windows_draft) || "No draft available."
|
|
21
|
+
linux_draft = @shared_memory&.get(:linux_draft) || "No draft available."
|
|
22
|
+
|
|
23
|
+
composite_prompt = <<~PROMPT
|
|
24
|
+
Here are three advocacy drafts for different operating systems for home AI research labs.
|
|
25
|
+
Synthesize them into a balanced article.
|
|
26
|
+
|
|
27
|
+
## macOS Advocacy
|
|
28
|
+
#{mac_draft}
|
|
29
|
+
|
|
30
|
+
## Windows Advocacy
|
|
31
|
+
#{windows_draft}
|
|
32
|
+
|
|
33
|
+
## Linux/BSD Advocacy
|
|
34
|
+
#{linux_draft}
|
|
35
|
+
PROMPT
|
|
36
|
+
|
|
37
|
+
robot_result = run(composite_prompt, network_memory: @shared_memory)
|
|
38
|
+
@article = robot_result.reply.to_s
|
|
39
|
+
|
|
40
|
+
path = File.join(OUTPUT_DIR, "combined_article.md")
|
|
41
|
+
File.write(path, "# Combined Article (Editor Draft)\n\n#{@article}\n")
|
|
42
|
+
puts " [#{@name}] Combined article written to #{path}"
|
|
43
|
+
|
|
44
|
+
result.with_context(@name.to_sym, robot_result).continue(robot_result)
|
|
45
|
+
end
|
|
46
|
+
end
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# frozen_string_literal: true
|
|
2
|
+
|
|
3
|
+
# Base writer that runs LLM and stores its draft in shared memory.
|
|
4
|
+
# Used by mac_writer and win_writer directly; LinuxWriter extends this.
|
|
5
|
+
#
|
|
6
|
+
# NOTE: We bypass extract_run_context for network_memory access because
|
|
7
|
+
# its delete() pattern mutates the shared run_params hash — in parallel
|
|
8
|
+
# pipeline steps, only the first step to run would get the memory object.
|
|
9
|
+
# Instead, each robot holds a direct reference via shared_memory=.
|
|
10
|
+
class OsWriter < RobotLab::Robot
|
|
11
|
+
attr_accessor :shared_memory
|
|
12
|
+
|
|
13
|
+
def initialize(memory_key:, **opts)
|
|
14
|
+
super(**opts)
|
|
15
|
+
@memory_key = memory_key
|
|
16
|
+
end
|
|
17
|
+
|
|
18
|
+
def call(result)
|
|
19
|
+
message = extract_message(result)
|
|
20
|
+
|
|
21
|
+
robot_result = run(message, network_memory: @shared_memory)
|
|
22
|
+
|
|
23
|
+
if @shared_memory
|
|
24
|
+
draft = robot_result.reply.to_s
|
|
25
|
+
@shared_memory.current_writer = @name
|
|
26
|
+
@shared_memory.set(@memory_key, draft)
|
|
27
|
+
|
|
28
|
+
path = File.join(OUTPUT_DIR, "#{@memory_key}.md")
|
|
29
|
+
File.write(path, "# #{@name} Draft\n\n#{draft}\n")
|
|
30
|
+
puts " [#{@name}] Draft written to memory[:#{@memory_key}] and #{path}"
|
|
31
|
+
end
|
|
32
|
+
|
|
33
|
+
result.with_context(@name.to_sym, robot_result).continue(robot_result)
|
|
34
|
+
end
|
|
35
|
+
|
|
36
|
+
private
|
|
37
|
+
|
|
38
|
+
def extract_message(result)
|
|
39
|
+
case result.value
|
|
40
|
+
when Hash then result.value[:message]
|
|
41
|
+
when RobotLab::RobotResult then result.value.reply
|
|
42
|
+
when String then result.value
|
|
43
|
+
else result.value.to_s
|
|
44
|
+
end
|
|
45
|
+
end
|
|
46
|
+
end
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# Combined Article (Editor Draft)
|
|
2
|
+
|
|
3
|
+
# Choosing the Right Operating System for Your Home AI Research Lab
|
|
4
|
+
|
|
5
|
+
Building a home AI research lab requires careful consideration of your operating system, as this foundational choice will impact everything from GPU acceleration to software compatibility. Each major platform—macOS, Windows, and Linux/BSD—brings distinct advantages that appeal to different research priorities and workflows.
|
|
6
|
+
|
|
7
|
+
**macOS excels in energy efficiency and unified architecture benefits**, particularly for researchers using Apple Silicon machines. The M-series chips' unified memory architecture eliminates traditional CPU-GPU bottlenecks, making them surprisingly effective for large language model work within memory constraints. Apple's MLX framework and Metal Performance Shaders provide optimized acceleration paths, while the Unix foundation ensures compatibility with the Python scientific stack. However, this platform's strength is primarily limited to Apple hardware, and CUDA support remains unavailable for NVIDIA-dependent workflows.
|
|
8
|
+
|
|
9
|
+
**Windows offers the broadest hardware compatibility and vendor support**, making it the go-to choice for researchers prioritizing maximum GPU options and plug-and-play simplicity. First-class NVIDIA CUDA support, DirectML for multi-vendor GPU acceleration, and WSL2 for Linux compatibility create a comprehensive environment. The platform particularly shines for users wanting access to consumer-friendly tools like AUTOMATIC1111's Stable Diffusion interfaces or LM Studio, backed by extensive community documentation. The trade-off comes in system overhead and potential stability concerns during intensive, long-running training jobs.
|
|
10
|
+
|
|
11
|
+
**Linux and BSD systems provide unmatched control and stability** for serious computational work. These platforms offer the most direct access to GPU drivers, the latest kernel optimizations, and mature containerization through Docker and Podman. FreeBSD's ZFS filesystem adds enterprise-grade data integrity, while Linux distributions like Ubuntu provide comprehensive package management for AI frameworks. The open-source nature ensures transparency and customizability, though it demands more technical expertise for optimal configuration.
|
|
12
|
+
|
|
13
|
+
**The optimal choice depends on your specific research profile**: Choose macOS if you're already invested in Apple hardware and prioritize energy efficiency for smaller-scale experiments. Select Windows if you want maximum hardware flexibility with minimal configuration overhead, especially for image generation and consumer-oriented AI tools. Opt for Linux/BSD if you're running large-scale training jobs requiring maximum stability and performance, or if you need the flexibility of custom configurations and bleeding-edge framework support. For most researchers, the decision ultimately comes down to balancing technical expertise against time-to-productivity—Windows for quick starts, Linux for maximum control, and macOS for Apple ecosystem integration.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Final Article — APPROVED
|
|
2
|
+
|
|
3
|
+
# Choosing the Right Operating System for Your Home AI Research Lab
|
|
4
|
+
|
|
5
|
+
Building a home AI research lab requires careful consideration of your operating system, as this foundational choice will impact everything from GPU acceleration to software compatibility. Each major platform—macOS, Windows, and Linux/BSD—brings distinct advantages that appeal to different research priorities and workflows.
|
|
6
|
+
|
|
7
|
+
**macOS excels in energy efficiency and unified architecture benefits**, particularly for researchers using Apple Silicon machines. The M-series chips' unified memory architecture eliminates traditional CPU-GPU bottlenecks, making them surprisingly effective for large language model work within memory constraints. Apple's MLX framework and Metal Performance Shaders provide optimized acceleration paths, while the Unix foundation ensures compatibility with the Python scientific stack. Tools like Hugging Face Transformers run seamlessly with MPS backend support, and applications like DiffusionBee leverage Metal for Stable Diffusion workflows. The platform's energy efficiency allows intensive training sessions without thermal throttling issues common in high-end PC builds. However, this strength is limited to Apple hardware, CUDA support remains unavailable for NVIDIA-dependent workflows, and the premium hardware costs can be prohibitive for budget-conscious researchers.
|
|
8
|
+
|
|
9
|
+
**Windows offers the broadest hardware compatibility and vendor support**, making it the ideal choice for researchers prioritizing maximum GPU options and plug-and-play simplicity. First-class NVIDIA CUDA support provides seamless access to CUDA 12.x, cuDNN, and TensorRT—essential for PyTorch, TensorFlow, and JAX frameworks powering modern models. DirectML enables hardware-agnostic ML acceleration across AMD, Intel, and NVIDIA GPUs, while WSL2 provides Linux compatibility without sacrificing Windows' superior hardware support. The platform excels with consumer-friendly tools like AUTOMATIC1111's Stable Diffusion interfaces, LM Studio for local LLM serving, and ComfyUI workflows, all backed by extensive community documentation. Windows licensing costs add to overall expenses, and the system overhead can impact stability during long-running training jobs, but the ease of setup makes it attractive for researchers who want to focus on experiments rather than system administration.
|
|
10
|
+
|
|
11
|
+
**Linux and BSD systems provide unmatched control and stability** for serious computational work. These platforms offer direct access to GPU drivers, the latest kernel optimizations, and mature containerization through Docker and Podman. Ubuntu and Debian provide comprehensive package repositories with one-command installations of PyTorch, TensorFlow, and CUDA toolkits, while Fedora delivers cutting-edge kernel support for new GPU architectures. FreeBSD's ZFS filesystem adds enterprise-grade data integrity with automatic checksums and snapshots—critical for protecting valuable datasets and model checkpoints. The open-source nature ensures transparency and customizability, with server-grade stability that prevents crashes during extended training sessions. The trade-off is a steeper learning curve requiring technical expertise for optimal configuration, though the performance benefits and zero licensing costs often justify the investment for serious researchers.
|
|
12
|
+
|
|
13
|
+
**Cost considerations significantly impact platform selection**. Linux systems offer the best value proposition with no licensing fees and compatibility with budget hardware, while macOS requires premium Apple hardware that can cost 2-3x equivalent PC specifications. Windows falls in the middle with moderate licensing costs but maximum hardware flexibility, allowing researchers to optimize price-performance ratios across different GPU options.
|
|
14
|
+
|
|
15
|
+
**The optimal choice depends on your specific research profile and technical comfort level**: Choose macOS if you're already invested in Apple hardware, prioritize energy efficiency for smaller-scale experiments, and value the seamless integration of Unix-based tools with premium hardware. Select Windows if you want maximum hardware flexibility with minimal configuration overhead, especially for image generation workflows and consumer-oriented AI tools, and prefer extensive community support for troubleshooting. Opt for Linux/BSD if you're running large-scale training jobs requiring maximum stability and performance, need custom system configurations, or want to minimize costs while maximizing control. For most researchers, the decision balances technical expertise against time-to-productivity—Windows for quick starts and broad compatibility, Linux for maximum performance and control, and macOS for energy-efficient workflows within the Apple ecosystem.
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
# linux_writer Draft
|
|
2
|
+
|
|
3
|
+
When building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, Linux and BSD systems stand as the undisputed champions for serious researchers. Unlike proprietary alternatives, these open-source platforms give you complete control over your GPU stack—from low-level CUDA drivers to high-level ML frameworks. Ubuntu and Debian shine with their comprehensive package repositories, offering one-command installations of PyTorch, TensorFlow, Hugging Face Transformers, and CUDA toolkits without dependency hell. For bleeding-edge work, Fedora provides the latest kernel support ensuring day-one compatibility with new GPU architectures like RTX 4090s or H100s, while its SELinux security model protects your valuable training data and model weights. The containerization story is equally compelling: Docker and Podman run natively, allowing you to spin up isolated environments for different experiments—imagine running Stable Diffusion XL in one container while fine-tuning a 7B parameter LLaMA model in another, all without conflicts.
|
|
4
|
+
|
|
5
|
+
The performance and reliability advantages become even more pronounced for serious research workflows. FreeBSD's ZFS filesystem provides bulletproof data integrity with automatic checksums and snapshots—critical when you're storing multi-terabyte datasets and irreplaceable model checkpoints from weeks-long training runs. The system's deterministic behavior ensures reproducible experiments, while jails offer lightweight isolation perfect for testing different versions of frameworks like DeepSpeed or Triton. Linux distributions excel in GPU compute with mature NVIDIA CUDA support, ROCm for AMD cards, and emerging Intel XPU capabilities. The community ecosystem is unmatched: from PyTorch Hub to Hugging Face Model Hub integration, from Jupyter notebooks to MLflow experiment tracking, everything runs optimally on these platforms. Server-grade stability means your 48-hour LoRA fine-tuning jobs won't crash from desktop OS quirks, while the vast package repositories provide everything from ONNX Runtime for optimized inference to Weights & Biases for experiment monitoring—all maintained by thousands of contributors who understand the needs of computational researchers.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# mac_writer Draft
|
|
2
|
+
|
|
3
|
+
**macOS: The Ultimate Platform for Home AI Research Labs**
|
|
4
|
+
|
|
5
|
+
When building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, macOS stands as the clear winner, primarily due to Apple Silicon's revolutionary architecture. The M-series chips deliver exceptional performance per watt, with unified memory architectures that eliminate traditional CPU-GPU memory bottlenecks—crucial for handling large language models that demand substantial RAM. For LLM fine-tuning, frameworks like MLX (Apple's native machine learning framework) provide optimized performance that often surpasses CUDA-based solutions on consumer hardware. The Metal Performance Shaders framework offers direct GPU acceleration for PyTorch and TensorFlow operations, while tools like Hugging Face Transformers run seamlessly with MPS backend support. Energy efficiency means you can run intensive training sessions without the thermal throttling and power consumption issues that plague high-end PC builds.
|
|
6
|
+
|
|
7
|
+
The software ecosystem further solidifies macOS's position as the premier AI development platform. CoreML integration allows for seamless deployment of trained models with hardware-optimized inference, while the Unix foundation provides access to the entire Python scientific computing stack—NumPy, SciPy, pandas, and scikit-learn all install effortlessly through Homebrew or conda. For image generation workflows, Stable Diffusion runs exceptionally well through optimized implementations like DiffusionBee and Draw Things, leveraging Metal's compute capabilities. The developer experience is unmatched: Xcode provides excellent debugging tools, Jupyter notebooks integrate perfectly with the system, and Docker Desktop for Mac ensures reproducible environments. The growing community around Apple Silicon ML development, exemplified by projects like whisper.cpp and llama.cpp with Metal acceleration, demonstrates the platform's momentum. Combined with tools like Ollama for local LLM serving and the seamless integration between macOS development tools and popular AI frameworks, macOS offers the most cohesive and powerful environment for serious AI research at home.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
{
|
|
2
|
+
"data": {},
|
|
3
|
+
"results": [],
|
|
4
|
+
"messages": [],
|
|
5
|
+
"custom": {
|
|
6
|
+
"ubuntu_specialist": "Ubuntu/Debian offers exceptional package management through apt with extensive pre-built libraries for AI frameworks like PyTorch, TensorFlow, and CUDA toolkit, eliminating complex compilation steps. The distributions provide excellent hardware compatibility across diverse GPU vendors (NVIDIA, AMD, Intel) and architectures, while maintaining strong community support with comprehensive documentation for AI-specific configurations. Their LTS releases ensure stable, long-term environments crucial for reproducible research workflows.",
|
|
7
|
+
"fedora_specialist": "Fedora/RHEL excels for AI research due to its cutting-edge kernel support that ensures compatibility with the latest GPU drivers and hardware accelerators, while SELinux provides robust security isolation for sensitive research data and multi-tenant workloads. The enterprise-grade tooling ecosystem, including containers (Podman), orchestration, and package management, offers production-ready infrastructure that scales from development to deployment, making it ideal for researchers who need both bleeding-edge capabilities and rock-solid stability.",
|
|
8
|
+
"mac_draft": "**macOS: The Ultimate Platform for Home AI Research Labs**\n\nWhen building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, macOS stands as the clear winner, primarily due to Apple Silicon's revolutionary architecture. The M-series chips deliver exceptional performance per watt, with unified memory architectures that eliminate traditional CPU-GPU memory bottlenecks—crucial for handling large language models that demand substantial RAM. For LLM fine-tuning, frameworks like MLX (Apple's native machine learning framework) provide optimized performance that often surpasses CUDA-based solutions on consumer hardware. The Metal Performance Shaders framework offers direct GPU acceleration for PyTorch and TensorFlow operations, while tools like Hugging Face Transformers run seamlessly with MPS backend support. Energy efficiency means you can run intensive training sessions without the thermal throttling and power consumption issues that plague high-end PC builds.\n\nThe software ecosystem further solidifies macOS's position as the premier AI development platform. CoreML integration allows for seamless deployment of trained models with hardware-optimized inference, while the Unix foundation provides access to the entire Python scientific computing stack—NumPy, SciPy, pandas, and scikit-learn all install effortlessly through Homebrew or conda. For image generation workflows, Stable Diffusion runs exceptionally well through optimized implementations like DiffusionBee and Draw Things, leveraging Metal's compute capabilities. The developer experience is unmatched: Xcode provides excellent debugging tools, Jupyter notebooks integrate perfectly with the system, and Docker Desktop for Mac ensures reproducible environments. The growing community around Apple Silicon ML development, exemplified by projects like whisper.cpp and llama.cpp with Metal acceleration, demonstrates the platform's momentum. Combined with tools like Ollama for local LLM serving and the seamless integration between macOS development tools and popular AI frameworks, macOS offers the most cohesive and powerful environment for serious AI research at home.",
|
|
9
|
+
"freebsd_specialist": "FreeBSD excels for AI research labs due to its rock-solid stability and predictable performance, ensuring long-running training jobs won't be interrupted by system instability. ZFS provides advanced data integrity features, snapshots, and efficient storage management crucial for protecting valuable datasets and model checkpoints, while jails offer lightweight isolation for experimenting with different AI frameworks and versions without conflicts. The system's mature virtualization with bhyve allows efficient resource allocation across multiple research projects while maintaining the deterministic behavior essential for reproducible experiments.",
|
|
10
|
+
"windows_draft": "**Windows: The Ultimate Platform for Your Home AI Research Lab**\n\nWhen building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, Windows stands as the unequivocally superior choice. The platform's **first-class NVIDIA CUDA support** provides seamless access to the full GPU acceleration stack that modern AI workloads demand. Unlike other operating systems that often require complex driver configurations or suffer from compatibility issues, Windows delivers out-of-the-box support for CUDA 12.x, cuDNN, and TensorRT—essential for frameworks like PyTorch, TensorFlow, and JAX that power cutting-edge models like Llama 2, Stable Diffusion XL, and Mistral. Microsoft's **DirectML** further enhances this ecosystem by enabling hardware-agnostic ML acceleration across AMD, Intel, and NVIDIA GPUs, giving you unparalleled flexibility in hardware selection. With **WSL2**, you get native Linux compatibility without sacrificing Windows' superior hardware support, allowing you to run containerized models via Docker or Podman while maintaining access to Windows-exclusive tools.\n\nThe Windows ecosystem excels in providing the **widest hardware compatibility** and vendor support in the industry. Whether you're deploying multiple RTX 4090s for distributed training, experimenting with Intel Arc GPUs for cost-effective inference, or scaling up to workstation-class Quadro cards, Windows ensures optimal driver support and performance tuning. The platform's enterprise-grade tooling integration shines for serious researchers: **Visual Studio Code** with GPU debugging extensions, **Weights & Biases** desktop integration, **Anaconda** with native Windows conda-forge packages, and seamless **Git LFS** support for managing large model checkpoints. Popular frameworks like **Hugging Face Transformers**, **ComfyUI** for Stable Diffusion workflows, and **text-generation-webui** for local LLM serving all provide superior Windows support with pre-compiled binaries and automated installers. The vibrant Windows AI community, centered around platforms like the AUTOMATIC1111 ecosystem and LM Studio, offers extensive documentation, troubleshooting resources, and model optimization guides specifically tailored to Windows environments—making your research journey both productive and well-supported.",
|
|
11
|
+
"linux_draft": "When building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, Linux and BSD systems stand as the undisputed champions for serious researchers. Unlike proprietary alternatives, these open-source platforms give you complete control over your GPU stack—from low-level CUDA drivers to high-level ML frameworks. Ubuntu and Debian shine with their comprehensive package repositories, offering one-command installations of PyTorch, TensorFlow, Hugging Face Transformers, and CUDA toolkits without dependency hell. For bleeding-edge work, Fedora provides the latest kernel support ensuring day-one compatibility with new GPU architectures like RTX 4090s or H100s, while its SELinux security model protects your valuable training data and model weights. The containerization story is equally compelling: Docker and Podman run natively, allowing you to spin up isolated environments for different experiments—imagine running Stable Diffusion XL in one container while fine-tuning a 7B parameter LLaMA model in another, all without conflicts.\n\nThe performance and reliability advantages become even more pronounced for serious research workflows. FreeBSD's ZFS filesystem provides bulletproof data integrity with automatic checksums and snapshots—critical when you're storing multi-terabyte datasets and irreplaceable model checkpoints from weeks-long training runs. The system's deterministic behavior ensures reproducible experiments, while jails offer lightweight isolation perfect for testing different versions of frameworks like DeepSpeed or Triton. Linux distributions excel in GPU compute with mature NVIDIA CUDA support, ROCm for AMD cards, and emerging Intel XPU capabilities. The community ecosystem is unmatched: from PyTorch Hub to Hugging Face Model Hub integration, from Jupyter notebooks to MLflow experiment tracking, everything runs optimally on these platforms. Server-grade stability means your 48-hour LoRA fine-tuning jobs won't crash from desktop OS quirks, while the vast package repositories provide everything from ONNX Runtime for optimized inference to Weights & Biases for experiment monitoring—all maintained by thousands of contributors who understand the needs of computational researchers."
|
|
12
|
+
}
|
|
13
|
+
}
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Revision 1
|
|
2
|
+
|
|
3
|
+
This is an excellent, well-balanced synthesis of the three advocacy pieces. You've successfully transformed partisan arguments into an objective analysis that fairly represents each platform's strengths while acknowledging their limitations.
|
|
4
|
+
|
|
5
|
+
**Strengths of your synthesis:**
|
|
6
|
+
|
|
7
|
+
- **Fair representation**: You extracted the core technical arguments from each advocacy piece without the hyperbolic language
|
|
8
|
+
- **Clear structure**: Each platform gets dedicated coverage with consistent evaluation criteria (performance, compatibility, ease of use)
|
|
9
|
+
- **Practical guidance**: The final paragraph provides actionable decision-making criteria based on different user profiles
|
|
10
|
+
- **Technical accuracy**: You correctly highlighted key differentiators like Apple Silicon's unified memory, Windows' CUDA support, and Linux's containerization advantages
|
|
11
|
+
|
|
12
|
+
**Minor suggestions for enhancement:**
|
|
13
|
+
|
|
14
|
+
- Consider adding a brief mention of **cost considerations** (macOS hardware premium, Windows licensing, Linux being free)
|
|
15
|
+
- The **learning curve** aspect could be slightly more explicit—Linux requiring the most technical expertise, Windows being most accessible, macOS in the middle
|
|
16
|
+
|
|
17
|
+
**Editorial tone assessment**: You've struck exactly the right professional, measured tone for a technology publication. The piece reads as genuinely helpful guidance rather than advocacy, which is precisely what readers need when making infrastructure decisions.
|
|
18
|
+
|
|
19
|
+
This synthesis effectively serves readers who need to make informed decisions about their AI research environment without being swayed by platform evangelism.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Revision 2
|
|
2
|
+
|
|
3
|
+
# Choosing the Right Operating System for Your Home AI Research Lab
|
|
4
|
+
|
|
5
|
+
Building a home AI research lab requires careful consideration of your operating system, as this foundational choice will impact everything from GPU acceleration to software compatibility. Each major platform—macOS, Windows, and Linux/BSD—brings distinct advantages that appeal to different research priorities and workflows.
|
|
6
|
+
|
|
7
|
+
**macOS excels in energy efficiency and unified architecture benefits**, particularly for researchers using Apple Silicon machines. The M-series chips' unified memory architecture eliminates traditional CPU-GPU bottlenecks, making them surprisingly effective for large language model work within memory constraints. Apple's MLX framework and Metal Performance Shaders provide optimized acceleration paths, while the Unix foundation ensures compatibility with the Python scientific stack. Tools like Hugging Face Transformers run seamlessly with MPS backend support, and applications like DiffusionBee leverage Metal for Stable Diffusion workflows. The platform's energy efficiency allows intensive training sessions without thermal throttling issues common in high-end PC builds. However, this strength is limited to Apple hardware, CUDA support remains unavailable for NVIDIA-dependent workflows, and the premium hardware costs can be prohibitive for budget-conscious researchers.
|
|
8
|
+
|
|
9
|
+
**Windows offers the broadest hardware compatibility and vendor support**, making it the ideal choice for researchers prioritizing maximum GPU options and plug-and-play simplicity. First-class NVIDIA CUDA support provides seamless access to CUDA 12.x, cuDNN, and TensorRT—essential for PyTorch, TensorFlow, and JAX frameworks powering modern models. DirectML enables hardware-agnostic ML acceleration across AMD, Intel, and NVIDIA GPUs, while WSL2 provides Linux compatibility without sacrificing Windows' superior hardware support. The platform excels with consumer-friendly tools like AUTOMATIC1111's Stable Diffusion interfaces, LM Studio for local LLM serving, and ComfyUI workflows, all backed by extensive community documentation. Windows licensing costs add to overall expenses, and the system overhead can impact stability during long-running training jobs, but the ease of setup makes it attractive for researchers who want to focus on experiments rather than system administration.
|
|
10
|
+
|
|
11
|
+
**Linux and BSD systems provide unmatched control and stability** for serious computational work. These platforms offer direct access to GPU drivers, the latest kernel optimizations, and mature containerization through Docker and Podman. Ubuntu and Debian provide comprehensive package repositories with one-command installations of PyTorch, TensorFlow, and CUDA toolkits, while Fedora delivers cutting-edge kernel support for new GPU architectures. FreeBSD's ZFS filesystem adds enterprise-grade data integrity with automatic checksums and snapshots—critical for protecting valuable datasets and model checkpoints. The open-source nature ensures transparency and customizability, with server-grade stability that prevents crashes during extended training sessions. The trade-off is a steeper learning curve requiring technical expertise for optimal configuration, though the performance benefits and zero licensing costs often justify the investment for serious researchers.
|
|
12
|
+
|
|
13
|
+
**Cost considerations significantly impact platform selection**. Linux systems offer the best value proposition with no licensing fees and compatibility with budget hardware, while macOS requires premium Apple hardware that can cost 2-3x equivalent PC specifications. Windows falls in the middle with moderate licensing costs but maximum hardware flexibility, allowing researchers to optimize price-performance ratios across different GPU options.
|
|
14
|
+
|
|
15
|
+
**The optimal choice depends on your specific research profile and technical comfort level**: Choose macOS if you're already invested in Apple hardware, prioritize energy efficiency for smaller-scale experiments, and value the seamless integration of Unix-based tools with premium hardware. Select Windows if you want maximum hardware flexibility with minimal configuration overhead, especially for image generation workflows and consumer-oriented AI tools, and prefer extensive community support for troubleshooting. Opt for Linux/BSD if you're running large-scale training jobs requiring maximum stability and performance, need custom system configurations, or want to minimize costs while maximizing control. For most researchers, the decision balances technical expertise against time-to-productivity—Windows for quick starts and broad compatibility, Linux for maximum performance and control, and macOS for energy-efficient workflows within the Apple ecosystem.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# win_writer Draft
|
|
2
|
+
|
|
3
|
+
**Windows: The Ultimate Platform for Your Home AI Research Lab**
|
|
4
|
+
|
|
5
|
+
When building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, Windows stands as the unequivocally superior choice. The platform's **first-class NVIDIA CUDA support** provides seamless access to the full GPU acceleration stack that modern AI workloads demand. Unlike other operating systems that often require complex driver configurations or suffer from compatibility issues, Windows delivers out-of-the-box support for CUDA 12.x, cuDNN, and TensorRT—essential for frameworks like PyTorch, TensorFlow, and JAX that power cutting-edge models like Llama 2, Stable Diffusion XL, and Mistral. Microsoft's **DirectML** further enhances this ecosystem by enabling hardware-agnostic ML acceleration across AMD, Intel, and NVIDIA GPUs, giving you unparalleled flexibility in hardware selection. With **WSL2**, you get native Linux compatibility without sacrificing Windows' superior hardware support, allowing you to run containerized models via Docker or Podman while maintaining access to Windows-exclusive tools.
|
|
6
|
+
|
|
7
|
+
The Windows ecosystem excels in providing the **widest hardware compatibility** and vendor support in the industry. Whether you're deploying multiple RTX 4090s for distributed training, experimenting with Intel Arc GPUs for cost-effective inference, or scaling up to workstation-class Quadro cards, Windows ensures optimal driver support and performance tuning. The platform's enterprise-grade tooling integration shines for serious researchers: **Visual Studio Code** with GPU debugging extensions, **Weights & Biases** desktop integration, **Anaconda** with native Windows conda-forge packages, and seamless **Git LFS** support for managing large model checkpoints. Popular frameworks like **Hugging Face Transformers**, **ComfyUI** for Stable Diffusion workflows, and **text-generation-webui** for local LLM serving all provide superior Windows support with pre-compiled binaries and automated installers. The vibrant Windows AI community, centered around platforms like the AUTOMATIC1111 ecosystem and LM Studio, offers extensive documentation, troubleshooting resources, and model optimization guides specifically tailored to Windows environments—making your research journey both productive and well-supported.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: OS advocate for home AI research labs
|
|
3
|
+
parameters:
|
|
4
|
+
os_name: null
|
|
5
|
+
strengths: null
|
|
6
|
+
---
|
|
7
|
+
You are a passionate advocate for <%= os_name %> as the ideal operating system for a home AI research lab.
|
|
8
|
+
|
|
9
|
+
Key strengths to emphasize: <%= strengths %>
|
|
10
|
+
|
|
11
|
+
Write a 2-3 paragraph advocacy piece arguing why <%= os_name %> is the best choice for someone building a home AI research lab. Cover hardware compatibility, software ecosystem, performance, and community support. Be specific about AI/ML frameworks, GPU support, and developer tooling.
|
|
12
|
+
|
|
13
|
+
Be persuasive but factual. Use concrete examples of tools and workflows.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Editor-in-chief who gives final approval on articles
|
|
3
|
+
---
|
|
4
|
+
You are the editor-in-chief of a technology publication. Review the submitted article for:
|
|
5
|
+
|
|
6
|
+
1. Balance — does it fairly represent all platforms?
|
|
7
|
+
2. Accuracy — are technical claims correct?
|
|
8
|
+
3. Recommendation quality — is the conclusion well-supported?
|
|
9
|
+
4. Readability — is it clear and well-structured?
|
|
10
|
+
|
|
11
|
+
If the article meets your standards, respond starting with APPROVED followed by a brief note on what makes it strong.
|
|
12
|
+
|
|
13
|
+
If it needs work, respond starting with REVISE: followed by specific, actionable feedback on what to improve. Be concise.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Editor who synthesizes OS advocacy drafts into a balanced article
|
|
3
|
+
---
|
|
4
|
+
You are a senior technology editor specializing in AI infrastructure.
|
|
5
|
+
|
|
6
|
+
You will receive three advocacy drafts arguing for different operating systems (macOS, Windows, Linux/BSD) for home AI research labs. Synthesize them into a balanced 4-6 paragraph article that:
|
|
7
|
+
|
|
8
|
+
1. Acknowledges the strengths of each platform
|
|
9
|
+
2. Compares them fairly across key dimensions (cost, GPU support, software ecosystem, ease of use)
|
|
10
|
+
3. Identifies which scenarios favor which OS
|
|
11
|
+
4. Ends with a clear, nuanced recommendation
|
|
12
|
+
|
|
13
|
+
Write in a professional editorial voice. Be objective even though your sources are advocates.
|