>Do you believe rehabilitation is impossible or do you want revenge?
I don't believe that someone who commits mass murder can be rehabilitated, no. It isn't about revenge; it's about public safety.
Someone once pointed out that hoping a rapist gets raped in prison isn't a victory for his victim(s), because it somehow gives him what he had coming to him, but it's actually a victory for rape and violence. I wish I could remember who said that, because they are right. The score doesn't go Rapist: 1 World: 1. It goes Rape: 2.
What this man did is unspeakable, and he absolutely deserves to spend the rest of his life in prison. If he needs to be kept away from other prisoners as a safety issue, there are ways to do that without keeping him in solitary confinement, which has been shown conclusively to be profoundly cruel and harmful.
Putting him in solitary confinement, as a punitive measure, is not a victory for the good people in the world. It's a victory for inhumane treatment of human beings. This ruling is, in my opinion, very good and very strong for human rights, *precisely* because it was brought by such a despicable and horrible person. It affirms that all of us have basic human rights, even the absolute worst of us on this planet.
This is precisely why I lost all interest in Oculus the instant I heard that it had been acquired by Facebook.
What is concerning are the twice refuted efforts for RDRAND to bypass the Linux kernel pool mixing entirely, and the design decisions which intentionally make RDRAND an inscrutable black box and trivial for a VMM to intercept and modify. These are not accidents.
While there is no harm in using RDRAND to complement entropy on a system, by no measure should it be used as the sole source of entropy in a system.
I tried to mod your comment +"insightful"; alas, I'm out of points...
the stars must align for a clusterfsck this big:
1) polemic agitator in attendance, in propinquity
2) opportunistic exploitation of overheard conversation occurs, twitter shaming to ten thousand
3) polemic agitator doubles down with histrionic blog post when twitter shame draws doubts and disapproval (this would be a crime in EU)
4) overly sensitive, over reactive start-up employer over compensates with firing, leading to social media furor, fanning flames
5) classy apology asking for less nuclear resolutions ignites the firestorm, critical mass achieved
6) juvenile hordes exact retribution on employers servers, DDoS'ing to oblivion until terms met
7) capitulation to vigilantes in a sea of misunderstanding drives media to madness
"Are you really honestly claiming that, based on this one rare and isolated incident, that casinos all do good to improve their overall security by getting rid of their cameras?"
No, but the "security tools" they apply should also be considered as sources of risk in the overall risk management equation. Too often security products get a pass because, well, they're security products.
The witty worm is another favorite example of this position of privilege turned against you.
Your development background will be very useful in a QA / Test Engineer role, assuming you are considering joining a technically competent organization.
I say this because many companies have an antiquated view of "testers" as low skilled keyboard jockeys able to bang keys and input fields like monkeys on ritalin. Avoid these places like the plague...
A premium QA/Test Engineer will apply development and other solid technical skills to:
- Provision test systems spanning wide varies of operating systems, network configuration, applications and settings, in short: be able to build everything you need to test the systems tasked of you.
- Obtain a deeper understanding of the system under test; able to dig into code to discern logical errors and oversights, triage down to root cause and even suggest a fix/patch.
- Integrate test automation technologies into the software process so regression and performance testing is part of a continuous integration & test lifecycle. Manual testing should only be a part of your efforts, as software systems continually expand in scope and a manual-only test process will eventually be overwhelmed by progress.
- Extend and apply third party tools, ranging from code performance analyzers to network traffic capture/replay, code coverage analysis and unit test frameworks, fuzzers and chaos monkeys, etc.
- Understand security risks and defensive coding techniques to identify deficiencies in a code base or implementation/design which introduce vulnerabilities. Catching these defects before a product goes live is very rewarding and can be exceptionally cost effective.
- Develop internal tools or customize existing software using Shell, PERL, Python, Ruby, Java, C/C++, and other languages as required or appropriate for the task at hand.
- Communicate effectively with multiple stake holders in an organization: development, product support, marketing, administration, operations. These will all be interfacing with you and the ability to tailor the technical depth and nomenclature of your written and oral communications to each of these groups is critical to being an effective QA/Test Engineer.
And many other skills and capabilities I've not listed, depending on the context of your role in the group and the domain of the organization you work for.
Many people still consider QA a less important or prestigious occupation compared to other technical professions, like software development. While the prestige may be lacking, the job satisfaction of a competent QA/Test Engineer who applies development, operations, and security analysis skills to improve a product is significant.
The many varied resources you should incorporate into your tester toolbox is too long to list here. Many sites exist devoted to QA toolsmith / test automation / security analysis roles, and you're going to want some skills and tools from all of these specialties at your disposal.
Good luck! I hope you consider the switch; the world needs more competent QA/Test Engineers.
Just wait until we have matter compilers.
Except where I come from, we call them "ribosomes".
Yes; but knowing how to programming those matter compilers,
"Any medium of exchange is just as much a shared hallucination as bitcoin..."
commodity based you can at least barter with or consume; in general you are correct and we agree.
they all have trade off's. i'll take decentralized, secure (potentially anonymous) Bitcoin and fend off the hackers while others pay banking intermediaries high fees for transactions performed at their leisure, presumably with less risk.
to each their own...
"It has value because we pretend it does."
absolutely true!
fiat currencies are just as much a shared hallucination as bitcoin.
at least bitcoins may provide more privacy...
I haven't posted a journal here in almost three years, because I couldn't find the button to start a new entry.
So... hi, Slashdot. I used to be really active here, but now I mostly lurk and read. I've missed you.
SCADA systems are not designed, implemented, or operated with network and application level security concerns in mind.
(Usually. The exceptions know who they are
Your compensating control is physical security to limit access to SCADA elements and programming. It costs more, but you have no sane alternative.
And before you get too cocky about that restricted air gap, consider Stuxnet turning such a strength into a weakness for exploit. At some point SCADA systems will be security conscious; that day is not today...
So carry the keys on your keyring you need all the time. Your place, your girlfriend's place, your office, whatever. Your grandparents' garage key can stay at home, or in your car, or somewhere off your person until you need it.
Also, I used to carry a knife on my keyring as well, and a mechanic told me that it was bad for the ignition mechanism to have a bunch of heavy stuff hanging off the keyring. He might have been BSing me, but he said he was serious, so I followed the advice and took my knife off.
The cost of feathers has risen, even down is up!
