From Mac to Linux: Web Development with Linux
medium.com
medium.com
It allows me to easily and conveniently manage dozens of windows, and it's hard to describe how convenient that is until you get used to it.
I usually have around 10 workspaces open:
1. Emacs with personal notes, goals, todo lists.
2. Emacs windows I use for development and code.
3. Terminals for all sorts of servers and processes running in the bg. Django, compass, webpack, stuff like that.
4. Terminal for "practical" tasks - updating git, ssh, all sorts of commands I want to use.
5. Nautilus.
8. Video player with tutorials and courses I'm watching.
9. Photoshop and other graphical/visual stuff.
10. Chrome.
I can switch to any of those with one hotkey, and navigation is super easy and convenient. It is so awesome that I'm thinking that it's almost the main reason I'm not going back to mac.
Oh, and also Ubuntu 16 is fucking great. Everything works pretty much out of the box, everything is easy to install, just perfect.
The only drawback of linux is editing graphics and videos. At the moment I'm using Photoshop with wine for design and kdenlive for video editing. They are good enough to work, but do have bugs and inconveniences, not as great as you would want.
I feel like a luddite though because I use and love linux, but have never taken the time to learn and use the workspaces feature. It would probably be cheaper to learn it than to keep throwing monitors at my space issues :P
At work I use OS X and compared to my setup at home, it's passable at best.
The whole windowing system (layers upon layers upon layers), Finder, iTunes, spinning beach balls, etc. is just not in any way appealing from the Linux side of the fence. Sure, "It Just Works"; same with Windows, you get a lot of functionality out of the box, but you can't choose, it's the kitchen sink or nothing.
Choose nothing ;-)
Although, It'd be awesome if someone did an iOS port of Vim — I've always thought a modal interface like Vim's would be perfect for a tablet + keyboard combination.
The killer feature for KDE is the "konsole" (KDE terminal) integration in their GUI tools. Their file manager (Dolphin) and text editors (Kwrite and Kate) have a CLI built in so I can leverage the best of both paradigms from a single interface. Couple that with Krunner (I know every DE and OS has a runner these days) and Yakuake (a Quake-style drop down terminal) and KDE is actually a surprisingly productive desktop environment even for people who are command line orientated or running on platforms with limited screen real estate (eg laptop screen).
But as much as we might intellectualise the productivity of different desktop environments and window managers, our personal preferences often just boil down to old habits. I've been using KDE since version 1 so when migrating to a tiling WM I was as much frustrated by having to rewrite muscle memory as I was by any personal preference with the UI design.
It required a couple special rules in the bspwm config but it worked just fine.
By default, it's impossible to use workspaces without frequent switches to the trackpad, which wouldn't be so bad, but without installing third party software it's not really possible to create shortcuts or start remapping keys either. Even once you've installed and started Kwm, Karabiner and Seil, the botched keyboard layout renders the Alt key useless for wm shortcuts. There's not even a keyboard shortcut that makes a window fullscreen without removing it from its workspace!
So much of the system lives in this unconfigurable space. As a Linux user, if my window manager isn't working for me, then I just install another one and start again with a fresh _and customizable_ blank slate.
Ironically the things that don't frustrate me about the chance from Linux to Mac are the things the author identified in the article. My editor works just the same in both OSes and Homebrew could be a lot worse.
And I get it, the OSX experience is a system that is averaged out to be comfortable and intuitive for everyone from musicians to graphic designers to programmers and business people. As a result, the user experience punishes power users the most.
If you primarily identify as a programmer and use a Mac on a day-to-day basis, go pick up a cheap Chromebook, throw a linux distro on it, and see how it feels. If it's not quite right, tweak it. If you get it working, great - you've just saved yourself ~$1000 and a vendor lock-in. If not, all you've lost is $150 and a few hours of your life.
GalliumOS has good-to-very-good support for almost all Intel Chromebooks, but does not support any ARM models yet.
GalliumOS works very well on the 2015 Pixels. It was a lot of work to get there.
And as with all Linux laptops throughout history, you should definitely check the hardware compatibility list first.
A decent chunk of chromebooks have upgradable ssds. I put a 256 in mine. The big bottleneck is unfortunately non-ugradable ram, though this is increasingly a laptop in general gripe.
Unfortunately the author delves into text editors, which can be flame inducing.
The argument "dev env == production env" is overrated IMO, because you typically want more conservative/controlled production environment anyway and/or you may prefer different distro for workstation use. For serious use you anyway need proper test environment etc.
Editors are editors. (Vim being slower on Mac is hard to buy, unless the author refers to some non-commandline variant.)
Debian has a policy of shipping a sane default config, and generally enables/launches services for you. This is friggin awesome when you're experimenting and learning. apt-get install nginx, and bam, running webserver.
Unfortunately you then start automating processes, and it becomes quite painful. Wanna build a MySQL host with a non-default size innodb log? You get to install the package, stop the service, reconfigure mysql, blow away the log files created when the service was started by dpkg, then start the service back up. Compare this with RHEL/CentOS/Arch: Install package, configure service, start service. These are 3 discrete operations.
(Yes, there are workarounds for this, such as using policy-rc.d, but they bring their own complexity to the table.)
Additionally I've recently started using elasticsearch docker containers and I found Linux is a far better host than Docker for Mac (as it still runs a tiny Linux vm with associated slower disk access).
And this is why MS has gotten all buddy buddy with Canonical.
Gimp is no replacement for Photoshop and Inkscape is not replacement for Illustrator, ...
Btw, mostly everything you install with `apt-get` can be installed with `brew` as well (MongoDB, Elastic, nvm, etc.).
Nor is Photoshop a replacement for the Gimp, or Illustrator a replacement for Inkscape. They are not cheap clones forever playing catchup to the commercial packages, but mature tools in their own right. Sure, the FOSS tools might miss some of the advanced features the proprietary tools have, but for web development both of them offer plenty of features — and they are free to boot!
Whether or not one can replace the other is mostly a matter of what you are used to. No alternative is going to satisfy you if you've intensively used Photoshop for a decade.
A much better example would be the native clients for GitHub or tools like those. I use the web ones and I'm happy with them.
I thought .psd mockups and HTML slicing were a thing of the past, and vector work (logos, etc) should be done by a graphic designer. Not to mention most icon/graphic assets can be provided by Bootstrap or FontAwesome.
No vector logos yet, but if they give me a .svg I can view it directly into the browser.
It was only:
1. Apt-get is cool 2. Vim 3. Sublime 4. Atom?
I felt a little more effort could have been put into this post (similar to a tutorial?)
Unfortunately, I work in a place where we need access to Outlook (and its calendar), and Skype for Business / Lync. There is not really a good story for these things on Linux still (and I doubt we will ever see a Skype for Business for Linux), and even with Thunderbird + Exquilla, email is tough.
That said, my laptop mounts my workstations home dir, and then I use iTerm's fantastic tmux integration to connect to the shell.
(My personal PC at home is still Linux though :) )
Skype for Business has no web interface :( . I tried windows VMs, dialing in, mobile apps, 3rd party apps - but nothing was reliable / usable enough for daily use.
Try out a pacman-based distribution some time. The idea of a rolling distro is great in my mind and most of the packages in the repo are up to date. If something is missing there is usually an AUR.
If you use zsh with oh-my-zsh then you're going to have a much easier time finding whatever you need to install. Pacman has an autocomplete written up for it.
Also, everything is near-perfectly documented in the arch wiki.
If you want APT based distro + rolling update, Debian testing is what you need.
(Obviously if you're satisfied with Arch, there is no need to change.)
You also don't have an AUR for Debian and there are many things that just aren't in the repos. Teamspeak 3, for example, is completely absent.
Arch with it's rolling release setup works, in my experience, because I know my system - all except the most core of the core components I'm never going to touch were installed by me and I know they are there and how I configured them, because I did it manually. No magic. When something goes wrong, I know why, and where to look to fix it. Rolling release adds a small amount of instability (although far less than you'd think), and I imagine that combined with the 'magic' in a more pre-built distro would be really annoying.
1. GUI git client (yes, i know how to use a terminal, but at times, you just wanna get work done and not google a command - I used to use sourcetree, and now Tower but there's nothing great on linux. The best I could find is Smartgit which is ok at best - but not on par with the others I have mentioned).
2. UI development - Sketch/XD etc.
3. Adobe Suite
I want to add games to that list, but we have recently got Rocket League so that and along with various valve games and Minecraft seems to be enough for casual gaming right now.
All what the articles says I do achieve simply by using docker and I have all the nice integrations around. I can have any target environment setup and switch between them in seconds. And since I can mount my code directories directly into the docker containers I don't need to do any complicated scp like deployments.
Well, but in the end it's a matter of personal taste. I am happy where I am :-)
... Which is not the only valid approach, of course, but it is compelling to many.
... And the counterargument is that having homogeneous dev and deploy environments has great value. And I agree, but I deploy on FreeBSD, Solaris, and Linux; self-hosted, AWS, and colocated. So I have lots of RAM, virtual machines, staging environments, and a strong preference for low levels of dogma.
I made similar switch from Linux workstation to Mac workstation about 10 years ago. The biggest challenge with Linux workstation were hardware related issues: accelerated graphics / suspend-to-disk / battery life, etc. Too much endless tweaking. Mac offered "ready-to-use" solution with familiar unix tools & DE with virtual desktops.
I guess the driver situation is now somewhat better but I'm now too accustomed to Macs & Apple ecosystem. No other laptop manufacturer can really compete with Apple in objective quality. No Linux DE feels "smooth" or polished enough after using macOS for long time, at least for me.
In the end, almost all open source / "unix-like" software runs fine on Mac. Still it's difficult decision between supporting "the ideogically right choice" and enjoying admirable industrial design.
1b) desktop apps availability/quality
2) drivers and support
3) With mac, I open my laptop and I can use it like a toaster, without thinking how to fix this or that issue after a software update
bonus) iphone/appletv/ipad smooth integration
PS (especially for downvoters): I've used linux since 1999, I have a sysadmin background, I used to build my desktop/servers from scratch or by using gentoo (that is almost the same), I wrote kernel modules. So I'm not afraid to tinker with a linux system down to the kernel details. Again I switched to macOS because I was tired of all those little issues that made my daily work a crappy experience (eg: why my Bluetooth device doesn't work today?)
Homebrew felt really clunky (broken/missing/out of date packages, manual intervention needed, etc...) and so dev tools were a pain. The OS X experience also didn't offer me room to change things to suit my needs, and the OS X apps all felt really lacking. I didn't find a file manager that could touch Dolphin, for example.
I also found that any decent OS X tool was going to cost me £20, mostly for really small applications that did specific things, so I'd want tons of them. By contrast, I never had to search hard for the Linux tooling, and it was always FOSS.
More specifically when comparing to Arch Linux, OS X suffered from the same magic problem as Ubuntu, Windows and anything else where the system is set up for you. The back end was all magic, so when something went wrong, I had no idea why or where to fix it. When you use it like a toaster, it's also pretty impenetrable. (Fine when your problem is common, less so when it isn't).
It's probably a difference between how we use our devices (I never needed to try and use bluetooth, for example).
OS X is still, after three years, the only OS that does multi-monitor with different densities well though, I'll give it that. Hoping that will get sorted soon in my Linux environment.
Better say that environment will be the same, I guess.
That being said - as an ex-Linux user (for about 10 years) I see now real reason for this kind of switch. You can have the same (or almost the same) env on you macOS.
Kernel - obviously, as I said earlier. As for packages and libs - Brew + something like pip\rvm\whatever will most likely solve this for you. You won't have the same lib, because it was build for a different env, but the way it works should stay the same. If not - I'd rather consider using different lib.
This + docker(or something similar) as someone already mentioned.
Also, unless IT agrees to put beefy machines under each one's desk, the server is quite different from what developers can use anyway.
Finally if there is any issue that really needs testing on the server, that is what remote connections (including remote debugging) are for.
[0] We usually develop on Windows and deploy on UNIX.
Running the same libraries, on the same base OS is invaluable to me - but that can depend on what you are developing.
> Also, unless IT agrees to put beefy machines under each one's desk, the server is quite different from what developers can use anyway.
With "the cloud", these days that is not necessarily true. a t2.large / m2.large are 2 cores, 8GB RAM. - well within the reach of a basic laptop.
> Finally if there is any issue that really needs testing on the server, that is what remote connections (including remote debugging) are for.
Never debug in production. No developer should have access to production.
Which is why we just connect to "cloud" and clone our own instance from a production server, if we really need to.
> Never debug in production. No developer should have access to production.
Maybe in a perfect world.
On real life I have been in projects where developers were exchanging dlls and jar files on them.
All of these issues tie together.
Developers can't access production, so they start using production like environments, which allows for proper Ops work (Infrastructure as code - e.g. config management), which allows for easier setup of production like environments for developers ... and continue cycle.
Its hard to move to that, and takes time, but it really helps. I know it can seem overkill, especially for small teams, but the tech debt paydown that happens when you end up doing it in the future can be huge, and massively disruptive.
Our main hardware guy would have liked to make sure all the DASD (Disks) where from the same production run as well.
Yeah, right.
>not being bound to Apple hardware.
Not an issue for years already, unless we are talking about some very specific hardware.
PS: not trying to advocate for either of systems, worked on both linux (ubuntu, arch, centos) and macOS. Both have their share of pros and cons.
A Hackintosh is a breach of the EULA, and no company should allow one to be used for their development, as it can create a potentially massive liability for them.
Having said this, I also don't agree with using Hackintoshs.
Having to press `fn` key in addition to backspace key is not a big deal at all, and I like more `fn` in combination with cursor keys than separate PgUp/PgDn/Home/End keys.
>Yeah, right.
Minimal Arch Linux with a minimal desktop and rolling updates.
> >not being bound to Apple hardware.
>Not an issue for years already, unless we are talking about some very specific hardware.
It is an issue, if you have a budget and you want a fast computer for compiling and so on. Right now I'm having a modern 4GHz i7 with 32 gigabytes of ram, a m.2 SSD and two monitors where the other is a 30" IPS. Having the fastest computer in the office is pretty nice, with a price of a macbook and monitor.
>Minimal Arch Linux with a minimal desktop and rolling updates.
I switched to Arch after Ubuntu 10.04 (or 10.10, I don't really remember when they brought Unity up). And yes - it's much better in this regard, but you still see an update on their main page from time to time that will tell you this and that about some big changes and instructions to handle this. OSX\macOS didn't have anything like that in years now.
* There are substantial subtle differences between Mac and Linux that will eventually trip you up when leaping the divide between development and deployment.
* The Mac often has ridiculously old versions of tools because of its GPL allergy.
But hey, Macs are shiny and popular.
I will say their screens are a step above 90% of other laptops, not that it makes a huge difference when you are reading text.
> Package management isn't a train-wreck (I always have
> troubles with brew
> The Mac often has ridiculously old versions of tools
> because of its GPL allergy.
I would actually love to ditch macOS - I used Arch on my MBA for some time, but in the end it was better drivers and brew that brought me back. I seriously miss i3wm though.
Brew is the best package manager I've ever used - so simple to add your own or edit existing formulae if what you want isn't available.
* Conflicts with other software installed causing all sorts of weirdness.
* Numerous packages not in the main repo that weirdly have to be installed by some other mechanism (pip, cask, etc.).
* Dependency on XCode. There's like a 5 step installation process to get it up and running!
* brew install rsync -> rsync [xyz] -> why isn't this working? -> oh wait, the version of rsync on the PATH is still the ancient system one for some reason.
* whatever brew doctor does. the fact that command even exists is a big red flag to me.
^^ This is just the stuff I've run into recently when I've had to debug stuff that was working just fine on linux but somehow broke on a somebody's mac.
> Conflicts with other software installed causing all
> sorts of weirdness.
> Numerous packages not in the main repo that weirdly have
> to be installed by some other mechanism (pip, cask,
> etc.)
> Dependency on XCode. There's like a 5 step installation
> process to get it up and running!
I think the only way around this would be for brew to ship a compiled binary, and then mandate that you install either XCode Command-Line Tools, or gcc. (Some formulae will need to compile.)
> brew install rsync -> rsync [xyz] -> why isn't this
> working? -> oh wait, the version of rsync on the PATH is
> still the ancient system one for some reason.
> whatever brew doctor does. the fact that command even
> exists is a big red flag to me.
> Please note that these warnings are just used to help
> the Homebrew maintainers with debugging if you file an
> issue. If everything you use Homebrew for is working
> fine: please don't worry and just ignore them. Thanks!* This is basically just a cross section of problems I came across helping other people who used a Mac over the period of a few days. I can only imagine how bad it is using it day to day.
* Everybody just accepted that these types of problems happened with a shrug. Except me because I've gotten used to them not existing (I almost never get PATH related issues on ubuntu).
* They may all have a solution but they shouldn't exist in the first place.
* They may not even be brew's fault per se, but it's still all part of the pain you have to deal with when using a mac which makes me want to toss it out the window.
[0] http://apple.stackexchange.com/questions/69223/how-to-replac...
I am considering the purchase of a Surface Pro 3 i7 w/ 512GB for Linux web-dev.
Follow these steps and you should have at least moderate success. Check out Manjaro, it's an easier to use arch-based distro.
Also, given the prevalence of various types of virtualisation - is this still overly relevant to the developer? (Genuine question, keen to understand how people work)
I'm writing this now on a mac running vms for ubuntu (14/16.04) as well as OpenBSD. I don't necessarily feel like it's a blocker but understand we all work differently.