This. It's pretty much my take, too. Imagine: playonlinux style "what works" compatible configs *maybe even tested by the original developers* and targeting the relative stable steam runtime environment? It's a no-brainer.
Honestly, I'm waiting for some ambitious desktop environment guy to start shipping a DE package via steam. No reason why you couldn't (or shouldn't). Steam has delivered a stable *end user* environment in a way no single distro or vendor has managed before on Linux. We can all take advantage.
What happens in assembler, and to a great extent in C, is what the computer is really doing (more or less, it's pretty close). In higher level languages this connection is very fuzzy. Not knowing what will really happen when you write that for loop is more likely to lead to you writing pathological and otherwise buggy code. It's not *essential* that you know how computers really work, but it's a *really damn good idea* and more or less essential for any really good programmer. The only people who disagree are the ones that never did learn a low-level language (IOW where you work with memory/registers/pointers/that sort of thing).
You are as much anonymous as anyone else is. If you don't understand how that can be then *shut the fuck up* about it until you do.
I imagine I am wasting my metaphorical breath, but I'll try to explain it as much as it can be explained.
Think pranks. Think prank phone calls and pizzas you didn't order, then imagine this done in a way designed to make you feel bad, then imagine that everyone who pranked you can see your face when you feel bad and laugh at you. That's about the limit of what anonymous will organize to do. All this breaking and entering shit is largely hacktivism done by people who aren't acting as anonymous when they do it, even if they may call on anonymous for help from time to time. And LOICers... they're just idiotic hangers-on. Angry and about as effective as egging someone's house. The effective DDoS attacks come from individuals (armed with botnets) and not some imaginary criminal conspiracy.
I am not an anonymous apologist, I am anonymous (and you can too). Wherever a little kid cries because someone told him he was fat, I will be there along with the baser parts of all mankind and we will be laughing at his misery. When those baser instincts band together to laugh at everything and nothing, there you have anonymous. Anonymous aren't criminals, anonymous is the internet hate machine. It's not good, it's not evil, it's simply humans being human--including the part of being human that we are all obliged to hide from society for fear of persecution. Anonymous exists so that you can be a jerk, a deviant, a racist and make jokes in bad taste knowing that **it's okay, we understand**, we both accept and revile you, too. Unless you're furry (DIAF, plzkthxbai).
There may be a global internet-based criminal organization out there which does bad things, harms people and needs to be busted by the authorities; in fact, I'm pretty sure there are several, but none of them are called Anonymous.
I'm not confusing them, I'm well aware. Lots of normal people keep rolling with the 6 month releases for freshness and run afoul of all manner of problems. The LTS users get the moderately tested and bugfixed version, but it's no better engineered.
The problem with Debian is that Debian has a non-free repository and documents this fact. Whether the user will be confused about whether or not he is installing non-free software is not the issue at all.
RMS maintains that documenting the existence of non-free software, even if the repo is not enabled by default and requires manual intervention to enable, is "suggesting" that it be used and this suggestion is tantamount to a recommendation to use non-free software, which RMS thinks is a thing that a fully freedom-loving distribution should not do.
Can a distro fully respect your freedoms and still document the existence of non-free software? I think so, but since the FSF is in the business of promoting Free software to the exclusion of all else they cannot endorse a distribution which fully respects your freedoms but mentions that non-free software exists. This is an entirely reasonable stance for the FSF; they can choose who they endorse based on any arbitrary criteria, and I respect that.
The Debian folks must necessarily take a more pragmatic view since their primary mission is not to promote Free software to the exclusion of all else. This does not mean that they are behaving in an unethical manner or in a manner which is inconsistent with the FSF principles and ideals, it's just at odds with some of their policies.
Compare this with Ubuntu - based on Debian unstable - which is both up-to-date and stable
Hah. I'll contain my laughter.
Canonical releases are rarely what I would call *stable*. They're full of issues both small and large and mixing packages from outside of their main repo can quickly destabilize what you do have.
Debian sid sometimes has *package dependency issues* or regressions, but that's where its "unstable" moniker stops applying. Debian policy leads to Debian stability and which archive you pull from doesn't matter much. To get something that might be broken in Debian, other than install-time difficulty due to mismatched dependency information, you usually need to go to experimental. If you're not familiar with it that's *good*, because it's not for you.
Ubuntu is poorly put together and less reliable than Debian. Anyone who's familiar with Debian from a sysadmin point of view will probably be able to confirm this for you. The only reasons Ubuntu gets away with it are (1) its users don't do much with their computers, and (2) after 6 months you dist-upgrade, so problems from the last release go away and get replaced by problems from the new release. It's all terribly slipshod and amateurish.
You must not live in the USA. I recommend you reserve judgement.
Standardized tests just cause schools to focus on scoring well and ignore actually educating students. If your school does not do well on standardized tests they take money away from you, period. If your school does well you can employ more teachers at better salaries, build more schools, have more programs like music and sports, etc.. The frenzy to "win" at tests is incredible. I've seen teachers all but GIVE students the answers ahead of time in a so-called "prep" test in the hopes that woefully undereducated students will pass muster on test day. Nothing else in a public school is more critical than getting a good score (which means good percentages and good averages across the student body) on test day. NOTHING. Not student welfare, not knowledge, nothing.
The answer to this is a philosophical one. We can say pretty definitively that rote memorization is a very poor method, but there is no generally accepted "best" method.
How does one measure the progress of students?
You don't. Progress is life; are they still alive? You can only encourage and hope, measurement is pointless.
How does one understand something without remebering it?
Easy. I understand lots of things that I can't remember if asked. Memorization is a very different thing than understanding.
I'll try to contrive an example: I understand English, for example, and can use it with precise correctness (and with a vast vocabulary) upon request, but if you ask me to define parts of speech or diagram a sentence I'll fail 99% of the time. I tend to score quite poorly on English exams that are not purely prose. A lot of things are like that, although less so in the discrete sciences. Do you understand recursion? Good. Can you tell me what year it was invented and by whom? You fail the programming exam! This is the way testing fails.
That said, I do feel that discrete names provide better clarity, and don't believe that having distinct symbol tables for each variable type is beneficial
I do not disagree that for this example there are superior name choices that could have been used. I preferred not to dig through real code to find an example of a case where there was no better choice than to use the same basic name with different sigils; it does happen and it's not unclear.
I think the guy who wrote the ruby version also understood what you were doing. His point (and mine, to a lesser degree) is that if you use distinct names, which he and I both appear to prefer, then the sigils become clutter.
And my point is sigils are part of the name, which makes each name distinct.
You could say the same thing about case-sensitive variables. The fact that you can use COLUMNS and columns in C and they mean different things is confusing, especially for neophytes! The VB solution of case insensitive names is obviously less confusing and thus superior, right? Why should anyone have to master this syntax quirk?
The sigil is part of the variable name and makes the names different (and this is very clear). Most of the time you will also alter the variable names in other ways, because it's usually a good idea, but there is no problem with leaving the non-sigil part the same from a confusion point of view *when the code is clearer as a result*. Just as COLUMNS in C is *obviously* a constant to anyone familiar with C, and just as having a COLUMNS constant should not preclude me from having a local int columns; variable.
Yes, also thanks to you for missing the point. I was not demonstrating best Perl practices, either in naming or code style or efficiency. Yes, all of the cool things you mentioned about Python work in Perl, too! I am not doing a feature comparison chart. Congratulations, you can write a better function to read a file! You know what? So can I. Now we're *all* special, together.
Yes, thanks for missing the point. I *deliberately* chose an example where the with-sigil variables *allow* you to name different things the same way without it being confusing. Of course you *can* choose names, as I said in my post, which are not the same. Would you care to choose another example of *using variables with different sigils but otherwise the same names*? Because, you know, *that was the whole point of the example*.
It rather depends on what you call a "big feature" - syntactically not much is likely to change, that's true. On the other hand if you look at the list of changes from the latest stable release it's clear that many things continue to be improved, even more so if you look at the sum of all changes from 5.12 forward (aka the modern perl5 era).
PHP may be more actively hacked on than perl5, though I doubt it, but it cannot be called better. All the flaws of perl5, and many flaws from perl4, are present in PHP, along with a bunch of other problems.
Perl5 OO is not so much "bolted on" as "Nonexistent"--instead it has a mechanism for designing your own OO system, which is great except that most people just want to get things done and don't care about being an architect at that level. These days it's a bit better in that you can tell any new person "Don't read perltoot, just use Moose" and they'll be a lot less frustrated and get more things done.
Right now, the best thing which could happen to Perl IMO is a fork of the Perl5. Yet, since user/developer base is declining, I very much doubt that would happen.
I find this funny, because after stagnating for a few years waiting on perl6 the development of perl5 did pick back up (not a fork, but a renewal) a few years ago and is going strong. Useful things are being added, the code is being improved, and so on.
sub read_file{
my $file = shift;
open(FILE, $file) or die "$!";
chomp(my @file = <FILE>);
close(FILE) or die "$!";
my %file;
while my $line (@file){
my($key, $value) = split/=/, $line;
$file{$key} = $value;
}
return %file; }
To a Perl programmer this is all very clear despite having multiple things called 'file' in the same scope. What would you prefer? "$file, $file_handle, $file_array, $file_hash"? There are a lot of things you could do instead but they're not much clearer or easier to read, and this is more than sufficiently clear.
And before you say anything, yeah this is not the best way to write such a function. If you're thinking "WTF?" the answer is "For illustration I went with something that should be fairly clear to non-Perl people" and "I'm trying to use as many different types of variable as possible."
Most modern languages have caught up to Perl5 in terms of basic regex power, so using Perl5 for its regex is no longer quite so essential in that you can probably get as powerful a system as you probably need in any language. That said, Perl5 *still* has regex features no one else has (or perhaps that no one else is crazy enough to implement.) For better or for worse, it's still the best......until you look at Perl6. Okay, so Perl6 is not done yet, but when it is the bar for regular expressions will instantly go up again. There's absolutely no competition for what it does, no other language has first class Perl6-style regex.
Smart cards neat kill the stickynote-on-monitor and password-too-weak problems dead. The main problem is inevitably some things don't support SSO.
For inside a big (or small!) company smartcards will eliminate a huge weakness. Requiring remote employees to log in via cert is even better, if you can afford it, because after that phishing loses some effectiveness ("Oh great, an attacker got the boss to send his PIN again. Too bad it's useless without the private key on his card.")
It's not a silver bullet but it does help for a certain class of problem. For the web... now there's another story, we don't have anything close to the right infrastructure to support generic smart card SSO. I had been hoping that OpenID would solve this: get all sites to adopt it, let most keep using passwords and let ME set up a provider that will auth me via smart card.
It only takes one site you use being compromised and having its hashed password list stolen, then all passwords brute-forced by rainbowtable, then the table distributed. An attacker targeting you simply gets your decrypted site password from the table by grepping your email address, sees the obvious pattern and now you're busted. If you think this is far-fetched "And no one is targeting me anyway," think again. Are you sure no one will for the lifetime of any of these sites? Are you sure no bad actor will *automate* this process at any time between now and when you no longer have any accounts protected by passwords?
Entirely random garbage of > 21 characters is required for security. It's not "How valuable is the data on site $foo?" or "How much do I trust site $bar?" that should worry you, instead it's "In the event that this password plaintext becomes known, how screwed would I be?" -- if compromising one password *could lead* to another of your passwords being compromised then you must increment your screwed level based on the damage from both the original compromised password and all other potentially compromised passwords. You *must* assume that the plaintext for any given site *WILL* become known sooner or later, that is simply the reality of web-based password authentication today.
If you insist on sticking with alpha-based word-based passwords with obvious changing bits then I recommend that the passphrase you choose have a minimum of 40 characters.
Slashdot Mirror
You're implying that you can't get the equivalent of BSD zones on Linux and run containers inside them. You can, it's just a lot of bother.
This. It's pretty much my take, too. Imagine: playonlinux style "what works" compatible configs *maybe even tested by the original developers* and targeting the relative stable steam runtime environment? It's a no-brainer.
Honestly, I'm waiting for some ambitious desktop environment guy to start shipping a DE package via steam. No reason why you couldn't (or shouldn't). Steam has delivered a stable *end user* environment in a way no single distro or vendor has managed before on Linux. We can all take advantage.
I wish I could mod you up. The quality of slashdot stories (and correction speeds) has become rather abysmal!
What happens in assembler, and to a great extent in C, is what the computer is really doing (more or less, it's pretty close). In higher level languages this connection is very fuzzy. Not knowing what will really happen when you write that for loop is more likely to lead to you writing pathological and otherwise buggy code. It's not *essential* that you know how computers really work, but it's a *really damn good idea* and more or less essential for any really good programmer. The only people who disagree are the ones that never did learn a low-level language (IOW where you work with memory/registers/pointers/that sort of thing).
I keep a chrome laptop around for this. It's enough for most people, and after logout everything's clean.
There is no criminal organization Anonymous.
You are as much anonymous as anyone else is. If you don't understand how that can be then *shut the fuck up* about it until you do.
I imagine I am wasting my metaphorical breath, but I'll try to explain it as much as it can be explained.
Think pranks. Think prank phone calls and pizzas you didn't order, then imagine this done in a way designed to make you feel bad, then imagine that everyone who pranked you can see your face when you feel bad and laugh at you. That's about the limit of what anonymous will organize to do. All this breaking and entering shit is largely hacktivism done by people who aren't acting as anonymous when they do it, even if they may call on anonymous for help from time to time. And LOICers... they're just idiotic hangers-on. Angry and about as effective as egging someone's house. The effective DDoS attacks come from individuals (armed with botnets) and not some imaginary criminal conspiracy.
I am not an anonymous apologist, I am anonymous (and you can too). Wherever a little kid cries because someone told him he was fat, I will be there along with the baser parts of all mankind and we will be laughing at his misery. When those baser instincts band together to laugh at everything and nothing, there you have anonymous. Anonymous aren't criminals, anonymous is the internet hate machine. It's not good, it's not evil, it's simply humans being human--including the part of being human that we are all obliged to hide from society for fear of persecution. Anonymous exists so that you can be a jerk, a deviant, a racist and make jokes in bad taste knowing that **it's okay, we understand**, we both accept and revile you, too. Unless you're furry (DIAF, plzkthxbai).
There may be a global internet-based criminal organization out there which does bad things, harms people and needs to be busted by the authorities; in fact, I'm pretty sure there are several, but none of them are called Anonymous.
I'm not confusing them, I'm well aware. Lots of normal people keep rolling with the 6 month releases for freshness and run afoul of all manner of problems. The LTS users get the moderately tested and bugfixed version, but it's no better engineered.
No.
The problem with Debian is that Debian has a non-free repository and documents this fact. Whether the user will be confused about whether or not he is installing non-free software is not the issue at all.
RMS maintains that documenting the existence of non-free software, even if the repo is not enabled by default and requires manual intervention to enable, is "suggesting" that it be used and this suggestion is tantamount to a recommendation to use non-free software, which RMS thinks is a thing that a fully freedom-loving distribution should not do.
Can a distro fully respect your freedoms and still document the existence of non-free software? I think so, but since the FSF is in the business of promoting Free software to the exclusion of all else they cannot endorse a distribution which fully respects your freedoms but mentions that non-free software exists. This is an entirely reasonable stance for the FSF; they can choose who they endorse based on any arbitrary criteria, and I respect that.
The Debian folks must necessarily take a more pragmatic view since their primary mission is not to promote Free software to the exclusion of all else. This does not mean that they are behaving in an unethical manner or in a manner which is inconsistent with the FSF principles and ideals, it's just at odds with some of their policies.
Compare this with Ubuntu - based on Debian unstable - which is both up-to-date and stable
Hah. I'll contain my laughter.
Canonical releases are rarely what I would call *stable*. They're full of issues both small and large and mixing packages from outside of their main repo can quickly destabilize what you do have.
Debian sid sometimes has *package dependency issues* or regressions, but that's where its "unstable" moniker stops applying. Debian policy leads to Debian stability and which archive you pull from doesn't matter much. To get something that might be broken in Debian, other than install-time difficulty due to mismatched dependency information, you usually need to go to experimental. If you're not familiar with it that's *good*, because it's not for you.
Ubuntu is poorly put together and less reliable than Debian. Anyone who's familiar with Debian from a sysadmin point of view will probably be able to confirm this for you. The only reasons Ubuntu gets away with it are (1) its users don't do much with their computers, and (2) after 6 months you dist-upgrade, so problems from the last release go away and get replaced by problems from the new release. It's all terribly slipshod and amateurish.
You must not live in the USA. I recommend you reserve judgement.
Standardized tests just cause schools to focus on scoring well and ignore actually educating students. If your school does not do well on standardized tests they take money away from you, period. If your school does well you can employ more teachers at better salaries, build more schools, have more programs like music and sports, etc.. The frenzy to "win" at tests is incredible. I've seen teachers all but GIVE students the answers ahead of time in a so-called "prep" test in the hopes that woefully undereducated students will pass muster on test day. Nothing else in a public school is more critical than getting a good score (which means good percentages and good averages across the student body) on test day. NOTHING. Not student welfare, not knowledge, nothing.
How does one teach understanding?
The answer to this is a philosophical one. We can say pretty definitively that rote memorization is a very poor method, but there is no generally accepted "best" method.
How does one measure the progress of students?
You don't. Progress is life; are they still alive? You can only encourage and hope, measurement is pointless.
How does one understand something without remebering it?
Easy. I understand lots of things that I can't remember if asked. Memorization is a very different thing than understanding.
I'll try to contrive an example: I understand English, for example, and can use it with precise correctness (and with a vast vocabulary) upon request, but if you ask me to define parts of speech or diagram a sentence I'll fail 99% of the time. I tend to score quite poorly on English exams that are not purely prose. A lot of things are like that, although less so in the discrete sciences. Do you understand recursion? Good. Can you tell me what year it was invented and by whom? You fail the programming exam! This is the way testing fails.
80% of the spec perhaps, now we're closer to 90% of the implementation. You can use almost all of it right now.
That said, I do feel that discrete names provide better clarity, and don't believe that having distinct symbol tables for each variable type is beneficial
I do not disagree that for this example there are superior name choices that could have been used. I preferred not to dig through real code to find an example of a case where there was no better choice than to use the same basic name with different sigils; it does happen and it's not unclear.
I think the guy who wrote the ruby version also understood what you were doing. His point (and mine, to a lesser degree) is that if you use distinct names, which he and I both appear to prefer, then the sigils become clutter.
And my point is sigils are part of the name, which makes each name distinct.
You could say the same thing about case-sensitive variables. The fact that you can use COLUMNS and columns in C and they mean different things is confusing, especially for neophytes! The VB solution of case insensitive names is obviously less confusing and thus superior, right? Why should anyone have to master this syntax quirk?
The sigil is part of the variable name and makes the names different (and this is very clear). Most of the time you will also alter the variable names in other ways, because it's usually a good idea, but there is no problem with leaving the non-sigil part the same from a confusion point of view *when the code is clearer as a result*. Just as COLUMNS in C is *obviously* a constant to anyone familiar with C, and just as having a COLUMNS constant should not preclude me from having a local int columns; variable.
It's not as if there's been no progress. It's much more around the corner now than it was 10 years ago, it's quite close to done now.
Yes, also thanks to you for missing the point. I was not demonstrating best Perl practices, either in naming or code style or efficiency. Yes, all of the cool things you mentioned about Python work in Perl, too! I am not doing a feature comparison chart. Congratulations, you can write a better function to read a file! You know what? So can I. Now we're *all* special, together.
Yes, thanks for missing the point. I *deliberately* chose an example where the with-sigil variables *allow* you to name different things the same way without it being confusing. Of course you *can* choose names, as I said in my post, which are not the same. Would you care to choose another example of *using variables with different sigils but otherwise the same names*? Because, you know, *that was the whole point of the example*.
It rather depends on what you call a "big feature" - syntactically not much is likely to change, that's true. On the other hand if you look at the list of changes from the latest stable release it's clear that many things continue to be improved, even more so if you look at the sum of all changes from 5.12 forward (aka the modern perl5 era).
PHP may be more actively hacked on than perl5, though I doubt it, but it cannot be called better. All the flaws of perl5, and many flaws from perl4, are present in PHP, along with a bunch of other problems.
Perl5 OO is not so much "bolted on" as "Nonexistent"--instead it has a mechanism for designing your own OO system, which is great except that most people just want to get things done and don't care about being an architect at that level. These days it's a bit better in that you can tell any new person "Don't read perltoot, just use Moose" and they'll be a lot less frustrated and get more things done.
Right now, the best thing which could happen to Perl IMO is a fork of the Perl5. Yet, since user/developer base is declining, I very much doubt that would happen.
I find this funny, because after stagnating for a few years waiting on perl6 the development of perl5 did pick back up (not a fork, but a renewal) a few years ago and is going strong. Useful things are being added, the code is being improved, and so on.
Confusing is in the eye of the beholder. Consider
To a Perl programmer this is all very clear despite having multiple things called 'file' in the same scope. What would you prefer? "$file, $file_handle, $file_array, $file_hash"? There are a lot of things you could do instead but they're not much clearer or easier to read, and this is more than sufficiently clear.
And before you say anything, yeah this is not the best way to write such a function. If you're thinking "WTF?" the answer is "For illustration I went with something that should be fairly clear to non-Perl people" and "I'm trying to use as many different types of variable as possible."
Most modern languages have caught up to Perl5 in terms of basic regex power, so using Perl5 for its regex is no longer quite so essential in that you can probably get as powerful a system as you probably need in any language. That said, Perl5 *still* has regex features no one else has (or perhaps that no one else is crazy enough to implement.) For better or for worse, it's still the best... ...until you look at Perl6. Okay, so Perl6 is not done yet, but when it is the bar for regular expressions will instantly go up again. There's absolutely no competition for what it does, no other language has first class Perl6-style regex.
Smart cards neat kill the stickynote-on-monitor and password-too-weak problems dead. The main problem is inevitably some things don't support SSO.
For inside a big (or small!) company smartcards will eliminate a huge weakness. Requiring remote employees to log in via cert is even better, if you can afford it, because after that phishing loses some effectiveness ("Oh great, an attacker got the boss to send his PIN again. Too bad it's useless without the private key on his card.")
It's not a silver bullet but it does help for a certain class of problem. For the web... now there's another story, we don't have anything close to the right infrastructure to support generic smart card SSO. I had been hoping that OpenID would solve this: get all sites to adopt it, let most keep using passwords and let ME set up a provider that will auth me via smart card.
It's worse than that.
It only takes one site you use being compromised and having its hashed password list stolen, then all passwords brute-forced by rainbowtable, then the table distributed. An attacker targeting you simply gets your decrypted site password from the table by grepping your email address, sees the obvious pattern and now you're busted. If you think this is far-fetched "And no one is targeting me anyway," think again. Are you sure no one will for the lifetime of any of these sites? Are you sure no bad actor will *automate* this process at any time between now and when you no longer have any accounts protected by passwords?
Entirely random garbage of > 21 characters is required for security. It's not "How valuable is the data on site $foo?" or "How much do I trust site $bar?" that should worry you, instead it's "In the event that this password plaintext becomes known, how screwed would I be?" -- if compromising one password *could lead* to another of your passwords being compromised then you must increment your screwed level based on the damage from both the original compromised password and all other potentially compromised passwords. You *must* assume that the plaintext for any given site *WILL* become known sooner or later, that is simply the reality of web-based password authentication today.
If you insist on sticking with alpha-based word-based passwords with obvious changing bits then I recommend that the passphrase you choose have a minimum of 40 characters.
Two words: port knocking.
You may laugh but it hides you from casual attackers pretty definitively. IOW, bot net brute forcers no longer clog up my auth log.