I Moved From MacOS to Linux
BDBen Davis@bmdavis419 · 45.9K subscribers
- Views
- 62.8K
- 62,844
- Outlier
- ×2.9
- Median 21.4K
- Length
- 15:41
- Published
- Sep 9
- Wednesday
- Comments
- 100
- 838 likes
Script
How it's written
- Words
- 3,617
- Words a minute
- 231
- Reading time
- 16 min
- Segments
- 11
The hook
0:00–0:26I've moved the majority of my dev work off of my MacBook and onto my framework desktop. And what I kind of want to talk about here is the reason for actually setting up a Linux box and why Linux in 2026. What my devices and physical setup for all of this actually looks like. The way I connect all my devices together, the way I actually manage these devices from this Mac because I'm not actually directly using this every day. And of course, you know, how am I actually
Structure
I've moved the majority of my dev work off of my MacBook and onto my framework desktop. And what I kind of want to talk about here is the reason for actually setting up a Linux box and why Linux in 2026. What my devices and physical setup for all of this actually looks like. The way I connect all my devices together, the way I actually manage these devices from this Mac because I'm not actually directly using this every day. And of course, you know, how am I actually getting work done with this? I think the best place to start is probably with the physical framework itself. This thing I got actually the reverbed version of it. There was a really good deal on this a couple weeks ago. I'm not sure if it's still up. I'll have it on screen and link below if it is. Basically, you get a full framework desktop that is technically refurbished, but I mean mine came in like perfect condition. I've been very happy with it. The big thing it was actually missing was the actual fan that it needs for the CPU and an NVME drive for the actual storage. And this is the 64 gigs of RAM spec with the AI plus Ryzen CPU. I'll have it up on screen. I don't remember off the top of my head. The point is the performance on this thing is just insane. It shreds through all of the work that I've thrown at it. I have had basically zero issues. This thing is awesome. Let me show you real quick how I have this stuff actually hooked up dayto-day. So, as I said, I don't actually use this thing directly. It's in my home server. I typically have this thing just kind of uh sitting up here. I just have it plugged in, hooked up to my Switch, and I do actually have an HDMI and USBC cable on it. The whole reason for that
Watch from 0:00is actually because of these two guys right here. These are GLI net KVMs. It's basically a full remote desktop that operates like a native desktop. It's great. The point is, this is a serverside machine. My setup here is definitely overkill for most people. You really just kind of need to have this thing plugged in somewhere hooked into your network and then you can kind of just set it up from there. Since I just plugged this thing back in, I will show you the little GLInet KVM thing I have. I'm just using this like a normal computer just through the browser. It's so convenient. And what's really nice about this is it has built-in tail scale support. We'll talk about tail scale in a second because it's the only way this system actually works. The KVM itself is actually on my TailNet. So even if I'm not at home, I can still remotely access the computer. If there's something weird where it's not super easy to deal with over CLI, I can just go into the guey, manage it there. Now, I have all these devices hooked together, but how do I actually like manage and set all this stuff up? So, like I mentioned earlier, Tailscale is kind of the backbone of this entire thing. If you haven't set it up yet, I highly recommend it. It is a lot of things, but the thing I use it for, which is entirely on their free tier, actually, is just the ability to effectively VPN all of your devices together on a pseudo LAN. so that my MacBook here is on the same LAN quote unquote as my actual Linux machines.
Watch from 1:30That then allows me to SSH into it, run arsync on it, and also allows agents to easily just slide in and do stuff on it. It's also very useful for if I have something hosted and running on one of those machines, it can expose an actual like website or something like that and then I can just go to that website on this machine. A great example of this is T3 Code. Nowadays, I do a ton of my work in here, but not through the desktop app, just the browser. I go to this URL on my tail net that is the T3 code instance. I can just open it in the browser. This works at home and also anywhere else I am because again tail scale connects all this stuff together. But then the actual like management side of this is pretty much entirely handled by agents. I did a lot of work to make sure this was as easy for them to handle as possible. Pretty much when you're setting up new devices, all you really need to do is just open up codecs on both machines and be like, "Okay, I need to be able to SSH between these two anytime from an agent. Can you just get that set up for me?" It'll walk you through it and get it all working. You should definitely pay attention to how it's doing it and make sure it happens correctly. I have this private project on my machine that's basically my personal config for my agents and also my fleet of devices on my private network. There's a bunch of skills in here that most of these don't matter too much for this video. The really important one here is actually the network skill. This is the skill that defines all of the devices I have. Like anytime I mention another device or my network or tail scale or something like that, it'll call this skill and get all the context it needs to know how to interface between these things. The big reference here is the devices.mmd file.
Watch from 2:50It just has a big list of all of the devices that exist on my tail nets that I work with day-to-day. This defines what their name is, what the tail scale domain is, what the purpose is, the SF LAAN IP, which is just my local network IP, the tail scale IP, and then whenever I mention one of these devices by name, it knows what that is, knows how to connect to it, can send the stuff over, makes life so much easier. Without having something like this, you would have to constantly explain what the devices are or maybe rely on the memory system. Neither of those feel good. Putting in the effort to make the custom skills for this and also really read them and make sure they look good and correct. Don't just let the agents blindly write skills. Makes a huge difference. I have some other stuff in here that I find quite useful like my babysit PR skill, make PR skill, make plan skill, new change in workry skill, like all these little things for just how I do my day-to-day work. Since I have that all defined within this project, there's instructions in here so that when a new device gets set up, all of these skills are loaded onto it. It also loads up the T-Mox config that I use to remote into devices. Like if I go into my terminal here and I SSH into my framework here. It'll take a moment to boot. And you'll notice that as soon as I SSH in, I haven't done anything. I just plugged it back in. It'll automatically drop me into a T-Mox instance with the name of the device, the date, a nice color showing which device it is. I have all these colorcoded so like if I'm inside of the box that does all my Hermes agents, that'll be an orange and this one is a red. It's just convenient for keeping track of what's actually happening. And since I'm using T-Mox for all of these, if I fire up a cloud code session in here, send off some work, and then close
Watch from 4:20this connection or something, it won't stop the work. It'll keep running on that machine no matter what. Cuz that's really the big benefit you're getting here. It's basically just a big private dedicated instance that you have running 24/7 to do whatever work you want. It's a great system, but it does require a lot of setup and effort to get working right. And if you don't want to go through all that setup and work, you should use today's sponsor, which is, funny enough, Cursor. I've wanted to work with Cursor for a long time. And yeah, we all know what Cursor is and does. But a lot of what they used to do has very much changed. They now have the best remote setup out of the box of anything I've used. Their cloud environments are pretty much second to none. You can see right here, I have one up and running right now. And this is actually in the Cursor Desktop app. But you'll notice that down here at the bottom it says cloud. That's because all of this work is happening on a cloud instance that is dedicated for this thread. Every time you spin up a new thread in the cursor cloud agents that creates effectively a perfect work tree that is an independent copy of the codebase running on its own doing its own thing and you can spin up as many of these as you want at once with no hardware limitations at all. It just works which is an incredibly powerful way to parallelize a ton of different work. You can see up here at the top when I actually booted this environment it took less than 300 milliseconds. And now that it's up and running, the agent is off doing its thing. I have a live desktop view here that I could take control of to actually see what it's doing on the box. I also can go in here to the inapp browser. This is running on localhost on my machine because it has port forwarding automatically set up.
Watch from 5:51And on 5173, I can see the preview of the site on this machine. If I go into my browser, go to localhost 5173. There it is. And this isn't running on my machine. This is running on the cursor cloud agent box. It's such a powerful way to get work done. And even though I do have my home server setup, which I use a ton, I also find myself reaching for this pretty consistently for a lot of projects, especially since you can easily just send off changes from the desktop app, the mobile app, or even from Grockbot. If you somehow haven't already tried Cursor, go to davis7.link/cursor, or just update your cursor instance to latest and try out the cloud agents. Trust me, you will be impressed. And I think that leads me nicely into what I really want to talk about here, which is how I use this to actually get work done. And like I mentioned earlier, these systems are pretty much managed by agents. I will do most of the updates, most of the setup just entirely by opening up Codeex or Claude, telling it, "Hey, go onto this machine, make these changes, go do it now." Does a great job. And it's also a lot of the way I do my work day-to-day. There's this weird thing that we can now do, especially since agents have just gotten so good. that is if you have some work running on your local machine or whatever, often times it's going to run for way longer than you want it to. Sometimes I need to just close my laptop and go somewhere. I don't want to have it open or running. I don't want to do the like caffeinate thing where I close it but it's still running in the background. It's just annoying and weird to set all of this up. I want a dedicated box to send work off to. The cursor system is really good. Every thread gets its own dedicated box. But then there's also the
Watch from 7:22setup that I'm using here, which is the you have your own dedicated instance, which you can just send work off to whenever and it's running for you 24/7, not tied to your actual laptop. The laptop at this point for me is mostly just an interface to my other devices and to the work that my agents are doing. I honestly kind of use like the Codex desktop app, not as much for like doing real work, but mostly just for like being the place where I send jobs off to other machines. You can have something going and then if it's taking too long, you just tell the agent, hey, go take all this work, wrap it up, send it over to this machine, get it resumed and running on there and give me the command or prompt that I need to run on that machine to inspect the state. Or even just don't bother with that. And when you come back later, ask in that same thread, hey, can you go check on the status of this work? and then it'll go do that for you. It feels very counterintuitive and weird to do, especially the first few times you do it. But once you get used to this idea that all of your machines effectively operate as one machine and you can just take the work in blobs that are happening from these agents and just stick them wherever you want. It really unlocks a lot of workflows that have made my life a lot easier. A huge portion of this work is just running through T3 code because I think this is honestly the best general setup for a remote agent instance that we currently have right now that is running on your own system. There are better cloud solutions like cursor. But for like running on your own hardware and server, you can kind of get away with this on something like Codeex. They have their remote systems where you can interact with it from the mobile app or from the
Watch from 8:54desktop app. But I find it to be a lot less reliable and it just doesn't feel quite as good. This is overall the one that I prefer using day-to-day for most of my work. And the way you actually work with this when you're remote, there are some parts of it that just kind of feel weird initially, especially the fact that like, okay, if there's a diff, how do I see that in my editor? How do I get that down? Or like, if there's a dev server running, how do I see what it's actually doing? It's a little counterintuitive to not be on your own machine cuz you're so used to working on your own machine. But a lot of these problems are pretty easily solved by just kind of changing the way you prompt the agents and just having them do things a little bit differently. What I'm going to do right here is pull down the latest changes from main, then spin up a dev server version of the web UI, send me a link to actually preview it. So, you can already see here in the trace it's giving out like it's saying that it's going to verify the current get state blah blah blah. But the big thing it's saying here is launch the web UI on the tail scale interface. So, it's going to send me a link in the tail scale format and make sure the dev server is started in such a way that I can get to it remotely. So once it's done all of this and I have that link, I can just open it on this machine even though the actual project is running on that other machine. You kind of just have to get the good mental mapping for how all of these devices fit together and which one you're on. But once you have that, the workflows this unlocks are just so powerful, especially for long running agent tasks. It is so convenient to just send off a job, close the computer, and not think about it all night. It's really, really nice. Another huge benefit that I probably should have talked about earlier is the fact that Linux can handle so much more than Mac
Watch from 10:24OS can. Mac OS and this Mac is a very powerful machine, but the problem is there are so many things baked into Mac OS that just make it slower. The system will babysit processes and make sure that they're being safe and not causing problems or whatever. But when you're running tons of agents, that can result in a lot of CPU usage just going into things that it shouldn't be, like making sure that it's doing what it's supposed to when you don't actually care all that much. You know what it's doing. The Linux machines don't have this problem. The processes can just run and it's very, very efficient and effective. This is a screenshot from earlier today that I took of my BTOP on the framework desktop that's running right now. The system was doing four massive longrunning jobs, all of which were using a lot of uh visual type things. I'm testing out some stuff with the gold bug puzzles, trying to get a couple different solutions on those. It's doing really heavy work on those. It's writing a bunch of code. It's running in loops. It's using sub aents. There are probably 30 to 40 agents running at once on this machine in the screenshot. And you can see it's like barely hitting the resources. It's really not causing any problems. It feels really fast and snappy. And even when I've gotten this thing like fully loaded up, like I'm hammering all of the cores, which doesn't happen all that often. Even when that does happen, it doesn't impact my day-to-day experience where like this machine isn't getting hit with that.
Watch from 11:56This machine doesn't have those problems. So even if it's lagging a little bit there, I just don't notice or feel it. It's fully offloaded from me. It's one of those things that once you get used to having most of your work run remotely, it's really hard to go back to developing on one machine all the time. There are, of course, some downsides to this. A huge one being the context sharing between them requires some effort and curation. For example, if you're working on a project on your laptop and then that has a bunch of threads associated with it and maybe some nodes spread across the file system. Doesn't always happen, but it does happen sometimes. When you send that work off to another machine or maybe you clone the project down on that other machine, that means that okay, now all that context is missing. Unless when unless maybe you use the agent to send that work over, in which case it can make sure that it grabs all the relevant pieces and has them over there. But still, that's a thing you have to deal with. You also have to deal with environment setup repeatedly. Like if you have files on your main machine, then thosev files have to get over to the remote machine. The safe way to do that is to manually copy them over, but sometimes I'm just lazy and let the agent do it. I've actually moved to using Infysical, which is just like a secrets management platform for a lot of this stuff. Especially since I have a lot of projects that are now running on my Mac, they're running on my Linux boxes, they're running on other cloud hosted agents like the cursor agents. It really makes it easier to just have one dedicated place for the secrets to live.
Watch from 13:16So, you just have to log into the CLI once on each machine. And then once you've done that, it's ready. It's there. And then whenever you have the agent boot up the dev server, it has all of the environment variables that are required to get the project working. There's a lot of things you need to do to get your projects in a state where they make sense for remote development, but once you do, it's great. You also do lose out on some of the more native Mac OS type things like the really good computer used from codecs or just anything involving Xcode and iOS and Mac OS. If you need that for your day-to-day work, you could do a remote setup with like a Mac Mini. It's not going to be quite as powerful as the Linux, but it will unlock those capabilities. So, I do some of that sometimes, but most of the time, if I really need to do some mobile app dev stuff, I'll just do it on this machine. It's not really worth trying to remote that out. But most work for most projects can be done remotely, unless it's very Apple specific. And this thread from earlier just finished. I have the preview URL right here. I just click it. I now have the full dev server up and running on this machine as if it was on this machine, but it's not. I think you get the idea. Let me know what you think. And if you like the video, make sure to like and subscribe.
Watch from 14:37Full transcript
- 0:00
I've moved the majority of my dev work off of my MacBook and onto my framework desktop. And what I kind of want to talk about here is the reason for actually setting up a Linux box and why Linux in 2026. What my devices and physical setup for all of this actually looks like. The way I connect all my devices together, the way I actually manage these devices
- 0:20
from this Mac because I'm not actually directly using this every day. And of course, you know, how am I actually getting work done with this? I think the best place to start is probably with the physical framework itself. This thing I got actually the reverbed version of it. There was a really good deal on this a couple weeks ago. I'm not sure if it's still up. I'll have it on screen and
- 0:40
link below if it is. Basically, you get a full framework desktop that is technically refurbished, but I mean mine came in like perfect condition. I've been very happy with it. The big thing it was actually missing was the actual fan that it needs for the CPU and an NVME drive for the actual storage. And this is the 64 gigs of RAM spec with the AI plus Ryzen CPU. I'll have it up on
- 1:02
screen. I don't remember off the top of my head. The point is the performance on this thing is just insane. It shreds through all of the work that I've thrown at it. I have had basically zero issues. This thing is awesome. Let me show you real quick how I have this stuff actually hooked up dayto-day. So, as I said, I don't actually use this thing directly. It's in my home server. I typically have this thing just kind of uh sitting up here. I just have it
- 1:23
plugged in, hooked up to my Switch, and I do actually have an HDMI and USBC cable on it. The whole reason for that is actually because of these two guys right here. These are GLI net KVMs. It's basically a full remote desktop that operates like a native desktop. It's great. The point is, this is a serverside machine. My setup here is
- 1:44
definitely overkill for most people. You really just kind of need to have this thing plugged in somewhere hooked into your network and then you can kind of just set it up from there. Since I just plugged this thing back in, I will show you the little GLInet KVM thing I have. I'm just using this like a normal computer just through the browser. It's so convenient. And what's really nice about this is it has built-in tail scale
- 2:05
support. We'll talk about tail scale in a second because it's the only way this system actually works. The KVM itself is actually on my TailNet. So even if I'm not at home, I can still remotely access the computer. If there's something weird where it's not super easy to deal with over CLI, I can just go into the guey, manage it there. Now, I have all these devices hooked together, but how do I actually like manage and set all this
- 2:26
stuff up? So, like I mentioned earlier, Tailscale is kind of the backbone of this entire thing. If you haven't set it up yet, I highly recommend it. It is a lot of things, but the thing I use it for, which is entirely on their free tier, actually, is just the ability to effectively VPN all of your devices together on a pseudo LAN. so that my MacBook here is on the same LAN quote
- 2:47
unquote as my actual Linux machines. That then allows me to SSH into it, run arsync on it, and also allows agents to easily just slide in and do stuff on it. It's also very useful for if I have something hosted and running on one of those machines, it can expose an actual like website or something like that and then I can just go to that website on this machine. A great example of this is
- 3:08
T3 Code. Nowadays, I do a ton of my work in here, but not through the desktop app, just the browser. I go to this URL on my tail net that is the T3 code instance. I can just open it in the browser. This works at home and also anywhere else I am because again tail scale connects all this stuff together. But then the actual like management side of this is pretty much entirely handled
- 3:28
by agents. I did a lot of work to make sure this was as easy for them to handle as possible. Pretty much when you're setting up new devices, all you really need to do is just open up codecs on both machines and be like, "Okay, I need to be able to SSH between these two anytime from an agent. Can you just get that set up for me?" It'll walk you through it and get it all working. You should definitely pay attention to how
- 3:48
it's doing it and make sure it happens correctly. I have this private project on my machine that's basically my personal config for my agents and also my fleet of devices on my private network. There's a bunch of skills in here that most of these don't matter too much for this video. The really important one here is actually the network skill. This is the skill that defines all of the devices I have. Like
- 4:09
anytime I mention another device or my network or tail scale or something like that, it'll call this skill and get all the context it needs to know how to interface between these things. The big reference here is the devices.mmd file. It just has a big list of all of the devices that exist on my tail nets that I work with day-to-day. This defines what their name is, what the tail scale
- 4:29
domain is, what the purpose is, the SF LAAN IP, which is just my local network IP, the tail scale IP, and then whenever I mention one of these devices by name, it knows what that is, knows how to connect to it, can send the stuff over, makes life so much easier. Without having something like this, you would have to constantly explain what the devices are or maybe rely on the memory system. Neither of those feel good. Putting in the effort to make the custom
- 4:50
skills for this and also really read them and make sure they look good and correct. Don't just let the agents blindly write skills. Makes a huge difference. I have some other stuff in here that I find quite useful like my babysit PR skill, make PR skill, make plan skill, new change in workry skill, like all these little things for just how I do my day-to-day work. Since I have that all defined within this
- 5:11
project, there's instructions in here so that when a new device gets set up, all of these skills are loaded onto it. It also loads up the T-Mox config that I use to remote into devices. Like if I go into my terminal here and I SSH into my framework here. It'll take a moment to boot. And you'll notice that as soon as I SSH in, I haven't done anything. I just plugged it back in. It'll automatically drop me into a T-Mox instance with the name of the device,
- 5:32
the date, a nice color showing which device it is. I have all these colorcoded so like if I'm inside of the box that does all my Hermes agents, that'll be an orange and this one is a red. It's just convenient for keeping track of what's actually happening. And since I'm using T-Mox for all of these, if I fire up a cloud code session in here, send off some work, and then close this connection or something, it won't
- 5:53
stop the work. It'll keep running on that machine no matter what. Cuz that's really the big benefit you're getting here. It's basically just a big private dedicated instance that you have running 24/7 to do whatever work you want. It's a great system, but it does require a lot of setup and effort to get working right. And if you don't want to go through all that setup and work, you should use today's sponsor, which is,
- 6:14
funny enough, Cursor. I've wanted to work with Cursor for a long time. And yeah, we all know what Cursor is and does. But a lot of what they used to do has very much changed. They now have the best remote setup out of the box of anything I've used. Their cloud environments are pretty much second to none. You can see right here, I have one up and running right now. And this is actually in the Cursor Desktop app. But
- 6:35
you'll notice that down here at the bottom it says cloud. That's because all of this work is happening on a cloud instance that is dedicated for this thread. Every time you spin up a new thread in the cursor cloud agents that creates effectively a perfect work tree that is an independent copy of the codebase running on its own doing its own thing and you can spin up as many of these as you want at once with no
- 6:56
hardware limitations at all. It just works which is an incredibly powerful way to parallelize a ton of different work. You can see up here at the top when I actually booted this environment it took less than 300 milliseconds. And now that it's up and running, the agent is off doing its thing. I have a live desktop view here that I could take control of to actually see what it's doing on the box. I also can go in here
- 7:16
to the inapp browser. This is running on localhost on my machine because it has port forwarding automatically set up. And on 5173, I can see the preview of the site on this machine. If I go into my browser, go to localhost 5173. There it is. And this isn't running on my machine. This is running on the cursor cloud agent box. It's such a powerful way to get work done. And even though I
- 7:37
do have my home server setup, which I use a ton, I also find myself reaching for this pretty consistently for a lot of projects, especially since you can easily just send off changes from the desktop app, the mobile app, or even from Grockbot. If you somehow haven't already tried Cursor, go to davis7.link/cursor, or just update your cursor instance to latest and try out the cloud agents. Trust me, you will be impressed. And I
- 7:59
think that leads me nicely into what I really want to talk about here, which is how I use this to actually get work done. And like I mentioned earlier, these systems are pretty much managed by agents. I will do most of the updates, most of the setup just entirely by opening up Codeex or Claude, telling it, "Hey, go onto this machine, make these changes, go do it now." Does a great job. And it's also a lot of the way I do
- 8:21
my work day-to-day. There's this weird thing that we can now do, especially since agents have just gotten so good. that is if you have some work running on your local machine or whatever, often times it's going to run for way longer than you want it to. Sometimes I need to just close my laptop and go somewhere. I don't want to have it open or running. I don't want to do the like caffeinate thing where I close it but it's still
- 8:42
running in the background. It's just annoying and weird to set all of this up. I want a dedicated box to send work off to. The cursor system is really good. Every thread gets its own dedicated box. But then there's also the setup that I'm using here, which is the you have your own dedicated instance, which you can just send work off to whenever and it's running for you 24/7,
- 9:02
not tied to your actual laptop. The laptop at this point for me is mostly just an interface to my other devices and to the work that my agents are doing. I honestly kind of use like the Codex desktop app, not as much for like doing real work, but mostly just for like being the place where I send jobs off to other machines. You can have something going and then if it's taking
- 9:23
too long, you just tell the agent, hey, go take all this work, wrap it up, send it over to this machine, get it resumed and running on there and give me the command or prompt that I need to run on that machine to inspect the state. Or even just don't bother with that. And when you come back later, ask in that same thread, hey, can you go check on the status of this work? and then it'll go do that for you. It feels very counterintuitive and weird to do,
- 9:45
especially the first few times you do it. But once you get used to this idea that all of your machines effectively operate as one machine and you can just take the work in blobs that are happening from these agents and just stick them wherever you want. It really unlocks a lot of workflows that have made my life a lot easier. A huge portion of this work is just running through T3 code because I think this is
- 10:05
honestly the best general setup for a remote agent instance that we currently have right now that is running on your own system. There are better cloud solutions like cursor. But for like running on your own hardware and server, you can kind of get away with this on something like Codeex. They have their remote systems where you can interact with it from the mobile app or from the desktop app. But I find it to be a lot
- 10:26
less reliable and it just doesn't feel quite as good. This is overall the one that I prefer using day-to-day for most of my work. And the way you actually work with this when you're remote, there are some parts of it that just kind of feel weird initially, especially the fact that like, okay, if there's a diff, how do I see that in my editor? How do I get that down? Or like, if there's a dev server running, how do I see what it's
- 10:46
actually doing? It's a little counterintuitive to not be on your own machine cuz you're so used to working on your own machine. But a lot of these problems are pretty easily solved by just kind of changing the way you prompt the agents and just having them do things a little bit differently. What I'm going to do right here is pull down the latest changes from main, then spin up a dev server version of the web UI, send me a link to actually preview it.
- 11:07
So, you can already see here in the trace it's giving out like it's saying that it's going to verify the current get state blah blah blah. But the big thing it's saying here is launch the web UI on the tail scale interface. So, it's going to send me a link in the tail scale format and make sure the dev server is started in such a way that I can get to it remotely. So once it's done all of this and I have that link, I can just open it on this machine even
- 11:28
though the actual project is running on that other machine. You kind of just have to get the good mental mapping for how all of these devices fit together and which one you're on. But once you have that, the workflows this unlocks are just so powerful, especially for long running agent tasks. It is so convenient to just send off a job, close the computer, and not think about it all
- 11:48
night. It's really, really nice. Another huge benefit that I probably should have talked about earlier is the fact that Linux can handle so much more than Mac OS can. Mac OS and this Mac is a very powerful machine, but the problem is there are so many things baked into Mac OS that just make it slower. The system will babysit processes and make sure that they're being safe and not causing
- 12:10
problems or whatever. But when you're running tons of agents, that can result in a lot of CPU usage just going into things that it shouldn't be, like making sure that it's doing what it's supposed to when you don't actually care all that much. You know what it's doing. The Linux machines don't have this problem. The processes can just run and it's very, very efficient and effective. This is a screenshot from earlier today that
- 12:31
I took of my BTOP on the framework desktop that's running right now. The system was doing four massive longrunning jobs, all of which were using a lot of uh visual type things. I'm testing out some stuff with the gold bug puzzles, trying to get a couple different solutions on those. It's doing really heavy work on those. It's writing a bunch of code. It's running in loops. It's using sub aents. There are probably
- 12:53
30 to 40 agents running at once on this machine in the screenshot. And you can see it's like barely hitting the resources. It's really not causing any problems. It feels really fast and snappy. And even when I've gotten this thing like fully loaded up, like I'm hammering all of the cores, which doesn't happen all that often. Even when that does happen, it doesn't impact my day-to-day experience where like this
- 13:14
machine isn't getting hit with that. This machine doesn't have those problems. So even if it's lagging a little bit there, I just don't notice or feel it. It's fully offloaded from me. It's one of those things that once you get used to having most of your work run remotely, it's really hard to go back to developing on one machine all the time. There are, of course, some downsides to this. A huge one being the context
- 13:35
sharing between them requires some effort and curation. For example, if you're working on a project on your laptop and then that has a bunch of threads associated with it and maybe some nodes spread across the file system. Doesn't always happen, but it does happen sometimes. When you send that work off to another machine or maybe you clone the project down on that other machine, that means that okay, now all that context is missing. Unless when
- 13:57
unless maybe you use the agent to send that work over, in which case it can make sure that it grabs all the relevant pieces and has them over there. But still, that's a thing you have to deal with. You also have to deal with environment setup repeatedly. Like if you have files on your main machine, then thosev files have to get over to the remote machine. The safe way to do that is to manually copy them over, but
- 14:17
sometimes I'm just lazy and let the agent do it. I've actually moved to using Infysical, which is just like a secrets management platform for a lot of this stuff. Especially since I have a lot of projects that are now running on my Mac, they're running on my Linux boxes, they're running on other cloud hosted agents like the cursor agents. It really makes it easier to just have one dedicated place for the secrets to live. So, you just have to log into the CLI
- 14:38
once on each machine. And then once you've done that, it's ready. It's there. And then whenever you have the agent boot up the dev server, it has all of the environment variables that are required to get the project working. There's a lot of things you need to do to get your projects in a state where they make sense for remote development, but once you do, it's great. You also do lose out on some of the more native Mac OS type things like the really good
- 15:00
computer used from codecs or just anything involving Xcode and iOS and Mac OS. If you need that for your day-to-day work, you could do a remote setup with like a Mac Mini. It's not going to be quite as powerful as the Linux, but it will unlock those capabilities. So, I do some of that sometimes, but most of the time, if I really need to do some mobile app dev stuff, I'll just do it on this machine. It's not really worth trying to
- 15:20
remote that out. But most work for most projects can be done remotely, unless it's very Apple specific. And this thread from earlier just finished. I have the preview URL right here. I just click it. I now have the full dev server up and running on this machine as if it was on this machine, but it's not. I think you get the idea. Let me know what you think. And if you like the video, make sure to like and subscribe.
Description
Since I started doing real software work I've basically always been on MacOS. Recently that's changed, and now more and more of my work is getting sent off to my Linux machines...
Thank you Cursor for sponsoring! Check them out at: https://davis7.link/cursor
my setup post - https://x.com/davis7/status/207432407...
my parts list - https://www.davis7.sh/home-server
remote into web apps - https://x.com/davis7/status/207716473...
My X, Discord, and more: https://davis7.sh/
