Intel co-CEO Michelle Johnston has asserted that Snapdragon-powered laptops are affected by high return rates. Although there is an absence of hard data on the matter, it is hard to deny that ARM-based Windows PCs have a long way to go before being considered a match for the market dominance by x86. Update: Qualcomm has responded
Same.
I honestly don’t think this issue has anything to with our staff, but our corporate policies. Users can’t even install an alternative browser, which is why our devs only support Chrome (our users are all corporate customers).
My issue has less to do with Windows (unacceptable for other reasons), but with lack of admin access. Our IT team eventually decided to have us install some monitoring software, which we all did while preserving root access on our devices.
I would honestly prefer our corporate laptops (ThinkPads) over Apple laptops, but we’re not allowed to install Linux on them and have root access because corporate wants control (my words, not theirs).
I don’t know your setup, but I probably wouldn’t like that, because it feels like solving the wrong problem. If compile times are a significant issue, you probably need to optimize your architecture because your app is probably a monolithic monster.
I like cloud build servers for deployment, but I hate debugging build and runtime issues remotely. There’s always something that remote system is missing that I need, and I don’t want to wait a day or two for it to get through the ticket system.
Customer data shouldn’t be on dev machines. Devs shouldn’t even have access to customer data. You could compromise every dev machine in our office and you wouldn’t get any customer data.
The only people with that access are our devOPs team, and they have checks in place to prevent issues. If I want something from prod to debug an issue, I ask devOPs, who gets the request cleared by someone else before complying.
I totally get the reason for security procedure, and I have no issue with that. My issue is that I need to control my operating system. Maybe I need to Wireshark some packets, or create a bridge network connection, or do something else no sane IT professional would expect the average user to need to do, and I really don’t want to deal with submitting a ticket and waiting a couple days every time I need to do something.
Exactly, but that’s what we had to tell IT so we wouldn’t have to use the standard image, which is super locked down and a giant pain when doing anything outside the Microsoft ecosystem. I honestly hate macOS, but if I squint a bit, I can make it almost make it feel like my home Linux system. I would’ve fought with IT a bit more, but that’s not what my boss ended up doing.
We run our backend on Linux, and our customers exclusively use Windows, so there’s zero reason for us to use macOS (well, except our iOS builds, but we have an outside team that does most of that). Linux would make a ton more sense (with Windows in a VM), but the company doesn’t allow installing “unofficial” operating systems, and I guess my boss didn’t want to deal with the limited selection of Linux laptops. I’m even willing to buy my own machine if that would be allowed (it’s not, and I respect that).
If our IT was more flexible, we’d probably be running Windows (and I wouldn’t be working there), but we went with macOS. Maybe we could’ve gotten Linux if we had a rockstar heading the dept, but our IT infra is heavy on Windows, so we’re pretty much the only group doing something different (corporate loves our product though, and we’re obsoleting other in-house tools).
No, I’ve just had really bad experiences with IT groups, to the point where I just nope out if something seems like a potential nightmare. If infra is largely Microsoft, the standard issue hardware runs Windows, and the software group that I’m interviewing with doesn’t have special exceptions, I have to assume it’s the bog standard “IT groups calls the shots” environment, and I’ll nope right on out. For me, it’s less about the pay and more about being able to actually do my job, and I’ll take a pay cut to not have to deal with a crappy IT dept.
I’m sure there are good IT depts out there (and maybe that’s yours), but it’s nearly impossible to tell the good from the bad when interviewing a company. So I avoid anything that smells off.
Yet, I’ve pointed out several security issues in our infra managed by a professional IT team, from zero days that could impact us to woefully outdated infra. I’m not perfect and I don’t believe anyone is, but just being in the IT position doesn’t mean you’re automatically better at keeping up with security patches.
I’m usually the first to update on our team (I’m a lead, so I want to catch incompatibilities before they halt development), and I work closely with our internal IT team to stay updated. In fact, just Friday I asked about some potential concerns, and it turns out we were running into resource limits on devices hosted on Linux OSes that were already out of the security update window. So two issues caught by curiosity about something I saw in the code as it relates to infra I can’t (and shouldn’t) access. I don’t blame our team (they’re always understaffed IMO), but my point here is that security should be everyone’s concern, not just a team who locks down your device so you can’t screw the things up.
If everything is exactly the same, everything will be compromised at the same time, so some variation (within certain controls) is a good thing IMO. Yet top down standardization makes that implausible.
The company also pays me to write secure, reliable software, and I can’t do that effectively if I can’t install the tools I need.
Yes, IT professionals have their place, and IMO that’s on the infra side, not the end-user machine side. So set up the WiFi to block direct access between machines, segment the network using VLANs to keep resources limited to teams that need them, put a boundary between prod (Ops) and devs to contain problems, etc. But don’t take away my root access. I’m happy to enable a system report to be sent to IT so they can check package versions and open ports and whatnot, but let me configure my own machine.
I get your points. But we simply wouldn’t get along at all. Even though I’d be able to provide every tool you could possibly want in a secure, policy meeting way, and probably long before you actually ever needed it.
If the remote system is a dev system… it should never be missing anything. So if something’s missing… Then there’s already a disconnect. Also, if you’re debugging runtime issues, you’d want faster compile time anyway. So not sure why your “monolith” comment is even relevant. If it takes you 10 compiles to figure the problem out fully, and you end up compiling 5 minutes quicker on the remote system due to it not being a mobile chip in a shit laptop (that’s already setup to run dev anyway). Then you’re saving time to actually do coding. But to you that’s an “inconvenience” because you need root for some reason.
No. At least not in the sense you present it. It’s not just locking down your device that you can’t screw it up. It’s so that you’re never a single point of failure. You’re not advocating for “Everyone looking out for the team”. You’re advocated that everyone should just cave and cater to your whim, rest of the team be damned. Where your whim is a direct data security risk. This is what the audit body will identify at audit time, and likely an ultimatum will occur for the company when it’s identified, fix the problem (lock down the machine to the policy standards or remove your access outright which would likely mean firing you since your job requires access) or certification will not be renewed. And if insurance has to kick in, and it’s found that you were “special” they’ll very easily deny the whole claim stating that the company was willfully negligent. You are not special enough. I’m not special enough, even as the C-suite officer in charge of it. The policies keep you safe just as much as it keeps the company safe. You follow it, the company posture overall is better. You follow it, and if something goes wrong you can point at policy and say “I followed the rules”. Root access to a company machine because you think you might one day need to install something on it is a cop out answer, tools that you use don’t change all that often that 2 day wait for the IT team to respond (your scenario) would only happen once in how many days of working for the company? It only takes one sudo command to install something compromised and bringing the device on campus or on the SDN (which you wouldn’t be able to access on your own install anyway… So not going to be able to do work regardless, or connect to dev machines at all)
Edit to add:
We’re the same! But… it’s Firefox… If you want to use alternate browsers while in our network, you’re using the VDI which spins up a disposable container of a number of different options. But none of them are persistent. In our case, catering to chrome means potentially using non-standard chrome specific functions which we specifically don’t do. Most of us are pretty anti-google overall in our company anyway. So
This is fair enough.