My experience didn't match that, but I think mine was a bit unique. We where a DEC shop and where going to switch to NT. DEC and Microsoft engineers descended on us after somebody in management agreed to go that route, but they took weeks trying to get the software installed and working. I still remember the two engineers in the next cube claiming the other's company was at fault. They had a heck of a time getting all the hardware (video and network) to match the drivers and actually function and neither really knew why what they had didn't work. Of course this was all going on during what we call "beta" test time. I think we tossed them out the door after two weeks of flailing. But that's what I remember it to be like.

Glad to hear they got it working for somebody though it never did for us.

Are bound to repeat it. (And those who do know history are doomed to watch helplessly while others repeat it).

Didn't Microsoft try this with NT? I recall that it had a DEC workstation Variant (Not that it worked all that well.)

My guess is that all the people who understood why this effort failed so completely are now gone and few are left who remember the lesson learned for Microsoft in that boondoggle. So the young bucks are now in the process of repeating the history they don't know. They will get *some* market share, but for the price sensitive user, Linux will be a better option for ARM because going to ARM only makes sense for large sized installs. Large installs have huge license costs and start to look cheaper on Linux, even with the management costs being more.

My guess is that this won't go well for Microsoft, but if they want to shoot themselves in the foot again, so be it. Personally, I'd not want to poke the Intel bear too much if I was Microsoft.

I'll bet that's not true...

Seems to me that the stuff I work on keeps getting bigger and bigger, as does my collection of digital pictures and videos. Where I attempt to pare down what I keep, some of it stays around...

I expect that most users do the same things and thus data keeps piling up. I don't think it matters how well you are at deleting stuff you don't need anymore.

Work around existed, nobody ever fielded in a configuration that was subject to the problem, so this was LOW risk. If you are working more important issues, LOW risk stuff gets to wait.

That's how.

Then too, it may be that Cisco's development lab is really just there to run test software loads. I imagine that they are using TFTP and TELNET for this purpose. Oh the horror! (sarcasm off)

Where I don't disagree with you, I'm not ready to dump on somebody who chooses to use TELNET for what ever reason. IF they understand the risks and knowingly choose to do it anyway, it's their equipment and their call. You and I might never choose to do it this way, but neither of us are involved so it's not our choice.

Don't misunderstand me, I'm not advocating TELNET. I'm just not ready to condemn someone for using it for legacy reasons in situations where security is not a huge concern.

Security is really "risk management". This means that you must weigh the implementation costs and consider the risks. Remember that the ONLY secure system is one that's powered off and not plugged in. And then, it's only as secure as the physical security makes it.

In a closed network, like in a development lab, I can imagine that there isn't much risk and running SSH may not be worth bucking the legacy. Who really cares? They are likely using TFTP to load test software images and test configurations anyway, TELNET is the least of their worries if they have a network security concern.

Of course YOUR situation is likely different, as is your assessment of risks and mitigation. Where I would recommend using SSH under almost all situations too, I'm not gong to dump on somebody who chooses to take the risk of using TELNET, especially if they really understand the risks as I'm SURE Cisco does. They decided that TELNET fits their costs/risks assessments, and it's their call.

