Live data from Hacker News

Microsoft Windows is prohibited at Gitlab

about.gitlab.com

301–310 of 324 posts

Re: Microsoft Windows is prohibited at Gitlab

#301
post #289
post #130

Earlier quoted context omitted.

Which means their workforce doesn't give a fuck about supporting CI/CD pipelines used by Windows development, unless they have some mental powers to test them with having Windows around.

So, you think a very small Modul that communicates via http only, and written in different language then the main project (go instead of Ruby), is a reason that the developers of the main project (ruby, only supported on Linux) should also be able to work on Windows, or even be supported in doing so, cause ~three people need to support the gitlab-ci runner on windows? Edit: oh, and testing of those gitlab-ci function…

Since when CI/CD products like a compiler, static analysis, os frameworks are a very small module?

If they aren't running Windows, I really doubt their skillset to give any kind of meaningful support.

Re: Microsoft Windows is prohibited at Gitlab

#302
post #162

Earlier quoted context omitted.

So their developers do indeed use Pixie dust when debugging Windows build pipelines and compilers.

I am running a Linux laptop, and I regularly run and test code on Windows, macOS, FreeBSD, OpenBSD, NetBSD, DragonFly BSD, and illumos. Basically, all the systems Go supports minus Solaris and AIX because they're proprietary and I can't "just download" them AFAIK, and Plan 9 because I found it too confusing/hard to set up (and is so obscure I don't really care too much either). The "Pixie dust" is QEMU and a zsh scri…

And naturally you can answer any Windows support question as good as a Windows developer that is running their system 8h a day.

I surely won't regarding UNIX flavours, and have been using them in some variation since 1992.

Re: Microsoft Windows is prohibited at Gitlab

#304

I'm no fan of Windows myself, but I find this a fairly bad policy. If nothing else - what's not used is not tested. And if you expect any real population of users to be using Windows machines with your products, you should have developers/PMs/QA/support interacting with your products using Windows machines. I see this as: We're saving a bit of money and making ITs life easier, and in exchange users will get a worse p…

> what's not used is not tested What are they going to test on Windows? It's a web platform that runs on a Linux server... And Rails is kinda annoying to develop on using Windows, you definitely won't put it on a Windows server, what's the point?

Test that the web UI works for the large number of customers running a browser on windows?

Confirm the Windows runners work as expected?

Re: Microsoft Windows is prohibited at Gitlab

#305

Earlier quoted context omitted.

I‘m a bit surprised that they care about the cost so much - the Dell laptops and the Apple Laptops come in at a price point of 2000 - 3000 USD and the Dell they specifically recommend for Linux use comes with Windows Pro preinstalled. The price difference to the equivalent Linux version is around 70USD. That‘s a negligible difference, especially when you start comparing to the employees wage (It‘s probably about 1 ho…

Most places I've worked at (Windows shops largely) had management tools that worked well on Windows but not as well on other devices. The IT staff was skilled largely in Windows, as well. The biggest argument against other OS options was that we simply did not have the tools and experience to effectively manage the other options. It's a valid argument, and seemed disingenuous to take digs at the other OS options when…

That was the only real benefit of having a mac in my experience - they were always a niche and off the radar and didn't have the 20 different security tools on them crippling performance like the Windows SOE.

Thankfully WSL2 on Windows is now an option, its also off the radar so whatever happens inside the Linux VM doesn't cop a performance hit.

Re: Microsoft Windows is prohibited at Gitlab

#306
post #198

Earlier quoted context omitted.

You are missing an important point: engineers want to use the tools that work best for them. They don’t care much about the things they can’t see. Taking a job with a super restrictive IT environment that would prevent me from doing my job effectively would be a deterrent to work for that company. I know many people who feel similar to this. The opportunity cost of not being able to hire those people or giving them o…

I've rarely seen individuals be very happy with Linux / Unix outside a few very dedicated, stereotypical hacker-types. Safe to say anecdotes don't work. I'd also think twice about the consequences of these decisions. If Gitlab and co decide Linux/Mac is the answer for market share, it's only a matter of time before hackers start targeting those platforms en masse. If the answer to Windows was restriction galore, I fa…

Seems like its a pretty good filter to me, anyone not adaptable to a different operating system is probably not a great fit for a company like gitlab.

Re: Microsoft Windows is prohibited at Gitlab

#307

Earlier quoted context omitted.

It implies a major problem in their org is/was pesky developers working on things that weren't assigned. Why weren't those things assigned? Bad PMs who don't care about the pain developers feel? Not enough developer freedom? The fact that the roadmap is completely disconnected from what's actually important for the business/developers? It's a product for developers; the developers should know better than anyone what…

It's interesting that what I read there is just a company saying "hey, we have this nice TODO app that interfaces with your development tools". There's nothing there about developers management, freedom or anything else. Looks like corporate lingo is no better than a Rorschach test.

Since when is “at the right time” a problem? Virtually no one has that problem, so if they think it’s a big issue, big enough to spend marketing copy on, that’s because they are weird. Inventing problems is typically seen as a sign of dysfunction.

Re: Microsoft Windows is prohibited at Gitlab

#308

I wonder if this has anything to do with the fact that gitlab is fully remote. In an office where you have on-site IT staff, and a local corporate LAN, you can require every windows machine to be part of AD, have group security policies pushed out, and generally have tools available for central management. But with gitlab, everyone is working in their own networks around the world. That sounds like a very hard enviro…

My corporate win 10 laptop does all those things fine when WFH.

They just set it up, couriered it to my house, gave me my password and off I went.

It does all its GPO update, carbon black policies etc. over the VPN exactly the same as if I was in the office.

Worst case scenario gitlab would just need to courier equipment globally via a decent carrier like DHL, but probably a drop in the ocean compared to other staff costs.

Re: Microsoft Windows is prohibited at Gitlab

#309
post #208

Earlier quoted context omitted.

Mobile device management is the topic. You can manage windows devices remotely, just as you can manage MacOS devices. No need for them to check in. It „just“ takes some effort, and if you have multiple operating systems to support, the effort is multiplied. But a company of their market cap and size probably should have the funds for a team dedicated to this.

BYOD certainly has its problems, but it doesn't seem like they're even trying. "To provide proof of Full Disk Encryption, please do the following depending on the system you are running..." Having your users send you a screenshot to verify device compliance is ridiculous.

Yeah its impossible, they can't meet the audit industry gold standard of the windows clock in the screenshot to validate its authenticity.

Re: Microsoft Windows is prohibited at Gitlab

#310
post #261

Earlier quoted context omitted.

They do allow linux though, and I have yet to find a competent device management software that supports Mac, Windows and Linux at the same time (or even Mac and Linux). I‘d be happy to hear recommendations.

What are you looking for? Managing Linux at scale is extremely easy as you can leverage basically all the tooling that sysadmins use(d) for management of infrastructure fleets. You can even get a pretty GUI if it’s saltstack enterprise.

Something like saltstack is not in the same league as point and drool windows solutions.
Post reply on HN