Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Submission + - White House Withholds Cyber-Security Order for Further Revision

Esther Schindler writes: President Donald Trump withheld an executive order on cyber-security that was ready for his signature leaving the Washington IT security community wondering what changes he intends to make," writes Wayne Rash at eWEEK. Rash goes on to look at each of the proposed items in the government's cybersecurity order, and how feasible they'd be to implement.

Apparently someone with security knowledge has been involved in the revisions so far. Rash writes. "The new EO also speaks clearly about the need to modernize the U.S. government’s antiquated data systems, to keep software and systems updated and to make sure the latest security practices are followed. The order also requires full assessments of government agency's cyber-security status and to report it to the White House."

The proposed EO's latest revisions also discusses risk management in detail and it discusses the risk of outdated systems:

The draft order says, “Known but unmitigated vulnerabilities are among the highest risks faced by executive departments and agencies (agencies). Known vulnerabilities include using operating systems or hardware beyond the vendor's support lifecycle, declining to implement a vendor's security patch, or failing to execute security specific configuration guidance.”

The problem with the approach is that it comes from a President who continues to use an older, unsecured, Samsung Galaxy cell phone on a constant basis despite having been provided a secure smartphone like the one used by his predecessor.

And, of course, we've no idea what will happen to the EO before any final revisions are made. Interesting reading, in the meantime.

Comment Re:Some good points. (Score 1) 269

Oh absolutely, yes: Quite a few have become very good, and regularly correct me. This is how I learned, too. Just as a great programmer knows that the code isn't done when it works -- that's when you start -- writing doesn't end with the first draft.

Verbal advice is ephemeral. It's easy to not-notice something said in passing. And while there have been situations in which I learned at a master's feet in person -- particularly when he didn't realize he was teaching -- the grunt work of getting better at my job is a processing of making small improvements. So the opportunity to see, on the page, how someone changed the text, and why... that lets me compare before-and-after at my own pace, without anyone standing over me.

Needless to say I'm still close with those who mentored me and with those whom I've mentored. But "how to mentor" is, perhaps, a different discussion.

Comment Re:I get it. (Score 1) 269

> The whole idea is a pretty radical change from the established order. Better tools need to be built. Better protocols need to be in place more consistently. Better practices need to be thought up and deployed, because the state of it now is objectively bad at the corporate level.

I'm interested in what changes you feel need to be made to improve the process, particularly if I left them out of the white paper (to which the article linked). As you may imagine, the topic is one that interests me greatly.

Submission + - The real reasons companies won't hire telecommuters

Esther Schindler writes: Those of us who telecommute cannot quite fathom the reasons companies give for refusing to let people work from home. But even if you don't agree with their decision, they do have reasons — and not all of them are, "Because we like to be idiots." In 5 reasons why the company you want to work for won’t hire telecommuters, hiring managers share their sincere reasons to insist you work in the office—and a few tips for how you might convince them otherwise.

Submission + - Making one-on-one meetings actually USEFUL

Esther Schindler writes: All too often, managers and team members reject a regular check-in because they think it's a waste of time. But when done well, one-and-one meetings are a great way to build trust and rapport. That weekly time slot is a predictable time for feedback and coaching. Even when a manager and team member get along well, a regular one-on-one is an opportunity to impart information privately, to raise emotional issues before they fester, to address career challenges, and to help managers make better decisions with team input.

But way too often, those manager-and-team-member meetings are a waste of time. Here's three ways they go wrong.

Submission + - 31 Ways to Know Your Project is Doomed

Esther Schindler writes: We've all been there: The project went horribly wrong. Nobody was happy with the application or product (if it ever did ship). And you're ashamed to let anyone know you had anything to do with it. Especially since, with hindsight, you realize that the Signs Of Doom were there all along, and you missed them. When THIS happened, you should have known....!

This article shares 31 project danger signs you should recognize, so you can decide if it's possible to fix them or bail. But oh, we can be so certain that there are plenty more to add...!

Submission + - Don't be fooled by Opera browser claim of 150% battery life (

richi writes: The Opera Web browser has a new 'power-saving' feature. Opera claims you can get 'up to' 50% more battery life — but is that likely? Uh, NO!

Yes, the actual software tweaks will make a difference, but the tests Opera's quoting are skewed, unscientific, and compare apples to oranges. But what do you expect from a company that's trying to get bought by a Chinese consortium for more than $1.2 billion?

Submission + - Would YOU Fire This Person? (

Esther Schindler writes: If “Tracy” were on your team, how would you handle her?

Among a project manager’s most painful tasks is firing an employee. Nobody enjoys the experience, even when the employee clearly deserves to be booted. But it’s much worse when an individual is a drag on the team, not a complete failure. Few of us are certain when it’s time to say, “I give up. I must get rid of this person.”

It’s an age-old management dilemma, but we can all learn from the way other people handle such situations. Here’s the story of a real team “problem child” and the troubles “Tracy” caused her manager. You get the opportunity to decide what you would do if you were the project manager. Then you can compare notes with other managers – before you learn how the story really ended.

Submission + - Things Sysadmins and Developers Would Change About One Another

Esther Schindler writes: Even in the best of organizations, the development and operations departments have friction. Each has its own goals, metrics for success, and team culture. Plus, ops is in the business of making things predictable and unchanging, while developers are in the business of changing everything. Those opposing priorities make it harder for dev and ops to communicate freely. Despite the industry’s ongoing efforts to bring the communities together, developers continue to grumble about ops, who simultaneously grumble about devs.

Grumbling doesn’t help to resolve the tension (or desire to throttle someone). Understanding does. So both developers and sysadmins were asked to imagine that they were granted a single wish: You have the power to give your company’s [ops team | development team] an understanding of one thing — just one thing — that currently irks you. What spell would you cast with that magic wand?

The results are in two articles: 3 Way Ops Can Help Devs: A Developer Perspective and 3 Ways Devs Can Help Ops: An Operations Perspective. Maybe it's not surprising that the shared component is: Listen to each other more. Share what you're up to, and what the goal is. (Kumbaya optional.)

But maybe some of the specifics can help you grok where the other folks are coming from. For instance:

As a developer named John writes, “Software development sometimes needs to be allowed to bend the rules/regulations in order to operate efficiently/quickly. Too many times, the rules (e.g., who has access, when, what can be installed, etc.) cause ridiculous delays in cycle time for development or support.”


A classic example is when developers assume always-on connectivity. “The network is not a static monolith that never changes,” one ops staffer noted. “We’re planning a data center network upgrade. It will require disconnecting every server and reconnecting them to the new switches.” That could cause some apps to think the entire world has ended and crash in an untidy heap.

Would you have included different magic spells?

Slashdot Top Deals

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.