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 product.
Realistically - that's a bad trade. It is almost never the right decision to prioritize IT quality of life over basically any other business need.
I mean, Gitlab is a web platform. It's pretty easy to test how it's going to work on different platforms without needing full machines. Heck, you can even just get Microsoft Edge binaries on macOS and Linux if you want to test Edge. But failing that, VMs are pretty sufficient.
God yes, I hate how all FEs have tunnel vision on MacOS nowadays. Our sign-up flow had godawful scrollbars both horizontally and vertically for the longest time but they didn't notice because they're all on retina display Macbooks instead of what the bulk of our users will be using.
Macos do have a option to always show scrollbar. And I think this is a pre-requirement to enable that if you ever care about what your user may actually see as a FE.
Besides that, there isn't actually obvious different between firefox/chrome/edge on macos/windows.
The most problematic one is actually safari(which is on mac only). If you dev on chrome and use on firefox or vise versus. You usually get a "mostly work with minor visual different". But safari… will give you a fail and are't even usable. It is outright the modern age ie.
A solution is to have somebody in each FE team with a "that's what the masses use" device. Screen-wise, CPU-wise, RAM-wise, network b/w wise. And let them use it as a primary dev device.
Doesn't sound sexy, no. Compensate them royaly. And make clear that they are superstars just by having this work environment. Then keep listening to what annoys them with whatever you are building, and let them fix it.
I agree with this nitpick. Unfortunately, I think we are losing that battle, because more platforms are adopting the hidden scrollbar (anti-)pattern.
That, however, is bound to happen even if you have Windows workstations. It happened at a job where I was, in fact, running Windows, because the designer ran macOS and was oblivious to this issue. (Of course, I would fix it when spotted. But it still managed to make it out to prod at times.)
What's especially nuts about this to me is that macOS supports static scrollbars! System Preferences → General → Show Scroll Bars → Always.
Or, leave the default settings in place, but plug in a mouse with a physical scroll wheel.
So it's not even that they're only using one platform, but they're only testing the platform with default settings with the default hardware. And we're not even talking about an obscure setting buried three levels deep, it's right there in the general pane!
This can be fixed by toggling a single MacOS setting to make the scrollbars always visible so that FE devs can feel the pain they are causing to their non-Mac using customers. Can be included into onboarding process. No need for a real windows machine just on that account.
This is one of the first things I always turn on with a new Mac. And I always encourage everyone on my teams to turn this on because otherwise it goes completely unnoticed until we get that huge surge of issues and product being angry because Windows users complain about it.
But I also place the blame on design teams. Most design teams I've worked with also doesn't account for this in anything they create. They usually only design for: 1: the latest macbook pro; and 2: the latest iPhone.
I think YouTube comments have a bug like this right now. On Windows I frequently see a giant horizontal scrollbar across some comments that doesn't even move, or moves very little.
VM's are sufficient only if you want "idk, it runs kinda glitchy on the VM" to be the end of the conversation when Windows-specific bugs come up in dev. And "idk, works fine on the VM" when Windows-specific tickets come up in prod.
The binary is still platform specific. Chrome, for example, does not render identical select element menus across platforms and certain select style rules are interpreted differently across said platforms.
I'll give you a point on VMs but it's cumbersome. There's a big difference between rolling to another machine or asking someone in the department who uses that machine every day and waiting for a VM to finish booting or using a service like Browserstack (and both cost $$ anyway).
Gitlab ships various ci runner executables for all platforms. I use their Windows ci runner and it works well, but I wonder how they test it without running windows.
This policy about which OS your laptop runs does not seem to preclude the use of Windows VMs (and presumably CI runners, though I bet we could see if that was the case ourselves) if it were needed. The open source nature of Gitlab also makes it easy for a developer to test things on an unprivileged personal device, I'd imagine.
If that was not enough, I believe the CI runner is written in the Go programming language, which has a surprisingly decent abstraction of OS functionality in it's standard library. Imperfect as it may be, I suspect that helps reduce the amount of effort needed to ensure individual platforms work properly.
> Gitlab ships various ci runner executables for all platforms. I use their Windows ci runner and it works well, but I wonder how they test it without running windows.
It is prohibited at Gitlab according to this policy. On developer laptops. It is not necessarily prohibited in all contexts. The one-line title could've been slightly clearer, but I think it's a totally fair statement.
The prohibition on developer laptops is not just a trivial or nitpicky detail; while the security of a VM obviously still matters, as you can't simply assume that malicious software in the VM can't escape, I would assume that the policy effectively means it would also be prohibited to setup a Linux dom0 and just run Windows under that and use it as your developer workspace. The benefit of only using Windows for testing is that you presumably won't be reading emails, talking on team chat, taking video calls, opening documents, etc. inside of Windows, only doing the thing you actually need (testing.) From a security standpoint, this can be helpful. I think that Windows vs Linux security is a rabbit hole not worth debating; both are very flawed and have many challenges, nothing is a panacea. However, I would say that every OS you don't need to harden is a huge operational advantage no matter how you slice it. You effectively cut off an entire slice of the malware market, and easily the largest slice in case of Windows.
If you would have kept reading, you would have noticed that employees can apply for an exception to the policy.
So if, for example, you are a UX dev and need to test your CSS on Edge, they have a process that allows you to do that.
And it's not "just a bit of money", Microsoft's enterprise product licensing is truly onerous. It's almost a career unto itself just to make sense of it, and it requires a non-trivial amount of infrastructure to support.
I agree. If nothing else they won’t be able to replicate Windows typography, which is different from Linux and OS X. Base fonts are different; kerning and anti-aliasing are different. Web design is still 90% typography, and cutting the largest install base out of your test matrix seems silly to me.
I have a company laptop that runs Windows, but everything I work on runs on an ARM-based device.
Work computer != target machine
For about 20 years, I've not developed anything at work that runs on the work computer that is used for doing the development, documention, e-mailing and whatnot.
Developing "essentially a website" is my full time job - if you genuinely don't think there are differences between platforms, you aren't paying attention.
The browser is wired into the OS in real ways, and they matter. Everything from "How does the os manage passwords" or "how are system notifications presented" or "How much screen real estate do I have have on a given window size (scrollbars...)" to subtle differences in how the network stack behaves, or how windows are rendered.
Hell, I can list about 20 differences just off the top of my head - and a damn good part of that is because I've been forced to pay attention to each of those platforms. Which clearly you have not...
I read your comment as "I only use a mac, and I don't understand".
Have you been using Gitlab lately? I don't think they have any interest in nuances, as they still have problems with basic stuff.
Overall i'm pretty sure that "list about 20 differences" is relevant in some cases/procucts/websites, but not for gitlab - they just proved that by disallowing working on Windows (which wouldn't disallow testing on a VM).
I've been making software for almost 10 years and password manager/notifications/responsiveness is not dependent on the platform that's why we have web standards.
> It's easy to spend decades making crappy software.
But here's the important question: are the problems that are caused by ignoring the aforementioned differences enough to prevent people from being able to use your software? Or, conversely, are they enough to weigh more heavily than the functionality that you provide for your users?
Because somehow even Electron based software is pretty popular in the desktop, oftentimes looking and feeling rather different from most of the native software. But apart from nitpicks and rightfully complaining about those annoying inconsistencies, does it really matter enough to spend resources towards fixing them?
I can't think of that many inconsistencies that caused web applications to be unusable across different platforms altogether, apart from IE not supporting certain JavaScript functionality back in the day and non-transpiled (to say, ES5) codebases breaking altogether. But look and feel related things have hardly been as important.
There can be weird differences that show up on different operating systems, even with the same browser.
For example, we ran into a difference between Chrome on Linux vs Chrome on macOS where it turns out that on macOS, if you right-click on a link (to open a context menu) it selects the text of the link, while on Linux it does no such thing. Initially we'd tested on only one platform because we assumed they'd behave the same, and this difference resulted in buggy behavior on the untested platform.
There are definitely differences between mac and windows (possibly linux) when it comes to font availability/rendering(maybe?)
I've seen more than once a mac design use some font in a light weight that comes across almost invisible on Windows. I'm the only windows guy at our shop and "everyone has access to windows VMs to test" (lol)
Outside of that, now that Edge is on Chromium most of our edge cases seem to be Safari these days (everyone uses chrome/firefox except a couple management using Safari).
Which all in all I guess is a testament to our lack of full browser testing :)
In fact, if you paste text into GitLab's "Web IDE" in a windows browser, the results are (or at least used to be? We stopped using it because of that) horrible to the max. Of course with the added nuance that copy-pasting a word vs. a paragraph vs. an entire file produced vastly different results, too. That one was fun to figure out.
Windows is a specific set of skills that takes a lot of people to do properly at any scale. The dedicated resources required are essentially a drain on the whole of IT. My company also bans Windows for the same reasons.
For many years, and in so many companies, the policy has been the opposite.
All company laptops must have windows, anything else needs to be vetted by the IT admin.
Now that the Edge browser works fine on Linux, there's really no need for all these licenses, and someone needs to start to break the unhealthy dependency every company has on Active Directory.
Yep. I find it kind of surprising that this is news. There are so many companies where nothing but Windows is allowed, but not allowing Windows in one corporation with a major Microsoft-owned competitor is the issue?
Testing for Windows on a non-Windows machine is far easier than testing for macOS on a non-macOS machine. Of course, having people use both is better. IIRC, Steve Klabnik uses Windows to ensure that Rust supports the platform well.
It doesn't sound like Gitlab doesn't allow windows at all.
This sounds to refer explicitly to using interim personal laptops until departmental hardware is issued formally (which, as I understood it, may then run windows).
you're gonna have a bad day if you're depending on random employees for testing a site used by millions.
instead, invest in:
- real automated testing (to the extent technically and economically feasible). One hack is to get customers and partners to fund it, then leverage outsourcing.
- feedback from users - make it easy, streamline responses, setup escalation. Understand that you can't nail down everything and quickly triage issues. Scale the team so at least you can do the triage.
I certainly expect them to be driving the phone they are developing for - in the case where a single team is doing both iOS and Android - yes, I expect them to be using both consistently (and I argue for issuing both at companies where I've led mobile teams).
I've been down the whole "we'll just test it in a vm" path, and it works... if by works you mean you get a happy path test every once in a while, and devs make sure the automated tests pass.
It doesn't instill the same level of care and attention that daily use gives. Dog-fooding is not a joke. It's genuinely hard to make a decent UI for a platform if you're not using that UI often, and in real situations.
I've literally gone as far as making devs switch device personas over time on my mobile teams. They get an assigned device from our test pool for the sprint from a list like
- High end stock android device with large screen
- High end stock android device with small screen
- High end Samsung ROM device with large screen
- High end Samsung ROM device with small screen
- Mid tier stock android device with large screen
- Mid tier stock android device with small screen
- Mid tier Samsung ROM device with large screen
etc... down to the devices no dev wants at all, like
- Amazon Kindle Fire default
- Amazon Kindle Fire kids
and they do all their dev/testing/use on it.
It works fucking wonders in suddenly making them care about things that were previously just "meh" problems. Two weeks stewing in their own problems on a device they were ignoring is one hell of an incentive.
It's common for companies to encourage their dev workforce to use a broad variety of company-provided mobile devices so that, while dog-fooding, they get better coverage.
Realistically... Microsoft owns GitHub, and the weird Azure devops-ish solution for git. If an enterprise is on Microsoft, they're going to use one of those two solutions instead of GitLab.
Making IT's life _vastly harder_ to allow employees to maybe use Windows and see a solution the testing team didn't see is not a good trade-off.
That's not even going into how, exactly, Windows is going to make anyone's life better than using a Mac. Realistically, they're at least at parity.
The trade-off here is "make every IT support and supply line more filled with friction" to gain "people can use Windows if they'd really prefer, instead of Mac or Linux". That's a terrible trade-off, and GitLab is making good decisions.
Take into account that they prohibit Windows Home specifically.
In my company I am dealing with buying laptops for new hires - there is no way I am buying laptop with Windows Home edition.
That is problem with explaining people that they should buy laptop with Windows Professional. Whatever the cost is - company is paying. New hires are shy to expense company THAT is the problem.
So I think problem is that people try to buy cheapest laptop they can to "be cheap".
If my company would be on scale of GitLab I probably would not be able to control that but I am specifically buying laptops via my manager - and there is no way we would buy Windows Home laptop.
Does anyone know if this policy is causing GitLab's product quality to suffer? I see your argument, but products like BrowserStack and VMs can be employed to mitigate some of the negative effects. It seems premature to call the policy bad without examples of harm it has caused.
I guess is is for developers and business but in some other areas Windows would be hard to avoid: physical security systems, guest management systems and a few others.
On top of that, the justification seems more like a baseless rant, citing only one blog post as a source. Ranting engineers should not make business decisions.
GitHub for example does have desktop apps that allow using GitHub for less CLI-inclined folks. This allows integrating people that are not primarily developers into your GitHub-based workflows with less hassle, and fosters collaboration across those boundaries.
Git for windows is also notoriously different when it comes to edge cases, so in Gitlabs place I‘d be absolutely happy to have developers that use that OS as a daily driver.
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?
>> GitLab approves the use of Linux, and Apple's macOS. Microsoft Windows is prohibited for the following reasons:
Due to Microsoft Windows' dominance in desktop operating systems, Windows is the platform most targetted by spyware, viruses, and ransomware.
macOS is preinstalled on Apple computers and Linux is available free of charge. To approve the use of Windows, GitLab would have to purchase Windows Professional licenses, as Windows Home Edition does not satisfy GitLab's security guidelines.
As many purchases of laptops have occurred with employees making the purchases and then being reimbursed by GitLab, a remote employee would typically be making a purchase of a laptop pre-loaded with Windows Home Edition.
Windows Home Edition is notoriously hard to secure.
edit: after thinking about this for a bit, it occurs to me that their main competitor is github and that maybe they just aren't very excited to use MSFT products?
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 hour of their time, one-time cost)
If they‘d make the point based on lack of internal support capacity, I‘d understand, but caring about the one-time cost of the license is a very weak point.
Where did they mention cost concerns? I’m reading this that it’s an IT/procurement hassle dealing with the Windows Pro upgrade licenses, on a platform they don’t feel is secure, not a cost issue.
The linux laptop they propose comes by default with an included Pro license, home edition would need to be selected extra. I haven‘t used Dell in a while, but I‘d assume that it behave like Lenovo and has the License Key baked right into the EFI, so there‘s literally no need to deal with any upgrade license if you proscribe which Laptop Model people are allowed to purchase (which they do)
They also mention multiple times that Linux and MacOS are free, as opposed to Windows Pro - which can reasonably be read as „we don’t want to spend money here“, since otherwise you could just strike these arguments and revert to „we don‘t believe Windows Pro is secure“, which incidentally they never say.
If you follow the link to the model in their page, it selects the default version with Windows 11 PRO. You can explicitly choose Ubuntu, but it‘s not the default. My point here is „acquiring the license for a windows based laptop is a non-issue if you‘re willing to spend the 70USD it costs.“.
The problem is generally less the individual pro license and the associated enterprise licensing costs that come with managing said device in Azure AD/InTune.
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 the reality was that we simply couldn't support a Mac well in an enterprise environment.
Microsoft Windows with AzureAd and Intune provides a suite of tools for managing your fleet of laptops at little to no additional cost. It's honestly so much for free that running any other suite of laptops becomes arduous and expensive. It all just works out of the box and it's easy to bolt things on. The viruses and malware argument is ludicrous if you do any amount of end point protection.
Apple is a walled garden. Everything is a degree of difficulty or two harder and you often run into weird ecosystem shit like some aspects of laptop mdm registration only working if the user has an iPhone. The tooling is 5-10 years behind, non-existent, or expensive because the third parties know they got you by the short and curlies.
Linux is a build your own from open source ecosystem and what understaffed overworked IT team has time for that. I mean Google manages their Linux laptop fleet by rolling their own distro. Never mind all the compatibility issues with other required tooling that may or may not work.
Some of these issue may have been easier to conquer in OnSite roles where laptops could be dropped at an IT cage but for full remote the Windows ecosystem has just gained more ground because of the iceberg of features most users never see.
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 other incentives to alleviate those concerns is easily orders of magnitude more expensive than just buying a device management as a service solution for other OSes.
I’ve rarely seen people being very enthusiastic Windows users btw.
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 fail to see how humans won't repeat history and do the same to Unix.
Until 4 months ago, I was leading a team responsible for a cross platform desktop app with 20 million daily users, most of them on Windows. I used Windows daily and found/reported numerous bugs to Microsoft. I would never have made it my primary development environment, but I had some people on my team who liked it for that.
I think your uninformed ad hominem attacks are really impolite by the way.
Speaking of ad hominim's I am confused. Have you "I’ve rarely seen people being very enthusiastic Windows users btw" or "had some people on my team who liked it for that."
From my perspective Windows in 2022...
- I can seamlessly develop in Linux on Windows using WSL2
- I can manage my machine with a package manager (winget)
- I can run Linux Native GUI application (wslg win 11)
- I get Microsoft's epic backwards compatability
- I get guaranteed comparability with 99% of the software and hardware available today
- I get a suite of expandable back office tools for managing my fleet
Honestly, there are days I spending in visual studio code and windows terminal where it doesn't even feel like I'm on Windows. I can get the best of both environments out of the box.
...but tell me again how there is nothing to be enthusiastic about windows.
Obviously there's a spectrum and my personal experience is not representative for the industry as a whole. From the people I've worked with in 2 decades, maybe 2% choose Windows over Unix when given the choice, even when most customers were using Windows. At my current job, I literally know nobody using Windows (>$1B software company with high 3 digit or low 4 digit number of engineers). Not sure why anybody thinks a Windows only policy would be a great idea in this labor market.
I entirely agree - supporting multiple operating systems is effort at every level and from a certain size on, you need people with dedicated knowledge of each OS. But if that’s the problem, make that point instead of finding excuses.
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.
It wasn't a limitation of the places you've worked at - endpoint management tools for Windows are light years ahead of the ones for Apple. Moreover said tools simply don't exist in Linux land.
I didn't read it as cost, but management overhead. It's easily possible to secure a Windows computer in an enterprise environment. They are fully remote and primarily a Mac shop, so they don't have that expertise or infrastructure. If you are running Linux on a Dell, then they assume you have the ability to manage that yourself.
I see this more as a function of them being fully remote more than anything else.
Then just say so instead of making excuses about security and cost. We also only buy a selected range of hardware and support a selected range of Operating Systems. But the reason is stated as “We currently don’t have the administrative capacity to support more than this. Period.” And that’s a fair reason and good reason and everyone understands that.
You wouldn’t use Home SKUs for enterprises anyway, if you want to apply any policy you need Pro/Enterprise. In the end it’s about GitLab dismissing an entire laptop over a $70 upgrade key, or $200 Pro license.
> Due to Microsoft Windows' dominance in desktop operating systems, Windows is the platform most targetted by spyware, viruses, and ransomware.
That may be true, but a much higher proportion of downloaded Mac software lacks code signing. Opting in to that as a developer on the Mac will carry a lot of risk of kafkaesque deactivation and, and most don’t want to deal with that. On Windows, on the other hand, it’s like getting an SSL certificate. Apple’s philosophy on the developer program is antiquated, obsolete, and has compromised the security of the platform.
How many Mac users do you think limit themselves to only signed apps? It’s much easier to do this on Windows (but requires a small amount of technical understanding, or is it too much for Gitlab employees?). But when you enforce the policy at the corporate domain level, you won’t be neutering the machine’s usefulness as you would on the Mac. Unsigned apps on Windows tend to be the janky ones, while the signed apps found on the Apple Store tend to be garbage in my experience.
Relying on “less malware is created for Mac” is a terrible idea in general. This isn’t the 90’s. When you are Gitlab, a high value target for sophisticated, targeted attacks, that won’t help you.
Good Security is a balancing act between safety and convenience, and Apple gets it completely wrong. Therefore I would be very cautious about trusting Gitlab’s security posture given their apparent ignorance on the subject.
> If your certificate expires, users can no longer launch installer packages for your Mac applications that were signed with this certificate.
> Apple Developer Program membership is required to request, download, and use signing certificates issued by Apple.
> Note: Apple can revoke digital certificates at any time at its sole discretion. For more information, read the Apple Developer Program License Agreement in your developer account.
… and many paragraphs detailing what parts of your app will break when certificates are revoked.
There are more nuances involved than I care to list in full here, though I’d be happy to be proven wrong about this.
I can’t remember the last time I allowed an unsigned app to run on Mac, I can’t even think of examples recently where I’ve gone “oh **, this thing is unsigned?!”. I’d love examples of high quality apps without a basic codesigned certificate, maybe we have a disagreement over the term “quality”.
“App Store apps are garbage” is also kinda rich, it’s not windows, the Mac App Store is the go-to source for distributing Mac apps at this point. There’s some examples of popular apps not on the MAS but they grow fewer by the year.
> There’s some examples of popular apps not on the MAS but they grow fewer by the year.
Well, yeah, the success stories have the budgets to handle compliance issues, and to manage risk appropriately. Apple will also be more lenient with large publishers for a number of reasons. I wasn't talking about popular apps, I was talking about apps that make me productive. Things made for power users. Popular isn't a concern there. But if BigCo doesn't allow me to install it, that's a dealbreaker for me working there. Experienced that in 2010 when working for a Fortune 50. One approved text editor, one approved browser. The productivity apps I use are not on the app store. They are signed, but chances are that a locked down Mac will require App Store installations only, while a Microsoft configuration would be more optimal.
For the record, I DO prefer a Mac for productivity. But when it comes to security, Microsoft wins. Or even better, Linux (though Microsoft is giving it a run for its money with W11)
Kdiff3 had its last release in 2014, old multiplatform apps that weren’t updated would have this problem. Zenmap seemed to not be unsigned? Wireshark was definitely signed, which I was kinda surprised about. I wouldn’t have expected QT apps to be signed, but looks like even those have some support. I’d also argue there’s better Mac apps, at least in terms of kdiff3 ;-).
Fair enough on App Store / popularity, my point was mainly saying the apps on the App Store are of “lesser quality” / the lowest quality is ridiculous. It’s not like the 30% of setapps not-on-the-AppStore apps are explicitly not doing it from a quality standpoint. Most are just because they don’t want to / financially can’t afford the revenue split.
All of the reasons are perfectly valid. Just not extremely relevant.
Normally any company looking at that level of operational detail has a problem. But on their case, yes, it's probably because Windows comes from their competitor.
Adding a bunch of work, costs, and risk to yourself that will only benefit your competitor does not feel good. No matter how relevant are the work, costs, and risk.
I haven't had problems with viruses, spyware and ransomware on Windows for years. Microsoft's builtin spyware marketed as telemetry and diagnostics otoh is very difficult to counter even with dedicated tools like O&O ShutUp10. I get why companies don't want to risk giving business secrets to Microsoft.
>I haven't had problems with viruses, spyware and ransomware on Windows for years.
That's great and all, but I'm not sure what point you're trying to make. That there isn't a problem of malware/ransomware? Because there certainly is, and for most organizations the risk of malware/ransomware is much more significant than the fact that Windows gets some error reporting and usage statistics and such.
Having such a supermajority of desktop operating systems in use means you get most of the developer attention. Unfortunately, it seems to surprise folks that malware also has developers responding to the overall market conditions.
Microsoft is certainly doing their best to mitigate the negative consequences of the monoculture, but it remains a fact and an issue. Just like in biological systems, diversity in software is also critically important for the health of the population.
Hey, quick question. I have been the same for years, using Windows without any problems (at least that I know of!).
But soon I will have to go to the offices of the startup that I work for (I work remotely) and they all use Mac, and I am a bit worried if they start asking question about how I keep my computer secure. Anyone (not only parent author) can recommend something? A software to install or anything like that?
So they banned a wildly popular OS because it does not satisfy their security guidelines. I just checked, they have no guidelines for securing Windows. So you can't satisfy their Windows security guidelines because the guidelines for securing Windows were never written. What a joke.
Isn't that a case of the wetware that procures the laptops being not quite on the samepage, especially for someone working in geared towards developers company.
A buy something with windows pro is not hard to communicate...
> Due to Microsoft Windows' dominance in desktop operating systems, Windows is the platform most targetted by spyware, viruses, and ransomware.
This is poor reasoning and a misunderstanding of how security works. Any org should be happy with any OS, as long as sufficient security controls for it exist. Anyone who oversees Windows estates, or works in desktop security, can tell you that they exist and are extensive, and are effective.
I suspect this is a policy that's been pushed out by a C-level who simply hates Windows but is being justified with >15 year old reasonings.
> macOS is preinstalled on Apple computers and Linux is available free of charge. To approve the use of Windows, GitLab would have to purchase Windows Professional licenses, as Windows Home Edition does not satisfy GitLab's security guidelines.
More tenuous reasoning - macOS is not 'free'. By their logic they should _only_ be allowing Linux. But I think that just tells us it isn't driven by logic.
This was after the GitHub acquisition but I know for a fact there was one engineer who really wanted a Windows machine but IT was not interested in adding it to the fleet as we were already heavily Mac/Linux.
I mean, Windows has a ton of telemetry and spyware in it. It does not make any sense at all to run spyware from your largest competitor inside your competing business.
So very obtuse of them to word it this way. Windows has a cheaper license for HOME users who don't need Pro features of a business. It's not the other way.
The claim is Mac OS comes pre-installed but people don't claim money back for removing it, because it's considered part of the "Mac". With windows, people consider it an extra and claim back money for it.
At least that's what that explanation was about. They never said Mac OS is "free".
Considering all the security software my corporation forces on all of us, each product hammering my CPU and RAM while I try to compile...windows is an issue for developer productivity. (I'm a windows based developer, I feel the pain)
I'll make sure to mark Gitlab off a company I apply at if I look for a new job. I'm totally blind and have been using Windows screen readers for the last 25 years. The switching cost to Mac or Linux appears to be incredibly high. I've attempted to use both and after brief usage was not able to get close to my productivity on Windows. Maybe that would change if they were my only option but I'm not going to risk poor productivity at a new job on that. I focus on back-end development and since WSL came out, I've not run into any situation where I can't do what I need using Windows, WSL, and VS Code.
This is pretty similar to the policy at my company: you get a Mac, unless you specifically request a Linux laptop. If you need Windows for testing, Microsoft makes VM images available with a browser pre-installed at https://developer.microsoft.com/en-us/microsoft-edge/tools/v...
As a long time Windows user, it would take me a considerable amount of time to get used to the operating system and all applications and utilities that I need to be productive. Not saying Windows is great, but it works for me. And I'm pretty sure they don't hire people to learn an operating system.
As a long time multiple OS user and administrator, I can assure you that people figure out MacOS in the first two weeks. It's not anywhere near as strange as getting used to git for the first time.
We don't hire people in order for them to learn Linux, per se. We hire junior sysadmins who already have at least a home lab level of experience there -- a standard interview request is to describe a disaster that you caused, what went wrong, how you solved it, and what you could have done to prevent it and what you did do differently afterwards.
You're not wrong, I only use mac nowadays but I was previously a windows engineer so I know it in and out. It took me two tries to get used to a macbook, one I returned in its 30 day window and the other a corporate policy required Macs years later. It was frustrating for maybe a month or two, mostly the different keyboard buttons and shortcuts, but eventually I got it and I love it now.
I don't love the cost of apps on it, there are some tiny apps that I can't believe how much they want for them, and some bigger apps that are easily $60-200 but I don't need any of those.
Still use windows to game and I think it's still a nice chill OS that just works, for me at least. I didn't enjoy developing on it, though, I broke WSL a bunch of times.
I don't think it's hard to adjust, especially if you are surrounded by other apple users who can give you tips like the command-shift-4/5 screen grab shortcuts, etc. Perhaps more important is a familiarity with unix style command line, which goes a long way in macOS.
With decent Linux knowledge I think being issued a MBP at my first job out of college was better for my productivity than a windows machine would have been within a week or so, even as a long time Windows user. Windows has generally always had a higher frequency of annoyances.
Would you not apply to a role because you aren't comfortable with the main programming language used?
Learning is a part of the on-boarding experience at any new job and technical learning usually pales in comparison to learning about the business domain and company specific practices.
Another good feature of this policy is that it rules out people who explicitly identify themselves as "$OPERATING_SYSTEM user"s. Tying your identity (personal or professional) to some proprietary software brand is a little silly.
I'm a self-identified $OPERATING_SYSTEM user because I have been using $OPERATING_SYSTEM for 20 years in much the same way, like how it works, have a lot of things set up for it which is not always easily portable (e.g. scripts and programs I wrote), and have a lot of $OPERATING_SYSTEM things hard-wired in to my brain and muscle memory.
Can I spend time and effort changing that? Of course. But why fix something that isn't broken?
Am I tying my identify to $OPERATING_SYSTEM? No. It just works for me, so I'm a $OPERATING_SYSTEM user.
Because this can be a form of brokenness. Someone would be hired for their aptitude and probably not because of something they have already repeated over and over (unless we include factory work). The ability to adapt and create (and be creative) is usually not described as such in SWE work, but a lot of the actual work does include that.
That said, if a job has a match based on OS, it would probably just as much be a good thing to explicitly know that you either will be or won't be a good fit based on what you are used to and what you think you can adapt to. Knowing this about a job or a potential hire saves everyone a lot of time.
I like doing useful things; switching tools merely because a corporate policy says so is not useful (whether there are good or bad reasons for that policy is besides the point here).
Says who? I think (as a devil's advocate) it's very useful that people are interchangeable, and that tools are similar enough to allow people to collaborate.
I also think that if (imaginary percentages used) a 10% reduction in productivity because a worker can't use their most bestest tool ever is worth it if it means I can get 40 of those workers for the same price as 10 workers that are proficient in that very special choice of tool. You can pretty much exchange any of those with management overhead or policy requirements (be it by law or otherwise).
I'm not saying there aren't completely valid reasons for a business to have certain policies limiting the software used by their employees (including OS choice), it's just not useful for me. Learning a new language or technology is useful for me because I can then use that language or technology. But switching OS or editor or whatnot well enough to be my daily driver? I don't really see how that's useful for me. I don't really learn anything new, and I won't be any more productive; it'll just be "a thing I have to do, grumble". That's it's useful for the business is a separate thing.
> tools are similar enough to allow people to collaborate.
I think this reason in particular isn't all that valuable though; especially not since people tend to customize their setups anyway. I once worked somewhere that mandated software choice (including IDE) for this reason and I never saw any value in it.
There are plenty of good developers who haven’t had the time to become masters at multiple operating systems yet. In this economy, it’s better to stick with what you know well.
I once worked at a CDN (you know, 99.9% *nix) that didn't allow Linux machines because corporate IT didn't know how to fix them and their remote cough spyware cough didn't work on them. We even told them they don't need to support us at all and we're all old school unix admins, didn't matter, corporate policy. Windows or mac.
The pretext for banning Windows is comically bad. Paying extra for Mac hardware is perfectly fine (no, encouraged!), but paying $100 or so to upgrade Windows Home to Windows Professional is prohibitively expensive? That's such a joke.
I have no trouble with companies mandating one OS or the other. But when the justification for the policy is so bad it looks petty and ideological as opposed to the result of a level-headed cost/benefit analysis.
I would suspect that there's a valid reason (probably along the lines of "we are set up to remote manage a bunch of linux and macos machines, and our tools work on them; we don't want to add more overhead") but that the person writing the page didn't entirely understand the reason.
"Mac or linux, but not windows" is a somewhat common policy, or certainly used to be, and it's never about the cost _of the licenses_ (except for tiny companies, perhaps).
To be clear, you're saying there is a way to prevent _any_ and _all_ data about the device and its usage ever being sent to MSFT? And it won't be overridden by Windows updates or any nonsense like that?
Although not even hinted at in the doc, I personally find the tedium of buying and provisioning and monitoring licenses worse than the cost of it. I suppose you are also inviting risk in the form of an audit.
I was looking at a quarter million for a few dozen machines and 2 AD servers and 4 SQL servers. Nearly on par with the cost of the hardware I was buying. Until some bright spark realized it was all testing/dev/qa for those machines, MSDN suddenly was way better cost wise. If all you are doing is testing/dev then MSDN is usually the choice you want (but grab your lawyer to dig into the terms on that one). But in a real env with no dev work, the licenses become a real pain and very costly, and per year recurring many times, and stack because each service type has time, or sometimes they combine. Not dealing with it at all is very tempting.
Also the always-looming threat of Microsoft telemetry and BSA audit. You can do everything right as far as you can tell, abd they can still come in and make your life miserable.
Wait, they buy a second license to save money? How does that work and, more importantly, how can I convince lots of folks to buy my product twice to save money?!
you're not really allowed to use those licenses in many contexts. Might be ok for a startup; but at Ubisoft we had to maintain a fleet of KMS infrastructure.
Microsoft licensing goes way beyond Windows - there‘s the whole range of office software (which you can also license on Mac), then all the server software, etc., most of which should does not apply to Gitlab (unless they want to deploy on linux and switch to SQL Server as database, but I doubt that). And then, if you‘re big enough, you can negotiate corporate licensing to save money, which requires license management etc. I doubt any of this applies to Gitlab as they stand.
I had to look again and might have missed it, but I didn’t see where Gitlab expressed concerns about the cost of Windows Professional version. They had concerns with team members sourcing they’re own Windows laptops which would traditionally come with Home Edition and need to be upgraded adding to the IT overhead.
Where were the cost concerns on buying windows licenses?
> macOS is preinstalled on Apple computers and Linux is available free of charge. To approve the use of Windows, GitLab would have to purchase Windows Professional licenses, as Windows Home Edition does not satisfy GitLab's security guidelines.
They are in favour of Linux for it being free, implying that they do not want to pay for Windows.
I wonder how much that goes back to predatory enforcement where one person using a home/personal license inappropriately could lead to costly audit requests … or the suggestion that if you buy an enterprise license the problem will go away. People have long memories about that kind of thing.
No harping on cost was done. This is a overhead issue, and the same things apply to IBM and Oracle software. Whenever the product needs artificial management to only deal with the specifics of contracts and licences that's just a drain on the business.
While I think not allowing windows is a silly policy, Apple laptops still sell for a serious premium after 3 or 4 years of use. I've worked for companies where this was the sole reason for Mac being the default laptop you got. If you wanted/needed anything else, you had to specifically ask for it.
I really wonder what it's like inside Gitlab. The product ticks all the boxes you'd want it to, but the user experience just resonates with sadness and misery.
I work there. (And have for the last 5 years.) Obviously I can't divulge anything confidential, but ask a more specific question and I'm happy to answer from my vantage.
- Transparency is amazing, but it doesn't always mean clarity. We try really hard to say "why not just what" but you won't always have or easily get all of the context because there is possibly a lot of context.
- Async is really hard for new folks to adopt to, and it can be hard for people to adopt to "you will be measured on your results, not hours worked."
- I think we've done a really decent job of navigating an organization with a huge amount of cultures represented, but adapting and then adopting a "company culture" on top of that can also be challenging for team members to understand. (Think some cultures are more direct, and others reserved). This doesn't play out in any kind of battle, just as a leader having to be extremely well-versed in a lot of global culture aspects.
Happy to answer other questions (again, within reason) if there are others!
Web Dev is a really wide term, so a place that's a larger co there is more separation for parts of the stack. At a small co, a web dev might do all of the following:
Whereas at this scale those are all separate groups. So I'd say try to get stronger in a specific area that you are interested in (Frontend - Vue / Backend - Rails).
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 the right things to work on are.
"Work on what you think is important" is a fantastic policy with the right people, especially if your developers are also users of the product. Where it falls down is when the team grows and the "not right people" get added to the team.
I've seen developers work on just completely the wrong stuff, and their entire salaries was 100% pissed away, or in some cases, even more than 100% because they added net-negative value.
You really need to optimize hiring the right people with the right mindset and have a good team lead/manager which balances developer autonomy with business interest. I have thus far not seen it work outside of fairly small teams, although I agree that in principle it's the best way to make a good product and keep your developers happy.
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.
I'm a fan, I'd even ban mac/apple stuff if I could from my place of work.
It's clear corporations are seeking more and more intrusive control of our applications both business and personal.
A large and popular software vendor we have used for 7 years has approached us recently and wants to charge us a variable amount depending how integral their product is to our business.
Now management understands the threat, and we are shifting resources to convert things to FOSS, and build up the software community more.
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 environment in which to globally apply the types of security policies that are needed to keep Windows secure.
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.
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.
> Due to Microsoft Windows' dominance in desktop operating systems, Windows is the platform most targetted by spyware, viruses, and ransomware.
Being targeted less frequently != more secure. MacOS and Safari have had plenty of critical vulnerabilities in recent years.
> macOS is preinstalled on Apple computers and Linux is available free of charge. To approve the use of Windows, GitLab would have to purchase Windows Professional licenses, as Windows Home Edition does not satisfy GitLab's security guidelines.
> As many purchases of laptops have occurred with employees making the purchases and then being reimbursed by GitLab, a remote employee would typically be making a purchase of a laptop pre-loaded with Windows Home Edition.
Come on. A PC with Windows Pro is going to be way cheaper than a comparable mac. This is just disengenuous.
> Windows Home Edition is notoriously hard to secure.
Their last point was literally about how they would force users to get Pro, why does this matter?
I'd issue a counterpoint: there is far more expertise out there in securing fleets of Windows machines, and I'll guess most corporate Windows systems are more hardened to threats than the typical developer's macbook.
The real reason to use Macs is that you get a functional unix-like environment where you don't have to constantly jump through hoops in order to work with Rails. They don't have to fabricate security reasons.
This is not actually that unusual; in fact, if I'm not misremembering, Google also does not generally allow Windows, aside from some limited, less privileged stuff.
IIRC Apple is the same way. It requires extremely special dispensation to even get a Windows VM (ex: iTunes & Safari on Windows groups).
It's not uncommon at all, to be honest. I've done IT at startups where we said "Mac Only". Why? Because supporting multiple platforms is a lot of work. You need to do everything twice. All the software security done twice (and differently for each). Rolling out something new to the employee base? Two different sets of instructions. Setting up conference rooms with power bricks and video adapters? Had to be done twice (though this was a while ago, that is less of an issue now).
For small teams, it's just a workload that may not be doable. It's not like someone in IT says "I hate Windows, we're going to go Apple only", but often times a "Well, we're 90% Mac already, lets stick to just that". And yes, even with the "Apple Tax" its still overall cheaper to buy/support just macs.
Yep; you basically cannot fully enforce a moratorium on Windows without seriously pissing off finance (Excel on Mac is a joke, and Excel Online can't run macros, which is 98% of the value behind Excel)
I strongly dislike numeric keypads in general, and especially on a laptop. I want to be centered on the display, not shoved to the side. I only rarely use the numeric keypad.
2015 / 2016 I bought the original HP Omen gaming laptop because it didn't have a numeric keypad. There weren't a lot of other choices in the 15.6in category.
> As many purchases of laptops have occurred with employees making the purchases and then being reimbursed by GitLab, a remote employee would typically be making a purchase of a laptop pre-loaded with Windows Home Edition.
Windows Home Edition is notoriously hard to secure.
This is a totally valid point. Anyone who has worked for big companies know how companies secure systems using security policies which are not available on home edition and tough to setup on Profesional license bought by user.
If a user really wants to do something on windows then I am sure they can run it in VirtualBox or VMware on their system.
>Windows Home Edition is notoriously hard to secure.
This is bullshit. In Windows 10 Home the Group Policy Editor is removed, and domain-join is not supported, however bulk security changes (i.e. Security Policies) can still be implemented directly to the registry with scripting.
It's a fairly odd that that IT cultures are segregated into places that have nothing but Macs and other places that have nothing but Windows.
I think it's risky because a small computing monoculture can feel complete but commit a software business to failure at the very beginning by rejecting 90% of the potential market.
Device management becomes much more complicated when you have multiple OSes, though. Unless your company is small enough that self-management remains viable, you have to hire for both Windows and Mac administration experience, and/or shell out a pretty penny for cross-platform "enterprise" device management software.
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.
Is there something you can’t do? Or are you assuming sysadmins don’t learn their tools.
Arguably learning the idiosyncracies of proprietary management tools is harder long-term as there are myriads of edge cases and they get replaced with completely new tools quite often.
Exceptions are SCCM maybe, but people are avoiding that as much as possible IME.
Most Windows compliance tools are seen as a tick in a box so ease of use and low effort deployment is often the most important thing.
I'm sure you could achieve similar results with Salt but it will be some bespoke contraption requiring a lot of engineering effort where you cant just hire new staff off the street to maintain it.
Tell me what you need and I’ll tell you how hard it is.
I’m sure certain things are a tick of a box, with salt it’s usually 3-5 lines of yaml. It’s not like you’re writing a management system by hand in a general purpose programming language.
where I work there are controls to block USB media devices, they block certain software publishers (eg. cant run firefox), all sorts of annoying things.
Microsoft ecosystem is really hard to dip a toe into.
Properly supporting a handful of machines practically means bringing AzureAD or Exchange. AzureAD brings in elements of Exchange (like outlook), which brings in weird default settings like teams/sharepoint/onedrive.
Apple has done a lot of work in supporting Microsoft Exchange, but it's still janky as hell (just browse r/macsysadmin and you'll see).
So, you have two choices.
1) support the monoculture, life will be easier.
2) get a bigger IT department.
People are happy to spend a boatload of money avoiding the second option, so, monoculture it is.
Reading further on the page, the "Laptop Repair" part is interesting :
>If your laptop is broken and needs to be repaired you can take it into an Apple repair store. You should ensure that you have a recent backup before doing so, and that your laptop is not your only registered device for iCloud two-factor authentication.
>If the repair is not going to be too expensive (more than $1000 dollars USD), go ahead and repair and expense. If the repair is going to take longer than a day then you need to make sure you have a back up laptop to work on that is non-Windows.
It seems like you need to have TWO Apple devices, to be on the safe side...
That‘s very funny since almost all repairs on apple devices that I‘ve seen took longer than a day. Apple had [1] some very funky policies about shipping spare parts that essentially required the repair shop to have the laptop on their workbench before ordering the spares.
That's was my experience while trying to replace a battery. I proposed to pay in advance and only leave it there for the swap, but they can only order the battery if I hand over the macbook. Moreover, where I live they take at least a week to give your computer back for a simple battery swap. I ended up giving up.
This is why I find this policy ironic and silly. MacOS is the largest target of choice for bad actors as late because the ratio of high value/low chance of rejection users have migrated to Mac over the past few years because of the whole "Macs are safer" myth. To the point that an exploit for MacOS goes for a lot more money not because they are all that rare but because the value of the targets is greater.
Note how the windows ones are more up to date and patched faster? That's because Mac only does major updates on a cycle and doesn't patch out of band ever if they can avoid it. So yeah I think this is all theater and people's own biases being silly. But if it works for them then that's fine.
>MacOS is the largest target of choice for bad actors as late
I work in cybersec and am in daily contact with a few threat analysts. Not one of them has said this or believes this. Do you have some reputable source that can confirm this, or is this just a feeling you have?
>Note how the windows ones are more up to date and patched faster?
The presence of, frequency of, and patching of CVEs has very little relation to real-life attack frequency and targets. People are still getting owned by EternalBlue on unpatched machines from 5 years ago, doesn't matter how fast the patch is released if people aren't applying it.
>That's because Mac only does major updates on a cycle and doesn't patch out of band ever
Same with Windows. Heard of Patch Tuesday? The regular cycle of once per month that Windows does updates? They avoid releasing updates on other days unless it is high severity and there is evidence of active exploitation, and when they do out-of-band security updates it's almost always covered in some media and/or CISA releases because out-of-band updates are noteworthy.
I mean, they use Rails, and Ruby/Rails are annoying to use on Windows. I imagine Windows is a massive headache not worth dealing with considering their stack...
1) The reasons shown as to why Windows is prohibited are essentially parallel construction.
2) The real reason is because someone has an agenda against Windows and Microsoft.
3) This is quite alright. It might be a net loss in the short term for everyone, but a net win in the long term for everyone. Microsoft has a lot of bad stuff coming their way, for good reason.
npm is currently a security nightmare, so while it provides a ton of useful functionality it also goes to Gitlab's position on the security of Microsoft products.
There may not be a "diversity and inclusion" requirement, but I wonder if using an alternative OS could be considered reasonable accommodations in disability law? I'm totally blind and interviewed at a startup and when I told them I needed a Windows machine for accessibility reasons they decided it wasn't worth having me do the take-home coding project. At that point I decided if they were going to refuse to make what I consider a reasonable accommodation I'm glad I found out before wasting time on a take-home project. If the job was IOS development, then they'd have a point, but it was all back-end work that could just as easily be done with WSL under Windows as Mac OS.
> Due to Microsoft Windows' dominance in desktop operating systems, Windows is the platform most targetted by spyware, viruses, and ransomware.
Consider linux dominance on end-users devices through android and embedded systems like smart tv's. There are more instances of linux running and being used right now by end-users than windows. UNIX legacy and a long maturation process on HPC and servers probably has to do with how linux systems evolved to be so secure today compared to windows; also because of "bad-habits" windows historically brings.
It may sound cheesy and although I'd like to see linux more used on the desktop, I'm pretty happy with the current situation.
A company forbidding the use of Windows (and more broadly Microsoft products/services) would be a huge green flag to me. I don't even care why. I would miss VS Code though.
Allowing (especially encouraging?) Linux is a huge green flag for me. I personally don't care if they also allow others to use other OSes. If the company can support the systems and they can interoperate with me, it's fine with me.
Going to an anti Microsoft shop sounds good on paper, then you find out garbage like Miro and Confluence is the replacement for office and you change your mind...
Avoiding Windows operating would be an ethical choice going forward, in my opinion. Windows has become a bloatware; it's a memory hog - no amount of RAM is enough. And to top if off, with every update, your hardware becomes obsolete because it lacks a fancy chip.
With Office products being increasingly accessible via the web browser, I think corporations should really start thinking about weaning themselves off Windows.
Google did this 15+ years ago, and while the transition took a couple of years, they never looked back. Productivity shot up for all the usual reasons.
I run docker desktop on my windows machine which I have setup for k8s and have gitlab running as a helm deployment. What's wrong with having windows but using WSL for dev work. That's how most of my flow works, I installed gitlab this way because I want to learn its cicd stuff without having to rely on the work instance or gitlab.com. I prefer selfhosting.
Given Microsoft’s history of severe vulnerabilities, I welcome this news for any company. Apple and Ubuntu have enough popularity and support options making this policy completely supportable. If not Ubuntu, IBM Red Hat seems to be a great alternative as well. At this point it is clear that Microsoft’s monopoly is over.
I am curious about the M1 max for the top performing configuration, wonder if there is a business need for it over an M1 pro with the same storage and memory. Especially since they are mentioning the few hundred dollars a windows pro licence would cost as a reason not to get windows laptops.
Blasphemy!! I hope you got out of the way of the lightning bolt that surely came to strike you down for such preposterous speach! That's like saying "I don't need that 4TB SSD, 512GB is plenty"
Exactly, is hard to get really high memory usage pressure with 32gb and only by running containers with docker for mac latest engine. Sure, it would try grab as many GB as you set in its configuration but you won’t actually get high memory usage unless running something like a dozen of KinD clusters with worker nodes all at the same time
Having to use a Windows laptop for work is the main reason I rejected working for Microsoft. Don’t get me wrong, it’s a great OS, but not for me and I just couldn’t bring myself to using it. I get their logic to have engineers use this, but it was a great dealbreaker for me.
"macOS is preinstalled on Apple computers and Linux is available free of charge. To approve the use of Windows, GitLab would have to purchase Windows Professional licenses, as Windows Home Edition does not satisfy GitLab's security guidelines."
Gitlab OpenSource is one of those software that I wish would go the way of LibreOffice/MariaDB: I wish that some foundation took the good open-source part and forked it to implement a real, full, no strings attached open source application.
Most x86 hardware comes with Windows license already. If build your own, I bought a Windows 11 Pro license last week for $13. Cost shouldn't be an issue.
Me too, so many companies enforce windows only with no way to get a linux machine or a mac that it's great to see it playing differently, I can only hope things will change when a new generation who has never used windows will come in the workforce
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 functionalities can easily be done in a VM.
Since when does Gitlab(-CI) Provide a Compiler or OS Framework? Gitlab-CI allows you to execute commands in some form of defined environment (Container based, insite a VM or on bare-metal), They have to make sure the commands are executed in the order you defined, and the output is then shown in the WebUI. Everthing run is "random" cli-tool you "found" somewhere.
100% Agreed. The really aggressive "fuck Microsoft" rhetoric is going to burn a lot of these startups over the long haul. It's incredible to me the number that still seem to be operating in an ideological bubble that was originally created 2 decades ago.
A lot of Serious Business happens on top of Microsoft technology right now, and the companies responsible for tending to solutions in this space are made extraordinarily uncomfortable by this kind of aura being given off by vendors like Gitlab.
Can Gitlab really afford to alienate double-digit % of its TAM in favor of this ideological position? It seems like they are already having financial difficulties based upon other recent articles.
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 script.
GitLab doesn't outright ban Windows for any and all usages; you just can't run it on your laptop as the main system (although exceptions are allowed).
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 product.
Realistically - that's a bad trade. It is almost never the right decision to prioritize IT quality of life over basically any other business need.