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
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.
It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.