TELNET is just the default way to access the equipment. It comes out of the box that way (OK, not really but it's the default way to set up). Think of it as a legacy thing.

There is nothing wrong with using TELNET on a private network but today we understand that security is better served using SSH for this functionality. However, in some environments, legacy dies hard because TELNET is not really that much of a security risk if you have good control over who accesses your network.

Sharing passwords and logins may seem to be a problem too, but again, there can be times when the costs of managing all the necessary accounts out weighs the risks. If you have positive controls on who accesses your network, that may be enough, for you.

Of course, the level of acceptable risk can vary between applications and companies. For your network, what Cisco does in their lab may be totally inadequate on many levels, or it may be overkill having to remember the "cisco" user password. It all depends on what risk is acceptable and what isn't to you.

It should hurt..

However, if memory serves, I think that Cisco provides SSH access and allows you to disable telnet. Even then, suggested practice was to put all your network hardware consoles on a private VLAN and firewall it from general access... So it's understandable that it took some time to fix this given there are multiple work arounds.

IMHO... Your opinion is still wrong and your argument inappropriate as it doesn't address the issue at hand..

My apologies. I was not intending to offend you by incorrectly imposing a specific sexual identity on you. Please OMIT the word "sir" from my previous post. However, you are increasingly nit picking on non relevant issues, which IMHO says to me that this debate is pointless as you insist on beating around unrelated bushes...

Until next time.....

You still haven't presented a valid argument, you are just arguing I don't know what I'm talking about because of some minor wording issue. I already knew some people get paid, some people don't, and said so. You think I should have said "MOST" when I said "FEW" and because of that difference I don't have any creditability here?

You sir are nit picking, while not addressing your real objection. What's that argument technique called? Oh yes.. A red herring fallacy, ad Hominem argument known as Poisoning the well – where adverse information about a target is presented with the intention of discrediting everything that the target person says.

You have a good weekend, and I'm done with this thread.

Shesh.. Really? Yes, I knew Torvalds gets paid and other developers are paid to contribute... .

Perhaps there would be more volunteers who are not paid by others if Torvalds would knock off his management rough edges?

I think my point still stands..

I think you have captured my feelings on this fairly well. I'm certainly NOT trying to say Torvalds has totally messed things up or even that I think I could have done better. But I am saying that his management style is sometimes too abrasive and often way too public. I think this has had a chilling effect on the pool of prospective contributors and has contributed to a less than optimal culture on the kernel project and you point to some examples of this. His projects have likely suffered from this. Not that the Kernel isn't successful, only that the project could be managed better.

I'm hoping that Torvalds' admission of this "biggest" mistake can lead to improvement in his style and the culture of the projects he manages, for the betterment of the projects in question...

OK, I'll bite.

As a bit of background, I've worked in the software industry for nearly 25 years. I've been involved in many development projects, some successful, some failures. I've worked with and for a lot of different people. I've observed what works well, what works, and what doesn't, and I've taken note of why the projects I've worked on either failed or succeeded. What management styles are most effective and succeed more often and what styles to avoid. What makes a team more effective and what destroys otherwise good teams.

From this experience, I can tell you that certain management styles are generally more successful. Such styles build collaboration and cooperation between team members, which leads to the team being more productive. Management (which Torvalds is in this case) does more than just guide the technical solution, they also set the tone for the team, they manage the culture of the project. How they treat team members has a great impact on the productivity of the team and the productivity of the team can be more important than the technical solution on determining the level of success of a team.

In "free" development projects, developers are really donating their time (usually). For example, few kernel developers get paid for their efforts. Who would want to donate their time and risk being publicly reprimanded? I suppose there are a few, but the universe of prospective team members gets smaller and thus the active contributors in your project is more limited. It's simple to understand why.

Also, one more time, just in case you missed it... I am not claiming to be *technically* as qualified as Torvalds. Now I've never seen a C or C++ program that I couldn't figure out given enough time, so the Kernel code is not beyond my capabilities, but I fully understand that Torvalds has decades experience with this project, it's why he's the leader. (Well that and he holds the trademark..) So do NOT misunderstand me. I am not saying I would or could be better than Torvalds or that I would want to take his job because I could do it better. What I'm saying is that Torvalds could be doing better.

So, in a way, I'm agreeing with Torvalds, his biggest mistake is how he treats his team. And I'm asking him how he intends to do better. Because I think (and my experience tells me) that this mistake has harmed his projects by producing a less than optimal culture on his teams which leads to less than ideal performance. PLUS it has discouraged many from even trying to help given his projected public persona.

That assumes that I'm as good as Linus technically and all other things are equal. Neither of these assumptions are likely true. He already has the name recondition, I would have none. He has the technical experience with the kernel, mine is limited. So your test isn't exactly apples to apples.

But I think it's clear, there has been a lot of people who simply didn't want the drama of working with him and I'm betting that over the decades some of these people could have been valuable to the project. Seems obvious to me, but you are free to be wrong about it..

You want to encourage exploration/exploitation of space? Fund NASA and point them in the desired direction..

Fully fund a manned mission to Mars and set a 10 year goal. Dig up a pile of past interplanetary missions and let's start funding them too. Saturn and Jupiter all have possibilities that we need to go look at. How about making a survey of near earth asteroids? What are they made of, is there something there we can use, refine or utilize so we don't have to get it all off the surface of the earth and into orbit? NASA has already suggested all these things and more.

Why are you asking the public for ideas, just FUND NASA and let NASA collect ideas and run with the good ones. All they need is the money....