Topic: About Mt. Gox flaw from a security expert - page 5. (Read 34165 times)

There actually isn't a flamewar going on.   The alternation between your off-the-chart arrogance combined with your refusal to elucidate (and your pretty compulsive need to denigrate folks).  You have painted yourself as the provocateur while taking on the role of the victim.  Perhaps you only see a fight because you are looking for one eh?
 
Actually that's a good illustration there.  The last thing I read you labeled as an "insult" was how I had said you "betrayed your skillset".  Sound like that could easily be you looking for an opportunity to take offense.

Good choice of words.  "Refuse to accept" this illustrates well how what we are observing with you is a non-rational process.


Hmmm...again you are kind of making things up.  There's nowhere where anyone said or implied that.


That's an old horse isn't it?  The old "Well you just have to read this book" dodge.  LOL.

Come on people, argument what is more secure Linux or BSD is so irrelevant when the sysadmin has hands growing out of his backside. And frankly, in the real world the later is usually the case.

I'm grateful that I'm not the only one who tries to step down this flamewar


 


You probably are true, still I see some of the posters of this thread as haters.

When I say:


I'm not saying that linux is not secure. But just as I refuse to think that IIS+windows is as safe as LAMP, I refuse to accept that BSD is as safe as linux.

Moreover if the subject is defended by people who thinks that SElinux is a flexible linux distro, or who states to be able to read 10 millions of code as if it was water.

http://en.wikipedia.org/wiki/Statistic
[/quote]

I love wikipedia, but I have to say that is not the most reliable source when you're dealing with science.

The fact that wikipedia says:

A statistic is an observable random variable

moreover writing observable in italic, should suggest you that the author is trying to explain a very complex concept with a very short description.

Behind this there's one of the biggest problem of modern mathematics, behind the name of theory of measure.

I do personally refuse to accept the Kolmogorovian axioms or the existence of real numbers, and this force me to use a much stricter formulation of statistical theory. But even without these two problems, defining a statistic as a random variable is a stretch.

Maybe if you have this book (it's the bible of statistic, it can be easily found in any scientific library) I could point you to some deeper analysis.

Uh really?  So you really think that calculation is meaningful?   How about you tell me why you think that.

Sorry if I'm making a broad assumption here but I'm getting the idea that you two are just trading wikipedia references.

I'm not saying the code is the same. I'm saying that the toolchain handle this.



I'm not sure I see your point.

I agree that you largely understand what you are talking about (as far as statistics) and that your English could be the primary cause of residual confusion. However, you are still making
overly confident statements, without taking a 'wikipedia moment' to verifiy them.

http://en.wikipedia.org/wiki/Statistic

LOL *rolls on floor laughing*. That's a good one! You do realise that we're talking about kernels here, right? Compilers don't know about page tables, or context switching, or power management, or interrupts (on most platforms), or any of a number of important architecture-specific things that kernels need to manage. The code to handle this is in the architecture-dependant arch/ directories of the Linux kernel. (I believe the BSDs handle the seperation between architecture-independant and architecture-specific code differently. Never used them though.)

Android is not Linux. Developing Android drivers and porting it to a new hardware platform is not that similar to developing Linux drivers and porting that to a new platform. Android's based on the Linux kernel, but it has enough fundamental changes to the driver APIs that they're not really compatible.

Lulz for life.

#Lulzsec

You just joined ignoreland alnog with the jgraham.


Even if I dont reply to you, please keep on posting, to keep the lulz up

you really are a troll.

I'm sorry for you.

Because the latency for DNS, first byte and connect were lower.   Exactly where is the data that those strongly correlate to security events?  Nowhere.
For all you know this has nothing at all to do with the OS.  Cluster size, hardware config, network organization (such as the composition and placement of edge devices).  Heck we don't even know that all of these systems are under the same load.   All effect these kinds of statistics and considering that we are talking about averages without any idea as to their VARIANCE the placement might well be random.

Guess the mouse dropped out of stats?

OMFG! you are now comparing a chip to a operation system.

Really?  Perhaps you can explain to me what you think he's trying to do here.

To me, even if "reliability" (as defined by Netcraft) was correlated with "security" (whatever we mean by that).   The kind of analysis you'd want to do here is a simple comparison of categoricals.  So ANOVA is the tool of choice.   Looking at the Netcraft data linked to early on it's pretty clear that things like failed requests, DNS latency, connect latency and first byte latency have little to do with uptime.  Sure you could make up a way they could be related to a security event (like say connect time or failed requests are related to DoS attacks but you wouldn't be able to differentiate between that and every other event).  What's left after that?  Outage - which might be related to a security event requiring a reboot but there almost everyone is at zero.  Except for two BSD sysetms and one linux system.

So I don't even have to boot up R to tell you that the correlation coefficient here is going to be next to nothing (and probably bad for BSD).

From where I stand this is an "shows promise" mark and where I grew up that's a C. ;-)

Jono

Edit: So drudging back through his morass of poor English.  It sounds like all this nonsense is actually about counting "serious" flaws per system over some time period? Exactly how does *that* become a security metric?  Not to mention that using the "flaws" metric is very likely not going to follow the kind of probability density function one is expecting.

I'd like to take a moment to say that math isn't magic.  The numbers you put in need to be meaningful and the operations you perform on them need to say something...*shakes head*
He might as well have taken the square root of spiders and integrated it by batman...

I'd agree that OpenBSD has security as an imperative for it's dev team and while ASLR isn't the be-all of security.   I would contend that it does show a team taking a proactive approach to security rather than simply reactive patching.  As far as I can tell even FreeBSD 9 doesn't have it committed to the roadmap (it was suggested years ago though).

But if you know what to do and need maximum reliability and security, without going Itanium, then BSD is a very good choice.

I would like to make you a question: why do you think that BSD had the 3 top spots in the reliability chart?

Do you think that the fourth company wasn't as good as the first three?

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

I loled a lot on this one and I completely agree. Even if I prefer nginx or apache to run software and get an extra level of security you can also secure an IIS very easily, and this without knowing a lot about computer security. Look how much flaw from new nginx and apache have been reported and look how much flaw on IIS have been reported (securityfocus) you'll see that what you say is completely out of bound...

Also php / perl / etc can be attacked if badly codded, daemon running on linux can easyly be attacked too, so this is complete no-sense.

they absolutely need to take steps so this CANT happen again.