Cysteine is susceptible to a variety of modifications by reactive oxygen and nitrogen oxide species, including glutathionylation; and when two cysteines are involved, disulfide formation. Glutathione-cysteine adducts may be removed from proteins by glutaredoxin, whereas disulfides may be reduced by thioredoxin. Glutaredoxin is homologous to the disulfide-reducing thioredoxin and shares similar binding modes of the protein substrate. The evolution of these systems is not well characterized. When a single Cys is present in a protein, conjugation of the redox buffer glutathione may induce conformational changes, resulting in a simple redox switch that effects a signaling cascade. If a second cysteine is introduced into the sequence, the potential for disulfide formation exists. In favorable protein contexts, a bistable redox switch may be formed. Because of glutaredoxin's similarities to thioredoxin, the mutated protein may be immediately exapted into the thioredoxin-dependent redox cycle upon addition of the second cysteine. Here we searched for examples of protein substrates where the number of redox-active cysteine residues has changed throughout evolution. We focused on cross-strand disulfides (CSDs), the most common type of forbidden disulfide. We searched for proteins where the CSD is present, absent and also found as a single cysteine in protein orthologs. Three different proteins were selected for detailed study—CD4, ERO1, and AKT. We created phylogenetic trees, examining when the CSD residues were mutated during protein evolution. We posit that the primordial cysteine is likely to be the cysteine of the CSD which undergoes nucleophilic attack by thioredoxin. Thus, a redox-active disulfide may be introduced into a protein structure by stepwise mutation of two residues in the native sequence to Cys. By extension, evolutionary acquisition of structural disulfides in proteins can potentially occur via transition through a redox-active disulfide state.

No abstract

No abstract

No abstract

SCADA systems allow users to monitor and/or control physical devices, processes, and events remotely and in real-time. As these systems are critical to industrial processes, they are often run on highly reliable and dedicated hardware. Moving these SCADA systems to an Infrastructure as a Service (IaaS) cloud allows for: cheaper deployments, system redundancy support, and increased uptime. The goal of this work was to present the results of our experimental study of moving/migrating a selected SCADA system to a cloud environment and present major lessons learned. To this end, EclipseSCADA was deployed to the NeCTAR research cloud using the "lift and shift" approach. Performance metrics of a unique nature and large scale of experimentation were collected from the deployed EclipseSCADA system under different loads to examine the effects cloud resources and public networks have on SCADA behavior.