Linux has higher share than MacOS among software developers : linux

[–] onlinepersona@programming.dev 27 points 1 year ago (2 children)

Not a surprise for those with containerised workloads. Mac is a nightmare for that. Every single dev team with mac that I've been on has struggled with it. Heard all these things and more:

We can't use Docker Desktop due to licensing!
podman doesn't work, but colima does
npm install takes forever!
Why can't it find the docker socket?
This only works on x86
The port-forwarding didn't work
XYZ works in the dev-container but not when deployed

Recreating a problem you encountered with your container in a x86 linux VM in the cloud on a mac with apple silicon is no fun either.

And good luck with custom hardware on a mac. Working from home with stuff that was plug and play on linux simply refused to work on mac. Ergonomic mice, keyboards, USB-C docks, high-quality webcams, USB headsets... Either you're in the Apple ecosystem or you're gonna have a bad time.

If an employer doesn't allow me to install linux on my dev machine, then I move on.

[–] prettybunnys@sh.itjust.works 12 points 1 year ago* (last edited 1 year ago) (2 children)

That’s kinda weird, I develop on a M2 Mac and use docker all day, I haven’t tried podman on my m2 but I used it on my previous i7 MBP without any issue for a project I was on.

I use my own mouse and keyboard and the same monitor setup I use for my personal computer.

This just doesn’t track at all.

mind you I literally have tux tattooed on my body

[–] some_guy@lemmy.sdf.org 7 points 1 year ago (1 children)

This just doesn’t track at all.

Agreed. The bit about peripherals, in particular, seems strange. I've never had a problem with a fucking keyboard or mouse. None of the rest, either, but seriously, keyboard or mouse? Suggesting that they don't work makes the whole post sound like an exaggeration.

[–] onlinepersona@programming.dev 0 points 1 year ago

Do you use a mouse with more than 3 buttons? Do you use a split keyboard?

[–] domi@lemmy.secnd.me 4 points 1 year ago (1 children)

I'm not a Mac guy so I can't comment on the hardware side of things but I can comment on the Docker side of things.

Docker runs in a VM on Mac, and in a VM or WSL on Windows. On Windows the experience is awful, doesn't matter if its WSL or VM. On Mac the experience is okish but there are enough differences that it makes Docker less effective as a platform.

The whole selling point of Docker is reproducibility, on Mac and Windows there are issues that do not occur on the platform that all the servers we deploy to run. I constantly have to help my coworkers with issues on Mac and Windows that simply do not exist on native Docker on Linux. It has gotten so bad that I simply refuse any help for anyone running Docker on Windows. I try my best on Mac but if I can't solve it quickly or reproduce it on a Linux machine I dismiss it.

The devil is in the detail, minor differences are enough to throw off a system that is made to be run in a container and expects identical environments between instances.

There's enough issues with Docker for Mac that they have separate tabs on the Docker known issues page: https://docs.docker.com/desktop/troubleshoot/known-issues/

There's also 426 open issues just for the Mac port of Docker: https://github.com/docker/for-mac/issues

[–] prettybunnys@sh.itjust.works 1 points 1 year ago (1 children)

Huh, I mean you’re saying a lot but still.

There are 200 open issues for docker compose, nearly 600 for docker cli.

The number of open issues means nothing without context.

Again, I’d love to hear about actual peculiarities you run into because as of yet in the last 5 years I’ve developed on a MBP (work provided, I previously “hated” Apple) I haven’t had these issues you’re claiming are all over.

[–] domi@lemmy.secnd.me 2 points 1 year ago (1 children)

The number of open issues means nothing without context.

The context is that the issues for docker compose and docker CLI are almost identical across Linux hosts and can be worked around, there are 426 additional issues just for Mac one has to watch out for.

Our main issues on Mac (that I can remember):

Severe slowdowns causing healthchecks to fail (Mostly caused by slow network requests and writing/reading thousands of smaller files)
Environment variables not being applied correctly to build containers
docker-compose file differences, e.g. newer versions not available or older versions deprecated earlier
Under high load the VM chokes even though there are plenty of resources available
I never was able to set permanent sysctl configs needed for some of our applications.
On ARM: Building some of our x86 containers is seriously slow and eats a lot of RAM
On ARM: Running x86 containers is much slower, sometimes hangs and sometimes even crashes the VM

[–] prettybunnys@sh.itjust.works -1 points 1 year ago (1 children)

You’ve said enough at this point for me to recognize it’s your bias speaking.

[–] onlinepersona@programming.dev 2 points 1 year ago (1 children)

Lol, as if yours isn't.

[–] prettybunnys@sh.itjust.works 0 points 1 year ago* (last edited 1 year ago) (1 children)

I have been a Linux admin for the better part of two decades now. I’m not saying that Mac is better, I’m just saying that in the real world I don’t run into any of those issues.

