Openwashing: Users and Adopters Beware

jenwike writes: With the success of open source software today, we are seeing organizations undertake more egregious marketing and promotion schemes that exaggerate their participation in, contributions to, and/or licensing of open source software. Their hope is to capitalize on the label of 'open source' and the success that goes along with it. The reality is that the responsibility is on the end-users to review the software and accompanying license to ensure it meets your expectations.

Comments

Re:The End-Users most of the time don't really car

[BronsCon]

With Linux, this is a lot more difficult and requires more third party add-ons.

Only allow root to mount disks. Your users shouldn't have access to sudo, su, or the root login, anyway. Pretty simple, really; locate the mount binary for your system (/bin/mount is a good bet; if your mount binary resides elsewhere, you'll have to modify the commands below to reflect that), then do the following:

chown root:root /bin/mount
chmod 0750 /bin/mount

Done. Now, only root can even execute the mount binary, so only root can mount disks, and that will include flash drives.

It does get a little more complicated if you need to be able to mount network shares, but you should be able to add those to /etc/fstab and auto-mount them on boot.

Scumbags

[wiredlogic]

I've seen a few "open source" projects where the open code is out of date and nothing like what is shipped in the current binaries. That's a pretty scummy way to abuse the label.

Re:The End-Users most of the time don't really car

[Curunir_wolf]

it takes more manpower to configure and secure a network of 1000 Linux servers than it does a forest of 1000 Windows boxes.

No, it doesn't. I've done both (~820 Windows, ~900 Linux), and the Windows takes more administrator time. But then, the Linux servers were all Red Hat, so the "fees" really weren't any cheaper, but the vendor support was a hell of a lot better.

Take an admin task of blocking USB flash drives from desktops in receiving. With Windows, it is just creating an OU, creating a GPO, and pushing it out. With Linux, this is a lot more difficult and requires more third party add-ons.

I think you're mixing things, here. At first you were comparing server OS's, but now it sounds like you're comparing deploying Windows desktops to deploying Linux servers. Yea, guess what? Managing a monolithic single-OS environment is easier than a mixed environment. If you're deploying Linux workstations you can do the same thing with the right tools. And don't get me started on all the issues you're going to encounter using GPOs in a complex environment. It works better these days, as long as your desktops are all "Enterprise" editions and you don't have any XP or 2003 servers sitting around (then it won't eve work at all).

Or something as basic as performance monitoring. Windows has utilities (SCOM) which make it trivial to watch server performance via WMI. Yes, you can do the same with Splunk, but that doesn't come cheap.

Wow talk about admin resources - have you ever set up a functional WMI infrastructure in a secure network. To say it's non-trivial is an understatement. It's easier if everything is the same version, from a well-tested image, but there are all kinds of snafus that mean your connections don't always work or some functionality goes wrong. SCOM, frankly, is a house of cards.

Actually, I'm impressed with some of the functionality available using PowerShell and remoting in Server 2012 R2, especially being able to roll out a lot of headless stuff. But the learning curve for that, and getting the tools in place for what you want to do, is a major undertaking. Maybe after a few years with it I'd be able to do the same things I do with bash scripts now, but it seems a lot more verbose to me.