The point is, he was saying you can most of the time assume that at least one person will have a weak password.
I was replying to a post that claimed JTR could crack every password. In a reasonable time, even years, it can't unless all the passwords are very weak. I have run it on files with hundreds of accounts and have cracked some accounts within seconds. Unobfuscated dictionary passwords will get cracked immediately.
JohnTheRipper is not good for even semi secure passwords. I ran it for a month 24/7 against a password I didn't consider all that strong and it couldn't crack it. Sure, it can crack weak or semi-weak passwords quickly, but a few special characters renders it nearly useless.
Re:no perl scripts should forget...
on
Perl Medic
·
· Score: 1
If your regex stuff goes "off the page"... I really hope I don't have to maintain that code (e.g. I read it as 100+ regexps, not one big regexp).
First off, 'off the page' can be 40-50 lines. At most, that's 5 nicely formatted regexes and resulting operations, not 100+. That is hardly an unreasonable number. If you can have one page open with 100 regexes visible, well, I don't want to maintain your code either.
Second, I have to deal with public domain files that I have no control over the formatting. For example, NCBI Unigene files use '//' as a record delimiter. Each record can contain a dozen different types of information for a single gene and can go on for hundreds of lines. One record could be 3 lines and contain only 3 peices of information, the next record could contain twenty or a hundred times as much data. A single line of data (out of a record that could be hundreds of lines) might contain anywhere from 1 to 50 more pieces of information, some uniformly delimited, some not.
As I said, I have no control of the format but I still need to parse it. This can easily require 10 or more regexes and what ever you need to do with the data per record. This is only one example. I have to deal with all kinds of wacky formats.
As far as the map map map example, that's exactly why it's frowned on. It's not a good idea to do it and it's exactly what leads to unreadable code - trying to perform 50 operations on a set of data in 5 lines just because you can and it looks cool (to you, the only person who can understand it.) No one here is going to get chewed out for writing:
my %hash = map { $_, 1 } @array;
As I said earlier, I work on a very large number of lines of Perl. Any code that follows our guidelines is eminently readable. Most of the code that doesn't, isn't. And that's not just me talking, it's when new developers join the team. Large scale Perl apps probably require the most discipline when it comes to coding guidelines. Otherwise, what everyone here says about Perl not being maintainable is absolutely true.
(which can be hard to deciper as well as inefficient speed wise when compared to other loops)
Also, if you have a series of regexes, it's nice to have some clue what you are searching through once the assignment to $_ is off the page.
As I said here, I think for serious projects, you have to really strict with guidelines when using perl for large projects. If it's just some personal script, do what ever you want. But I am talking about two hundred thousand lines and developers of very different skill levels. Control and consistency is very important.
Comments to come: blah, Perl hard to read/maintain
on
Perl Medic
·
· Score: 4, Funny
Why would you want to intentionally fuck up your car's computer? Hacking a server is one thing, but hacking your car? That seems like want to test the fireproofing in your house.
HowTo: How To Deal With A Shitty Book:
on
Apache Jakarta Commons
·
· Score: 5, Insightful
If you don't mind dropping $99, ChartDirector is pretty good. Good documentation, lots of features, good support, responsive to bug reports. It runs on Windows, Linux and FreeBSD.
Another issue I have with sharp is while they're all about Linux on the PDA, they don't seem interested in writing software to sync the PDA with a Linux workstation.
Say, what is the state of syncing software for linux these days? I still use JPilot. Is there anything better? Course, I haven't upgraded JPilot in three years so maybe it has more features.
Slashdot Mirror
The point is, he was saying you can most of the time assume that at least one person will have a weak password.
I was replying to a post that claimed JTR could crack every password. In a reasonable time, even years, it can't unless all the passwords are very weak. I have run it on files with hundreds of accounts and have cracked some accounts within seconds. Unobfuscated dictionary passwords will get cracked immediately.
Send a bill to your predecessor for the cost of a new license. It was his responsibility. It was a company asset. He lost it.
Yeah. He'd have a good laugh as he walked toward the trash can...
JohnTheRipper is not good for even semi secure passwords. I ran it for a month 24/7 against a password I didn't consider all that strong and it couldn't crack it. Sure, it can crack weak or semi-weak passwords quickly, but a few special characters renders it nearly useless.
Should be from the-captain-of-the-obvious-department.
Anti-trust.
I seriously doubt the courts would approve such a purchase.
Linux: Are you coming or what?
More like:
Linux: Hey, are you going to eat that?
It's not.
If your regex stuff goes "off the page"... I really hope I don't have to maintain that code (e.g. I read it as 100+ regexps, not one big regexp).
First off, 'off the page' can be 40-50 lines. At most, that's 5 nicely formatted regexes and resulting operations, not 100+. That is hardly an unreasonable number. If you can have one page open with 100 regexes visible, well, I don't want to maintain your code either.
Second, I have to deal with public domain files that I have no control over the formatting. For example, NCBI Unigene files use '//' as a record delimiter. Each record can contain a dozen different types of information for a single gene and can go on for hundreds of lines. One record could be 3 lines and contain only 3 peices of information, the next record could contain twenty or a hundred times as much data. A single line of data (out of a record that could be hundreds of lines) might contain anywhere from 1 to 50 more pieces of information, some uniformly delimited, some not.
As I said, I have no control of the format but I still need to parse it. This can easily require 10 or more regexes and what ever you need to do with the data per record. This is only one example. I have to deal with all kinds of wacky formats.
As far as the map map map example, that's exactly why it's frowned on. It's not a good idea to do it and it's exactly what leads to unreadable code - trying to perform 50 operations on a set of data in 5 lines just because you can and it looks cool (to you, the only person who can understand it.) No one here is going to get chewed out for writing:
my %hash = map { $_, 1 } @array;
As I said earlier, I work on a very large number of lines of Perl. Any code that follows our guidelines is eminently readable. Most of the code that doesn't, isn't. And that's not just me talking, it's when new developers join the team. Large scale Perl apps probably require the most discipline when it comes to coding guidelines. Otherwise, what everyone here says about Perl not being maintainable is absolutely true.
Short answer, no with a but:
No, not right away, but given enough time probably.
Long answer, yes with a maybe:
Yes, it will...but maybe you'll be dead by the time it happens.
3 lines?!
/\s+/, ;
print scalar split
Ok, so we do use it with grep. We frown on map because it can lead to resource hogging if you
my @results = map { }
map { }
map { } @a_very_big_array;
(which can be hard to deciper as well as inefficient speed wise when compared to other loops)
Also, if you have a series of regexes, it's nice to have some clue what you are searching through once the assignment to $_ is off the page.
As I said here, I think for serious projects, you have to really strict with guidelines when using perl for large projects. If it's just some personal script, do what ever you want. But I am talking about two hundred thousand lines and developers of very different skill levels. Control and consistency is very important.
s/shitty perl code/shitty code in any language/;
You can inherit shit in any language.
That's sort of like kicking Michael the hell out of Slashdot.
Why would you want to intentionally fuck up your car's computer? Hacking a server is one thing, but hacking your car? That seems like want to test the fireproofing in your house.
Stop reading it the minute you realize it's shit.
That's because desktop linux is making gains in the real world. Desktop linux: "It's not just in your parent's basement anymore."
Peter Svensson of the Associated Press has reviewed OpenOffice and declared it a Microsoft Office killer:
Anyone care to point out where this was said, because I obviously missed it when I RTFA...
Welcome to Slashspin, do you want lies with that?
Would one of those kinks be the OO version of PowerPoint?
The word we were looking for was pandemic. Pandemic.
Yeah, I did. When I was 10.
Uh, can't they already determine heights to high degree of accuracy with GPS or other radio wave methods? How would a picture be more accurate?
If you don't mind dropping $99, ChartDirector is pretty good. Good documentation, lots of features, good support, responsive to bug reports. It runs on Windows, Linux and FreeBSD.
Another issue I have with sharp is while they're all about Linux on the PDA, they don't seem interested in writing software to sync the PDA with a Linux workstation.
Say, what is the state of syncing software for linux these days? I still use JPilot. Is there anything better? Course, I haven't upgraded JPilot in three years so maybe it has more features.
It's like finding a species thought to be extinct! Seriously.