robot_lab 0.1.0 → 0.2.1
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/.architecture/AGENTS.md +32 -0
- data/.architecture/config.yml +8 -0
- data/.architecture/members.yml +60 -0
- data/.architecture/reviews/feature-free-will.md +490 -0
- data/.architecture/reviews/overall-codebase.md +427 -0
- data/.claude/settings.local.json +57 -0
- data/.codex/config.toml +2 -0
- data/.irbrc +2 -2
- data/.rubocop.yml +172 -0
- data/CHANGELOG.md +72 -0
- data/CLAUDE.md +139 -0
- data/README.md +91 -95
- data/Rakefile +109 -3
- data/agent2agent_review.md +192 -0
- data/agentf_improvements.md +253 -0
- data/agents.md +14 -0
- data/docs/examples/index.md +37 -2
- data/docs/getting-started/configuration.md +20 -7
- data/docs/guides/index.md +16 -16
- data/docs/guides/knowledge.md +7 -1
- data/docs/guides/observability.md +132 -0
- data/docs/index.md +30 -3
- data/docs/superpowers/plans/2026-05-06-agentskills.md +1303 -0
- data/docs/superpowers/specs/2026-05-06-agentskills-design.md +247 -0
- data/examples/.envrc +1 -0
- data/examples/01_simple_robot.rb +5 -9
- data/examples/02_tools.rb +5 -9
- data/examples/03_network.rb +8 -9
- data/examples/04_mcp.rb +21 -29
- data/examples/05_streaming.rb +12 -18
- data/examples/06_prompt_templates.rb +11 -19
- data/examples/07_network_memory.rb +16 -31
- data/examples/08_llm_config.rb +10 -22
- data/examples/09_chaining.rb +16 -27
- data/examples/10_memory.rb +12 -28
- data/examples/11_network_introspection.rb +15 -29
- data/examples/12_message_bus.rb +5 -12
- data/examples/13_spawn.rb +5 -10
- data/examples/14_rusty_circuit/.envrc +1 -0
- data/examples/14_rusty_circuit/comic.rb +2 -0
- data/examples/14_rusty_circuit/heckler.rb +1 -1
- data/examples/14_rusty_circuit/open_mic.rb +1 -3
- data/examples/14_rusty_circuit/scout.rb +2 -0
- data/examples/15_memory_network_and_bus/.envrc +1 -0
- data/examples/15_memory_network_and_bus/editorial_pipeline.rb +6 -3
- data/examples/15_memory_network_and_bus/linux_writer.rb +1 -1
- data/examples/15_memory_network_and_bus/output/combined_article.md +6 -6
- data/examples/15_memory_network_and_bus/output/final_article.md +6 -8
- data/examples/15_memory_network_and_bus/output/linux_draft.md +4 -2
- data/examples/15_memory_network_and_bus/output/mac_draft.md +3 -3
- data/examples/15_memory_network_and_bus/output/memory.json +6 -6
- data/examples/15_memory_network_and_bus/output/revision_1.md +10 -11
- data/examples/15_memory_network_and_bus/output/revision_2.md +6 -8
- data/examples/15_memory_network_and_bus/output/windows_draft.md +3 -3
- data/examples/16_writers_room/.envrc +1 -0
- data/examples/16_writers_room/writers_room.rb +2 -4
- data/examples/17_skills.rb +8 -17
- data/examples/18_rails/Gemfile +1 -0
- data/examples/19_token_tracking.rb +9 -15
- data/examples/20_circuit_breaker.rb +10 -19
- data/examples/21_learning_loop.rb +11 -20
- data/examples/22_context_compression.rb +6 -13
- data/examples/23_convergence.rb +6 -17
- data/examples/24_structured_delegation.rb +11 -15
- data/examples/25_history_search.rb +5 -12
- data/examples/26_document_store.rb +6 -13
- data/examples/27_incident_response/incident_response.rb +4 -5
- data/examples/28_mcp_discovery.rb +8 -11
- data/examples/29_ractor_tools.rb +4 -9
- data/examples/30_ractor_network.rb +10 -19
- data/examples/31_launch_assessment.rb +10 -23
- data/examples/32_newsletter_reader.rb +188 -0
- data/examples/33_stock_generator.rb +80 -0
- data/examples/33_stock_predictor.rb +306 -0
- data/examples/34_agentskills.rb +72 -0
- data/examples/README.md +1 -1
- data/examples/common.rb +76 -0
- data/examples/ruboruby.md +423 -0
- data/examples/temp.md +51 -0
- data/lib/robot_lab/agent_skill.rb +63 -0
- data/lib/robot_lab/agent_skill_catalog.rb +74 -0
- data/lib/robot_lab/ask_user.rb +2 -2
- data/lib/robot_lab/bus_poller.rb +12 -5
- data/lib/robot_lab/config.rb +1 -12
- data/lib/robot_lab/delegation_future.rb +1 -1
- data/lib/robot_lab/doom_loop_detector.rb +98 -0
- data/lib/robot_lab/history_compressor.rb +4 -10
- data/lib/robot_lab/mcp/client.rb +1 -2
- data/lib/robot_lab/mcp/connection_poller.rb +3 -3
- data/lib/robot_lab/mcp/server.rb +1 -1
- data/lib/robot_lab/mcp/server_discovery.rb +0 -2
- data/lib/robot_lab/memory.rb +32 -27
- data/lib/robot_lab/memory_change.rb +2 -2
- data/lib/robot_lab/message.rb +4 -4
- data/lib/robot_lab/network.rb +11 -6
- data/lib/robot_lab/robot/agent_skill_matching.rb +99 -0
- data/lib/robot_lab/robot/bus_messaging.rb +9 -27
- data/lib/robot_lab/robot/history_search.rb +4 -1
- data/lib/robot_lab/robot/mcp_management.rb +5 -11
- data/lib/robot_lab/robot/template_rendering.rb +60 -40
- data/lib/robot_lab/robot.rb +323 -206
- data/lib/robot_lab/robot_result.rb +6 -5
- data/lib/robot_lab/run_config.rb +5 -11
- data/lib/robot_lab/script_tool.rb +76 -0
- data/lib/robot_lab/state_proxy.rb +7 -5
- data/lib/robot_lab/tool.rb +3 -3
- data/lib/robot_lab/tool_config.rb +1 -1
- data/lib/robot_lab/tool_manifest.rb +5 -7
- data/lib/robot_lab/user_message.rb +2 -2
- data/lib/robot_lab/version.rb +1 -1
- data/lib/robot_lab/waiter.rb +1 -1
- data/lib/robot_lab.rb +41 -52
- data/logfile +8 -0
- data/mkdocs.yml +2 -3
- data/robot_concurrency.md +38 -0
- data/simple_acp_review.md +298 -0
- data/site/404.html +2300 -0
- data/site/api/core/index.html +2706 -0
- data/site/api/core/memory/index.html +3793 -0
- data/site/api/core/network/index.html +3500 -0
- data/site/api/core/robot/index.html +4566 -0
- data/site/api/core/state/index.html +3390 -0
- data/site/api/core/tool/index.html +3843 -0
- data/site/api/index.html +2635 -0
- data/site/api/mcp/client/index.html +3435 -0
- data/site/api/mcp/index.html +2783 -0
- data/site/api/mcp/server/index.html +3252 -0
- data/site/api/mcp/transports/index.html +3352 -0
- data/site/api/messages/index.html +2641 -0
- data/site/api/messages/text-message/index.html +3087 -0
- data/site/api/messages/tool-call-message/index.html +3159 -0
- data/site/api/messages/tool-result-message/index.html +3252 -0
- data/site/api/messages/user-message/index.html +3212 -0
- data/site/api/streaming/context/index.html +3282 -0
- data/site/api/streaming/events/index.html +3347 -0
- data/site/api/streaming/index.html +2738 -0
- data/site/architecture/core-concepts/index.html +3757 -0
- data/site/architecture/index.html +2797 -0
- data/site/architecture/message-flow/index.html +3238 -0
- data/site/architecture/network-orchestration/index.html +3433 -0
- data/site/architecture/robot-execution/index.html +3140 -0
- data/site/architecture/state-management/index.html +3498 -0
- data/site/assets/css/custom.css +56 -0
- data/site/assets/images/favicon.png +0 -0
- data/site/assets/images/robot_lab.jpg +0 -0
- data/site/assets/javascripts/bundle.79ae519e.min.js +16 -0
- data/site/assets/javascripts/bundle.79ae519e.min.js.map +7 -0
- data/site/assets/javascripts/lunr/min/lunr.ar.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.da.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.de.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.du.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.el.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.es.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.fi.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.fr.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.he.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.hi.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.hu.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.hy.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.it.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.ja.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.jp.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.kn.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.ko.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.multi.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.nl.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.no.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.pt.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.ro.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.ru.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.sa.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.stemmer.support.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.sv.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.ta.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.te.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.th.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.tr.min.js +18 -0
- data/site/assets/javascripts/lunr/min/lunr.vi.min.js +1 -0
- data/site/assets/javascripts/lunr/min/lunr.zh.min.js +1 -0
- data/site/assets/javascripts/lunr/tinyseg.js +206 -0
- data/site/assets/javascripts/lunr/wordcut.js +6708 -0
- data/site/assets/javascripts/workers/search.2c215733.min.js +42 -0
- data/site/assets/javascripts/workers/search.2c215733.min.js.map +7 -0
- data/site/assets/stylesheets/main.484c7ddc.min.css +1 -0
- data/site/assets/stylesheets/main.484c7ddc.min.css.map +1 -0
- data/site/assets/stylesheets/palette.ab4e12ef.min.css +1 -0
- data/site/assets/stylesheets/palette.ab4e12ef.min.css.map +1 -0
- data/site/concepts/index.html +3455 -0
- data/site/examples/basic-chat/index.html +2880 -0
- data/site/examples/index.html +2907 -0
- data/site/examples/mcp-server/index.html +3018 -0
- data/site/examples/multi-robot-network/index.html +3131 -0
- data/site/examples/rails-application/index.html +3329 -0
- data/site/examples/tool-usage/index.html +3085 -0
- data/site/getting-started/configuration/index.html +3745 -0
- data/site/getting-started/index.html +2572 -0
- data/site/getting-started/installation/index.html +2981 -0
- data/site/getting-started/quick-start/index.html +2942 -0
- data/site/guides/building-robots/index.html +4290 -0
- data/site/guides/creating-networks/index.html +3858 -0
- data/site/guides/index.html +2586 -0
- data/site/guides/mcp-integration/index.html +3581 -0
- data/site/guides/memory/index.html +3586 -0
- data/site/guides/rails-integration/index.html +4019 -0
- data/site/guides/streaming/index.html +3157 -0
- data/site/guides/using-tools/index.html +3802 -0
- data/site/index.html +2671 -0
- data/site/search/search_index.json +1 -0
- data/site/sitemap.xml +183 -0
- data/site/sitemap.xml.gz +0 -0
- data/site/tags.json +1 -0
- data/temp.md +6 -0
- data/tool_manifest_plan.md +155 -0
- metadata +154 -92
- data/docs/examples/rails-application.md +0 -419
- data/docs/guides/ractor-parallelism.md +0 -364
- data/docs/guides/rails-integration.md +0 -681
- data/docs/superpowers/plans/2026-04-14-ractor-integration.md +0 -1538
- data/docs/superpowers/specs/2026-04-14-ractor-integration-design.md +0 -258
- data/lib/generators/robot_lab/install_generator.rb +0 -90
- data/lib/generators/robot_lab/job_generator.rb +0 -40
- data/lib/generators/robot_lab/robot_generator.rb +0 -55
- data/lib/generators/robot_lab/templates/initializer.rb.tt +0 -42
- data/lib/generators/robot_lab/templates/job.rb.tt +0 -21
- data/lib/generators/robot_lab/templates/migration.rb.tt +0 -32
- data/lib/generators/robot_lab/templates/result_model.rb.tt +0 -52
- data/lib/generators/robot_lab/templates/robot.rb.tt +0 -31
- data/lib/generators/robot_lab/templates/robot_job.rb.tt +0 -18
- data/lib/generators/robot_lab/templates/robot_test.rb.tt +0 -34
- data/lib/generators/robot_lab/templates/routing_robot.rb.tt +0 -59
- data/lib/generators/robot_lab/templates/thread_model.rb.tt +0 -40
- data/lib/robot_lab/document_store.rb +0 -155
- data/lib/robot_lab/ractor_boundary.rb +0 -42
- data/lib/robot_lab/ractor_job.rb +0 -37
- data/lib/robot_lab/ractor_memory_proxy.rb +0 -85
- data/lib/robot_lab/ractor_network_scheduler.rb +0 -154
- data/lib/robot_lab/ractor_worker_pool.rb +0 -117
- data/lib/robot_lab/rails_integration/engine.rb +0 -29
- data/lib/robot_lab/rails_integration/job.rb +0 -158
- data/lib/robot_lab/rails_integration/railtie.rb +0 -51
- data/lib/robot_lab/rails_integration/turbo_stream_callbacks.rb +0 -72
data/examples/12_message_bus.rb
CHANGED
|
@@ -10,11 +10,7 @@
|
|
|
10
10
|
# Usage:
|
|
11
11
|
# bundle exec ruby examples/12_message_bus.rb
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
require_relative "../lib/robot_lab"
|
|
16
|
-
|
|
17
|
-
RubyLLM.configure { |c| c.logger = Logger.new(File::NULL) }
|
|
13
|
+
require_relative "common"
|
|
18
14
|
|
|
19
15
|
MAX_ATTEMPTS = 5
|
|
20
16
|
|
|
@@ -23,7 +19,7 @@ class Comedian < RobotLab::Robot
|
|
|
23
19
|
TEMP_STEP = 0.2
|
|
24
20
|
|
|
25
21
|
def initialize(bus:)
|
|
26
|
-
super(name: "bob", template: :comedian, bus: bus, temperature: TEMP_START)
|
|
22
|
+
super(name: "bob", model: LLM[:default].model, template: :comedian, bus: bus, temperature: TEMP_START)
|
|
27
23
|
@attempts = 0
|
|
28
24
|
on_message do |message|
|
|
29
25
|
@attempts += 1
|
|
@@ -40,7 +36,7 @@ end
|
|
|
40
36
|
|
|
41
37
|
class ComedyCritic < RobotLab::Robot
|
|
42
38
|
def initialize(bus:)
|
|
43
|
-
super(name: "alice", template: :comedy_critic, bus: bus)
|
|
39
|
+
super(name: "alice", model: LLM[:default].model, template: :comedy_critic, bus: bus)
|
|
44
40
|
@accepted = false
|
|
45
41
|
@rounds = 0
|
|
46
42
|
on_message do |message|
|
|
@@ -60,15 +56,12 @@ bus = TypedBus::MessageBus.new
|
|
|
60
56
|
bob = Comedian.new(bus: bus)
|
|
61
57
|
alice = ComedyCritic.new(bus: bus)
|
|
62
58
|
|
|
63
|
-
|
|
64
|
-
puts "Example 12: Tell Me a Funny Robot Joke"
|
|
65
|
-
puts "=" * 60
|
|
66
|
-
puts
|
|
59
|
+
banner "Tell Me a Funny Robot Joke"
|
|
67
60
|
|
|
68
61
|
puts "Alice: Tell me a funny robot joke."
|
|
69
62
|
puts
|
|
70
63
|
alice.send_message(to: :bob, content: "Tell me a funny robot joke.")
|
|
71
64
|
|
|
72
|
-
|
|
65
|
+
hr
|
|
73
66
|
puts "Attempts: #{bob.attempts} / #{MAX_ATTEMPTS}"
|
|
74
67
|
puts "Accepted: #{alice.accepted}"
|
data/examples/13_spawn.rb
CHANGED
|
@@ -13,11 +13,7 @@
|
|
|
13
13
|
# Usage:
|
|
14
14
|
# bundle exec ruby examples/13_spawn.rb
|
|
15
15
|
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
require_relative "../lib/robot_lab"
|
|
19
|
-
|
|
20
|
-
RubyLLM.configure { |c| c.logger = Logger.new(File::NULL) }
|
|
16
|
+
require_relative "common"
|
|
21
17
|
|
|
22
18
|
QUESTIONS = [
|
|
23
19
|
"Why did the Roman Empire fall?",
|
|
@@ -29,7 +25,7 @@ class Dispatcher < RobotLab::Robot
|
|
|
29
25
|
attr_reader :spawned
|
|
30
26
|
|
|
31
27
|
def initialize(bus: nil)
|
|
32
|
-
super(name: "dispatcher", template: :dispatcher, bus: bus)
|
|
28
|
+
super(name: "dispatcher", model: LLM[:default].model, template: :dispatcher, bus: bus)
|
|
33
29
|
@spawned = {}
|
|
34
30
|
@pending = {}
|
|
35
31
|
|
|
@@ -53,6 +49,7 @@ class Dispatcher < RobotLab::Robot
|
|
|
53
49
|
# Spawn the specialist (reuse if already spawned)
|
|
54
50
|
specialist = @spawned[role] ||= spawn(
|
|
55
51
|
name: role,
|
|
52
|
+
model: LLM[:default].model,
|
|
56
53
|
system_prompt: instruction
|
|
57
54
|
)
|
|
58
55
|
|
|
@@ -74,9 +71,7 @@ end
|
|
|
74
71
|
|
|
75
72
|
dispatcher = Dispatcher.new
|
|
76
73
|
|
|
77
|
-
|
|
78
|
-
puts "Example 13: Spawning Specialist Robots"
|
|
79
|
-
puts "=" * 60
|
|
74
|
+
banner "Spawning Specialist Robots"
|
|
80
75
|
|
|
81
76
|
QUESTIONS.each_with_index do |question, i|
|
|
82
77
|
puts
|
|
@@ -85,6 +80,6 @@ QUESTIONS.each_with_index do |question, i|
|
|
|
85
80
|
end
|
|
86
81
|
|
|
87
82
|
puts
|
|
88
|
-
|
|
83
|
+
hr
|
|
89
84
|
puts "Specialists spawned: #{dispatcher.spawned.keys.join(', ')}"
|
|
90
85
|
puts "Total robots on bus: #{dispatcher.spawned.size + 1}"
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export ROBOT_LAB_TEMPLATE_PATH="${PWD}/prompts"
|
|
@@ -56,6 +56,7 @@ class GetCoaching < RobotLab::Tool
|
|
|
56
56
|
robot.coaches_spawned += 1
|
|
57
57
|
robot.spawn(
|
|
58
58
|
name: "comedy_coach",
|
|
59
|
+
model: LLM[:default].model,
|
|
59
60
|
system_prompt:
|
|
60
61
|
"You are a veteran comedy coach backstage at a live show. " \
|
|
61
62
|
"A comedian is struggling and needs quick, actionable advice. " \
|
|
@@ -100,6 +101,7 @@ class Comic < RobotLab::Robot
|
|
|
100
101
|
|
|
101
102
|
super(
|
|
102
103
|
name: "comic",
|
|
104
|
+
model: LLM[:default].model,
|
|
103
105
|
template: :open_mic_comic,
|
|
104
106
|
bus: bus,
|
|
105
107
|
local_tools: [
|
|
@@ -23,7 +23,7 @@ class Heckler < RobotLab::Robot
|
|
|
23
23
|
@won_over = false
|
|
24
24
|
@display = display
|
|
25
25
|
|
|
26
|
-
super(name: "heckler", template: :open_mic_heckler, bus: bus)
|
|
26
|
+
super(name: "heckler", model: LLM[:default].model, template: :open_mic_heckler, bus: bus)
|
|
27
27
|
|
|
28
28
|
# Handle incoming messages — the core processing guard
|
|
29
29
|
# serializes all deliveries, preventing concurrent run()
|
|
@@ -38,11 +38,9 @@
|
|
|
38
38
|
|
|
39
39
|
ENV["ROBOT_LAB_TEMPLATE_PATH"] ||= File.join(__dir__, "prompts")
|
|
40
40
|
|
|
41
|
-
require_relative "
|
|
41
|
+
require_relative "../common"
|
|
42
42
|
require_relative "display"
|
|
43
43
|
|
|
44
|
-
RubyLLM.configure { |c| c.logger = Logger.new(File::NULL) }
|
|
45
|
-
|
|
46
44
|
MAX_ROUNDS = 5
|
|
47
45
|
|
|
48
46
|
require_relative "comic"
|
|
@@ -22,6 +22,7 @@ class RecruitAnalyst < RobotLab::Tool
|
|
|
22
22
|
robot.analysts_spawned += 1
|
|
23
23
|
robot.spawn(
|
|
24
24
|
name: "#{specialty}_analyst",
|
|
25
|
+
model: LLM[:default].model,
|
|
25
26
|
system_prompt:
|
|
26
27
|
"You are an expert #{specialty.tr('_', ' ')} analyst " \
|
|
27
28
|
"for stand-up comedy. You've studied the craft for decades. " \
|
|
@@ -85,6 +86,7 @@ class Scout < RobotLab::Robot
|
|
|
85
86
|
|
|
86
87
|
super(
|
|
87
88
|
name: "scout",
|
|
89
|
+
model: LLM[:default].model,
|
|
88
90
|
template: :open_mic_scout,
|
|
89
91
|
bus: bus,
|
|
90
92
|
local_tools: [
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export ROBOT_LAB_TEMPLATE_PATH="${PWD}/prompts"
|
|
@@ -36,11 +36,9 @@
|
|
|
36
36
|
|
|
37
37
|
ENV["ROBOT_LAB_TEMPLATE_PATH"] ||= File.join(__dir__, "prompts")
|
|
38
38
|
|
|
39
|
-
require_relative "
|
|
39
|
+
require_relative "../common"
|
|
40
40
|
require "fileutils"
|
|
41
41
|
|
|
42
|
-
RubyLLM.configure { |c| c.logger = Logger.new(File::NULL) }
|
|
43
|
-
|
|
44
42
|
MAX_REVISIONS = 3
|
|
45
43
|
OUTPUT_DIR = File.join(__dir__, "output")
|
|
46
44
|
|
|
@@ -59,6 +57,7 @@ bus = TypedBus::MessageBus.new
|
|
|
59
57
|
|
|
60
58
|
mac_writer = OsWriter.new(
|
|
61
59
|
name: "mac_writer",
|
|
60
|
+
model: LLM[:default].model,
|
|
62
61
|
template: :os_advocate,
|
|
63
62
|
local_tools: [RobotLab::AskUser],
|
|
64
63
|
context: {
|
|
@@ -70,6 +69,7 @@ mac_writer = OsWriter.new(
|
|
|
70
69
|
|
|
71
70
|
win_writer = OsWriter.new(
|
|
72
71
|
name: "win_writer",
|
|
72
|
+
model: LLM[:default].model,
|
|
73
73
|
template: :os_advocate,
|
|
74
74
|
local_tools: [RobotLab::AskUser],
|
|
75
75
|
context: {
|
|
@@ -81,6 +81,7 @@ win_writer = OsWriter.new(
|
|
|
81
81
|
|
|
82
82
|
linux_writer = LinuxWriter.new(
|
|
83
83
|
name: "linux_writer",
|
|
84
|
+
model: LLM[:default].model,
|
|
84
85
|
template: :os_advocate,
|
|
85
86
|
local_tools: [RobotLab::AskUser],
|
|
86
87
|
context: {
|
|
@@ -93,6 +94,7 @@ linux_writer = LinuxWriter.new(
|
|
|
93
94
|
|
|
94
95
|
editor = OsEditor.new(
|
|
95
96
|
name: "editor",
|
|
97
|
+
model: LLM[:default].model,
|
|
96
98
|
template: :os_editor,
|
|
97
99
|
bus: bus
|
|
98
100
|
)
|
|
@@ -114,6 +116,7 @@ end
|
|
|
114
116
|
|
|
115
117
|
chief = EditorInChief.new(
|
|
116
118
|
name: "chief",
|
|
119
|
+
model: LLM[:default].model,
|
|
117
120
|
template: :os_chief,
|
|
118
121
|
bus: bus
|
|
119
122
|
)
|
|
@@ -57,7 +57,7 @@ class LinuxWriter < OsWriter
|
|
|
57
57
|
|
|
58
58
|
distros.each do |distro|
|
|
59
59
|
puts " [#{@name}] Spawning #{distro[:label]} specialist..."
|
|
60
|
-
specialist = spawn(name: distro[:name], system_prompt: distro[:prompt])
|
|
60
|
+
specialist = spawn(name: distro[:name], model: LLM[:default].model, system_prompt: distro[:prompt])
|
|
61
61
|
@specialists << specialist
|
|
62
62
|
|
|
63
63
|
analysis = specialist.run(
|
|
@@ -1,13 +1,13 @@
|
|
|
1
1
|
# Combined Article (Editor Draft)
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
For a home AI research lab, the operating-system decision is less about ideology than about trade-offs among hardware, software, and the kind of work you expect to do. All three camps have real strengths. macOS offers a polished, low-friction experience on Apple Silicon, with impressive power efficiency and strong support for local inference and lightweight fine-tuning. Windows is the most flexible consumer platform for pairing modern NVIDIA GPUs with mainstream desktop workflows, and WSL2 has narrowed the gap with Linux considerably. Linux remains the closest match to the software environment used in professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-style workflows; BSD, while more niche, can be attractive for users who prioritize storage integrity and system control.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
On cost and hardware, the divide is clear. Windows and Linux generally win on price-performance if your goal is maximum GPU throughput, because both let you build or upgrade commodity x86 systems around NVIDIA RTX cards, still the center of gravity for home AI training and image-generation workloads. They also support a wider range of motherboards, storage, networking gear, and multi-GPU configurations. macOS, by contrast, is less modular and often more expensive upfront, but Apple Silicon machines deliver something unusual: quiet, compact systems with capable integrated acceleration and unified memory that can be very effective for local inference, quantized models, and practical experimentation without the heat, noise, and power draw of a discrete-GPU tower. For buyers who value efficiency and simplicity over upgradeability, that premium can be justified.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Software ecosystem and GPU support are where the distinctions matter most. Linux is still the native habitat of modern ML tooling: CUDA stacks, PyTorch, JAX, DeepSpeed, vLLM, containerized workflows, and many research repos tend to work there first. It is also the best path for AMD ROCm users. Windows is close behind for NVIDIA-centric labs, with broad support for PyTorch, TensorFlow, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends, plus the practical advantage of running desktop applications and Linux tooling side by side through WSL2. macOS has improved substantially, especially for inference and smaller-scale development via Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but it remains less universal for cutting-edge training stacks and does not offer the same straightforward path to top-end discrete GPU performance.
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Ease of use depends on what kind of friction you are trying to avoid. macOS is arguably the easiest platform to live with day to day: strong Unix underpinnings, consistent hardware support, and minimal driver drama make it appealing for researchers who want to spend more time experimenting than debugging. Windows is often the easiest place to start for users already comfortable with consumer PC hardware, especially if they want one machine for AI, productivity, and general use; its broad driver support and huge volume of community tutorials are practical advantages. Linux has the steepest learning curve for some users, but it rewards that investment with superior reproducibility, remote-management habits, and alignment with cloud and lab infrastructure. BSD is best understood as a specialist option rather than a mainstream recommendation for AI compute itself.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The best choice, then, depends on your scenario. If your lab is centered on local inference, scripting, evaluation, and moderate fine-tuning in a quiet, power-efficient machine, macOS is an excellent fit. If you want the strongest all-around home setup for NVIDIA GPUs, image generation, and mixed desktop/Linux workflows, Windows is highly compelling. If you are building a serious research environment that mirrors production or cloud infrastructure, expect to use containers heavily, or want maximum compatibility with the latest open-source training stacks, Linux is the strongest foundation.
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
My recommendation is nuanced but clear: for most serious home AI labs, Linux is the best long-term platform, with Ubuntu, Debian, or Fedora the safest bets. Windows is the best choice for users who want top consumer GPU performance with less lifestyle disruption, especially on a single versatile workstation. macOS is the best choice for researchers who prioritize stability, efficiency, and a tightly integrated system over absolute training performance. In other words, choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.
|
|
@@ -1,15 +1,13 @@
|
|
|
1
1
|
# Final Article — APPROVED
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on budget, tolerance for system maintenance, and—most important—the workload. Local inference, quantized experimentation, LoRA-style fine-tuning, and full-scale multi-GPU training place very different demands on a machine. Each platform has real strengths. macOS offers a polished, low-friction experience on Apple Silicon, with excellent power efficiency and increasingly capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style AI development. Linux, meanwhile, remains the closest match to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-style workflows. BSD is more niche, but still relevant for users who value storage integrity and system control.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually deliver the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home fine-tuning and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU setups. macOS is less modular and often more expensive upfront, but Apple Silicon offers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the heat, noise, and power draw of a traditional tower.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
The software stack is where Linux keeps its advantage. Most modern machine-learning infrastructure is developed and deployed with Linux as the default target, so CUDA, PyTorch, DeepSpeed, vLLM, Docker, and many research repositories are typically best supported there. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends. TensorFlow support is more uneven than it once was in native Windows setups, however, and many users now rely on WSL2 for a more current Linux-compatible path. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but Apple Silicon does not offer NVIDIA/CUDA-class upgradeability or equally broad support for large-scale training stacks.
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Ease of use depends on what kind of friction matters most. macOS is arguably the easiest platform to live with day to day: its Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project of its own. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, productivity, and media-heavy desktop applications; broad driver support and a vast library of community tutorials are significant advantages. Linux demands more initiative up front, but rewards that effort with stronger reproducibility, better remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better understood as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The practical recommendation depends on what “home AI lab” means in your case. If your workload is primarily local inference, evaluation, scripting, and moderate fine-tuning, macOS is an excellent fit. If you want a single versatile workstation for image generation, local model serving, and NVIDIA-accelerated experimentation—with access to Linux tooling when needed—Windows is highly compelling. If your priority is full training compatibility, containerized workflows, remote operation, or a setup that mirrors production and rented GPU environments, Linux is the strongest foundation.
|
|
12
12
|
|
|
13
|
-
|
|
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.
|
|
13
|
+
For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are built and run. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single all-purpose workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over maximum training flexibility. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.
|
|
@@ -1,5 +1,7 @@
|
|
|
1
1
|
# linux_writer Draft
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
If you’re building a home AI research lab for LLM fine-tuning, image generation, and local inference, Linux/BSD is the best foundation because it gives you full control of the hardware and software stack in a way consumer desktop OSes simply don’t. On Ubuntu/Debian, that means straightforward NVIDIA CUDA installation, broad compatibility with PyTorch, TensorFlow, JAX, Hugging Face Transformers, bitsandbytes, vLLM, Ollama, and Stable Diffusion toolchains like AUTOMATIC1111, ComfyUI, and InvokeAI. Fedora/RHEL brings the same AI-ready strengths with newer kernels, strong NVIDIA and AMD support, and excellent container workflows through Podman and Docker-compatible tooling, plus SELinux for safer multi-service setups. And if your lab values long-term predictability and data integrity, FreeBSD is compelling for its ZFS snapshots, lightweight jails, and bhyve virtualization—especially for storing large model checkpoints, datasets, and reproducible experiment environments.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Performance and workflow are where Linux/BSD really pull ahead. AI researchers want server-parity: the same CUDA libraries, Python environments, container images, SSH workflows, and orchestration patterns they’ll use on rented GPUs or lab servers. Linux is the default target for most ML infrastructure, so fine-tuning with PyTorch + DeepSpeed, FSDP, PEFT/LoRA, Axolotl, llama.cpp, or text-generation-webui generally works first and best there. ROCm support for AMD is also primarily Linux-first. Developer tooling is mature and frictionless: apt, dnf, pip, conda, uv, poetry, tmux, systemd, Podman/Docker, NVIDIA Container Toolkit, and VS Code Remote SSH all fit naturally into a research workflow. That makes it easy to run one box as a local inference host, another as a training node, and package both with containers for repeatable deployments.
|
|
6
|
+
|
|
7
|
+
Just as important, Linux/BSD gives you massive community support and a free, open ecosystem that rewards experimentation instead of fighting it. If you hit a CUDA mismatch, need a custom kernel module, want to pin an older Python for a model repo, or need community-tested guides for QLoRA fine-tuning on an RTX 4090, the answer is almost always documented somewhere for Ubuntu, Debian, Fedora, or another major distro. That depth of packages, tutorials, and forum knowledge matters when you’re juggling GPU drivers, model servers, vector databases, and web UIs at home. In practical terms: Linux is the native habitat of AI/ML tooling, Fedora/RHEL offers a modern and enterprise-grade path, Ubuntu/Debian maximize ease and compatibility, and FreeBSD adds unmatched storage discipline and clean isolation. For a serious home AI lab, Linux/BSD isn’t just a good choice—it’s the platform that most directly aligns with how modern AI systems are actually built and run.
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
# mac_writer Draft
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
macOS is a remarkably strong choice for a home AI research lab, especially if your work centers on LLM fine-tuning, image generation, and local inference. On Apple Silicon, you get an unusually compelling mix of CPU, GPU, and unified memory in one quiet, power-efficient system. That matters in real workflows: local inference with tools like Ollama, LM Studio, and llama.cpp runs smoothly on M-series Macs, while PyTorch has native Metal Performance Shaders support so models can use the integrated GPU without needing a discrete NVIDIA card. For image generation, projects such as Stable Diffusion, ComfyUI, and AUTOMATIC1111 can run effectively on macOS, and Apple’s unified memory architecture is especially useful when working with larger models or batching workflows that would otherwise be constrained by separate VRAM limits.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
The software ecosystem is another major advantage. macOS gives you a Unix foundation with first-class terminal tooling, Homebrew for package management, and easy access to Python, Conda, Docker alternatives, Git, SSH, tmux, and Jupyter-based workflows. For AI development specifically, you can work with PyTorch on Metal, TensorFlow with Apple’s ML extensions, Hugging Face Transformers, llama.cpp, ONNX Runtime, MLX, and Core ML. Apple’s MLX framework is particularly exciting for home researchers because it is built for Apple Silicon and makes training and inference on local hardware feel much more natural. Core ML also gives you a path to highly optimized deployment for local apps and edge-style workflows, which is useful if your lab includes benchmarking, model packaging, or building inference tools for personal use.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
What makes macOS arguably the best home-lab platform is how well the whole stack fits together. Hardware compatibility is simple because Apple controls the platform end to end; you are not spending weekends debugging GPU drivers, CUDA mismatches, or power and cooling issues. An M2 Max, M3 Pro, or higher-end M-series system can serve as a capable always-on research workstation that handles experimentation, scripting, quantized fine-tuning, evaluation, and media generation while drawing far less power than a traditional multi-GPU tower. Add in strong developer tooling like Xcode, VS Code, iTerm2, and excellent community support around Apple Silicon optimization, and you get a platform that is stable, efficient, and genuinely productive. If you want a home AI lab that prioritizes practical local experimentation over endless infrastructure maintenance, macOS is hard to beat.
|
|
@@ -3,11 +3,11 @@
|
|
|
3
3
|
"results": [],
|
|
4
4
|
"messages": [],
|
|
5
5
|
"custom": {
|
|
6
|
-
"ubuntu_specialist": "Ubuntu/Debian
|
|
7
|
-
"
|
|
8
|
-
"mac_draft": "
|
|
9
|
-
"
|
|
10
|
-
"
|
|
11
|
-
"linux_draft": "
|
|
6
|
+
"ubuntu_specialist": "Ubuntu/Debian is a strong choice for a home AI research lab because it offers excellent hardware and driver support, especially for NVIDIA CUDA setups, while keeping software installation straightforward through the apt ecosystem. It’s also stable, well-documented, and widely used in research and server environments, which makes troubleshooting, automation, and reproducing experiments much easier.",
|
|
7
|
+
"windows_draft": "Windows is the strongest all-around choice for a home AI research lab because it gives you the best combination of raw GPU support, hardware flexibility, and practical developer workflow. For LLM fine-tuning, image generation, and local inference, NVIDIA CUDA support on Windows is first-class: PyTorch, TensorFlow, xFormers, bitsandbytes, TensorRT, ONNX Runtime, and popular tools like Ollama, LM Studio, ComfyUI, AUTOMATIC1111, and Stable Diffusion WebUI all have strong Windows paths. If you want the highest-performance consumer GPUs for AI work, Windows pairs especially well with NVIDIA RTX hardware, from a single 4070 Ti Super up to multi-GPU prosumer setups. And if you need Linux-native scripts or package workflows, WSL2 gives you a near-seamless Ubuntu environment on the same machine, so you can run Hugging Face Transformers, PEFT, DeepSpeed, vLLM, llama.cpp, JupyterLab, and CUDA-enabled Linux tooling without giving up native Windows apps.\n\nWindows also wins on hardware compatibility and ecosystem breadth. A home lab often mixes gaming-class GPUs, high-core-count CPUs, fast NVMe storage, USB devices, capture cards, and sometimes unusual motherboard or networking gear; Windows consistently offers the widest driver support and easiest setup across that mix. Beyond CUDA, Windows also supports DirectML, which broadens acceleration options on AMD and Intel hardware for local inference and experimentation. On the tooling side, it integrates cleanly with Visual Studio Code, Visual Studio, Docker Desktop, PowerShell, Windows Terminal, Git for Windows, and enterprise-friendly tools for remote access, file sharing, backup, and virtualization. In practice, that means you can fine-tune a LoRA in WSL2, monitor GPUs with native Windows utilities, manage datasets on NTFS storage, launch ComfyUI or LM Studio from the desktop, and still have access to familiar scripting and automation.\n\nJust as important, Windows has massive community support for home AI builders. Most consumer AI guides now assume either native Windows or Windows plus WSL2, especially for Stable Diffusion workflows, local LLM front ends, and single-node fine-tuning recipes. Troubleshooting is easier when there are abundant guides for CUDA driver versions, PyTorch wheels, Flash Attention builds, and model-serving stacks on common RTX cards. For someone building a serious home AI lab, Windows offers the most practical balance: top-tier NVIDIA performance, Linux compatibility when you need it, broad hardware support, and a mature tool ecosystem that scales from casual experimentation to disciplined research workflows.",
|
|
8
|
+
"mac_draft": "macOS is a remarkably strong choice for a home AI research lab, especially if your work centers on LLM fine-tuning, image generation, and local inference. On Apple Silicon, you get an unusually compelling mix of CPU, GPU, and unified memory in one quiet, power-efficient system. That matters in real workflows: local inference with tools like Ollama, LM Studio, and llama.cpp runs smoothly on M-series Macs, while PyTorch has native Metal Performance Shaders support so models can use the integrated GPU without needing a discrete NVIDIA card. For image generation, projects such as Stable Diffusion, ComfyUI, and AUTOMATIC1111 can run effectively on macOS, and Apple’s unified memory architecture is especially useful when working with larger models or batching workflows that would otherwise be constrained by separate VRAM limits.\n\nThe software ecosystem is another major advantage. macOS gives you a Unix foundation with first-class terminal tooling, Homebrew for package management, and easy access to Python, Conda, Docker alternatives, Git, SSH, tmux, and Jupyter-based workflows. For AI development specifically, you can work with PyTorch on Metal, TensorFlow with Apple’s ML extensions, Hugging Face Transformers, llama.cpp, ONNX Runtime, MLX, and Core ML. Apple’s MLX framework is particularly exciting for home researchers because it is built for Apple Silicon and makes training and inference on local hardware feel much more natural. Core ML also gives you a path to highly optimized deployment for local apps and edge-style workflows, which is useful if your lab includes benchmarking, model packaging, or building inference tools for personal use.\n\nWhat makes macOS arguably the best home-lab platform is how well the whole stack fits together. Hardware compatibility is simple because Apple controls the platform end to end; you are not spending weekends debugging GPU drivers, CUDA mismatches, or power and cooling issues. An M2 Max, M3 Pro, or higher-end M-series system can serve as a capable always-on research workstation that handles experimentation, scripting, quantized fine-tuning, evaluation, and media generation while drawing far less power than a traditional multi-GPU tower. Add in strong developer tooling like Xcode, VS Code, iTerm2, and excellent community support around Apple Silicon optimization, and you get a platform that is stable, efficient, and genuinely productive. If you want a home AI lab that prioritizes practical local experimentation over endless infrastructure maintenance, macOS is hard to beat.",
|
|
9
|
+
"fedora_specialist": "Fedora and RHEL are strong choices for a home AI research lab because they combine up-to-date kernels, excellent NVIDIA/AMD driver support, and robust container tooling like Podman, making it easy to run modern ML workloads reliably. They also offer strong SELinux security, reproducible enterprise-style workflows, and a clear path from experimentation on Fedora to long-term stability on RHEL-compatible systems.",
|
|
10
|
+
"freebsd_specialist": "FreeBSD is a strong choice for a home AI research lab because it offers excellent stability, predictable system behavior, and powerful storage features through ZFS, which is ideal for protecting large datasets and snapshots of experiment environments. Its lightweight jails and bhyve virtualization make it easy to isolate services and test setups efficiently, while the base system’s consistency helps reduce maintenance overhead for long-running workloads.",
|
|
11
|
+
"linux_draft": "If you’re building a home AI research lab for LLM fine-tuning, image generation, and local inference, Linux/BSD is the best foundation because it gives you full control of the hardware and software stack in a way consumer desktop OSes simply don’t. On Ubuntu/Debian, that means straightforward NVIDIA CUDA installation, broad compatibility with PyTorch, TensorFlow, JAX, Hugging Face Transformers, bitsandbytes, vLLM, Ollama, and Stable Diffusion toolchains like AUTOMATIC1111, ComfyUI, and InvokeAI. Fedora/RHEL brings the same AI-ready strengths with newer kernels, strong NVIDIA and AMD support, and excellent container workflows through Podman and Docker-compatible tooling, plus SELinux for safer multi-service setups. And if your lab values long-term predictability and data integrity, FreeBSD is compelling for its ZFS snapshots, lightweight jails, and bhyve virtualization—especially for storing large model checkpoints, datasets, and reproducible experiment environments.\n\nPerformance and workflow are where Linux/BSD really pull ahead. AI researchers want server-parity: the same CUDA libraries, Python environments, container images, SSH workflows, and orchestration patterns they’ll use on rented GPUs or lab servers. Linux is the default target for most ML infrastructure, so fine-tuning with PyTorch + DeepSpeed, FSDP, PEFT/LoRA, Axolotl, llama.cpp, or text-generation-webui generally works first and best there. ROCm support for AMD is also primarily Linux-first. Developer tooling is mature and frictionless: apt, dnf, pip, conda, uv, poetry, tmux, systemd, Podman/Docker, NVIDIA Container Toolkit, and VS Code Remote SSH all fit naturally into a research workflow. That makes it easy to run one box as a local inference host, another as a training node, and package both with containers for repeatable deployments.\n\nJust as important, Linux/BSD gives you massive community support and a free, open ecosystem that rewards experimentation instead of fighting it. If you hit a CUDA mismatch, need a custom kernel module, want to pin an older Python for a model repo, or need community-tested guides for QLoRA fine-tuning on an RTX 4090, the answer is almost always documented somewhere for Ubuntu, Debian, Fedora, or another major distro. That depth of packages, tutorials, and forum knowledge matters when you’re juggling GPU drivers, model servers, vector databases, and web UIs at home. In practical terms: Linux is the native habitat of AI/ML tooling, Fedora/RHEL offers a modern and enterprise-grade path, Ubuntu/Debian maximize ease and compatibility, and FreeBSD adds unmatched storage discipline and clean isolation. For a serious home AI lab, Linux/BSD isn’t just a good choice—it’s the platform that most directly aligns with how modern AI systems are actually built and run."
|
|
12
12
|
}
|
|
13
13
|
}
|
|
@@ -1,19 +1,18 @@
|
|
|
1
1
|
# Revision 1
|
|
2
2
|
|
|
3
|
-
This is
|
|
3
|
+
This is strong as written. Here’s a lightly tightened editorial version with a slightly smoother cadence and clearer conclusion:
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on your hardware budget, tolerance for system maintenance, and the kind of AI work you plan to do. Each platform has legitimate strengths. macOS offers a polished, low-friction experience on Apple Silicon, combining strong power efficiency with capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style development. Linux, meanwhile, remains the closest analogue to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-oriented tooling. BSD is more niche, but still relevant for users who care deeply about storage integrity and system control.
|
|
6
6
|
|
|
7
|
-
-
|
|
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
|
|
7
|
+
Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually offer the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home training and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU configurations. macOS is less modular and often more expensive upfront, but Apple Silicon delivers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the noise, heat, and power demands of a traditional tower.
|
|
11
8
|
|
|
12
|
-
|
|
9
|
+
The software stack is where Linux keeps its edge. It remains the default environment for much of modern machine-learning infrastructure: CUDA, PyTorch, JAX, DeepSpeed, vLLM, Docker, and countless research repositories tend to land there first. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, TensorFlow, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends, while WSL2 allows users to mix native desktop convenience with Linux workflows on the same machine. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but it still lacks the same universality for cutting-edge training stacks and does not offer a straightforward route to top-tier discrete-GPU performance.
|
|
13
10
|
|
|
14
|
-
|
|
15
|
-
- The **learning curve** aspect could be slightly more explicit—Linux requiring the most technical expertise, Windows being most accessible, macOS in the middle
|
|
11
|
+
Ease of use depends on what kind of friction matters most to you. macOS is arguably the easiest platform to live with day to day: the Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project in itself. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, general productivity, and media-heavy desktop applications; its broad driver support and vast library of community tutorials are real advantages. Linux demands more initiative up front, but rewards that effort with better reproducibility, stronger remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better viewed as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
|
|
16
12
|
|
|
17
|
-
|
|
13
|
+
The practical recommendation is straightforward, even if the answer is not one-size-fits-all. For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are developed and deployed. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single versatile workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over absolute training performance. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.
|
|
18
14
|
|
|
19
|
-
|
|
15
|
+
If you want, I can also:
|
|
16
|
+
- make it more magazine-like and opinionated,
|
|
17
|
+
- make it shorter and punchier,
|
|
18
|
+
- or remove the final “Linux-first” tilt to make it even more neutral.
|
|
@@ -1,15 +1,13 @@
|
|
|
1
1
|
# Revision 2
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on budget, tolerance for system maintenance, and—most important—the workload. Local inference, quantized experimentation, LoRA-style fine-tuning, and full-scale multi-GPU training place very different demands on a machine. Each platform has real strengths. macOS offers a polished, low-friction experience on Apple Silicon, with excellent power efficiency and increasingly capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style AI development. Linux, meanwhile, remains the closest match to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-style workflows. BSD is more niche, but still relevant for users who value storage integrity and system control.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually deliver the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home fine-tuning and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU setups. macOS is less modular and often more expensive upfront, but Apple Silicon offers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the heat, noise, and power draw of a traditional tower.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
The software stack is where Linux keeps its advantage. Most modern machine-learning infrastructure is developed and deployed with Linux as the default target, so CUDA, PyTorch, DeepSpeed, vLLM, Docker, and many research repositories are typically best supported there. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends. TensorFlow support is more uneven than it once was in native Windows setups, however, and many users now rely on WSL2 for a more current Linux-compatible path. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but Apple Silicon does not offer NVIDIA/CUDA-class upgradeability or equally broad support for large-scale training stacks.
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Ease of use depends on what kind of friction matters most. macOS is arguably the easiest platform to live with day to day: its Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project of its own. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, productivity, and media-heavy desktop applications; broad driver support and a vast library of community tutorials are significant advantages. Linux demands more initiative up front, but rewards that effort with stronger reproducibility, better remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better understood as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The practical recommendation depends on what “home AI lab” means in your case. If your workload is primarily local inference, evaluation, scripting, and moderate fine-tuning, macOS is an excellent fit. If you want a single versatile workstation for image generation, local model serving, and NVIDIA-accelerated experimentation—with access to Linux tooling when needed—Windows is highly compelling. If your priority is full training compatibility, containerized workflows, remote operation, or a setup that mirrors production and rented GPU environments, Linux is the strongest foundation.
|
|
12
12
|
|
|
13
|
-
|
|
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.
|
|
13
|
+
For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are built and run. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single all-purpose workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over maximum training flexibility. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.
|