When pasting I always find myself in insert mode when I remember I need to:set paste. So I have some hooks that allow me to turn it on while in insert mode:
F10 to turn on paste mode and F11 to turn it off, and it works in command mode and insert mode. That is straight out of the vim help files if you type:help pastetoggle.
That hooks the command,t to perltidy. If you don't highlight anything and type,t in command mode it will filter the whole file. If you highlight some lines and hit,t it will only filter the selected lines.
And if you put that in.vim/ftplugin/perl.vim then those commands will only work when editing perl files.
vim can automatically handle wrapping in comments for you, as long as you have the proper filetype plugin loaded. This works for me when programming in perl using vim. You can even reformat an existing comment paragraph using the command gqap. That will automatically wrap all the lines at 78 columns (or whatever you have set), and reset all the comment markers at the start of the lines.
These things are never black and white. But since everything is so secret, and only one party is talking (ie Arar), I tend to put a lot of weight on his story (the party keeping quiet is usually trying to hide something).
The way I see it there are three things that could have happened by returning him to Syria:
Nothing happens to him, since he is harmless
He meets back up with his terrorist buddies (if he actualy is a terrorist)
He gets tossed in jail and tortured by the Syrian authorities
If he was harmless, why the fuss, and why not send him to Canada where he asked to go when given a choice. If Syria is going to welcome him with open arms as a terrorist, why ship him back there. That only leaves torture. Maybe, just maybe they shipped him over there so that the Syrians could use their harsher methods to try and get info out of him...
To me, any way you look at this, the US (and possibly the Canadian authorities) got this one wrong (regardless of whether he is, or isn't a terrorist).
Peter Quinn, the CIO who used to have the job, quit because of an M$ funded witchhunt that got him a lot of bad publicity and negative attention
This is the kind of stuff that is making the crowd at Groklaw less and less useful to me. It used to be just about the facts. Now, all the facts are still presented (which is why I still visit), but it is usually wrapped up with some opinion based retoric where Microsoft is to blame for every bad thing that happens out in the world.
Where are the facts that this was a Microsoft funded witchhunt? I'm not saying it isn't true, but since there is no proof that they did or didn't do this why even mention it. From what I have read, there was a nasty Boston Globe article (which was later proven to be inaccurate), and there are some politicians that are trying to pull rank by trying to block the ODF policy from going into effect. Sure Microsoft has been spouting lots of crap about ODF and praising the "openness" of their own XML formats, but I don't see proof of a witchhunt for Peter Quinn's head.
Stick to the facts, that is what Groklaw is good at...
And before I get called a shill, I started using Linux 12 years ago and have been using it as my only OS for over 6 years now.
The Lingua::Romana::Perligata makes it makes it possible to write Perl programs in Latin. (If you have to ask "Why?", then the answer probably won't make any sense to you either.)
What sort of budget limits do you guys have for your show these days? I remember seeing some earlier episodes where money really seemed to be an issue (spending an extra $700 on helium for the weather baloon lawn chair seemed to cause some concern). Whereas these days you guys seem to have no problem blowing up cement trucks or catapulting a boom lift.
As a corollary: Which experiment(s) ran rediculously over budget, and which one was surpirisingly cheap to pull off?
That is not what SCO is claiming. They seem to think that their contract with IBM gives them this control over methods and concepts. So it is not Copyright law that is at issue, it is Contract law. So this doesn't affect Linux, since it is a contract dispute between IBM and SCO.
Of course AT&T (who was actually a party to the contract negotiations to which SCO claims it is a successor in interest) has already stated that the contract does not say what SCO thinks it says.
PostgreSQL has had updatable views for quite a while now (at least as far back as 7.2) through the Rule System. The rule system is powerful enough to allow you to update ambigous insert or update statements in a view that may join across multiple tables. One INSERT/UPDATE statement can be rewritten into multiple updates or inserts into multiple tables.
There may be other things that MS-SQL can do that PostgreSQL can't (I haven't used MS-SQL so I have no knowledge there), but I just wanted to clear that one up.
As for vacuuming, it hasn't really bothered me. Especially now that the autovacuum daemon does the work very efficiently for you. And before that, a cronjob always did the job.
A coworker of mine did a similar thing on a production machine with rpmbuild. This was about 9 or ten years ago, but I think the command they used was something like this:
rpmbuild -bb --build-root / specfile
Don't ever use the --build-root switch unless you really know what you are doing. The build-root directory is a temporary directory where the package will be built and installed before it is packaged up into an RPM. The first thing RPM does is to clear the build-root directory to make sure there are no files there that will interfere with the build process. Yes you guessed it, it does an rm -rf , or in this case rm-rf/.
Luckily there were backups of the data, but it still took them most of the night to get the system back up and running:)
(This was orginally posted here but it seems to fit here as well)
I think it has more to do with bad scripting practises. A tool to recursively delete all files in a tree is absolutely necesary. But if you use it you should be careful. This problem could have been avoided by adding two dashes to the command:
Although I know you were going for humour here, I just want to dispell any concerns people might have that take your comments seriously.
I have this mouse, and my Wireless-G router is about a foot and a half away from my mouse, and I have not had any conflicts. It would be silly if Logitech didn't take that into consideration.
As for the quality of this mouse, I have had it for about 5 months now, and it is amazing. I've only replaced the batteries once, and I use it for at least 8 hours a day, and I rarely turn it off. They got the size right as well for a laptop mouse. Not too big, and not impossible to use like those micro mice.
This one is definately worth the high price tag...
That's why such a thing can't really happen to a body of work like glibc, gcc, or the linux kernel
Are you sure about that? I was under the impression that the FSF requires you to sign over copyright when contributing to these projects (Linux excluded from your list of course). I am not implying that they are going to fork a commercial version, but your reasoning is off, since one entity does own the copyrights to the entire codebase.
There are many other projects that require you to sign over your contributions. MySQL being one of them, since they dual license their code.
If everyone on the internet started using TMDA, then the email would stop functioning completely. It is an interesting solution, but all it ends up doing is placing the burden of SPAM on someone else.
TMDA will send a request back to the sender and we all know that spammers don't use their own reply to address. So if everyone used TMDA, then all you are doing is 'Joe Jobbing' some poor shmuck that the spammers happen to be using as a from address.
Also, you are doubling the negative effect of SPAM on the internet by responding to SPAM messages so at least two messages are sent for every SPAM.
This effect can be reduced by using an alternate SPAM filtering solution that drops obvious SPAM, but then you are back to using a filtering solution and you can't claim the 100% no false positives that TMDA is supposed to achieve.
SPAM is a tough problem, and I don't think anyone has come up with the right solution yet. Although I think hurting the perps is a good step...
WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, when log records describing the changes have been flushed to permanent storage. If we follow this procedure, we do not need to flush data pages to disk on every transaction commit, because we know that in the event of a crash we will be able to recover the database using the log: any changes that have not been applied to the data pages can be redone from the log records.
And since the log file is written sequencially, a transaction can usually be commited with a single fsync. Of course eventually everything needs to be written to disk, but it can be batched and should be more efficient than writing each transaction to disk on its own.
that magic worked for me, but it is simply a shortcut! that's why it looks like magic.
I know what the command was trying to do, but would suggest that it should be unnecesary in a system as 'amazing' as the ports collection.
Upgrading perl on FreeBSD is a non-trivial task that has the tendency to break the system. All I am saying is that this is a deficiency in the ports system!
you can't compare a perl upgrade with packages vs. source
I'm not talking about having to compile verses not compile. I am talking about a very basic concept in package/port management, and that is depedencies. Appearantly the ports collection doesn't handle dependencies as well as some people would make you think. If it did, it would not allow you to upgrade (without using force) your perl port without also upgrading all ports that depend on it. You have to do a bit of hoop jumping to get things done, and even then you are told that it might not work.
I use both FreeBSD and Debian regularly, and have to say that I've had my problems with the ports collection as well. Has anyone tried to upgrade perl lately? Here is an excerpt from/usr/ports/UPDATING on how to upgrade perl (just a minor version upgrade)
* run some magic incantations to upgrade all ports depending on perl, that is run something like: portupgrade -f `(pkg_info -R perl-5\* |tail +4; \ find/usr/local/lib/perl5/site_perl/5.[68].[1245] -type f -print0 \ | xargs -0 pkg_which -fv | sed -e '/: ?/d' -e 's/.*://')|sort -u` This is likely to fail for a few ports, you'll have to upgrade them afterwards by hand.
Not the cleanest way to do a package upgrade. When I upgrade perl on debian, it just had to download a few packages, and everything was handled properly.
I like both systems for what they provide me, but neither system is perfect...
I think you may be mixing up your lawsuits. IBM has been parading witness after witness (in depositions) while SCO has only found one or two that kind of buy their story. This article is about the Novell case.
The Novell case (Slander of Title) hasn't seen too much movement in the last while, so this is an important step. Especially since the outcome of this case can have a huge domino effect on the rest of the cases. ie if Novell can get a judgement that SCO doesn't own the copyrights, then the IBM lawsuit will most likely just go away...
A coworker of mine did a similar thing on a production machine with rpmbuild. This was about 9 or ten years ago, but I think the command they used was something like this:
rpmbuild -bb --build-root / specfile
Don't ever use the --build-root switch unless you really know what you are doing. The build-root directory is a temporary directory where the package will be built and installed before it is packaged up into an RPM. The first thing RPM does is to clear the build-root directory to make sure there are no files there that will interfere with the build process. Yes you guessed it, it does an rm -rf , or in this case rm-rf/.
Luckily there were backups of the data, but it still took them most of the night to get the system back up and running:)
This is kind of a double edged sword. Now that you can use NDIS drivers under Linux, it will be that much harder to convince these companies that providing a native Linux driver would be good for their business...
If you are in the market for one of these cards, buy from a company that supports your OS of choice...
Apache 2.0 has a lot more going for it than just better windows support.
One of the most useful features is the new Filter architecture. This allows you to send you HTML through multiple stages for processing. In other words, you could have a page that is parsed by PHP, then mod_perl, and then mod_include! Although that is a contrived example and no one would want to write a dynamic page using three languages, it does explain the possibilities. A useful example of a filter in Apache2 is mod_deflate which compresses content on the way out to the client. Also, it would be simple to write a filter in mod_perl that grabbed all the response headers and printed them to a file for debugging.
The new MPM (Multi-Processing Modules) , which has allowed for the improvement of windows support, also gives you choices on Unix in allowing you to use threaded models, or process models, or a combination of both...
But you are absolutely right in your observation that most admins are more than happy with what Apache 1.3.x provides for them.
I think Apache is one of the great success stories in the internet age.
Slashdot Mirror
When pasting I always find myself in insert mode when I remember I need to :set paste. So I have some hooks that allow me to turn it on while in insert mode:
F10 to turn on paste mode and F11 to turn it off, and it works in command mode and insert mode. That is straight out of the vim help files if you type :help pastetoggle.
You can easily create shortcuts for these as well, if you use them often
That hooks the command ,t to perltidy. If you don't highlight anything and type ,t in command mode it will filter the whole file. If you highlight some lines and hit ,t it will only filter the selected lines.
And if you put that in .vim/ftplugin/perl.vim then those commands will only work when editing perl files.
vim can automatically handle wrapping in comments for you, as long as you have the proper filetype plugin loaded. This works for me when programming in perl using vim. You can even reformat an existing comment paragraph using the command gqap. That will automatically wrap all the lines at 78 columns (or whatever you have set), and reset all the comment markers at the start of the lines.
These things are never black and white. But since everything is so secret, and only one party is talking (ie Arar), I tend to put a lot of weight on his story (the party keeping quiet is usually trying to hide something).
The way I see it there are three things that could have happened by returning him to Syria:
If he was harmless, why the fuss, and why not send him to Canada where he asked to go when given a choice. If Syria is going to welcome him with open arms as a terrorist, why ship him back there. That only leaves torture. Maybe, just maybe they shipped him over there so that the Syrians could use their harsher methods to try and get info out of him...
To me, any way you look at this, the US (and possibly the Canadian authorities) got this one wrong (regardless of whether he is, or isn't a terrorist).
The US likes to deport Canadian Citizens to Syria even though they only arrived in the US for a stop-over flight back to Canada.
This is the kind of stuff that is making the crowd at Groklaw less and less useful to me. It used to be just about the facts. Now, all the facts are still presented (which is why I still visit), but it is usually wrapped up with some opinion based retoric where Microsoft is to blame for every bad thing that happens out in the world.
Where are the facts that this was a Microsoft funded witchhunt? I'm not saying it isn't true, but since there is no proof that they did or didn't do this why even mention it. From what I have read, there was a nasty Boston Globe article (which was later proven to be inaccurate), and there are some politicians that are trying to pull rank by trying to block the ODF policy from going into effect. Sure Microsoft has been spouting lots of crap about ODF and praising the "openness" of their own XML formats, but I don't see proof of a witchhunt for Peter Quinn's head.
Stick to the facts, that is what Groklaw is good at...
And before I get called a shill, I started using Linux 12 years ago and have been using it as my only OS for over 6 years now.
You must be talking about Lingua::Romana::Perligata.
From the docs:
What sort of budget limits do you guys have for your show these days? I remember seeing some earlier episodes where money really seemed to be an issue (spending an extra $700 on helium for the weather baloon lawn chair seemed to cause some concern). Whereas these days you guys seem to have no problem blowing up cement trucks or catapulting a boom lift.
As a corollary: Which experiment(s) ran rediculously over budget, and which one was surpirisingly cheap to pull off?
That is not what SCO is claiming. They seem to think that their contract with IBM gives them this control over methods and concepts. So it is not Copyright law that is at issue, it is Contract law. So this doesn't affect Linux, since it is a contract dispute between IBM and SCO.
Of course AT&T (who was actually a party to the contract negotiations to which SCO claims it is a successor in interest) has already stated that the contract does not say what SCO thinks it says.
Astonishing isn't it!
Wow, that was even more astonishing! If you don't know anything about perl then quit bad mouthing it.
PostgreSQL has had updatable views for quite a while now (at least as far back as 7.2) through the Rule System. The rule system is powerful enough to allow you to update ambigous insert or update statements in a view that may join across multiple tables. One INSERT/UPDATE statement can be rewritten into multiple updates or inserts into multiple tables.
There may be other things that MS-SQL can do that PostgreSQL can't (I haven't used MS-SQL so I have no knowledge there), but I just wanted to clear that one up.
As for vacuuming, it hasn't really bothered me. Especially now that the autovacuum daemon does the work very efficiently for you. And before that, a cronjob always did the job.
A coworker of mine did a similar thing on a production machine with rpmbuild. This was about 9 or ten years ago, but I think the command they used was something like this:
rpmbuild -bb --build-root / specfileDon't ever use the --build-root switch unless you really know what you are doing. The build-root directory is a temporary directory where the package will be built and installed before it is packaged up into an RPM. The first thing RPM does is to clear the build-root directory to make sure there are no files there that will interfere with the build process. Yes you guessed it, it does an rm -rf , or in this case rm-rf /.
Luckily there were backups of the data, but it still took them most of the night to get the system back up and running :)
(This was orginally posted here but it seems to fit here as well)
I think it has more to do with bad scripting practises. A tool to recursively delete all files in a tree is absolutely necesary. But if you use it you should be careful. This problem could have been avoided by adding two dashes to the command:
rm -f -- *
Although I know you were going for humour here, I just want to dispell any concerns people might have that take your comments seriously.
I have this mouse, and my Wireless-G router is about a foot and a half away from my mouse, and I have not had any conflicts. It would be silly if Logitech didn't take that into consideration.
As for the quality of this mouse, I have had it for about 5 months now, and it is amazing. I've only replaced the batteries once, and I use it for at least 8 hours a day, and I rarely turn it off. They got the size right as well for a laptop mouse. Not too big, and not impossible to use like those micro mice.
This one is definately worth the high price tag...
Are you sure about that? I was under the impression that the FSF requires you to sign over copyright when contributing to these projects (Linux excluded from your list of course). I am not implying that they are going to fork a commercial version, but your reasoning is off, since one entity does own the copyrights to the entire codebase.
There are many other projects that require you to sign over your contributions. MySQL being one of them, since they dual license their code.
If everyone on the internet started using TMDA, then the email would stop functioning completely. It is an interesting solution, but all it ends up doing is placing the burden of SPAM on someone else.
TMDA will send a request back to the sender and we all know that spammers don't use their own reply to address. So if everyone used TMDA, then all you are doing is 'Joe Jobbing' some poor shmuck that the spammers happen to be using as a from address.
Also, you are doubling the negative effect of SPAM on the internet by responding to SPAM messages so at least two messages are sent for every SPAM.
This effect can be reduced by using an alternate SPAM filtering solution that drops obvious SPAM, but then you are back to using a filtering solution and you can't claim the 100% no false positives that TMDA is supposed to achieve.
SPAM is a tough problem, and I don't think anyone has come up with the right solution yet. Although I think hurting the perps is a good step...
Read up on Write-Ahead Logging (WAL).
And since the log file is written sequencially, a transaction can usually be commited with a single fsync. Of course eventually everything needs to be written to disk, but it can be batched and should be more efficient than writing each transaction to disk on its own.
--
Cees
I know what the command was trying to do, but would suggest that it should be unnecesary in a system as 'amazing' as the ports collection.
Upgrading perl on FreeBSD is a non-trivial task that has the tendency to break the system. All I am saying is that this is a deficiency in the ports system!
I'm not talking about having to compile verses not compile. I am talking about a very basic concept in package/port management, and that is depedencies. Appearantly the ports collection doesn't handle dependencies as well as some people would make you think. If it did, it would not allow you to upgrade (without using force) your perl port without also upgrading all ports that depend on it. You have to do a bit of hoop jumping to get things done, and even then you are told that it might not work.
I use both FreeBSD and Debian regularly, and have to say that I've had my problems with the ports collection as well. Has anyone tried to upgrade perl lately? Here is an excerpt from /usr/ports/UPDATING on how to upgrade perl (just a minor version upgrade)
Not the cleanest way to do a package upgrade. When I upgrade perl on debian, it just had to download a few packages, and everything was handled properly.
I like both systems for what they provide me, but neither system is perfect...
I think you may be mixing up your lawsuits. IBM has been parading witness after witness (in depositions) while SCO has only found one or two that kind of buy their story. This article is about the Novell case.
The Novell case (Slander of Title) hasn't seen too much movement in the last while, so this is an important step. Especially since the outcome of this case can have a huge domino effect on the rest of the cases. ie if Novell can get a judgement that SCO doesn't own the copyrights, then the IBM lawsuit will most likely just go away...
A coworker of mine did a similar thing on a production machine with rpmbuild. This was about 9 or ten years ago, but I think the command they used was something like this:
/.
:)
rpmbuild -bb --build-root / specfile
Don't ever use the --build-root switch unless you really know what you are doing. The build-root directory is a temporary directory where the package will be built and installed before it is packaged up into an RPM. The first thing RPM does is to clear the build-root directory to make sure there are no files there that will interfere with the build process. Yes you guessed it, it does an rm -rf , or in this case rm-rf
Luckily there were backups of the data, but it still took them most of the night to get the system back up and running
That looks more cryptic that it needs to be.
This is kind of a double edged sword. Now that you can use NDIS drivers under Linux, it will be that much harder to convince these companies that providing a native Linux driver would be good for their business...
If you are in the market for one of these cards, buy from a company that supports your OS of choice...
Apache 2.0 has a lot more going for it than just better windows support.
One of the most useful features is the new Filter architecture. This allows you to send you HTML through multiple stages for processing. In other words, you could have a page that is parsed by PHP, then mod_perl, and then mod_include! Although that is a contrived example and no one would want to write a dynamic page using three languages, it does explain the possibilities. A useful example of a filter in Apache2 is mod_deflate which compresses content on the way out to the client. Also, it would be simple to write a filter in mod_perl that grabbed all the response headers and printed them to a file for debugging.
The new MPM (Multi-Processing Modules) , which has allowed for the improvement of windows support, also gives you choices on Unix in allowing you to use threaded models, or process models, or a combination of both...
But you are absolutely right in your observation that most admins are more than happy with what Apache 1.3.x provides for them.
I think Apache is one of the great success stories in the internet age.
The first RC of Apache::Request for mod_perl2 was released a couple of days ago...
v -r c1.tar.gz
http://httpd.apache.org/~joes/libapreq2-2.01-de
It shouldn't be long before it is released as stable