Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment Virtualization may be your answer (Score 2) 98

We had a similar issue with our engineers. We had login servers which worked great as they were poorly advertised and woefully underused, but once we had a system in place for them to make efficient use of them, they started to randomly crash. Most times it was due to them trying to submit a job to our compute farm and end up running it on the login servers, but sometimes it was malicious and a deliberate attempt to get a few extra CPU cycles at the expense of others. For us, the solution was rolling our own virtual desktop farm. We used KVM for the hypervisor, python for the back end control, and php for the front end web interface. We used Active Directory for authentication and rights management. That way we could control precisely how much resources each engineer had rights to.

As you are working at a school, it is not without reason to believe that you can use the students to help develop a system to manage the virtual instances. With a bit of forethought and a limit to the specifications, you can have a simple VDI broker developed and tested in a month. And if you avoid my mistake and use the libvirt API, you will even have the ability to easily expand the system to using linux containers.

Comment Re:Haven't cared in 5 years, don't care now (Score 1) 108

We officially rolled out centOS6 earlier this year, and we were hit hard by the transition from KDE3 to KDE4. In the end all we could do was either recommend that users either go to gnome, or switch to Trinity (KDE3 fork). I expect that we'll have similar challenges when transitioning to CentOS7 in 2 years unless KDE4 was fixed in CentOS7, except then we'll have challenges with both KDE4 and Gnome3.

Don't sweat it -- it's only ones and zeros. -- P. Skelly