1. 18

    Nice setup.

    1. I really advice against the side by side monitors. There problem is, your going to have your main app open in one monitor at a time so your going to be turning your neck for hours at a time. Suggest either stacking it going with a single large monitor. I got a Dell 43” 4k monitor for $700 ish. I previously had a single 32” ultra wide, which as the author mentioned is too short. Then a friend sold me his and I stacked them. That was ok but made me standing desk hard to use in standing mode.

    I like the single monitors with a window management app. I’d love this setup now if I could get it in a curved version and a higher resolution for sharper text, but otherwise it’s amazing.

    1. I’m always amazed that people are so hesitant to spend money on their work tools. They are tax-deductible but more importantly, they are in investment in your long term health and happiness. It’s one of the biggest advantages of working from home. Your don’t have to use the cheap crap your employer provides.

    It’s doubly amazing because many in this situation are making $100k (possibly multiples of that). Also do many people have some crazy expensive bike,car,boat,guitars, home theater, etc that’s only used a few hours a week.

    I know it’s tempting to cheap out, but 30,40,50 year old you will thank you.

    That’s my PSA if the day.

    1. 3

      Shouldn’t have read this. The night just got expensive.

      1. 3

        turning your neck for hours at a time. Suggest either stacking it going with a single large monitor.

        So you should be looking up for hours at a time?

        1. 1

          The distance between the center of two widescreen monitors is much smaller when stacked than when side-by-side. And of course that’s not true of landscape or square monitors. Not ALL stacked monitors are ergonomically arranged but you can reduce neck movement by stacking.

          1. 4

            I don’t know if it’s just about distance. I find the vertical angle matters much more than the horizontal angle. For example, I find laptops difficult to use for long periods because my neck gets sore looking down all the time, instead of looking straight ahead. However, I don’t have any problems with horizontal monitors.

        2. 1

          That’s a good point about the dual monitors. I’m considering having one facing flat forward, and another angled off to the side. I’d probably have to sit off to one side of my desk but that’s not too concerning.

          I get your point about spending money on work tools, which might fall in the same category as what people say about beds & shoes. I do worry this attitude if adopted too enthusiastically can dull judgement about whether a given tool is really necessary - for example a gas-spring monitor stand instead of a basic one or an Ergodox instead of Goldtouch keyboard (although I admit being tempted by the Kinesis Advantage2 from seeing all the people who swear by it). With the way our society is set up it is often very difficult to determine (even within our own heads) whether something expensive is a reasonable purchase that supports good craftsmanship, or just a flex.

          1. 6

            Consider rotating one of the screens. I sit straight down the middle for the landscape screen, then have the portrait screen to my right.

            I’m pretty sensitive to shitty ergonomic setups, and this causes me no problems at all.

            1. 2

              This is my setup too. Looks dorky, works great.

              1. 2

                I do this too. The only problem is that 16:9 screens reeally don’t like being in portrait. I have a 24” 16:9 screen to the left of the primary screen used mostly for web browsing, and it’s really common for websites to grow a combination of horizontal scroll bars and buttons with text extending outside of their bounds.

                1. 1

                  Hah, yeah I got the last 16:10 that dell sold a few years ago and just picked up a partner for it, and having them side-by-side vertically is great, but I would be loathe to throw away 10% of that space.

                2. 1

                  That’s a neat idea, I think I’ll try that!

                3. 2

                  All decisions come with error bars. Fall on one side, you have a flex; fall on the other, you are performing worse at work than you could be.

                  I know which side I’m happier to land on.

                  1. 2

                    The main point is this: every single person I’ve had a discussion on buying quality tools for work and had an objection to spending money also had some expensive hobby they were willing to splurge on. (I’m sure not everyone is like this, just seemed the people with the strongest objection had other money sinks). Is just a matter of logical consistently. They might have $25k of bike equipment in the garage but get upity about spending $500 on good equipment. That’s why this is one of my hot button issues. A course of physical therapy is going to cost more than decent equipment.

                    My old equipment always finds it way to friends and family and tends to get years of useful life beyond me.

                    1. 2

                      There’s nothing logically inconsistent about spending money in some places and saving it in others. “I spent a bunch of money on thing X, so I should also spend a lot of money on thing Y” sounds more like sales tactic psychology than logical reasoning. You can easily get good enough ergonomic equipment to keep the PT away without spending much money. A $20 used Microsoft Natural Ergonomic 4000 keyboard, a $25 Anker vertical mouse… even monitor stands can be replaced with a stack of old technical manuals. A good chair is really the only thing I’d say you need, and you can get a good-enough used Costco model for like $60.

                      1. 1

                        a stack of old technical manuals

                        To be fair, these are harder and harder to find. Same goes for phone books…

                        1. 1

                          It is if a) this is the way you make your living and b) you are oddly cheap in this area but spend big money on things you use way less. That’s the point in trying to make and I still find the behavior quite baffling.

                          Invest in yourself and your health.

                          I’m not trying to sell you a standing desk.

                      2. 1

                        That’s a good point about the dual monitors. I’m considering having one facing flat forward, and another angled off to the side. I’d probably have to sit off to one side of my desk but that’s not too concerning.

                        At work with a two monitors set-up, I tended to have my main one in front of me flat and the other angled on the left. Not being in the centre of the desk allowed me to have a notebook and pen on the left of the mouse that I can reach for quick notes and having a space not in front of the main screen for thinking with reasonable space to use the notebook.

                      3. 1

                        Could not agree more with this! Many of my colleagues think I’m crazy for sticking to one monitor but I find it not only saves my kneck but also helps keep focus.

                      1. 1

                        I’ve been using a Das Keyboard Ultimate for years now which has blank keycaps. But I could touch type long before I bought it, it has still improved my typing on all keyboards (even those with lettering) - perhaps it’s forced me never to look down even when making a mistake or similar. I think the mechanical nature of the keyboard is the real winner though - I’m significantly more accurate on it than other, non-mechanical, keyboards.

                        1. 2

                          Bizzarely my mobile provider (Three) blocks access to this domain. Works fine via WiFi!

                          1. 1

                            That’s really strange. I’ve been using it for several years via gandi.net. Do you have any guesses why?

                            1. 1

                              Unfortunately no idea; going direct to the IP works fine so a real mystery. Sadly there’s no mechanism to discuss this with them either, only thing I can think of is an accidental content block :/

                              1. 1

                                I suppose I asked for this treatment by describing myself as a “hacker”. :v(

                              2. 1

                                I’m on Three (UK) and can access your website fine

                            1. 2

                              Family BBQ Saturday, probably avoid much screen time this weekend :) Will probably crack on with some pyinfra v1.1 work on Sunday evening!

                              1. 3

                                I implemented and have been using Kubernetes at work since 1.8. First installed from scratch(!) with no auth/etc (all within private network). We’re now using Rancher to handle provisioning for us which comes with all the bells and whistles built-in. We run/manage ~6 clusters currently. Lessons learnt:

                                • Build a toy cluster from scratch using vagrant or similar as a learning experience. It has allowed me to really understand the “low level” components of K8s. At its core, it’s really not that complex (or, at least, it wasn’t in 1.8!).
                                • YAML is ok for simple configuration but completely useless for anything more complext. Expect to bring workarounds or other horrible hacks (helm chart syntax).
                                • The ability to bring up rapid staging environments really is amazing and has been a huge win for us. Moving this to prod takes seconds too as the docker images already exist.
                                1. 3

                                  Half way through but released pyinfra v1 at last!

                                  And now spending the rest of the weekend out of code, walk the dog and chill out :)

                                  1. 3

                                    Dev stuff:

                                    • finishing up a minor redesign of Kanmail
                                    • hope to fix a few open issues and release pyinfra 0.15.1

                                    Life stuff

                                    • planning a trip to France now that borders are opening up
                                    • attempting to re seed some of the lawn
                                    1. 2
                                      • Solid terminal + editor with appropriate customization for language and individual. This is well worth investing time in, anyone that I know who has done so has reaped huge benefit for weeks/months/years after.
                                      • Docker (or other containers) based development, with a well defined and low/0-effort path to production. At work we’ve built an in-house tool (kubetools) to enable local dev via docker-compose with one command pushes to K8s clusters. Any process/flow like this is ideal IMO.

                                      Ultimately there are just some things that only a production environment needs that. Someone has to handle this - be it the programmer of the features or a dedicated operations team. I suppose (never used) services like Heruko and Elasticbeanstalk abstract these elements away, which is cool.

                                      1. 7

                                        Docker absolutely does not belong in your edit/build/test loop. It’s a tool for integration testing, not your laptop (or prod, for that matter). If this seems unrealistic to you, in my opinion, you haven’t balkanized your architecture in an appropriate way for delivering business value, and that deserves fixing.

                                        1. 3

                                          Curious, but why do you say not in production?

                                          1. 3

                                            I spent enough time in the sausage factory to become a vegetarian, so to speak. I was in the core Docker ecosystem for several years at the outset, and the code quality I observed convinced me that it has no place running important workloads.

                                          2. 1

                                            It’s a tool for integration testing, not your laptop (or prod, for that matter)

                                            Assuming your objection is to “on laptop integration testing,” I get the idealism here. But, we live in the real world where pushing to a “proper integration testing environment” takes a lot of time, and removes us from the flow of development. Having the ability to do some local integration testing, on my laptop, is pretty huge. It allows me to test that my assumptions in regards to an API / protocol / etc aren’t completely misguided, long before I submit it for a full test run in a more realistic setup.

                                            (Note: I am not a docker apologist.)

                                            1. 2

                                              we live in the real world where pushing to a “proper integration testing environment” takes a lot of time, and removes us from the flow of development. Having the ability to do some local integration testing, on my laptop, is pretty huge

                                              I guess I don’t agree that integration testing with real dependencies should be part of your development cycle, because I believe (quite strongly) that creating business value at the service level with mock dependencies should be an explicit and enforced design goal of any architecture. Said another way, if you need to integration test to be confident in your changes, you’re too tightly coupled.

                                              1. 1

                                                Said another way, if you need to integration test to be confident in your changes, you’re too tightly coupled.

                                                Something, somewhere has to actually touch the database.

                                                1. 1

                                                  Sure, but I don’t need a real DB when I’m developing. In fact I explicitly don’t want a real DB when I’m developing.

                                                  Of course I’m speaking from a specific context: business applications where DB access can be easily modeled with a simple contract, and not services that put a lot of logic at the DB layer.

                                                  1. 1

                                                    not services that put a lot of logic at the DB layer.

                                                    I know of few “business applications” that don’t use the whole power of the database. but if you are just talking “Bob’s rails app,” fine. That’s a pretty generous generalization though.

                                                    1. 1

                                                      I know of few “business applications” that don’t use the whole power of the database

                                                      Almost all business applications I’m exposed to have simple CRUD-ish contracts with their persistence layer. Not much logic there. But I’m sure we work in different contexts.

                                            2. 1

                                              I’ll bite, I am curious as I am working on a re-write of an open source platform for sharing electronics projects. I am re-using the Gitea open source git hosting software (a self-hostable Github clone) as a back-end. I have everything dockerized and use docker-compose so that any dev that wants to help out can spin up the whole application. I currently also deploy it to staging.kitspace.org using the same setup (with some production overrides in a docker-compose.production.yml). How would you suggest I balkanize this architecture correctly and stop using docker during dev?

                                          1. 3
                                            • Deploying a new ES cluster and moving a bunch of data on it
                                            • Improved onboarding for Kanmail
                                            • Finish up and publish my new tiny wiki engine
                                            1. 4

                                              Email definitely has issues, but it + IRC over Slack/etc any day.

                                              1. 12

                                                Fully agree. The convenience and efficiency of email is unmatched. I hate having to use Slack for work. The UI is so sluggish, I get pinged for the silliest of things (because they can!). Email makes people more thoughtful while communicating. You can’t delete a sent mail. And more importantly, email won’t go away. What’s to say Slack won’t “thank you for the incredible journey” when their VC funding stops?

                                                1. 5

                                                  Also agree and hate slack for work - have you tried Ripcord? I switched from the official client and it’s far quicker/calmer! Still won’t fix the expectation slack gives to colleagues sadly…

                                                  1. 5

                                                    Ripcord won’t build on OpsnBSD, sadly. I’ve spoken to the dev about it. For now, I use wee-slack, which sucks less.

                                                  2. 4

                                                    What’s to say Slack won’t “thank you for the incredible journey” when their VC funding stops?

                                                    I hope that is the case. Fortunately, my time using Slack was brief. When you give the users to option to ping people with ease they will, however, due to the nature of email (and email lists) they are normally more precise as they are only done when necessary.

                                                  1. 3

                                                    I installed Ubuntu 18 (now dist-upgrade’d to 20) on my old 12” Macbook for testing/developing Linux desktop apps. Worked a charm out of the box except suspend/resume blank screen. I’m extremely impressed with how far Ubuntu has come along, especially 20 (ignoring the whole Snap debacle), it definitely runs quicker than MacOS ever did on the machine!

                                                    1. 5

                                                      Fiddling with a Wiki engine I stupidly decided to throw together yesterday. And painting our front door!

                                                      1. 2

                                                        I wonder how much the lightweight and simplicity claims will hold if/when this grows to the number of functionalities and thoroughness of ansible.

                                                        1. 3

                                                          I don’t think it ever will, certainly not under my watch! Been using it for years now and the module coverage has barely changed. Because it’s Just Python almost anything else can be achieved without changing pyinfra itself :)

                                                        1. 2

                                                          I recall setting up MediaWiki years ago and loving it! Really like the idea of a personal Wiki fro this kind of thing - currently using SimpleNote but it’s pretty limiting, maybe I’ll give MediaWiki a go.

                                                          1. 2

                                                            At the beginning, I wasn’t all that impressed or optimistic about MediaWiki simply because of how dated it looks. After exploring more and seeing what it’s actually capable of, I don’t know how I ever lived without it ;) All of what I’m documenting is for NixNet and MediaWiki is perfect but I’ve also started trying to maintain a Zettelkasten as more of a personal knowledge base. It’s only been a few weeks and I haven’t had much to write outside of documentation but it seems like it’ll work pretty well.

                                                          1. 3

                                                            That looks lovely! I’m a big hater of yaml-based configuration and reinventing the wheel, when things like that can be done in a proper programming language. I don’t have to manage many servers, but I like the idea of having reproducible state of the system. Like NixOs, but NixOs/Nix seems like a lot of work, whereas I’m 99% happy with simply using apt, pip and few ad-hoc commands.

                                                            I was about to cleanup my current setup scripts (done with a bunch of scripts + Ansible), so I think I’ll give this tool a try. Do you think it makes sense for my usecase (personal desktop/laptop)? Are you using it for that purpose?

                                                            1. 4

                                                              I do think it makes sense - I do exactly the same :) So far I’ve used pyinfra for both ad-hoc/local box setup and also in production managing medium size (100’s of nodes) Elasticsearch clusters, amongst other things. An example is my (very WIP) MacBootstrap deploy: https://github.com/Fizzadar/MacBootstrap.

                                                            1. 2

                                                              What i find funny about these configuration management systems is how they tout agentlessness as a feature. It seems by it’s very nature (push vs pull) a system based on this model can never be useful beyond a toy application. Homelab, personal projects, etc. In which case, i have to agree with other posters, there would need to be a compelling reason to not just use idempotent shell scripts. I’ve felt the same way about Ansible. The whole point of these things are the abstraction (“over abstraction?”) for the sake of not having to write anything to keep something idempotent.

                                                              Since i know Chef and am familiar with it’s model (and problems), Chef or Puppet seems to make a lot more sense to me. Some equivalent in python (or even Go, which might be a bit ambitious) would be much more interesting to see (but also quite the undertaking).

                                                              1. 3

                                                                I agree with this in some ways! I have used both Ansible and pyinfra extensively in medium scale production environments without issue (100’s of targets). As the number of targets grows this becomes more of an issue (particularly for Ansible due to it’s threading model).

                                                                I see good arguments on both sides of the push vs. pull thing - anything with >thousands of targets I wouldn’t even entertain push solutions due to the inevitable bottleneck. But, for anything smaller I’d be content with either methods - I believe both can provide the same kind of consistency guarantees as long as they are applied appropriately.

                                                                A pull based system in Python would indeed be a very interesting project…!

                                                                1. 3

                                                                  i think anyone contemplating such an undertaking would do well to read Mark Burgess’ Promise theory (http://markburgess.org/promises.html), there’s a wiki on it too (https://en.wikipedia.org/wiki/Promise_theory). This is the kind of physics that went into cfengine.

                                                                  1. 1

                                                                    I have used cfengine for single servers (in other words overengineered for learning purposes). I tried to understand the point of Promise Theory but I don’t get it.

                                                                    The advantage of cfengine for me is its a small tool with nearly no dependencies. The Python interpreter alone is big in comparison.

                                                                2. 3

                                                                  It seems by it’s very nature (push vs pull) a system based on this model can never be useful beyond a toy application.

                                                                  Well that’s just completely false. I don’t even understand why you could think that.

                                                                  Since i know Chef and am familiar with it’s model (and problems), Chef or Puppet seems to make a lot more sense to me.

                                                                  Oh, right, ok. Perhaps it’s just that?

                                                                  1. 2

                                                                    to be sure, i didn’t mean to minimize your work here, i already think Ansible is overly complicated yet still somehow limiting in some ways (!?), so i would venture to say this seems to have a better core design

                                                                    anything could be done in Ansible, but really, should it?

                                                                    1. 2

                                                                      just use idempotent shell scripts

                                                                      Writing idempotent shell scripts is not easy. Just helping with this alone is valuable.

                                                                      Unfortunately, most config management tools do not solve the problem either. My canonical example: Install two packages which conflict with each other, so when you install the second one, it uninstalls the first (and vice versa). Puppet, Ansible, etc all fail. Success would be to show an error in your configuration.

                                                                      1. 1

                                                                        Puppet, Ansible, etc all fail. Success would be to show an error in your configuration.

                                                                        depending on how you test your Chef code, while i wouldn’t see Chef throwing an error in such a scenario, you could certainly have a test harness throw an error if there were changed resources (in this case your package install) on the 2nd convergence (in fact i’ve done this in a pipeline)… at that point then, Chef provides a couple mechanisms to deal with that situation…. but to your point, none are automatic

                                                                        1. 1

                                                                          I never administrated a large number of server but apparently it is not a big deal in practice. In Debian/Ubuntu there are practically no conflicting packages. The mechanism is only used for certain rare transitions where obsolete packages should be deleted. Debian fixes a lot of conflicts by providing management on top with update-alternatives.

                                                                          Well, maybe it is a big deal but everybody assumes it cannot be improved. Package managers like apt/rpm are by their nature somewhat in competition with configuration managers.

                                                                          For my homeserver, I restricted myself to a single installation command. Then apt complains about the conflict. Configuration managers don’t do this for ordering or modularity purposes, I think. What my own system does not capture is a configuration-internal conflict where I install and remove a package at the same time. My config is small enough though.

                                                                    1. 4

                                                                      I gave this a go and I really like it. It is pretty much straightforward and I prefer having this type of configuration in Python and not YAML.

                                                                      As far as I can see it doesn’t read the ~/.ssh/config file?

                                                                      1. 3

                                                                        It should read standard SSH config (https://github.com/Fizzadar/pyinfra/tree/master/pyinfra/api/connectors/sshuserclient)! If it’s not working please submit an issue!

                                                                      1. 8

                                                                        If I understand it correctly, I like the idea. As far as I understand your focus is to provide a lightweight system written in Python and then for most use cases the deploy steps will just be written in standard shell commands with your shell function? I have always wondered whether a simple bash-script based idempotent deploy might be better for simple use cases than Ansible (background: I have written many ansible roles for my hobby deployments and it has cost me a lot of debugging and time)

                                                                        Can you maybe elaborate a bit on:

                                                                        • Why a Python surrounding is needed, i.e. what advantages it gives you?
                                                                        • Why you needed to implement some functions like file or package as Python helpers instead of shell, because at first sight it seems to break the logic to use shell, but I guess there is some reason behind (package is one of the aspects I am a bit skeptical why it is abstracted, because they also do this in ansible, but many times packages have different names between Debian-based distributions and e.g. Archlinux anyway)

                                                                        I might prefer it even a bit simpler/more reduced. When adopting new technology I came to love it when they support a scheme that I can continue working even if the technology dies. In this case this could e.g. work if you allow the user to write standard shell files (my-nginx-deploy.sh) and load these into pyinfra. If pyinfra might not exist anymore some day, the user could still execute the shell scripts manually.

                                                                        1. 3

                                                                          The most simple approach would be:

                                                                          ssh my.server.com <setup.sh
                                                                          

                                                                          My question would be: Against this baseline, what problems does pyinfra solve?

                                                                          For example, Ansible can work on multiple servers in parallel. It provides idempotent commands which you have to ensure yourself in shell. It skips commands already executed in previous runs.

                                                                          1. 5

                                                                            So pyinfra is built out of my personal frustrations with Ansible! pyinfra operations are idempotent similar to Ansible and it will skip commands just the same. The key differences:

                                                                            • The deploy is executed in two phases, making it possible to do a “dry run”, this identifies where pyinfra can skip commands
                                                                            • Instant debugging - I grew sick of debugging anything with Ansible, pyinfra just drops the output and the shell command itself
                                                                            • Performance - not important but a small obsession of mine! pyinfra is significantly faster than ansible over large numbers of hosts
                                                                            • Properly agentless - pyinfra does not require the target server to have anything other than a shell (vs Python + requirements for Ansible)
                                                                          2. 3

                                                                            So the idea is to roughly match some of Ansible’s abstractions - ie apt.packages(...) instead of executing the shelll directly. The advantage to this approach is pyinfra will only execute the underlying apt command if the package is not installed (by default). In this way pyinfra is very similar to Ansible.

                                                                            This is the same for most other pyinfra modules, eg files.file, etc, which will check the current remote state before executing commands to update anything as needed. I have tried to remain true to each underlying tool, so there’s a dedicated pacman module, and so on.

                                                                            Totally with you on the debugging thing! One of the reasons I started pyinfra was frustration debugging things with Ansible! pyinfra should always give the output and underlying commands that failed, making failures easily replicatable in a shell.

                                                                            I think that answers your questions? Let me know if not/you’ve more :)

                                                                            1. 1

                                                                              There is at least one config management thing that uses bash: cdist. After looking at the examples/docs, the syntax doesn’t seem simple. I’ve never used it, so it could make sense after you spend enough time on the long learning curve for it.

                                                                              1. 8

                                                                                Each time I read about cdist I remember this:

                                                                                Shell script is used by UNIX system engineers for decades. So when cdist is introduced, your staff does not need to learn a new DSL or programming language.

                                                                                Which implies that « staff » knows how to write correct bash scripts… which, to be very honest, isn’t an easy task.

                                                                                1. 3

                                                                                  I’ve been writing bash for 10 years and I think I’m halfway there. Hard to say for certain…

                                                                                  1. 2

                                                                                    I ran into a weird failure, recently, where bash redirection of files to stdin ( cmd < path) would result in no stdin input to the receiving command, but only when run under go generate, and only on one colleague’s machine.

                                                                                    I rewrote the script in golang. That’s the kind of BS I expect from JavaScript; I thought bash was better than that.

                                                                              1. 1

                                                                                Did not know there were beta versions! Just switched back to K-9 beta from FairMail, great so far (FairEmail is clunky).