Nice, self-serving BS. There is absolutely no point in explaining anything to you as you are convinced you already have the absolute truth, while you clearly do not even understand the basics. I encourage you to look up the Dunning-Kruger effect though, and try to understand what it means to be on the left side of the graph.
If and when the human race learns to code software that is very hard or impossible to compromise, SDN may have a place, but before that, it is an exceptionally bad idea. It is also not a new bad idea, but an old one that has been renamed. For example, "Active Networking" did try this thing before.
It should have been "we only take in systemd as default if the distro stays fully functional with sysvinit". By not retaining that choice, the Debian technical committee has screwed over the Debian user community.
The point is that if sysvinit has problems, you can usually diagnose and fix them yourself. You can also work around it. So while not perfect and sometimes a pain, you can adapt it to be not broken for your particular needs and after that it usually stays non-broken, because it is stable and mature.
With systemd that is no longer possible. Even creating bug-reports for systemd seems to be a real challenge, and not only because the dev-team is mostly unresponsive.
In Debian, one rightfully expects the "default" to be rock-solid, and minimal-fuss. This implicit promise is broken by systemd. Also notice that systemd as default implies no full alternatives are possible long-term, as a lot has to be adjusted to whatever systemd needs. This means that over time, the "default" will be the only way to use the fill distro. Doubtlessly, that is what the systemd-mafia wants.
While I do not know how your reading comprehension is, you have at least failed to read any documents detailing the impact of making systemd the "default".
Also my take. The decision to go that way is still a complete mystery to me. And no, I will not use systemd anytime soon. Maybe I will have a look at it in 5 or 10 years when it may (or may not) have reached a stable feature set and some code maturity, but not before.
Seriously, this is an intermediate subject in crypto and filesystem design. I can only give you hints. If you really want to understand this, some study on your part is required.
For example, one thing you do to prevent crafted collisions when you do not control the input to a hashing-scheme is to add a "salt" that is not accessible to the attacker. This makes even broken crypto hashes exceptionally resistant against crafted collisions. It is a well-known technique and also used in conventional hash-tables with non-cryptographic hash-functions to prevent algorithmic complexity attacks. As to random collisions, they do not happen in practice even with weaker crypto-hashes, as long as the hash-length is tailored to the maximum filesystem size.
Some level of understanding is rightfully required to make claims in this space. I do not see that level in Valery, and hence I call here "not so smart". If you take exception with that, come right out with it and do not hide behind technicalities.
You do not write a "meh" paper on an important design aspect in an area you are currently working if you are smart. Instead you try to understand the subject better and then write a good paper. As to wrong, it needs a bit more than a first glance and it needs some understanding of the crypto and computer hardware involved. The paper, as it is, shows "ego". It does not show "smart", but the absence of it. It is also not the only indicator of that problem in her person. This being/. I am not going to do more research for you.
It seems like she does understand this, but is saying that the comparison of collision rates to hardware failures is not appropriate.
That is one of the criticisms I have, because the comparison is appropriate. You do need to understand how to do it right, but she does not. Her explanation is bogus. She does not understand the statistics. Given that she was working as a file-system developer at that time, this is not acceptable and clearly shows that she has no understanding of her own limits.
Hmm. Difficult question. I learned PASCAL in school (and knew BASIC and some assembler before), but it was taught by an enthusiast teacher and we were all there in our spare time, no grades or anything. And I self-learned C from a book not long after, because PASCAL back then was limited to 64k data and I needed more.
Still, I do not think COBOL is a good idea. A combination of PYTHON and C may serve the same goal (just require real understanding for most of what is taught), without putting off the ones with the talent to learn.
On example is her writing on compare-by-hash. It has been a while and I am currently not finding the original text anymore, but at a quick glance this paper seems to be the same thing: http://valerieaurora.org/revie... I have no idea (and currently no time to check) whether the emotional arguments and faulty statistics I found in the text I read are also in the PDF.
Now, compare by hash is perfectly fine if you do it right. In that case the computer producing bit-errors and the like while you do the hashing for a comparison is more likely than getting a hash collision. Yet for some reason Valery seems to not understand that, or at least did not back then.
We also have female assholes (about 50% of them all, IMO, consistent with feminist "theory" that gender is an illusion) and when these do their thing and then experience push-back, that is not "harassment" either.
Add neck- and back-problems to that. But getting your work criticized in clear language? Being able to take that is called "professionalism". And nobody will put porn into a presentation, unless it was on-topic. It is more likely that these women cannot stand that about 100% of men like porn (and not so few women), and they want to fight that preemptively.
I read some of Valerie's technical texts a while back. Driven, focuses, maybe, but smart, not so much. She even gets intermediary technical things wrong that are quite obvious to any precise thinker. Then she uses emotional appeal to cover up her lack of arguments and to convince the reader anyways. That is a real problem, as physical reality is quite unforgiving to those that do not understand it.
What, you want to discourage anybody with real talent to go into coding or CompSci? While I admire your ingenuity, I do not quite understand what your end-game here is. Accelerated collapse of industrial society?
Slashdot Mirror
Nice, self-serving BS. There is absolutely no point in explaining anything to you as you are convinced you already have the absolute truth, while you clearly do not even understand the basics. I encourage you to look up the Dunning-Kruger effect though, and try to understand what it means to be on the left side of the graph.
No, it cannot. It does require a complete lack of understanding how networks can and cannot be protected to make such a claim however.
Who let the insane one in here again?
If and when the human race learns to code software that is very hard or impossible to compromise, SDN may have a place, but before that, it is an exceptionally bad idea. It is also not a new bad idea, but an old one that has been renamed. For example, "Active Networking" did try this thing before.
It should have been "we only take in systemd as default if the distro stays fully functional with sysvinit". By not retaining that choice, the Debian technical committee has screwed over the Debian user community.
The point is that if sysvinit has problems, you can usually diagnose and fix them yourself. You can also work around it. So while not perfect and sometimes a pain, you can adapt it to be not broken for your particular needs and after that it usually stays non-broken, because it is stable and mature.
With systemd that is no longer possible. Even creating bug-reports for systemd seems to be a real challenge, and not only because the dev-team is mostly unresponsive.
In Debian, one rightfully expects the "default" to be rock-solid, and minimal-fuss. This implicit promise is broken by systemd. Also notice that systemd as default implies no full alternatives are possible long-term, as a lot has to be adjusted to whatever systemd needs. This means that over time, the "default" will be the only way to use the fill distro. Doubtlessly, that is what the systemd-mafia wants.
While I do not know how your reading comprehension is, you have at least failed to read any documents detailing the impact of making systemd the "default".
Exactly my point. Thank you.
You confuse indicator and proof.
Also my take. The decision to go that way is still a complete mystery to me. And no, I will not use systemd anytime soon. Maybe I will have a look at it in 5 or 10 years when it may (or may not) have reached a stable feature set and some code maturity, but not before.
If you see computer viruses as alive, then we can terminate the discussion right here, as you are utterly clueless about physical reality.
Seriously, this is an intermediate subject in crypto and filesystem design. I can only give you hints. If you really want to understand this, some study on your part is required.
For example, one thing you do to prevent crafted collisions when you do not control the input to a hashing-scheme is to add a "salt" that is not accessible to the attacker. This makes even broken crypto hashes exceptionally resistant against crafted collisions. It is a well-known technique and also used in conventional hash-tables with non-cryptographic hash-functions to prevent algorithmic complexity attacks. As to random collisions, they do not happen in practice even with weaker crypto-hashes, as long as the hash-length is tailored to the maximum filesystem size.
Some level of understanding is rightfully required to make claims in this space. I do not see that level in Valery, and hence I call here "not so smart". If you take exception with that, come right out with it and do not hide behind technicalities.
With that student group as target, I agree to your reasoning.
Hyperbole like "forever" has no place in a professional treatment of the situation. May take a decade or two though.
You do not write a "meh" paper on an important design aspect in an area you are currently working if you are smart. Instead you try to understand the subject better and then write a good paper. As to wrong, it needs a bit more than a first glance and it needs some understanding of the crypto and computer hardware involved. The paper, as it is, shows "ego". It does not show "smart", but the absence of it. It is also not the only indicator of that problem in her person. This being /. I am not going to do more research for you.
It seems like she does understand this, but is saying that the comparison of collision rates to hardware failures is not appropriate.
That is one of the criticisms I have, because the comparison is appropriate. You do need to understand how to do it right, but she does not. Her explanation is bogus. She does not understand the statistics. Given that she was working as a file-system developer at that time, this is not acceptable and clearly shows that she has no understanding of her own limits.
Hmm. Difficult question. I learned PASCAL in school (and knew BASIC and some assembler before), but it was taught by an enthusiast teacher and we were all there in our spare time, no grades or anything. And I self-learned C from a book not long after, because PASCAL back then was limited to 64k data and I needed more.
Still, I do not think COBOL is a good idea. A combination of PYTHON and C may serve the same goal (just require real understanding for most of what is taught), without putting off the ones with the talent to learn.
On example is her writing on compare-by-hash. It has been a while and I am currently not finding the original text anymore, but at a quick glance this paper seems to be the same thing: http://valerieaurora.org/revie... I have no idea (and currently no time to check) whether the emotional arguments and faulty statistics I found in the text I read are also in the PDF.
Now, compare by hash is perfectly fine if you do it right. In that case the computer producing bit-errors and the like while you do the hashing for a comparison is more likely than getting a hash collision. Yet for some reason Valery seems to not understand that, or at least did not back then.
We also have female assholes (about 50% of them all, IMO, consistent with feminist "theory" that gender is an illusion) and when these do their thing and then experience push-back, that is not "harassment" either.
Also note that getting one's work criticized is neither "threats" nor "harassment". Some women apparently do not understand that.
Add neck- and back-problems to that. But getting your work criticized in clear language? Being able to take that is called "professionalism". And nobody will put porn into a presentation, unless it was on-topic. It is more likely that these women cannot stand that about 100% of men like porn (and not so few women), and they want to fight that preemptively.
I read some of Valerie's technical texts a while back. Driven, focuses, maybe, but smart, not so much. She even gets intermediary technical things wrong that are quite obvious to any precise thinker. Then she uses emotional appeal to cover up her lack of arguments and to convince the reader anyways. That is a real problem, as physical reality is quite unforgiving to those that do not understand it.
And what about those that do not love coding yet, because they do not know it yet? Which these days will be the majority of the talented?
And how is that relevant?
What, you want to discourage anybody with real talent to go into coding or CompSci? While I admire your ingenuity, I do not quite understand what your end-game here is. Accelerated collapse of industrial society?