# Using implict variable $_ foreach ("a".."e") { print }
while (my $line = <>) { print $line if $line =~/Perl/; } #... or, using implict variables... while (<>) { print if/Perl/; }
The last one is definately more convenient in Perl, assuming the filter is only going to be used in this single context, and never refactored out for other use. That's something I fairly seldom need, apart from when I'm doing command line stuff - where I always use Perl rather than Ruby.
Apart from that, the Perl variants seem more awkward to me, though the Ruby variants seemed slightly odd until I "got" iterators.
For perl, I'd say scalar(@{$hash->{$subkey}}) definately looks more awkward than Ruby's hash[subkey].length - though the niceness of Ruby mostly shows up in slightly more complex programs.
Maybe our preference difference comes from what program space we tend to work in? I write very few small filtering apps - either my filtering is part of a larger app, or it's pure command line (where I, as I've repeatedly mentioned, think Perl is better.)
Eivind.
Re:Screensavers, music, and Unicode?
on
State of the Onion 9
·
· Score: 2, Interesting
Do you actually know Ruby? I know both, I program in both (mostly in Perl, for what-pay-my-bills reasons), and I've hardly ever found anything that I could express easier in Perl than in Ruby.
If there are things, I'm really curious to hear about them, as that should mean that there's some interesing Perl paradigms I don't know...
Eivind.
Re:Forced labour is not the open source way.
on
State of the Onion 9
·
· Score: 2, Insightful
s/has been a godsend for hundreds of thousands of programmers/has fooled hundreds of thousands of programmers into using an inappropriate tool/
Perl6 is, in my opinion, a mistake. Probably perl5 was also a mistake (I've written many tens of thousands of lines of code in Perl5, and work with it full time, so I have some idea what I'm talking about). Perl4 was decent, for doing what Perl4 was used for - the Perl5 extensions make it *seem like* Perl is usable for more tasks. Actually, it IS usable for more tasks, and even more so than perl4 - just like a screwdriver with something protecting the head is more usable as a hammer than a screwdriver without something protecting the head.
For the space that Perl5 and especially Perl6 is trying to fit into, Ruby is the best design I know of today - design-wise and convenience-wise it improve on Perl5 in almost every way.
There's three particular usecases where it doesn't improve: - Perl is better for one-liners (command line use). - Perl is better if you need some particular obscure library from CPAN - The change of the type system to actually have strong typing (instead of automatically converting between text and numbers) can be slightly inconvenient in some text parsing cases.
Apart from that, I've found Ruby to generally just be better. Half as much to type, more consistent, more powerful.
I'll note that your behaviour is *negative* influence when it comes to DFBSD achieving that goal.
Also, with all due respect to Matt, there are a LOT of others doing FreeBSD work, and while he is definately talented, he has never contributed anywhere near the same amount of code as all others combined.
As for problems with FreeBSD development: There have been some, and there's some that's resolved, and I definately welcome DFBSD to the table. It (fortunately) seems like it will be viable. Whether it will take the place of FreeBSD remains to be seen - their situation has both advantages and disadvantages, and in my opinion, only time can tell. I believe will depend more on the development of the two cultures and the infrastructure supporting them than on the present state of the codebases or particular individuals working on them (apart as culture providers.)
Well, let's just start actually paying for the cost of using fossil fuels. We can use markets to handle this.
How about adding the purchase of a mandatory insurance policy to all use of fossil fuel: You pay the market rate for an insurance policy to clean up the effects of that pollution, when/if necessary.
If your evidence is so compelling, there will be investors lining up on that side of the fence, and the price of that policy will be close to zip.
If the actual cost, as far as we can estimate, is high, that policy will be expensive.
If your data is better than the overall data, you can make a gazillion by investing on the right side, being in front of the price.
Put your money where your mouth is. And let's pay for our cleanup.
MOD PARENT DOWN with the (unfortunately fictous) "Wrong and stupid" moderation.
(A) We figured out Katrina fairly well
(B) The problem of figuring specific fluctionations in a chaothic system is different from predicting the attractors over time. Trivially: We can't predict if it will rain in two weeks - but we *can* predict that it will be hotter next July than it is right now (at least where I'm located.)
Being a "college graduate" in some random subject does not make you competent in every other subject in the world. For instance, I have no particular confidence in the competence of journalism majors when it comes to science.
In fact, I have little confidence in the particulars of newspaper information, as newspapers tend to be slightly wrong when they're writing about anything I'm an expert in. I suspect they're also slightly wrong when they write about things I am an *not* an expert in.
1. Peer review works, over time. I don't see it as "that horribly flawed", I see it has being possible to tweak to be even better. Even though everybody tries to be objective, there is a tendency to fads in science, and a tendency for new ideas to only be accepted as the wielders of the old flame dies. For an example, I seem to remember plate tectonics being blocked for a very long time until the blocker died. Removing prestige will make the process more objective.
And I'm not interested in whether people wave the banner of pseudo-science - or at least not interested enough to change how we do science to accomodate them. I'm interested in making how we do science work better.
2. The income from journals is 95% or so made from the subscriptions. These are kept by researchers in that small market. The researchers have to stay abreast with the research, so avoiding a 3 or 6 months delay is worth the cost. For those that just want to sort of track what's going on, a 6 month delay is acceptable.
As for author pays, most of the present research is done by universities. The calculations I saw indicate they'd spend just a trifle less with author pays, and get the ability to have more journals. And others could afford them. I agree that there is the lobby problem, yet that one is a problem no matter how we turn it. It's more of a problem with being able to pay for research than being able to pay for publication, anyway. I've been paid to do research that would place one company ahead of another if it panned out, and would be unpublishable with a null result. My time was more expensive than any publication fee. (And I didn't think of the possible ethical problem of doing that research until a short while after I was finished - and I haven't yet decided if it really was an ethical problem...)
3. I also just want the political people to keep their sausage fingers out of science. Scientists should decide what's "true" in science, and politicans should not change around based on who they agree with. I'm probably dreaming.
Sure. Peer reviewers know the identity of the person that wrote the article they are reviewing. This reinforce academic bias. I'd improve it by making the article submitters anonymous towards the reviewers.
Scientific articles are hard to get hold of without significant payment. I'd move to author pays, with a general release after three or six months.
The president of the US is subsidising the distribution of false science. I'd replace the president of the US.
We *always* use models to decide what to change, what policy to set. The question is how good the models are. Scientific models are, almost by defintition, the best ones we've got.
They're the agreement we come to after debate between the people that have put the effort into learning a subject.
There's a negative feedback loop between the quality of models and the prices following those models. Good models are used to trade on (and there's actually quite a bit of trading based on models). This change the price to account for any information in the models. Most of the really good models are in private software, and is making money for the people or company that wrote them.
RNAse is the bugbear of RNA work, its a normal part of every cell and its job it to break up RNA (which it does very well). When its in the cell its kept under close control, however if the cell is broken up (to extract RNA for example) the control is broken and it eats any RNA it can find
You're telling me God exists, and he put in protection against reverse engineering?
The article claims that BSD miss "PCI and framebuffer support". All BSDs have PCI support and have had so since 1994. At least FreeBSD, NetBSD, OpenBSD and DragonflyBSD have framebuffer support. In FreeBSD, the support for framebuffers was introduced in early november 1999. (For comparison, the Linux fbdev project was started in late december 1999.)
Next, a lot of standard features are referred to as "Linux" features. From the concept of kernel drivers to virtual terminals, these are implied to be Linux only features.
In my opinion, the architecture overview is OK. However, all statements about what isn't available on non-Linux platforms should be disregarded.
You seem to have knowledge in this area. Can you list some potential applications for those of us that are curious and lack detailed knowledge of material use (at least for hard materials)?
Your statements makean assumption that some of us aren't willing to make: That you (or I) as the author is going to be available to decide in each case.
I don't want that cost. I'm frequently unavailable, and I would like to make it possible for people to use some of my work then, too. I change e-mail addresses. I want people to be able to use some of my work when they can't get a current e-mail address for me.
At some point, I will be unavailable permanently. I'd like people to be able to use some of my works then, too.
These aren't works that I would negotiate a fee for. The cost of negotiating feesand giving permission would be too high compared to the few fees I would get.
describe a scheme that will work and allow all people involved to be making the same amount of money they're making now (not an unreasonable stipulation, I think).
I work with creating digital goods. I think it is a horribly unreasonable stipulation.
A parallel is the attempt at blocking the use of robots for production (and there were attempts), on the basis that "All the people involved should be making the same amount of money."
The question isn't how we can keep the status quo. The question is "How can we set up a system that maximize the value produced?" If we want professional production, it need to involve *some* form of compensation to authors, editors and publishers for the risk taken, and the time invested. Either through copyright or through something else.
As it is, we have large costs from the copyright system, in the form of very high transaction costs around licensing copyrighted works. The transcation costs of licensing is WAY higher than the cost of making the actual copy. On average, I'd guess it is at least ten time higher, often a hundred times higher.
Cutting these costs would be an enabler. As an example, Shakespeare worked as a collector and rewriter. His works would not be legal to write under the present copyright regime.
While gaining Shakespeare, we would lose Waterworld and soap operas - as that kind of investment in a single item require per-copy returns.
"Clearly, those companies would rather keep their changes proprietary,"
Your "Clearly" is anything but. I've worked with developing embedded systems based on FreeBSD. Roughly 90% of our changes were appropriate for giving back to the community and were given back to the community.
Keeping changes proprietary is a tradeoff - it forms a small barrier-to-entry, and impose maintenance costs compared to having them integrated. For most changes, the maintenance costs are higher than the value of lifting the barrier-to-entry.
In addition, by releasing the changes you get the value of being able to use the community expertise, and (often) of making your own employees happier.
But any single good hash should beat out any number of worse hashes.
Definately. As you note, the problem is predicting what is a "good" hash.
Personally I'd take SHA-8092 over using 4 128-bit digest hash programs, no matter what their implementation. Unless you can show me an attack that will reduce the complexity to below the others individually.
The real question is whether one is afraid of a "short circuit" attack, losing close to all security from a hash. I'm afraid of those. I'm also afraid of attacks that just reduce the complexity proportionally, so I'd use more than 128 bits per component - 256 bits at the least.
The point is to engineer against future attacks bringing down the effective hash length.
If I use the combination of an SHA-256, an iterated AES (Rijndael) 256 bit hash, and an iterated HPC (Hasty Pudding Cipher) as my hash function, it means that *each* of these algorithms have to be broken before I have a security problem, instead of getting a security problem from the break of a single algorithm.
The point is to be redundant against algorithmic breaks, not just to extend the key length.
Or at least as I understood the poster. (Not that I'd choose either SHA-1 or MD5 as my building block for that redundancy these days.)
... and lack the complexity of the fats that's normally in meat, and probably a bunch of other things.
Animals and meat are complicated things. Reproducing it in a lab won't create the same thing. Even feeding animals grain instead of grass doesn't create the same thing (bad omega 3 levels etc.)
It's not quite true that sending spam has no cost - the cost is just taken in somewhat randomly, just like speeding tickets.
The cost include:
At least three spammers murdered. At some point, I guess suicidal geeks will decide "If I'm going, why not take a spammer with me?" - though so far, it's been plain murders, perpetrator not caught.
Fines, like the $7M fine recently imposed against a spammer.
While both are needed, I think the former force is likely to be more effective than the latter.
The ultimate deterrent, of course, would be if some zillionaire decided to hire the mob to take care of spam. Scene (two men in suits at door of spammer): "Me and Josey wants to talk to you about those there emails."
I think most of these blogs have something of interest to somebody, and that the value of blogs is in their diversity - in a lot of things having value to a small number of people.
This effect is called the The long tail effect, and is visible all over the web. For instance, Amazon.com says that every day, it sells more books that didn't sell yesterday than the sum of books sold that *also* sold yesterday. In other words, they sell (in sum) more of the items selling less than one every other day than of items selling (by type) more than that.
Slashdot Mirror
Apart from that, the Perl variants seem more awkward to me, though the Ruby variants seemed slightly odd until I "got" iterators.
For perl, I'd say scalar(@{$hash->{$subkey}}) definately looks more awkward than Ruby's hash[subkey].length - though the niceness of Ruby mostly shows up in slightly more complex programs.
Maybe our preference difference comes from what program space we tend to work in? I write very few small filtering apps - either my filtering is part of a larger app, or it's pure command line (where I, as I've repeatedly mentioned, think Perl is better.)
Eivind.
Do you actually know Ruby? I know both, I program in both (mostly in Perl, for what-pay-my-bills reasons), and I've hardly ever found anything that I could express easier in Perl than in Ruby.
If there are things, I'm really curious to hear about them, as that should mean that there's some interesing Perl paradigms I don't know...
Eivind.
s/has been a godsend for hundreds of thousands of programmers/has fooled hundreds of thousands of programmers into using an inappropriate tool/
Perl6 is, in my opinion, a mistake. Probably perl5 was also a mistake (I've written many tens of thousands of lines of code in Perl5, and work with it full time, so I have some idea what I'm talking about). Perl4 was decent, for doing what Perl4 was used for - the Perl5 extensions make it *seem like* Perl is usable for more tasks. Actually, it IS usable for more tasks, and even more so than perl4 - just like a screwdriver with something protecting the head is more usable as a hammer than a screwdriver without something protecting the head.
For the space that Perl5 and especially Perl6 is trying to fit into, Ruby is the best design I know of today - design-wise and convenience-wise it improve on Perl5 in almost every way.
There's three particular usecases where it doesn't improve:
- Perl is better for one-liners (command line use).
- Perl is better if you need some particular obscure library from CPAN
- The change of the type system to actually have strong typing (instead of automatically converting between text and numbers) can be slightly inconvenient in some text parsing cases.
Apart from that, I've found Ruby to generally just be better. Half as much to type, more consistent, more powerful.
Eivind.
Also, with all due respect to Matt, there are a LOT of others doing FreeBSD work, and while he is definately talented, he has never contributed anywhere near the same amount of code as all others combined.
As for problems with FreeBSD development: There have been some, and there's some that's resolved, and I definately welcome DFBSD to the table. It (fortunately) seems like it will be viable. Whether it will take the place of FreeBSD remains to be seen - their situation has both advantages and disadvantages, and in my opinion, only time can tell. I believe will depend more on the development of the two cultures and the infrastructure supporting them than on the present state of the codebases or particular individuals working on them (apart as culture providers.)
Eivind (FreeBSD developer).
How about adding the purchase of a mandatory insurance policy to all use of fossil fuel: You pay the market rate for an insurance policy to clean up the effects of that pollution, when/if necessary.
If your evidence is so compelling, there will be investors lining up on that side of the fence, and the price of that policy will be close to zip.
If the actual cost, as far as we can estimate, is high, that policy will be expensive.
If your data is better than the overall data, you can make a gazillion by investing on the right side, being in front of the price.
Put your money where your mouth is. And let's pay for our cleanup.
Eivind.
(A) We figured out Katrina fairly well
(B) The problem of figuring specific fluctionations in a chaothic system is different from predicting the attractors over time. Trivially: We can't predict if it will rain in two weeks - but we *can* predict that it will be hotter next July than it is right now (at least where I'm located.)
Eivind.
Being a "college graduate" in some random subject does not make you competent in every other subject in the world. For instance, I have no particular confidence in the competence of journalism majors when it comes to science.
In fact, I have little confidence in the particulars of newspaper information, as newspapers tend to be slightly wrong when they're writing about anything I'm an expert in. I suspect they're also slightly wrong when they write about things I am an *not* an expert in.
Eivind.
And I'm not interested in whether people wave the banner of pseudo-science - or at least not interested enough to change how we do science to accomodate them. I'm interested in making how we do science work better.
2. The income from journals is 95% or so made from the subscriptions. These are kept by researchers in that small market. The researchers have to stay abreast with the research, so avoiding a 3 or 6 months delay is worth the cost. For those that just want to sort of track what's going on, a 6 month delay is acceptable.
As for author pays, most of the present research is done by universities. The calculations I saw indicate they'd spend just a trifle less with author pays, and get the ability to have more journals. And others could afford them. I agree that there is the lobby problem, yet that one is a problem no matter how we turn it. It's more of a problem with being able to pay for research than being able to pay for publication, anyway. I've been paid to do research that would place one company ahead of another if it panned out, and would be unpublishable with a null result. My time was more expensive than any publication fee. (And I didn't think of the possible ethical problem of doing that research until a short while after I was finished - and I haven't yet decided if it really was an ethical problem...)
3. I also just want the political people to keep their sausage fingers out of science. Scientists should decide what's "true" in science, and politicans should not change around based on who they agree with. I'm probably dreaming.
Eivind.
Scientific articles are hard to get hold of without significant payment. I'd move to author pays, with a general release after three or six months.
The president of the US is subsidising the distribution of false science. I'd replace the president of the US.
And there's probably more ;)
Eivind.
They're the agreement we come to after debate between the people that have put the effort into learning a subject.
Eivind.
Eivind.
You're telling me God exists, and he put in protection against reverse engineering?
Eivind.
Next, a lot of standard features are referred to as "Linux" features. From the concept of kernel drivers to virtual terminals, these are implied to be Linux only features.
In my opinion, the architecture overview is OK. However, all statements about what isn't available on non-Linux platforms should be disregarded.
Eivind (FreeBSD developer).
Eivind.
Anyway, to me it is immaterial, either way. I would consider the demise of television as entertainment a large step forward for humanity.
Eivind.
Eivind.
I don't want that cost. I'm frequently unavailable, and I would like to make it possible for people to use some of my work then, too. I change e-mail addresses. I want people to be able to use some of my work when they can't get a current e-mail address for me.
At some point, I will be unavailable permanently. I'd like people to be able to use some of my works then, too.
These aren't works that I would negotiate a fee for. The cost of negotiating feesand giving permission would be too high compared to the few fees I would get.
Eivind.
I work with creating digital goods. I think it is a horribly unreasonable stipulation.
A parallel is the attempt at blocking the use of robots for production (and there were attempts), on the basis that "All the people involved should be making the same amount of money."
The question isn't how we can keep the status quo. The question is "How can we set up a system that maximize the value produced?" If we want professional production, it need to involve *some* form of compensation to authors, editors and publishers for the risk taken, and the time invested. Either through copyright or through something else.
As it is, we have large costs from the copyright system, in the form of very high transaction costs around licensing copyrighted works. The transcation costs of licensing is WAY higher than the cost of making the actual copy. On average, I'd guess it is at least ten time higher, often a hundred times higher.
Cutting these costs would be an enabler. As an example, Shakespeare worked as a collector and rewriter. His works would not be legal to write under the present copyright regime.
While gaining Shakespeare, we would lose Waterworld and soap operas - as that kind of investment in a single item require per-copy returns.
Maybe it would be worth it?
Eivind.
Your "Clearly" is anything but. I've worked with developing embedded systems based on FreeBSD. Roughly 90% of our changes were appropriate for giving back to the community and were given back to the community.
Keeping changes proprietary is a tradeoff - it forms a small barrier-to-entry, and impose maintenance costs compared to having them integrated. For most changes, the maintenance costs are higher than the value of lifting the barrier-to-entry.
In addition, by releasing the changes you get the value of being able to use the community expertise, and (often) of making your own employees happier.
Eivind.
Definately. As you note, the problem is predicting what is a "good" hash.
Personally I'd take SHA-8092 over using 4 128-bit digest hash programs, no matter what their implementation. Unless you can show me an attack that will reduce the complexity to below the others individually.
The real question is whether one is afraid of a "short circuit" attack, losing close to all security from a hash. I'm afraid of those. I'm also afraid of attacks that just reduce the complexity proportionally, so I'd use more than 128 bits per component - 256 bits at the least.
Eivind.
If I use the combination of an SHA-256, an iterated AES (Rijndael) 256 bit hash, and an iterated HPC (Hasty Pudding Cipher) as my hash function, it means that *each* of these algorithms have to be broken before I have a security problem, instead of getting a security problem from the break of a single algorithm.
The point is to be redundant against algorithmic breaks, not just to extend the key length.
Or at least as I understood the poster. (Not that I'd choose either SHA-1 or MD5 as my building block for that redundancy these days.)
Eivind.
That's my understanding of the present level of understanding in the field, anyway. I'd be happy to be proved wrong :)
Eivind.
Animals and meat are complicated things. Reproducing it in a lab won't create the same thing. Even feeding animals grain instead of grass doesn't create the same thing (bad omega 3 levels etc.)
Eivind.
The cost include:
- At least three spammers murdered. At some point, I guess suicidal geeks will decide "If I'm going, why not take a spammer with me?" - though so far, it's been plain murders, perpetrator not caught.
- Fines, like the $7M fine recently imposed against a spammer.
While both are needed, I think the former force is likely to be more effective than the latter.The ultimate deterrent, of course, would be if some zillionaire decided to hire the mob to take care of spam. Scene (two men in suits at door of spammer): "Me and Josey wants to talk to you about those there emails."
Eivind.
This effect is called the The long tail effect, and is visible all over the web. For instance, Amazon.com says that every day, it sells more books that didn't sell yesterday than the sum of books sold that *also* sold yesterday. In other words, they sell (in sum) more of the items selling less than one every other day than of items selling (by type) more than that.
Eivind.