They don't? The methodology isn't perfect, but we're not talking about calculating tolerances for a bridge or determining what hunk of tissue to excise during brain surgery here. In other words, a blunt metric is all we're looking for (and is certainly more reliable than a quote from an individual with a direct interest in promoting the language).
Oh, and here, or more specificly here is one metric reflecting a significant drop in popularity for Perl relative to other languages.
That isn't to say Perl is "bad" or going away any time soon. The huge installed base and extensive module repository ensures its longevity (and even as it wanes a larger job market) but as time goes on fewer new projects (both public and internal) are choosing Perl as the implementation language. It was never particularly strong as a desktop application language - Python seems the leader there - and it has long since been eclipsed by PHP as a web development language.
Perl's strongest area is in it's roots as a quick and often dirty language used by administrators. Unlike developers admins are relatively unlikely to go language shopping and most of the deficiencies of Perl are relatively unimportant for that type of work.
Eh, two options for code blocks (do-end and braces) is hardly damning. And some of us consider Ruby's sane use of sigils to be an advantage.:) How does $global_var, @@class_var, @instance_var, local_var make for unreadable code? Or did you have other funny characters in mind?
I've often said that CPAN is both perl's biggest stength and it's biggest weakness. For any given need there are at least five diffent modules, at least three abandoned (but often still widely used). Great for one-off tasks and quick-and-dirty prototyping but generally a pain in the ass for any sort of long term maintenance, especially if you have more than one person writing code. Then you end up with one person useing TimeDate, another using Date::Manip, another using Date::Calc, another parsing dates with regexps and so forth. And of course if you ever want to package anything be prepared for a million dependencies because this module author decided to use an "improved" make system, another decided to use a half dozen esoteric test harnesses, another uses a custom object system, etc, etc.
I think my record is twelve packages to fulfill a request for one module.
List price is marginally lower, yes. It's an apples to oranges comparison, though, since Sun is covering an operating system and a small number of bundled applications (Apache, Bind, Sendmail, WU-FTPd, OpenSSH, Samba and a few other minor components). The subscriptions from Red Hat are far more comprehensive, covering software that Sun ships with Solaris but cover with the support contract (e.g. MySQL and Postgresl) as well as a ton of additional software that Sun doesn't even ship (Postfix, Exim, VS-FTPd, lighttpd, Tomcat, Dovecot, blah, blah, blah, etc).
Fair point about load average (find a lot of people get needlessly hysterical about that without looking at other metrics), though I'm not generally fond of relying on vertical scaling to that extent.
As for the rest, where exactly did I say we left broken hardware in production? Failed machines are pulled for diagnostic and root cause analysis. It may be relatively rare compared to some vendors, but Sun hardware can and does fail and Sun software can and does fail to handle it gracefully sometimes. We've hit undetected cpu faults, firmware bugs and of course the fucked cache modules Sun was shipping in the older Enterprise servers for a while.
And no, it had nothing to do with user actions. The only applications we've run on Solaris machines are databases. Only a handful of highly trusted admins even have access and in none of the cases was anyone logged in.
Academic matter, anyways. We're largely abandoning Solaris. We're getting far better price/performance on x86 hardware and the reliability advantage is minimal to non-existent. Not that we trust the reliability of a single machine anyways.
A load of 80 on a 32 cpu system sounds like a poorly architected solution to me.:)
As for the rest, give me a break. One of the benefits Linux is that if you want cutting edgeness and desktop goodies you can have them, but if you're looking for stability and vendor support you can have that too. And it doesn't mean spending a ton of money either - RHEL is relatively cheap and Debian is free (no idea what you're smoking there), as are a number of other options (CentOS, Ubuntu LTS, etc).
We run hundreds of servers on Linux servicing millions of subscribers and have absolutely no stability issues whatsoever. Machines occasionally go down due to hardware faults, power incidents or kernel upgrades, but only a handful of kernel related failures over the years. We've actually had more failures with our Sparc/Solaris machines, generally exhibiting as spontaneous reboots.
It's a mess in the audio department. The oldest versions use OSS output, which works fine but is antiquated. The current stable one does ALSA by default, but implements it poorly (which in turns makes it incompatible with PulseAudio which is being adopted by most distributions). There's a library called libflashsupport that adds additional outputs but sometimes causes the plugin to crash, so it's recommended to run it inside nspluginwrapper, even on the native platform. And finally there's the beta version of 10, which includes native PulseAudio support but tickles a bug in FF3 and crashes the whole browser.
To be fair to Adobe a big part of the problem is the moving target that is Linux audio - from OSS to ESD and ARTS to ALSA to Pulse, along with other sound servers and frameworks and so forth (e.g. Jack, NAS). I just hope with all the major distributions embracing PA we can maybe see an end to the mess.
Erm, Silverlight 2 is already out in beta, with new controls released under a public license. The Moonlight 2 team has alpha builds already.:)
Re:Not the only choice
on
Bash Cookbook
·
· Score: 1
Oh, bah. Somehow missed you were doing 'set' and not 'env'
Still, using "set | wc -l" as a measure of namespace polution isn't exactly honest, since that includes the bodies of the functions. Looks like it's more like 185 functions:
[mberg@samedi ~]$ set | egrep '^\{' | wc -l 184
And all but three of those are prefixed with an underscore:
[mberg@samedi ~]$ set | egrep '^_' | wc -l 181
That's hardly unreasonable.
Never bothered with command completion anyways. Most things are easier to just type out (or possibly pull out as a whole commend in an r-search).
Re:Not the only choice
on
Bash Cookbook
·
· Score: 1
Doesn't effect the number of environmental variables for me:
But... but... you can make that so much shorter in bash!
<begin super sweet optimized version> #!/bin/bash
perl <<< print '"hello world\n"' <end super sweet optimized version>
Re:Not the only choice
on
Bash Cookbook
·
· Score: 1
Eh? How does bash necessitate polluting your environment with variables ("set" shows variables not functions)? Gotta wonder what kind of retarded set-up you have on your box:
Yeah, Via has been woefully slow in bringing announced products at times. I'm hoping the refocus will allow them to tighten their product cycle a bit. We hopefully won't be waiting long for a netbook though; there are already Openbook prototypes utilizing the ULV variant of the Nano (unsurprising since it's socket and chipset compatible with the C3/C7 line).
I'm interested in seeing what happens with the Atom, since Intel has the clout to push it pretty aggressively into the market. The power envelope is relatively impressive, but that appears to be a combination of superior fab and an awful lot of compromises (many of which mirror those made by Via in their last generation). The one advantage they seem to scale down to significantly lower power designs, but with a diminished feature set (no 64-bit instructions, no virtualization), lower clock and bus speeds (800MHz on a 400MT/s bus compared to 1000MHz on a 533MT/s bus on Via's low end). If anything I would say that the Atom is reasonably positioned for handhelds, mobile internet devices and netbooks, while the Nano currently isn't really suitable for handhelds and might still be a bit power hungry for MIDs as well. On the other hand, it should provide a far more satisfying experience for netbooks, full size laptops and low power desktops.
Maybe Intel will manage reasonable performance with the upcoming dual core version of the chip, but given initial reviews (and the dearth of execution units) I suspect that will just move them from painful to adequate.:) And so far as I know they still haven't released their low power companion chipset to manufacturers. From prior presentations it sounds ill-suited to anything but handheld and MID devices, given the performance figures provided for the PowerVX graphics core they licensed.
And of course Via is likely to refresh the Eden platform around the new architecture. Even without process improvements they could trim the caches (which are responsible for much of the size premium over the Atom) and push the clock rate way down. Even down at 400-500MHz like their ULV designs (some as low as 1W peak draw) they should be able to beat the pants of the 800-1000MHz Atom parts.
It wouldn't be new for them. Their last generation they had the CoreFusion, which is essentially a Via C3 on the same die as the CN400 (which includes their Unichrome Pro IGP).
This current generation I wonder if they won't stick with a cpu coupled with a low power integrated north/southbridge rather than the cpu/northbridge + discrete southbridge combo, though. A Nano @ 1GHz with a VX800U chipset likely beats the old CoreFusion architecture in terms of system power consumption (7.5 watts for the Nano/VX800U vs 6 watts for the 533MHz CoreFusion; not seeing a published TDP for their south bridge options, but since none of them are specifically aimed at the mobile market, I doubt they would be less than a couple watts).
It will be nice if they come out with a full SoC as part of their ultra low power strategy, though. Guess we'll see when they start transitioning the Eden platform to the new core. A full solution running at, say, 2-3W peak would be very nice indeed.
It doesn't matter if the signing request or certificate are modified, though. The request originator can easily validate that the certificate since he holds the private key. And the point isn't to authenticate an individual, just a domain. In theory, yes, intercepting a particular SMTP transmission is entirely possibly. In practice it's far from trivial. Ideally it would be nice if e-mail verification required DKIM or at minimum SPF, but even current practice represents a significant increase in security over a self-signed cert.
As for authenticating companies, who cares about physical forms? The important bit is tying to a legal entity, which doesn't strike me as a particularly difficult problem. Check for legal registration, verify the registered location, verify a principal individual in the company. The requirements set forth by the CA/Browser forum are actually quite good, overall.
Remember, security can never make a breach impossible. The goal is to make it hard enough it's not worth trying.
The certificate originates with the CA, so of course they know it's authentic.
It seems like you're not actually familiar with how thi works:
1) The site administrator generates a key pair. The private key is never ever transmitted to anyone - not the certificate authority, not the end user.
2) The site administrator generates a signing request and sends it to the certificate authority; this contains only the public key and data which will be included in the certificate (including the "common name", which is the FQDN the certificate is intended for).
3) The certificate authority gives back back a certificate.
None of the communication here contains any privileged information, which is part of the beauty of PKI. Secure transmission simply isn't necessary.
What you do need is some form of validation. For a basic certificate the aim is to tie a certificate to a domain owner. A simple mail to a privileged account name (or even better, one on file with the registrar as an authorized contact) is simple and reasonably effective.
For extended verification, where the goal is to validate a certificate against a legal entity, the process is far more involved and does require a physical meeting (if not with the CA directly, with an appointed third party validator or notary) as well as proof of legal existence (with onus on the issuing CA to validate and cross-check the information). These certificates are required to be backed by multi-million dollar policies with an agency in good standing.
Certificates aren't private. They're transmitted to any client attempting a connection. The only private component is the private key, which the CA never sees.
Slashdot Mirror
They don't? The methodology isn't perfect, but we're not talking about calculating tolerances for a bridge or determining what hunk of tissue to excise during brain surgery here. In other words, a blunt metric is all we're looking for (and is certainly more reliable than a quote from an individual with a direct interest in promoting the language).
And it's not like there aren't corroborating sources like Google trends, Sourceforge statistics (a bit old but still relevent), book sales and so forth.
Oh, and here, or more specificly here is one metric reflecting a significant drop in popularity for Perl relative to other languages.
That isn't to say Perl is "bad" or going away any time soon. The huge installed base and extensive module repository ensures its longevity (and even as it wanes a larger job market) but as time goes on fewer new projects (both public and internal) are choosing Perl as the implementation language. It was never particularly strong as a desktop application language - Python seems the leader there - and it has long since been eclipsed by PHP as a web development language.
Perl's strongest area is in it's roots as a quick and often dirty language used by administrators. Unlike developers admins are relatively unlikely to go language shopping and most of the deficiencies of Perl are relatively unimportant for that type of work.
More specifically that quote is from Richard Dice, president of the Perl Foundation. Can't imagine why he would speak highly of Perl. ;)
We have hundreds of terabytes in LVM, with no issues. Also:
Or $0/year, but that seems to be lost in the hysterics right now.
Eh, two options for code blocks (do-end and braces) is hardly damning. And some of us consider Ruby's sane use of sigils to be an advantage. :) How does $global_var, @@class_var, @instance_var, local_var make for unreadable code? Or did you have other funny characters in mind?
I've often said that CPAN is both perl's biggest stength and it's biggest weakness. For any given need there are at least five diffent modules, at least three abandoned (but often still widely used). Great for one-off tasks and quick-and-dirty prototyping but generally a pain in the ass for any sort of long term maintenance, especially if you have more than one person writing code. Then you end up with one person useing TimeDate, another using Date::Manip, another using Date::Calc, another parsing dates with regexps and so forth. And of course if you ever want to package anything be prepared for a million dependencies because this module author decided to use an "improved" make system, another decided to use a half dozen esoteric test harnesses, another uses a custom object system, etc, etc.
I think my record is twelve packages to fulfill a request for one module.
List price is marginally lower, yes. It's an apples to oranges comparison, though, since Sun is covering an operating system and a small number of bundled applications (Apache, Bind, Sendmail, WU-FTPd, OpenSSH, Samba and a few other minor components). The subscriptions from Red Hat are far more comprehensive, covering software that Sun ships with Solaris but cover with the support contract (e.g. MySQL and Postgresl) as well as a ton of additional software that Sun doesn't even ship (Postfix, Exim, VS-FTPd, lighttpd, Tomcat, Dovecot, blah, blah, blah, etc).
Fair point about load average (find a lot of people get needlessly hysterical about that without looking at other metrics), though I'm not generally fond of relying on vertical scaling to that extent.
As for the rest, where exactly did I say we left broken hardware in production? Failed machines are pulled for diagnostic and root cause analysis. It may be relatively rare compared to some vendors, but Sun hardware can and does fail and Sun software can and does fail to handle it gracefully sometimes. We've hit undetected cpu faults, firmware bugs and of course the fucked cache modules Sun was shipping in the older Enterprise servers for a while.
And no, it had nothing to do with user actions. The only applications we've run on Solaris machines are databases. Only a handful of highly trusted admins even have access and in none of the cases was anyone logged in.
Academic matter, anyways. We're largely abandoning Solaris. We're getting far better price/performance on x86 hardware and the reliability advantage is minimal to non-existent. Not that we trust the reliability of a single machine anyways.
To be fair, ZFS is a lot more than just a filesystem. It encompasses snapshotting, redundancy and volume management as well.
Not to mention that an uptime of years generally means someone hasn't been keeping their system patched properly. :)
A load of 80 on a 32 cpu system sounds like a poorly architected solution to me. :)
As for the rest, give me a break. One of the benefits Linux is that if you want cutting edgeness and desktop goodies you can have them, but if you're looking for stability and vendor support you can have that too. And it doesn't mean spending a ton of money either - RHEL is relatively cheap and Debian is free (no idea what you're smoking there), as are a number of other options (CentOS, Ubuntu LTS, etc).
We run hundreds of servers on Linux servicing millions of subscribers and have absolutely no stability issues whatsoever. Machines occasionally go down due to hardware faults, power incidents or kernel upgrades, but only a handful of kernel related failures over the years. We've actually had more failures with our Sparc/Solaris machines, generally exhibiting as spontaneous reboots.
It's a mess in the audio department. The oldest versions use OSS output, which works fine but is antiquated. The current stable one does ALSA by default, but implements it poorly (which in turns makes it incompatible with PulseAudio which is being adopted by most distributions). There's a library called libflashsupport that adds additional outputs but sometimes causes the plugin to crash, so it's recommended to run it inside nspluginwrapper, even on the native platform. And finally there's the beta version of 10, which includes native PulseAudio support but tickles a bug in FF3 and crashes the whole browser.
To be fair to Adobe a big part of the problem is the moving target that is Linux audio - from OSS to ESD and ARTS to ALSA to Pulse, along with other sound servers and frameworks and so forth (e.g. Jack, NAS). I just hope with all the major distributions embracing PA we can maybe see an end to the mess.
Erm, Silverlight 2 is already out in beta, with new controls released under a public license. The Moonlight 2 team has alpha builds already. :)
Oh, bah. Somehow missed you were doing 'set' and not 'env'
Still, using "set | wc -l" as a measure of namespace polution isn't exactly honest, since that includes the bodies of the functions. Looks like it's more like 185 functions:
[mberg@samedi ~]$ set | egrep '^\{' | wc -l
184
And all but three of those are prefixed with an underscore:
[mberg@samedi ~]$ set | egrep '^_' | wc -l
181
That's hardly unreasonable.
Never bothered with command completion anyways. Most things are easier to just type out (or possibly pull out as a whole commend in an r-search).
Doesn't effect the number of environmental variables for me:
[mberg@samedi ~]$ env | wc -l /etc/bash_completion
38
[mberg@samedi ~]$ complete -p | wc -l
0
[mberg@samedi ~]$ .
[mberg@samedi ~]$ env | wc -l
38
[mberg@samedi ~]$ complete -p | wc -l
500
Linux still uses the outmoded FHS at the front end
If the user is poking around the filesystem manually looking for applications or libraries, you've already lost.
Linux needs to stop preaching about free software and get back to wor
Linux is a kernel. It doesn't preach.
Users don't want to be rebuffed with the old 'that's the great thing about FOSS - if there's something you don't like, you fix it yourself' line
Ascribing the surly attitudes of some developers to the community at large is highly disingenous.
But... but... you can make that so much shorter in bash!
<begin super sweet optimized version>
#!/bin/bash
perl <<< print '"hello world\n"'
<end super sweet optimized version>
Eh? How does bash necessitate polluting your environment with variables ("set" shows variables not functions)? Gotta wonder what kind of retarded set-up you have on your box:
[mberg@samedi ~]$ set | wc -l
73
Yeah, Via has been woefully slow in bringing announced products at times. I'm hoping the refocus will allow them to tighten their product cycle a bit. We hopefully won't be waiting long for a netbook though; there are already Openbook prototypes utilizing the ULV variant of the Nano (unsurprising since it's socket and chipset compatible with the C3/C7 line).
I'm interested in seeing what happens with the Atom, since Intel has the clout to push it pretty aggressively into the market. The power envelope is relatively impressive, but that appears to be a combination of superior fab and an awful lot of compromises (many of which mirror those made by Via in their last generation). The one advantage they seem to scale down to significantly lower power designs, but with a diminished feature set (no 64-bit instructions, no virtualization), lower clock and bus speeds (800MHz on a 400MT/s bus compared to 1000MHz on a 533MT/s bus on Via's low end). If anything I would say that the Atom is reasonably positioned for handhelds, mobile internet devices and netbooks, while the Nano currently isn't really suitable for handhelds and might still be a bit power hungry for MIDs as well. On the other hand, it should provide a far more satisfying experience for netbooks, full size laptops and low power desktops.
Maybe Intel will manage reasonable performance with the upcoming dual core version of the chip, but given initial reviews (and the dearth of execution units) I suspect that will just move them from painful to adequate. :) And so far as I know they still haven't released their low power companion chipset to manufacturers. From prior presentations it sounds ill-suited to anything but handheld and MID devices, given the performance figures provided for the PowerVX graphics core they licensed.
And of course Via is likely to refresh the Eden platform around the new architecture. Even without process improvements they could trim the caches (which are responsible for much of the size premium over the Atom) and push the clock rate way down. Even down at 400-500MHz like their ULV designs (some as low as 1W peak draw) they should be able to beat the pants of the 800-1000MHz Atom parts.
It wouldn't be new for them. Their last generation they had the CoreFusion, which is essentially a Via C3 on the same die as the CN400 (which includes their Unichrome Pro IGP).
This current generation I wonder if they won't stick with a cpu coupled with a low power integrated north/southbridge rather than the cpu/northbridge + discrete southbridge combo, though. A Nano @ 1GHz with a VX800U chipset likely beats the old CoreFusion architecture in terms of system power consumption (7.5 watts for the Nano/VX800U vs 6 watts for the 533MHz CoreFusion; not seeing a published TDP for their south bridge options, but since none of them are specifically aimed at the mobile market, I doubt they would be less than a couple watts).
It will be nice if they come out with a full SoC as part of their ultra low power strategy, though. Guess we'll see when they start transitioning the Eden platform to the new core. A full solution running at, say, 2-3W peak would be very nice indeed.
It doesn't matter if the signing request or certificate are modified, though. The request originator can easily validate that the certificate since he holds the private key. And the point isn't to authenticate an individual, just a domain. In theory, yes, intercepting a particular SMTP transmission is entirely possibly. In practice it's far from trivial. Ideally it would be nice if e-mail verification required DKIM or at minimum SPF, but even current practice represents a significant increase in security over a self-signed cert.
As for authenticating companies, who cares about physical forms? The important bit is tying to a legal entity, which doesn't strike me as a particularly difficult problem. Check for legal registration, verify the registered location, verify a principal individual in the company. The requirements set forth by the CA/Browser forum are actually quite good, overall.
Remember, security can never make a breach impossible. The goal is to make it hard enough it's not worth trying.
The certificate originates with the CA, so of course they know it's authentic.
It seems like you're not actually familiar with how thi works:
1) The site administrator generates a key pair. The private key is never ever transmitted to anyone - not the certificate authority, not the end user.
2) The site administrator generates a signing request and sends it to the certificate authority; this contains only the public key and data which will be included in the certificate (including the "common name", which is the FQDN the certificate is intended for).
3) The certificate authority gives back back a certificate.
None of the communication here contains any privileged information, which is part of the beauty of PKI. Secure transmission simply isn't necessary.
What you do need is some form of validation. For a basic certificate the aim is to tie a certificate to a domain owner. A simple mail to a privileged account name (or even better, one on file with the registrar as an authorized contact) is simple and reasonably effective.
For extended verification, where the goal is to validate a certificate against a legal entity, the process is far more involved and does require a physical meeting (if not with the CA directly, with an appointed third party validator or notary) as well as proof of legal existence (with onus on the issuing CA to validate and cross-check the information). These certificates are required to be backed by multi-million dollar policies with an agency in good standing.
Certificates aren't private. They're transmitted to any client attempting a connection. The only private component is the private key, which the CA never sees.
Erm, how is Vala any less cross-platform than Gnome itself is? And being tightly integrated with GObject is kind of the point. :)