that the slashdot crowd is completely oblivious to all the marches and protests (often violent) against globablisation having *anything* to do with the topic at hand.
Hmmm... yah. Can't be. Those inumerable people against globalisation must all be out of their minds.
Aside from making a good point, you definitely qualify for the best sig ever seen on slashdot (by me).
Or maybe I'm just too big of a Sartre fan. Who knows.
Re:It's nice
on
Immortal Code
·
· Score: 4, Interesting
you can't see microsoft code because you don't look.
Download the friggin DDK from their site, and they have working samples for almost all their core drivers.
Stripped of a license, the samples in there are as good as OSS.
And btw, they are nice cleanly coded samples. There is just as much pressure on programmers there to keep that code clean: it's in their DDK, and they don't want to show shody samples. So I'm sure the code review processes are just as stringent.
I've heard many things being said about Palladium, but have paid almost no attention whatsoever to them as of yet... mainly because this is still vapour-ware, and whatever is being said right now is most probably zealotism, or trendism (both of which I hate).
it's being criticized because it *does* what they claim...
So what is it that Palladium does that TCP doesn't do that's so bad for you? I've heard of Palladium doing curtain memory (which at least seems like a Good Thing(tm), but definitely is not a Bad Thing (tm) -- in the worst case a Useless Thing(tm) ), I have also heard that Palladium is *not* DRM.
So what's it to you? why are you complaining? Enlighten me, oh gods of OSS.
His company recommends to architects and builders that they take steps like those recommended by Mr. Blaze, measures that make it more difficult to cut extra keys -- like using systems that are protected by patents because their key blanks are somewhat harder to buy [...]
I find it interesting seeing that security by obfuscation is a prevalent concept throughout mankinds realm. I guess it is nurtured by the ostrich-sticking-head-in-sand effect of thinking something doesn't exist if we're not aware of it.
It also makes me laugh how newspapers always skew stuff for sensationalism: now terrorists are one step closer to the US. They are pounding on the gates! WATCH OUT!!!. I think this security whole is mostly going to be used by 16 year old K-Mart workers.
Anyways, very nice article in the end, and hats off to AT&T for having 'brass hats'.
Re:Life Without the Internet - similar...
on
Ask Kevin Mitnick
·
· Score: 5, Interesting
I've seen many intelligent people get enraptured in computers, and eventually come off of the high. I am one of those people too, and despite the fact that I've made a career out of it, I've had days where I cought glimpses of another life in which I would only have the crudest computer access, and manage to be happy.
Did spending an extensive period of time away from computers make you realize that you might just move away one day? or are you still fascinated like the first geek was?
Let me put it this way... there are three things microsoft has done very well, regardless of whatever anyone here would admit:
MS SQL 2000
MS VC
Windows NT kernel
The NT kernel is good, it's stable. Security compromises on the Windows platform mostly come from user mode applications not behaving while they're under power (under the system or admin accounts).
There is no point whatsoever to make such a retarded move. If anything, I'd like to see an OS Xish shell on top of the NT kernel.
What they're probably trying to avoid is competition making them look bad by publishing benchmarks, or whatevers that show they are worse than said competition.
I really doubt they actually care of custommer base writing reviews - that has very little credibility. Norton, on the other hand, saying NA is no good is something to think about (for some).
>kernel programming, and kernel optimizations are very much a black art, rocket sciene, or voodoo
It isnt really. Its quite well understood. Its just there's lots to it - which means most of us will never be able to understand all or even a part of modern highly-featured kernels. But there's nothing magic about it.
Have a sense of humour. Of course *nothing* is magic. I was just making a point that it's beyond the programming most people learn in CompSci because it's so specific in nature. But on top of the sheer breadth of knowledge necessary, kernel mode programming has some fundemantally different ideas that aren't present in user mode programming. So it's not just the quantity.
Well, i dont really know much about the NT kernel. So originally your point was it was so reentrant, depending on the level. Now you've qualified that to say that many functions cant be called if irq level is elevated - hence nullifying much of that supposed reentrancy.:)
You're playing with words, it would take me far too long to explain the intricacies of what this means... And I'm not even an expert on the matter.
See my last comment about this not being a place where such conversations would hold water.../. is essentially a bar where people meet and talk after hours over a few beers. If you really want to learn about the re-entrancy issues, read a few books about it... an 'insightful' post isn't going to cut it.
And last but not least:
So come up with some benchmarks.:)
I *refuse* to come up with benchmarks in order to explain my dislikes about benchmarks. It's like saying to a movie critic, "hey, go and shoot a movie to explain yourself". Stop being defensive and viewing it as a race between good and evil. It will actually do linux more good in the end if people are critical, and don't cave in to what IBM might have to say that might just be the beginnings of a Microsoft style skewing of numbers. Because, heck, I'm positive this whole article would have been viewed in a completely different perspective had it been Microsoft posting its results.
So show me a recent benchmark that backs up your claim
My claim isn't really about NT. What I was saying about NT was just an FYI for the chearleaders.
My claim was that this article, despite it's title (HT Speeds Linux), wasn't really showing any proof that linux itself was going faster.
Obviously applications which use multiple threads are going to go faster on an HT machine, (the kernel would have to be really bad for that not to happen). But the article's numbers didn't show any speed up in linux itself. Which was my point, and the article itself, IMO, backs that claim.
Another thing is that the NT kernel might be re-entrant, but the rules of IRQL still hold... there are many functions that can't be called at elevated IRQLevels. So, it's not as complicating the kernel as you might think.
One last thing, the general point I'd like to stress is that kernel programming, and kernel optimizations are very much a black art, rocket sciene, or voodoo. It's very hard to assert whether spin locks are enough overhead to not be justifiable. And I think those kinds of discussions are way beyond the scope of this forum.
The bottom line is this article, IMHO, was a piece of self serving specialized benchmark put out by IBM (what's so hard to believe about that?), and despite the fact that it's linux that's being talked about, I still find the numbers to be skewed to the profit of the publisher.
Thank you for probably the only rational post I've seen so far.
Well, I agree with you, over the years, the gap will probably slowly close. With kernels, really, much more than the kernel, it's all the parafanelia that counts. The countless drivers that have, or have not been designed with pre-emtability - and interruptability in mind.
Even if the kernel is modified completely overnight, it will take a few years for the whole kernel mode system to catch up.
Bottom line is, and given that this benchmark comes from IBM it really doesn't surprise me, there isn't much there to see *yet*.
the NT kernel is fully pre-emptible, fully-interuptible, and re-entrant by design
Care to explain what these mean?
I'll explain to you what this means:
it means a piece of hardware raising an interupt will launch a driver's ISR, hardware wise, at that point, any other hardware raising an interupt at a lower IRQ level will not be serviced. BUT, any higher IRQLed hardware can take over of that 'thread' that is servicing the first interupt. There are *no* exceptions to this rule. In effect, your ISR is fully interuptible.
The thread dispatcher runs at DIRQL (D=Disptach), any IRQL higher than DIRQL is kind of beyond the concept of threads. But any thread running bellow DIRQL (ie, APC or normal threads) are fully pre-emtible. There is no thread that has *any* priority of not being pre-empted anywhere in the system.
All of the kernel is also re-entrant, which means from anywhere within the kernel, so long as you are in proper IRQL, you can call back the kernel.
At these altitudes, or depths, whichever you wish, there are many strange beasts that you've never heard of - or never had a reason to really use - that are being used to do synchronization. Namely spin locks. Moft came up with queued spin locks a few years ago, and that was a rather Good Thing (tm). It made spin locks so much better under SMP systems.
Now, to all the posts that say "all I need is an OS that doesn't suffer from SMP", all I have to say is why do you use SymmetricalMP in the first place??! Why not use assymetrical processing, and just queue all interupts on a single CPU? it'll sure as hell simplify everything, and reduce overloading the bus with those damn spin locks!
If you're going to claim that the Linux kernel is doing a good job of an SMP system, you have to show me it's actually performing better. Not just allowing more threads to run on more processors... everyone can do that.
Second thing is: don't flatter yourself by 'easy wins'. All I'm saying is that this is just *not* an win for linux. It's only a win for HT and multithreading... but hey, we all knew that Multithreading is a Good Thing(tm)... right?
See, something that very few people know is that the NT kernel is fully pre-emptible, fully-interuptible, and re-entrant by design. ie. even for single processor systems, it's like that.
The linux kernel is not.
It's very hard to 'tack on' SMP features onto a system that wasn't made with that in mind in the first place.
This has some advantages, and some drawbacks... NT kernel programming is *frigging* hard. HARD.
But it also has the advantage that it makes *much* better use of SMP.
Compilers are notoriously single threaded monsters.
On moft platforms, CL.exe goes file per file, and outputs. It's a linear opertation. So HT for compiling makes no difference.
However, the NT DDK has a cool feature that allows you to spawn as many instances of CL as there are processors. Which you guessed it, is only of any use if you are compiling tens/hundreds of files.
Sorry, I do not really know of compiler internals for *NIX. Maybe someone can back me up? or clear it up?
if you had read the article, you would have seen that the kernel doesn't show too many signs of superb HT usage. In fact, performance degrades in many places.
Also, if you knew just an itsy bit about kernels, you would know that Microsoft has done some pretty good advancements and achievements in the SMP realm.
I think what contributes to C's longevity is the fact that there is no other language that can be used in K-mode programming, apart from asm (which isn't a language per-se).
And as such will never go into oblivion. C does not do *any* behind the scenes action... which is why it attracts to many people.
That can be an advantage, or a disadvantage... up to you to chose it properly.
So, even if we assume that the leadership at places like IBM and Redhat would behave as badly as the leadership at Microsoft has been convicted of doing, we can also assume that they will have slightly less opportunity.
In all honesty, if IBM were to stray from the Linux tree, which is perfectly legal under GPL, they would be making proprietary software which is not compatible with the main stream. At which point this so called OSS benefit becomes only IBM's benefit. Sure you have access to the source code, but can you migrate? Can you use IBM's brand spankin' new MagicAdmin 2.5 software on incompatible Linux machines?
My point was that this is not the case only because at the moment, it's in their interest. But the GPL does nothing against them breaking standard, it only says you can see what the breakage is. Now, see or not, the whole issue is that a company has the choice to do whatever it wants.
So, apart from the people who work at one of these huge corporations, GPL or not, it doesn't really matter... only standard matters.
I do recognize that I was slightly OT. Sorry for that. I just wanted to express this opinion of mine. And I also recognize that this post is slightly unfocused, it's late and I have a cold.
You are a primal fool if you think they are *any* different from Moft. They are big corporations, and at the corporate level, THERE ARE NO MORALS... just like there is no ettiquette for hitting under the belt.
You are deluding yourself if you think Redhat is not pulling Moft'y FUD tactics out of good will and the GPL soul... it's because they have best interest in not doing so.
This reminds me of a similar problem that was the bitch-slap-trend of the time: AMD vs Evil Intel. Evil Intel was accused of making Evil Rambus, that was Evilly proprietary. Well guess what... AMD was a partner of Rambus too.
Everyone who thinks *ANY* corporation is out to do good is a fool.
Now, is GPL good/bad/hemeroid/cancer-cure? No Comment.
Scientist have discovered that humans and all life on earth was just a discarded bacterial disk drive from a geek with pimples living in his mother's basement 5 million light years from the solar system.
Slashdot Mirror
Hmmm... yah. Can't be. Those inumerable people against globalisation must all be out of their minds.
Or maybe I'm just too big of a Sartre fan. Who knows.
Download the friggin DDK from their site, and they have working samples for almost all their core drivers.
Stripped of a license, the samples in there are as good as OSS.
And btw, they are nice cleanly coded samples. There is just as much pressure on programmers there to keep that code clean: it's in their DDK, and they don't want to show shody samples. So I'm sure the code review processes are just as stringent.
it's being criticized because it *does* what they claim...
So what is it that Palladium does that TCP doesn't do that's so bad for you? I've heard of Palladium doing curtain memory (which at least seems like a Good Thing(tm), but definitely is not a Bad Thing (tm) -- in the worst case a Useless Thing(tm) ), I have also heard that Palladium is *not* DRM.
So what's it to you? why are you complaining? Enlighten me, oh gods of OSS.
Bose and Einstein are added to the black list of the OSS/linux zealot guild...
I find it interesting seeing that security by obfuscation is a prevalent concept throughout mankinds realm. I guess it is nurtured by the ostrich-sticking-head-in-sand effect of thinking something doesn't exist if we're not aware of it.
It also makes me laugh how newspapers always skew stuff for sensationalism: now terrorists are one step closer to the US. They are pounding on the gates! WATCH OUT!!!. I think this security whole is mostly going to be used by 16 year old K-Mart workers.
Anyways, very nice article in the end, and hats off to AT&T for having 'brass hats'.
Did spending an extensive period of time away from computers make you realize that you might just move away one day? or are you still fascinated like the first geek was?
You know why? because you are a little loser of an AC who probably talks out his ass all day long. In fact, I'm pretty sure your face *is* your ass.
Let karma gods strike me down... it won't save you from your ass-hood.
MS SQL 2000
MS VC
Windows NT kernel
The NT kernel is good, it's stable. Security compromises on the Windows platform mostly come from user mode applications not behaving while they're under power (under the system or admin accounts).
There is no point whatsoever to make such a retarded move. If anything, I'd like to see an OS Xish shell on top of the NT kernel.
I really doubt they actually care of custommer base writing reviews - that has very little credibility. Norton, on the other hand, saying NA is no good is something to think about (for some).
It isnt really. Its quite well understood. Its just there's lots to it - which means most of us will never be able to understand all or even a part of modern highly-featured kernels. But there's nothing magic about it.
Have a sense of humour. Of course *nothing* is magic. I was just making a point that it's beyond the programming most people learn in CompSci because it's so specific in nature. But on top of the sheer breadth of knowledge necessary, kernel mode programming has some fundemantally different ideas that aren't present in user mode programming. So it's not just the quantity.
Well, i dont really know much about the NT kernel. So originally your point was it was so reentrant, depending on the level. Now you've qualified that to say that many functions cant be called if irq level is elevated - hence nullifying much of that supposed reentrancy. :)
You're playing with words, it would take me far too long to explain the intricacies of what this means... And I'm not even an expert on the matter.
See my last comment about this not being a place where such conversations would hold water... /. is essentially a bar where people meet and talk after hours over a few beers. If you really want to learn about the re-entrancy issues, read a few books about it... an 'insightful' post isn't going to cut it.
And last but not least:
So come up with some benchmarks. :)
I *refuse* to come up with benchmarks in order to explain my dislikes about benchmarks. It's like saying to a movie critic, "hey, go and shoot a movie to explain yourself". Stop being defensive and viewing it as a race between good and evil. It will actually do linux more good in the end if people are critical, and don't cave in to what IBM might have to say that might just be the beginnings of a Microsoft style skewing of numbers. Because, heck, I'm positive this whole article would have been viewed in a completely different perspective had it been Microsoft posting its results.
My claim isn't really about NT. What I was saying about NT was just an FYI for the chearleaders.
My claim was that this article, despite it's title (HT Speeds Linux), wasn't really showing any proof that linux itself was going faster.
Obviously applications which use multiple threads are going to go faster on an HT machine, (the kernel would have to be really bad for that not to happen). But the article's numbers didn't show any speed up in linux itself. Which was my point, and the article itself, IMO, backs that claim.
Another thing is that the NT kernel might be re-entrant, but the rules of IRQL still hold... there are many functions that can't be called at elevated IRQLevels. So, it's not as complicating the kernel as you might think.
One last thing, the general point I'd like to stress is that kernel programming, and kernel optimizations are very much a black art, rocket sciene, or voodoo. It's very hard to assert whether spin locks are enough overhead to not be justifiable. And I think those kinds of discussions are way beyond the scope of this forum.
The bottom line is this article, IMHO, was a piece of self serving specialized benchmark put out by IBM (what's so hard to believe about that?), and despite the fact that it's linux that's being talked about, I still find the numbers to be skewed to the profit of the publisher.
Well, I agree with you, over the years, the gap will probably slowly close. With kernels, really, much more than the kernel, it's all the parafanelia that counts. The countless drivers that have, or have not been designed with pre-emtability - and interruptability in mind.
Even if the kernel is modified completely overnight, it will take a few years for the whole kernel mode system to catch up.
Bottom line is, and given that this benchmark comes from IBM it really doesn't surprise me, there isn't much there to see *yet*.
Care to explain what these mean?
I'll explain to you what this means:
it means a piece of hardware raising an interupt will launch a driver's ISR, hardware wise, at that point, any other hardware raising an interupt at a lower IRQ level will not be serviced. BUT, any higher IRQLed hardware can take over of that 'thread' that is servicing the first interupt. There are *no* exceptions to this rule. In effect, your ISR is fully interuptible.
The thread dispatcher runs at DIRQL (D=Disptach), any IRQL higher than DIRQL is kind of beyond the concept of threads. But any thread running bellow DIRQL (ie, APC or normal threads) are fully pre-emtible. There is no thread that has *any* priority of not being pre-empted anywhere in the system.
All of the kernel is also re-entrant, which means from anywhere within the kernel, so long as you are in proper IRQL, you can call back the kernel.
At these altitudes, or depths, whichever you wish, there are many strange beasts that you've never heard of - or never had a reason to really use - that are being used to do synchronization. Namely spin locks. Moft came up with queued spin locks a few years ago, and that was a rather Good Thing (tm). It made spin locks so much better under SMP systems.
Now, to all the posts that say "all I need is an OS that doesn't suffer from SMP", all I have to say is why do you use SymmetricalMP in the first place??! Why not use assymetrical processing, and just queue all interupts on a single CPU? it'll sure as hell simplify everything, and reduce overloading the bus with those damn spin locks!
If you're going to claim that the Linux kernel is doing a good job of an SMP system, you have to show me it's actually performing better. Not just allowing more threads to run on more processors... everyone can do that.
Second thing is: don't flatter yourself by 'easy wins'. All I'm saying is that this is just *not* an win for linux. It's only a win for HT and multithreading... but hey, we all knew that Multithreading is a Good Thing(tm)... right?
The kernel has lots of work to do when you call into it. Of course it wouldn't boost up if all kernel calls were like this:
void myKernelFunc( long param ) { return param * 2 - 23; }
But kernels do work.
See, something that very few people know is that the NT kernel is fully pre-emptible, fully-interuptible, and re-entrant by design. ie. even for single processor systems, it's like that.
The linux kernel is not.
It's very hard to 'tack on' SMP features onto a system that wasn't made with that in mind in the first place.
This has some advantages, and some drawbacks... NT kernel programming is *frigging* hard. HARD.
But it also has the advantage that it makes *much* better use of SMP.
Sad, but true.
On moft platforms, CL.exe goes file per file, and outputs. It's a linear opertation. So HT for compiling makes no difference.
However, the NT DDK has a cool feature that allows you to spawn as many instances of CL as there are processors. Which you guessed it, is only of any use if you are compiling tens/hundreds of files.
Sorry, I do not really know of compiler internals for *NIX. Maybe someone can back me up? or clear it up?
if you had read the article, you would have seen that the kernel doesn't show too many signs of superb HT usage. In fact, performance degrades in many places.
Also, if you knew just an itsy bit about kernels, you would know that Microsoft has done some pretty good advancements and achievements in the SMP realm.
Of course multi-threaded applications are going to improve. What's your point?
For those who didn't RTFA:
Simple syscall 1.10 1.10 0%
Simple read 1.49 1.49 0%
Simple write 1.40 1.40 0%
Simple stat 5.12 5.14 0%
Simple fstat 1.50 1.50 0%
Simple open/close 7.38 7.38 0%
Select on 10 fd's 5.41 5.41 0%
Select on 10 tcp fd's 5.69 5.70 0%
Signal handler installation 1.56 1.55 0%
Signal handler overhead 4.29 4.27 0%
Pipe latency 11.16 11.31 -1%
Process fork+exit 190.75 198.84 -4%
Process fork+execve 581.55 617.11 -6%
Process fork+/bin/sh -c 3051.28 3118.08 -2%
is it just me? or does the linux kernel not perform so much better in SMP HT?
And as such will never go into oblivion. C does not do *any* behind the scenes action... which is why it attracts to many people.
That can be an advantage, or a disadvantage... up to you to chose it properly.
Very few compilers truly implement templates as they have been specced out.
On another note, I believe templates are the greatest invention since the bit.
In all honesty, if IBM were to stray from the Linux tree, which is perfectly legal under GPL, they would be making proprietary software which is not compatible with the main stream. At which point this so called OSS benefit becomes only IBM's benefit. Sure you have access to the source code, but can you migrate? Can you use IBM's brand spankin' new MagicAdmin 2.5 software on incompatible Linux machines?
My point was that this is not the case only because at the moment, it's in their interest. But the GPL does nothing against them breaking standard, it only says you can see what the breakage is. Now, see or not, the whole issue is that a company has the choice to do whatever it wants.
So, apart from the people who work at one of these huge corporations, GPL or not, it doesn't really matter... only standard matters.
I do recognize that I was slightly OT. Sorry for that. I just wanted to express this opinion of mine. And I also recognize that this post is slightly unfocused, it's late and I have a cold.
Thank you come again.
My post was purely addressing the naiveness of believing in corporations.
Would you like some fava beans with your liver Clarice?
You are a primal fool if you think they are *any* different from Moft. They are big corporations, and at the corporate level, THERE ARE NO MORALS... just like there is no ettiquette for hitting under the belt.
You are deluding yourself if you think Redhat is not pulling Moft'y FUD tactics out of good will and the GPL soul... it's because they have best interest in not doing so.
This reminds me of a similar problem that was the bitch-slap-trend of the time: AMD vs Evil Intel. Evil Intel was accused of making Evil Rambus, that was Evilly proprietary. Well guess what... AMD was a partner of Rambus too.
Everyone who thinks *ANY* corporation is out to do good is a fool.
Now, is GPL good/bad/hemeroid/cancer-cure? No Comment.
Terms a) and b) are used in mathematics. Term c) does not exist in mathematics.
You're comparing apples and oranges.
It's like saying to someone's comment "an electron is not 'cool', it's negative".
Scientist have discovered that humans and all life on earth was just a discarded bacterial disk drive from a geek with pimples living in his mother's basement 5 million light years from the solar system.