I didn’t purchase my Mac, it is work provided. My infrastructure is a mixture of x86 and arm but it’s all Linux.

I’ve ran into exactly 0 issues using the work issued Mac to interact with my infrastructure or develop containers or any of the supporting software for our operations.

I’ve used an intel MBP and an apple silicon MBP as well as developing on a handful of other platforms running other Linux platforms per contract requirements. There are peculiarities between any operating system but what they’re saying straight up isn’t true.

Issue numbers out of context is a stupid metric, their explanation for that metric is even dumber.

They legitimately said “peripheral issues” then when pressed backed off because “they’re not a Mac user”.

Then saying x86 containers run slower when on a different instruction set than native is somehow another indicator …

When I realized I wasn’t talking with someone who actually had real information I said what I said.

My bias is simply that repeating a narrative you’re not actually aware of is stupid. All of the things that person said aren’t actually the problem they say they are, so I certainly hope it is showing.

[–] domi@lemmy.secnd.me 1 points 1 year ago

They legitimately said “peripheral issues” then when pressed backed off because “they’re not a Mac user”.

OP and me are not the same person.

My first comment states I'm not a Mac user, some of my co-workers are.

[–] fogetaboutit@programming.dev 2 points 1 year ago (2 children)

I agree with everything but the "This only works on x86". I'm not saying that everything runs smoothly on arm, but I think it really is the future. Either that, or risc-v. I doubt riscv will garner a mainstream adoption anytime soon though, but one could only dream.

[–] Still@programming.dev 5 points 1 year ago

well yeah arm is definitely the future, but edge cases and undefined behavior make parity between the instruction sets a major pain

[–] mrkite@programming.dev 1 points 1 year ago

Gdb doesn't work at all on m1 macs

[–] LemmyIsFantastic@lemmy.world 26 points 1 year ago

Containers and slow file system access. I'm not sure if Apple has fixed it to this day.

[–] MrSpArkle@lemmy.ca 18 points 1 year ago

This is true, there’s been a marked increase in people at meetups unable to get their laptop working with the projector.

[–] JoMiran@lemmy.ml 15 points 1 year ago* (last edited 1 year ago)

I've seen a shift to Linux from Mac for a few years now, and definitely in my companies. I cannot speak for anyone else but my trigger was the "iOS-ification" of MacOS and the changes made to the hardware interface on MBPs. Once my Mac battery started to "football", I switched back to ThinkPads but this time running Linux as my daily driver. It's been great.

EDIT: I've been working with Linux since Red Hat Halloween, but I have never used it as my main everything computer until now.

[–] namingthingsiseasy@programming.dev 9 points 1 year ago

It would be interesting to see a breakdown by region on that statistic. I would say I work with about 80% Americans and 20% Europeans and Linux is definitely more popular amongst the Europeans. That said, a couple of my American colleagues have also switched from Macs to Linux, but not many people on my team use Jetbrains products (VS Code is more popular here). Overall, I would guess that Linux is more popular in Europe, South America, and Asia, while Apple is more popular in the US, but that's just a pretty rough speculation.

[–] canis_majoris@lemmy.ca 2 points 1 year ago

My dev env doesn't really change much over the OSes I use because I tend to stick with VSC which just works everywhere.

I've found that WSL covers more and more of my use cases when it comes to wanting to do something in Linux.

I have a ThinkPad with Fedora Silverblue on it but I'd never use it for work.

Most of the time I just stick to Windows because it covers everything I need it to and it works on every single device I own flawlessly. I'm still tinkering with this laptop, and since it's a T80s, there are no working drivers for the fingerprint sensor that I can find. Windows Hello just works, I don't have to worry about what I plugged in or what laptop I picked up.

[–] Mikina@programming.dev 1 points 1 year ago (3 children)

I would love to finally switch to Linux, but it's basically unusable for any kind of gamedev...

[–] swordsmanluke@programming.dev 18 points 1 year ago

I suppose that's gonna be engine dependent, but godot works fine. ...assuming your project is a fit for godot!

[–] Thrift3499@lemm.ee 10 points 1 year ago (1 children)

Ah how come? I've had to build simple stuff in unity for university, I've not run into issues.

[–] Mikina@programming.dev 1 points 11 months ago

I've tried switching to Fedora several times, but I never managed to get it to working conditions. Unity Hub was regularly crashing, I got a bazillion of errors related to unsupported type of media files we're using for ingame videos, and only during the time I was trying to troubleshoot the issue, Unity has crashed several times.

I suppose that if I was starting a new project, I would just go with Godot and on Linux, but a project that has been build for the last few years on Windows, and is planned to only be build for Windows for now, it adds unneccessary risk to the whole development. Just the fact that I would have to dualboot just to test whether builds work as expected is additional bother, and I suppose you will eventually run into issues with something not working the same on Windows as it did on Linux.

