Grub2 zero day bug - Hit backspace 28 times...
|
|
if they can get to your console you have more problems than that
The juniper bug is more frightening http://www.engadget.com/2015/12/17/juniper-networks-finds-backdoor-code-in-its-firewalls/ backdoors are not a good thing always look out for number one and don't step in number two |
|
Been there for a while longer than 2012
http://www.theregister.co.uk/2015/12/17/juniper_screen_os_contains_unauthorised_code/ on The Register's reading of the situation, the unauthorised code may have been present since 2008, an assertion we make because Juniper's notice about the problem says it impacts ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20. ScreenOS 6.2 was released in 2008. Screen OS 6.3 came out in 2009. |
|
Red China is behind it.
Juniper 'fesses up to TWO attacks from 'unauthorised code' For what it is worth, The Register has been contacted by a former Juniper staffer who suggested “Maybe you should be looking where Juniper's sustaining engineering is done for the ScreenOS products.”Product code from Chinese developers? Give me a break! Not that they can't substitute code as the product is manufactured. Alex "There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that "my ignorance is just as good as your knowledge." -- Isaac Asimov |
|
Well, Netscreen was Chinese. Maybe someone got creative with git...
|
|
Well, damn!
Open source has a serious problem if there is no one doing code review. Alex "There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that "my ignorance is just as good as your knowledge." -- Isaac Asimov |
|
Somebody needs to pay for it. :-(
|
|
ESR was wrong
And this, and heartbleed, and the other long-standing vulns in open-source apps, all prove it. It's simply not true, for complex systems, that with sufficient eyes all bugs are shallow. You need the right people looking for the right things. And yeah, that shit ain't free or even cheap. |
|
It's the high notes
http://www.joelonsoftware.com/articles/HighNotes.html If your soprano can't hit the high f, you don't solve it by hiring 5 more sopranos who also can't hit the high f. -- Drew |
|
Yeahbut...
NPR, a few days ago: DYLAN MINOR: Thank you for having me. I've not read a lot of Joel, but each piece I remember rubs me the wrong way like this one does. He writes as if he has found some great simple truth that the huge successful companies out there don't recognize. But his great simple truth is either a truism or is something that really isn't true in general. His first paragraph doesn't even mention customers for his "software that works". It sounds like supply-side nonsense (and we know how well that worked out for the economy as a whole). Hiring great productive programmers is fine - who wouldn't want to do that? But if they're all jerks who can't work together or who make lives miserable for people who have to work with them, then it doesn't matter if they write working code 50% faster than their peers - they company will fail anyway. Or if hiring great productive programmers that cost 3x as much as hiring good, productive, flexible people who can learn to be great productive programmers over time - is the most expensive option automatically the best choice, especially long-term? It must have been nice for him to have the time and freedom to write 15,000+ character posts like this so often. I wonder how he rated its effect on the bottom line... :-/ FWIW. Cheers, Scott. |
|
Some insight, some questionable strategy
I agree that a pile of mediocre programmers will never do what one great one does. That's the part that applies to security/encryption. Does that make it the best way to build your software company? Less clear. He wouldn't be the only person, though, saying that starting with great people is the best predictor of the success of a startup. For large, established companies, the toxic worker is a real problem. When you've only got a half-dozen programmers, and they mostly work independently, productivity probably trumps cooperation. -- Drew |
|
Here's the thing:
Toxic workers may be highly productive, but that doesn't mean that highly productive workers are toxic. I've worked with one of the toxic, highly productive ones. The negative, poisonous effect of these people on the other people in the company cannot be overstated, but they're loved by management because of the apparent productivity. Regards, -scott Welcome to Rivendell, Mr. Anderson. |
|
had one of those at a previous place, my last job as an FTE
Great programmer, toxic as fuck had glaring ignorance about pieces of stuff that cost the company but shouted heartily and beloved by the management clique. I could deal with him but a lot of equally good people left because of him. always look out for number one and don't step in number two |
|
There is a connection, though
An overabundance of confidence leads to productivity, and to being an asshole. Most of the managers I've worked with prefer "decisive and frequently right" to "methodical and rarely wrong". I'd like to say that's the wrong choice, but how do I know I'm not just favoring my own personality? [edit: tyop] -- Drew |
|
team the two tegether, that gets all of the I's dotted and leaps of faith dissected
always look out for number one and don't step in number two |
|
I know more highly productive people who aren't toxic, however.
I've just worked with the one, but he was enough to give me PTSD for years afterward. Regards, -scott Welcome to Rivendell, Mr. Anderson. |
|
Think about it from management's side
They only deal with developers at the beginning and end of a project. In the beginning one guy sounds confident and decisive, the other keeps talking about problems and challenges. Some time later the first guy says it's ready for pilot and the second guy says he still has questions about requirements. I really don't need to flesh this out any more to make the point, do I? What I can't decide is whether the first guy might be right. Fail faster ... Release early, release often ... Minimum viable product ... We talk about doing the smallest thing that could possibly work, but when someone tries to go faster than we're comfortable with, they're reckless and overconfident. -- Drew |
|
Different situation with this guy
He wouldn't work with anyone unless they did exactly what he told them to, started major projects completely by himself without the Chief Software Architect (me) even knowing about them, and so on. Fail faster at this place meant hours of downtime on a Monday where each hour had at least 7 digits attached to it. Regards, -scott Welcome to Rivendell, Mr. Anderson. |
|
But what about small teams?
Remember I started this from Joel's post about getting the best developers at a very small company, where each person might be working on a project solo. In those cases maybe you don't care so much about personality and teamwork. As for always doing things his way, which is better: a half-dozen people spending several days trying to reach a compromise on the best direction, or that same group all going in a reasonable direction set down by the most forceful personality? Obviously someone should see those expensive Mondays you describe and do something about it. But with enough prior reputation someone could survive one or two of those as the cost of being aggressive. -- Drew |
|
You do care about it.
Because small companies become (hopefully) big companies, and by that time the asshole is too deeply ingrained to get rid of. And now that the company is big, his asshattery is causing bigger, more expensive problems, and he isn't (supposed to be) working on solo projects any more. Regards, -scott Welcome to Rivendell, Mr. Anderson. |
|
One could argue that you should care *more* in small company cases.
While the potential damage may be greater in a larger company, in that case you have the potential to "route around the damage" by, say, getting other managers involved. When the company is small, each piece has relatively more of the company resting on it. Cheers, Scott. |