xine I'm not sure about, but last I knew, libdvdmenu wasn't updated for the longest time and that's what xine used.
Perhaps you should actually make an attempt to find out, rather than ignorantly assuming that menu support isn't available. What's actually happened is that the menus have been rolled into the main Xine package, rather than being maintained as a separate package. Menu support under Xine is excellent; random or shuffle menus are not yet supported (many hardware DVD players don't support them, either, so this is hardly a major criticism) but menu support is complete and correct otherwise.
Boy, and I thought houses in housing developments were too cookie-cutter now.
This is hardly a new phenomenon. Builders have been making rows of houses with the same design at least since the early 20th Century. It's harder to see this in old neighborhoods because over time the owners make expansions and renovations or tear down some houses to put in newer ones, obscuring the initial similarity. If you look carefully, though, you can see that the houses are all duplicates in many places.
I find one of the worst trends in neighborhoods is houses that stand out (either they are ugly or make the rest look so).
I'm inclined to disagree, though perhaps that's just because I grew up in a neighborhood where no two houses were built at the same time or on the same pattern. I think that it's rather cool for every house to be different from every other house, even if some of the houses stand out from the rest. It definitely makes the neighborhood more interesting.
Funny that you should use that article as evidence that Kodak is behind. Take a look at the last paragraph:
Kodak has taken some significant strides forward. The company was the number one brand in digital cameras in America over the Christmas period and in the top three in Europe and China.
Kodak's problem doesn't seem to be that they're having trouble getting into the digital camera business; they're actually doing pretty well. Their problem seems to be that they have a large film business that's dragging the company's overall profitability down. Any company would have problems if their main business suddenly became technolgically obsolete. It's a measure of Kodak's good management that they've remained profitable.
I'm very glad not to have this kind of problem. My Dad has been using computers since the days of punch cards, and he was the one who introduced me to Linux. The tech support questions I tend to get from him are things like "Which distribution are you using these days?" Naturally, he's more than capable of taking care of my Mom's tech support issues.
There are some natural limits to how much Microsoft will be able to cheat those PHBs, though. Even a PHB understands that paying money for no product is a waste. Once the shiny PHB magazines start talking favorably about some alternative to Microsoft, especially if it's presented as the latest greatest thing, the PHBs will start to run away from MS with the same lemminglike fervor that they started running toward it with years ago. At that point, the Microsoft empire will be finished.
The only problem is that Dell screws you anyway. I just tried their site and configured two identical desktop systems, except that one came with FreeDos and one with WindowsXP Home (but no Office software). The XP system came out $73 less than the FreeDos system. I guess that Dell though that nobody would notice, because the price difference wouldn't have shown up if I had decided to splurge and buy Office as well as XP.
I can't speak for anyone else, but the reason that I avoid using $_ is because of scope problems. $_ is made local when perl automatically substitutes something into it (i.e. with map, grep, foreach without explicit variable asignment, etc.) but otherwise it's global. The worst thing is that it's a global variable that careless programmers are especially inclined to use without a second thought about the consequences. After spending a few hours tracking down a bug caused by this exact kind of carelessness (exclusively my own; I can't blame anyone else) convinced me to avoid using $_ except in the narrowest cases.
The team could hack into computers running these programs by using specially crafted network packets to fool the spyware into thinking it was receiving a legitimate software update. This technique could be used to take complete control of a computer.
Ugh! So not only are spyware creators trying to slip their junk onto unsuspecting users' computers without their knowledge, they're also making the machines more vulnerable to other malware in the process. And, as the author of the article points out, if a user doesn't even know that the spyware is on his machine- and the spyware author doesn't want to alert him to that fact- there's no real chance of patching the hole. It's just one more example of why it's evil to keep users in the dark about what's going on with their computers.
And don't forget about Ponie, the project to build a Perl 5 interpreter on top of Parrot. That means that Perl 5 should continue to be useful even if the existing core code is eventually scrapped. This, of course, is one of the principal advantages of having a multilingual VM; any language that can target that VM can be maintained with much less effort.
If you look at the Parrot FAQ, they explain exactly why they chose to write their own VM instead of using JVM or CLR. To quote:
Why your own virtual machine? Why not compile to JVM/.NET?
Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that Perl would run more slowly there than on an interpreter geared towards dynamic languages.
The.NET VM didn't even exist when we started development, or at least we didn't know about it when we were working on the design. We do now, though it's still not suitable.
FWIW, it looks as though Parrot will give very good performance as VMs go. Python for Parrot (at least the parts that work already) is faster than the existing implimentation of Python, and there's every reason to think that the same will be true of Perl, Ruby, and whatever other languages they impliment.
It also helps enormously that there are clear expectations of what Perl documentation is supposed to look like. By the time you've read the documentation for four or five modules, it's very clear that there are expected parts. Everyone knows what the format is supposed to be, so everyone uses it. That means that A) you know where in the documentation to find the information you need, and B) it will be there when you look for it.
One thing that you really have to love about the people who write Perl is that they have a sense of humor. This kind of document could be extremely boring and bland, but Damian had the good sense to liven it up by using humorous examples, mostly drawn from Shakespeare. He's doing some great work, but he's also obviously having fun doing it.
all of my installs have been on a freshly formatted drive.
As an aside, you can save yourself a lot of trouble in doing a fresh install with some intelligent partitioning. Most systems have an expert mode (or may offer nothing but expert mode, depending on the system) that lets you specify which partition corresponds to which mount point manually and decide which partitions should and should not be reformatted. If you set up/home on a separate partition, you can wipe everything else while leaving your user data alone. That can save you the trouble of having to restore all of your personal files when you install the new system. It's not necessarily perfect- some configuration files may change between versions of your favorite desktop environment, for instance- but it's a big improvement. You should obviously back up your data before doing the install just in case, but you should be doing periodic backups of your system already anyway.
It's not just community spririt; it's actually their job. While the NSA is well known for its role as a spy agency stealing other countries' secrets, it has a less well known role of helping America to protect its own secrets. Looking at their mission statement on their web site, they say that their goal includes:
The Information Assurance mission provides the solutions, products, and services, and conducts defensive information operations, to achieve information assurance for information infrastructures critical to U.S. national security interests.
IOW, designing secure computer systems is a critical part of their job. Making SELinux means that, as an example, DOD projects that use Linux- and the DOD likes Linux quite a bit- will now be that much more secure.
Except that this isn't necessarily true. It's probably true that there's an inverse relationship between convenience and security within a given security architecture, but the whole point of SELinux is that it changes the architecture. There's no loss of convenience to a user when suid programs are replaced by ones that have specific limited privileges, but there is a big gain in security. An average user probably won't even notice that they're using a SELinux system instead of an older system. It may be more of a pain for administrators, and certainly will be more of a pain for distribution writers, but they're professionals who should be able to deal with it.
I'm not so sure whether the problems you have with maintaining large Perl programs are caused by Perl or are a result of bad habits from writing small programs. This may be more of a problem in Perl, both because there are more nasty habits to get into and more programmers who are used to working exclusively on small projects where they can get away with using them, but it's hardly unique to Perl. Nobody says that C is a bad language because it has lots of ugly hacks and different programmers have different styles. Instead they impose standards and code reviews to make sure that their programmers are writing maintainably. There's no reason that the same practices can't be applied successfully to Perl. Perl6 may actually be an improvement on this point; my understanding is that it will make it easier to create pragmatic modules that enforce these kinds of coding standards.
I think that a lot of the complaints about ugly code come from two things: excessive use of automatic variables like @_ and $!, and regexps. Reading automatic variables is something that comes with practice (Quick! Do you know what @+ is?) but reading regexps is likely to remain a problem until people start using/x (or Perl6) and comment them.
You might be interested in Ponie, then. Ponie is the project to create a Perl5 interpreter for Parrot. It should let you get much of the speed benefit of the new virtual machine without having to learn the new Perl6 syntax. Of course you may still want to learn the new syntax, since it will add many powerful new features, but Ponie will ensure that Perl5- and all of the work you've put into your Perl5 scripts- won't be completely abandoned just because Perl6 has come out.
The article is from CNN, not directly from NASA, so you can't conclude anything about what units NASA is using by reading it. If you actually go to the JPL website, it turns out that the original material from NASA uses metric units as the primary measure, with Imperial units added for ease of comprehension.
I think that what you really want is something like (stealing shamelessly):
URGENT AND CONFIDENTIAL
ATTN: DIRECTOR/C.E.O.
Dear Sir,
REQUEST FOR URGENT SEXTACULAR RELATIONSHIP
Please forgive us for making your acquaintance in so informal a manner. I must solicit your strictest confidence in this transaction.
This is by virtue of its nature utterly confidential and 'top secret'. You have been recommended by an associate who assured me in confidence of your ability and reliability to give it to filthy teen sluts all night long.
We are top officials of the hot sex whore XXXX cum palace who are interested in importation of goods into your bedroom with hot sexy teens who will beg for it all night long. In order to commencet his business we solicit your assistance to help us transfer into your bedroom said hot lesbian action. XXX.
Please, note that this transaction is 100% safe and we hope to commence the night of hot sucking and mind-blowing sex by gorgeous women who will cater to your every need.
The above information will enable us to satisfy your every fantasy and let you find out what everyone is talking about. We are looking forward to you doing your business with our legions of lesbian coed big breasted nymphos. They want your big throbbing cock inside their hot pussies as
you plunge your manhood deep inside them as they whimper with pleasure and beg you to fuck them harder and harder all night long and you will cum so hard in those filthy whore teen slut lesbian HOT SEX XXXXX ACTION THEY WANT IT FROM YOU SO BAD GIVE IT TO THEM HARDER AND HARDER AND DON'T STOP THIS WILL BE THE GREATEST MOMENT OF YOUR LIFE AND YOU WILL THINK YOU ARE LIVING IN A FANTASY WORLD THE SEX WILL MAKE YOU SO HOT WITH THAT HUGE COCK OF YOURS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
Remember this is deal, so treat with utmost confidentiality.
But you're missing the point that this doesn't require any extra ports being open. The listener waits for the correct series of attempted connections to closed ports, and then transiently opens an otherwise closed port. Thus the approach lets you leave a port open temporarily when you would otherwise have to leave it open all the time, so it should add safety by your known good administration practices.
That means that, for instance, with a well configured system, a buffer overflow DOES NOT provide root on the box - it just crashes the process that was overflowed.
That's not quite right. What it really means is that it's now possible to set up a system where being root doesn't give you complete control over the system. IOW a cracker can open up a root shell on your box and still not be able to do much damage.
What makes you so sure that your governor hasn't done exactly the same thing? It sounds as though the people in Utah only found out about their being entered in the program because they got a new governor. It was a big surprise even to other people in the state government. If that can happen in Utah, it can happen in your state or mine. People in other parts of the country may well have had their information in the same program and simply not know about it because their governments haven't let the cat out of the bag yet. That's the truly scary implication of the situation.
Slashdot Mirror
Perhaps you should actually make an attempt to find out, rather than ignorantly assuming that menu support isn't available. What's actually happened is that the menus have been rolled into the main Xine package, rather than being maintained as a separate package. Menu support under Xine is excellent; random or shuffle menus are not yet supported (many hardware DVD players don't support them, either, so this is hardly a major criticism) but menu support is complete and correct otherwise.
This is hardly a new phenomenon. Builders have been making rows of houses with the same design at least since the early 20th Century. It's harder to see this in old neighborhoods because over time the owners make expansions and renovations or tear down some houses to put in newer ones, obscuring the initial similarity. If you look carefully, though, you can see that the houses are all duplicates in many places.
I'm inclined to disagree, though perhaps that's just because I grew up in a neighborhood where no two houses were built at the same time or on the same pattern. I think that it's rather cool for every house to be different from every other house, even if some of the houses stand out from the rest. It definitely makes the neighborhood more interesting.
Funny that you should use that article as evidence that Kodak is behind. Take a look at the last paragraph:
Kodak's problem doesn't seem to be that they're having trouble getting into the digital camera business; they're actually doing pretty well. Their problem seems to be that they have a large film business that's dragging the company's overall profitability down. Any company would have problems if their main business suddenly became technolgically obsolete. It's a measure of Kodak's good management that they've remained profitable.
I'm very glad not to have this kind of problem. My Dad has been using computers since the days of punch cards, and he was the one who introduced me to Linux. The tech support questions I tend to get from him are things like "Which distribution are you using these days?" Naturally, he's more than capable of taking care of my Mom's tech support issues.
There are some natural limits to how much Microsoft will be able to cheat those PHBs, though. Even a PHB understands that paying money for no product is a waste. Once the shiny PHB magazines start talking favorably about some alternative to Microsoft, especially if it's presented as the latest greatest thing, the PHBs will start to run away from MS with the same lemminglike fervor that they started running toward it with years ago. At that point, the Microsoft empire will be finished.
The only problem is that Dell screws you anyway. I just tried their site and configured two identical desktop systems, except that one came with FreeDos and one with WindowsXP Home (but no Office software). The XP system came out $73 less than the FreeDos system. I guess that Dell though that nobody would notice, because the price difference wouldn't have shown up if I had decided to splurge and buy Office as well as XP.
I can't speak for anyone else, but the reason that I avoid using $_ is because of scope problems. $_ is made local when perl automatically substitutes something into it (i.e. with map, grep, foreach without explicit variable asignment, etc.) but otherwise it's global. The worst thing is that it's a global variable that careless programmers are especially inclined to use without a second thought about the consequences. After spending a few hours tracking down a bug caused by this exact kind of carelessness (exclusively my own; I can't blame anyone else) convinced me to avoid using $_ except in the narrowest cases.
Ugh! So not only are spyware creators trying to slip their junk onto unsuspecting users' computers without their knowledge, they're also making the machines more vulnerable to other malware in the process. And, as the author of the article points out, if a user doesn't even know that the spyware is on his machine- and the spyware author doesn't want to alert him to that fact- there's no real chance of patching the hole. It's just one more example of why it's evil to keep users in the dark about what's going on with their computers.
And don't forget about Ponie, the project to build a Perl 5 interpreter on top of Parrot. That means that Perl 5 should continue to be useful even if the existing core code is eventually scrapped. This, of course, is one of the principal advantages of having a multilingual VM; any language that can target that VM can be maintained with much less effort.
If you look at the Parrot FAQ, they explain exactly why they chose to write their own VM instead of using JVM or CLR. To quote:
FWIW, it looks as though Parrot will give very good performance as VMs go. Python for Parrot (at least the parts that work already) is faster than the existing implimentation of Python, and there's every reason to think that the same will be true of Perl, Ruby, and whatever other languages they impliment.
It also helps enormously that there are clear expectations of what Perl documentation is supposed to look like. By the time you've read the documentation for four or five modules, it's very clear that there are expected parts. Everyone knows what the format is supposed to be, so everyone uses it. That means that A) you know where in the documentation to find the information you need, and B) it will be there when you look for it.
One thing that you really have to love about the people who write Perl is that they have a sense of humor. This kind of document could be extremely boring and bland, but Damian had the good sense to liven it up by using humorous examples, mostly drawn from Shakespeare. He's doing some great work, but he's also obviously having fun doing it.
Interesting. If you check them out on Netcraft, it turns out that:
No wonder they're having problems. It also suggests that they're not particularly committed to Linux, doesn't it?
As an aside, you can save yourself a lot of trouble in doing a fresh install with some intelligent partitioning. Most systems have an expert mode (or may offer nothing but expert mode, depending on the system) that lets you specify which partition corresponds to which mount point manually and decide which partitions should and should not be reformatted. If you set up /home on a separate partition, you can wipe everything else while leaving your user data alone. That can save you the trouble of having to restore all of your personal files when you install the new system. It's not necessarily perfect- some configuration files may change between versions of your favorite desktop environment, for instance- but it's a big improvement. You should obviously back up your data before doing the install just in case, but you should be doing periodic backups of your system already anyway.
It's not just community spririt; it's actually their job. While the NSA is well known for its role as a spy agency stealing other countries' secrets, it has a less well known role of helping America to protect its own secrets. Looking at their mission statement on their web site, they say that their goal includes:
IOW, designing secure computer systems is a critical part of their job. Making SELinux means that, as an example, DOD projects that use Linux- and the DOD likes Linux quite a bit- will now be that much more secure.
Except that this isn't necessarily true. It's probably true that there's an inverse relationship between convenience and security within a given security architecture, but the whole point of SELinux is that it changes the architecture. There's no loss of convenience to a user when suid programs are replaced by ones that have specific limited privileges, but there is a big gain in security. An average user probably won't even notice that they're using a SELinux system instead of an older system. It may be more of a pain for administrators, and certainly will be more of a pain for distribution writers, but they're professionals who should be able to deal with it.
Couldn't you just use:
or would that not be fun enough?
I'm not so sure whether the problems you have with maintaining large Perl programs are caused by Perl or are a result of bad habits from writing small programs. This may be more of a problem in Perl, both because there are more nasty habits to get into and more programmers who are used to working exclusively on small projects where they can get away with using them, but it's hardly unique to Perl. Nobody says that C is a bad language because it has lots of ugly hacks and different programmers have different styles. Instead they impose standards and code reviews to make sure that their programmers are writing maintainably. There's no reason that the same practices can't be applied successfully to Perl. Perl6 may actually be an improvement on this point; my understanding is that it will make it easier to create pragmatic modules that enforce these kinds of coding standards.
I think that a lot of the complaints about ugly code come from two things: excessive use of automatic variables like @_ and $!, and regexps. Reading automatic variables is something that comes with practice (Quick! Do you know what @+ is?) but reading regexps is likely to remain a problem until people start using /x (or Perl6) and comment them.
You might be interested in Ponie, then. Ponie is the project to create a Perl5 interpreter for Parrot. It should let you get much of the speed benefit of the new virtual machine without having to learn the new Perl6 syntax. Of course you may still want to learn the new syntax, since it will add many powerful new features, but Ponie will ensure that Perl5- and all of the work you've put into your Perl5 scripts- won't be completely abandoned just because Perl6 has come out.
The article is from CNN, not directly from NASA, so you can't conclude anything about what units NASA is using by reading it. If you actually go to the JPL website, it turns out that the original material from NASA uses metric units as the primary measure, with Imperial units added for ease of comprehension.
I think that what you really want is something like (stealing shamelessly):
But you're missing the point that this doesn't require any extra ports being open. The listener waits for the correct series of attempted connections to closed ports, and then transiently opens an otherwise closed port. Thus the approach lets you leave a port open temporarily when you would otherwise have to leave it open all the time, so it should add safety by your known good administration practices.
That's not quite right. What it really means is that it's now possible to set up a system where being root doesn't give you complete control over the system. IOW a cracker can open up a root shell on your box and still not be able to do much damage.
What makes you so sure that your governor hasn't done exactly the same thing? It sounds as though the people in Utah only found out about their being entered in the program because they got a new governor. It was a big surprise even to other people in the state government. If that can happen in Utah, it can happen in your state or mine. People in other parts of the country may well have had their information in the same program and simply not know about it because their governments haven't let the cat out of the bag yet. That's the truly scary implication of the situation.