Also, isn't there the whole issue of DirectX not being supported on Linux?

And since gamedev is usually a lot more resource-intensive compared to other development, you can't really containerize it.

[–] turbohz@programming.dev 2 points 1 year ago (1 children)

Nonsense

[–] Mikina@programming.dev 1 points 11 months ago (1 children)

From my experience, just getting Unity to run on Linux has a plethora of issues. When I tried running our project we've been developing on Windows for the past few years, I couldn't even compile it. Apparently, Unity on Linux doesn't support some kind of media file formats we use for cutscenes. While I was trying to resolve it, Unity crashed few times.

And then there's the hug problem with "works on my machines". We're targeting Windows, Windows is still major market share for gaming, and me being the lead programmer, I can't afford not being able to build and test a build on the OS we're targeting.

Even if the differences between build targets are minor, there's still a posibility that something will just work differently on Linux than in does on Windows. And then you have the whole DirectX issue - IIRC, you can't use DirectX on Linux, so we would have to develop the game for Vulkan or something else, which adds another problems to deal with for other programmers in our team, who don't use Linux.

And then you have consoles. Do the SDKs for Sony, Switch or XDK even support running on Linux?

[–] turbohz@programming.dev 1 points 11 months ago (1 children)

You said: (Linux) "unusable for any kind of gamedev...".

That's nonsense.

You raise valid points, but they do not support your conclusion that: (Linux) "unusable for ANY kind of gamedev...".

You know that, though. You were hyperbolic, I know that, too.

By the way, you should try Godot. You'll be surprised.

[–] Mikina@programming.dev 1 points 11 months ago

Oh, you are right, now I got your point. Sorry for that, I honestly didn't realize that I was making such a hyperbole.

I definitely plan to switch to Godot once I'm finally done with the school-project turned indie, that we're struggling with for the past 5 years and it's mostly holding on sunken cost fallacy. Unfortunately, since at work we mostly work on ports for other studios, I doubt I'll ever get to work on Godot there. But maybe at least the Unreal experience is better on Linux, never really checked that out.

[+] turbohz@programming.dev 1 points 11 months ago

[deleted]

[–] Auzy@beehaw.org 0 points 1 year ago (2 children)

I was going to switch to Linux, but my big hesitation at this point is none of the distros integrate Android support

Whereas osx supports iOS and Windows supports Android now

So, it's actually far less productive for me

[–] onlinepersona@programming.dev 6 points 1 year ago (1 children)

What kind of Android support are you talking about? You can run full android on linux with WayDroid

[–] Auzy@beehaw.org 1 points 1 year ago (1 children)

I've never seen that before, but looks interesting. Unfortunately though, also looks like its still Beta.

And not sure I could rely in it for the extended long term either unfortunately if a distro developer like Canonical or the red hat guys aren't working on it directly :(

[–] onlinepersona@programming.dev 1 points 1 year ago

WayDroid works pretty well for me.

[–] autokludge@programming.dev 3 points 1 year ago (1 children)

Care to elaborate on you are looking for with Android support?

Have been happily using KDE Connect for a while now.

[–] Auzy@beehaw.org 1 points 1 year ago (1 children)

Ability to easily run Android Apps natively, within Linux.. There are lots of hacky ways, but I really want a proper official supported way (which both OSX and Windows does).

Because I have a few custom apps and such I need for work or for other things. Yes I can do them on my phone, but easier to do them on computer

[–] starman@programming.dev 1 points 1 year ago* (last edited 1 year ago) (1 children)

You shall not get "proper official supported way" from Linux, for it is a kernel, not an Android emulator.

[–] Auzy@beehaw.org 2 points 1 year ago

You know what I meant.. Obviously I meant something baked into a distro like Ubuntu or fedora to let me use Android apps without messing around.

Arguing semantics isn't really helpful

[–] kherge@beehaw.org -1 points 1 year ago (1 children)

I cannot imagine doing this for my work. I need a machine I do not need to worry about breaking or suddenly becoming incompatible with the next update.

[–] Piatro@programming.dev 10 points 1 year ago (1 children)

Wait are you talking about macos or Linux?

[–] kherge@beehaw.org 1 points 1 year ago (1 children)

My bad, it was meant to be a response to the comment about people switching from macOS to Linux.

[–] varsock@programming.dev 4 points 1 year ago

getting a developer account with redhat you can have up to 10(?) instances of RedHat Linux LTS. super stable, is run on servers for many critical serves. Or just use rocky linux (bug for bug compatible with red hat) and establish a roll back procedure. There are rollback options at the filesystem level so you can snapshot before an update.

I use fedora and I don't typically have any issues and that is considered bleeding edge.

Macs have too many guardrails that get in the way which can be as disruptive as something breaking bc you need to work around it. But I am acknowledging that it is use case dependant.