A somewhat sweeping statement. Most Christian denominations worldwide take a fairly "modern" view on contraception. And you have to wonder about the influence of the Vatiican when highly Catholic Italy has a catastophically low birth rate.
Atheism has only had about a century in which to wield political power, but it has caught up fast on the genocide front.
Agreed. But at least serving over HTTP is something you can reasonably assess on the basis of single requests (because it is stateless). I'm not quite sure what stateless emotion would mean.
On another skim through TFA, it turns out that the system doesn't read anything - it seems to be based on a set of carefully crafted graphs representing the fables. It's hard not to feel that producing the graphs is 90+% of the task.
So it's more like setting up a webserver to return a page of HTML in response to a URL, and then saying
"Web server understands requests for news (once that natural language request has been turned into a URL)"
I'm not convinced it's anywhere near that simple. Stories can produce a range of emotions in the same person at different times, let alone in different people, and I don't think that those differences are solely down to "conditioning". See Chomsky's famous rant at Skinner about a "reinforcing" explanation of how people respond to art. - the agent experiencing the emotion - or even the comprehension - has to be active in deciding which aspects of the story to respond to.
One set of stories, one one-sentence response. Would that be news in any field of IT other than AI? Eg "Web server returns a correct response to one carefully-chosen HTTP request!!!"?
Surely the whole thing about emotion is that it happens across a wide range of situations, and often in ways that are very hard to tie down to any specific situational factors. "I feel sad for the bird" in this case is really just literary criticism. It's another way of saying "A common and dominant theme in the three stories is the negative outcome for the character which in each case is a type of bird". Doing that sort of analysis across a wide range of stories would be a neat trick, but I don't see the experience of emotion. I see an objective analysis of the concept of emotion as expressed in stories, which is not the same thing at all.
Reading the daily newspaper and saying how the computer feels at the end of it, and why, and what it does to get past it, might be more interesting.
TFA suggests that replacing "inert" hydrogen peroxide with propane will make jet packs more dangerous. Maybe, maybe not, but hydrogen peroxide is a powerful oxidant that attacks many organic compounds (eg people) and can explode. It's not inert by any stretch of the imagination - how useful would an inert rocket fuel be in any case?
Strapping a propane cylinder to your back might not be great either, but I suspect propane is easier to manage.
XSLT is not in itself a data model, but it assumes a data model that is not DOM (although obviously all "working with XML" models tend to have a lot in common). XSLT/XPath 2.0 depends explicitly on the W3C XDM data model. XSLT 1.0 (which is what you tend to find in browsers) is a bit more murky, but, for example, you won't find Result Tree Fragments in DOM (thank goodness).
Recently there has been a bit of revival in client-side XSLT processing, so the point isn't totally obscure...
It evolves because a billion different people and entities change it in some way.
That's hyperbolic by several orders of magnitude. The last figures I saw go past for Linux kernel developers past and present were in the thousands. That's amazing, but it's quite a way short of a billion. The last figures I saw for the development team of Open Office was, what, two dozen?
Many of the most prolific contributors were paid by someone to contribute. Where does that money come from? The myth of Linux being built for free by volunteers is just that - a myth.
Those who just sit on the side and yap are irrelevant and their needs are irrelevant.
Not if they influence purchasing decisions that affect the bottom line of companies putting money into Linux.
For example, my guess is that Apache effectively sells a lot of Redhat Enterprise licences. If Apache was fundamentally broken, those sitting on the side and yapping would drive purchases away from Linux and towards Microsoft solutions.
To put it another way, the ones who can directly or indirectly put money into open source-friendly companies make a difference too. See Corel for a worked example of what happens when the company supporting linux doesn't get paid.
In some markets it simply hasn't been possible to buy a 2 year-old spec until recently. In particular, laptops used to vanish at the point at which they made sense for someone who just wanted a portable screen and keyboard with which to take notes and maybe enter some code. The only way to get a laptop much cheaper than the premium spec was to go s/h, and s/h laptops have never been that attractive an option.
Machines with the relative spec of NetBooks would have sold fine a decade ago. It's just that the laptop-manufacturing cartel refused to sell them to us. NetBooks have broken that cartel, and I'm expecting the shock waves to shake up prices a lot further up the spec rankings. That's what really worries companies like Sony - a $2000 Vaio becomes harder to justify the more the price of the basic product drops, and the more people demonstrate that the basic product is good enough for many tasks.
How many servers in total are watched over by people posting on Slashdot? I suspect that the answer is high enough that it would be amazing if at least one of them didn't crash within 20 seconds of the New Year.
But... but... You seem to think that because CPAN still supports older packages, everyone is going to use them. It doesn't work that way. The point is that the older XML packages are patched to do what the underlying technology can do, while new packages are developed for newer underlying technology. So you can still run XML::Parser (based on Expat) today, and expect it to do what it says on the tin. If, for example, you want extensive support for namespaces, you use XML::LibXML. The continuing support for XML::Parser doesn't stop development of XML::LibXML - why on Earth would it? What it does do is keep a lot of useful legacy code running.
I don't know which incompatibility caught you, but I still come across perl4 scripts in production settings. Making old perl5 scripts work with new perl5 parsers is generally as easy as adding one 'use' statement at the top of the script. That gives you compatibility back to 1994, which is when the very first version of python came out. Having to run python 2 code through a convertor and then fix the rest by hand doesn't seem to compare very well with perl backwards compatibility across the same time frame. However elegant the language's spec...
It's an interesting theory, but does CPAN support it in practice?
To take the example of XML, there's basically a perl API to every XML and XSLT parser in existence, starting with expat. (Incidentally, some of those XSLT parsers are in java.) So, if LibXML/LibXSLT do what you want (as they do in my case), you use XML::LibXML and XML::LibXSLT.
Picking between a number of well-documented XML technologies such as LibXSLT and Sablotron seems to me to be altogether better than going for The Newest From Scratch XSLT Implementation In My Favourite Language, as if this implementation is going to be the first ever not to have any bugs and not to deviate from the specs in any way whatsoever.
Also, what you are calling bit rot is what enables backwards compatibility. Python seems to be a bit better than PHP on this score, but, as I understand it, Python 3 will not be compatible with Python 2, and issuing warnings in Python 2.6 is supposed to magically update all legacy code. Since that approach has never resulted in universal updating of legacy code in the entire history of computing, I don't expect it to work for the Python community either. It's just as well that there is so little legacy code out there compared with perl:)
You could equally argue that many of the CPAN modules have been tested and fixed incrementally over a decade, ie that new code isn't necessary better code. Some of the major CPAN modules have stopped being updated because there is pretty much nothing left to fix.
Even if CPAN was the only argument for using perl (which it isn't), it would still be one hell of an argument. So much of the argument for python seems to be boil down to "anyone trying to solve a problem that anyone has ever solved before isn't a real meat-eating programmer, and so doesn't count." But most of what most programmers do looks a lot like stuff that has been done. Perl's way to handle that via CPAN is so far ahead of any other scripting language that it's hard to even attempt a comparison.
The other day I needed an embedded RSS client for a db-powered website. I wrote it in 20 lines of perl using LWP, DBI (streets ahead of anything I've seen for PHP in terms of abstraction) XML::LibXML and XML:Writer. I could have used one of the standard RSS libraries, but since I had those packages installed and only needed to read one specific feed it was easier to unpick the XML by hand. Actually, I didn't use DBI directly, I just picked up the DB package I had created for the website using DBI.
The previous week I needed to send email based on XML input. I installed one of the email-sending packages, and the solution was then extremely concise. In my experience, there are packages for just about every application. That means I spend my time writing application code, not being the 4,357,198th person to implement a particular protocol or form of encryption, and that I don't then have to maintain my own implementation of basic technology.
I have looked at Python several times. The last time was when I wanted to write a standalone application using XML and XSLT via sockets. But it looked to me like I was going to end up reinventing a lot of wheels, so I went with Tcl instead.
Oh, they should blame the install, which was poor? Exactly how?
I have bought five Eeepcs so far for my company, and the one I'm typing on now is my main computer as a linux application programmer.
But none of them is still running Xandros, the install, because it is horrid. Even the 'getting a proper desktop' package is no longer officially supported, and getting anything more exotic to work requires far more knowledge of Debian internals than I ever intend to acquire. A colleague has found some specific bugs, including the inability of the wifi manager to cope with WPA codes that include spaces and a reliable way of trashing the update mechanism simply by clicking icons in the wrong order. And the ones sold by Vodafone in France don't even have Skype.
With Kubuntu installed, and a few patches documented on the Ubuntu website to fix wifi et al, they are great. But that's not the linux that people get when they open the box.
Why does anyone expect Windows users not to want something that looks like a Windows desktop, which any linux distro could deliver if the hardware manufacturers hadn't knobbled it?
The one non-techie I know who bought a Dell laptop with Ubuntu installed is still happy with it a year later. But if Dell had been dumb enough to ship a dumbed-down version of Xandros, I'm sure she would have intalled XP by now.
Exactly. It's not a breach of any FOSS licence. It's possibly a breach of FOSS project best practice, but that isn't clear either, because we don't know how the problem happened or what code had to be modified to fix it.
Even if some FOSS code was modified, there is no licence obligation to distribute the changes unless you are distributing the binaries.
As I understand it, the security breach was that someone gained remote access to their servers. It doesn't necessarily follow that any of the code served by the servers was faulty. Last time I checked, not all the code running Redhat sites was open-source.
And the breach could well have been down to a sys admin error, rather than a problem with the codebase itself. It would obviously be acutely embarassing if Redhat's in-house team turned out to have made the kind of mistake that causes people to fail their RHCE exam, but it wouldn't have anything to do with FOSS.
Also, there may not be a simple answer to the 'what does this mean for me?' question. In the Debian case, the answer was quite simple, and so was the solution. The Redhat announcements sounded to me like "We know there was a breach, we don't know exactly what happened as a result, we don't think anything serious happened, but, to be on the safe side, we are changing all the locks."
Redhat's PR department obviously misjudged the best way to handle this incident, but the expectations of the FOSS community also seem unrealistic. When a company open-sources some code, it doesn't mean that anyone in the world gets unfettered access to all the information in the company. Reading TFA, I can't help but think that it is at least partly motivated by the blogger's outrage that Redhat didn't roll out the red carpet all the way to the server room for his terribly important blog.
Um no, that isn't even close to my point, although a lot of Israelis do speak excellent English. If you speak a foreign language well enough to be useful, congratulations, but all the studies as well as my anecdotal experience of multinational teams is that you are the exception. Cf, say, the Netherlands, where every school child has spent ten years studying English, and many of them can pass for either British or American (depending which accent they specialised in). Or cf Germany, where many large companies use English as their routine working language whether or not there are any non-German-speakers in the room.
My point is that Europeans get a bit upset when Americans shout loudly in English in our streets about how terrible it is that we don't want to speak their language - the only language the American in question speaks - in our own country, just for the personal convenience of the monolinguistic tourist.
It's not actually that hard a reaction to understand. If you were accosted in the supermarket by a loud tourist from Louisiana who openly mocked you for not speaking French in your own town, would you instantly like that tourist? Why exactly should Parisians waste their time using whatever language skills they possess on people who display such a total lack of common courtesy? (Hint: the standard of living in Paris is higher than in many parts of the US, ie they don't need your tourist dollars.)
Here in Germany, it is a given that everyone will speak basic English, because they took it in school
Here in France, we receive regular propaganda from the state schools telling us that German is a far more useful language to learn than English. The reasons for this are purely political, and go back to the post-war deal between France and Germany that ultimately led to the EU.
When a German says he speaks basic English, it usually means that he can function in English with a slightly odd accent. When a Frenchman says he speaks basic English, he may just about be able to say 'How are you?' In statistical terms, it makes as much sense to walk up to a random Frenchman speaking English as it does to walk up to an American asking what they think about IP6.
And of course when an American claims to speak any other language, they usually don't (unless they were born in Cuba) and everyone outside America knows this, which doesn't really help to make everyone else indulgent when Americans criticise their language skills.
Middle-grade Perl is not bad, but it is simply not as clean and legible as, say, Python, Lisp, Ruby or in some cases perhaps Java (although modern Java is trying very hard to be uglier than Perl).
I moved to perl having written a lot of Lisp, and I can't say that reduced legibility has ever been my concern. Lisp can be totally opaque, especially when you end up with 30 closing parentheses for a relatively short function. And I worked with a guy who wrote Fortran in Lisp, which is considerably worse to read than Fortran in Fortran. For most applications, code that generates and modifies code is the ultimate obfuscation, and, historically, that's at the very heart of Lisp's lambda expressions.
Perl was a great language when we were all used to awk and ksh. There's really no non-legacy (and I include the wonderful CPAN under that heading) reason to use it nowadays though.
Some of the reasons include
It's still blindingly fast - as fast or faster than non-optimised C in some cases and much faster than other scripting languages in many cases
CPAN - there's a tested library to do pretty much anything relating to sys admin and/or websites, plus a simple way to install and update them.
Superlative support from Apache - cf the enduring mess that is suEXEC for PHP
Backwards compatibility - not a legacy issue when you look at the way every subversion of PHP breaks compatibility with code that in some cases is only months old.
For a current project I tried hard to talk myself back into Lisp, but gave up when I failed to find support for namespaced XML (yes yes, XML is an ugly s-expression, but try telling that to the software I need to interface with), any sane way to plug it into a production web server, or any agreement on which version of Lisp we should all be running this week. I loved the Lisp machine I programmed for a year, but it's the past - far more so than perl.
Business users, of course, don't want nasty old, broken Perl code. They want the shiny new technologies.
But Larry Wall also says that Perl 5 is old, and, in places, nasty, and there are some aspects that I'd describe as broken.
Take UTF handling, for example - check out the chapter in the camel book for how simple it isn't. Only this week I fixed an encoding issue by adding 'use bytes' to get UTF8 to render correctly - that is not the sign of mature unicode support. For one project, I taught myself tcl/tk from scratch simply because I knew the unicode would work, where getting unicode to work consistently with perl/tk has Holy Grail status.
Worse, perl 5 is due to be replaced by perl 6, but who knows when if ever perl 6 will ship in a production-ready form. In the meantime, it would be madness to rework perl 5 code in a more elegant version of perl 5.
If Larry Wall either shipped perl 6 or said "only joking", perl would become a serious long-term strategy again.
We tried TRAC, and switched to BugZilla after several of our staff refused to use TRAC anymore. The way of handling parallel posts is particularly bad, ie 'throw away one of the posts so you can't even reclaim the text to submit it again'. Bugzilla isn't ideal in my view, but we like it a whole lot better than Trac.
In this case, it seems to me that the ideal solution would be lisp-style macros that would rewrite the getter/setter as a nested hash reference at compile time. Then you get a clean interface with no overheads.
I've never been convinced by any hard-and-fast coding stylistics. Sure, it's possible to write good code and bad code, readable code and unreadable code, but beauty is very much in the eye of the beholder, and, also, it depends a lot what you are trying to do. Insisting on one inflexible set of stylistics works about as well as telling people never ever to split infinitives or never ever to use the word 'said'.
Last night I came across this in the documentation for CPAN's Net::Server (you probably guessed from the above that I'm not a Pascal programmer):
You may get and set properties in two ways. The suggested way is to access properties directly via
my $val = $self->{server}->{key1};
Accessing the properties directly will speed the server process - though some would deem this as bad style. A second way has been provided for object oriented types who believe in methods. The second way consists of the following methods:
my $val = $self->get_property( 'key1' );
my $self->set_property( key1 => 'val1');
This struck me as remarkably sensible - the author of the module puts his prejudices on the table, but tells you how to do it a different way if you like. (And, personally, I prefer the first example, because it's just as clear, faster, and I've never managed to take OOP in perl entirely seriously - a problem that Larry Wall appears to have too.)
You judge good style in any particular case by looking at the overall work, not by nit-picking about the punctuation in isolation.
Because it's available. I pre-ordered a 701, waited 4 months for it to appear (supply in Europe has been very poor), and by that point the 900 was almost with us. My previous laptop had a broken key, and I wanted to set up my new machine before I next needed to use the local keyboard, so I bought what was available rather than what the wholesaler thought might be in stock in a month's time.
Slashdot Mirror
A somewhat sweeping statement. Most Christian denominations worldwide take a fairly "modern" view on contraception. And you have to wonder about the influence of the Vatiican when highly Catholic Italy has a catastophically low birth rate.
Atheism has only had about a century in which to wield political power, but it has caught up fast on the genocide front.
"I've never got it when it comes to SQL databases. It's like, why? Just give me a hash table and a shitload of RAM and I'm happy."
Agreed. But at least serving over HTTP is something you can reasonably assess on the basis of single requests (because it is stateless). I'm not quite sure what stateless emotion would mean.
On another skim through TFA, it turns out that the system doesn't read anything - it seems to be based on a set of carefully crafted graphs representing the fables. It's hard not to feel that producing the graphs is 90+% of the task.
So it's more like setting up a webserver to return a page of HTML in response to a URL, and then saying
"Web server understands requests for news (once that natural language request has been turned into a URL)"
I'm not convinced it's anywhere near that simple. Stories can produce a range of emotions in the same person at different times, let alone in different people, and I don't think that those differences are solely down to "conditioning". See Chomsky's famous rant at Skinner about a "reinforcing" explanation of how people respond to art. - the agent experiencing the emotion - or even the comprehension - has to be active in deciding which aspects of the story to respond to.
One set of stories, one one-sentence response. Would that be news in any field of IT other than AI? Eg "Web server returns a correct response to one carefully-chosen HTTP request!!!"?
Surely the whole thing about emotion is that it happens across a wide range of situations, and often in ways that are very hard to tie down to any specific situational factors. "I feel sad for the bird" in this case is really just literary criticism. It's another way of saying "A common and dominant theme in the three stories is the negative outcome for the character which in each case is a type of bird". Doing that sort of analysis across a wide range of stories would be a neat trick, but I don't see the experience of emotion. I see an objective analysis of the concept of emotion as expressed in stories, which is not the same thing at all.
Reading the daily newspaper and saying how the computer feels at the end of it, and why, and what it does to get past it, might be more interesting.
TFA suggests that replacing "inert" hydrogen peroxide with propane will make jet packs more dangerous. Maybe, maybe not, but hydrogen peroxide is a powerful oxidant that attacks many organic compounds (eg people) and can explode. It's not inert by any stretch of the imagination - how useful would an inert rocket fuel be in any case?
Strapping a propane cylinder to your back might not be great either, but I suspect propane is easier to manage.
There's a summary of H202 safety risks here
XSLT is not in itself a data model, but it assumes a data model that is not DOM (although obviously all "working with XML" models tend to have a lot in common). XSLT/XPath 2.0 depends explicitly on the W3C XDM data model. XSLT 1.0 (which is what you tend to find in browsers) is a bit more murky, but, for example, you won't find Result Tree Fragments in DOM (thank goodness).
Recently there has been a bit of revival in client-side XSLT processing, so the point isn't totally obscure...
Doesn't HTML5 JS still provide XSLT as well as DOM?
That's hyperbolic by several orders of magnitude. The last figures I saw go past for Linux kernel developers past and present were in the thousands. That's amazing, but it's quite a way short of a billion. The last figures I saw for the development team of Open Office was, what, two dozen?
Many of the most prolific contributors were paid by someone to contribute. Where does that money come from? The myth of Linux being built for free by volunteers is just that - a myth.
Not if they influence purchasing decisions that affect the bottom line of companies putting money into Linux.
For example, my guess is that Apache effectively sells a lot of Redhat Enterprise licences. If Apache was fundamentally broken, those sitting on the side and yapping would drive purchases away from Linux and towards Microsoft solutions.
To put it another way, the ones who can directly or indirectly put money into open source-friendly companies make a difference too. See Corel for a worked example of what happens when the company supporting linux doesn't get paid.
In some markets it simply hasn't been possible to buy a 2 year-old spec until recently. In particular, laptops used to vanish at the point at which they made sense for someone who just wanted a portable screen and keyboard with which to take notes and maybe enter some code. The only way to get a laptop much cheaper than the premium spec was to go s/h, and s/h laptops have never been that attractive an option.
Machines with the relative spec of NetBooks would have sold fine a decade ago. It's just that the laptop-manufacturing cartel refused to sell them to us. NetBooks have broken that cartel, and I'm expecting the shock waves to shake up prices a lot further up the spec rankings. That's what really worries companies like Sony - a $2000 Vaio becomes harder to justify the more the price of the basic product drops, and the more people demonstrate that the basic product is good enough for many tasks.
How many servers in total are watched over by people posting on Slashdot? I suspect that the answer is high enough that it would be amazing if at least one of them didn't crash within 20 seconds of the New Year.
But... but... You seem to think that because CPAN still supports older packages, everyone is going to use them. It doesn't work that way. The point is that the older XML packages are patched to do what the underlying technology can do, while new packages are developed for newer underlying technology. So you can still run XML::Parser (based on Expat) today, and expect it to do what it says on the tin. If, for example, you want extensive support for namespaces, you use XML::LibXML. The continuing support for XML::Parser doesn't stop development of XML::LibXML - why on Earth would it? What it does do is keep a lot of useful legacy code running.
I don't know which incompatibility caught you, but I still come across perl4 scripts in production settings. Making old perl5 scripts work with new perl5 parsers is generally as easy as adding one 'use' statement at the top of the script. That gives you compatibility back to 1994, which is when the very first version of python came out. Having to run python 2 code through a convertor and then fix the rest by hand doesn't seem to compare very well with perl backwards compatibility across the same time frame. However elegant the language's spec...
It's an interesting theory, but does CPAN support it in practice?
To take the example of XML, there's basically a perl API to every XML and XSLT parser in existence, starting with expat. (Incidentally, some of those XSLT parsers are in java.) So, if LibXML/LibXSLT do what you want (as they do in my case), you use XML::LibXML and XML::LibXSLT.
Picking between a number of well-documented XML technologies such as LibXSLT and Sablotron seems to me to be altogether better than going for The Newest From Scratch XSLT Implementation In My Favourite Language, as if this implementation is going to be the first ever not to have any bugs and not to deviate from the specs in any way whatsoever.
Also, what you are calling bit rot is what enables backwards compatibility. Python seems to be a bit better than PHP on this score, but, as I understand it, Python 3 will not be compatible with Python 2, and issuing warnings in Python 2.6 is supposed to magically update all legacy code. Since that approach has never resulted in universal updating of legacy code in the entire history of computing, I don't expect it to work for the Python community either. It's just as well that there is so little legacy code out there compared with perl :)
You could equally argue that many of the CPAN modules have been tested and fixed incrementally over a decade, ie that new code isn't necessary better code. Some of the major CPAN modules have stopped being updated because there is pretty much nothing left to fix.
Even if CPAN was the only argument for using perl (which it isn't), it would still be one hell of an argument. So much of the argument for python seems to be boil down to "anyone trying to solve a problem that anyone has ever solved before isn't a real meat-eating programmer, and so doesn't count." But most of what most programmers do looks a lot like stuff that has been done. Perl's way to handle that via CPAN is so far ahead of any other scripting language that it's hard to even attempt a comparison.
The other day I needed an embedded RSS client for a db-powered website. I wrote it in 20 lines of perl using LWP, DBI (streets ahead of anything I've seen for PHP in terms of abstraction) XML::LibXML and XML:Writer. I could have used one of the standard RSS libraries, but since I had those packages installed and only needed to read one specific feed it was easier to unpick the XML by hand. Actually, I didn't use DBI directly, I just picked up the DB package I had created for the website using DBI.
The previous week I needed to send email based on XML input. I installed one of the email-sending packages, and the solution was then extremely concise. In my experience, there are packages for just about every application. That means I spend my time writing application code, not being the 4,357,198th person to implement a particular protocol or form of encryption, and that I don't then have to maintain my own implementation of basic technology.
I have looked at Python several times. The last time was when I wanted to write a standalone application using XML and XSLT via sockets. But it looked to me like I was going to end up reinventing a lot of wheels, so I went with Tcl instead.
But none of them is still running Xandros, the install, because it is horrid. Even the 'getting a proper desktop' package is no longer officially supported, and getting anything more exotic to work requires far more knowledge of Debian internals than I ever intend to acquire. A colleague has found some specific bugs, including the inability of the wifi manager to cope with WPA codes that include spaces and a reliable way of trashing the update mechanism simply by clicking icons in the wrong order. And the ones sold by Vodafone in France don't even have Skype.
With Kubuntu installed, and a few patches documented on the Ubuntu website to fix wifi et al, they are great. But that's not the linux that people get when they open the box.
Why does anyone expect Windows users not to want something that looks like a Windows desktop, which any linux distro could deliver if the hardware manufacturers hadn't knobbled it?
The one non-techie I know who bought a Dell laptop with Ubuntu installed is still happy with it a year later. But if Dell had been dumb enough to ship a dumbed-down version of Xandros, I'm sure she would have intalled XP by now.
Exactly. It's not a breach of any FOSS licence. It's possibly a breach of FOSS project best practice, but that isn't clear either, because we don't know how the problem happened or what code had to be modified to fix it.
Even if some FOSS code was modified, there is no licence obligation to distribute the changes unless you are distributing the binaries.
As I understand it, the security breach was that someone gained remote access to their servers. It doesn't necessarily follow that any of the code served by the servers was faulty. Last time I checked, not all the code running Redhat sites was open-source.
And the breach could well have been down to a sys admin error, rather than a problem with the codebase itself. It would obviously be acutely embarassing if Redhat's in-house team turned out to have made the kind of mistake that causes people to fail their RHCE exam, but it wouldn't have anything to do with FOSS.
Also, there may not be a simple answer to the 'what does this mean for me?' question. In the Debian case, the answer was quite simple, and so was the solution. The Redhat announcements sounded to me like "We know there was a breach, we don't know exactly what happened as a result, we don't think anything serious happened, but, to be on the safe side, we are changing all the locks."
Redhat's PR department obviously misjudged the best way to handle this incident, but the expectations of the FOSS community also seem unrealistic. When a company open-sources some code, it doesn't mean that anyone in the world gets unfettered access to all the information in the company. Reading TFA, I can't help but think that it is at least partly motivated by the blogger's outrage that Redhat didn't roll out the red carpet all the way to the server room for his terribly important blog.
Um no, that isn't even close to my point, although a lot of Israelis do speak excellent English. If you speak a foreign language well enough to be useful, congratulations, but all the studies as well as my anecdotal experience of multinational teams is that you are the exception. Cf, say, the Netherlands, where every school child has spent ten years studying English, and many of them can pass for either British or American (depending which accent they specialised in). Or cf Germany, where many large companies use English as their routine working language whether or not there are any non-German-speakers in the room.
My point is that Europeans get a bit upset when Americans shout loudly in English in our streets about how terrible it is that we don't want to speak their language - the only language the American in question speaks - in our own country, just for the personal convenience of the monolinguistic tourist.
It's not actually that hard a reaction to understand. If you were accosted in the supermarket by a loud tourist from Louisiana who openly mocked you for not speaking French in your own town, would you instantly like that tourist? Why exactly should Parisians waste their time using whatever language skills they possess on people who display such a total lack of common courtesy? (Hint: the standard of living in Paris is higher than in many parts of the US, ie they don't need your tourist dollars.)
Here in France, we receive regular propaganda from the state schools telling us that German is a far more useful language to learn than English. The reasons for this are purely political, and go back to the post-war deal between France and Germany that ultimately led to the EU.
When a German says he speaks basic English, it usually means that he can function in English with a slightly odd accent. When a Frenchman says he speaks basic English, he may just about be able to say 'How are you?' In statistical terms, it makes as much sense to walk up to a random Frenchman speaking English as it does to walk up to an American asking what they think about IP6.
And of course when an American claims to speak any other language, they usually don't (unless they were born in Cuba) and everyone outside America knows this, which doesn't really help to make everyone else indulgent when Americans criticise their language skills.
I moved to perl having written a lot of Lisp, and I can't say that reduced legibility has ever been my concern. Lisp can be totally opaque, especially when you end up with 30 closing parentheses for a relatively short function. And I worked with a guy who wrote Fortran in Lisp, which is considerably worse to read than Fortran in Fortran. For most applications, code that generates and modifies code is the ultimate obfuscation, and, historically, that's at the very heart of Lisp's lambda expressions.
Some of the reasons include
For a current project I tried hard to talk myself back into Lisp, but gave up when I failed to find support for namespaced XML (yes yes, XML is an ugly s-expression, but try telling that to the software I need to interface with), any sane way to plug it into a production web server, or any agreement on which version of Lisp we should all be running this week. I loved the Lisp machine I programmed for a year, but it's the past - far more so than perl.
But Larry Wall also says that Perl 5 is old, and, in places, nasty, and there are some aspects that I'd describe as broken.
Take UTF handling, for example - check out the chapter in the camel book for how simple it isn't. Only this week I fixed an encoding issue by adding 'use bytes' to get UTF8 to render correctly - that is not the sign of mature unicode support. For one project, I taught myself tcl/tk from scratch simply because I knew the unicode would work, where getting unicode to work consistently with perl/tk has Holy Grail status.
Worse, perl 5 is due to be replaced by perl 6, but who knows when if ever perl 6 will ship in a production-ready form. In the meantime, it would be madness to rework perl 5 code in a more elegant version of perl 5.
If Larry Wall either shipped perl 6 or said "only joking", perl would become a serious long-term strategy again.
We tried TRAC, and switched to BugZilla after several of our staff refused to use TRAC anymore. The way of handling parallel posts is particularly bad, ie 'throw away one of the posts so you can't even reclaim the text to submit it again'. Bugzilla isn't ideal in my view, but we like it a whole lot better than Trac.
In this case, it seems to me that the ideal solution would be lisp-style macros that would rewrite the getter/setter as a nested hash reference at compile time. Then you get a clean interface with no overheads.
I've never been convinced by any hard-and-fast coding stylistics. Sure, it's possible to write good code and bad code, readable code and unreadable code, but beauty is very much in the eye of the beholder, and, also, it depends a lot what you are trying to do. Insisting on one inflexible set of stylistics works about as well as telling people never ever to split infinitives or never ever to use the word 'said'.
Last night I came across this in the documentation for CPAN's Net::Server (you probably guessed from the above that I'm not a Pascal programmer):
You may get and set properties in two ways. The suggested way is to access properties directly via
my $val = $self->{server}->{key1};
Accessing the properties directly will speed the server process - though some would deem this as bad style. A second way has been provided for object oriented types who believe in methods. The second way consists of the following methods:
my $val = $self->get_property( 'key1' );
my $self->set_property( key1 => 'val1');
This struck me as remarkably sensible - the author of the module puts his prejudices on the table, but tells you how to do it a different way if you like. (And, personally, I prefer the first example, because it's just as clear, faster, and I've never managed to take OOP in perl entirely seriously - a problem that Larry Wall appears to have too.)
You judge good style in any particular case by looking at the overall work, not by nit-picking about the punctuation in isolation.
Because it's available. I pre-ordered a 701, waited 4 months for it to appear (supply in Europe has been very poor), and by that point the 900 was almost with us. My previous laptop had a broken key, and I wanted to set up my new machine before I next needed to use the local keyboard, so I bought what was available rather than what the wholesaler thought might be in stock in a month's time.