Yes, that is exactly what I was referring to when explaining its threading model. That warning was (quite recently) added because people thought the implementation'd be like in every other language, but it isn't.
The thread support has been the same for a long time. I'm not fond of its model, but I can't say it's bad either.
I can't really work much with the very vague description of 'sucked' though.
Perl uses a different thread model than most programming language: variables are explicitly shared (everything is thread-local by default), rather than implicitly (everything is shared). The implicit model gives you concurrency problems (race conditions). The explicit model gives you high memory usage.
I hear that some new programming languages [citation needed] are designed with the explicit model, so it's likely a matter of opinion which one is better.
You can also use the CPAN module of forks. It's a drop-in module that gives you higher performance / lower memory usage at the cost of slower cross-thread communication.
I've not significant experience with Perl's threads (as I said, I'm not fond of them), so take of this what you will.
Perl's real problem is that Perl has too long lacked critical features that other languages have been getting while Perl did not because of waiting for Perl 6.
So, what are these 'critical' features?
I can't think of almost any post-5.8 feature I could call 'critical', with the possible exception of better unicode support. 5.8 was released in 2002.
'Over a decade'? Come on, the cutting-edge of WWW in 2002-2005 was about this newfangled CSS that could replace table-based layouts. CSS Zen Garden, A List Apart etc. Those kinds of sites.
HTML5 has been around maybe four or five years at most? (Okay, I double-checked. 2008-2009 seems to be the correct year when browsers started implementing it.)
With Flash a 2004 Sempron has no trouble playing 720P at 30FPS
Really? My experience is that it takes 4-10 times the cpu power to play a video with flash than with a stand-alone (optimised) video player. (No GPU decoding or anything, just 'xv' video acceleration.)
The new HTML5 video playback that's been pushed to web browsers is far from optimised (read: rubbish) as well, but it's roughly on par with Flash, give or take 50 %.
assl was written by Marco Peereboom in order to hide the awful OpenSSL API. It strives to reuse openssl(1) APIs and provide a much simpler and sane interface for programmers that are interested in writing applications that require the SSL/TLS protocol for secure communications.
I think the BSDs are much more worthwhile than Debian: they produce code; Debian mostly just packages others' code.
NetBSD, DragonflyBSD, OpenBSD, FreeBSD. Pick one.
OpenBSD seems perpetually short on cash, yet they spend their time on very important projects (OpenSSH, LibreSSL, OpenNTPD) which are worth supporting even if you don't personally use them.
You know, in 2009 I downloaded an album from TPB by a fairly obscure jazz pianist. He decided to use torrents to promote his music: His album is named 'Share' and the album art contains the text 'Copyright is for losers'.
He's still obscure. Probably under 1000 people downloaded it. Last.fm counts 8 200 unique listeners.
Baptiste Trotignon, in case you're interested. Good music, in my opinion.
You need to be popular to be popular on the pirate sites.
In short: To render text properly in Japanese, you need a Japanese font. To render text properly in Chinese, you need a Chinese font. It's not just because of character coverage, but because of a thing called Han unification the consortium did.
The Unicode consortium decided to map similar characters to the same code-point. Personally, I'm not particularly bothered by this. but it leads to the technical problem that each text must be supplied with a language tag to select a correct font.
And this is problematic when there are two CJK languages mixed in the same document -- in the GP's case, Chinese and Japanese --, or when a program must automatically decide which font to render things in.
Take a web browser for example. It reaches a random Chinese web page, encoded in UTF-8. The page's author never bothered adding a language tag. Now the web browser must guess whether to render the page in a Chinese font or a Japanese one. And a "guess" is really all that it can do.
(Typically, software used base the guesses on the user's locale. It's pretty accurate -- Chinese users tend to view Chinese documents, Japanese Japanese ones. But the problems start when someone tries viewing a 'foreign' document...)
It's really quite ironic that the consortium decided on codepoint unification for the three languages that would most benefit from Unicode.
Scripting language quicker to develop in than a rigid OO language known for its verbosity! News at eleven!
(I realise some people may not like the term 'scripting language'; basically, I mean all the languages that typically don't need a separate compilation step. I love them.)
I've turned off the data connection and all apps, and set all the power-saving tunables I could find, yet my MB526 aka Motorola Defy+ still can't do more than two days without a charge. So I was very much not surprised.
(Yes, even if I don't fiddle with it one bit. Make no phone calls. The display stays off for the whole time.)
The Berne Convention treaty requires a minimum of 50 years.
No, it requires a minimum of life + 50 years. This was changed in the 1948 revision of the convention. Before that, the treaty did not dictate a minimum copyright length.
Oddly enough, the United States didn't sign the convention until 1989. I wonder who lobbied for life+50 back then. Certainly not the MPAA?
Anyone wanting to legislate sane copyright lengths will have to break an international treaty to achieve it.
The diffs are huge every single time, despite the releases being boring bug and security fixes. Things that shouldn't need more than twenty lines each.
That's for brute-forcing every combination. On average, you only need to brute-force half of them, so halve those numbers.
So yes, the shorter ones can be weak to a dictionary attack as you say.
That being said, I think that while a trillion guesses per second may be plausible, if a situation where the attacker can bruteforce that fast were to occur, the site has had at least two security vulnerabilities been taken advantage of: weak password hashing, and the vulnerability they used to download the users table.
The problems with diceware are that a big chunk of those words don't even sound like English ('69er', '1600', 'lu', 'zc', 'viva', '101st', 'pang', 'ijk') because they were chosen to be short, and that having the five-word passphrase necessary for some decent protection is still a lengthy 25-character passphrase you wouldn't want to keep typing ten times a day just to unlock the screensaver.
The physical dice are there to provide true randomness. Diceware actually recommends casino dice. In fact, they explicitly say: Do not use a computer program or electronic dice generator.
Yeah. Even Stackexchange (you know, that programmer place) does that. "Uppercase, punctuation, numbers. Pick two." My password there is now 'Password!'
when a dns lookup fails at parse time, do not abort but try again to resolve the hostname every 60 seconds fixes ntpd invocations before e. g. a dialup link is established and such. as we want ntpd to be a "fire and forget" background daemon it should cope with such situations. tested by many
Slashdot Mirror
Yes, that is exactly what I was referring to when explaining its threading model. That warning was (quite recently) added because people thought the implementation'd be like in every other language, but it isn't.
The thread support has been the same for a long time. I'm not fond of its model, but I can't say it's bad either.
I can't really work much with the very vague description of 'sucked' though.
Perl uses a different thread model than most programming language: variables are explicitly shared (everything is thread-local by default), rather than implicitly (everything is shared). The implicit model gives you concurrency problems (race conditions). The explicit model gives you high memory usage.
I hear that some new programming languages [citation needed] are designed with the explicit model, so it's likely a matter of opinion which one is better.
You can also use the CPAN module of forks. It's a drop-in module that gives you higher performance / lower memory usage at the cost of slower cross-thread communication.
I've not significant experience with Perl's threads (as I said, I'm not fond of them), so take of this what you will.
Perl's real problem is that Perl has too long lacked critical features that other languages have been getting while Perl did not because of waiting for Perl 6.
So, what are these 'critical' features?
I can't think of almost any post-5.8 feature I could call 'critical', with the possible exception of better unicode support. 5.8 was released in 2002.
'Over a decade'? Come on, the cutting-edge of WWW in 2002-2005 was about this newfangled CSS that could replace table-based layouts. CSS Zen Garden, A List Apart etc. Those kinds of sites.
HTML5 has been around maybe four or five years at most? (Okay, I double-checked. 2008-2009 seems to be the correct year when browsers started implementing it.)
With Flash a 2004 Sempron has no trouble playing 720P at 30FPS
Really? My experience is that it takes 4-10 times the cpu power to play a video with flash than with a stand-alone (optimised) video player. (No GPU decoding or anything, just 'xv' video acceleration.)
The new HTML5 video playback that's been pushed to web browsers is far from optimised (read: rubbish) as well, but it's roughly on par with Flash, give or take 50 %.
Guys. Just use OpenNTPD.
It's actively developed, and it doesn't have any of the bloat that is in the official ntpd. And it syncs clocks!
Brought to you by the OpenBSD project. Known for writing secure software.
People have done that before:
assl was written by Marco Peereboom in order to hide
the awful OpenSSL API. It strives to reuse openssl(1) APIs and provide a
much simpler and sane interface for programmers that are interested in
writing applications that require the SSL/TLS protocol for secure
communications.
I think the BSDs are much more worthwhile than Debian: they produce code; Debian mostly just packages others' code.
NetBSD, DragonflyBSD, OpenBSD, FreeBSD. Pick one.
OpenBSD seems perpetually short on cash, yet they spend their time on very important projects (OpenSSH, LibreSSL, OpenNTPD) which are worth supporting even if you don't personally use them.
NetBSD and FreeBSD are tax-deductible in the US.
You know, in 2009 I downloaded an album from TPB by a fairly obscure jazz pianist. He decided to use torrents to promote his music: His album is named 'Share' and the album art contains the text 'Copyright is for losers'.
He's still obscure. Probably under 1000 people downloaded it. Last.fm counts 8 200 unique listeners.
Baptiste Trotignon, in case you're interested. Good music, in my opinion.
You need to be popular to be popular on the pirate sites.
In short:
To render text properly in Japanese, you need a Japanese font. To render text properly in Chinese, you need a Chinese font. It's not just because of character coverage, but because of a thing called Han unification the consortium did.
The Unicode consortium decided to map similar characters to the same code-point. Personally, I'm not particularly bothered by this. but it leads to the technical problem that each text must be supplied with a language tag to select a correct font.
And this is problematic when there are two CJK languages mixed in the same document -- in the GP's case, Chinese and Japanese --, or when a program must automatically decide which font to render things in.
Take a web browser for example. It reaches a random Chinese web page, encoded in UTF-8. The page's author never bothered adding a language tag. Now the web browser must guess whether to render the page in a Chinese font or a Japanese one. And a "guess" is really all that it can do.
(Typically, software used base the guesses on the user's locale. It's pretty accurate -- Chinese users tend to view Chinese documents, Japanese Japanese ones. But the problems start when someone tries viewing a 'foreign' document...)
It's really quite ironic that the consortium decided on codepoint unification for the three languages that would most benefit from Unicode.
Scripting language quicker to develop in than a rigid OO language known for its verbosity! News at eleven!
(I realise some people may not like the term 'scripting language'; basically, I mean all the languages that typically don't need a separate compilation step. I love them.)
I've turned off the data connection and all apps, and set all the power-saving tunables I could find, yet my MB526 aka Motorola Defy+ still can't do more than two days without a charge. So I was very much not surprised.
(Yes, even if I don't fiddle with it one bit. Make no phone calls. The display stays off for the whole time.)
The Berne Convention treaty requires a minimum of 50 years.
No, it requires a minimum of life + 50 years. This was changed in the 1948 revision of the convention. Before that, the treaty did not dictate a minimum copyright length.
Oddly enough, the United States didn't sign the convention until 1989. I wonder who lobbied for life+50 back then. Certainly not the MPAA?
Anyone wanting to legislate sane copyright lengths will have to break an international treaty to achieve it.
The diffs are huge every single time, despite the releases being boring bug and security fixes. Things that shouldn't need more than twenty lines each.
% diff -rNU 0 openssl-1.0.1[lm]|wc
675635 2681760 21556437
Twenty-one megabytes. 675 thousand lines changed.
Here's the changelog between 1.0.1L and 1.0.1M, for two months of bugfixes:
Changes between 1.0.1l and 1.0.1m [19 Mar 2015]
*) Segmentation fault in ASN1_TYPE_cmp fix
[detailed descriptions snipped]
*) ASN.1 structure reuse memory corruption fix
*) PKCS7 NULL pointer dereferences fix
*) DoS via reachable assert in SSLv2 servers fix
*) Use After Free following d2i_ECPrivatekey error fix
*) X509_to_X509_REQ NULL pointer deref fix
*) Removed the export ciphers from the DEFAULT ciphers
Twenty-one megabytes for seven fixes. What the hell are they doing with their source code to create that much churn?
'A trillion guesses per second':
7776 ** 1 / 1e12 = 0,008 microseconds
7776 ** 2 / 1e12 = 0,060 milliseconds.
7776 ** 3 / 1e12 = 470 milliseconds
7776 ** 4 / 1e12 = 61 minutes
7776 ** 5 / 1e12 = 329 days
That's for brute-forcing every combination. On average, you only need to brute-force half of them, so halve those numbers.
So yes, the shorter ones can be weak to a dictionary attack as you say.
That being said, I think that while a trillion guesses per second may be plausible, if a situation where the attacker can bruteforce that fast were to occur, the site has had at least two security vulnerabilities been taken advantage of: weak password hashing, and the vulnerability they used to download the users table.
The problems with diceware are that a big chunk of those words don't even sound like English ('69er', '1600', 'lu', 'zc', 'viva', '101st', 'pang', 'ijk') because they were chosen to be short, and that having the five-word passphrase necessary for some decent protection is still a lengthy 25-character passphrase you wouldn't want to keep typing ten times a day just to unlock the screensaver.
The physical dice are there to provide true randomness. Diceware actually recommends casino dice. In fact, they explicitly say: Do not use a computer program or electronic dice generator.
Yeah. Even Stackexchange (you know, that programmer place) does that. "Uppercase, punctuation, numbers. Pick two." My password there is now 'Password!'
It's not a bug.
The commit log states this:
when a dns lookup fails at parse time, do not abort but try again
to resolve the hostname every 60 seconds
fixes ntpd invocations before e. g. a dialup link is established and such.
as we want ntpd to be a "fire and forget" background daemon it should
cope with such situations.
tested by many
Relevant diff: http://cvsweb.openbsd.org/cgi-...
(I'm assuming that the "bug" you found is that it's comparing the return value to -1 when the host() function can only return 0 or 1)